From lukeshu at lukeshu.com Thu Mar 1 07:21:17 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Thu, 01 Mar 2018 02:21:17 -0500 Subject: [Dev] [PATCH] make librechroot target arch agnostic In-Reply-To: <20180227061816.GA5175@parabola-pocket.localdomain> References: <20180227061816.GA5175@parabola-pocket.localdomain> Message-ID: <87woywdzwy.wl-lukeshu@lukeshu.com> On Tue, 27 Feb 2018 01:18:16 -0500, Andreas Grapentin wrote: > > Hi, > > in the light of my attempts to create a riscv64 parabola port, I would > like to see the following changes made to librechroot. > > The patch removes the hard-coded arm cross arch checks in favour of a > more general approach, that works for more architectures. As a side > effect, this now also would behave correctly when creating x86 chroots > on arm, although why anyone would choose to do this is beyond me. > > Looks OK? > > Cheers, > Andreas > > --- > src/chroot-tools/librechroot | 20 ++++++++++++-------- > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot > index 27e17bd..750f34c 100755 > --- a/src/chroot-tools/librechroot > +++ b/src/chroot-tools/librechroot > @@ -69,17 +69,21 @@ hack_arch_nspawn_flags() { > CARCH="$(uname -m)" > fi > > - if [[ "$CARCH" == armv7h ]] && ! setarch armv7l /bin/true 2>/dev/null; then > - # We're running an ARM chroot on a non-ARM processor > + case $CARCH in > + armv7h) _setarch=armv7l ; _qemuarch=arm ;; > + *) _setarch=$CARCH ; _qemuarch=$CARCH ;; > + esac 1. These variables should be declared local. 2. No need to _underscore them. 3. I'd like it to reference a complete interpreter, rather than Qemu's processor family name. Something like: local setarch interpreter case "$CARCH" in armv7h) setarch=armv7l; interpreter=/usr/bin/qemu-arm-static ;; *) setarch=$CARCH; interpreter=/usr/bin/qemu-$CARCH-static ;; esac > + if ! setarch $_setarch /bin/true 2>/dev/null; then > + # We're running a cross-arch chroot > > # Make sure that qemu-static is set up with binfmt_misc > if [[ -z $(grep -l -xF \ > - -e 'interpreter /usr/bin/qemu-arm-static' \ > + -e "interpreter /usr/bin/qemu-$_qemuarch-static" \ > -r -- /proc/sys/fs/binfmt_misc 2>/dev/null \ > | xargs -r grep -xF 'enabled') ]] > then > - error 'Cannot cross-compile for ARM on x86' > - plain 'This requires a binfmt_misc entry for qemu-arm-static.' > + error 'Cannot cross-compile for %s on %s' $CARCH $(uname -m) > + plain 'This requires a binfmt_misc entry for qemu-%s-static.' $_qemuarch `$CARCH`, `$(uname -m)`, and `$_qemuarch` should be quoted. > prose 'Such a binfmt_misc entry is provided by the %s > package. If you have it installed, but still see > this message, you may need to restart %s.' \ > @@ -88,13 +92,13 @@ hack_arch_nspawn_flags() { > fi > > # Let qemu/binfmt_misc do its thing > - arch_nspawn_flags+=(-f /usr/bin/qemu-arm-static -s) > + arch_nspawn_flags+=(-f /usr/bin/qemu-$_qemuarch-static -s) > > # The -any packages are built separately for ARM from > # x86, so if we use the same CacheDir as the x86 host, > # then there will be PGP errors. > - mkdir -p /var/cache/pacman/pkg-arm > - arch_nspawn_flags+=(-c /var/cache/pacman/pkg-arm) > + mkdir -p /var/cache/pacman/pkg-$CARCH > + arch_nspawn_flags+=(-c /var/cache/pacman/pkg-$CARCH) > fi > } > > -- > 2.16.2 The rest of it LGTM. -- Happy hacking, ~ Luke Shumaker From andreas at grapentin.org Thu Mar 1 09:00:21 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Thu, 1 Mar 2018 10:00:21 +0100 Subject: [Dev] [PATCHv2] make librechroot target arch agnostic Message-ID: <20180301090021.GA22117@parabola-pocket.localdomain> Hi, Thanks for the feedback :) I have attached an updated patch. -A --- src/chroot-tools/librechroot | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot index 27e17bd..dec14bc 100755 --- a/src/chroot-tools/librechroot +++ b/src/chroot-tools/librechroot @@ -69,17 +69,22 @@ hack_arch_nspawn_flags() { CARCH="$(uname -m)" fi - if [[ "$CARCH" == armv7h ]] && ! setarch armv7l /bin/true 2>/dev/null; then - # We're running an ARM chroot on a non-ARM processor + local setarch interpreter + case $CARCH in + armv7h) setarch=armv7l; interpreter=/usr/bin/qemu-arm-static ;; + *) setarch=$CARCH; interpreter=/usr/bin/qemu-$CARCH-static ;; + esac + if ! setarch $setarch /bin/true 2>/dev/null; then + # We're running a cross-arch chroot # Make sure that qemu-static is set up with binfmt_misc if [[ -z $(grep -l -xF \ - -e 'interpreter /usr/bin/qemu-arm-static' \ + -e "interpreter $interpreter" \ -r -- /proc/sys/fs/binfmt_misc 2>/dev/null \ | xargs -r grep -xF 'enabled') ]] then - error 'Cannot cross-compile for ARM on x86' - plain 'This requires a binfmt_misc entry for qemu-arm-static.' + error 'Cannot cross-compile for %s on %s' "$CARCH" "$(uname -m)" + plain 'This requires a binfmt_misc entry for %s.' "$interpreter" prose 'Such a binfmt_misc entry is provided by the %s package. If you have it installed, but still see this message, you may need to restart %s.' \ @@ -88,13 +93,13 @@ hack_arch_nspawn_flags() { fi # Let qemu/binfmt_misc do its thing - arch_nspawn_flags+=(-f /usr/bin/qemu-arm-static -s) + arch_nspawn_flags+=(-f $interpreter -s) # The -any packages are built separately for ARM from # x86, so if we use the same CacheDir as the x86 host, # then there will be PGP errors. - mkdir -p /var/cache/pacman/pkg-arm - arch_nspawn_flags+=(-c /var/cache/pacman/pkg-arm) + mkdir -p /var/cache/pacman/pkg-$CARCH + arch_nspawn_flags+=(-c /var/cache/pacman/pkg-$CARCH) fi } -- 2.16.2 -- ------------------------------------------------------------------------------ Andreas Grapentin, M.Sc. Research Assistant @ Hasso-Plattner-Institut Operating Systems and Middleware Group www.dcl.hpi.uni-potsdam.de Phone: +49 (0) 331 55 09-238 Fax: +49 (0) 331 55 09-229 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 nobody at parabola.nu Fri Mar 2 14:06:49 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 02 Mar 2018 14:06:49 -0000 Subject: [Dev] Orphan Pcr package [openrc] marked out-of-date Message-ID: <20180302140649.799.2196@proton.parabola.nu> voidanix at gmail.com wants to notify you that the following packages may be out-of-date: * openrc 0.34.11-3.parabola1 [pcr] (armv7h): https://parabolagnulinux.org/packages/pcr/armv7h/openrc/ * openrc 0.34.11-3.parabola1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/openrc/ * openrc 0.34.11-3.parabola1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/openrc/ * openrc-init 0.34.11-3.parabola1 [pcr] (armv7h): https://parabolagnulinux.org/packages/pcr/armv7h/openrc-init/ * openrc-init 0.34.11-3.parabola1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/openrc-init/ * openrc-init 0.34.11-3.parabola1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/openrc-init/ The user provided the following additional text: As of 2018-03-02 the OpenRC 0.35.2 package is available on GitHub. From adfeno at hyperbola.info Fri Mar 2 19:16:42 2018 From: adfeno at hyperbola.info (Adonay Felipe Nogueira) Date: Fri, 02 Mar 2018 16:16:42 -0300 Subject: [Dev] Is Iridium safe to use? In-Reply-To: <188848491.vilEeLjz0v@iserlohn-fortress.net> (jc gargma's message of "Wed, 15 Nov 2017 12:12:23 -0800") References: <5A0C94FE.1070906@gmail.com> <87bmk3xqff.fsf@hyperbola.info> <188848491.vilEeLjz0v@iserlohn-fortress.net> Message-ID: <87muzqthid.fsf@hyperbola.info> 2017-11-15T13:12:23-0800 jc_gargma wrote: > When you post the results of QtWebEngine, please cc qtwebengine at qt-project.org > so that they are not left out of the loop this time. > Qt is a friend to the free software community. Please give them the chance to > fix the issues. > > > -jc Could someone plese help? It mostly involves doing the same as we are doing for Chromium ([1]) and for Discourse ([2]) --- see the tools used to evaluate the entries, the results I posted there are currently only in raw, so there is lots of false-positives, but the hints for the tools and methos should prove useful. I'm somewhat overworked already, so I can't take any more entries/packages/software to evaluate. For all the entries that need [re]evaluation, see [3]. There might be more to add to [3], but I'm not aware of any currently. [1] . [2] . [3] . -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (n?o confundir com gratis). - "WhatsApp"? Ele n?o ? livre. Por favor, veja formas de se comunicar instantaneamente comigo no endere?o abaixo. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padr?o ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM. From lukeshu at lukeshu.com Fri Mar 2 21:15:04 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 02 Mar 2018 16:15:04 -0500 Subject: [Dev] FWD: [openbsd-ports] Porters, please read re GitHub auto-generated tarballs vs releases Message-ID: <87r2p2dvs7.wl-lukeshu@lukeshu.com> FYI. Many Parabola PKGBUILDs also use this. https://marc.info/?l=openbsd-ports&m=151973450514279 On 2018-02-27 at 12:28:07 Stuart Henderson wrote: > Many ports are using github's on-the-fly generated source-code tarballs > via the GH_ variables in Makefiles. > > These are *not* guaranteed to be stable, they can change as github > update software and caches expire (this has happened at some point over > the last few months so we have been seeing a number of hash failures > recently). Due to local caches at the github clusters, these files > can be different depending on which cluster you're connecting to, > so if you regenerate distinfo to match the file which you see > locally, it may cause breakage elsewhere in the world. > > : "It is not meant to be reliable or a way to distribute software > : releases and nothing in the software stack is made to try to > : produce consistent archives." > > Sometimes upstream *only* provides these auto generated files, but in > other cases they use github's releases infrastructure and upload "normal" > generated distfiles which are not then subject to change. > > To identify this, go to the project's "releases" page. > Using an example of a port I've just fixed: > > https://github.com/rdoeffinger/iec16022/releases/. > > Under "Assets" on this page, you might see files with a "box" icon > which are uploads. > > On the iec16022 page I'm using as an example, Assets has these: > > iec16022-0.3.0.exe <- uploaded windows binary > iec16022-0.3.0.tar.xz <- uploaded source tarball > iec16022-0.3.0.tar.xz.asc <- uploaded gpg sig > Source code (zip) <- auto generated > Source code (tar.gz) <- auto generated > > If there are only entries for "Source code (zip)" and "Source code > (tar.gz)" the only options are to use GH_TAGNAME or ask upstream to > upload a file. > > But in the case above, a proper distfile is available, so I've > switched the graphics/iec16022 port across to use it. > > This is done by avoiding the GH_* variables and reducing the amount > of magic in the ports Makefile: just use DISTNAME and MASTER_SITES > as standard, and set HOMEPAGE if needed (it's provided automatically > when GH_* are set). > > You will also often find that these uploaded tarballs have autoconf > scripts etc. generated, whereas they aren't present in the auto- > generated tarballs, so you may be able to remove make targets and > dependencies needed to generate these. > > If you are publishing your own software to github, please do use > the releases infrastructure and upload distfiles that you have > generated yourself! > > I've done a query of the github releases API for all ports that are > currently using GH_TAGNAME and looked at assets for these. I have skipped > the ones where the assets are clearly only for distributing binaries and > listed the others: it is quite likely that the following ports do have > source tarballs available which can be used instead of the auto-generated > ones. > > archivers/deutex > astro/stellarium > audio/audiality2 > audio/cantata > audio/mumble > audio/puddletag > devel/cpp-hocon > devel/leatherman > devel/lua-tz > devel/msgpack > devel/ocaml-extlib > devel/protobuf-c > fonts/fantasque-sans > fonts/overpass > games/fs2open > games/megaglest/base > games/megaglest/data > games/unknown-horizons > geo/osm-gps-map > graphics/ffmpegthumbnailer > graphics/glm > graphics/py-cairo > graphics/vigra > inputmethods/ibus > inputmethods/ibus-anthy > mail/mu > math/libtommath > misc/redshift > multimedia/streamlink > net/avahi > net/libproxy > net/libstrophe > net/lua-mmdb > net/lua-psl > net/nagios/check_rabbitmq > net/rabbitmq-c > net/rsnapshot > print/cups > print/system-config-printer > security/gopass > security/opensc > security/plaso > security/py-dfdatetime > security/py-dfvfs > security/py-dfwinreg > sysutils/consolekit > sysutils/exfat-fuse > sysutils/fleetctl > sysutils/opam > sysutils/riemann-c-client > sysutils/rofi > sysutils/tree > textproc/enchant > textproc/libical > www/kore > www/liferea > www/py-jinja2 > www/wp-cli > x11/compton > x11/xdotool > x11/xwallpaper From lukeshu at lukeshu.com Fri Mar 2 21:18:01 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 02 Mar 2018 16:18:01 -0500 Subject: [Dev] FWD: [openbsd-ports] Porters, please read re GitHub auto-generated tarballs vs releases In-Reply-To: <87r2p2dvs7.wl-lukeshu@lukeshu.com> References: <87r2p2dvs7.wl-lukeshu@lukeshu.com> Message-ID: <87po4mdvna.wl-lukeshu@lukeshu.com> On 2018-02-27 at 12:28:07 Stuart Henderson wrote: > Many ports are using github's on-the-fly generated source-code tarballs > via the GH_ variables in Makefiles. > > These are *not* guaranteed to be stable, they can change as github > update software and caches expire (this has happened at some point over > the last few months so we have been seeing a number of hash failures > recently). Due to local caches at the github clusters, these files > can be different depending on which cluster you're connecting to, > so if you regenerate distinfo to match the file which you see > locally, it may cause breakage elsewhere in the world. That's a bummer. Around 2011, the auto-generated tarballs were really not stable; it would just about never give you the same file twice. Since then (2014-ish, maybe?), they had changed their implementation, and it it started consistently giving the same file, to different parts of the world (ie, probably hitting different clusters), for years. I had assumed that meant GitHub had committed to keeping them stable, and we started allowing them in Parabola. It's a bummer that in the last few months they've apparently started breaking that. Though I wonder if that's intentional/allowed, or if it's really just a bug in GitHub. > : "It is not meant to be reliable or a way to distribute software > : releases and nothing in the software stack is made to try to > : produce consistent archives." I can't seem to find a source for that quote. -- Happy hacking, ~ Luke Shumaker From bill-auger at peers.community Sat Mar 3 01:38:59 2018 From: bill-auger at peers.community (bill-auger) Date: Fri, 2 Mar 2018 20:38:59 -0500 Subject: [Dev] Is Iridium safe to use? In-Reply-To: <87muzqthid.fsf@hyperbola.info> References: <5A0C94FE.1070906@gmail.com> <87bmk3xqff.fsf@hyperbola.info> <188848491.vilEeLjz0v@iserlohn-fortress.net> <87muzqthid.fsf@hyperbola.info> Message-ID: there is no point to scrutinize iriduim (or ungoogled or any other derived browser) - their codebase is probably 99% similar to chromium; so if any of these have licensing issues it would be most likely what they derive from chromium - i would not begin to look at derivatives or qtwebengine until the issues with chromium are fully understood if actual notable problems are discovered in chromium, then the next step would be to report them to the chromium team - if chromium fixes the problem, then all down-streams will surely take the fix without question once the chromium search is completed exhaustively and no problems are found, or if problems were found and reported, but refused or neglected, then and only then it may be worthwhile to compare the results against derived browsers and qtwebengine and ask them to fix the problems in their forks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Sat Mar 3 02:03:03 2018 From: bill-auger at peers.community (bill-auger) Date: Fri, 2 Mar 2018 21:03:03 -0500 Subject: [Dev] FWD: [openbsd-ports] Porters, please read re GitHub auto-generated tarballs vs releases In-Reply-To: <87po4mdvna.wl-lukeshu@lukeshu.com> References: <87r2p2dvs7.wl-lukeshu@lukeshu.com> <87po4mdvna.wl-lukeshu@lukeshu.com> Message-ID: <0d743d13-a6fa-c4f2-edc6-75aea5894d7e@peers.community> On 03/02/2018 04:18 PM, Luke Shumaker wrote: > On 2018-02-27 at 12:28:07 > Stuart Henderson wrote: >> Many ports are using github's on-the-fly generated source-code tarballs >> via the GH_ variables in Makefiles. >> > Though I wonder if that's intentional/allowed, or if it's really just > a bug in GitHub. > >> : "It is not meant to be reliable or a way to distribute software >> : releases and nothing in the software stack is made to try to >> : produce consistent archives." > > I can't seem to find a source for that quote. > i would like to see that documentation also i dont know what those the GH_ variables in Makefiles actually do - but i can say from my experience that the github auto-generated "releases" that are based on git tags seem to be exactly what you get with the `git archive` command - i use a git commit hook that creates the tarball with `git archive` then signs it with GPG then downloads the auto-generated tarball from github and compares the local signature against the remote tarball before uploading the signature and i have not seen any in-consistency - maybe the "tagged" releases are more stable or maybe i have just been lucky i dunno -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From adfeno at hyperbola.info Sat Mar 3 18:01:40 2018 From: adfeno at hyperbola.info (Adonay Felipe Nogueira) Date: Sat, 03 Mar 2018 15:01:40 -0300 Subject: [Dev] Networking In-Reply-To: <6453917b-8abb-4d4d-7757-74bef3eb9d34@copper.net> (Carl & Kim's message of "Fri, 2 Feb 2018 18:43:01 -0700") References: <6453917b-8abb-4d4d-7757-74bef3eb9d34@copper.net> Message-ID: <874llxf37f.fsf@hyperbola.info> > 1 - Can't connect via wifi? on at least 2 of my computers.? Fails on > bootup -with message "direct firmware load for rtl9192ce > /*(DEBLOBBED)/ failed with error -2"? or words to that effect. True of [...] > 2 - Still trying to get a workiing install of either LXDE or MATE > openrc alpa? releases.? Installing to usb sticks.? Install & boots OK, > looks good.? Cannot connect to any wifi.? Many sites found, fail with > message "Not authorized to control networking" or words to that > effect.? Don't have wired connections to most computers.? If it does Any updates on the status of all this? -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (n?o confundir com gratis). - "WhatsApp"? Ele n?o ? livre. Por favor, veja formas de se comunicar instantaneamente comigo no endere?o abaixo. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padr?o ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM. From nobody at parabola.nu Wed Mar 7 20:23:28 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:23:28 -0000 Subject: [Dev] Orphan Libre package [mesa] marked out-of-date Message-ID: <20180307202328.799.16638@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * mesa 17.3.2-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/mesa/ * mesa 17.3.4-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/mesa/ * mesa 17.3.4-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/mesa/ The user provided the following additional text: Current release is 17.3.6 From nobody at parabola.nu Wed Mar 7 20:25:42 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:25:42 -0000 Subject: [Dev] Orphan Libre package [linux-libre-hardened] marked out-of-date Message-ID: <20180307202542.801.37210@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * linux-libre-hardened 4.15.2_gnu.a-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened/ * linux-libre-hardened 4.15.2_gnu.a-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened/ * linux-libre-hardened-docs 4.15.2_gnu.a-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened-docs/ * linux-libre-hardened-docs 4.15.2_gnu.a-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-docs/ * linux-libre-hardened-headers 4.15.2_gnu.a-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened-headers/ * linux-libre-hardened-headers 4.15.2_gnu.a-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-headers/ The user provided the following additional text: Current release is 4.15.7.a From nobody at parabola.nu Wed Mar 7 20:28:52 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:28:52 -0000 Subject: [Dev] Orphan Libre package [systemd] marked out-of-date Message-ID: <20180307202852.801.28203@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * libsystemd 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/libsystemd/ * libsystemd 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/libsystemd/ * libsystemd 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/libsystemd/ * libsystemd-standalone 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/libsystemd-standalone/ * libsystemd-standalone 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/libsystemd-standalone/ * libsystemd-standalone 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/libsystemd-standalone/ * libudev 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/libudev/ * libudev 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/libudev/ * libudev 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/libudev/ * nss-myhostname 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/nss-myhostname/ * nss-myhostname 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/nss-myhostname/ * nss-myhostname 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/nss-myhostname/ * nss-mymachines 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/nss-mymachines/ * nss-mymachines 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/nss-mymachines/ * nss-mymachines 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/nss-mymachines/ * nss-resolve 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/nss-resolve/ * nss-resolve 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/nss-resolve/ * nss-resolve 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/nss-resolve/ * nss-systemd 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/nss-systemd/ * nss-systemd 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/nss-systemd/ * nss-systemd 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/nss-systemd/ * systemd 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/systemd/ * systemd 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/systemd/ * systemd 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/systemd/ * systemd-sysvcompat 237.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/systemd-sysvcompat/ * systemd-sysvcompat 237.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/systemd-sysvcompat/ * systemd-sysvcompat 237.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/systemd-sysvcompat/ The user provided the following additional text: Current release is 237.64 From nobody at parabola.nu Wed Mar 7 20:42:30 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:42:30 -0000 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date Message-ID: <20180307204230.801.64969@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * linux-libre 4.15.2_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre/ * linux-libre 4.15.2_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/ * linux-libre-docs 4.15.2_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/ * linux-libre-docs 4.15.2_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/ * linux-libre-headers 4.15.2_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/ * linux-libre-headers 4.15.2_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/ The user provided the following additional text: Current release is 4.15.7 From nobody at parabola.nu Wed Mar 7 20:47:31 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:47:31 -0000 Subject: [Dev] Orphan Libre package [ark] marked out-of-date Message-ID: <20180307204731.801.90628@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * ark 17.12.1-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/ark/ * ark 17.12.1-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/ark/ * ark 17.12.1-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/ark/ The user provided the following additional text: Current release is 17.12.2 From jc_gargma at iserlohn-fortress.net Wed Mar 7 20:53:35 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 12:53:35 -0800 Subject: [Dev] Orphan Libre package [ark] marked out-of-date In-Reply-To: <20180307204731.801.90628@proton.parabola.nu> References: <20180307204731.801.90628@proton.parabola.nu> Message-ID: <5987470.oKB4SbI1f7@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update ark to 17.12.2 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-ark-to-17.12.2.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 20:57:20 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 20:57:20 -0000 Subject: [Dev] Orphan Libre package [khotkeys] marked out-of-date Message-ID: <20180307205720.801.20600@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * khotkeys 5.11.5-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/khotkeys/ * khotkeys 5.11.5-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/khotkeys/ * khotkeys 5.11.5-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/khotkeys/ The user provided the following additional text: Current release is 5.12.3 From jc_gargma at iserlohn-fortress.net Wed Mar 7 20:58:58 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 12:58:58 -0800 Subject: [Dev] Orphan Libre package [khotkeys] marked out-of-date In-Reply-To: <20180307205720.801.20600@proton.parabola.nu> References: <20180307205720.801.20600@proton.parabola.nu> Message-ID: <2445886.vUGHgXd9OJ@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update khotkeys to 5.12.3 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-khotkeys-to-5.12.3.patch Type: text/x-patch Size: 1675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 21:01:05 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 21:01:05 -0000 Subject: [Dev] Orphan Libre package [kinfocenter] marked out-of-date Message-ID: <20180307210105.801.50083@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * kinfocenter 5.11.5-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/kinfocenter/ * kinfocenter 5.11.5-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/kinfocenter/ * kinfocenter 5.11.5-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/kinfocenter/ The user provided the following additional text: Current release is 5.12.3 From jc_gargma at iserlohn-fortress.net Wed Mar 7 21:02:56 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 13:02:56 -0800 Subject: [Dev] Orphan Libre package [kinfocenter] marked out-of-date In-Reply-To: <20180307210105.801.50083@proton.parabola.nu> References: <20180307210105.801.50083@proton.parabola.nu> Message-ID: <1572142.y81jO5oefE@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update kinfocenter to 5.12.3 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-kinfocenter-to-5.12.3.patch Type: text/x-patch Size: 2239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 21:06:39 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 21:06:39 -0000 Subject: [Dev] Orphan Libre package [kio-extras] marked out-of-date Message-ID: <20180307210639.798.15766@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * kio-extras 17.12.1-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/kio-extras/ * kio-extras 17.12.1-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/kio-extras/ * kio-extras 17.12.1-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/kio-extras/ The user provided the following additional text: Current release is 17.12.2 From jc_gargma at iserlohn-fortress.net Wed Mar 7 21:08:10 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 13:08:10 -0800 Subject: [Dev] Orphan Libre package [kio-extras] marked out-of-date In-Reply-To: <20180307210639.798.15766@proton.parabola.nu> References: <20180307210639.798.15766@proton.parabola.nu> Message-ID: <2518735.CX3qDoPyj6@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update kio-extras to 17.12.2 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-kio-extras-to-17.12.2.patch Type: text/x-patch Size: 1566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 21:47:10 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 21:47:10 -0000 Subject: [Dev] Orphan Libre package [kio] marked out-of-date Message-ID: <20180307214710.801.30267@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * kio 5.42.0-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/kio/ * kio 5.42.0-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/kio/ * kio 5.42.0-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/kio/ The user provided the following additional text: Current release is 5.43.0 From jc_gargma at iserlohn-fortress.net Wed Mar 7 21:49:28 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 13:49:28 -0800 Subject: [Dev] Orphan Libre package [kio] marked out-of-date In-Reply-To: <20180307214710.801.30267@proton.parabola.nu> References: <20180307214710.801.30267@proton.parabola.nu> Message-ID: <47515778.zo0foiejOx@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update kio to 5.43.0 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-kio-to-5.43.0.patch Type: text/x-patch Size: 2575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From lukeshu at lukeshu.com Wed Mar 7 21:52:28 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 07 Mar 2018 16:52:28 -0500 Subject: [Dev] Orphan Libre package [ark] marked out-of-date In-Reply-To: <5987470.oKB4SbI1f7@iserlohn-fortress.net> References: <20180307204731.801.90628@proton.parabola.nu> <5987470.oKB4SbI1f7@iserlohn-fortress.net> Message-ID: <87ina7eeoz.wl-lukeshu@lukeshu.com> On Wed, 07 Mar 2018 15:53:35 -0500, jc_gargma wrote: > [1 ] > [1.1 ] > [1.1.1 ] > > The user provided the following additional text: > I've attached a git format-patch to update ark to 17.12.2 > > > -jc > [1.1.2 0001-Updated-ark-to-17.12.2.patch ] > From 186198af3497f90c75c11b888cc491f539c877c1 Mon Sep 17 00:00:00 2001 > From: jc_gargma > Date: Wed, 7 Mar 2018 11:57:12 -0800 > Subject: [PATCH] Updated ark to 17.12.2 > > --- > libre/ark/PKGBUILD | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libre/ark/PKGBUILD b/libre/ark/PKGBUILD > index f276cdce3a..2d85da09fe 100644 ... FYI, you can send the patch file directly using git send-email --to=dev at lists.parabola.nu 0001-Updated-ark-to-17.12.2.patch If you want to provide additional commentary in the email, without putting it in the commit message, you can stick it between the "---" and the first "diff" line (where the diffstat is) in the patch file. -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Wed Mar 7 21:53:33 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 21:53:33 -0000 Subject: [Dev] Orphan Libre package [konqueror] marked out-of-date Message-ID: <20180307215333.798.66103@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * konqueror 17.08.0-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/konqueror/ * konqueror 17.12.1-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/konqueror/ * konqueror 17.12.1-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/konqueror/ The user provided the following additional text: Current release is 17.12.2 From jc_gargma at iserlohn-fortress.net Wed Mar 7 21:55:24 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 13:55:24 -0800 Subject: [Dev] Orphan Libre package [konqueror] marked out-of-date In-Reply-To: <20180307215333.798.66103@proton.parabola.nu> References: <20180307215333.798.66103@proton.parabola.nu> Message-ID: <2036844.759Sh6Cs5F@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update konqueror to 17.12.2 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-konqueror-to-17.12.2.patch Type: text/x-patch Size: 1351 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 21:56:34 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 21:56:34 -0000 Subject: [Dev] Orphan Libre package [okular] marked out-of-date Message-ID: <20180307215634.801.66376@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * okular 17.12.1-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/okular/ * okular 17.12.1-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/okular/ * okular 17.12.1-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/okular/ The user provided the following additional text: Current release is 17.12.2 From jc_gargma at iserlohn-fortress.net Wed Mar 7 21:58:24 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 07 Mar 2018 13:58:24 -0800 Subject: [Dev] Orphan Libre package [okular] marked out-of-date In-Reply-To: <20180307215634.801.66376@proton.parabola.nu> References: <20180307215634.801.66376@proton.parabola.nu> Message-ID: <7920485.qRE2Dgj0aA@iserlohn-fortress.net> > The user provided the following additional text: I've attached a git format-patch to update okular to 17.12.2 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-okular-to-17.12.2.patch Type: text/x-patch Size: 1300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From nobody at parabola.nu Wed Mar 7 22:03:26 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 07 Mar 2018 22:03:26 -0000 Subject: [Dev] Orphan Libre package [qtcreator] marked out-of-date Message-ID: <20180307220326.800.67299@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * qtcreator 4.5.0-2.parabola2 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/qtcreator/ * qtcreator 4.5.0-2.parabola2 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/qtcreator/ * qtcreator 4.5.0-2.parabola2 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/qtcreator/ The user provided the following additional text: Current release is 4.5.1 From nobody at parabola.nu Sat Mar 10 04:10:19 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sat, 10 Mar 2018 04:10:19 -0000 Subject: [Dev] Orphan Libre package [qutebrowser] marked out-of-date Message-ID: <20180310041019.800.93863@proton.parabola.nu> kevin at kphoenix.us wants to notify you that the following packages may be out-of-date: * qutebrowser 1.1.1-1.parabola1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/qutebrowser/ The user provided the following additional text: https://blog.qutebrowser.org/qutebrowser-v120-released.html From nobody at parabola.nu Mon Mar 12 11:11:14 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 12 Mar 2018 11:11:14 -0000 Subject: [Dev] Orphan Libre package [virt-install] marked out-of-date Message-ID: <20180312111114.1229.87119@proton.parabola.nu> nroof at protonmail.com wants to notify you that the following packages may be out-of-date: * virt-install 1.5.0-1.parabola1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/virt-install/ The user provided the following additional text: Thank you for maintaining this package! A new version 1.5.1 is available: https://github.com/virt-manager/virt-manager/blob/v1.5-maint/NEWS.md Without this package, virt-manager, which comes from Arch, won't upgrade, here are the pacman complaints: warning: cannot resolve "virt-install=1.5.1", a dependency of "virt-manager" :: The following package cannot be upgraded due to unresolvable dependencies: virt-manager From megver83 at hyperbola.info Tue Mar 13 20:18:45 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 13 Mar 2018 17:18:45 -0300 Subject: [Dev] I'm back Message-ID: Hi everyone! You might have noticed that I've been away for some time (because of various reasons), and I saw that Andreas took the initiative of maintaining kernels and linux-libre-firmware. Just wanted to say that since I'm back I'll be in charge again, because to be honest (please don't take it bad, it's just my opinion) I really didn't like what I saw. Regards, -- ~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 Tue Mar 13 21:49:22 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 13 Mar 2018 21:49:22 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20180313214922.1230.82876@proton.parabola.nu> hjensen at mailbox.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:58.0-5.1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/iceweasel/ * iceweasel 1:58.0.2-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ * iceweasel 1:58.0.2-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ The user provided the following additional text: Firefox 59.0 is released From nobody at parabola.nu Wed Mar 14 01:15:05 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 14 Mar 2018 01:15:05 -0000 Subject: [Dev] Orphan Libre package [opencv] marked out-of-date Message-ID: <20180314011505.1232.48030@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * opencv 3.2.0-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/opencv/ * opencv 3.4.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/opencv/ * opencv 3.4.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/opencv/ The user provided the following additional text: Current release is 3.4.1 From nobody at parabola.nu Wed Mar 14 01:17:32 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 14 Mar 2018 01:17:32 -0000 Subject: [Dev] Orphan Libre package [openexr] marked out-of-date Message-ID: <20180314011732.1232.34156@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * openexr 2.2.0-3.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/openexr/ * openexr 2.2.0-3.parabola2 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/openexr/ * openexr 2.2.0-3.parabola2 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/openexr/ The user provided the following additional text: Current release is 2.2.1 From andreas at grapentin.org Wed Mar 14 10:10:45 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Wed, 14 Mar 2018 11:10:45 +0100 Subject: [Dev] I'm back In-Reply-To: References: Message-ID: <20180314101045.GA5020@parabola-pocket.localdomain> On Tue, Mar 13, 2018 at 05:18:45PM -0300, Megver83 wrote: > Hi everyone! You might have noticed that I've been away for some time > (because of various reasons), and I saw that Andreas took the initiative > of maintaining kernels and linux-libre-firmware. > > Just wanted to say that since I'm back I'll be in charge again, because > to be honest (please don't take it bad, it's just my opinion) I really > didn't like what I saw. You know what, this really annoys and upsets me. You needed to take a break, and couldn't maintain the kernels, that is fine with me. Life stuff happens and I can understand and relate to that. But when things fall apart, and somebody takes over and tries to fix your shit, you don't just come back and berate them for it, and take over again. That's just not done. *Especially* not on a public mailing list, and *Especially* not without presenting cause and reason for your criticism, and *MOST Especially* not without a word of thanks for taking over the work you left behind. I don't care if it's just 'your opinion', I'm not taking kindly to being personally and professionally attacked. Yes, I *am* taking this badly, and expect an apology. Best, Andreas -- ------------------------------------------------------------------------------ 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 jc_gargma at iserlohn-fortress.net Thu Mar 15 04:35:45 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Wed, 14 Mar 2018 21:35:45 -0700 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules Message-ID: <8268276.Okeu99Xnlx@iserlohn-fortress.net> The linux-libre-4.15.9_gnu-1-x86_64.pkg.tar.xz kernel update that just went live is missing numerous critical kernel modules. Had I not noticed the mkinitcpio errors during update I would have found my system unbootable. An quick exam shows all file-systems other than EXT4 have been disabled in the kernel configuration. So has dm-crypt and all libre wifi drivers. # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set # CONFIG_F2FS_FS is not set # CONFIG_FS_DAX is not set # CONFIG_DM_CRYPT is not set # CONFIG_ATH9K is not set # CONFIG_ATH9K_HTC is not set # CONFIG_B43 is not set # CONFIG_CARL9170 is not set These are missing across x86_64, i686, and armv7h architectures. If this kernel update is not replaced or reverted with haste a sizable portion of the Parabola userbase will likely find their systems unbootable or without wireless support within a very short timeframe. -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From andreas at grapentin.org Thu Mar 15 06:31:54 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Thu, 15 Mar 2018 07:31:54 +0100 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: <8268276.Okeu99Xnlx@iserlohn-fortress.net> References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> Message-ID: <20180315063154.GA22593@parabola-pocket.localdomain> On Wed, Mar 14, 2018 at 09:35:45PM -0700, jc_gargma wrote: > The linux-libre-4.15.9_gnu-1-x86_64.pkg.tar.xz kernel update that just went > live is missing numerous critical kernel modules. Had I not noticed the > mkinitcpio errors during update I would have found my system unbootable. > > An quick exam shows all file-systems other than EXT4 have been disabled in the > kernel configuration. So has dm-crypt and all libre wifi drivers. > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > # CONFIG_XFS_FS is not set > # CONFIG_GFS2_FS is not set > # CONFIG_OCFS2_FS is not set > # CONFIG_BTRFS_FS is not set > # CONFIG_NILFS2_FS is not set > # CONFIG_F2FS_FS is not set > # CONFIG_FS_DAX is not set > > # CONFIG_DM_CRYPT is not set > > # CONFIG_ATH9K is not set > # CONFIG_ATH9K_HTC is not set > # CONFIG_B43 is not set > # CONFIG_CARL9170 is not set > > These are missing across x86_64, i686, and armv7h architectures. This is bad. As a temporary hack, I removed linux-libre from the repositories, to mitigate the impact this upgrade would have on existing systems. However, this currently makes pacstrap incapable of bootstrapping and installing new systems, so we need a real fix ASAP. I see that my changes to the PKGBUILDs have been reverted, and an upgrade to 4.15.9 has been squashed into one ~40000 line commit, that I can't possibly review to figure out what's wrong. We need to wait for Megver before we can even start to sort this out. -A -- ------------------------------------------------------------------------------ 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 bill-auger at peers.community Thu Mar 15 12:36:52 2018 From: bill-auger at peers.community (bill-auger) Date: Thu, 15 Mar 2018 08:36:52 -0400 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: <20180315063154.GA22593@parabola-pocket.localdomain> References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> <20180315063154.GA22593@parabola-pocket.localdomain> Message-ID: <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> rather than leave the distro without a kernel surely the last know good build could be restored or re-created - even if it were a months old kernel it would be better than having none - i probably have a copy of 4.09 or 4.14 in a VM for example -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From andreas at grapentin.org Thu Mar 15 13:18:22 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Thu, 15 Mar 2018 14:18:22 +0100 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> <20180315063154.GA22593@parabola-pocket.localdomain> <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> Message-ID: <20180315131822.GA25221@parabola-pocket.localdomain> On Thu, Mar 15, 2018 at 08:36:52AM -0400, bill-auger wrote: > rather than leave the distro without a kernel surely the last know good > build could be restored or re-created - even if it were a months old > kernel it would be better than having none - i probably have a copy of > 4.09 or 4.14 in a VM for example > Good Point! After some minor surgery, the repos are now back at 4.15.2 without needing to touch the pkgbuilds. -A -- ------------------------------------------------------------------------------ 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 megver83 at hyperbola.info Thu Mar 15 14:47:13 2018 From: megver83 at hyperbola.info (Megver83) Date: Thu, 15 Mar 2018 11:47:13 -0300 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: <20180315131822.GA25221@parabola-pocket.localdomain> References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> <20180315063154.GA22593@parabola-pocket.localdomain> <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> <20180315131822.GA25221@parabola-pocket.localdomain> Message-ID: El 15/03/18 a las 10:18, Andreas Grapentin escribi?: > > On Thu, Mar 15, 2018 at 08:36:52AM -0400, bill-auger wrote: >> rather than leave the distro without a kernel surely the last know good >> build could be restored or re-created - even if it were a months old >> kernel it would be better than having none - i probably have a copy of >> 4.09 or 4.14 in a VM for example >> > > Good Point! > > After some minor surgery, the repos are now back at 4.15.2 without > needing to touch the pkgbuilds. > > -A > > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > Hey, Sorry for this, I shouldn't have had used the defconfig :S I'll rebuild it as soon as possible. -- ~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 Thu Mar 15 15:26:24 2018 From: bill-auger at peers.community (bill-auger) Date: Thu, 15 Mar 2018 11:26:24 -0400 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> <20180315063154.GA22593@parabola-pocket.localdomain> <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> <20180315131822.GA25221@parabola-pocket.localdomain> Message-ID: <5617a6bc-facf-e2d5-5d88-6eccd65ca2f2@peers.community> i guess we all can make mistakes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Thu Mar 15 23:28:45 2018 From: megver83 at hyperbola.info (Megver83) Date: Thu, 15 Mar 2018 20:28:45 -0300 Subject: [Dev] [RFC] Deprecation of webkitgtk2 Message-ID: <784bf28d-6d23-7ada-c783-9610165a4d7b@hyperbola.info> I've been removing some [nonprism] packages that are not any longer in the rest of the repos (excepting, of course, the *-hardened-preferences packages). However, there's only one that I haven't removed and it's webkitgtk. It seems that only two packages depend on it: freefilesync and vimprobable2-git, both outdated. Idk how much ppl use those packages, because we can add the webkitgtk2 pkg with its "prism" version in [pcr] so we don't break dependencies. The other option is two remove freefilesync and vimprobable2-git, so we can safely remove webkitgtk2. -- ~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 Thu Mar 15 23:37:56 2018 From: megver83 at hyperbola.info (Megver83) Date: Thu, 15 Mar 2018 20:37:56 -0300 Subject: [Dev] [RFC] Deprecation of webkitgtk2 In-Reply-To: <784bf28d-6d23-7ada-c783-9610165a4d7b@hyperbola.info> References: <784bf28d-6d23-7ada-c783-9610165a4d7b@hyperbola.info> Message-ID: <3b6076a8-5349-aaf8-7c66-11d0205cae8d@hyperbola.info> El 15/03/18 a las 20:28, Megver83 escribi?: > However, there's only one that I haven't removed and it's webkitgtk. It > seems that only two packages depend on it: freefilesync and > vimprobable2-git, both outdated. Btw, it seems that the AUR version[0] uses webkit2gtk instead of webkitgtk2 [0] https://aur.archlinux.org/packages/freefilesync/ -- ~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 andreas at grapentin.org Fri Mar 16 08:48:47 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Fri, 16 Mar 2018 09:48:47 +0100 Subject: [Dev] PING: [PATCHv2] make librechroot target arch agnostic In-Reply-To: <20180301090021.GA22117@parabola-pocket.localdomain> References: <20180301090021.GA22117@parabola-pocket.localdomain> Message-ID: <20180316084847.GA12472@parabola-pocket.localdomain> Ping. OK to commit? On Thu, Mar 01, 2018 at 10:00:21AM +0100, Andreas Grapentin wrote: > > Hi, > > Thanks for the feedback :) > I have attached an updated patch. > > -A > --- src/chroot-tools/librechroot | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot index 27e17bd..dec14bc 100755 --- a/src/chroot-tools/librechroot +++ b/src/chroot-tools/librechroot @@ -69,17 +69,22 @@ hack_arch_nspawn_flags() { CARCH="$(uname -m)" fi - if [[ "$CARCH" == armv7h ]] && ! setarch armv7l /bin/true 2>/dev/null; then - # We're running an ARM chroot on a non-ARM processor + local setarch interpreter + case $CARCH in + armv7h) setarch=armv7l; interpreter=/usr/bin/qemu-arm-static ;; + *) setarch=$CARCH; interpreter=/usr/bin/qemu-$CARCH-static ;; + esac + if ! setarch $setarch /bin/true 2>/dev/null; then + # We're running a cross-arch chroot # Make sure that qemu-static is set up with binfmt_misc if [[ -z $(grep -l -xF \ - -e 'interpreter /usr/bin/qemu-arm-static' \ + -e "interpreter $interpreter" \ -r -- /proc/sys/fs/binfmt_misc 2>/dev/null \ | xargs -r grep -xF 'enabled') ]] then - error 'Cannot cross-compile for ARM on x86' - plain 'This requires a binfmt_misc entry for qemu-arm-static.' + error 'Cannot cross-compile for %s on %s' "$CARCH" "$(uname -m)" + plain 'This requires a binfmt_misc entry for %s.' "$interpreter" prose 'Such a binfmt_misc entry is provided by the %s package. If you have it installed, but still see this message, you may need to restart %s.' \ @@ -88,13 +93,13 @@ hack_arch_nspawn_flags() { fi # Let qemu/binfmt_misc do its thing - arch_nspawn_flags+=(-f /usr/bin/qemu-arm-static -s) + arch_nspawn_flags+=(-f $interpreter -s) # The -any packages are built separately for ARM from # x86, so if we use the same CacheDir as the x86 host, # then there will be PGP errors. - mkdir -p /var/cache/pacman/pkg-arm - arch_nspawn_flags+=(-c /var/cache/pacman/pkg-arm) + mkdir -p /var/cache/pacman/pkg-$CARCH + arch_nspawn_flags+=(-c /var/cache/pacman/pkg-$CARCH) fi } -- 2.16.2 > _______________________________________________ > 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 bill-auger at peers.community Fri Mar 16 11:47:09 2018 From: bill-auger at peers.community (bill-auger) Date: Fri, 16 Mar 2018 07:47:09 -0400 Subject: [Dev] [RFC] Deprecation of webkitgtk2 In-Reply-To: <3b6076a8-5349-aaf8-7c66-11d0205cae8d@hyperbola.info> References: <784bf28d-6d23-7ada-c783-9610165a4d7b@hyperbola.info> <3b6076a8-5349-aaf8-7c66-11d0205cae8d@hyperbola.info> Message-ID: maybe webkit2gtk and webkitgtk2 are the same software with different names - that would not be uncommon for AUR packages but what makes you say it is deprecated? "deprecated" is not the same thing as "arch stopped packaging it" - i would not use the word deprecated unless the upstream developers say so - even then, it may still be worth keeping - it sounds like probably not in this case though the question a distro should ask in such cases is "does this program offer any unique and important functionality to the distro that would be missing if it were removed?" - like a web browser - no distro needs 10 web browsers but they should all probably have at least one - in the case of file sync, there are surely several alternatives (unison and rsync for examples); so parabola users would not be missing the "file sync" ability - i dont know what the other program does but i suspect it would not meet the "important" criteria - maybe send mail to the [assist] list asking anyone to speak up if they want to save those packages -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From freemor at freemor.ca Fri Mar 16 13:05:54 2018 From: freemor at freemor.ca (Freemor) Date: Fri, 16 Mar 2018 10:05:54 -0300 Subject: [Dev] [RFC] Deprecation of webkitgtk2 In-Reply-To: References: <784bf28d-6d23-7ada-c783-9610165a4d7b@hyperbola.info> <3b6076a8-5349-aaf8-7c66-11d0205cae8d@hyperbola.info> Message-ID: <20180316130554.GD3364@freemor.ca> On Fri, Mar 16, 2018 at 07:47:09AM -0400, bill-auger wrote: > maybe webkit2gtk and webkitgtk2 are the same software with different > names - that would not be uncommon for AUR packages > > but what makes you say it is deprecated? "deprecated" is not the same > thing as "arch stopped packaging it" - i would not use the word > deprecated unless the upstream developers say so - even then, it may > still be worth keeping - it sounds like probably not in this case though > > the question a distro should ask in such cases is "does this program > offer any unique and important functionality to the distro that would be > missing if it were removed?" - like a web browser - no distro needs 10 > web browsers but they should all probably have at least one - in the > case of file sync, there are surely several alternatives (unison and > rsync for examples); so parabola users would not be missing the "file > sync" ability - i dont know what the other program does but i suspect it > would not meet the "important" criteria - maybe send mail to the > [assist] list asking anyone to speak up if they want to save those packages > > > They are the same but different. If I understand correctly and some duckduckgo-ing seem to support my understanding webkitgtk2 is a older unsupported version of webkit, where as webkit2gtk is the current supported branch of the code. I can't remember the reason for the version split but do recall that the old version has several severe vulnerabilities in it that will not be patched. I had to change my browser choices for a while to move off on the old unpatched webkit until some projects switched over. Given the confusing nature of the naming and the vulnerabilities it may be an idea to ditch the older ones. There is some good discussion of it here: https://www.linuxquestions.org/questions/slackware-14/what-is-the-difference-between-webkitgtk-and-webkitgtk2-and-can-they-co-exist-please-4175589659/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From aurelien at hackers.camp Sun Mar 18 07:16:46 2018 From: aurelien at hackers.camp (aurelien at hackers.camp) Date: Sun, 18 Mar 2018 08:16:46 +0100 Subject: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules In-Reply-To: <5617a6bc-facf-e2d5-5d88-6eccd65ca2f2@peers.community> (bill-auger@peers.community's message of "Thu, 15 Mar 2018 11:26:24 -0400") References: <8268276.Okeu99Xnlx@iserlohn-fortress.net> <20180315063154.GA22593@parabola-pocket.localdomain> <1b103d58-af46-0c99-e7a2-3d7f00f5c006@peers.community> <20180315131822.GA25221@parabola-pocket.localdomain> <5617a6bc-facf-e2d5-5d88-6eccd65ca2f2@peers.community> Message-ID: <87o9jl97kx.fsf@hackers.camp> bill-auger writes: > i guess we all can make mistakes :-) -- Aur?lien DESBRI?RES GNU Hacker From nobody at parabola.nu Sun Mar 18 11:59:48 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 18 Mar 2018 11:59:48 -0000 Subject: [Dev] Orphan Kernels package [linux-libre-xtreme] marked out-of-date Message-ID: <20180318115948.1020.42893@proton.parabola.nu> alexdowson at mailbox.org wants to notify you that the following packages may be out-of-date: The user provided the following additional text: Needs updating to 4.15 for latest Meltdown/Spectre patches. Given the severity of Meltdown/Spectre and the fact that this kernel has a focus on security I'd really like to see this bumped to 4.15. https://kernelnewbies.org/Linux_4.15 (doesn't display anything with librejs enabled). From kevin at kphoenix.us Sun Mar 18 23:56:29 2018 From: kevin at kphoenix.us (Kevin Phoenix) Date: Sun, 18 Mar 2018 19:56:29 -0400 Subject: [Dev] qutebrowser update patch Message-ID: <1521417389.10776.6.camel@kphoenix.us> Hello all, I've noticed the qutebrowser package I've been enjoying recently has become orphaned. I've attached a patch upgrading the PKGBUILD to the latest upstream release which I would appreciate being reviewed for feedback and applied. Thanks, Kevin Phoenix -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-libre-qutebrowser-Update-to-1.2.1.patch Type: text/x-patch Size: 1707 bytes Desc: not available URL: From nobody at parabola.nu Mon Mar 19 00:47:31 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 19 Mar 2018 00:47:31 -0000 Subject: [Dev] Orphan Libre package [clamav] marked out-of-date Message-ID: <20180319004731.1021.74391@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * clamav 0.99.3-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/clamav/ * clamav 0.99.3-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/clamav/ * clamav 0.99.3-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/clamav/ The user provided the following additional text: Current release is 0.99.4 From bill-auger at peers.community Mon Mar 19 04:34:36 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 19 Mar 2018 00:34:36 -0400 Subject: [Dev] qutebrowser update patch In-Reply-To: <1521417389.10776.6.camel@kphoenix.us> References: <1521417389.10776.6.camel@kphoenix.us> Message-ID: thanks i have upgraded the qutebrowser package to v1.2.1 just so you know, this was well beyond the typical effort required to get a package upgraded - you could have just waited or asked someone to prioritize it - it was only a matter of time before someone got to it - on the other hand, the patch was quite correct and is the entirety of the routine job of keeping packages up to date; so you might make a very fine parabola package monkey if you are so inclined -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From andreas at grapentin.org Tue Mar 20 20:51:49 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Tue, 20 Mar 2018 21:51:49 +0100 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures Message-ID: <20180320205149.GA19939@parabola-pocket.localdomain> archlinux32 is building their own arch=(any) packages, which means they can't share the same cachedir as the x86_64 built -any packages. This patch adds a separate cachedir for each CARCH in librechroot, which should solve the signature issues we have seen in libremakepkg. -A --- src/chroot-tools/librechroot | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot index 8256d77..4360622 100755 --- a/src/chroot-tools/librechroot +++ b/src/chroot-tools/librechroot @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { # Let qemu/binfmt_misc do its thing arch_nspawn_flags+=(-f "$interpreter" -s) + fi - # The -any packages are built separately for ARM from - # x86, so if we use the same CacheDir as the x86 host, - # then there will be PGP errors. + if [[ $CARCH != $(uname -m) ]]; then + # The -any packages are built seperately for all arches, + # so if we use the same CacheDir as the host, then there + # will be PGP errors. mkdir -p "/var/cache/pacman/pkg-$CARCH" arch_nspawn_flags+=(-c "/var/cache/pacman/pkg-$CARCH") fi -- 2.16.2 -- ------------------------------------------------------------------------------ Andreas Grapentin, M.Sc. Research Assistant @ Hasso-Plattner-Institut Operating Systems and Middleware Group www.dcl.hpi.uni-potsdam.de Phone: +49 (0) 331 55 09-238 Fax: +49 (0) 331 55 09-229 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 lovell.joshyyy at gmail.com Tue Mar 20 21:26:58 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Tue, 20 Mar 2018 21:26:58 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180320205149.GA19939@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> Message-ID: <5AB17CA2.4090401@gmail.com> I say; there has been some decent work related to libretools recently... With gratitude, Josh On 20/03/18 20:51, Andreas Grapentin wrote: > > archlinux32 is building their own arch=(any) packages, which means they > can't share the same cachedir as the x86_64 built -any packages. This > patch adds a separate cachedir for each CARCH in librechroot, which > should solve the signature issues we have seen in libremakepkg. > > -A > > --- > src/chroot-tools/librechroot | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot > index 8256d77..4360622 100755 > --- a/src/chroot-tools/librechroot > +++ b/src/chroot-tools/librechroot > @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { > > # Let qemu/binfmt_misc do its thing > arch_nspawn_flags+=(-f "$interpreter" -s) > + fi > > - # The -any packages are built separately for ARM from > - # x86, so if we use the same CacheDir as the x86 host, > - # then there will be PGP errors. > + if [[ $CARCH != $(uname -m) ]]; then > + # The -any packages are built seperately for all arches, > + # so if we use the same CacheDir as the host, then there > + # will be PGP errors. > mkdir -p "/var/cache/pacman/pkg-$CARCH" > arch_nspawn_flags+=(-c "/var/cache/pacman/pkg-$CARCH") > fi > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From lukeshu at lukeshu.com Wed Mar 21 01:16:52 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 20 Mar 2018 21:16:52 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180320205149.GA19939@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> Message-ID: <87r2oew7ln.wl-lukeshu@lukeshu.com> On Tue, 20 Mar 2018 16:51:49 -0400, Andreas Grapentin wrote: > archlinux32 is building their own arch=(any) packages, which means they > can't share the same cachedir as the x86_64 built -any packages. This > patch adds a separate cachedir for each CARCH in librechroot, which > should solve the signature issues we have seen in libremakepkg. But we don't import arch=(any) packages from archlinux32 anymore, do we? Actually, I don't think we import arch=(any) packages from ALARM anymore either. Does that mean we can get rid of this hack? CC'ing isacdaavid because he's more knowledgeable about db-import-pkg than I am. > > -A > > --- It's not a big deal, but please put signatures & meta-commentary below the "---". The stuff above "---" should be the desired commit message. > src/chroot-tools/librechroot | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot > index 8256d77..4360622 100755 > --- a/src/chroot-tools/librechroot > +++ b/src/chroot-tools/librechroot > @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { > > # Let qemu/binfmt_misc do its thing > arch_nspawn_flags+=(-f "$interpreter" -s) > + fi > > - # The -any packages are built separately for ARM from > - # x86, so if we use the same CacheDir as the x86 host, > - # then there will be PGP errors. > + if [[ $CARCH != $(uname -m) ]]; then > + # The -any packages are built seperately for all arches, > + # so if we use the same CacheDir as the host, then there > + # will be PGP errors. > mkdir -p "/var/cache/pacman/pkg-$CARCH" > arch_nspawn_flags+=(-c "/var/cache/pacman/pkg-$CARCH") > fi > -- > 2.16.2 If I'm mistaken, and we do import arch=(any) packages from archlinux32, then this LGTM. -- Happy hacking, ~ Luke Shumaker From isacdaavid at isacdaavid.info Wed Mar 21 06:58:28 2018 From: isacdaavid at isacdaavid.info (Isaac David) Date: Wed, 21 Mar 2018 00:58:28 -0600 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87r2oew7ln.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> Message-ID: <1521615508.3211.0@plebeian.isacdaavid.info> Luke Shumaker wrote: > On Tue, 20 Mar 2018 16:51:49 -0400, > Andreas Grapentin wrote: >> archlinux32 is building their own arch=(any) packages, which means >> they >> can't share the same cachedir as the x86_64 built -any packages. >> This >> patch adds a separate cachedir for each CARCH in librechroot, which >> should solve the signature issues we have seen in libremakepkg. > > But we don't import arch=(any) packages from archlinux32 anymore, do > we? > > Actually, I don't think we import arch=(any) packages from ALARM > anymore either. right, unless it's an original package. more precisely, Arch's arch=(any) packages may override existing ALARM or Arch32 pkgnames -- they are given priority and all architectures are meant to use archlinux-keyring. i don't expect this scenario to surface often in practice, since both ALARM and Arch32 follow Arch, not the other way around. on the other hand, ALARM and Arch32's arch=(any) packages aren't allowed to override Arch's arch=(any) stuff, nor each other's. this is the relevant code: https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n124 https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n304 -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From andreas at grapentin.org Wed Mar 21 07:56:19 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Wed, 21 Mar 2018 08:56:19 +0100 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <1521615508.3211.0@plebeian.isacdaavid.info> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> Message-ID: <20180321075619.GA22549@parabola-pocket.localdomain> On Wed, Mar 21, 2018 at 12:58:28AM -0600, Isaac David wrote: > more precisely, Arch's arch=(any) packages may override > existing ALARM or Arch32 pkgnames -- they are given priority > and all architectures are meant to use archlinux-keyring. > i don't expect this scenario to surface often in practice, > since both ALARM and Arch32 follow Arch, not the other way > around. > > on the other hand, ALARM and Arch32's arch=(any) packages aren't > allowed to override Arch's arch=(any) stuff, nor each other's. > > this is the relevant code: > > https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n124 > https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n304 Isn't this asking for trouble when arch32 or alarm make significant changes to an -any package, required for it to function correctly on the respective platforms? This might never happen though, so it's probably okay, but one of these days we should probably check for this, to be safe :) -A -- ------------------------------------------------------------------------------ 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 bill-auger at peers.community Wed Mar 21 17:27:01 2018 From: bill-auger at peers.community (bill-auger) Date: Wed, 21 Mar 2018 13:27:01 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <1521615508.3211.0@plebeian.isacdaavid.info> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> Message-ID: <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> i dont doubt that is correct information but that policy sounds backward - the very idea of an "over-ride" is that special things are able to specialize over the generalities of more general things when necessary - not merely *allowed* to be special in cases where nothing else actively casts it into conformity it is like *allowing* OOP subclasses to specialize only if the superclass is abstract (and so they must specialize) - but if ever at some later time the superclass is made concrete, then forcefully reducing all dogs, cats, and mice into nothing more than generic "animals", stripping them of their peculiar characters sorry kitty, you will never "meow" again! - per orders from the big guy upstairs - you will henceforth be known as 'Mammal[42]' sry i had to mention that - it just stokes my philosophical fur the wrong way - id be interested to hear why anyone though this was a reasonable policy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From lovell.joshyyy at gmail.com Wed Mar 21 19:00:36 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 19:00:36 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180320205149.GA19939@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> Message-ID: <5AB2ABD4.6050600@gmail.com> In regards to the patch ... 1) Why is this: > if [[ $CARCH != $(uname -m) ]]; then 2) Any better than this: > if ! setarch $setarch /bin/true 2>/dev/null; then The first doesn't change the cachedir if the host architecture is the same as the build architecture. The second is a bit complicated, but as I gather, sets the architecture and runs /bin/true. If /bin/true returns false (something to do with setting the architecture fails), then the code is run. I may have got this wrong, but frankly I would be surprised if this works as it should and I like surprises. For the first, bare in mind there is a possibility that you would want to cross-compile to the same architecture for some reason (e.g. reproducible builds). For the second, I guess you want to know if you are compiling in a chroot or not, which makes sense, but I'm not 100% convinced that code works correctly just from reading. In regards to the responses on the mailing list regarding mixing packages/overrides etc. I'm not sure how they correspond to the code in the patch. For the first, packages will not be mixed if the CARCH is different from the host. For the second, packages will not be mixed if a chroot exists (that is ... if the code works as it is presumably intended ... something I am not entirely convinced on at the moment, but soon may be). Josh From lukeshu at lukeshu.com Wed Mar 21 21:14:41 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 17:14:41 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2ABD4.6050600@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <5AB2ABD4.6050600@gmail.com> Message-ID: <87k1u5w2pq.wl-lukeshu@lukeshu.com> To address the big picture: A better subject line might have been "librechroot: don't share the package cache directory between architectures". I think both you and I agree that this patch correctly achieves that objective. The discussion so far has been about whether that *objective* is correct, or if different architectures should share a package cache. ---- To address the details: First of all, the function being modified is hack_arch_nspawn_flags, the entire function is a hack, and none of it is particularly elegant. Just keep that in mind. On Wed, 21 Mar 2018 15:00:36 -0400, Josh Branning wrote: > > In regards to the patch ... (I'm going to re-order your paragraphs a bit, so I'm not jumping back and forth between the two cases in my replies.) > In regards to the responses on the mailing list regarding mixing > packages/overrides etc. I'm not sure how they correspond to the code > in the patch. This patch keeps package caches for different architectures separate; that discussion is about whether this is the right thing to do. > 1) Why is this: > > if [[ $CARCH != $(uname -m) ]]; then > > The first doesn't change the cachedir if the host architecture is the > same as the build architecture. > > For the first, bare in mind there is a possibility that you would want > to cross-compile to the same architecture for some reason > (e.g. reproducible builds). We (libretools) don't cross-compile the way some other projects cross-compile; we never use a cross-toolchain, we always use the target's native toolchain, and use user-mode processor emulation to make that possible. "Cross-compiling" to the host architecture isn't possible, because that would mean telling the kernel to use qemu to run native ELF files, which you can't do because qemu itself is a native ELF file, and it would get stuck in a loop. > For the first, packages will not be mixed if the CARCH > is different from the host. Right, that's why it's what was used; that's what this patch is accomplishing. > 2) Any better than this: > > if ! setarch $setarch /bin/true 2>/dev/null; then > > The second is a bit complicated, but as I gather, sets the > architecture and runs /bin/true. If /bin/true returns false (something > to do with setting the architecture fails), then the code is run. I > may have got this wrong, but frankly I would be surprised if this > works as it should and I like surprises. > > For the second, I guess you want to know if you are compiling in a > chroot or not, which makes sense, but I'm not 100% convinced that code > works correctly just from reading. This will always be compiling in a chroot (this is code in libreCHROOT, after all). That isn't the question. The question is "is the architecture of the chroot one that the host kernel can run natively, or one that requires an interpreter?" `setarch $target` will fail if the kernel can't run $target binaries natively. > For the second, packages will not be mixed > if a chroot exists (that is ... if the code works as it is presumably > intended ... something I am not entirely convinced on at the moment, > but soon may be). Not quite, see above. The reality is: For the second, packages will not be mixed if we need an interpreter to run target binaries. That seems a little silly--the interpreter has nothing to do with the package cache. It's a hack--right now, for Parabola's supported architectures (x86_64, i686, and armv7l), that means it splits the caches between x86 and ARM, which was the correct thing when I first wrote the code. Andreas is saying that since the archlinux/archlinux32 split, it is no longer correct to lump the package caches for i686 and x86_64 together. I disagree, and am saying that since migrating to db-import-pkg, it is no longer necessary to keep any of the package caches separate. -- Happy hacking, ~ Luke Shumaker Pardon any typos, I'm still getting used to my new Model 01 keyboard. From lukeshu at lukeshu.com Wed Mar 21 21:17:58 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 17:17:58 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180321075619.GA22549@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <20180321075619.GA22549@parabola-pocket.localdomain> Message-ID: <87in9pw2k9.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 03:56:19 -0400, Andreas Grapentin wrote: > On Wed, Mar 21, 2018 at 12:58:28AM -0600, Isaac David wrote: > > more precisely, Arch's arch=(any) packages may override > > existing ALARM or Arch32 pkgnames -- they are given priority > > and all architectures are meant to use archlinux-keyring. > > i don't expect this scenario to surface often in practice, > > since both ALARM and Arch32 follow Arch, not the other way > > around. > > > > on the other hand, ALARM and Arch32's arch=(any) packages aren't > > allowed to override Arch's arch=(any) stuff, nor each other's. > > > > this is the relevant code: > > > > https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n124 > > https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n304 > > Isn't this asking for trouble when arch32 or alarm make significant > changes to an -any package, required for it to function correctly on the > respective platforms? If significant changes are needed to make it function on a different architecture, then it shouldn't be an arch=(any) package. > This might never happen though, so it's probably okay, but one of these > days we should probably check for this, to be safe :) -- Happy hacking, Luke Shumaker From lukeshu at lukeshu.com Wed Mar 21 21:24:07 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 17:24:07 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <1521615508.3211.0@plebeian.isacdaavid.info> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> Message-ID: <87h8p9w2a0.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 02:58:28 -0400, Isaac David wrote: > > Luke Shumaker wrote: > > On Tue, 20 Mar 2018 16:51:49 -0400, > > Andreas Grapentin wrote: > >> archlinux32 is building their own arch=(any) packages, which means > >> they > >> can't share the same cachedir as the x86_64 built -any > >> packages. This > >> patch adds a separate cachedir for each CARCH in librechroot, which > >> should solve the signature issues we have seen in libremakepkg. > > > > But we don't import arch=(any) packages from archlinux32 anymore, do > > we? > > > > Actually, I don't think we import arch=(any) packages from ALARM > > anymore either. > > right, unless it's an original package. > > more precisely, Arch's arch=(any) packages may override > existing ALARM or Arch32 pkgnames -- they are given priority > and all architectures are meant to use archlinux-keyring. > i don't expect this scenario to surface often in practice, > since both ALARM and Arch32 follow Arch, not the other way > around. > > on the other hand, ALARM and Arch32's arch=(any) packages aren't > allowed to override Arch's arch=(any) stuff, nor each other's. Two questions: 1. If there's an arch=(any) package that exists in ALARM and in archlinux32, but not in archlinux, do we import it? (Do any such packages exist?) 2. If yes, which one wins? i686 or ARM? Thanks. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 21 21:35:52 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 17:35:52 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> Message-ID: <87fu4tw1qf.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 13:27:01 -0400, bill-auger wrote: > > i dont doubt that is correct information but that policy sounds backward > - the very idea of an "over-ride" is that special things are able to > specialize over the generalities of more general things when necessary - > not merely *allowed* to be special in cases where nothing else actively > casts it into conformity > > it is like *allowing* OOP subclasses to specialize only if the > superclass is abstract (and so they must specialize) - but if ever at > some later time the superclass is made concrete, then forcefully > reducing all dogs, cats, and mice into nothing more than generic > "animals", stripping them of their peculiar characters > > sorry kitty, you will never "meow" again! - per orders from the big guy > upstairs - you will henceforth be known as 'Mammal[42]' > > sry i had to mention that - it just stokes my philosophical fur the > wrong way - id be interested to hear why anyone though this was a > reasonable policy ALARM and archlinux32 shouldn't be modifying arch=(any) packages, just rebuilding them (because they rebuild *everything*, instead of importing pre-built packages from Arch like we do). The reason this matters is because makepkg doesn't do reproducible builds (yet), and so package signatures don't match, even if no changes were made. -- Happy hacking, ~ Luke Shumaker From lovell.joshyyy at gmail.com Wed Mar 21 21:36:52 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 21:36:52 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87k1u5w2pq.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <5AB2ABD4.6050600@gmail.com> <87k1u5w2pq.wl-lukeshu@lukeshu.com> Message-ID: <5AB2D074.8080507@gmail.com> On 21/03/18 21:14, Luke Shumaker wrote: > To address the big picture: A better subject line might have been > "librechroot: don't share the package cache directory between > architectures". I think both you and I agree that this patch > correctly achieves that objective. The discussion so far has been > about whether that *objective* is correct, or if different > architectures should share a package cache. > > ---- > > To address the details: > > First of all, the function being modified is hack_arch_nspawn_flags, > the entire function is a hack, and none of it is particularly elegant. > Just keep that in mind. > > On Wed, 21 Mar 2018 15:00:36 -0400, > Josh Branning wrote: >> >> In regards to the patch ... > > (I'm going to re-order your paragraphs a bit, so I'm not jumping back > and forth between the two cases in my replies.) > >> In regards to the responses on the mailing list regarding mixing >> packages/overrides etc. I'm not sure how they correspond to the code >> in the patch. > > This patch keeps package caches for different architectures separate; > that discussion is about whether this is the right thing to do. The current state (without the patch) is to keep package caches separate when using librechroot. The patch makes it so they are not separate when the host is the same as the build. > >> 1) Why is this: >>> if [[ $CARCH != $(uname -m) ]]; then >> >> The first doesn't change the cachedir if the host architecture is the >> same as the build architecture. >> >> For the first, bare in mind there is a possibility that you would want >> to cross-compile to the same architecture for some reason >> (e.g. reproducible builds). > > We (libretools) don't cross-compile the way some other projects > cross-compile; we never use a cross-toolchain, we always use the > target's native toolchain, and use user-mode processor emulation to > make that possible. "Cross-compiling" to the host architecture isn't > possible, because that would mean telling the kernel to use qemu to > run native ELF files, which you can't do because qemu itself is a > native ELF file, and it would get stuck in a loop. Yes, I shouldn't have said cross-compile, rather I should have said "compile in a chroot". Even so, there is a possibility that you would want to compile the same architecture in a chroot with qemu, for instance, because of reproducible builds. > >> For the first, packages will not be mixed if the CARCH >> is different from the host. > > Right, that's why it's what was used; that's what this patch is > accomplishing. But they will be mixed when CARCH is the same as the host. > >> 2) Any better than this: >>> if ! setarch $setarch /bin/true 2>/dev/null; then >> >> The second is a bit complicated, but as I gather, sets the >> architecture and runs /bin/true. If /bin/true returns false (something >> to do with setting the architecture fails), then the code is run. I >> may have got this wrong, but frankly I would be surprised if this >> works as it should and I like surprises. >> >> For the second, I guess you want to know if you are compiling in a >> chroot or not, which makes sense, but I'm not 100% convinced that code >> works correctly just from reading. > > This will always be compiling in a chroot (this is code in > libreCHROOT, after all). That isn't the question. The question is > "is the architecture of the chroot one that the host kernel can run > natively, or one that requires an interpreter?" `setarch $target` > will fail if the kernel can't run $target binaries natively. > That is not what the code does in it's present state. Try the following in a terminal: if ! setarch i686 /bin/true; then echo "do the business"; fi (change i686 to your architecture, or the architecture of the chroot) May I further suggest you remove the exclamation mark from that line. >> For the second, packages will not be mixed >> if a chroot exists (that is ... if the code works as it is presumably >> intended ... something I am not entirely convinced on at the moment, >> but soon may be). > > Not quite, see above. The reality is: > > For the second, packages will not be mixed if we need an > interpreter to run target binaries. That seems a little silly--the > interpreter has nothing to do with the package cache. It's a > hack--right now, for Parabola's supported architectures (x86_64, i686, > and armv7l), that means it splits the caches between x86 and ARM, > which was the correct thing when I first wrote the code. I tend to agree this is perhaps the correct thing to do, but the code accomplish that in it's present state. > > Andreas is saying that since the archlinux/archlinux32 split, it is no > longer correct to lump the package caches for i686 and x86_64 > together. I disagree, and am saying that since migrating to > db-import-pkg, it is no longer necessary to keep any of the package > caches separate. I don't know what you'd be gaining by not keeping them separate. From lovell.joshyyy at gmail.com Wed Mar 21 21:40:34 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 21:40:34 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2D074.8080507@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <5AB2ABD4.6050600@gmail.com> <87k1u5w2pq.wl-lukeshu@lukeshu.com> <5AB2D074.8080507@gmail.com> Message-ID: <5AB2D152.4050304@gmail.com> > I tend to agree this is perhaps the correct thing to do, but the code > accomplish that in it's present state. *doesn't accomplish. From lovell.joshyyy at gmail.com Wed Mar 21 22:18:07 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 22:18:07 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87fu4tw1qf.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> Message-ID: <5AB2DA1F.8000102@gmail.com> Ignore the last two emails. Code seems to work as expected. I see you are purposefully testing for a negative and not that the line is wrong. if setarch $setarch /bin/false 2>/dev/null; then Would have been more readable instead of a double negative; bit confusing. Still, I think there is no loss and only gains to having separate dirs for packages as with the present code. Josh From lovell.joshyyy at gmail.com Wed Mar 21 22:27:06 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 22:27:06 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2DA1F.8000102@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> <5AB2DA1F.8000102@gmail.com> Message-ID: <5AB2DC3A.1000706@gmail.com> Last email ... probably good to change line 77 to if [[ $CARCH != $(uname -m) ]]; then As suggested, does pretty much the same job, but helps readability. Also doesn't depend on the chroot having /bin/true or /bin/false. I'll be quiet now. Josh From lukeshu at lukeshu.com Wed Mar 21 22:53:23 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 18:53:23 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2D074.8080507@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <5AB2ABD4.6050600@gmail.com> <87k1u5w2pq.wl-lukeshu@lukeshu.com> <5AB2D074.8080507@gmail.com> Message-ID: <87d0zxvy58.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 17:36:52 -0400, Josh Branning wrote: > The current state (without the patch) is to keep package caches > separate when using librechroot. No, the current state (without the patch) is for librechroot to keep the package caches separate if building ARM-on-x86 or x86-on-ARM, but to share them if building x86-on-x86 or ARM-on-ARM. > The patch makes it so they are not separate when the host is the same > as the build. It does that with or without the patch, that behavior isn't being changed. Of Parabola's supported architectures, i686-on-x86_64 is the only case that this patch changes. > >> For the first, bare in mind there is a possibility that you would want > >> to cross-compile to the same architecture for some reason > >> (e.g. reproducible builds). > > > > We (libretools) don't cross-compile the way some other projects > > cross-compile; ... > > Yes, I shouldn't have said cross-compile, rather I should have said > "compile in a chroot". Even so, there is a possibility that you would > want to compile the same architecture in a chroot with qemu, for > instance, because of reproducible builds. librechroot/libremakepkg always build in a chroot. db-update on the server rejects packages that aren't built in a chroot. We _always_ build in a chroot. Even when building for the host architecture. (In fact, it's relatively recent that libremakepkg--which has always built packages in a chroot--gained the ability to compile packages for architectures other than the host architecture.) > >> For the first, packages will not be mixed if the CARCH > >> is different from the host. > > > > Right, that's why it's what was used; that's what this patch is > > accomplishing. > > But they will be mixed when CARCH is the same as the host. Right. The goal of the patch is to split the cache between architectures. An x86_64 host and all x86_64 chroots can share the same cache with eachother, but not with armv7h chroots or i686 chroots. > >> 2) Any better than this: > >>> if ! setarch $setarch /bin/true 2>/dev/null; then > >> > >> For the second, I guess you want to know if you are compiling in a > >> chroot or not, which makes sense, but I'm not 100% convinced that code > >> works correctly just from reading. > > > > This will always be compiling in a chroot (this is code in > > libreCHROOT, after all). That isn't the question. The question is > > "is the architecture of the chroot one that the host kernel can run > > natively, or one that requires an interpreter?" `setarch $target` > > will fail if the kernel can't run $target binaries natively. > > That is not what the code does in it's present state. Yes it is. > Try the following in a terminal: > > if ! setarch i686 /bin/true; then echo "do the business"; fi > > (change i686 to your architecture, or the architecture of the chroot) In this example, `echo "do the business"` is the code that only needs to run if we will be using an interpreter. My x86_64 kernel can run x86_64 and i686 binaries without an interpreter, so that snippet keeps quiet when I type "x86_64" or "i686". But it does need an interpreter to run armv7l binaries, so it prints the message when I type "armv7l". > May I further suggest you remove the exclamation mark from that line. No, because that would be wrong. > > For the second, packages will not be mixed if we need an > > interpreter to run target binaries. That seems a little silly--the > > interpreter has nothing to do with the package cache. It's a > > hack--right now, for Parabola's supported architectures (x86_64, i686, > > and armv7l), that means it splits the caches between x86 and ARM, > > which was the correct thing when I first wrote the code. > > I tend to agree this is perhaps the correct thing to do, but the code > accomplish that in it's present state. Yes, it does. > > Andreas is saying that since the archlinux/archlinux32 split, it is no > > longer correct to lump the package caches for i686 and x86_64 > > together. I disagree, and am saying that since migrating to > > db-import-pkg, it is no longer necessary to keep any of the package > > caches separate. > > I don't know what you'd be gaining by not keeping them separate. Disk space, download time; you know, the reasons you use a cache at all. The reason to keep them separate is that the way db-import-alarm-pkg used to work meant that sharing a cache between architectures would result in package signature errors for arch=(any) packages. It was a hack to work around something that db-import-alarm-pkg did wrong. Now that we have a correct unified db-import-pkg, I no longer think that we should have the package cache hack at all. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 21 22:58:40 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 18:58:40 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180320205149.GA19939@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> Message-ID: <87bmfhvxwf.wl-lukeshu@lukeshu.com> On Tue, 20 Mar 2018 16:51:49 -0400, Andreas Grapentin wrote: > archlinux32 is building their own arch=(any) packages, which means they > can't share the same cachedir as the x86_64 built -any packages. This > patch adds a separate cachedir for each CARCH in librechroot, which > should solve the signature issues we have seen in libremakepkg. > > -A > > --- > src/chroot-tools/librechroot | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot > index 8256d77..4360622 100755 > --- a/src/chroot-tools/librechroot > +++ b/src/chroot-tools/librechroot > @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { > > # Let qemu/binfmt_misc do its thing > arch_nspawn_flags+=(-f "$interpreter" -s) > + fi > > - # The -any packages are built separately for ARM from > - # x86, so if we use the same CacheDir as the x86 host, > - # then there will be PGP errors. > + if [[ $CARCH != $(uname -m) ]]; then On ARM, $CARCH is "armv7h", but $(uname -m) is "armv7l", which means that it would needlessly create a separate cache when building natively on ARM. It should use $setarch instead of $CARCH. > + # The -any packages are built seperately for all arches, > + # so if we use the same CacheDir as the host, then there > + # will be PGP errors. > mkdir -p "/var/cache/pacman/pkg-$CARCH" > arch_nspawn_flags+=(-c "/var/cache/pacman/pkg-$CARCH") > fi > -- > 2.16.2 -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 21 23:04:58 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 19:04:58 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2DA1F.8000102@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> <5AB2DA1F.8000102@gmail.com> Message-ID: <87a7v1vxlx.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 18:18:07 -0400, Josh Branning wrote: > Ignore the last two emails. > > Code seems to work as expected. > > I see you are purposefully testing for a negative and not that the > line is wrong. > > if setarch $setarch /bin/false 2>/dev/null; then > > Would have been more readable instead of a double negative; bit confusing. That would never trigger, there is no way that exits with 0. If setarch fails, it exits with 1. If setarch succeeds, then it runs /bin/false, which exits with 1. No matter what, it exits with 1. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 21 23:09:21 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 21 Mar 2018 19:09:21 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2DC3A.1000706@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> <5AB2DA1F.8000102@gmail.com> <5AB2DC3A.1000706@gmail.com> Message-ID: <878talvxem.wl-lukeshu@lukeshu.com> On Wed, 21 Mar 2018 18:27:06 -0400, Josh Branning wrote: > > Last email ... > > probably good to change line 77 to > > if [[ $CARCH != $(uname -m) ]]; then > > As suggested, does pretty much the same job, but helps > readability. No, because the interpreter code needs to not fire when using an i686 chroot on an x86_64 host. That change would break that. > Also doesn't depend on the chroot having /bin/true or > /bin/false. That isn't the chroot's /bin/true, that's /bin/true on the host. From lovell.joshyyy at gmail.com Wed Mar 21 23:45:48 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 21 Mar 2018 23:45:48 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87a7v1vxlx.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> <5AB2DA1F.8000102@gmail.com> <87a7v1vxlx.wl-lukeshu@lukeshu.com> Message-ID: <5AB2EEAC.7090300@gmail.com> On 21/03/18 23:04, Luke Shumaker wrote: > On Wed, 21 Mar 2018 18:18:07 -0400, > Josh Branning wrote: >> Ignore the last two emails. >> >> Code seems to work as expected. >> >> I see you are purposefully testing for a negative and not that the >> line is wrong. >> >> if setarch $setarch /bin/false 2>/dev/null; then >> >> Would have been more readable instead of a double negative; bit confusing. > > That would never trigger, there is no way that exits with 0. If > setarch fails, it exits with 1. If setarch succeeds, then it runs > /bin/false, which exits with 1. No matter what, it exits with 1. > You are correct. From what you have said about the alternatives (uname, /bin/false), the present code seems to do the job better already. Though I am not certain about mashing all the package cache into one directory. You said the packages, when built for the same architecture, are already built in a chroot. Reproducible packages might require a very similar environment, so it would be beneficial to use qemu and librechroot for these too (not just a vanilla chroot on the same architecture). It also makes the process standardized, as no matter if you are compiling on the same or a different architecture, you could use librechroot and qemu and expect similar, or the same, behavior when using the tools. Either way, the patch doesn't seem to address any of this at all in any meaningful sense. If one wanted to make a patch for this, I'd suggest they completely remove the conditional (but not the body) at line 77. As it is, you are not keen on that happening either way. I myself feel that where the arch=(any) packages are different, they are probably different for a reason and would suggest that the build architecture take priority; for they are most likely to have the best support for that architecture family. Josh From lovell.joshyyy at gmail.com Thu Mar 22 00:47:17 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Thu, 22 Mar 2018 00:47:17 +0000 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2EEAC.7090300@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <1770344b-6c4e-8109-17e0-ecd832a0dd3d@peers.community> <87fu4tw1qf.wl-lukeshu@lukeshu.com> <5AB2DA1F.8000102@gmail.com> <87a7v1vxlx.wl-lukeshu@lukeshu.com> <5AB2EEAC.7090300@gmail.com> Message-ID: <5AB2FD15.3000808@gmail.com> > I myself feel that where the arch=(any) packages are different, they are > probably different for a reason and would suggest that the build > architecture take priority; for they are most likely to have the best > support for that architecture family. I guess: 1) The tar.xz files have the architecture already in the name. 2) These files don't have to be downloaded or stored more than once. 3) Parabola devs choose which arch=(any) package makes it into parabola. The last point is important, devs can pick and choose which individual arch=(any) package comes from say, arch32 or archarm, or arch x86_64 or wherever. (Though one would obviously hope that arch=(any) packages run on all architectures). There is pretty much no need for any fixed rules about the upstream origin of the package either, and so no need for an overall conversation about which upstream source should be prioritized. Much better to assess arch=(any) packages on a case-by-case basis instead, and make sure by hand that there aren't conflict duplicates from different upstream providers. If a discussion has to be had about the upstream source for an individual package, then so be it. Therefore it probably makes sense to lump them all into a single package cache. And there is probably little point in having duplicate arch=(any) packages, mainly because: 1) You'd have to download lots more 2) You'd have to host more code 3) But finally and most importantly: The whole concept of the tag "arch=(any)" would become completely flawed Maybe some day someone will write some code to address this issue. Josh From isacdaavid at isacdaavid.info Thu Mar 22 17:56:17 2018 From: isacdaavid at isacdaavid.info (Isaac David) Date: Thu, 22 Mar 2018 11:56:17 -0600 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87h8p9w2a0.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87r2oew7ln.wl-lukeshu@lukeshu.com> <1521615508.3211.0@plebeian.isacdaavid.info> <87h8p9w2a0.wl-lukeshu@lukeshu.com> Message-ID: <1521741378.1634.0@plebeian.isacdaavid.info> Luke Shumaker wrote : > Two questions: > > 1. If there's an arch=(any) package that exists in ALARM and in > archlinux32, but not in archlinux, do we import it? yes, all else being equal (i.e. no blacklisting). > (Do any such packages exist?) idk. > 2. If yes, which one wins? i686 or ARM? the one to come first. all 4 keyrings are required by all 3 pacmans in any case. i don't know whether both could make it to our package cache under the adequate concurrency conditions. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From andreas.grapentin at hpi.uni-potsdam.de Wed Mar 21 19:08:51 2018 From: andreas.grapentin at hpi.uni-potsdam.de (Andreas Grapentin) Date: Wed, 21 Mar 2018 20:08:51 +0100 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <5AB2ABD4.6050600@gmail.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <5AB2ABD4.6050600@gmail.com> Message-ID: <20180321190851.GA31334@parabola-pocket.localdomain> On Wed, Mar 21, 2018 at 07:00:36PM +0000, Josh Branning wrote: > In regards to the patch ... > > 1) Why is this: > > if [[ $CARCH != $(uname -m) ]]; then > > 2) Any better than this: > > if ! setarch $setarch /bin/true 2>/dev/null; then Those two checks are for different things. The first one checks whether the target CARCH is different from the host arch, and the second one checks whether we need a binfmt interpreter to run binaries for that architecture. These checks differ notably for i686 on x86_64. The CARCHs differ, but the setarch check succeeds, so no cross-arch binfmt magic is needed. > > The first doesn't change the cachedir if the host architecture is the same > as the build architecture. > > The second is a bit complicated, but as I gather, sets the architecture and > runs /bin/true. If /bin/true returns false (something to do with setting the > architecture fails), then the code is run. I may have got this wrong, but > frankly I would be surprised if this works as it should and I like > surprises. > > > For the first, bare in mind there is a possibility that you would want to > cross-compile to the same architecture for some reason (e.g. reproducible > builds). > > For the second, I guess you want to know if you are compiling in a chroot or > not, which makes sense, but I'm not 100% convinced that code works correctly > just from reading. not quite following here, to be honest. > > In regards to the responses on the mailing list regarding mixing > packages/overrides etc. I'm not sure how they correspond to the code in the > patch. For the first, packages will not be mixed if the CARCH is different > from the host. For the second, packages will not be mixed if a chroot exists > (that is ... if the code works as it is presumably intended ... something I > am not entirely convinced on at the moment, but soon may be). again, different checks, at different places in the script, for different reasons. the first check is for avoiding mixing of -any packages of different CHOSTs, and the second one is to try and figure out whether we need a binfmt interpreter. Best, Andreas -- ------------------------------------------------------------------------------ Andreas Grapentin, M.Sc. Research Assistant @ Hasso-Plattner-Institut Operating Systems and Middleware Group www.dcl.hpi.uni-potsdam.de Phone: +49 (0) 331 55 09-238 Fax: +49 (0) 331 55 09-229 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 Sat Mar 24 23:08:17 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Sat, 24 Mar 2018 19:08:17 -0400 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <20180320205149.GA19939@parabola-pocket.localdomain> References: <20180320205149.GA19939@parabola-pocket.localdomain> Message-ID: <87in9lul5q.wl-lukeshu@lukeshu.com> On Tue, 20 Mar 2018 16:51:49 -0400, Andreas Grapentin wrote: > --- > src/chroot-tools/librechroot | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot > index 8256d77..4360622 100755 > --- a/src/chroot-tools/librechroot > +++ b/src/chroot-tools/librechroot > @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { > Oh! I almost forgot! Don't forget to add yourself to the copyright statement at the top of the file! -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Sun Mar 25 00:33:11 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 25 Mar 2018 00:33:11 -0000 Subject: [Dev] Orphan Libre package [gst-plugins-bad] marked out-of-date Message-ID: <20180325003311.1092.70712@proton.parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * gst-plugins-bad 1.12.4-3.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/gst-plugins-bad/ * gst-plugins-bad 1.12.4-3.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/gst-plugins-bad/ * gst-plugins-bad 1.12.4-3.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/gst-plugins-bad/ The user provided the following additional text: Current release is 1.14.0 From lovell.joshyyy at gmail.com Sun Mar 25 02:39:34 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Sun, 25 Mar 2018 03:39:34 +0100 Subject: [Dev] [PATCH] libretools: fix i686 gpg signature failures In-Reply-To: <87in9lul5q.wl-lukeshu@lukeshu.com> References: <20180320205149.GA19939@parabola-pocket.localdomain> <87in9lul5q.wl-lukeshu@lukeshu.com> Message-ID: <5AB70BE6.1020605@gmail.com> On 24/03/18 23:08, Luke Shumaker wrote: > On Tue, 20 Mar 2018 16:51:49 -0400, > Andreas Grapentin wrote: >> --- >> src/chroot-tools/librechroot | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/src/chroot-tools/librechroot b/src/chroot-tools/librechroot >> index 8256d77..4360622 100755 >> --- a/src/chroot-tools/librechroot >> +++ b/src/chroot-tools/librechroot >> @@ -94,10 +94,12 @@ hack_arch_nspawn_flags() { >> > > Oh! I almost forgot! Don't forget to add yourself to the copyright > statement at the top of the file! > Aye. Well deserved. And apologies to both of you if I seemed like I was pressing a bit too much the other day. As I stated in the first email, there has been some decent work on libretools recently and it is much appreciated. Josh From nobody at parabola.nu Sun Mar 25 07:30:49 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 25 Mar 2018 07:30:49 -0000 Subject: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date Message-ID: <20180325073049.1091.80577@proton.parabola.nu> eliotreyna at cock.email wants to notify you that the following packages may be out-of-date: * iceweasel-l10n-ach 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ach/ * iceweasel-l10n-af 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-af/ * iceweasel-l10n-an 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-an/ * iceweasel-l10n-ar 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ar/ * iceweasel-l10n-as 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-as/ * iceweasel-l10n-ast 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ast/ * iceweasel-l10n-az 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-az/ * iceweasel-l10n-be 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-be/ * iceweasel-l10n-bg 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bg/ * iceweasel-l10n-bn-bd 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-bd/ * iceweasel-l10n-bn-in 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-in/ * iceweasel-l10n-br 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-br/ * iceweasel-l10n-bs 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bs/ * iceweasel-l10n-ca 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ca/ * iceweasel-l10n-cak 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cak/ * iceweasel-l10n-cs 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cs/ * iceweasel-l10n-cy 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cy/ * iceweasel-l10n-da 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-da/ * iceweasel-l10n-de 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-de/ * iceweasel-l10n-dsb 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-dsb/ * iceweasel-l10n-el 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-el/ * iceweasel-l10n-en-gb 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-gb/ * iceweasel-l10n-en-us 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-us/ * iceweasel-l10n-en-za 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-za/ * iceweasel-l10n-eo 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eo/ * iceweasel-l10n-es-ar 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-ar/ * iceweasel-l10n-es-cl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-cl/ * iceweasel-l10n-es-es 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-es/ * iceweasel-l10n-es-mx 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-mx/ * iceweasel-l10n-et 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-et/ * iceweasel-l10n-eu 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eu/ * iceweasel-l10n-fa 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fa/ * iceweasel-l10n-ff 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ff/ * iceweasel-l10n-fi 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fi/ * iceweasel-l10n-fr 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fr/ * iceweasel-l10n-fy-nl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fy-nl/ * iceweasel-l10n-ga-ie 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ga-ie/ * iceweasel-l10n-gd 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gd/ * iceweasel-l10n-gl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gl/ * iceweasel-l10n-gn 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gn/ * iceweasel-l10n-gu-in 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gu-in/ * iceweasel-l10n-he 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-he/ * iceweasel-l10n-hi-in 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hi-in/ * iceweasel-l10n-hr 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hr/ * iceweasel-l10n-hsb 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hsb/ * iceweasel-l10n-hu 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hu/ * iceweasel-l10n-hy-am 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hy-am/ * iceweasel-l10n-id 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-id/ * iceweasel-l10n-is 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-is/ * iceweasel-l10n-it 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-it/ * iceweasel-l10n-ja 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ja/ * iceweasel-l10n-ka 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ka/ * iceweasel-l10n-kab 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kab/ * iceweasel-l10n-kk 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kk/ * iceweasel-l10n-km 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-km/ * iceweasel-l10n-kn 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kn/ * iceweasel-l10n-ko 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ko/ * iceweasel-l10n-lij 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lij/ * iceweasel-l10n-lt 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lt/ * iceweasel-l10n-lv 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lv/ * iceweasel-l10n-mai 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mai/ * iceweasel-l10n-mk 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mk/ * iceweasel-l10n-ml 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ml/ * iceweasel-l10n-mr 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mr/ * iceweasel-l10n-ms 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ms/ * iceweasel-l10n-my 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-my/ * iceweasel-l10n-nb-no 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nb-no/ * iceweasel-l10n-ne-np 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ne-np/ * iceweasel-l10n-nl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nl/ * iceweasel-l10n-nn-no 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nn-no/ * iceweasel-l10n-or 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-or/ * iceweasel-l10n-pa-in 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pa-in/ * iceweasel-l10n-pl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pl/ * iceweasel-l10n-pt-br 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-br/ * iceweasel-l10n-pt-pt 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-pt/ * iceweasel-l10n-rm 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-rm/ * iceweasel-l10n-ro 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ro/ * iceweasel-l10n-ru 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ru/ * iceweasel-l10n-si 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-si/ * iceweasel-l10n-sk 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sk/ * iceweasel-l10n-sl 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sl/ * iceweasel-l10n-son 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-son/ * iceweasel-l10n-sq 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sq/ * iceweasel-l10n-sr 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sr/ * iceweasel-l10n-sv-se 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sv-se/ * iceweasel-l10n-ta 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ta/ * iceweasel-l10n-te 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-te/ * iceweasel-l10n-th 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-th/ * iceweasel-l10n-tr 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-tr/ * iceweasel-l10n-uk 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uk/ * iceweasel-l10n-ur 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ur/ * iceweasel-l10n-uz 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uz/ * iceweasel-l10n-vi 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-vi/ * iceweasel-l10n-xh 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-xh/ * iceweasel-l10n-zh-cn 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-cn/ * iceweasel-l10n-zh-tw 1:58.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-tw/ The user provided the following additional text: Please update Iceweasel to th version 59 (including language packs). New in Firefox 59: 1.- Enhanced features (improvement in page load times and image rendering). 2.- Removal of path site information for prevent cross-site tracking. More information: https://www.mozilla.org/en-US/firefox/59.0/releasenotes/ Thanks. From jc_gargma at iserlohn-fortress.net Sun Mar 25 21:13:05 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Sun, 25 Mar 2018 14:13:05 -0700 Subject: [Dev] kipi-plugins update patch Message-ID: <2253579.MYKifvfjC0@iserlohn-fortress.net> I've attached a git-format patch to update kipi-plugins to 5.9.0 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-kipi-plugins-to-5.9.0.patch Type: text/x-patch Size: 1867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From kevin at kphoenix.us Mon Mar 26 21:26:55 2018 From: kevin at kphoenix.us (Kevin Phoenix) Date: Mon, 26 Mar 2018 17:26:55 -0400 Subject: [Dev] Update nonprism/evolution-data-server Message-ID: Attached is a patch to update nonprism/evolution-data-server to match the version in extra. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-nonprism-evolution-data-server.patch Type: text/x-patch Size: 1919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Mon Mar 26 21:51:47 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 26 Mar 2018 17:51:47 -0400 Subject: [Dev] Update nonprism/evolution-data-server In-Reply-To: References: Message-ID: <836243a3-882e-4622-fc05-623d6a9d1699@peers.community> why did you remove all of the maintainer names? why did you remove /$pkgname from the install dir? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From kevin at kphoenix.us Mon Mar 26 21:56:36 2018 From: kevin at kphoenix.us (Kevin Phoenix) Date: Mon, 26 Mar 2018 17:56:36 -0400 Subject: [Dev] Update nonprism/evolution-data-server In-Reply-To: <836243a3-882e-4622-fc05-623d6a9d1699@peers.community> References: <836243a3-882e-4622-fc05-623d6a9d1699@peers.community> Message-ID: I was following the patch in extra, which did the same. I figured it was best to keep the diff as small as possible from extra. On Mon, 2018-03-26 at 17:51 -0400, bill-auger wrote: > why did you remove all of the maintainer names? > > why did you remove /$pkgname from the install dir? > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From lukeshu at lukeshu.com Mon Mar 26 23:05:30 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Mon, 26 Mar 2018 19:05:30 -0400 Subject: [Dev] libretools 20180326 release announcement Message-ID: <87d0zq1lqd.wl-lukeshu@lukeshu.com> I just released libretools 20180326 to [libre] and pushed the source tarball to . This is a very minor release. Changes from 20180103 to 20180326: - libremakepkg: * Respect GNUPGHOME (from devtools) - librechroot: * Generalize ARM-on-x86 logic to work for any cross-architecture chroot. - xbs: * Update documentation to have correct config file paths - xbs-abs: * Fix up from being totally broken Special thanks to Andreas Grapentin ("oaken-source") for his work on generalizing librechroot---in the interest of a RISC-V port! XBS is primarily used within dbscripts (on the server side), fixing the abs plugin for it allows us to work with the dbscripts test suite. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Mon Mar 26 23:10:35 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Mon, 26 Mar 2018 19:10:35 -0400 Subject: [Dev] libretools 20180326 release announcement In-Reply-To: <87d0zq1lqd.wl-lukeshu@lukeshu.com> References: <87d0zq1lqd.wl-lukeshu@lukeshu.com> Message-ID: <87a7uu1lhw.wl-lukeshu@lukeshu.com> Somehow, localization is broken. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Tue Mar 27 03:04:47 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Mon, 26 Mar 2018 23:04:47 -0400 Subject: [Dev] release announcments for server stuff Message-ID: <874ll21ank.wl-lukeshu@lukeshu.com> Hi all, - I've pushed dbscripts 20180326 to winston. It should shut up the annoying (but harmless) errors. The test suite (`make -C test test`) passes. It's rather slow, but updating it to use BATS and getting it to pass provides a basis for finally cleaning dbscripts up a bit, and being confident in those changes. - Looking in to parabolaweb not getting package updates, I realized that because of the bash pipeline in parabolaweb-reporead-rsync, it was always exiting with 0, which is why monitoring didn't alert me to an error: the script was exiting successfully. I've pushed parabolaweb-utils 20180326.1 to proton to fix that, but there's still the actual problem that reporead is failing. IDK why yet. https://labs.parabola.nu/issues/1666 -- Happy hacking, ~ Luke Shumaker From uaqben at disroot.org Tue Mar 27 22:56:36 2018 From: uaqben at disroot.org (Ben) Date: Wed, 28 Mar 2018 00:56:36 +0200 Subject: [Dev] libretools 20180326 release announcement In-Reply-To: <87d0zq1lqd.wl-lukeshu@lukeshu.com> References: <87d0zq1lqd.wl-lukeshu@lukeshu.com> Message-ID: <2e988723-f9d1-8981-345f-4770509f5f1a@disroot.org> On 03/27/2018 01:05 AM, Luke Shumaker wrote: > > Special thanks to Andreas Grapentin ("oaken-source") for his work on > generalizing librechroot---in the interest of a RISC-V port! very cool! From lukeshu at lukeshu.com Wed Mar 28 01:53:10 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 27 Mar 2018 21:53:10 -0400 Subject: [Dev] libretools 20180327 release announcement Message-ID: <87tvt1yni1.wl-lukeshu@lukeshu.com> I just released libretools 20180326 to [libre] and pushed the source tarball to . This release has no functional changes. The change is that localization now works correctly--If you have your LANG set to Spanish, libretools should now be in Spanish. Changes from 20180326 to 20180327: - Makefile: * Correctly install localization files. - libremessages: * whitespace_collapse: Don't sometimes erroneously insert trailing whitespace. -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Wed Mar 28 13:02:05 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 28 Mar 2018 13:02:05 -0000 Subject: [Dev] Orphan Nonprism package [evolution-data-server] marked out-of-date Message-ID: <20180328130205.1092.67738@proton.parabola.nu> felicien at hyperbola.info wants to notify you that the following packages may be out-of-date: The user provided the following additional text: A new version (3.28) of evolution-data-server has released. Until the package is upgraded, Evolution and GNOME Calendar won't work correctly. https://www.archlinux.org/packages/extra/x86_64/evolution/ Thank you in advance?! Happy hacking From nobody at parabola.nu Thu Mar 29 03:25:00 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 29 Mar 2018 03:25:00 -0000 Subject: [Dev] Orphan Libre package [epiphany] marked out-of-date Message-ID: <20180329032500.1091.57700@proton.parabola.nu> jm.100best at gmail.com wants to notify you that the following packages may be out-of-date: * epiphany 3.24.2-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/epiphany/ * epiphany 3.26.6-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/epiphany/ * epiphany 3.26.6-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/epiphany/ The user provided the following additional text: GNOME 3.28 Released (https://www.gnome.org/news/2018/03/gnome-3-28-released/) From megver83 at hyperbola.info Thu Mar 29 16:58:47 2018 From: megver83 at hyperbola.info (Megver83) Date: Thu, 29 Mar 2018 13:58:47 -0300 Subject: [Dev] libretools 20180327 release announcement In-Reply-To: <87tvt1yni1.wl-lukeshu@lukeshu.com> References: <87tvt1yni1.wl-lukeshu@lukeshu.com> Message-ID: El 27/03/18 a las 22:53, Luke Shumaker escribi?: > This release has no functional changes. The change is that > localization now works correctly--If you have your LANG set to > Spanish, libretools should now be in Spanish. awesome, when I finish translating libretools (it is almost done) I'll tell you so you can push the tarball to https://repo.parabola.nu/other/libretools fully translated :) -- ~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 jc_gargma at iserlohn-fortress.net Sat Mar 31 22:44:32 2018 From: jc_gargma at iserlohn-fortress.net (jc_gargma) Date: Sat, 31 Mar 2018 15:44:32 -0700 Subject: [Dev] kinfocenter and khotkeys update patches Message-ID: <4195558.zHrDN0CqZE@iserlohn-fortress.net> I've attached git format-patches to update kinfocenter and khotkeys to 5.12.4 -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-kinfocenter-to-5.12.4.patch Type: text/x-patch Size: 1314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-khotkeys-to-5.12.4.patch Type: text/x-patch Size: 1209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: