Re: [Dev] [dev] [nonsystemd] NetworkManager, dbus and display managers require manual intervention

[Megver83]

To be brief: the wiki needs to updated (I plan to do this later) and no, 
i wouldn't put openrc init scripts in depends=() for any package, after 
all, the repo is called "nonsystemd" and not "openrc".


This will give us the necessary flexibility to include more init 
alternatives. See https://labs.parabola.nu/issues/3290 for more.


P.S: openrc-desktop was deprecated and other groups will do too, 
opentmpfiles and opensysusers where replaced by etmpfiles and esysusers


El 19-07-22 a las 00:16, bill-auger escribió:

the wiki need to be updated then

in https://wiki.parabola.nu/Installation_Guide

# pacstrap /mnt networkmanager
so that would need to become
# pacstrap /mnt networkmanager networkmanager-openrc

but it would be better if the nonsystend/networkmanager had the
init script package in it's depends=() - probably everyone who
installs nonsystend/networkmanager wants the init scripts - for
that matter, as it is a tiny package, wouldn't it make the most
sense to put the init scripts directly in the
nonsystend/networkmanager package?

the install guide also makes this note:


Note, however, that essential services are enabled by default
(e.g. dbus, elogind, opensysusers and opentmpfiles).


is it possible to enable a service ('dbus') automatically, if
the init scripts are not installed?


in https://wiki.parabola.nu/OpenRC


but dbus from [nonsystemd] has its init script already.



If the package was installed from Nonsystemd, it's likely to have its init 
script already installed. Core packages, like elogind and dbus, have those 
services installed and enabled by default.


also, what happened to the 'openrc-desktop' package group? the
wiki still suggests installing it


one can install the openrc-desktop package group to get most software and its 
init scripts needed for desktop environments:

___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Move libre/kio to [nonprism]

[Megver83]

Arch's kio doesn't have any proprietary nor branding issues, only
privacy ones. I think we should move our package [nonprism] rather than
blacklisting and building it in [libre]. Unless, and here's my doubt,
there's something that prevents us from doing this to which I'm unaware.
-- 
~Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] gnusocial parabola group was deleted?

[Megver83]

I think it was deleted a long time ago. Let's remove it, nobody said
anything about its disappearance and the group was (almost) inactive.

El 23-05-21 a las 00:00, bill-auger escribió:
> does anyone know what happened to the parabola group on
> gnusocial.net ? - or who created it? - we should probably remove
> this from the home-page?
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 

-- 
~Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] parabola GNU/Linux-libre on Risc-V and OpenPower

[Megver83]

Awesome!! 拾拾拾
I'm really excited about this, my only pain is not having real ppc and
risc-v hardware. Could you write a quick guide on how to install
Parabola in this hardware? I might eventually get, at least, a risc-v
SBC. This sunday is my birthday, so I wish someone gives me one as a gift 

El 08-04-21 a las 15:21, Andreas Grapentin escribió:
> 
> Hi All,
> 
> I am happy to announce that today, the kingstone has been placed on top
> of the parabola risc-V port, meaning that we can now reliably produce
> virtual machine images running on both the riscv64 and the powerpc64le
> architectures.
> 
> parabola is completely self-sufficient and self-hosted on these systems,
> which means that, while the amount of available packages is limited, the
> entire system, and indeed every other package, can be built and
> reproduced using only packages that are already available and no further
> cross-compilation is needed.
> 
> All of this work has been done on x86_64 parabola GNU/Linux-libre hosts
> using exclusively free software, so the ports are not tainted by
> non-free software.
> 
> If you want to check out the virtual machine images, they are available
> here:
> 
> https://mirror.grapentin.org/parabola-ports/riscv64/
> https://mirror.grapentin.org/parabola-ports/powerpc64le/
> 
> We are currently limited by a lack of actual hardware, which we would
> need to progress further with these ports. There might be unforseen
> issues if you try to deploy parabola to a physical device. Feel free to
> contact us if you have a device to spare!
> 
> Best Regards,
> Andreas
> 
> 
> oaken-source
> for the parabola project
> https://parabola.nu
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 

-- 
~Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Fw: [arch-announce] Moving to Zstandard images by default on mkinitcpio

[Megver83]

El 26-02-21 a las 19:05, bill-auger escribió:
> related to:
> https://lists.parabola.nu/pipermail/assist/2021-February/001591.html
> 
> Megver - would you be able to upgrade linux-libre-lts this week?

Of course, I'll upgrade kernels this weekend, starting with linux-libre-lts

> a bug of this severity would normally a justify bug report - the
> solution is obvious though, and needs little discussion
> 
> we could fix this temporarily in 'nonsystemd/mkinitcpio', and
> add an emergency 'libre/mkinitcpio' package with:
>   /etc/mkinitcpio.conf:
> COMPRESSION="gzip"
> 
> thoughts?, comments?, suggestions?

Better wait till kernels get their updates. Last time I had problems
when building PCK, that's why it got stuck in v5.8, but the rest is OK.
Maybe a news telling to wait the update is simpler.

-- 
~Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Registration request: new public Parabola Linux mirror (Hungary)

[Megver83]

Hi, sorry for the late answer. I saw your mail but didn't have the time
to respond, I'm preparing for my exams in November so I've had little
time for Parabola pitifully.

I'll ask bill-auger if he knows how to add mirrors, so me or he can do
it asap.

Thank you for the mirror, as always, all contributions are very
appreciated for Parabola.

El 29-09-20 a las 13:40, Quantum Mirror escribió:
> Dear Parabola Linux developers,
> 
> 
> I sent my registration request almost 1 month ago, but I haven't
> received a response yet and the mirror hasn't appeared in the parabola
> mirror list also https://www.parabola.nu/mirrors/
> https://www.parabola.nu/mirrors/status/ .
> 
> The full registration request (as Tier1) can be read here:
> 
> https://lists.parabola.nu/pipermail/dev/2020-September/007877.html
> 
> 
> Would you be so kind to consider the application?
> 
> 
> If You need more information or have any questions, please feel free to
> contact me on this mailing list or at r...@quantum-mirror.hu.
> 
> 
> I'm very looking forward to your kind answer.
> 
> Thank you for your help in advance!
> 
> 
> Best regards,
> 
> Peter
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 

-- 
~Megver83
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [gajim-plugin-omemo] marked out-of-date

[Megver83]

afaik, Gajim only offers FLOSS plugins

El 26-07-20 a las 15:44, bill-auger escribió:
> that is one of the main reasons why plugins are packaged
> separately though - if that program allows searching and
> downloading plugins from the internet, it falls under the
> category of a third-party package manager, and most of
> those are dubious WRT FSDG-fitness
> 
> unless that program only lists free software, then it is likely
> that someone will eventually post a freedom bug report, to
> remove the entire download feature - which means we may need to
> re-package gajim, and some of its its popular plugins too
> 
> there is a long discussion about TPPMs, and many related issues,
> and proposals for how to handle them - it seems that gajim needs
> to be added to that ticket as another one to investigate
> 
> https://labs.parabola.nu/issues/1035
> 
> we should be moving in the direction of filtering or avoiding
> third-party package managers, rather than encouraging people to
> use them - what we have found so far, is that filtering is either
> very difficult or impossible to do automatically, because very
> few TPPMs indicate licenses or have any policies about what is
> allowed in the repo - with the exception of haskell and guix,
> which have stricter guidelines than the others, it would be
> better to discourage their use as much as possible
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [gajim-plugin-omemo] marked out-of-date

[Megver83]

I might delete this package as you can install the plugin from the
plugin installer

El 26-07-20 a las 13:18, Parabola Website Notification escribió:
> oxy...@protonmail.com wants to notify you that the following packages may be 
> out-of-date:
> 
> 
> * gajim-plugin-omemo 2.6.29-2 [pcr] (armv7h): 
> https://parabolagnulinux.org/packages/pcr/armv7h/gajim-plugin-omemo/
> * gajim-plugin-omemo 2.6.29-2 [pcr] (i686): 
> https://parabolagnulinux.org/packages/pcr/i686/gajim-plugin-omemo/
> * gajim-plugin-omemo 2.6.29-2 [pcr] (x86_64): 
> https://parabolagnulinux.org/packages/pcr/x86_64/gajim-plugin-omemo/
> 
> 
> The user provided the following additional text:
> 
> This package needs upgrading otherwise it causes Pacman upgrade to fail. 
> 
> New version as found in the AUR: 
> https://aur.archlinux.org/packages/gajim-plugin-omemo/
> 
> Thanks in advance!
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Linphone is now in PCR!

[Megver83]

Hi everyone, hope you're all doing well. Just wanted to say that I could
finally build and package Linphone Desktop in [pcr]. I built it (and its
dependencies) for x86_64 and i686 only, for now.

This fixes and closes https://labs.parabola.nu/issues/2657

I wish you a good day! :D

P.D.: Yes, I'm super happy for this, I remember the bloody battle I had
before trying to build linphone-desktop without success... difficult
times :P



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

I opened an issue in ungoogled-chromium's GitHub, asking if it
completely cleans Chromium from non-free software. It certainly doesn't,
but I got very interesting and useful info. For further reading:

https://github.com/Eloston/ungoogled-chromium/issues/1054

in fact it looks like the ungoogle-chromium guys are open to make a fork
to clean Chromium completely from non-free software:

https://github.com/Eloston/ungoogled-chromium/issues/1054#issuecomment-643565898

Let them know if you want that (I think we all want it) to incentivize
them. I'll give a thumb up to that comment :)



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH] README.maintenance: clarify how to become redmine admin

[Megver83]

El 12-06-20 a las 18:15, Denis 'GNUtoo' Carikli escribió:
> +After logging in winston, run the Redmine's rail rail console.
did you write "rails" twice purposely or by mistake?

> +  $ sudo su labs
> +  [labs@winston labs.parabola.nu]$ cd /srv/http/labs.parabola.nu/
> +  [labs@winston labs.parabola.nu]$ ./enter-rails-console
> +  irb(main):001:0>
wouldn't be a better option to run that script with `sudo -u labs
./enter-rails-console`?



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

you forgot to send this to the mailing list

El 02-06-20 a las 20:03, eliotreyna@cock.email escribió:
> Honestly, I'm using Chromium from Arch Linux (installed in my netbook
> due to my wifi card that requires a blob to work), and it doesn't
> include Widevine support by default. Actually the only one widely
> avariable function in Chromium is the Media Source Extension feature,
> but EME support is strictly limited to Widevine in the stable branch.
> 
> Exist a community of Chromium builds (which is focused mainly on
> Windows) that are really dedicated to offer vay editions of Chromium,
> since "Chrome-like" until "ungoogled".
> 
> The website is here >> https://chromium.woolyss.com/
> 
> On 2020-05-29 19:03, Megver83 wrote:
>> I think that one of the greatest problems with this is that users and
>> devs of FSDG distros are not joining forces, or better say: we are not
>> doing a coordinated effort to address this topic, but I think we all
>> know that. Coordinating efforts is in fact easier that how it sounds.
>> Someone (me? when I've the time, I'm super busy now, but just wanted to
>> share the idea) could create a GitLab/Gitea/Gogs repo (called
>> "chromium-fsdg-research" for example, and using sth. like Gitea give us
>> the ability to report issues in such project) with text files with all
>> of what we know about the issues related to Chromium, possible
>> solutions, and what is needed to solve this from once of all.
>>
>> Here I'd link (as a start point):
>> * useful Parabola issues
>> * useful Debian/PureOS issues
>> * FSF pages
>> * Chromium documentation
>> * *concrete known issues* (e.g. the non-free widevine extension[0]) with
>> references and elaborated explanation (not just "license is unclear" or
>> simplistic stuff)
>>
>> And one of the most important things: planning. My proposal for a plan
>> is to 1) collect and centralize all the needed info we can in this git
>> repo, 2) report the known issues in this repo's issue tracker, so we can
>> track the specific issues one by one, and look for a way to solve them,
>> for which we need to 3) invite experienced free software contributors
>> and programmers to actively participate in this project (looking for
>> issues and solving them), or anyone with the will and experience to help.
>>
>> The purpose with this is to create a distro-agnostic project to solve
>> the Chromium problem, so then each FSDG distro will implement the
>> solutions in their specific ways. I think that ppl from Parabola, PureOS
>> and the FSF/GNU project will be the most interested and active ones
>> (Trisquel is developed by one person only, and idk if Hyperbola devs may
>> even care about this, since they are very strict with their browsers'
>> security and Chromium isn't the most secure one)
>>
>> I'd like to know what do you think about this, and if you have another
>> idea or if you would change sth. of my proposal. This is just a draft of
>> an idea, if wanted to go more in detail I'd say, for example, that the
>> requirements for reporting an issue is to put the corresponding
>> references and proofs of that is being reported, or whatever. But first,
>> I want some feedback from the community, to see if there's some interest
>> in this, at least in Parabola :)
>>
>> [0]
>> https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/README.debian#L32
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@lists.parabola.nu
>> https://lists.parabola.nu/mailman/listinfo/dev



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

I get your point, and I understand it completely. For many (most?)
cases, the "use IceCat instead of Chromium" solution works. However,
I've encountered myself webpages that refuse to work with anything that
isn't Chrome (not pages that I use, but that some ppl of my family, e.g.
for business or working in projects) or some web platforms optimized for
Chromium (e.g. Jitsi, although it works in FF and derivatives, but not
completely well). Sometimes changing the user agent works, but not always.

I know this is a bit recherche, but it happens. Now, what you say about
electron, I completely agree. Just let it die. Regarding qt5-webengine,
I agree too, it's a smaller codebase and by liberating it we would
unblacklist hundreds of packages and solve many broken dependencies.
Plus, that would help PureOS too, and they could help us. Maybe we do
not need all the world's help, but we could do this a common effort
between Parabola, qt5-webengine devs and PureOS (if they want to join)

I liked this idea^ :)

El 29-05-20 a las 21:43, bill-auger escribió:
> regarding iridium/ungoogled, this has all been discussed before
> on the FSDG and FSD mailing lists - from what i remember,
> ungoogled is not a browser, but a set of patches - iridium is a
> browser which is made using the ungoogled patches - as we build
> everything from source, the two projects are probably identical,
> for the purpose of discussion
> 
> FWIW, people rarely even ask about chromium anymore - im not
> sure why you think it is worth rescuing - for all the massive
> effort it would take, it would be more practical to focus on
> 'qt5-webengine'
> 
> * it is a much smaller code-base, so less work to do
> * the qt5-webengine devs have expressed an interest in accepting
>   patches for any freedom bugs that are found
> * it would rescued most of the programs which are blacklisted
>   for this association with chromium
> 
> focusing on chromium would be much much more work to audit than
> qt5-webengine - electron is a hopeless cause; so all that
> extra effort would result in removing exactly one additional
> program from the blacklist
> 
> you are right that there is little collaboration of central
> discussion - this issue pops up on various lists from time to
> time - about two years ago, david and adfeno setup a wiki page
> on the FSD, for exactly the same purpose as this OP describes:
> "chromium-fsdg-research"; but it did not get any attention from
> any distro devs - about a year ago, oaken-source suggested on
> the FSDG mailing list, to focus on qt5-webengine rather than
> chromium, and again no one was interested - it is just too much
> work - no one wants to do it
> 
> the FSDG mailing list is the appropriate one to discuss
> this - that is unfortunately the FSDG mailing list is totally
> dysfunctional now, and the chromium quagmire is one of the
> central issues which broke it - i would not waste another moment
> wishing for cross-distro collaboration before that situation is
> fixed
> 
> sadly to say, even if this were conducted on the FSDG mailing
> list, parabola would be the only distro that would benefit from
> the result - the two FSDG distros which wanted chromium and
> webengine, chose to dismiss the concerns, rather than doing the
> work of auditing and liberating them, and added them to their
> repos anyways, against the recommendation of the FSDG work-group
> - the others have shown no interest at all
> 
> if only the *concrete known issues* are considered, then
> probably the ungoogled chromium solves them - that is quite
> irrelevant though; because the current FSDG recommendation for
> chromium is: "use icecat instead" - i would not want to add
> chromium of webengine to parabola before the FSDG work-group
> changes the recommendation - none of the FSDG should want to do
> that - it just makes the problem even uglier
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

El 29-05-20 a las 23:03, bill-auger escribió:
> On Fri, 29 May 2020 22:06:46 -0400 Megver83 wrote:
>> I've encountered myself webpages that refuse
>> to work with anything that isn't Chrome
> 
> i would not consider that to be our problem - that is a problem
> for those websites to address - if they do not want firefox
> users to use their website, then firefox users should not use
> their website - problem solved :)
> 
Not my problem too. I agree, in fact, just wanted to make a point. Not
really such a big deal anyways.

> 
> On Fri, 29 May 2020 22:06:46 -0400 Megver83 wrote:
>> Plus, that would help
>> PureOS too, and they could help us. 
>> Parabola (if they want to join)
> 
> why do you presume that? - pureos already has chromium and
> webengine in their repos - so liberating these programs would
> not help puroes - and it is hard to imagine people wanting to
> spend time on such a massive effort, which they do not believe
> is solving any problem at all
> 
do they suffer from a freedom issue then? because if they did like us,
they would at least filter it for prevention. Idk their criteria nor
Debian's Chromium (just that they apply like thousands of patches to
it), so I will ask them for details about how did they handle it (I was
reading some issues in their issue tracker, but they didn't have much info).

> i think you would first need to convince them, that it is a good
> idea to help the FSDG work-group reach a satisfying formal
> recommendation - that would go a long way toward restoring the
> credibility of the work-group - i sincerely wish that you could
> - i would like to see that problem resolved much much more than
> i care about chromium or webengine
> 
So then let's do it. Patience is a virtue :P

P.S: I'm cloning chromium from git, to explore its source. It's heavy as
hell!!! (16GB)



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

El 29-05-20 a las 21:58, Denis 'GNUtoo' Carikli escribió:
> As I see it, there are several approaches possible:
> - Replace Chromium by Gecko somehow. This will need to be done for
>   every API that uses chromium, like qt5-webengine, electron and so on.
>   The advantage is that we don't have the privacy issues of Chromium
>   and we can work with Mozilla upstream if needed. The disadvantage is
>   that people might not be able to work on it incrementally, which
>   lowers the probability of fixing it a lot, unless people want to
>   apply for funding to solve that and/or reserve big quantity of time
>   for it. This would work for every distribution almost automatically
>   and would probably be easy enough to package, especially if it lands
>   in various upstream projects (which require way more work than just
>   making that API compatibility).
Sounds interesting. Maybe too laborious, but since we are just in the
brainstorm step, we can consider it.

> - Starting from some existing Chromium version, like the one in GuiX,
>   and filling bugs and so on.
btw, who maintains it? just wondering, maybe its maintainers could lend
us a hand

> - As chromium is made of many and many components, it's probably
>   possible to package each component, but I wonder if there are
>   intermediate use case that would push people to want that and
>   maintain it when it will not be possible yet to build chromium from
>   such components. Skia is for instance used by other software than
>   Chromium as well, so maybe if it's built as a shared library it could
>   be useful for Iceweasel as well for instance.
Debian applies some interesting patches to Chromium, e.g. they separate
Widevine, leaving it as an optdepend. The more ppl who is involved the
better, in that way it will be easier to do a deep research, compared to
one or a few ppl doing it.

> 
> I've started a page about it here:
> https://libreplanet.org/wiki/Group:Software/research/Chromium
> 
> If it's not the right place to do that I can just delete the page. 
> 
> Note that anyone can create an FSF account, even non-members, and so
> everyone should be able to edit this wiki.
> 

Great, that's a good place to start collecting info. Maybe a warning
saying sth. like: "We are in the first steps of deep research for
Chromium, so the info here may not be completely correct or verified.
This is, for now, only a draft started by some Parabola devs" would be
good, just in case, and link this discussion as a reference, so anyone
who sees it knows how was it all started.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[Megver83]

I think that one of the greatest problems with this is that users and
devs of FSDG distros are not joining forces, or better say: we are not
doing a coordinated effort to address this topic, but I think we all
know that. Coordinating efforts is in fact easier that how it sounds.
Someone (me? when I've the time, I'm super busy now, but just wanted to
share the idea) could create a GitLab/Gitea/Gogs repo (called
"chromium-fsdg-research" for example, and using sth. like Gitea give us
the ability to report issues in such project) with text files with all
of what we know about the issues related to Chromium, possible
solutions, and what is needed to solve this from once of all.

Here I'd link (as a start point):
* useful Parabola issues
* useful Debian/PureOS issues
* FSF pages
* Chromium documentation
* *concrete known issues* (e.g. the non-free widevine extension[0]) with
references and elaborated explanation (not just "license is unclear" or
simplistic stuff)

And one of the most important things: planning. My proposal for a plan
is to 1) collect and centralize all the needed info we can in this git
repo, 2) report the known issues in this repo's issue tracker, so we can
track the specific issues one by one, and look for a way to solve them,
for which we need to 3) invite experienced free software contributors
and programmers to actively participate in this project (looking for
issues and solving them), or anyone with the will and experience to help.

The purpose with this is to create a distro-agnostic project to solve
the Chromium problem, so then each FSDG distro will implement the
solutions in their specific ways. I think that ppl from Parabola, PureOS
and the FSF/GNU project will be the most interested and active ones
(Trisquel is developed by one person only, and idk if Hyperbola devs may
even care about this, since they are very strict with their browsers'
security and Chromium isn't the most secure one)

I'd like to know what do you think about this, and if you have another
idea or if you would change sth. of my proposal. This is just a draft of
an idea, if wanted to go more in detail I'd say, for example, that the
requirements for reporting an issue is to put the corresponding
references and proofs of that is being reported, or whatever. But first,
I want some feedback from the community, to see if there's some interest
in this, at least in Parabola :)

[0]
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/README.debian#L32



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] do we need the [kernels], [cross], and [unmaintained] repos anymore?

[Megver83]

I agree. However, I'd like to keep the PKGBUILDs in [cross] from the
abslibre, since they are templates for creating cross-compilers, which I
use and maintain, unless we move them somewhere else.

El 23-05-20 a las 13:10, bill-auger escribió:
> the only packages in [unmaintained] are some browser themes -
> the mozilla sources install multiple default themes now - so
> even those few are probably not useful for anyone - im thinking
> we can just delete those PKGBUILDs from abslibre and eliminate
> all three of these repos
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] do we need the [kernels], [cross], and [unmaintained] repos anymore?

[Megver83]

tl;dr but I get the idea
I used to maintain linux-libre-xtreme, linux-libre-lts-xtreme,
linux-libre-rt and linux-libre-pae in [kernels], however, I removed all
of them, due to different reasons.

The point: IMO, [kernels] isn't needed. However, I've seen those kernels
you mention (linux-libre-x86_64 and others) which are maintained by
GNUtoo. I think I asked him once about their purpose, but I don't
remember if he ever answered me, or what was his answer.

[kernels] was, afaik, created by Emulatorman because he had a full
jungle of kernels, but now there are only a few, so in conclusion, I
think those kernels can be moved to [libre] and we can delete [kernels]

Regarding [cross], there used to be many outdated cross-compilers and
toolchains, which I deleted because it looked like no one was interested
on them, and no one has said anything since then. Afaik, it was used
when Parabola was ported to MIPS (or armv7? I don't remember), but
nowadays most custom toolchains go to [libre] (if they are makedepends
for a [libre] package, e.g. linux-libre-firmware) or to [pcr].

Now, about [unmaintained]: do we really need that? I mean, I totally
agree on adding it to PUR, if that can be created first, otherwise the
easiest thing would be to add those PKGBUILDs in "unmaintained" in
abslibre, but without building them, or maybe a new branch can be created?

El 23-05-20 a las 07:37, bill-auger escribió:
> i was just updating pbot's factoid about the available kernels -
> im not sure why any of these repo was ever needed really; but
> now there are only two packages in [i686/kernels] - both have
> not been updated since january - there is nothing for the other
> arches; and [cross] is empty for all arches
> 
> * i686/kernels/linux-libre-aarch64 5.4.8
> * i686/kernels/linux-libre-x86_64 5.4.8
> 
> i also noticed 'linux-libre-64' in [i686/libre] - that is more
> recent than the other new (undocumented) ones - is there any
> difference between 'linux-libre-64' and 'linux-libre-x86_64'? -
> and why are these only in the i686 repos?
> 
> * i686/libre/linux-libre-64 5.6.12
> 
> what is the use case for those foreign kernels? - are they
> experimental, or something we should document? - maybe its a
> good time to nail down the semantics of what goes in [kernels]
> and [cross]; or maybe decide if those specialty repos are any
> longer needed
> 
> the wiki is not very helpful for understanding their original
> intentions
> 
>   [libre]
>   "contains non-standard kernels such as "long term support with
>   stealth TCP sockets patches" kernels oriented towards servers,
>   or kernels compiled with AppArmor, TOMOYO, SMACK and SELinux
>   support"
> 
>   [cross]
>   "contains mostly-unsupported packages that contain tool-chains
>   for cross-compiling for a different architecture"
> 
> IMHO we do not want any permanently "unsupported packages" - we
> have the personal name-spaces for experimentation; and there is
> another repo which is named: [unmaintained] - though again i
> think there should not be any unsupported nor unmaintained
> packages in the system - a "PUR" PKGBUILD repos would serve that
> purpose better
> 
> we have discussed adding a something like a [build-tools] repo,
> for to hide 'pip' and other sharp kitchen utensils - maybe we
> could rename and re-purpose [cross] for that?
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Beefcake downtime

[Megver83]

El 17-05-20 a las 11:20, Luke Shumaker escribió:
> On Wed, 13 May 2020 02:35:23 -0400,
> bill-auger wrote:
>>
>> no need to apologize - beefcake has been an invaluable tool to
>> parabola for years
> 
> Is that literally true? :P Beefcake hasn't actually been around that
> long, it doesn't seem like.
> 
> Huh... November 2017.  I guess it has been years. :)
> 

Time flies. How are you doing, Luke? I see you haven't had much activity
since last year (at least in IRC and packaging).



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] new plan for managing 'icu' and 'poppler' dependent packages

[Megver83]

whenever icu upgrades, and iceweasel and friends break because of the
need of the previous version (and even some Arch pkgs, which don't
specify a version, just break), I install it from the AUR (e.g. the last
time I installed icu65, added icu=65 in "provides", and everything went
flawless)

idk if instead of making an icu-parabola pkg we better make a icuXX
(with "XX" being the previous version) for each needed version, although
I assume you want to do sth. similar with icu-parabola

El 05-05-20 a las 12:51, bill-auger escribió:
> as most people know, the dreaded icu-pocalypse has been a
> recurring bother for the parabola devs and user alike - gnutoo
> and eli have cooked up a new plan for an 'icu-parabola' package,
> to smooth the transition from one version of 'icu' to the next -
> the main advantage of this is that, in the future, people will
> no longer be blocked from upgrading, during the transition
> period - if it works out well, we will do the same for 'poppler'
> - denis will send an email later to explain more, once the
> logistics are nailed down
> 
> to go along with this, i have completed the task that freemor
> started on the bug tracker, to make tracking and managing the
> many rebuilds easier to grok - there are 6 special redmine
> tickets, with each dependent package as sub-tasks - we will be
> able to keep those 6 open always; and simply toggle each
> individual package tickets 'open' and 'fixed' as needed - the
> "STICKY" tag should make them easy to locate when needed
> 
> https://labs.parabola.nu/issues/2723 [STICKY][poppler]: and friends (armv7h)
> https://labs.parabola.nu/issues/2720 [STICKY][poppler]: and friends (i686)
> https://labs.parabola.nu/issues/2546 [STICKY][poppler]: and friends (x86_64)
> https://labs.parabola.nu/issues/2071 [STICKY][icu] and friends (armv7h)
> https://labs.parabola.nu/issues/2727 [STICKY][icu] and friends (i686)
> https://labs.parabola.nu/issues/2047 [STICKY][icu] and friends (x86_64)
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Libre package [linux-libre] marked out-of-date

[Megver83]

I'm building it right now

P.S: reported from an outlook address? really? ;)

El 26-04-20 a las 21:20, Parabola Website Notification escribió:
> eliotre...@outlook.com wants to notify you that the following packages may be 
> out-of-date:
> 
> 
> * linux-libre 5.6.5-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre/
> * linux-libre 5.6.5-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre/
> * linux-libre 5.6.5-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/
> * linux-libre-chromebook 5.6.5-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-chromebook/
> * linux-libre-docs 5.6.5-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-docs/
> * linux-libre-docs 5.6.5-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/
> * linux-libre-docs 5.6.5-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/
> * linux-libre-headers 5.6.5-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-headers/
> * linux-libre-headers 5.6.5-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/
> * linux-libre-headers 5.6.5-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/
> 
> 
> The user provided the following additional text:
> 
> Linux-libre kernel has been updated into the version 5.6.7 in upstream branch.
> 
> https://pod.libreplanetbr.org/posts/961118
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Which packages go in which repositories?

[Megver83]

In my case, whenever I build a package which does not correspond to
[libre], I put it in [pcr]. Now, you may ask, what goes in [libre]? In
my case, besides the obvious stuff (libre replacements) I also upload
dependencies of [libre] packages (e.g. linux-libre-firmware
cross-compilers), and you can also see Parabola's developers tools and
related stuff.

I've also faced that issue, build Arch packages for ARM which aren't in
ALARM, and in that case I put them in [pcr], because they're not a
[libre] replacement and aren't needed by any [libre] pkgs, at least for ARM.

El 15-04-20 a las 22:17, Denis 'GNUtoo' Carikli escribió:
> Hi,
> 
> I want to build a Xonotic package for Parabola ARM, that I then upload
> using librerelease, in order to make it available to everyone.
> 
> So I was suggested by Bill Auger to either convince archlinuxarm to
> built it for me, or to add the Xonotic PKGBUILD in pcr.
> 
> As before the discussion I thought that the PCR repository was meant
> for PKGBUILDs that would be imported from AUR and potentially modified,
> and not for packages that don't fit in all other repositories, it
> triggered a discussion on which packages should go where.
> 
> I was asked to start a thread about that on the mailing list.
> 
> According to Bill Auger, there is also different understanding of what
> should go in libre.
> 
> Denis.
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Recommendations to avoid WebRTC leak in Iceweasel/Icecat

[Megver83]

Hi everyone. As you may know, Iceweasel recently has enabled WebRTC by
default, and afaik Icecat already had it enabled. However, maybe not
everyone may use it in these times, or simply want to keep it disabled
to avoid the know IP leak, without having to change the
media.peerconnection.enabled option every time you're going to use Jitsi
or similar software, like me.

For that reason, I wanted to share an addon I've found which is like a
Swiss knife for privacy. It lets you enable/disable WebRTC (the main
reason I'm sharing it to you), override the user agent (and set a time
interval to periodically change it), spoof many things (among my
favorites, screen resolution spoofing, which is sth. that Tor Browser
does by default), and much more. I'm talking about Chameleon[0], maybe
some of you may know it, it's the WebExtension port of Random Agent Spoofer.

If you want to verify your IP is "leakable", check it here[1][2]

Hope this is useful to you!

[0] https://github.com/sereneblue/chameleon
[1] https://browserleaks.com/ip
[2] https://browserleaks.com/webrtc



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [REQUEST] adding wine to nonsystemd-multilib

[Megver83]

some [nonsystemd-multilib] pkgs depends on lib32-eudev, which is in
[pcr-multilib], but I'll move it to [nonsystemd-multilib] soon

Remember to have [nonsystemd] above all other repos and [nonsystemd-
multilib] above all multilib repos in pacman.conf, so that pacman
prioritizes their pkgs

If you have it correctly set up, when running pacman -Sy the repos
should be ordered like this:

:: Synchronizing package databases...
 nonsystemd is up to date
 nonprism is up to date
 libre is up to date
 core is up to date
 extra is up to date
 community is up to date
 pcr is up to date
 nonsystemd-multilib is up to date
 libre-multilib is up to date
 multilib is up to date
 pcr-multilib is up to date

El vie, 03-04-2020 a las 12:27 +, leestro...@disroot.org escribió:
> I didn't have [nonsystemd-multilib] and [pcr-multilib] enabled in my
> pacman.conf. I enabled those, as Megver suggested and wine installed
> fine (x86, OpenRC).
> 
> Regards,
> 
> Lee
> 
> 
> April 3, 2020 8:25 AM, join...@cock.li wrote:
> 
> > finally I managed to get it installed with these steps:
> > 
> > - enable [nonsystemd-multilib] ([pcr-multilib] I miss this repo)
> > [multilib] repos
> > 
> > - install nonsystemd-multilib/lib32-dbus package
> > 
> > - install pcr-multilib/lib32-eudev
> > 
> > - install nonsystemd-multilib/lib32-libusb
> > 
> > - install wine
> > 
> > this how I managed to install but I think maybe if I enable Pcr-
> > Multilib before it will
> > work out of the box but I am not sure and next time I should post
> > in assist mailing list
> > first.


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [REQUEST] adding wine to nonsystemd-multilib

[Megver83]

This is strange. I can install wine without issues. Do you have
[nonsystemd] and [nonsystemd-multilib] above all the other repos in
pacman.conf?

El jue, 02-04-2020 a las 20:23 +, leestro...@disroot.org escribió:
> The conflict between dbus and lib32-dbus is one I reported a couple
> of weeks ago:
> 
> https://labs.parabola.nu/issues/2659
> 
> I wouldn't recommend removing dbus, as it is required by many other
> packages (as your printout shows).
> 
> Lee (Time4Tea)
> 
> 
> April 2, 2020 4:18 PM, join...@cock.li wrote:
> 
> > to give more information about the satiation here is my log
> > 
> > $ sudo pacman -S wine
> > resolving dependencies...
> > looking for conflicting packages...
> > :: lib32-dbus and dbus are in conflict (libdbus-1.so). Remove dbus?
> > [y/N] y
> > :: lib32-systemd and your-initfreedom are in conflict. Remove your-
> > initfreedom? [y/N] y
> > error: failed to prepare transaction (could not satisfy
> > dependencies)
> > :: unable to satisfy dependency 'dbus' required by lib32-dbus
> > :: removing dbus breaks dependency 'dbus' required by a2jmidid
> > :: removing dbus breaks dependency 'dbus' required by ardour
> > :: removing dbus breaks dependency 'dbus' required by at-spi2-core
> > :: removing dbus breaks dependency 'dbus' required by avahi
> > :: removing dbus breaks dependency 'libdbus-1.so=3-64' required by
> > avahi
> > :: removing dbus breaks dependency 'dbus-openrc' required by avahi-
> > openrc
> > :: removing dbus breaks dependency 'dbus' required by bluez
> > :: removing dbus breaks dependency 'dbus' required by colord
> > :: removing dbus breaks dependency 'dbus' required by dbus-glib
> > :: removing dbus breaks dependency 'dbus' required by dleyna-
> > connector-dbus
> > :: removing dbus breaks dependency 'dbus' required by elogind
> > :: removing dbus breaks dependency 'libdbus-1.so=3-64' required by
> > fluidsynth
> > :: removing dbus breaks dependency 'dbus' required by ghostscript
> > :: removing dbus breaks dependency 'dbus' required by libpcap
> > :: removing dbus breaks dependency 'dbus' required by libproxy
> > :: removing dbus breaks dependency 'dbus' required by libpulse
> > :: removing dbus breaks dependency 'libdbus' required by libteam
> > :: removing dbus breaks dependency 'dbus' required by libvirt
> > :: removing dbus breaks dependency 'libdbus' required by
> > notsystemd-common
> > :: removing dbus breaks dependency 'libdbus-1.so=3-64' required by
> > pipewire
> > :: removing dbus breaks dependency 'dbus' required by python-dbus
> > :: removing dbus breaks dependency 'dbus' required by python2-dbus
> > :: removing dbus breaks dependency 'dbus' required by quota-tools
> > :: removing dbus breaks dependency 'dbus' required by rtkit
> > :: removing dbus breaks dependency 'libdbus' required by
> > wpa_supplicant
> > :: removing dbus breaks dependency 'dbus' required by xorg-server
> > :: removing dbus breaks dependency 'dbus' required by zbar
> > 
> > then I try to install nonsystemd-multilib/lib32-dbus but pacman
> > still
> > tell me to install lib32-systemd.
> > 
> > And then I try to install wine deps before installing it but pacman
> > tell
> > me again to install lib32-systemd and remove yourinitfreedom.
> > 
> > Since artix have their own PKGBUILDS for wine instead of taking
> > them
> > from arch I think there is a difference.
> > 
> > Thank Megver83 for the reply>
> > ___
> > Dev mailing list
> > Dev@lists.parabola.nu
> > https://lists.parabola.nu/mailman/listinfo/dev
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [REQUEST] adding wine to nonsystemd-multilib

[Megver83]

"not available for OpenRC users"

what is that? OpenRC users can also do `pacman -S wine' too. Wine
doesn't need systemd by default. Not all Artix packages are modified,
only the ones that need systemd, which is not the case of wine

El jue, 02-04-2020 a las 22:22 +0300, mr.fantastic escribió:
> hi,
> 
> I have noticed that wine in not available for OpenRC users and I
> noticed
> as Megver83 says he look at artix I searched and get the package
> builds
> at that link:
> https://gitea.artixlinux.org/artixlinux/community/src/branch/master/wine
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] accountsservice package build problem

[Megver83]

I added nonsystemd/accountsservice yesterday to replace
pcr/accountsservice-elogind, with the latest version.

fyi, whenever I build packages in [nonsystemd], I use Artix's PKGBUILDs
as a base, because they enable elogind by default when it's available,
remove systemd's units and sometimes they apply patches if necessary.

https://gitea.artixlinux.org/artixlinux

El mar, 31-03-2020 a las 23:24 +0300, mr.fantastic escribió:
> hi,
> 
> I am trying to build accountsservice-elogind after changing the
> commit
> to the latest stable tag then i found that they converted from
> autotools
> to meson so i copied the PKGBUILD from arch to know how they build it
> and then disable systemd but even if i disable it the meson
> systemdunits
> options does't disabled.
> 
> my question is how can i disable string option in meson i lookup the
> documentation but i didn't found the solutions if anyone have
> experience
> with meson can tell us.
> 
> anyway what i do in the attached file is that i remove lines that use
> the
> string variable with sed.
> 
> happy hacking,
> mr.fantastic
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Creation for a new wiki user

[Megver83]

Hi, I want to create a wiki user for mai (read here[0] to get in
context). However, I'd like to know how can I create users (from
winston?).

And regarding the wiki page openness, do we still need registrations to
be closed? I remember the spam attack problem, but haven't anyone got a
solution? a captcha or sth. like the typical "what is the output of
"?

[0] https://labs.parabola.nu/issues/2372#note-42


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] New installation images

[Megver83]

El vie, 31-01-2020 a las 04:50 -0500, bill-auger escribió:
> parabolaiso should work as expected with the simple commands
> noted in the README - with the 'master' branch (or the
> 'parabolaiso' package), it may only be possible to build openrc
> ISOs; but im not certain

Just for the record, I successfully built and tested the
TalkingParabola ISO (it's now updated in the downloads, since it didn't
got an update since 2017), which uses systemd. I haven't tested releng
but it's 99% likely to work.

The openrc profiles are almost the same, just change the init system,
EFI boot manager (from systemd-boot to refind) and some other little
things in the airootfs files (like adding some files to replace their
systemd analogs, and enabling NetworkManager in customize_airootfs.sh)


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] A10 OLinuxino Lime not booting

[Megver83]

El vie, 31-01-2020 a las 02:14 -0500, bill-auger escribió:
> i glossed over this message because of the title
> 
> a few months back, olimex released a new post proudly
> proclaiming that parabola works well on it - this just shows how
> difficult these ARM devices are to support, especially if none
> of us actually have one
> 
> ideally megver would have one of each, including a C201 - i
> think the olimex lime board is one that we should target
> specifically - maybe we should ask olimex if they would gift us
> one

Ideally, but the only thing we've for now are our testers. I remember
that a long time ago a user offered to donate an EOMA86, and after some
talk he said he was going to send it to me, but nothing happened :/

However, I see more hope in olimex since, as you said, they proudly
proclaim parabola as a working OS for their SBC. A good excuse to ask
for one is having it so we make sure Parabola remains working in such
device.

P.S: This last week I've got some money from Liberapay donations
through paypal which is almost the half of the price of the C201. If I
get enough from the donations I will inmediately buy a C201.


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] New OpenRC ISOs releases

[Megver83]

I've recently released new OpenRC (CLI and LXDE) ISOs. See the download
page to get them. Main changes are:

* In LXDE ISO:
  - some improvements in language selection scripts
  - replaced iceweasel with midori (it's lighter and less problematic
in i686)
  - replaced icedove with evolution (less problematic in i686, and
icedove has this issue: https://labs.parabola.nu/issues/2267)
* Both:
  - replaced pacman-init initscript with etc/local.d/pacman-init.start
* Changes to parabolaiso ('master' branch):
  - updated customize_airootfs.sh script
  - do the uefi-shell checksum more elegant (build.sh)
  - mkparabolaiso: remove runit support (dropped from [pcr])
  - mkparabolaiso: install linux-libre in the base installation

Also wanted to comment that I thought on replacing the LXDE
installation scripts with something better and up-to-date. They
currently use dialog to display a ncurses menu which does the job, but
after some research I discovered Revenge Installer[0], and forked it[1]
(I haven't done any change currently, this is part of my TODO for
future LXDE ISOs).

This script LGTM, it uses zenity and it's simple. I haven't run it but
watched some videos and looks like a promising replacement for our
current dialog installer, which honestly idk who uses it.

Any comments or recommendations are always welcomed, just avoid writing
me a 1000+ lines email, otherwise I might not read it completely :)


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Getting Linux-libre working in the C201

[Megver83]

Hi everybody, I recently uploaded linux-libre-cros in [libre-testing],
which is a deblobbed version of the ChromiumOS kernel[1]. I did this
because that's what Paul Kocialkowski suggested once [2], and none of
the actual kernels work correctly in the C201, read more in #2372 [3]

Any important feedback about if it's working or not, with logs and
info, post it in the tracker, and any doubt, discussion or
recommendation, ask it here (e.g. things like "how do I XXX?" or
"should we XXX?"). *Also*, if some hardware doesn't work with this
kernel or have another non-critical problem, but you can sucessfully
boot it, DO NOT (yet) post any issue related to linux-libre-cros since
it is an experimental kernel. You can, instead, post them here so I try
to solve them before getting it in [libre].

Temporary git repo with deblobbed CrOS kernel, if anybody is interested
(version 5.4.2 as of now): 
https://gitlab.com/libreforks/linux-libre-cros

[1] https://chromium.googlesource.com/chromiumos/third_party/kernel
[2] https://lists.parabola.nu/pipermail/dev/2016-April/003940.html
[3] https://labs.parabola.nu/issues/2372


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Let's talk about Infrastructure and Hosting

[Megver83]

El dom, 17-11-2019 a las 01:26 +0100, Andreas Grapentin escribió:
> Hi,
> 
> it's been almost two weeks since the first announcement was made, and
> I
> believe we have now a good understanding of our infrastructure and
> our
> hosting needs, and are ready to move forward.
> 
> We have discussed internally, and have come to the conclusion that a
> good course of action could be to keep winston running, but start
> migrating some of the essential services off it one by one,
> streamlining
> their deplopment in the process.
> 
> To get started, we are currently looking at getting a single VPS,
> with
> specs comparable to, or slightly improved upon, the specs of winston
> itself.
> 
> Winston currently has:
> 
>  - (nominally) about 4GiB of RAM.
> 
>we believe that 4GiB is currently the lower bound of what our
>services need to function. Winston is currently struggling with
> RAM,
>but this seems to be mainly because he's not having the nominal
>amount actually available for use.
> 
>To get some room to breathe, we're hoping for an upgrade here
> towards
>the region of 6 or 8GiB of ram, mainly to make sure the machine
>doesn't need to swap as much as it does now.
> 

+1

>  - 4 QEMU virtual CPUS @ 2.2GhZ
> 
>winston is never really computationally busy. iirc, vikings is
>allowing only for 1 CPU VPS's (please correct me if I'm wrong) so
>we're not looking for an upgrade here. Realistically, anything
> that's
>not a potato should be sufficient to deal with our workload.
> 

+1

>  - 500GiB of storage
> 
>storage is getting a bit tight. We are planning to extend our
> repos
>to more architectures, chiefly ppc64le and riscv64, and we would
> not
>be able to host all the built packages due to limited storage
>capacity.

Regarding the ppc64le and riscv64 ports, we have to discuss that
because we need more people for this *unless* we set up a functional
autobuilder for all our packages in a very capable machine (mainly
because there are some *very heavy* software). We can create a git repo
for modified PKGBUILDs like Arch32 and ALARM do, but for testing these
in real hardware (because IMO it's useless to waste time in porting to
architectures that are only going to be used in VMs or emulators) we
need testers (could be some Parabola devs with this hardware or very
collaborative users that own it). Plus, some packages won't cross-
compile using qemu (like libretools does with armv7h), which is sth.
that has happened to me with some armv7 pkgs, so I build them in my
Banana Pi and works.

Idk how will we do for ppc64le, because the TALOS II is too expensive,
but there are other PPC computers (I'm digging a bit about them, I
already know the discontinued PowerMacs from Apple but I want to find
something more)

> 
>Ideally, we would like to see an extended capacity of at least
> 1TiB
>here, in order to work towards our medium-term goals. Even more
>storage would allow us to move forward with other projects, such
> as
>providing a source packgaes repository, or maintaining a larger
>archive of older packages. But we can discuss these separately
> once
>the respective projects move forward.
>  - virtually unlimited network traffic
> 
>as far as I know, winston is not limited in terms of network
> traffic.
>And we do incur a LOT of network traffic. The order of magnitude
>should be somewhere in the single-digit TiB's per month, although
>it's hard to be sure since we don't have a monitoring in place.
> 
>Most of this traffic is because of a growing number of busily
> syncing
>parabola mirrors, and we could cut that down by better structuring
>our network of mirrors, and giving that more of a hierarchy
> instead
>of having everyone pull from the root.
> 
>We should talk to the vikings people here, what sort of traffic is
>allowed on their network, to get a feeling how much we need to cut
>down here. Also, we should start putting better traffic monitoring
> in
>place.
> 
> So much for the rationale. In summary, we believe that we currently
> need
> a single VPS with:
> 
>- a single core
>- at least 8GiB of RAM
>- at least 1TiB of storage
>- a reasonable agreement on traffic limits
> 
> If I have missed or forgot anything, let me know. Otherwise, we
> should
> probably get the vikings people in the loop and discuss next steps!
> 
> Best,
> Andreas (oaken-source)
> 
> 
> 
> On Tue, Nov 05, 2019 at 11:28:36PM +0100, Andreas Grapentin wrote:
> > Hi,
> > 
> > As you know, a good chunk of the infrastructure that makes parabola
> > is
> > currently hosted on a virtual machine called winston, which is
> > generously provided by the hosting provider 1984. We used to have
> > proton
> > as well, but when that died, the things that it hosted were
> > migrated
> > over to winston.
> > 
> > It's come to our attention that this machine is currently
> > struggling to
> > cope with the load it 

Re: [Dev] arch replaced the 'base' package group with a leaner 'base' meta-package

[Megver83]

El lun, 11-11-2019 a las 21:32 -0500, bill-auger escribió:
> re:
>  why are we discussing adding a base-extra
> metapackage / group? Isn't that something upstream should be
> doing?
> 
> i think they are discussing it - my reason to propose it now is
> that currently, `pacstrap base` no longer installs a working
> system - even if we fix the init-system conflicts, one still must
> `pacstrap base linux-libre` at the bare minimum to get a working
> system (and a boot-loader too) - in order to get an equivalent
> system as what the base group once installed, that pacstrap
> command would need to include all of the packages in my previous
> post
> 
> if thats the way it is going to be then the documentation could
> be updated; but it would be quite ugly indeed - my interest is
> raising this topic now, is that i also need to add that mess to
> calamares and parabolaiso; and if this is a temporary situation
> (if arch does add a 'base-extras' package), then i will need to
> revert that anyways - so much simpler to add a 'base-extras'
> package now - it would be a harmless optional thing, so i dont
> see any reason not to do it - even if it helps only the
> installers - the thing to discuss is what packages should go in
> it
> 
> probably a better name would be 'parabola-full' or something
> similar - i would also like to add a 'parabola-desktop' for the
> same reason - as it is now, i am maintaining the package lists
> for the installers in three different places; which is kinda
> tedious to manage - those are: the package lists for what goes
> on the various live systems, the package lists for the ncurses
> installers, and the package lists for calamares - it would be
> very good to consolidate those; and a good way to manage that is
> with meta-packages + 'provides'
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev

I would wait to see what upstream does, but things like parabola-
desktop (which Arch isn't likely to get sth. like that) could be added
without problem. I saw some archiso commits and they had to update
their package lists because of this new base metapackage thing, so
maybe base-extras would not kill anyone, I feel like this new adoption
of base metapkg with less pkgs that the ex base group gives users more
flexibility in terms of which pkgs they want to install. For example,
nano was in base group, but what about ppl who doesn't use it? it
doesn't really belong to a very base installation, and here is my
favorite part: you want it? then install it yourself, and that's the
Arch philosophy, *do it yourself*

___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [armv7h] DO NOT update to mkinitcpio v27 yet

[Megver83]

New mkinitcpio v27 introduces some changes that may lead to unwanted
issues in armv7h. In x86_64 and i686 it doesn't, but newer kernel
versions may require you to reinstall mkinitcpio. Im working in a patch
for making it work in armv7h, but it may take some time. I'll possibly
make an announcement in the news about this, with more detail.

Sorry for not explaning this problem too deeply, but I'm working hard
to get the solution as soon as possible.


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] arch replaced the 'base' package group with a leaner 'base' meta-package

[Megver83]

El lun, 28-10-2019 a las 11:39 -0400, bill-auger escribió:
> there is an open ticket about this on redmine[1] because it was
> immediately clear that some action would be required - there is
> still much to discuss though in regards to how they should be
> done; and the mailing list is the best venue to discuss things
> that are yet to be decided
> 
> so i am staring this thread to avoid using the bug tracker as a
> discussion forum, and for the benefit of list subscribers;
> so that the user community and inactive devs can be "in the loop"
> 
> let us try to have the general discussion via email amd reserve
> the bug tracker for specific work items which are decided to be
> done and how
> 
> [1]: https://labs.parabola.nu/issues/2506
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev

Well, regarding that, we should remove the your-* packages from the
base and base-openrc groups


signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Take advantage of the latest and comfortable innovation in chronic pain relief! Today!

[Megver83]

What is this spam doing here?

El dom, 13-10-2019 a las 06:07 -0400, 100% Natural Pain Relief
escribió:
> 
> 
> Are you ready to say goodbye to your chiropractors and medicines?
> 
> SoniPad is an innovative device that helps to reduce muscle pain for
> shoulder, arms, belly, legs and most of the body parts. It is high
> time you stop using too much medication with side effects in order to
> reduce muscle pain. SoniPad with its electrical nerve stimulation
> will make your life much easier in a completely natural process.
> 
> Features :
> 
> Uses natural process of transcutaneous electrical nerve stimulation
> (TENS) therapy
> Adjusts easily to painful body regions with no straps or wire
> Easy, portable and convenient; uses a USB port for charging
> Reliefs muscle stiffness, pain and aches of all body parts
> View Offer >>
> 
> 
> 
> If you does't like this update, no problem please Click here
> 4428 Bernardo Street Salem, IN 47167
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 246_dbd It may take decades to know the full extent of the damage
> done by vaping, although Jani thinks we shouldn’t wait that long. “It
> took us more than 20 years to realize that cigarette smoking is
> injurious to health,” he said. “We are repeating the same mistake
> right now.” Young people at risk from vaping While vaping products
> aren’t completely harmless, they appear to be safer than smoking.
> Cigarette smoke contains a much larger number of toxins and cancer-
> causing chemicals than e-cigarette vapor. “If a patient who is a
> heavy smoker transitions to e-cigarettes and then quits altogether,
> there is some benefit,” Kanaan said. However, he’s also concerned
> about people who give up cigarettes but continue to vape. “We don’t
> have all the data to know what exactly is being delired and how those
> chemicals are affecting the lungs,” he said.
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev

___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Thanks for supporting armv7 arch

[Megver83]

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@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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Kernels package [linux-libre-xtreme] marked out-of-date

[Megver83]

El 23-09-19 a las 11:49, Freemor escribió:
> On Mon, Sep 23, 2019 at 12:55:07PM -, Parabola Website Notification wrote:
>> robi...@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@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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH] libremakepkg: fix building packages requring a rw startdir

[Megver83]

El 19-05-19 a las 04:33, bill-auger escribió:
> the log message for the commit that introduced this change indicates that it 
> was necessary for some reason - i think it would be hasty to revert this 
> until we know what the trade-off would be
> 
>   "- We mount the temporary directory containing the extracted source package 
> files read-only, to be sure that makepkg doesn't modify the PKGBUILD. This is 
> necessary because --holdver only disables pkgver() if it's a VCS package."
> 
> right now, i think the only packages that are broken by this are the kernels 
> - there is a single command that requires a writable /startdir, and it does 
> not appear to have any value whatsoever - all that it does is write the 
> 'pkgbase' into the .install script - 'pkgbase' will never change, so that 
> could and should be hard-coded into the .install script - i suggest this 
> change to the kernels PKGBUILDs instead
> 

Well, (as I said in IRC and the bug tracker) I'm not having this issue
with the [nonsystemd] libretools. I'll reverts these changes hence in
some moment

> 
> --- a/linux.install
> +++ b/linux.install
> @@ -7,8 +7,6 @@
>  }
>  
>  post_remove() {
> -  rm -f boot/initramfs-%PKGBASE%.img
> -  rm -f boot/initramfs-%PKGBASE%-fallback.img
> +  rm -f boot/initramfs-linux-libre.img
> +  rm -f boot/initramfs-linux-libre-fallback.img
>  }
> -
> -# vim:set ft=sh ts=8 sts=2 sw=2 et:
> 
> 
> --- a/PKGBUILD
> +++ b/PKGBUILD
> @@ -10,7 +10,7 @@
>  # Based on linux package
>  
>  pkgbase=linux-libre # Build stock kernel
> -#pkgbase=linux-libre-custom # Build kernel with a different name
> +#pkgbase=linux-libre-custom # Build kernel with a different name (ASSERT: 
> hard-coded into linux.install)
>  _srcbasever=5.1-gnu
>  _srcver=5.1.3-gnu
>  
> @@ -225,10 +225,6 @@
>"
>fi
>  
> -  # hack to allow specifying an initially nonexisting install file
> -  sed "$subst" "$startdir/$install" > "$startdir/$install.pkg"
> -  true && install=$install.pkg
> -
># fill in mkinitcpio preset and pacman hooks
>sed "$subst" ../linux.preset | install -Dm644 /dev/stdin \
>  "$pkgdir/etc/mkinitcpio.d/$pkgbase.preset"
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] I am starting a review into whether QtWebEngine is free software

[Megver83]

El 16-04-19 a las 04:45, Andreas Grapentin escribió:
> 
> Hello Everyone,
> 
> You have read the subject line of this email, so you know what's up.
> 
> =
> What is the situation?
> =
> 
> As you all know, in the past, the freedom of QtWebEngine has been
> questioned repeatedly, to the point that parabola (and I believe most if
> not all the FSDG compliant distributions) was forced to remove it from
> its official repositories.
> 
> As a consequence, many programs that directly or through their
> dependencies depend on QtWebEngine needed to be blacklisted as well, or
> be modified to use the -- arguably outdated -- QtWebKit instead. At the
> moment, this impacts dozens of packages on parabola, which takes away
> from the experience of the distributions users. It also creates a
> considerable amount of work for the us maintainers to keep the modified
> programs up to date, which gets increasingly difficult as the developers
> move away from QtWebKit.
> 
> =
> What is the plan?
> =
> 
> What I am now trying to do is organize the existing allegations made
> against QtWebEngine, and conclusively determine whether or not
> QtWebEnigne is free software, and if it is deemed to not be entirely
> free, what steps need to be taken towards liberating it and towards
> creating a version of QtWebEngine that can be packaged and distributed
> by FSDG compliant distros.
> 
> I will *not* be investigating whether Chromium is free software, at
> least not right now. This review is only for QtWebEngine, and the subset
> of chromium that it embeds.
> 
> =
> Do you want to help?
> =
> 
> If you want to help me out, please forward me any existing allegations
> against QtWebEngine that I might have missed. I want this review to be
> conclusive, and it can only be complete if all complaints are
> sufficiently addressed.
> 
> If you want to get involved more actively, I am currently in the process
> of setting up a local fossology instance, but I could easily set up a
> public instance for a collaborative investigation instead. I am also
> setting up a git repository to organize the results of the review. If
> you want to get access to any of these, let me know.
> 
> 
> Come find me in #parabola on freenode for a chat.
> 
> 
> Best,
> Andreas Grapentin (oaken-source)
> 
> for the parabola GNU/Linux-libre distribution.
> 
> 
> --
> 
> --
> my GPG Public Key: https://files.grapentin.org/.gpg/public.key
> --
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 

Great! would be good to also see someone from other free distro or
GNU/FSF working with you. Pitifully, because of time, I can't help now

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] qemu-user-static updated to 3.1.0

[Megver83]

El 16/02/19 a las 19:19, Luke Shumaker escribió:
> On Mon, 11 Feb 2019 17:12:18 -0500,
> Andreas Grapentin wrote:
>> Remember that you need to recreate the chroot, for the update to take
>> effect.
> 
> I don't think that's true.  I think it should copy in the qemu binary
> every time it enters the chroot.
> 
I can confirm this, because librechroot runs arch-nspawn with the -f
$interpreter flag which copies the file inside the chroot


/bin/librechroot:73:local setarch interpreter
/bin/librechroot:75:armv7h) setarch=armv7l;
interpreter=/usr/bin/qemu-arm-static;;
/bin/librechroot:76:*)  setarch=$CARCH;
interpreter=/usr/bin/qemu-$CARCH-static ;;
/bin/librechroot:83: -e "interpreter $interpreter" \
/bin/librechroot:88:plain 'This requires a
binfmt_misc entry for %s.' "$interpreter"
/bin/librechroot:97:arch_nspawn_flags+=(-f "$interpreter" -s)

Usage: arch-nspawn [options] working-dir [systemd-nspawn arguments]
A wrapper around systemd-nspawn.  Provides support for pacman.

 options:
-C  Location of a pacman config file
-M  Location of a makepkg config file
-c   Set pacman cache
-f  Copy file from the host to the chroot
-s    Do not run setarch
-hThis message


-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] systemd-libs package issue

[Megver83]

I've reported the issue here -> https://labs.parabola.nu/issues/2177

Basically the problem is that this new package conflicts libudev
providers, systemd-libsystemd and systemd-nss-* pkgs and we must find a
solution.

I'm writing here because idk really to who should I assign the issue
since afaik lukeshu has been absent for a while, and I've seen other ppl
working with systemd, but I did assign the report to him.
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [linphone] marked out-of-date

[Megver83]

El 04/12/18 a las 11:42, Parabola Website Notification escribió:
> grizzlyu...@protonmail.com wants to notify you that the following packages 
> may be out-of-date:
> 
> 
> * linphone 3.12.0-1 [pcr] (armv7h): 
> https://parabolagnulinux.org/packages/pcr/armv7h/linphone/
> * linphone 3.12.0-1 [pcr] (i686): 
> https://parabolagnulinux.org/packages/pcr/i686/linphone/
> * linphone 3.12.0-1 [pcr] (x86_64): 
> https://parabolagnulinux.org/packages/pcr/x86_64/linphone/
> 
> 
> The user provided the following additional text:
> 
> Although some links on their website and in GitHub mirror show the version 3 
> is still latest, it seems they are not creating tags and there is new version 
> 4:
> 
> http://www.linphone.org/news/55/26/Linphone-4-0-for-desktop-platforms-is-available.html
> http://lists.nongnu.org/archive/html/linphone-developers/2017-06/msg00046.html
> 
> Also available in the AUR:
> https://aur.archlinux.org/packages/linphone-desktop-all/
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
I know about this, in fact I tried to upgrade it some months ago, but
the building failed

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] From Iceweasel to Abrowser

[Megver83]

El 28/11/18 a las 14:18, Distopico Vegan escribió:
> 
> Hi, Maintain a package is hard work, mostly for the time, I think is a good 
> idea join efforts to keep an updated free/libre version of Firefox, so one 
> possibility is to keep an upstream version of Abrowser and helps to the 
> maintenance of Abrowser, Abrowser keep updated and is a good option, is only 
> a idea, please consider it.
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
This was already discussed last year, if i'm not mistaken

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Issues with your-initfreedom

[Megver83]

El 31/10/18 a las 15:07, José Alberto escribió:
> Hi,
> 
> New parabola user here, after several years on Arch. I installed
> parabola using the openrc cli complete iso. After that, I added
> nonsystemd repo and tried to install your-initfreedom. It says that it
> conflics with {,lib}systemd-dummy, but those are required for essential
> things like, for example, device-mapper. Also, they are dummy empty
> packages. Isn't this a bug in your-initfreedom package? I can patch it,
> but I'd need some guidance. If it's not a bug, how can I solve it?
> 
> Thanks!
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
Sorry for being late. I've been very busy during October.

I fixed this and closed #2013 https://labs.parabola.nu/issues/2030#note-3

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [FSF][PPC] Fwd: [gnu.org #1326235] Parabola: a future libre PowerPC distro

[Megver83]

Hi guys, I've written to the FSF about the Parabola PPC port. This is
something that has been developed and discussed (in IRC mainly) by
oaken-source, ebrasca, ovruni, lukeshu and me. We already have some
packages in our repos, and already ported the -any packages. Some of the
next goals are: create a feature-rich autobuilder, get more hardware to
test it, make Parabola to have full support over this architecture and
write the installation guide for it.

Ppl at the FSF are now asking for more details (see the forwarded email
below), and unfortunately I do not have time right now to answer them
(AFAIK oaken-source neither), so if any of you devs (lukeshu, ovruni,
ebrasca, or someone else who has worked in this) can help, please.

 Mensaje reenviado 
Asunto: [gnu.org #1326235] Parabola: a future libre PowerPC distro
Fecha: Fri, 26 Oct 2018 20:35:37 -0400
De: John Sullivan via RT 
Responder a: campai...@fsf.org
Para: megve...@parabola.nu

Hi David,

I've added our tech and licensing teams to this ticket, and included
your full message below for their context. Can you share more detail
about where things are at, what the goals are, and what we might be able
to do to help?

-john

On Mon Oct 01 11:00:34 2018, megve...@parabola.nu wrote:
> Hi, I'm David, a Parabola GNU/Linux-libre developer. I'm writing to you
> because, as far as I know, the FSF is interested in a libre PowerPC distro.
> 
> At Parabola we are working on it. One of our developers has a TALOS II
> and it already boots Parabola *but* it is still under heavy development.
> 
> I don't know if this is the right address to which I should write, if
> not please redirect me to the corresponding place.
> 
> We would like your help, in anything that you can, like infrastructure
> for a build server, volunteers for packaging, etc. so if we can discuss
> it maybe in a mailing list, it would be awesome.
> 
> Thanks.


-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at





signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Massive package breakage on i686 (missing libraries)

[Megver83]

El 24/10/18 a las 20:55, Denis 'GNUtoo' Carikli escribió:
> Hi again,
> 
> On Wed, 24 Oct 2018 17:23:14 +0200
> Denis 'GNUtoo' Carikli  wrote:
>> - unar (1.10.1-8.2)
> The unar package breakage is a different issue as it was replaced by
> community/unarchiver. I've no idea why it was not automatically
> replaced by pacman though.
> 
> Denis.
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
Two things:

1) unar was not automatically replaced becuase Arch's unarchiver doesn't
have 'unar' in 'replaces', which is expected as unar was never in Arch's
official repos (but in Parabola's [libre]).

2) I saw some packages in your pkglist that are no longer in our repos.
Please check which are those foreign packages with pacman -Qm. If you'll
continue using them, you'll have to rebuild them.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] The wiki runs an outdated MediaWiki software

[Megver83]

El 06/10/18 a las 05:00, Jens Hausdorf escribió:
> Hey there,
> 
> after a question on IRC of myself, I was forwarded to this list, so here
> we go:
> 
> - Why is the wiki still on such an old MediaWiki version?
> - Are there any plans to upgrade it in the future to use a version which
> is not EOL (and perhaps make the UI a little bit fancier)?
> 
> 
> -- 
> 
> Regards
> 
> Jens
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
I also had the same doubt, but didn't take the time to discuss it.
ArchWiki is updated, plus it has a mobile version (but ParabolaWiki doesn't)

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: pixelfed.social/Megver83
PeerTube: peertube.xtenz.xyz/accounts/megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] recent pbot bugs

[Megver83]

El 24/09/18 a las 05:26, bill-auger escribió:
> i introduced a bug while tweaking pbot a few days ago that broke his
> ability to store memos - he did say 'certainly'; but you may also
> remember seeing "WARNING: I HAVE NEVER SEEN "" HERE BEFORE. CHECK YOUR
> SPELLING." - if so, then the message was not stored - i saw megver hit
> this yesterday
> 
> that is fixed now but just to remind anyone who left a memo recently to
> assume that "whoever" did not and will not get that memo
> 
> pbot was also suppressing any unregistered user from pasting a
> missing shared lib error if it had a very long filename - the very long
> filename matched the GIBBERISH_REGEX in the spam filter - i have allowed
> those to pass now
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
I think this is not fixed completely, but partially. When I say "pbot:
tell someone: blablablah" if fails with:

WARNING: I HAVE NEVER SEEN "someone:" HERE BEFORE. CHECK YOUR SPELLING.

So I've to remove the double dots ":". Plus, it always returns:

-pbot- Error: Not able to parse this command: "pbot: tell someone:
blablablah"

This^ happens with and without the double dots.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [apparmor-libapparmor] marked out-of-date

[Megver83]

El 21/08/18 a las 12:33, Parabola Website Notification escribió:
> libapparmor uses an out of date version of perl, and needs to be updated to 
> use 5.28
> 

Then you should have reported an issue in the bug tracker, not mark the
pkg as outdated.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Fwd: linux 4.17.7 not suitable for i386

[Megver83]

El 17/07/18 a las 15:56, Brett Gilio escribió:
> 
> This is from the Guix mailing list, I am forwarding here just to make
> sure everybody is aware of this problem.
> 
> Leo Famulari writes:
> 
>> FYI, the latest stable Linux release (4.17.7) is not suitable for i386
>> (i686-linux) systems. Quoting Greg Kroah-Hartman:
>>
>> "NOTE, this kernel release is broken for i386 systems.  If you are
>> running such a machine, do NOT update to this release, you will not be
>> able to boot properly.
>>
>> I did this release anyway with this known problem as there is a fix in
>> here for x86-64 systems that was nasty to track down and was affecting
>> people.  Given that the huge majority of systems are NOT i386, I felt
>> this was a safe release to do at this point in time."
>>
>> https://lkml.org/lkml/2018/7/17/434
>>
>> So, we should take care to preserve the linux-libre 4.17.6 package
>> definition for i686-linux, or skip this release.
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
Thanks for the info. Will see what does ArchLinux32 does regarding this,
but surely the easiest way is to skip linux-libre 4.17.7, which is about
to be released.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] dbscripts 20180715 release announcement, and more!

[Megver83]

El 15/07/18 a las 18:41, Luke Shumaker escribió:
> TL;DR: `db-move` and `db-remove` now work correctly!
Yhaaa!!!

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Kernels package [linux-libre-xtreme] marked out-of-date

[Megver83]

El 09/07/18 a las 12:53, Parabola Website Notification escribió:
> korob...@vinterdalen.se wants to notify you that the following packages may 
> be out-of-date:
> 
> 
> 
> 
> The user provided the following additional text:
> 
> Please, update to the latest 4.16.18
> 
> thanks in advance,
> Andrey
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
Parabolaweb shows older versions of packages, Linux-libre-xtreme is on
4.17.3

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83





signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Unblacklisted Mesa

[Megver83]

El 12/06/18 a las 15:36, Luke Shumaker escribió:
> Hi all,
> 
> Because Mesa was a point of contention last year, I'm publicly
> discussing this here.
> 
> I've unblacklisted extra/mesa, and am going to remove libre/mesa.  The
> differences are:
> 
>  - libre/mesa said "free" instead of "open-source" in pkgdesc
>  - libre/mesa removed most everything from /etc/drirc
> 
> The reason libre/mesa existed (or continued to exist after 2017-03) is
> because: /etc/drirc configures workarounds for specific buggy
> applications, and the stock file from upstream is a growing database
> of them.  Most of these end up being proprietary applications, since
> free applications get patched, rather than needing workarounds in the
> graphics driver.
> 
> Emulatorman had considered these references to non-free programs to be
> significant enough to warrant repackaging it.
> 
> I disagree, I don't believe the collection of workarounds in
> /etc/drirc to be a freedom problem.  It isn't *trying* to load them
> (like Linux might with non-free blobs).  The user won't be confused in
> to thinking something is wrong if the non-free thing isn't installed.
> 
+1

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Intellij IDEA includes User Agreement that revokes freedoms?

[Megver83]

El 08/06/18 a las 14:26, dllud escribió:
> Hi everyone,
> 
> I've just installed the intellij-idea-community-edition package and upon
> opening Intellij it showed me the "JETBRAINS USER AGREEMENT". On it, one
> can read:
> 
>> (B) You may not:
>> (i) Rent, lease, reproduce, modify, adapt, create derivative works of,
> distribute, sell, or transfer the Product(s);
> 
> Products is defined as follows.
> 
>> "Product" means any generally available JetBrains software product
> identified by JetBrains as an individual developer tool, which is either
> covered by Toolbox Subscription, or provided perpetually for free. For
> the avoidance of doubt, the Product is not produced to the
> specifications of the User nor customized through modification or
> personalization, and is intended for mass distribution.
> 
> I am not fluent in legalese, but it seems that upon accepting this User
> Agreement I would be relinquishing my rights to free software freedoms
> number 2 and 3. I opted to decline and uninstall this package.
> 
> I would like you to take a look at this and consider whether this
> package should be removed from Parabola.
> 
> Upon inspecting the PKGBUILD (
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/intellij-idea-community-edition
> ) one can see that binaries are directly downloaded from Jetbrains' server.
> 
> I suspect that accepting this User Agreemen won't be mandatory if
> compiled directly from the source available at
> https://github.com/JetBrains/intellij-community
> I will test this later when I find the time.
> 
> Regards,
> David

I haven't installed or checked this package. Just wanted to suggest
making a freedom issue report in the issue tracker so we can better
track the issue :P (redundant).

P.S: After looking at the PKGBUILD, it seems to me that it builds from
binaries.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
PixelFed: https://pixelfed.social/Megver83



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Consolekit2

[Megver83]

El 30/05/18 a las 22:25, bill-auger escribió:
> it may help to open a packaging request for this on the parabola bug tracker
> 
> https://labs.parabola.nu/projects/issue-tracker/issues?set_filter=1_id=7
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
please don't, because we used to support it and it was already dropped
from [pcr], consolekit was giving me too many issues, otherwise I'd have
keept it

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] same blacklist txt ?

[Megver83]

El 27/05/18 a las 18:19, Megver83 escribió:
> El 27/05/18 a las 12:19, Dika SP escribió:
>> your-freedom
>> your-freedom_emu
>> your-privacy
>> all version 20180516-1
>>
>> just wondering across package and found that these three packages
>> contains the same exact blacklist.txt and same conflit depedencies
>>
>> so whats the point ? are they will be merged ?
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@lists.parabola.nu
>> https://lists.parabola.nu/mailman/listinfo/dev
>>
> it is because of a bug from our automatic build system, which I
> described here ->
> https://lists.parabola.nu/pipermail/dev/2018-May/006731.html
> 
just rebuilt them

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] same blacklist txt ?

[Megver83]

El 27/05/18 a las 12:19, Dika SP escribió:
> your-freedom
> your-freedom_emu
> your-privacy
> all version 20180516-1
> 
> just wondering across package and found that these three packages
> contains the same exact blacklist.txt and same conflit depedencies
> 
> so whats the point ? are they will be merged ?
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
it is because of a bug from our automatic build system, which I
described here ->
https://lists.parabola.nu/pipermail/dev/2018-May/006731.html

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Consolekit2

[Megver83]

El 27/05/18 a las 10:36, joinlaw escribió:
> 
> hi
> 
> why parabola replaces consolekit with elogind
> instead of Consolekit2 https://github.com/ConsoleKit2/ConsoleKit2
> i know guix is using elogind but what is gentoo using.
> 
> elogind seems bloated replaces consolekit & pm-utils
> so what the benfit for elogind over Consolekit2.
> 
> all the best
> joinlaw
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
I'd suggest to first read and then ask.

https://wiki.parabola.nu/OpenRC#The_system_can.27t_shutdown_correctly

"Since /sbin/init was replaced with openrc-init, shutdown was replaced
with openrc-shutdown, Consolekit doesn't work correctly and you need to
use elogind instead"

And elogind is not bloated, it's extracted from systemd-logind, yes, but
it does it job, without going further.
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Libre package [linux-libre] marked out-of-date

[Megver83]

El 20/05/18 a las 16:03, Parabola Website Notification escribió:
> 4.16.9 on kernel.org (I think 4.16.10 might be imminent too)
We don't care about what's on kernel.org, since out kernels are the
deblobbed ones from linux-libre.fsfla.org.

Anyways, I upgraded it for all its arch'es

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Blacklist and autobuilder

[Megver83]

Hi all. I've working on some things regarding the blacklist, and I've
encountered a few problems, thought on solutions, and wanted to discuss
some topics, so I will summarize everything in this mail.

1) Autobuilder
  Something strange happens to it. I just pushed some changes to the
blacklists, and now your-privacy and your-freedom_emu have the same
conflicts=() as your-freedom and the PKGBUILDs pushed to the abslibre by
the autobuilder have incorrect checksums, except your-freedom.

  lukeshu, could you look at this?

2) New script to get deprecated packages
  I created this script
  https://git.parabola.nu/blacklist.git/tree/find-deprecated-pkgs

  So anyone can get deprecated packages that are still in our blacklists
(read the script for more info) and remove them. I used it for
commit
https://git.parabola.nu/blacklist.git/commit/?id=c914523aa7fb48abea19f391bf5ebf3a2486fb69
and works well

3) Uboot packages
  We block Arch ARM's uboot packages
  https://git.parabola.nu/blacklist.git/tree/blacklist.txt#n701

  However, is it necessary? I mean, they are in the [alarm] which is a
particular repo from Arch ARM that we don't sync. Plus, some packages
like vboot-utils, which are at [alarm], not in the blacklist and in
[libre]. So then why uboot?

  In summary (regarding this point), we should not blacklist [alarm]
packages if we don't sync it. However, I think we can consider syncing
it, because there are some useful packages there, like fake-hwclock,
vboot-utils (which is ultra outdated in [libre]), some xf86-video
drivers, etc.
  If we don't, the second option would be to, in some way, move the
useful packages to [libre] (maybe using a whitelist instead of a
blacklist is a better idea in this case).
  And in the last case, which is probably what we do now, manually build
those packages ourselves and upload them to [libre].
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] duplicate 'unarchiver' packages

[Megver83]

El 14/05/18 a las 12:00, Megver83 escribió:
> yes, that's right. Unless (regarding point 1) the package unarchiver was
> added after adding unar in Parabola, which would explain the conflicts
> array.

I mean, added to AUR after Parabola added it to its repos

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] duplicate 'unarchiver' packages

[Megver83]

El 14/05/18 a las 09:32, bill-auger escribió:
> On Mon, 2018-05-14 at 07:55 -0300, Freemor wrote:
>> I'd like to propose an "unar is replaced by unarchiver"
> 

How can we achieve that? we can't build an external package to do such
things like a manjaro-system thing, we just have to post a new in the
feed saying this

> yes these are both obvious solutions - i really posted this to see if anyone
> could explain the confused situation it is currently in
> 
> * why the 'unar' package is not already named 'unarchiver'

I also wondered that

> * why the 'unar' package replaces('unrar') but that is an entirely different
> software

maybe someone confused "alternative" with "replacement"

> * why the 'unar' package is in [libre] and not [pcr] although it is not 
> modified
> from the upstream
> 

wasn't it at [pcr] at first?

> if no one knows how it got that way, can we at least agree that all 3 of those
> points are incorrect procedure
> 

yes, that's right. Unless (regarding point 1) the package unarchiver was
added after adding unar in Parabola, which would explain the conflicts
array. No matter unar's history, I think we should remove it and write
about this in the news so that users know what happened.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] duplicate 'unarchiver' packages

[Megver83]

El 13/05/18 a las 18:17, bill-auger escribió:
> the parabola package 'unar' may not longer be necessary as it seems arch
> has begun packaging the same program under the name 'unarchiver' so
> there is now the same program available in two different repos under
> different names - this is not critical but the current situation is very
> confusing how it got to be this way - can anyone sort out how to handle this
> 
> the 'unar' package is listed in the blacklist as replacing the 'unrar'
> package - but those are not the same software - that would explain the
> different name but that would not be considered to be a replacement but
> a completely unrelated alternative - i would really like to see the
> blacklist data be as informative and helpful as possible - this
> particular example is more confusing than helpful - the blacklist
> descriptions should all read something like: "the parabola version of
> this program was liberated in the following ways " in which case the
> parabola package lives in [libre] and usually has the same name as the
> non-free package - or else it should read: "parabola did not liberate
> this package but the following alternative is recommended instead "
> with the alternative package having a different name and noted only in
> the description but not in the metadata column #2 as the definitive
> liberated replacement
> 
> secondly, the PKGBUILD for 'unar' has it replacing the 'unarchiver'
> which was presumably in the AUR when this was added - but that would not
> explain the different name because it is exactly the same program - it
> furthermore is not modified in any significant way from the upstream so
> therefore does not belong in [libre] but instead in [PCR]
> 
> 
> this is issue #1769 https://labs.parabola.nu/issues/1769
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
since both unarchiver and unar provide the same binaries, then unar
should be dropped

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Funny file permissions on repo

[Megver83]

El 12/05/18 a las 12:06, bill-auger escribió:
> On 05/11/2018 11:37 PM, Luke Shumaker wrote:
>>  - What's up with ISOs?  What's up with them being owned by root? 
> 
> i can answer to the pkglist.*.txt files - none of the files you
> mentioned are ISOs - they are all the package list text files - i copied
> those directly from the inside of the ISOs with the `mc` program -
> nearly all files inside the ISOs are owned by root; so i guess mc
> preserves the perms
> 
> megver made the openrc torrents - maybe he remembers making them - i
> seem to remember there is an automated script somewhere for that - i
> think he used that to create them - all of the current ISO are due to be
> replaced soon - i will try to mind the permissions on everything with
> the next batch
> 
> i just transfered the package lists to the repo user and set the torrent
> files to 644 - i dont know what the kodi files are - i left them be
> 

Didn't know there was an script for creating torrents, in fact those do
not work. Where is such script? I'd like to know.

Btw, I might upgrade the OpenRC ISOs this month or next, because I want
to first add enough [nonsystemd] packages to announce this new repo on
the news plus its inclusion in the new OpenRC ISOs.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support

[Megver83]

El 08/05/18 a las 19:01, bill-auger escribió:
> yes - im sure i am misunderstanding
> 
> so the [notsystemd] repo would allow access to all of the replacements
> for things that depend on systemd - like all of the *-openrc packages

I must first point out that *-openrc packages are init scripts.
[nonsystemd] would not offer initscripts, but rebuilt packages without
systemd support. For example, mkinitcpio:

Repository  : core
Name: mkinitcpio
Version : 24-2
Description : Modular initramfs image creation utility
Architecture: any
URL : https://projects.archlinux.org/mkinitcpio.git/
Licenses: GPL
Groups  : None
Provides: None
Depends On  : awk  mkinitcpio-busybox>=1.19.4-2  kmod
util-linux>=2.23  libarchive  coreutils  bash  findutils  grep
filesystem>=2011.10-1  gzip  systemd

This is the one we all use, but this is nonsystemd's:

Repository  : nonsystemd
Name: mkinitcpio
Version : 24-2.nosystemd1
Description : Modular initramfs image creation utility
Architecture: any
URL : https://projects.archlinux.org/mkinitcpio.git/
Licenses: GPL
Groups  : None
Provides: None
Depends On  : awk  mkinitcpio-busybox>=1.19.4-2  kmod
util-linux>=2.23  libarchive  coreutils  bash  findutils  grep
filesystem>=2011.10-1  gzip  eudev

Exactly the same one as [core], but without systemd as a dependency but
eudev. It is also patched with Artix's nosystemd.patch[0]

> 
> so what would actually happen when you install 'your-initfreedom'? -
> will it remove systemd and all of it's dependents? if so, then what
> would the user have for an init system? would it automatically install
> openrc? - if not, then that is a very dangerous package to install - if
> yes, then would one need to remove 'your-initfreedom' on order to
> install a different init system that is neither openrc nor systemd?
> 

your-initfreedom would remove systemd and its counterparts, yes, *but*
in the post_install() and post_upgrade() there would be a warning saying
that you need to install an init provider (As of now, OpenRC/Runit).

Installing such package is equivalent to removing systemd without
installing anything else, this is why it is intended to be (optionally)
installed during or after the migration from systemd to another init,
otherwise the system will not boot.

I think that with the warning is enough, 'cause I really doubt someone
would be too distracted to ignore such thing. Anyways I can write a wiki
page explaining this with more detail, the procedure of installation and
precautions to be taken.

[0]
https://github.com/artix-linux/packages/blob/master/mkinitcpio/repos/core-any/nosystemd.patch

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support

[Megver83]

El 08/05/18 a las 16:12, bill-auger escribió:
> you would know best how problematic is may be to keep all these
> "foo-openrc" alternatives around - the one thing i would add is that the
> other "your-whatever" meta packages off replacements for the essential
> things that they remove - in the case of your-initfreedom that would
> currently need to be everything that is now a *-openrc packages - but
> would that not make it problematic to add other inits or replace openrc
> entirely? - "anti-systemd" is not the same as "init freedom" - for
> freedom you need to be able to move freely - this sounds like locking in
> either systemd or openrc with no room for anything else

Let's clarify things: If anyone doesn't want systemd on its system,
he/she is free to remove it *completely*. Period. Current Parabola
OpenRC users have to use eudev-systemd and libeudev-systemd so packages
built for systemd can run. And any user is free to enable or disable
[nonsystemd] repo.

Second, your-initfreedom won't remove core packages. I mean, it for some
reason there's a very important package that cannot have a nonsystemd
version and has a hard-depend on systemd (which, afaik, there aren't),
of course I will not put it there. Not having systemd does not mean
breaking your system to make it disappear.

> 
> i like the idea of trying shepherd for example - but how would that fit
> into this scheme? - if all non-systemd inits were lumped together then
> there still need to be a slew of *-openrc and *-shepherd packages
> analogous to their *-system counterparts - so maybe not much is gained
> by this practically speaking
> 

Seems that you did not understand my proposal.

The idea of this fully-optional repo (I say this to avoid confusions) is
that the ones who which to use packages built without support for
systemd (mainly OpenRC and/or Runit users I imagine) can install them if
they want. Some packages even run systemctl and related stuff in their
pacman install scripts, sth. that's annoying for non-systemd users.

And the last but not the least: OpenRC, Runit, new inits (like Shepherd)
and initscripts *will keep on [PCR]*. [nonsystemd] is just, as I said,
like [nonprism]: not mandatory for anything and non-critical

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [RFC] [nonsystemd] repository, packages built without systemd support

[Megver83]

Hi all,

I just created a new (experimental) repository named [nonsystemd] (the
folder at /srv/repo/main seems to be there since 2015 so I decided to
use it) and my idea was to do the same as [nonprism], but applied to
systemd.

So, as in [nonprism] we build packages without support for nonfree or
privacy-dangerous services/protocols, [nonsystemd] packages would have
packages built without systemd support (so we don't have to create
-nosystemd packages). I thought also on creating your-initfreedom or
sth. like that, which conflicts with systemd and its friends: netctl,
libsystemd, libsystemd-standalone, systemd-kcm, python-systemd,
nss-{resolv,systemd}, etc. (we can add the list on blacklist.git too)

As of now, [nonsystemd] has a version of mkinitcpio taken from Artix. I
don't think it's necessary to put "$pkgdesc, without systemd support" in
the PKGBUILDs since the repository name says everything.
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Kernels package [linux-libre-lts-xtreme] marked out-of-date

[Megver83]

El 06/05/18 a las 11:42, Parabola Website Notification escribió:
> o...@riseup.net wants to notify you that the following packages may be 
> out-of-date:
> 
> 
> 
> 
> The user provided the following additional text:
> 
> Is there a reason this isn't on the 4.14.x series yet, like linux-libre-lts?
> If there is, sorry, ignore this :)
> 

Simply because the knock patch is not for 4.14. Plus, 4.9 is still
maintained.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [riscv64-linux-gnu-linux-libre-api-headers] marked out-of-date

[Megver83]

El 01/05/18 a las 05:48, Andreas Grapentin escribió:
> 
> The riscv64-linux-gnu-* prefixed packages should probably be removed
> from pcr. They have served their purpose and are now obsolete.
> 
> Best,
> -A
> 

I think that cross-compilers (for testing/porting purposes, not as
makedepends of a [pcr] or [libre] pkg) should go to [cross]. I've
recently cleaned it (there were many outdated and unused cross-compilers)

The base PKGBUILDs for toolchains are at the abslibre.git named
cross-{gcc,binutils,newlib}

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Rework of the ARM installation guide

[Megver83]

El 01/05/18 a las 05:55, Andreas Grapentin escribió:
> 
> fwiw, using qemu-user-static it is possible to pacstrap an arm image
> directly, so the general installation instructions apply
> 
> 1) partition sdcard
> 2) pacstrap to sdcard
> 3) chroot and configure
> 4) insert and boot
> 
> Best
> -A
> 

What a smart hack! I agree with this installation method. It's better
than making ARM rootfs tarballs IMO, and idk why no one else thought on
this (this could be even done from an x86 install ISO). Could you add an
entry about this in the ARM installation guide, plz?

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] dbscripts 2018425 / winston.parabola.nu upgrade

[Megver83]

El 26/04/18 a las 16:41, Luke Shumaker escribió:
> On Wed, 25 Apr 2018 17:57:42 -0400,
> Luke Shumaker wrote:
>>  2. The Nginx mime.types holoscript seems to be broken:
>>
>> Working on file:/etc/nginx/mime.types
>>   store at /var/lib/holo/files/base/etc/nginx/mime.types
>>   passthru 
>> /usr/share/holo/files/10-config-mgmt-nginx/etc/nginx/mime.types.holoscript
>> 
>> sed: -e expression #1, char 0: unmatched `{'
> 
> This ended up messing up Content-Types served by nginx, so CSS files
> were ignored.  The relevant file extensions now exist in the default
> mime.types; I've pushed a new config-mgmt-nginx with
> mime.types.holoscript removed.
> 
Great :)

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] dbscripts 2018425 / winston.parabola.nu upgrade

[Megver83]

El 26/04/18 a las 12:34, Luke Shumaker escribió:
> On Wed, 25 Apr 2018 17:57:42 -0400,
> Luke Shumaker wrote:
>> $ sudo pacman -Su --ignore={python-pyspf,libxfont,xorgproto} 
>> config-mgmt-nshd-local
>> $ # accept default answer to all questions
> 
> This updated /etc/ssh/sshd_config to include a new cipher that the old
> sshd didn't know about.  So then the running sshd stopped accepting
> new connections.  Even to emergency@ (good thing this happened on
> winston, not proton!).  Thanks to Megver83 for alerting me that
> something was amiss.
> 

Well, good that I realized right when I wanted to clone hackers.git
(coincidence? who knows!)

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Test

[Megver83]

This is just a test, ignore this message
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Help

[Megver83]

El 23/04/18 a las 16:13, Luke Shumaker escribió:
> 
> I haven't seen you on #parabola in a while.  I hope you're well.
> 
[16:24]  pbot: when did you last see encyclomundi
[16:24]  I last saw encyclomundi speak 11 months ago.

:-O

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Libre package [linux-libre] marked out-of-date

[Megver83]

El 16/04/18 a las 18:21, nRoof escribió:
> So maybe it won't be a bad idea to put 4.16 in libre-testing, so that
> all wishing can test beforehand and report issues if there are any, like
> recent issues with missing modules?
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
Arch Linux tracks most of those issues, and make patches for that. In
Parabola, it wouldn't make sense since we even use a similar configuration.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] libretools 20180327 release announcement

[Megver83]

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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] Deprecation of webkitgtk2

[Megver83]

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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [RFC] Deprecation of webkitgtk2

[Megver83]

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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] linux-libre-4.15.9_gnu-1 update missing critical kernel modules

[Megver83]

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@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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] I'm back

[Megver83]

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: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Community package [electrum] out of date

[Megver83]

El 09/01/18 a las 07:01, Ben escribió:
> On 01/09/2018 03:15 AM, Megver83 wrote:
>> This package comes from Arch, so none of our packagers are the ones in
>> charge.
> 
> ok, so that's why I couldn't flag-it-as-out-of-date on our site, yes?

Yes, what called my attention is that the typical "This package comes
from Arch" message doesn't appear. Might be due to the Winston issue.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Community package [electrum] out of date

[Megver83]

El 08/01/18 a las 20:10, Ben escribió:
> Hi All,
> 
> 
> https://www.parabola.nu/packages/community/any/electrum/ 3.0.3
> 
> https://www.archlinux.org/packages/community/any/electrum/ 3.0.5
> 
> Electrum's site:
> 
>   Security Notice: A vulnerability has been found in Electrum, and
> patched in version 3.0.5. Please update your software if you are running
> an earlier version.
> 
> 
> 
> (for some reason I can't use the report-out-of-date flag on our site for
> this package, hopefully this is not redundant)
> 
> ;)
> Ben
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
This package comes from Arch, so none of our packagers are the ones in
charge.

It might me outdated since Winston (winston.parabola.nu) is in
maintenance (packages are hosted there, so there won't be updated until
the maintenance ends. In fact we, the packagers, are unable to upload
packages.)

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] meltdown/spectre?

[Megver83]

El 04/01/18 a las 12:14, fauno escribió:
> 
> hey, how are we on meltdown/spectre?[^0]  i see that arch already
> patched their kernel[^1], are we following in on it?  can i help?  i'd
> update the kernel but i think megver and ebrasca are on top of kernels
> now so i don't want to overstep :)
> 
> 
> [^0]: https://meltdownattack.com/
> [^1]: 
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux=0b8ad988d054cd9952434002d03ba403ff798529
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
I'm totally conscious about this vulnerabilities and Arch's kernel
patches. However, since kernels are kinda outdated I want to first get
them up-to-date and on future releases (hopefully 4.14.12) add this patches.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] CrazyToon has passed away

[Megver83]

El 26/12/17 a las 13:45, Luke Shumaker escribió:
> A former Parabola contributor, CrazyToon, has passed away earlier
> today, December 26th at 4:40 AM UTC, at the age of 60.
> 
> On September 30th, he suffered two cerebral aneurysms and intracranial
> hemorrhages.  Surgery was performed on October 13th and he entered
> into coma until November 1st.  On November 10th, he suffered two
> cerebral strokes and lost all possibility of recovering his health.
> He proceeded to have catatonic stupor state, hard convulsions,
> continuous high pressure, fever and general hemorrhages.
> 
> He will be remembered as the father of two other Parabola
> contributors, André Silva ("Emulatorman") and Márcio Silva ("coadde");
> for his artwork, including Parabola's mascot; as a Free Software and
> Free Culture activist; and as a founder of the Hyperbola project.
> 
Thanks, for all of your work Crazytoon. All of us will remember you,
your work, and your will. R.I.P.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Libre package [linux-libre-hardened] marked out-of-date

[Megver83]

El 21/12/17 a las 14:32, Parabola Website Notification escribió:
> hu...@amail.club wants to notify you that the following packages may be 
> out-of-date:
> 
> 
> * linux-libre-hardened 4.13.13_gnu.a-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-hardened/
> * linux-libre-hardened 4.13.13_gnu.a-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened/
> * linux-libre-hardened 4.13.13_gnu.a-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened/
> * linux-libre-hardened-docs 4.13.13_gnu.a-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-hardened-docs/
> * linux-libre-hardened-docs 4.13.13_gnu.a-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened-docs/
> * linux-libre-hardened-docs 4.13.13_gnu.a-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-docs/
> * linux-libre-hardened-headers 4.13.13_gnu.a-1 [libre] (armv7h): 
> https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-hardened-headers/
> * linux-libre-hardened-headers 4.13.13_gnu.a-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-hardened-headers/
> * linux-libre-hardened-headers 4.13.13_gnu.a-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-headers/
> 
> 
> The user provided the following additional text:
> 
> https://www.parabola.nu/packages/libre/x86_64/linux-libre/
> 
> https://github.com/copperhead/linux-hardened/releases
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
I haven't upgraded this pkg since there were issues with linux-libre
4.14, but as the things have improved I might update this one soon.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

[Megver83]

El 21/12/17 a las 03:22, Luke Shumaker escribió:
> Hi guys,
> 
> I wrote a little pyalpm script for finding blacklist replacements (as
> in the second column in blacklist.txt).
> 
> I'll be polishing it up and committing it soon, but it did identify a
> few problems/concerns.
> 
>  - unrar is replaced by both libre/unar and pcr/gna-unrar.  libre/unar
>should drop the replaces=(unrar) line, and pcr/gna-unrar should be
>moved to libre.
> 

+1

>  - tensorflow has several other versions that are not blacklisted:
>tensorflow-opt and tensorflow-opt-cuda.  I think that this is an
>argument toward prioritizing switching to pkgbase-based
>blacklisting.

I agree, for example the 'linux' package from arch is an split package
which compiles 'linux', 'linux-headers' and 'linux-docs'. Although it
might make difficult to specify its replacement.

I mean, let's say we blacklist linux and linux-docs/linux-headers are
automatically blacklisted. All right up to there, but where do we
specify that linux-headers' replacement is linux-libre-headers? (same
for -docs)

> 
>  - b43-fwcutter is not replaced by, but is provided by
>libre/b43-tools.  For one, I am flabbergasted that whatever freedom
>issues b43-fwcutter has aren't also issues with b43-tools.
>Secondly, b43-tools should probably replaces=(b43-fwcutter), or be
>renamed to b43-fwcutter.

Did not know about this.

> 
>  - Why does linux-libre-pck provide linux-zen?  Replacing it (which it
>doesn't do) makes a little bit of sense, but providing it makes no
>sense to me.

The Parabola Community Kernel *has the linux-zen patch* (which has BFQ,
BFS and gracy's gcc kernel patch) plus a few others (as of now, apart
from ZEN, it has TuxOnIce, UKSM and AUFS). So technically it does
replace and provides linux-zen since, as I said, ZEN is one if the
patches from PCK.

> 
>  - What's the deal with pcr/mesa-vanilla replacing a bunch of nvidia
>stuff?  It seems that mesa-vanilla is unmaintained since
>emulatorman and coadde left, we should just drop it?

We should look for packages that depend on it. If there aren't, I don't
see why not removing it.

> 
>  - The following packages are on pcr, but should be moved to libre:
>figlet, mplayer-vaapi
>  
> 
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] modular pacman.conf and makepkg.conf by default

[Megver83]

El 15/12/17 a las 23:26, Luke Shumaker escribió:
> Hi,
> 
> What do you guys think about modifying the default pacman.conf to have
> this at the end:
> 
>   Include = /etc/pacman.d/*.conf

Sure, why not. In that way anyone can set up its custom repos in
separated files rather than in pacman.conf itself.

> 
> and the default makepkg.conf to have this at the end:
> 
>   for file in /etc/makepkg.d/*.conf; do
>   if [[ -f "$file" ]]; then
>   source "$file"
>   fi
>   done
>   unset file
> 

I imagine that then pacman should come with an empty /etc/makepkg.d dir?
Because I don't see it in my /etc dir.

> This would make it easier for configuration packages (like Holo
> packages or <https://config.parabola.nu/> /
> <https://git.parabola.nu/server/config.git/>) to add bits to their
> configurations.
> 
>  - As an admin of several Parabola-running servers, including the
>parabola.nu servers, that is appealing to me.
> 
>  - As the developer of a package (libretools) that has to modify the
>default makepkg.conf, that is appealing to me.
> 
>  - As someone involved in Holo, which works best with modular config
>files, that is appealing to me.
> 
> One of the few things that I like more than writing code is deleting
> code.  And it would let me phase-out and delete the
> `librefetch-install` program.

Yea, deleting code rocks! specially when it's crappy and badly written :)

> 
> On one hand, we don't like unnecessarily modifying the default
> configuration files from upstream; but we're patching makepkg anyway;
> and we are the single source of truth for the default pacman & makepkg
> configs on Parabola.
> 


-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Linux-libre 4.14 available at [libre-testing]

[Megver83]

I've recently added Linux-libre 4.14.4 to [libre-testing], for all its
architectures.

https://git.parabola.nu/abslibre.git/commit/?id=f0d3a651744c676c319564cc0004526999412c3e

Before moving it to [libre], I'd like that ppl with encrypted partitions
test it and give me some feedback, since they where the ones who
suffered more on the last update.

Feel free to assign me new issues on the bug tracker or simply contact
me on #parabola. I expect to see linux-libre 4.14.x on [libre] soon (a
week maybe?), so please test it.

Regards,
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] PCR requests

[Megver83]

El 08/12/17 a las 02:58, Andreas Grapentin escribió:
> 
> bisq looks ok, but the mist PKGBUILD on the AUR is unusable, because it
> builds the package from .deb packages rather that from source.
> 
> -A
> 
> On Wed, Dec 06, 2017 at 07:57:31PM -0500, bill-auger wrote:
>>
>>
>> On 12/04/2017 11:41 AM, Christian wrote:
>>> Hello,
>>>
>>> Would anyone be willing to add mist and bisq from the AUR to the PCR?
>>
>> there exist open package requests for these on the bug tracker
>> mist: https://labs.parabola.nu/issues/1482
>> bisq: https://labs.parabola.nu/issues/1481
>>
> 
> 
> 
> 
>> ___
>> Dev mailing list
>> Dev@lists.parabola.nu
>> https://lists.parabola.nu/mailman/listinfo/dev
> 
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
most AUR PKGBUILDs are crappy, sometimes I prefer to make my own
PKGBUILDs which build from source correctly.

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] texlive-core problem, and repairs

[Megver83]

El 06/12/17 a las 12:14, Nelson H. F. Beebe escribió:
> I built a new machine running Hyperbola 0.2.1 in our test farm of
> Unix(-like) systems, and successfully installed more than 650
> packages on it with "pacman -Sy", based on a similar list from
> an Arch Linux system in the farm.

I'm sorry, but I think you confused the mailing list. This is Parabola's
dev list, not Hyperbola's nor Arch's.

> 
> One package, texlive-core, failed to install completely, however,
> and I diagnosed the problem, and found a workaround logged in
> these system notes:
> 
> When I installed texlive-core, I found that the installation step
> failed because of missing Czech fonts (.../cs/cs*.mf).  A comparison
> with Arch Linux showed that Hyperbola is missing many files:
> 
>   hyperbola:
>   # pacman -Fl texlive-core | wc -l
>   16266
> 
>   archlinux:  
>   # pacman -Fl texlive-core | wc -l
>   24069
> 
> I was able to temporarily repair the problem like this:
> 
>   # fmtutil-sys --listcfg
>   # fmtutil-sys --disablefmt csplain
>   # fmtutil-sys --disablefmt cslatex
>   # fmtutil-sys --all
> 
> Now the Czech fonts are disabled, and the remaining *.fmt files are created:
> 
>   hyperbola:
>   # find /var/lib/texmf/web2c -name '*.fmt' |wc -l
>   18
>   
>   archlinux:  
>   # find /var/lib/texmf/web2c -name '*.fmt' |wc -l
>   38
> 
> It is unclear why almost 8000 files are missing from texlive-core
> compared to the package on Arch Linux.  
> 
> I'm a member of the TeX Live team that prepares the annual releases,
> and I have TeX installed on almost 200 systems in the farm without
> ever seeing a problem like this, until I build the Hyperbola system.
> 
> ---
> - Nelson H. F. BeebeTel: +1 801 581 5254  
> -
> - University of UtahFAX: +1 801 581 4148  
> -
> - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  
> -
> - 155 S 1400 E RM 233   be...@acm.org  be...@computer.org 
> -
> - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ 
> -
> ---
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 


-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Iceweasel 57 status

[Megver83]

El 21/11/17 a las 19:02, Andreas Grapentin escribió:
> 
> Hi,
> 
> sorry I'll promptly get back to you guys, I am presently on a conference
> and have limited time available.
> 
> I am aware of the iceweasel issue, and there are currently two problems
> that need solving:
> 
>  a) the branding patches are broken and need to be updated
>  b) firefox-57 has removed support for legacy extensions, so all addon
> packages need to be verified if they still work. At least noscript
> needs to migrate to 10.x
> 
> I hope I'll get to doing that today or tomorrow.
> 
> I am not sure if we particularily need an iceweasel-esr version, that
> role has typically been filled by icecat, which will probably switch to
> 59 soon as well, once all the issues are ironed out, but it can't hurt I
> guess. But that's an issue I'd assign a lower priority to, unless
> someone sais it's important to them :)
> 
> Best,
> Andreas
> 

Right, well in that case you can try to get the rebranding for these new
versions and upload iceweasel on [libre-testing] until we've migrated
all the extensions from the iceweasel-addons group (which may also go to
[libre-testing] if the testing version of iceweasel is there)

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Iceweasel 57 status

[Megver83]

El 20/11/17 a las 21:48, eliotreyna@cock.email escribió:
> Greetings.
> 
> Since the release of Firefox 57 officially in wedmesday, existed some
> issues related to the release of Iceweasel. However, due to the big
> changes that has been made from the source code, exists a delay with the
> release of Iceweasel 57.
> 
> If we can help about the changes that has been made in the source code
> for apply the rebranding and/or another variables for make the browser
> free.

Andreas, its maintainer, just has to adapt the rebranding, if necessary.
I don't think, however, that it would be such a big deal.

> 
> If we can improve the progress of Iceweasel 57, we can follow this
> developer release notes:
> https://developer.mozilla.org/docs/Mozilla/Firefox/Releases/57
> 
> PS: Can I make an Iceweasel rebrand for the version 59 for the release
> of Quantum source code for ESR branch?

If you know how to do it, of course. You should then get in contact with
oaken-source (Andreas's nick on IRC)

> 
> Thanks.
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev


-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [RFC] More init systems

[Megver83]

El 18/11/17 a las 18:04, bill-auger escribió:
> GNU shepherd may also be an appropriate init system for parabola - it is
> maintained by the guix team for guixSD
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
Thanks for mentioning it, I forgot it. Yes, I think shepherd is also
getting into Parabola, after s6 and sinit

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [RFC] More init systems

[Megver83]

Since I've seen a lot of Arch-based distros offering not only OpenRC as
an alternative to Systemd but also other inits such as runit, s6, sinit,
busybox, daemontools, etc. I thought on why not doing the same.

I've added Runit[0][1] to [pcr] (I already tested it *a lot* to make it
work well). I "borrowed" the PKGBUILD from Artix, but did some
modifications to it so it provides /sbin/init.

As OpenRC can work well with the provided init program (it used to do
with sysvinit by default), I modified it to package openrc-init in a
separated package[3] called 'openrc-init' which, like the package
'runit', provides and conflicts 'init'.

Our runit version, different from Artix's, can (optionally) work with
OpenRC through 'runit-scripts'[1][4] which will invoke /sbin/openrc if
it exists[5]. As agetty is started by the init program (in this case
runit[6] of course), I've pulled /etc/{conf,init}.d/agetty.* from
'openrc' to 'openrc-init' (also the poweroff, shutdown, halt and reboot
scripts, which work only with openrc-shutdown. Maybe that binary I
should also move it to openrc-init).

Which are your thoughts on this? I thought on, later, add S6-rc from
Obarun[7], as it has many init scripts and looks more active[8] that
others like runit or sinit (which haven't got update for like 2-3 years,
but at least they KISS)

[0]
https://git.parabola.nu/abslibre.git/diff/pcr/runit/PKGBUILD?id=c799f6ae2ec796e75d399028736c9d70c021dcd7
[1]
https://git.parabola.nu/abslibre.git/diff/pcr/runit-scripts/PKGBUILD?id=c799f6ae2ec796e75d399028736c9d70c021dcd7
[3]
https://git.parabola.nu/abslibre.git/commit/?id=c799f6ae2ec796e75d399028736c9d70c021dcd7
[4] https://gitlab.com/Megver83/runit-scripts
[5] https://gitlab.com/Megver83/runit-scripts/blob/master/1#L5
[6] https://gitlab.com/Megver83/runit-scripts/blob/master/2
[7] https://web.obarun.org/
[8] https://git.skarnet.org/cgi-bin/cgit.cgi/s6/
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Libre package [linux-libre] marked out-of-date

[Megver83]

El 12/11/17 a las 23:35, Parabola Website Notification escribió:
> nowh...@example.com wants to notify you that the following packages may be 
> out-of-date:
> 
> 
> * linux-libre 4.13.12_gnu-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre/
> * linux-libre 4.13.12_gnu-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/
> * linux-libre-docs 4.13.12_gnu-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/
> * linux-libre-docs 4.13.12_gnu-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/
> * linux-libre-headers 4.13.12_gnu-1 [libre] (i686): 
> https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/
> * linux-libre-headers 4.13.12_gnu-1 [libre] (x86_64): 
> https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/
> 
> 
> The user provided the following additional text:
> 
> https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14-gnu/
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
nowh...@example.com? is this a bot? plus, we won't go ahead with 4.14
immediately since Arch hasn't launched an update, yet

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Install media releng / I made some changes

[Megver83]

El 07/11/17 a las 16:17, bill-auger escribió:
> that halo tool seems very nifty - the actual configuration is minimal
> and the modifications are trivial though - a configuration management
> tool would be "managing" very little
> 
> these are all of the modifications to existing files owned by other
> packages:
> 
> for all ISOs:
> * 4 languages are un-commented in /etc/locale.gen
> * the edition title is injected into /etc/motd

LXDE OpenRC have 8 languages uncommented, fyi

> 
> for the 'complete' ISOs only:
> * the definition of the local on-disk package repo is added to
> /etc/pacman.conf
> 
> of those, the edition title is the only dynamic value - it contains the
> build date matching the output filename - even that is fully
> deterministic it needs not be a date - it is actually the version string
> that is printed verbatim as passed into the build script on the command
> line - the others are static values will apply with the current values
> to ISOs present and future (unless a new locale is added) - but the live
> environment does not use a DM so im not even sure if the locales are
> applicable to anything but the CLI install script (which is being phased
> out)
> 
> there are a small number of files in the 'root-image' overlay that are
> copied directly to the live environment filesystem (so not owned by any
> package that is installed in the live environment) - i would eventually
> like to put these all in the 'parabolaiso-data' package which could be
> installed in the live environment and the 'root-image' overlay feature
> could be removed or at least unused - that is the original intended way
> to customize the install with anything specific to the live environment
> that did not belong in any standard package (e.g. service files,
> password-less sudoers file, ssh root login)
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 


-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Buildbot

[Megver83]

El 06/11/17 a las 14:11, Andreas Grapentin escribió:
> 
> as for batch processing of jobs, we should probably take a look at
> pcr/task-spooler. it's great and I've been using it for queueing builds
> on my crunching box for a while.
> 
> by the way, I would personally discourage using text parsing on git
> commits for triggering builds. it's prone to mistakes, and doesn't
> follow the principle of least astonishment [1]. Would probably be better
> to get a cli tool on the server to do it, or, if people prefer that, a
> website or something.
> 
> Come to think of it, what might work would be having a git hook that
> activates upon a pushed commit, scanning for updated pkgbuild files, and
> rebuilding them, if a certain flag is set or something. But we'd better
> document the hell out of this or it will come back and bite us in the
> ass.
> 
>  [1] - https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> 
> 
> 
> On Mon, Nov 06, 2017 at 02:02:46PM -0300, Megver83 wrote:
>> As we will have a build server soon, thanks to lukeshu for that, I was
>> thinking on what features should the autobuilder have. I read about
>> Buildbot which seems very interesting
>>
>> https://buildbot.net/
>>
>> I think that our autobuilder should compile when we specify it on the
>> commit. E.g. when the commit begins like "updpkg: /
>> " then compile it in the background, because if for any reason
>> the packager disconnects from the SSH then the compilation would stop,
>> but not if is in the background. That's one of the features I'm thinking
>> about RN.
>> -- 
>> ~Megver83
>>
>> SIP: megve...@sip.linphone.org
>> XMPP: megve...@jabjab.de
>> Tox: megve...@toxme.io
>> GPG: 0x227CA7C556B2BA78
>> GNUSocial: @megve...@quitter.cl
>> Diaspora*: megve...@diasp.org
>> Matrix: @Megver83:matrix.org
>>
> 
> 
> 
> 
>> ___
>> Dev mailing list
>> Dev@lists.parabola.nu
>> https://lists.parabola.nu/mailman/listinfo/dev
> 
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev
> 
or it could maybe detect the changes in a .SRCINFO file like AUR does?

-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

[Dev] Buildbot

[Megver83]

As we will have a build server soon, thanks to lukeshu for that, I was
thinking on what features should the autobuilder have. I read about
Buildbot which seems very interesting

https://buildbot.net/

I think that our autobuilder should compile when we specify it on the
commit. E.g. when the commit begins like "updpkg: /
" then compile it in the background, because if for any reason
the packager disconnects from the SSH then the compilation would stop,
but not if is in the background. That's one of the features I'm thinking
about RN.
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev