From nobody at parabola.nu  Sun Sep  1 03:13:33 2019
From: nobody at parabola.nu (Parabola Website Notification)
Date: Sun, 01 Sep 2019 03:13:33 -0000
Subject: [Dev] Orphan Pcr package [crosstool-ng] marked out-of-date
Message-ID: <20190901031333.1214.82850@winston.parabola.nu>

alex3kov at zoho.com wants to notify you that the following packages may be out-of-date:


* crosstool-ng 1.23.0-1.parabola1 [pcr] (armv7h): https://parabolagnulinux.org/packages/pcr/armv7h/crosstool-ng/
* crosstool-ng 1.23.0-1.parabola1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/crosstool-ng/
* crosstool-ng 1.23.0-1.parabola1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/crosstool-ng/


The user provided the following additional text:

Thanks for packaging this. 1.24 is out http://crosstool-ng.github.io/2019/04/13/release-1.24.0.html


From nobody at parabola.nu  Tue Sep  3 17:26:24 2019
From: nobody at parabola.nu (Parabola Website Notification)
Date: Tue, 03 Sep 2019 17:26:24 -0000
Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date
Message-ID: <20190903172624.17220.95241@winston.parabola.nu>

reg+parabola at disroot.org wants to notify you that the following packages may be out-of-date:


* iceweasel 1:66.0.3-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/
* iceweasel 1:68.0.2-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/


The user provided the following additional text:

Firefox 69 has been released https://www.mozilla.org/en-US/firefox/69.0/releasenotes/


From theova at bluewin.ch  Sun Sep 15 11:30:26 2019
From: theova at bluewin.ch (theova)
Date: Sun, 15 Sep 2019 13:30:26 +0200
Subject: [Dev] Upgrade for [nonprism/gnome-online-accounts] to 3.34.0
In-Reply-To: <20190813194410.iglog5jvsv4zn5dj@RainbowWarrior.localdomain>
References: <20190813194410.iglog5jvsv4zn5dj@RainbowWarrior.localdomain>
Message-ID: <20190915113026.b2xizsty6hv2lssa@RainbowWarrior.localdomain>

PKGBUILD for [nonprism/gnome-online-accounts] 3.34.0.

Changelog:
- Update tag
- Add verbose flag to function in check()
- 3.34.0 introduces option for fedora account system
  (https://fedoraproject.org/wiki/Account_System). It is disabled by
  default and I let it as that.

Building:
- The package builds on all 3 supported architectures.

Testing:
- I have tested the x86_64 package by looking at the corresponding
  category in gnome's settings. Only the deserved ones are there.


theova <theova at bluewin.ch> schrieb am Tue, 13. Aug 19 21:44:
>The PKGBUILD attached is the updated version for
>[nonprism/gnome-online-accounts].
>
>Changelog:
>- Generally make PKGBUILD closer to Arch's one
>- Update version and source
>- Remove unneeded dependencies
>- Change to meson build system
>- Add check()
>- Change compile flags:
> - kerberos, owncloud, imap-smtp are enabled per default.
> - Telepathy, Todoist, Twitter and Yahoo support was removed [1] [2]
>   [3] [4]
>
>Testing:
>I have tested the package by looking at the corresponding category in
>gnome's settings. Only the deserved ones are there.
>
>Thanks for updating the package in Parabolas Repo.
>
>
>[1]
>https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/d44f89f8b9891593ff0fe1b428e1a1253a4667af
>[2]
>https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/bf77325d847d2878159e8ba2677768b2fe6386a6
>[3]
>https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/eac46d6de3ba6db904a7dfbe7a82e6db8e12bc4b
>[4]
>https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/64cfb8183150475465f20631d4e9d4f917d128e3

-------------- next part --------------
# $Id$
# Contributor (Arch): Ionut Biru <ibiru at archlinux.org>
# Contributor: Andreas Grapentin <andreas at grapentin.org>
# Contributor: M?rcio Silva <coadde at hyperbola.info>
# Contributor: Isaac David <isacdaavid at at@isacdaavid at dot@info>
# Contributor: Theova <theova at member.fsf.org>

# parabola changes and rationale:
#  - removed support for possibly unsafe protocols

pkgname=gnome-online-accounts
pkgver=3.34.0
pkgrel=1
pkgrel+=.nonprism1
pkgdesc="Single sign-on framework for GNOME"
pkgdesc+=", without support for unsafe and dangerous for privacy protocols"
url="https://wiki.gnome.org/Projects/GnomeOnlineAccounts"
arch=(x86_64)
arch+=(i686 armv7h)
license=(LGPL)
depends=(webkit2gtk json-glib libnotify rest libsecret krb5 gcr)
makedepends=(gobject-introspection gtk-doc vala git meson)
optdepends=('gvfs-goa: Virtual file systems, e.g. OwnCloud')
_commit=eabe91aec08ce2e1d2b7bb6b67c6ba097aee0ba9  # tags/3.34.0^0
source=("git+https://gitlab.gnome.org/GNOME/gnome-online-accounts.git#commit=$_commit")
sha256sums=('SKIP')

pkgver() {
  cd $pkgname
  git describe --tags | sed 's/-/+/g'
}

prepare() {
  cd $pkgname
}

build() {
  arch-meson $pkgname build \
    -D lastfm=false \
    -D media_server=true \
    -D gtk_doc=true \
    -D man=true \
    -D inspector=true \
    -D exchange=false \
    -D facebook=false \
    -D flickr=false \
    -D google=false \
    -D pocket=false \
    -D windows_live=false \
    -D foursquare=false
  ninja -C build
}

check() {
  meson test -C build --print-errorlogs
}

package() {
  DESTDIR="$pkgdir" meson install -C build
}

# vim:set ts=2 sw=2 et:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20190915/3f697511/attachment.sig>

From bill-auger at peers.community  Tue Sep 17 17:49:04 2019
From: bill-auger at peers.community (bill-auger)
Date: Tue, 17 Sep 2019 13:49:04 -0400
Subject: [Dev] testing
Message-ID: <20190917134904.362c2b66@parabola>

testing

From labs at parabola.nu  Mon Sep  9 11:44:40 2019
From: labs at parabola.nu (labs at parabola.nu)
Date: Mon, 09 Sep 2019 11:44:40 +0000
Subject: [Dev] [libretools - Feature Request #2403] [libremakepkg]:
 eradicate mksource() from abslibre
References: <redmine.issue-2403.20190726221017@parabola.nu>
Message-ID: <redmine.journal-12951.20190909114408.ed6b50cbc2e9423f@parabola.nu>

Issue #2403 has been updated by freemor.


Interesting, and good researching of the subject. But To my minimalist mind
that still leaves us with mksource() in the PKGBUILDs and yet another tool all
to accomplish what: makepkg -o does without these things. I still feel that
having libretools roll the source tarball post prepare() would be the cleanest
way to go.

Going the other way would require us to strip steps out of prepare to move them
into mksource() for every package we build. This creates a glaring divide
between Parabola packages and Arch packages and also add a lot of un-necessary
work. 

Since we probably don't want to re-write makepkg, I'd suggest taking the
rolling of the source tarball out of libremakepkg and moving it into librestage
which could just run makepkg -o, roll up the tarball and move it to staging. Of
course the problem with this is we then have a clean source that the PKGBUILD
may fail to build from depending on the steps in prepare(). Which is what
mksource is trying to  fix I guess. 

My concern is the further we get from standard Arch tools the larger the
learning curve for new people coming to Parabola. People coming from Arch are
going to be confused if the usual pull the PKGBUILD, run makepkg approach
fails. 

I understand that if Parabola hosts the source tarballs they should be clean
ones, But the ugly truth is that the actual process is: pull unclean source,
make it libre, build it. In such a case I see hosting clean source files as
slightly disingenuous. The PKGBUILD is always going to have the location of the
original source so it's not like we are able to hide that, nor should we.
Trying to debug from pre-cleaned sources could be problematic too as if one of
our patches breaks something is a weird way it becomes very difficult to see
what was supposed to happen short of going and downloading the un-patched
source. 

So it really ends up feeling that all hosting clean sources does is:
  
   a.) complicate things. 
   b.) kick the unclean source a step or two further down the road. 




----------------------------------------
Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre
https://labs.parabola.nu/issues/2403#change-12951

* Author: bill-auger
* Status: info needed
* Priority: discussion
* Assignee: 
* Category: 
----------------------------------------
related to forum thread https://labs.parabola.nu/boards/18/topics/125

IIRC when discussing the 'ruby' package, we concluded that it was probably intended per the FSDG, to provide complete and pre-cleaned source-balls to the distro users; which entails the devs to keep some of the libre-fications tools private

the FSDG does not require support for versions of 'foo' that were not included in any distro release however; but OTOH, this PKGBUILD contains instructions for downloading known non-free software

on the third hand (the philosophical hand), the 'gist' of the four freedoms is not about possessing or sharing non-free software; but that the user is able to do with it as they see fit - if the only thing that one wishes to do with that software is to merely posses it or share it, then anything redistributable would satisfy the 'gist' of the four freedoms for that person

probably the simplest way to resolve this class of issue, is to add a note to the PKGBULID with sed above every instance of 'mksource()', asking the reader to ignore it and ask a parabola dev to publish the intermediate source-ball, if they are building ahead of the current release; then to publish the missing source-ball for any enthusiastic user who asks for one - a better solution to this class of issue, would be for the PKGBUILD to explaining how to run mksource() and have the mksource() function create the source-ball with expected libre name in the sources() array - if that does not conflict with the FSDG - an even better solution to this class of issue, is to eliminate it by eradicating mksource() from abslibre somehow, even if that is simply moving the PKGBUILD to a private git branch

this incident is not a peculiar though - it is currently systematic AFAIK; so i consulted the FSDG:

  "A free system distribution must not steer users towards obtaining any nonfree information
for practical use, or encourage them to do so. The system should have no repositories 
for nonfree software and no specific recipes for installation of particular nonfree programs."

there is another clause that might suggest that this use case is within the guidelines; although it is in the "Documentation" section

  "In general, something that helps people who already use nonfree software
to use the free software better with it is acceptable,
but something that encourages users of the free software to install nonfree software is not."

libre-fications would seem to fit into that documentation exception - id say the key point is that such scripts do not install the program "for practical use" - the use-case in which the user is interested, is to download a non-free tarball, and to liberate it, without viewing or executing any of the files within it; for the sole purpose of using the cleaned sources in freedom - it would seems better to instruct people how to liberate non-free software rather than impeding their curiosity or ambition; though it may snag upon some FSDG caveat 

some options:

* should consult the FSDG mailing list about this grey area
* put these on the wiki as documentation, instead of in PKGBUILDs
* libretools could be made to download the file into memory instead of writing a hard copy
* hide all such scripts at the cost of impeding enthusiastic users who want to help




-- 
-- ^^^^ Type your reply above this line ^^^^ --
--     Please keep the 'Subject' as it is    --

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From labs at parabola.nu  Mon Sep  9 16:06:04 2019
From: labs at parabola.nu (labs at parabola.nu)
Date: Mon, 09 Sep 2019 16:06:04 +0000
Subject: [Dev] [libretools - Feature Request #2403] [libremakepkg]:
 eradicate mksource() from abslibre
References: <redmine.issue-2403.20190726221017@parabola.nu>
Message-ID: <redmine.journal-12952.20190909160531.591b2daad8b25f07@parabola.nu>

Issue #2403 has been updated by bill-auger.


freemor wrote:
>
> Going the other way would require us to strip steps out of
> prepare to move them into mksource() for every package we
> build.

well not every package; but every one that replaces something in
arch - the parity with the arch PKGBUILDs could still be
maintained that way - only the "librefication" commands would
need to be in mksource() - doing so could actually make the
diffs cleaner than they are now


freemor wrote:
> Since we probably don't want to re-write makepkg, the
> problem with this is we then have a clean source that the
> PKGBUILD may fail to build

yea thats my thinking - any changes from the current workflow
would entail some modification to makepkg - at least we
understand now why mksource() exists - it just was not fully
utilized for every package; probably because it is such a huge
take


freemor wrote:
> People coming from Arch are going to be confused if the usual
> pull the PKGBUILD, run makepkg approach fails. 

makepkg would not fail with the current workflow because the
cleaned tarballs are published at the location where the PKGBUILD
expects them to be - as i understand, the mksource() function
only runs if that tarball is not found on the server


freemor wrote:
> Trying to debug from pre-cleaned
> sources could be problematic too

thats certainly true; but simply changing the URL of the
expected cleaned source-ball in the sources array would force
mksource() to run again - AFAIK the newly generated source-ball
only gets published upon librerelease


freemor wrote:
>    a.) complicate things. 
>    b.) kick the unclean source further down the road. 

i dont think mksource+librefetch: would be "complicated" - it
would just be a shit-ton of work to sort the librefication
commands out of prepare() and into mksource() for every libre
package; but presumably the tools already have that
functionality to handle it

what would be complex is modifying makepkg to create the tarball
after prepare() has run, and to skip over prepare() if
pre-cleaned source-balls are detected - if we were writing
makepkg from scratch, i think that would be most reasonable from
the engineering perspective; but it is a significant deviation
from arch; but going to be the case no matter how this is done

approach B would surely be less work; but that is a deviation
from the arch tools also - approach A has the added advantage of
making the diffs against arch much cleaner for evermore into the
future

if librefetch does its magic transparently, without manual
steps, it probably is the best approach as a long-term investment

* the deviation from arch is constrained to libretools
* the tooling already exists and is working well for hyperbola
* cleaner diffs
* users who run libremakepkg on versions ahead of parabola will
get a cleaned tarball

----------------------------------------
Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre
https://labs.parabola.nu/issues/2403#change-12952

* Author: bill-auger
* Status: info needed
* Priority: discussion
* Assignee: 
* Category: 
----------------------------------------
related to forum thread https://labs.parabola.nu/boards/18/topics/125

IIRC when discussing the 'ruby' package, we concluded that it was probably intended per the FSDG, to provide complete and pre-cleaned source-balls to the distro users; which entails the devs to keep some of the libre-fications tools private

the FSDG does not require support for versions of 'foo' that were not included in any distro release however; but OTOH, this PKGBUILD contains instructions for downloading known non-free software

on the third hand (the philosophical hand), the 'gist' of the four freedoms is not about possessing or sharing non-free software; but that the user is able to do with it as they see fit - if the only thing that one wishes to do with that software is to merely posses it or share it, then anything redistributable would satisfy the 'gist' of the four freedoms for that person

probably the simplest way to resolve this class of issue, is to add a note to the PKGBULID with sed above every instance of 'mksource()', asking the reader to ignore it and ask a parabola dev to publish the intermediate source-ball, if they are building ahead of the current release; then to publish the missing source-ball for any enthusiastic user who asks for one - a better solution to this class of issue, would be for the PKGBUILD to explaining how to run mksource() and have the mksource() function create the source-ball with expected libre name in the sources() array - if that does not conflict with the FSDG - an even better solution to this class of issue, is to eliminate it by eradicating mksource() from abslibre somehow, even if that is simply moving the PKGBUILD to a private git branch

this incident is not a peculiar though - it is currently systematic AFAIK; so i consulted the FSDG:

  "A free system distribution must not steer users towards obtaining any nonfree information
for practical use, or encourage them to do so. The system should have no repositories 
for nonfree software and no specific recipes for installation of particular nonfree programs."

there is another clause that might suggest that this use case is within the guidelines; although it is in the "Documentation" section

  "In general, something that helps people who already use nonfree software
to use the free software better with it is acceptable,
but something that encourages users of the free software to install nonfree software is not."

libre-fications would seem to fit into that documentation exception - id say the key point is that such scripts do not install the program "for practical use" - the use-case in which the user is interested, is to download a non-free tarball, and to liberate it, without viewing or executing any of the files within it; for the sole purpose of using the cleaned sources in freedom - it would seems better to instruct people how to liberate non-free software rather than impeding their curiosity or ambition; though it may snag upon some FSDG caveat 

some options:

* should consult the FSDG mailing list about this grey area
* put these on the wiki as documentation, instead of in PKGBUILDs
* libretools could be made to download the file into memory instead of writing a hard copy
* hide all such scripts at the cost of impeding enthusiastic users who want to help




-- 
-- ^^^^ Type your reply above this line ^^^^ --
--     Please keep the 'Subject' as it is    --

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From labs at parabola.nu  Wed Sep 11 22:22:02 2019
From: labs at parabola.nu (labs at parabola.nu)
Date: Wed, 11 Sep 2019 22:22:02 +0000
Subject: [Dev] [libretools - Feature Request #2403] [libremakepkg]:
 eradicate mksource() from abslibre
References: <redmine.issue-2403.20190726221017@parabola.nu>
Message-ID: <redmine.journal-12956.20190911222149.90f04cf1f26933c3@parabola.nu>

Issue #2403 has been updated by bill-auger.


plan A is not without is cons also - ive been mulling them over 

* something like 800 PKGBUILDs would need the mksource() treatment - ouch!
* some source-balls end up in the repo under other/ and not sources/
* its kinda goofy

so i am coming around to the merits of plan B - the most attractive property of plan B is that it could be accomplished in a reasonably finite amount of time; and would "just work" for any future packages without special treatment - i think it would entail the following:

* modify libremakepkg to:
  * create the source-ball not before the prepare() function but before build()
* modify makepkg to:
  * always attempt to download the cleaned source-ball from the sources repo
  * ignore the sources() array and skip prepare() if the cleaned source-ball was found


----------------------------------------
Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre
https://labs.parabola.nu/issues/2403#change-12956

* Author: bill-auger
* Status: info needed
* Priority: discussion
* Assignee: 
* Category: 
----------------------------------------
related to forum thread https://labs.parabola.nu/boards/18/topics/125

IIRC when discussing the 'ruby' package, we concluded that it was probably intended per the FSDG, to provide complete and pre-cleaned source-balls to the distro users; which entails the devs to keep some of the libre-fications tools private

the FSDG does not require support for versions of 'foo' that were not included in any distro release however; but OTOH, this PKGBUILD contains instructions for downloading known non-free software

on the third hand (the philosophical hand), the 'gist' of the four freedoms is not about possessing or sharing non-free software; but that the user is able to do with it as they see fit - if the only thing that one wishes to do with that software is to merely posses it or share it, then anything redistributable would satisfy the 'gist' of the four freedoms for that person

probably the simplest way to resolve this class of issue, is to add a note to the PKGBULID with sed above every instance of 'mksource()', asking the reader to ignore it and ask a parabola dev to publish the intermediate source-ball, if they are building ahead of the current release; then to publish the missing source-ball for any enthusiastic user who asks for one - a better solution to this class of issue, would be for the PKGBUILD to explaining how to run mksource() and have the mksource() function create the source-ball with expected libre name in the sources() array - if that does not conflict with the FSDG - an even better solution to this class of issue, is to eliminate it by eradicating mksource() from abslibre somehow, even if that is simply moving the PKGBUILD to a private git branch

this incident is not a peculiar though - it is currently systematic AFAIK; so i consulted the FSDG:

  "A free system distribution must not steer users towards obtaining any nonfree information
for practical use, or encourage them to do so. The system should have no repositories 
for nonfree software and no specific recipes for installation of particular nonfree programs."

there is another clause that might suggest that this use case is within the guidelines; although it is in the "Documentation" section

  "In general, something that helps people who already use nonfree software
to use the free software better with it is acceptable,
but something that encourages users of the free software to install nonfree software is not."

libre-fications would seem to fit into that documentation exception - id say the key point is that such scripts do not install the program "for practical use" - the use-case in which the user is interested, is to download a non-free tarball, and to liberate it, without viewing or executing any of the files within it; for the sole purpose of using the cleaned sources in freedom - it would seems better to instruct people how to liberate non-free software rather than impeding their curiosity or ambition; though it may snag upon some FSDG caveat 

some options:

* should consult the FSDG mailing list about this grey area
* put these on the wiki as documentation, instead of in PKGBUILDs
* libretools could be made to download the file into memory instead of writing a hard copy
* hide all such scripts at the cost of impeding enthusiastic users who want to help




-- 
-- ^^^^ Type your reply above this line ^^^^ --
--     Please keep the 'Subject' as it is    --

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From labs at parabola.nu  Wed Sep 11 23:28:01 2019
From: labs at parabola.nu (labs at parabola.nu)
Date: Wed, 11 Sep 2019 23:28:01 +0000
Subject: [Dev] [libretools - Feature Request #2403] [libremakepkg]:
 eradicate mksource() from abslibre
References: <redmine.issue-2403.20190726221017@parabola.nu>
Message-ID: <redmine.journal-12961.20190911232452.20cf2d4130572715@parabola.nu>

Issue #2403 has been updated by bill-auger.

Related to Feature Request #760: [librefetch]/[libremakepkg] Run mksource() in the chroot added

----------------------------------------
Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre
https://labs.parabola.nu/issues/2403#change-12961

* Author: bill-auger
* Status: info needed
* Priority: discussion
* Assignee: 
* Category: 
----------------------------------------
related to forum thread https://labs.parabola.nu/boards/18/topics/125

IIRC when discussing the 'ruby' package, we concluded that it was probably intended per the FSDG, to provide complete and pre-cleaned source-balls to the distro users; which entails the devs to keep some of the libre-fications tools private

the FSDG does not require support for versions of 'foo' that were not included in any distro release however; but OTOH, this PKGBUILD contains instructions for downloading known non-free software

on the third hand (the philosophical hand), the 'gist' of the four freedoms is not about possessing or sharing non-free software; but that the user is able to do with it as they see fit - if the only thing that one wishes to do with that software is to merely posses it or share it, then anything redistributable would satisfy the 'gist' of the four freedoms for that person

probably the simplest way to resolve this class of issue, is to add a note to the PKGBULID with sed above every instance of 'mksource()', asking the reader to ignore it and ask a parabola dev to publish the intermediate source-ball, if they are building ahead of the current release; then to publish the missing source-ball for any enthusiastic user who asks for one - a better solution to this class of issue, would be for the PKGBUILD to explaining how to run mksource() and have the mksource() function create the source-ball with expected libre name in the sources() array - if that does not conflict with the FSDG - an even better solution to this class of issue, is to eliminate it by eradicating mksource() from abslibre somehow, even if that is simply moving the PKGBUILD to a private git branch

this incident is not a peculiar though - it is currently systematic AFAIK; so i consulted the FSDG:

  "A free system distribution must not steer users towards obtaining any nonfree information
for practical use, or encourage them to do so. The system should have no repositories 
for nonfree software and no specific recipes for installation of particular nonfree programs."

there is another clause that might suggest that this use case is within the guidelines; although it is in the "Documentation" section

  "In general, something that helps people who already use nonfree software
to use the free software better with it is acceptable,
but something that encourages users of the free software to install nonfree software is not."

libre-fications would seem to fit into that documentation exception - id say the key point is that such scripts do not install the program "for practical use" - the use-case in which the user is interested, is to download a non-free tarball, and to liberate it, without viewing or executing any of the files within it; for the sole purpose of using the cleaned sources in freedom - it would seems better to instruct people how to liberate non-free software rather than impeding their curiosity or ambition; though it may snag upon some FSDG caveat 

some options:

* should consult the FSDG mailing list about this grey area
* put these on the wiki as documentation, instead of in PKGBUILDs
* libretools could be made to download the file into memory instead of writing a hard copy
* hide all such scripts at the cost of impeding enthusiastic users who want to help




-- 
-- ^^^^ Type your reply above this line ^^^^ --
--     Please keep the 'Subject' as it is    --

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From nobody at parabola.nu  Mon Sep 23 12:55:07 2019
From: nobody at parabola.nu (Parabola Website Notification)
Date: Mon, 23 Sep 2019 12:55:07 -0000
Subject: [Dev] Orphan Kernels package [linux-libre-xtreme] marked out-of-date
Message-ID: <20190923125507.1141.61140@winston.parabola.nu>

robinde at tutanota.com wants to notify you that the following packages may be out-of-date:




The user provided the following additional text:

Dear maintainer,
The 5.0.x linux branch has now been end of life for quite some time, the current latest stable releases are 5.2.x and 5.3.x
Please update all `linux-libre-xtreme` packages accordingly
Kind regards


From freemor at freemor.ca  Mon Sep 23 14:49:30 2019
From: freemor at freemor.ca (Freemor)
Date: Mon, 23 Sep 2019 11:49:30 -0300
Subject: [Dev] Orphan Kernels package [linux-libre-xtreme] marked
 out-of-date
In-Reply-To: <20190923125507.1141.61140@winston.parabola.nu>
References: <20190923125507.1141.61140@winston.parabola.nu>
Message-ID: <20190923144930.GD20067@freemor.ca>

On Mon, Sep 23, 2019 at 12:55:07PM -0000, Parabola Website Notification wrote:
> robinde at tutanota.com wants to notify you that the following packages may be out-of-date:
> 
> 
> 
> 
> The user provided the following additional text:
> 
> Dear maintainer,
> The 5.0.x linux branch has now been end of life for quite some time, the current latest stable releases are 5.2.x and 5.3.x
> Please update all `linux-libre-xtreme` packages accordingly
> Kind regards
>


I seem to recall discussion about Linux-Libre-Extreme a ways back WRT the
people making the patches no longer releasing then in a libre manner and thus
the reason extreme is not moving forwards. 

Can't find it on the bug tracker. Perhaps it was here on the ML or something.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20190923/9f667ed9/attachment.sig>

From megver83 at hyperbola.info  Tue Sep 24 21:10:58 2019
From: megver83 at hyperbola.info (Megver83)
Date: Tue, 24 Sep 2019 18:10:58 -0300
Subject: [Dev] Orphan Kernels package [linux-libre-xtreme] marked
 out-of-date
In-Reply-To: <20190923144930.GD20067@freemor.ca>
References: <20190923125507.1141.61140@winston.parabola.nu>
 <20190923144930.GD20067@freemor.ca>
Message-ID: <68a2ea81-320d-e07c-d05e-a557832ae1ff@hyperbola.info>

El 23-09-19 a las 11:49, Freemor escribi?:
> On Mon, Sep 23, 2019 at 12:55:07PM -0000, Parabola Website Notification wrote:
>> robinde at tutanota.com wants to notify you that the following packages may be out-of-date:
>>
>>
>>
>>
>> The user provided the following additional text:
>>
>> Dear maintainer,
>> The 5.0.x linux branch has now been end of life for quite some time, the current latest stable releases are 5.2.x and 5.3.x
>> Please update all `linux-libre-xtreme` packages accordingly
>> Kind regards
>>
> 
> 
> I seem to recall discussion about Linux-Libre-Extreme a ways back WRT the
> people making the patches no longer releasing then in a libre manner and thus
> the reason extreme is not moving forwards. 
> 
> Can't find it on the bug tracker. Perhaps it was here on the ML or something.
> 
> 
> 
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
That was the knock patch, but with linux-libre-lts-xtreme, which was
removed because of that plus the time consume. The thing is that I don't
know if it's worth to keep linux-libre-xtreme because all the LSM that
are enabled there are the same as of mainstream kernels, but I think
I'll update it for 5.3 soon

-- 
~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
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 520 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20190924/566f8adc/attachment-0001.sig>

From alex3kov at zoho.com  Wed Sep 25 15:04:15 2019
From: alex3kov at zoho.com (Aleksei)
Date: Wed, 25 Sep 2019 18:04:15 +0300
Subject: [Dev] Thanks for supporting armv7 arch
Message-ID: <20190925150415.3imseqsqg6cv324m@gnulinux.localdomain>

Hi,
I just migrated my Cubieboard1 from Arch ARM to Parabola and it went without a
hitch, took only like 30 minutes.
Just wanted to say thanks to Parabola developers, you guys rock!



From megver83 at hyperbola.info  Wed Sep 25 20:39:19 2019
From: megver83 at hyperbola.info (Megver83)
Date: Wed, 25 Sep 2019 17:39:19 -0300
Subject: [Dev] Thanks for supporting armv7 arch
In-Reply-To: <20190925150415.3imseqsqg6cv324m@gnulinux.localdomain>
References: <20190925150415.3imseqsqg6cv324m@gnulinux.localdomain>
Message-ID: <28abcc6e-3026-f040-8839-85cf94b57c44@hyperbola.info>

El 25-09-19 a las 12:04, Aleksei escribi?:
> Hi,
> I just migrated my Cubieboard1 from Arch ARM to Parabola and it went
> without a
> hitch, took only like 30 minutes.
> Just wanted to say thanks to Parabola developers, you guys rock!
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
I'm glad to know this, not many people speak when things go well :P

-- 
~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
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 520 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20190925/95c9c6e8/attachment.sig>

From bill-auger at peers.community  Wed Sep 25 22:55:10 2019
From: bill-auger at peers.community (bill-auger)
Date: Wed, 25 Sep 2019 18:55:10 -0400
Subject: [Dev] Thanks for supporting armv7 arch
In-Reply-To: <28abcc6e-3026-f040-8839-85cf94b57c44@hyperbola.info>
References: <20190925150415.3imseqsqg6cv324m@gnulinux.localdomain>
 <28abcc6e-3026-f040-8839-85cf94b57c44@hyperbola.info>
Message-ID: <20190925185510.23d69b20@parabola>

the olimex folks just posted a nice "yay, parabola" last week too

https://olimex.wordpress.com/2019/09/16/the-open-source-hardware-linux-board-a20-olinuxino-lime2-is-now-supported-by-freedom-respected-parabola-gnu-linux-libre-distribution/

From nobody at parabola.nu  Sun Sep 29 07:07:08 2019
From: nobody at parabola.nu (Parabola Website Notification)
Date: Sun, 29 Sep 2019 07:07:08 -0000
Subject: [Dev] Orphan Libre package [virt-install] marked out-of-date
Message-ID: <20190929070708.1144.41225@winston.parabola.nu>

8abtu15qtyj8 at opayq.com wants to notify you that the following packages may be out-of-date:


* virt-install 2.2.0-1.par1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/virt-install/
* virt-install 2.0.0-3.par1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/virt-install/
* virt-install 2.2.0-1.par1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/virt-install/


The user provided the following additional text:

2.2.1 is out and has been, afaict, since July:

https://releases.pagure.org/virt-manager/virt-manager-2.2.1.tar.gz

https://github.com/virt-manager/virt-manager/releases/tag/v2.2.1

virt-manager requires this newer version now.