Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] [proposal] templates without official binaries
@ 2020-10-26 15:53 hippi777
  2020-10-27 11:53 ` Duncaen
                   ` (19 more replies)
  0 siblings, 20 replies; 21+ messages in thread
From: hippi777 @ 2020-10-26 15:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

New issue by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901

Description:
hi folks! :)

there are a bunch of rejected stuffs like kernel variants (like libre/xanmod/zen), browsers etc, and the reason against them is basically the compilation time and resources that they consume. (sure, others are rejected cuz of maintenance reasons, and whatever else, but those are different issues for now.)

so actually i think that it would be nice to have a way to give official blessing for some templates that could get enough backers, and that way it wouldnt be necessary to mess with merging the official master with a few other packages, while the need exists for such stuffs, and therefore there would be someone who would put the effort into those...

(also, more or less related, but dropped packages could be moved to somewhere instead of deleting them, so it can be easier to reanimate such, while im not enough deep into git wizardry, and maybe the history can be enough for this one.)

(((the basic idea came from the missing libre kernel, cuz the rest of the system is easy to be kept blob-free, and this holds back much ppl from picking up void, maybe even thats the only missing bit for a respect your freedom cert, and no matter what does that actually mean (as it isnt perfect) its still marginal for many...)))

thx for ur time, and all the bests to all of u folks! :)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
@ 2020-10-27 11:53 ` Duncaen
  2020-10-27 11:53 ` Duncaen
                   ` (18 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2020-10-27 11:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-717191594

Comment:
We already have that with restricted packages, mainly for things we are not able to redistribute.

A major problem with that is that its becomes a lot harder to check if changes don't break the currently limited amount of restricted packages.
Without binary packages in a repository, there is no fast way to look up what libraries a restricted package links, resulting in situations where a seemingly harmless change like removing a [libcurl-gnutls.so symlink](https://github.com/void-linux/void-packages/pull/25764) and then accidentally [breaking restricted packages like spotify](https://github.com/void-linux/void-packages/commit/1c81540ce821e58faa240d7a0428d90ae480f96f).

Its similar for dependencies, with packages in the repository we can go through the repository metadata and see all packages depending on another package, with restricted packages this information is limited to template files, which are not easy to parse and change depending on outside factors like the architecture meaning you have to evaluate every single template file to gather dependencies.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
  2020-10-27 11:53 ` Duncaen
@ 2020-10-27 11:53 ` Duncaen
  2020-10-27 13:20 ` hippi777
                   ` (17 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2020-10-27 11:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-717191594

Comment:
We already have that with restricted packages, mainly for things we are not allowed to redistribute.

A major problem with that is that its becomes a lot harder to check if changes don't break the currently limited amount of restricted packages.
Without binary packages in a repository, there is no fast way to look up what libraries a restricted package links, resulting in situations where a seemingly harmless change like removing a [libcurl-gnutls.so symlink](https://github.com/void-linux/void-packages/pull/25764) and then accidentally [breaking restricted packages like spotify](https://github.com/void-linux/void-packages/commit/1c81540ce821e58faa240d7a0428d90ae480f96f).

Its similar for dependencies, with packages in the repository we can go through the repository metadata and see all packages depending on another package, with restricted packages this information is limited to template files, which are not easy to parse and change depending on outside factors like the architecture meaning you have to evaluate every single template file to gather dependencies.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
  2020-10-27 11:53 ` Duncaen
  2020-10-27 11:53 ` Duncaen
@ 2020-10-27 13:20 ` hippi777
  2020-10-31 16:58 ` reback00
                   ` (16 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: hippi777 @ 2020-10-27 13:20 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-717238412

Comment:
ohh, thx, i see! :)

so, if i understood correctly, then there are some missing bits without actually running the functions inside the templates, and the info that can be obtained from the variables are insufficient, and its still not a real solution to not make actual packages but something similar with whatever info that can be obtained from the templates...

this way, i can think about 3 possibilities, or 4:

the 1st is to have them only for having a template that either works or not, but its already written and those who want to make use of it, will still need to test it on their own, but they wont need to write it from the ground up, and there is nothing much to do about these other than letting them exists with some isolation or denotation as such.

the 2nd is to get the actual metadata from those that will actually use them (maybe alongside their identity and environment), as actually running them is the missing link, and then the integrity checks can be done, while it is only reliable at this level, but not that these or things relying on them will really work, and in the worst case (mistake or bad intention) it just wont actually work. whoever would use such should be aware of this, but its still better than hunting for templates in the wild or doing it alone.

the 3rd possibility, is that if the infra, as a bottleneck, is the only showstopper, then it is to ask the community to pay for some upgrades, and i think it would work and render void that much more competitive.

the 4th is the sad path, that is letting void get fragmented by those who want to resolve common needs elsewhere, like how ymir-linux became a thing (that i found after my message :D ), that really isnt in a shiny state as of now, and i think i only saw 2 ppl there, but its about nothing that really requires a spin-off, while it could be really a strong selling point for void. (((btw i saw on the way that the ryf cert has even more crazy requirements, like the nonfree repo couldnt even exists... X'D but whatever, if void can be used without blobs with official support, then it can be advertised as such without a ryf cert.)))

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (2 preceding siblings ...)
  2020-10-27 13:20 ` hippi777
@ 2020-10-31 16:58 ` reback00
  2020-10-31 17:23 ` hippi777
                   ` (15 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-10-31 16:58 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-719959943

Comment:
@hippi777 
> (btw i saw on the way that the ryf cert has even more crazy requirements, like the nonfree repo couldnt even exists...

Well, [RYF](https://ryf.fsf.org/) is for libre hardware and [FSDG](http://www.gnu.org/distros/free-system-distribution-guidelines.html) is for Free/libre distros. So, I think you're referring to FSDG.

Yes. That's true. FSDG has many strict rules. Those are to ensure that packages remain "pure". There are so much telemetries, nonfree advertisements pointing to other apps + plugins and nonfree dependencies within the packages we use, that GNU had to be this strict to ensure distros and their packages are truely respecting our freedom and privacy. Even Linux kernel has become somewhat poisonous. Hyperbola went so far as to wanting to [develop their own BSD system](https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/) in order to escape the issues with Linux kernel and the current state of FOSS licensing and nonfree dependencies.

However, in the current state of Void it is impossible that it can be accepted as libre. Even Fedora and Debian which do not have repos with proprietary packages enabled by default, were [refused](https://www.gnu.org/distros/common-distros.html) because their default repo has some nonfree parts or they host the nonfree repo on their own server.

So, in order to get Void to be FSDG approved there has to be a massive undertaking of sorts, like:
- totally deleting `restricted` repo from server and system as if it does not exist,
- cleaning up existing packages and removing packages from main repo that can't be liberated ever,
- getting rid of `linux` kernel and only offering `linux-libre` kernel,
- changing documentations and every text to erase everything related to nonfree things (unless criticizing nonfree options),
- and there could be more things to take care of?!

@drake-newell started a [project](https://github.com/ymir-linux/void-packages) to create linux-libre kernel packages for Void. Then I joined him to contribute on "liberating" nonfree packages. As much as I understand Drake and myself, we would really be happy if we could include these packages on Void's ecosystem. We came to know that [due to resource limitations](https://www.reddit.com/r/voidlinux/comments/g3v6hl/linuxlibre_kernel_built_with_xbpssrc/fnwex2y/) custom kernels (like linux-libre) can't be accepted. Drake didn't want to create a separate project, but he had to, because how much of the package we had to liberate + custom kernel had to be kept separate. We are still friends to, and grateful to the Void Linux community.

> rejected stuffs like kernel variants (like libre/xanmod/zen), browsers etc

If you mean you want to have libre packages to be available on a Void repo, I think this would be a great idea. A separate `libre` (or some other chosen name) repo can be created. Packages with [minor issues](https://github.com/ymir-linux/void-packages/issues/8) can be there with liberated versions of them. It can be a bunch of patches over the existing srcpkgs specifying the changes to be applied on templates and files in order to liberate them. This way we can eliminate the need to merge changes from master everytime a change comes. I think this is doable.

This will not be a 100% FSDG compliance by any means, but it would be a step in the right direction. People will be able to enjoy "reasonable freedom" on their Void system.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (3 preceding siblings ...)
  2020-10-31 16:58 ` reback00
@ 2020-10-31 17:23 ` hippi777
  2020-10-31 17:47 ` reback00
                   ` (14 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: hippi777 @ 2020-10-31 17:23 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-719962998

Comment:
thx for u too! now i have a way better understanding about what im facing with! :) 

and yes, i was thinking about fsdg, i think its the right time to read more about both them, not that i would be lazy, but that i always have more things to learn/do than what i actually can :D

> were refused because their default repo has some nonfree parts or they host the nonfree repo on their own server.

this already makes the nonfree case reasonable, next time i will try to be smarter! :) 

otherwise the common ground for the templates could still be nice, but im also under educated about the requirements of this, and i hope i will catch up with things around here sooner than later :D

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (4 preceding siblings ...)
  2020-10-31 17:23 ` hippi777
@ 2020-10-31 17:47 ` reback00
  2020-11-01  9:56 ` hippi777
                   ` (13 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-10-31 17:47 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-719965729

Comment:
@hippi777 
> otherwise the common ground for the templates could still be nice, but im also under educated about the requirements of this, and i hope i will catch up with things around here sooner than later :D

Sure. Let us know if we can help in anything.

Also, if you want to get a better idea of how we liberated packages, you can check [this](https://notabug.org/reback00/void-goodies/src/master/liberatedpkgs) out. Sorry for somewhat unclear documentation for some of the packages. I wrote them as a note to myself back then without thinking about others.

We had lots of help from Parabola's [blacklist](https://git.parabola.nu/blacklist.git/plain/blacklist.txt) project. It is big list of nonfree packages with reasons for which the package is considered nonfree by Parabola community. We then work on cleaning the package based on the issue they described. ([details on how to parse it here](https://github.com/ymir-linux/void-packages/issues/8))

Each package has (a) some changes in the `template` files compared to Void's original version and/or (b) some patch added to `patches` folder. `template` changes are minor. So if we can store a diff of the template and include the patches needed for liberating, we can skip the need to store a copy of the template file. We can just apply a patch when a new version comes along, for example. The source for the `libre` repo can just be a collection of patches.

I don't have a lot of experience with big collection of patches. Can it screw things up? Maybe. But this is the solution I have so far.

Also, we have a [`your-freedom`](https://notabug.org/reback00/void-goodies/src/master/srcpkgs/your-freedom) package that once installed, conflicts with nonfree packages, so that you can't accidentally install any nonfree packages! This can also be a great tool for freedom lovers living on Void.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (5 preceding siblings ...)
  2020-10-31 17:47 ` reback00
@ 2020-11-01  9:56 ` hippi777
  2020-11-01 10:29 ` Duncaen
                   ` (12 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: hippi777 @ 2020-11-01  9:56 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720062427

Comment:
ahh, that link pointing to here from ymir made the conversation somewhat tangled, sorry for that! :D probably resolving this and bringing the two conversations to the same ground could make things better, and i guess this place is more straightforward to anything...

so, that notabug repo made the differences much cleaner, i had no idea what else differs other than the kernel, but i knew that there are more things than that... its existence was a great missing link to me, otherwise im aware of the rest, as i have read all the issues of ymir when i found it :D 

> I don't have a lot of experience with big collection of patches. Can it screw things up? Maybe. But this is the solution I have so far.

this is the thing on the very 1st place why i came up with upstreaming there, and the unused templates for things like the libre-kernel here, thinking basically about the templates, and not necessarily the packages, and i guess that actually having an isolated set of patches makes things much smoother, than having only 2 variants of the huge `void-packages` repo heading towards two directions with the possibility of having more and worse conflicts by the time, but im not into git wizardry deep enough to be confident about this, maybe its nothing more complicated than having the patches... otherwise my point was to keep those modifications under options for templates instead in patches, if and whenever its just possible and acceptable.

(((btw sorry for arriving with too much gaps in my knowledge, recently i talked about the awesomenesses of void elsewhere, and then someone showed me guix with its strong points, and told me that it isnt just a matter of not using nonfree to get a libre void, and that made me jumping into this... but still, that tastes like a "scheme fanboy distro" to me that i dont really like, and i think the musl related efforts are probably greater and more important, and moving the strong points of the 2 projects onto the same funds would be better here, as that already have been strongly built around scheme, that wont change any time soon, while picking up musl there seems to be the greater effort, at least by the amount... - but dont mind this, it was just some clearance of my background story, and i really dont want to mess up this topic even more! :D )))

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (6 preceding siblings ...)
  2020-11-01  9:56 ` hippi777
@ 2020-11-01 10:29 ` Duncaen
  2020-11-01 11:45 ` hippi777
                   ` (11 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2020-11-01 10:29 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720066389

Comment:
Are you both really discussing manual patch handling instead of using git?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (7 preceding siblings ...)
  2020-11-01 10:29 ` Duncaen
@ 2020-11-01 11:45 ` hippi777
  2020-11-01 12:05 ` Duncaen
                   ` (10 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: hippi777 @ 2020-11-01 11:45 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720075682

Comment:
im somewhat dumb to git, but not really, thats not the point, u got mislead by that i am puzzled around it....

those patches only make me understand the difference between the two projects easier, as by simply looking at the ymir repo couldnt help me to figure out their changes. maybe i didnt look hard enough, or it would require some git wizardry to find those 200 packages they patched from that 10k that void has... but this is not the point, this is probably the lack of my education. :D 

the point is that the templates can have optional variations, that is already an existing possibility, and that can be utilized by xbps-src to create the packages either this or that way as a matter of providing a flag (lets say it could even be 'libre' for this case). and the patches they maintain could probably be merged into the original template by utilizing these options. however my problem is that i dont know the scope of these options, while my inner hacker says theres no impossible.

on the contrary, i dunno if _those_ patches that come alongside the templates can be made optional, or they are applied automatically when they present, no matter what. i also dunno if linting (in case of hardcore hacking) or any magic of xbps-src would limit the scope of utilizing those options, and therefore it would prevent bringing anything onto the common ground, that is only about the templates, not the packages.

i think this could be beneficial for both projects, keeping the gap minimal, making the cooperation easier, it maybe even be a step towards a future reunion that we cant even imagine as of now, but here is the power and there is the liberation, and i see that this is a hard nut, but as far as i can think, void has the possibility to include those efforts at the level of the templates, and then the two projects can still do their own different builds.

this was the topic of my previous message.

other than that, that is the original proposal here, is for having templates for whatever stuffs that arent built officially. u can even think about it as a junkyard, where ppl can find their own treasures, that they will maybe need to work on (or maybe not), but at least they will have something to work on and that they dont need to pull out from the thin-air, like even a template for git head grub, that isnt a thing now (in general), cuz it would be a pain to maintain the builds... when someone asked for it, i could search my messy notes.txt for this https://www.reddit.com/r/voidlinux/comments/eo1y08/luks2_support_in_grub/ and i think such materies could get a common ground, and probably it would be the best to keep such gems near to the official templates to be easier to keep them more-or-less in sync with the rest of void, even if they wouldnt get much special care.

and sure, thx for ur patience! i hope i will be able to catch up by the time and become more useful! :D

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (8 preceding siblings ...)
  2020-11-01 11:45 ` hippi777
@ 2020-11-01 12:05 ` Duncaen
  2020-11-01 12:06 ` Duncaen
                   ` (9 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2020-11-01 12:05 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720078121

Comment:
https://github.com/void-linux/void-packages/compare/master...ymir-linux:master if you don't want to diff with git diff.
They didn't follow our commit title rules so you have to look at commits like "Update" and "fix scripts" to find out what they actually changed.

My position is, we don't want to maintain more patches than necessary, adding your patches for liberation, which no one of the void maintainers care about just adds more work for everyone.

There are a few possibilities how this would end up:

* We ignore those patches and libre build options and they are going to break from time to time:
  * Users who build those packages with libre options will complain, open Issues and PRs = more work.
* We have to additionally test and update libre patches we don't care at all about  = a lot more work.

With the current situation, the people who care about libre stuff can just use git to merge our repository with their changes, git is pretty smart about merging changes as it is its main purpose, maintaining a set of patches by hand seems backwards.
There is no extra work for us and the work for the libre maintainers its a very similiar amount of work as they only have to additionally resolve merge conflicts.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (9 preceding siblings ...)
  2020-11-01 12:05 ` Duncaen
@ 2020-11-01 12:06 ` Duncaen
  2020-11-01 18:13 ` reback00
                   ` (8 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2020-11-01 12:06 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720078121

Comment:
https://github.com/void-linux/void-packages/compare/master...ymir-linux:master if you don't want to diff with git diff.
They didn't follow our commit title rules so you have to look at commits like "Update" and "fix scripts" to find out what they actually changed.

My position is that we don't want to maintain more patches than necessary, adding your patches for liberation (which no one of the void maintainers care about) just adds more work for everyone.

There are a few possibilities how this would end up:

* We ignore those patches and libre build options and they are going to break from time to time:
  * Users who build those packages with libre options will complain, open Issues and PRs = more work.
* We have to additionally test and update libre patches we don't care at all about  = a lot more work.

With the current situation, the people who care about libre stuff can just use git to merge our repository with their changes, git is pretty smart about merging changes as it is its main purpose, maintaining a set of patches by hand seems backwards.
There is no extra work for us and the work for the libre maintainers its a very similiar amount of work as they only have to additionally resolve merge conflicts.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (10 preceding siblings ...)
  2020-11-01 12:06 ` Duncaen
@ 2020-11-01 18:13 ` reback00
  2020-11-01 18:14 ` reback00
                   ` (7 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-11-01 18:13 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720129719

Comment:
@Duncaen 
> They didn't follow our commit title rules so you have to look at commits like "Update" and "fix scripts" to find out what they actually changed.

We didn't plan for merging with upstream. Maybe that's our bad. But we didn't think it's ever going to be merged with upstream, at least not like it's done currently. The templates are directly changed on their place, which is designed for a full libre experience, replacing their nonfree versions. We thought Void will never accept that. So we didn't follow those rules.

If Void ever decides to introduce a libre repo, those commits will not be used. Instead changes will have to be made separately (for the libre repo packages). So I guess this should be fine. But let us know if you think otherwise.

> My position is that we don't want to maintain more patches than necessary, adding your patches for liberation (which no one of the void maintainers care about) just adds more work for everyone.

I hope that more void maintainers will be interested in future to get at least some form of libre experience into Void. This is not only important for user freedom but sometimes important for security and privacy as well. Purism and others are working towards a libre environment. I hope maintainers understand what it brings for the community.

>  the original proposal here, is for having templates for whatever stuffs that arent built officially. u can even think about it as a junkyard, where ppl can find their own treasures, that they will maybe need to work on (or maybe not)

btw... is this happening? This will be a blessing since I heard many complaining that there aren't enough packages on official repos. If there is a separate repo for user packages they can be found in one place rather than being scattered throughout the web.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (11 preceding siblings ...)
  2020-11-01 18:13 ` reback00
@ 2020-11-01 18:14 ` reback00
  2020-11-01 18:17 ` reback00
                   ` (6 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-11-01 18:14 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720129719

Comment:
@Duncaen 
> They didn't follow our commit title rules so you have to look at commits like "Update" and "fix scripts" to find out what they actually changed.

We didn't plan for merging with upstream. Maybe that's our bad. But we didn't think it's ever going to be merged with upstream, at least not like it's done currently. The templates are directly changed on their place, which is designed for a full libre experience, replacing their nonfree versions. We thought Void will never accept that. So we didn't follow those rules.

If Void ever decides to introduce a libre repo, those commits will not be used. Instead changes will have to be made separately (for the libre repo packages). So I guess this should be fine. But let us know if you think otherwise.

> My position is that we don't want to maintain more patches than necessary, adding your patches for liberation (which no one of the void maintainers care about) just adds more work for everyone.

I hope that more Void maintainers will be interested in future to get at least some form of libre experience into Void. This is not only important for user freedom but sometimes important for security and privacy as well. Purism and others are working towards a libre environment. I hope maintainers understand what it brings for the community.

>  the original proposal here, is for having templates for whatever stuffs that arent built officially. u can even think about it as a junkyard, where ppl can find their own treasures, that they will maybe need to work on (or maybe not)

btw... is this happening? This will be a blessing since I heard many complaining that there aren't enough packages on official repos. If there is a separate repo for user packages they can be found in one place rather than being scattered throughout the web.

Edit: uppercase

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (12 preceding siblings ...)
  2020-11-01 18:14 ` reback00
@ 2020-11-01 18:17 ` reback00
  2020-11-01 20:06 ` hippi777
                   ` (5 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-11-01 18:17 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720129719

Comment:
@Duncaen 
> They didn't follow our commit title rules so you have to look at commits like "Update" and "fix scripts" to find out what they actually changed.

We didn't plan for merging with upstream. Maybe that's our bad. But we didn't think it's ever going to be merged with upstream, at least not like it's done currently. The templates are directly changed on their place, which is designed for a full libre experience, replacing their nonfree versions. We thought Void will never accept that. So we didn't follow those rules.

If Void ever decides to introduce a libre repo, those commits will not be used. Instead changes will have to be made separately (for the libre repo packages). So I guess this should be fine. But let us know if you think otherwise.

> My position is that we don't want to maintain more patches than necessary, adding your patches for liberation (which no one of the void maintainers care about) just adds more work for everyone.

I hope that more Void maintainers will be interested in future to get at least some form of libre experience into Void. This is not only important for user freedom but sometimes important for security and privacy as well. Purism and others are working towards a libre environment. I hope maintainers understand what it brings for the community.

>  the original proposal here, is for having templates for whatever stuffs that arent built officially. u can even think about it as a junkyard, where ppl can find their own treasures, that they will maybe need to work on (or maybe not)

btw... is this happening? This will be a blessing since I heard many complaining that there aren't enough packages on official repos. If there is a separate repo for user packages they can be found in one place rather than being scattered throughout the web.

They won't have to go through build process. But to be manually built by users, just like AUR.

Edit: uppercase, build process

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (13 preceding siblings ...)
  2020-11-01 18:17 ` reback00
@ 2020-11-01 20:06 ` hippi777
  2020-11-01 22:31 ` fosslinux
                   ` (4 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: hippi777 @ 2020-11-01 20:06 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720143673

Comment:
thank u very much Duncaen! :) i think i finally got to the point, and i should say it is fine then this way (i mean not messing with the template options) - or at least after all i dare to hope so... :D


> btw... is this happening? This will be a blessing since I heard many complaining that there aren't enough packages on official repos. If there is a separate repo for user packages they can be found in one place rather than being scattered throughout the web.

this is the very essence of my proposal, and it sounds like the need for it really exists, however i made no steps towards it, and im not aware of anything like that...


i think what u, Duncaen, explained to me applies more-or-less to the case of the extra/dropped templates too, but as those wouldnt necessarily mess with the blessed templates or the packaging, they could still get a place to exists, and why i came here is that keeping such resources around the official stuffs would make them discoverable.

and yep, i know this smells like aur and i saw anticipation about that previously (maybe that was the git head grub :D ), but as of my understanding, that was about the maintainability of them, while that isnt a necessary requirement as of my proposal. so the question that remains here is whether it could get a repo under the flagship of github.com/void-linux, or maybe a directory somewhere inside github.com/void-linux/void-packages, as i guess that these options could make any related workflow any smoother, but u will know that better. the downside of the latter is that it would generate some noise for the packagers, and the former would still need the staff to merge whatever would come there. and still, i mean that these would be denoted as not being too much distinct from a junkyard with possible gems for common needs that doesnt fit, while it is still better than making things from the ground up or even hunting for them on various grounds.

after all, if it isnt a thing that the maintainers would welcome to be too near, it can still be done elsewhere, and it can still get a pointer from somewhere, but the question is if it could worth for any reason to keep such near or not? maybe it could even become a thing like aur by the time, maybe it can be started elsewhere and a reason to make an official fork could arose, so after all, this isnt that much of a cardinal question, but it may still worth to think about it, and to ask it. either way, a decision about it will draw the path for any continuation.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (14 preceding siblings ...)
  2020-11-01 20:06 ` hippi777
@ 2020-11-01 22:31 ` fosslinux
  2020-11-01 22:34 ` fosslinux
                   ` (3 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: fosslinux @ 2020-11-01 22:31 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

New comment by fosslinux on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720162082

Comment:
I've been thinking about this for a while. I don't think anything like the AUR is a good idea, as it exposes void to much of the issues of the AUR and security issues there without much review.

I think there are two reasonable compromises:

1. Adding an alternative secondary void-packages repository that is not confirmed to be working, as no official upstream support for a lack of breakage and is fully community managed. A select group of people accept PRs to this repository, like with void-packages - maybe a different group of people?? Idk, a rough idea.
2. Alternatively, add a page to docs.voidlinux.org containing a list of secondary source and binary package repositories that are "endorsed" by Void for specific wants by users.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (15 preceding siblings ...)
  2020-11-01 22:31 ` fosslinux
@ 2020-11-01 22:34 ` fosslinux
  2020-11-02 16:12 ` reback00
                   ` (2 subsequent siblings)
  19 siblings, 0 replies; 21+ messages in thread
From: fosslinux @ 2020-11-01 22:34 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

New comment by fosslinux on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720162082

Comment:
I've been thinking about this for a while. I don't think anything like the AUR is a good idea, as it exposes void to much of the issues of the AUR and security issues there without much review.

I think there are two reasonable compromises:

1. Adding an alternative secondary void-packages repository that is not confirmed to be working, as no official upstream support for a lack of breakage and is fully community managed. A select group of people accept PRs to this repository, like with void-packages - maybe a different group of people?? Idk, a rough idea.
2. Alternatively, add a page to docs.voidlinux.org containing a list of secondary source and binary package repositories that are "endorsed" by Void for specific wants by users. IDEA: add packages like `void-repo-multilib` like `secondary-repo-ymir` that add repository entries for those that have binary repos.

However, I understand if this doesn't really align with the maintainers and I would see why that is as a contributor.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (16 preceding siblings ...)
  2020-11-01 22:34 ` fosslinux
@ 2020-11-02 16:12 ` reback00
  2022-04-22  2:14 ` github-actions
  2022-04-22 15:56 ` [ISSUE] [CLOSED] " Duncaen
  19 siblings, 0 replies; 21+ messages in thread
From: reback00 @ 2020-11-02 16:12 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720569106

Comment:
> 1. Adding an alternative secondary void-packages repository that is not confirmed to be working, as no official upstream support for a lack of breakage and is fully community managed. A select group of people accept PRs to this repository, like with void-packages - maybe a different group of people?? Idk, a rough idea.
> 2. Alternatively, add a page to docs.voidlinux.org containing a list of secondary source and binary package repositories that are "endorsed" by Void for specific wants by users. IDEA: add packages like void-repo-multilib like secondary-repo-ymir that add repository entries for those that have binary repos.

I'd prefer # 1. Seems like less of a mess than to clone multiple repos just to get some handful of packages working. Another issue may be that if # 2 lists binary packages, odds are, some old unmaintained binary will break with a system upgrade.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (17 preceding siblings ...)
  2020-11-02 16:12 ` reback00
@ 2022-04-22  2:14 ` github-actions
  2022-04-22 15:56 ` [ISSUE] [CLOSED] " Duncaen
  19 siblings, 0 replies; 21+ messages in thread
From: github-actions @ 2022-04-22  2:14 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-1105933503

Comment:
Issues become stale 90 days after last activity and are closed 14 days after that.  If this issue is still relevant bump it or assign it.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [ISSUE] [CLOSED] [proposal] templates without official binaries
  2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
                   ` (18 preceding siblings ...)
  2022-04-22  2:14 ` github-actions
@ 2022-04-22 15:56 ` Duncaen
  19 siblings, 0 replies; 21+ messages in thread
From: Duncaen @ 2022-04-22 15:56 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

Closed issue by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901

Description:
hi folks! :)

there are a bunch of rejected stuffs like kernel variants (like libre/xanmod/zen), browsers etc, and the reason against them is basically the compilation time and resources that they consume. (sure, others are rejected cuz of maintenance reasons, and whatever else, but those are different issues for now.)

so actually i think that it would be nice to have a way to give official blessing for some templates that could get enough backers, and that way it wouldnt be necessary to mess with merging the official master with a few other packages, while the need exists for such stuffs, and therefore there would be someone who would put the effort into those...

(also, more or less related, but dropped packages could be moved to somewhere instead of deleting them, so it can be easier to reanimate such, while im not enough deep into git wizardry, and maybe the history can be enough for this one.)

(((the basic idea came from the missing libre kernel, cuz the rest of the system is easy to be kept blob-free, and this holds back much ppl from picking up void, maybe even thats the only missing bit for a respect your freedom cert, and no matter what does that actually mean (as it isnt perfect) its still marginal for many...)))

thx for ur time, and all the bests to all of u folks! :)

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-04-22 15:56 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-26 15:53 [ISSUE] [proposal] templates without official binaries hippi777
2020-10-27 11:53 ` Duncaen
2020-10-27 11:53 ` Duncaen
2020-10-27 13:20 ` hippi777
2020-10-31 16:58 ` reback00
2020-10-31 17:23 ` hippi777
2020-10-31 17:47 ` reback00
2020-11-01  9:56 ` hippi777
2020-11-01 10:29 ` Duncaen
2020-11-01 11:45 ` hippi777
2020-11-01 12:05 ` Duncaen
2020-11-01 12:06 ` Duncaen
2020-11-01 18:13 ` reback00
2020-11-01 18:14 ` reback00
2020-11-01 18:17 ` reback00
2020-11-01 20:06 ` hippi777
2020-11-01 22:31 ` fosslinux
2020-11-01 22:34 ` fosslinux
2020-11-02 16:12 ` reback00
2022-04-22  2:14 ` github-actions
2022-04-22 15:56 ` [ISSUE] [CLOSED] " Duncaen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).