Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Mon, 3 Apr 2023 00:28:28 -0400
bill-auger  wrote:

> On Mon, 3 Apr 2023 04:26:54 +0200 Denis wrote:
> > And as you pointed in another mail, that's already covered as in an
> > "actively maintained" criteria.
> 
> a bit too vaguely though, to capture this "action-ability"
> concern - uruk would pass most of the criteria transitively
> via pureos, including "actively maintained"; but it is
> maintained by another distro, so not "actionable" by the uruk
> maintainers
If the goal is to respect the FSDG, users can also report to PureOS
directly.

> the FSDG only requires that distros are willing to address
> freedom bugs - it does not explicitly say that they must be
> _able_ to - presumably, that "action-ability" was taken for
> granted (not specified, because it was assumed to always be the
> case); but in the case of a supplemental spin-off, it is not the
> case - such distros can only manage the supplemental packages

I think that the section about that is here:
> Most distribution development teams don't have the resources to
> exhaustively check that their distribution meet all these criteria.
> Neither do we. So we expect distros to occasionally contain mistakes:
> nonfree software that slipped through, etc. We don't reject a
> distribution over mistakes. Our requirement is for the distribution
> developers to have a firm commitment to promptly correct any mistakes
> that are reported to them.

But distributions probably cannot have firm commitment to correct
mistakes if they are knowingly setup specifically to not be able to
correct these mistakes. 

Though they could also make mistake about their infrastructure, setup,
dependencies and so on and accidentally get in a situation where they
cannot easily fix things.

Parabola is in this situation with the licenses of the packages
definition that isn't very clear. So depending on the authors, the
specific packages definitions, and maybe the licenses of the packages
depending on how you interpret the GPL(v2/3?), it could be considered
nonfree, non-copyrightable or under free licenses (a minority of
packages definitions have licenses).

Replicant also got in a situation like that because at some point it
depended on Debian main instead of FSDG approved distributions (I've
spent a lot of time trying various approaches to fix that but it's not
easy, so help would be welcome there). We'd also need help to review
the repositories licenses as some nonfree source code can more easily
slip in Replicant than in distributions that have package definitions.

This text also seems to work with the situation where there is just too
much packages to fix (for instance with third party package managers
that slip in everywhere): the "firm commitment" can work if the
distribution start addressing the problem.

Denis.


pgp4oE6IW4WXb.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Mon, 3 Apr 2023 04:26:54 +0200 Denis wrote:
> And as you pointed in another mail, that's already covered as in an
> "actively maintained" criteria.

a bit too vaguely though, to capture this "action-ability"
concern - uruk would pass most of the criteria transitively
via pureos, including "actively maintained"; but it is
maintained by another distro, so not "actionable" by the uruk
maintainers

the FSDG only requires that distros are willing to address
freedom bugs - it does not explicitly say that they must be
_able_ to - presumably, that "action-ability" was taken for
granted (not specified, because it was assumed to always be the
case); but in the case of a supplemental spin-off, it is not the
case - such distros can only manage the supplemental packages

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Fri, 31 Mar 2023 00:36:57 -0400
bill-auger  wrote:
> i did not intend to be so specific about the infra, such as to
> own all hardware and operate all services - there is no criteria
> about SaaSS, for example - i only meant that the distro should
> be able to fix bugs and freedom issues in any portion of the
> distro, at any time - to do that, requires controlling what gets
> built and published
[...]
> it would not significantly alter the review process - there
> should be no need to scrutinize the infra, beyond determining
> that the distro maintainers can control what gets built and
> published

If the goal is to make sure that the distribution can fix things, then
it's probably better to require exactly that, instead of requiring
a specific way to do it (self hosting the infrastructure).

And to have the exact implementation be an implementation detail that
can be reviewed, discussed and so on.

And as you pointed in another mail, that's already covered as in an
"actively maintained" criteria.

Denis.


pgp9bGmbyo1ZV.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Fri, 31 Mar 2023 04:57:44 +0200 Denis wrote:
> > the point of the 2018 changes and the "brief final review", was
> > that the community would do all of the difficult and
> > time-consuming work - the FSF only needs to read the mailing
> > list messages, and can largely trust the reviewers findings
> > the FSF's role needs to be no more than to double-check what
> > the "application manager" has documented  
> The issue here may be precisely the amount of work needed to do this
> double-check.

i could give two points of reference - pureos and hyperbola were
fully reviewed and endorsed within a few (2-3) months - you made
the argument that hyperbola was easier, because it was a fork of
an already-endorsed distro - but pureos was not - if that was a
factor, i would expect that pureos would have taken much longer
than hyperbola, for that reason alone - there was obviously much
more to double-check

also, the hyperbola review took place after the change which
relieved most of the work from the FSF - the brief final review
was all that the FSF needed to do for hyperbola - that makes two
factors which should have made the pureos process much longer -
but it was not

there is probably a third factor also - hyperbola's package
selection is much more modest than the average distro - it has
many fewer bloated GUI applications (eg: no desktop suites such
as GNOME, KDE, etc), which is where the majority of freedom and
privacy problems are found

to me, that suggests that either the double-checking is not very
demanding, or that the FSF was watching the pureos process unfold
(reading the mailing list), or was involved directly all along,
and so a secondary double-checking phase was not needed

either way, it suggest that a review (if without delays) takes
less than 3 months, regardless of the distro, or the portion of
the workload done by the FSF

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Thu, 30 Mar 2023 00:28:56 +0200 Denis wrote:
> > that may be a adequate clarification, what i would add to the
> > "complete distros" section:
> >   
> > > Distro maintainers must have complete autonomy over all software
> > > that they distribute.  
> > 
> > i really dont think that is expecting too much - i would tend to
> > see it as essential, if i were choosing a distro  
> If the question here is to make the review faster, I don't see any
> issue so far.
> 
> If instead the question here here is what is FSDG compliant, there
> is the issue of defining that precisely. 
> 
> If a distro runs a VM, does it need to control the underlying hardware?

i did not intend to be so specific about the infra, such as to
own all hardware and operate all services - there is no criteria
about SaaSS, for example - i only meant that the distro should
be able to fix bugs and freedom issues in any portion of the
distro, at any time - to do that, requires controlling what gets
built and published

for example, i would be fine if the distro hosted all source
code, recipes, and binary packages on github, sourceforge,
whatever, with all packages auto-built by a third-party CI
service - the point is that the distro would be in control over
what gets built, and when, the exact recipes, etc

naturally, security issue come into play; but i think you are
correct, in that there is no criteria requiring software to be
secure

it would not significantly alter the review process - there
should be no need to scrutinize the infra, beyond determining
that the distro maintainers can control what gets built and
published

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Mon, 27 Mar 2023 13:12:54 -0400
bill-auger  wrote:

> On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> > Here the issue is that I fear that no one will commit to do the full
> > review, but small parts were already reviewed by different people  
> 
> no single person needs to commit to do the entire review - one
> person needs to commit to over-see the process, collect the
> findings, manage the checklist, organize the discussions, then
> open a licensing ticket when all is done (and pester the FSF if
> it is ignored for 5 years), and so on
OK.

> i added the review checklist to that page, and moved it out of
> the "incoming" name-space - the page should remain, even after it
> is no longer "incoming", though maybe the extended notes could
> be deleted eventually
> 
> https://libreplanet.org/wiki/Uruk
Thanks a lot.

> On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> > My main concern here is to find a process that can easily be checked
> > later on by someone else.  
> 
> that was somewhat the idea for the checklist - any detected
> problems should be summarized on the checklist - the wiki
> change history could be reviewed at any later time
Yes, that makes things easier, but the issue is how to trust it not to
have missed too important things.

For instance if someone reviews uruk-cleaner, without contributing to
the free software directory along the way, we'd need to re-do the same
work to check if that review is valid.

Also do we need to review the package or the upstream git? And can
there be discrepancies between both?

Here using the free software directory would help as there is already a
process to take care of reviews by people, and the name of people is
also recorded, so over time people can build reputations through that
system.

So here we can even trust people with specific reputations (like a
reputation to find problematic things in software but do only a quick
review, a reputation to do the review in depth, etc).

So the checks I was talking about were more for this fine grained level.

And here some light automation can be useful too as it could also help
bridging the gap between uruk-cleaner's git and uruk-cleaner's package
(we probably need to review the git for the free software directory and
the package for the FSDG and we want to avoid doing the work twice).

You can also ask questions through code when you have parsable data.
For instance is there any GPLv2-only package that uses OpenSSL as a
dependency? Obviously that won't tell how OpenSSL is used (it could be
through the 'openssl' command line application or by linking to it) so
you'd still need a human in the loop.

And some of the code to ask questions can also be shared, so that work
is then reusable for distributions using the same package managers for
instance.

> notwithstanding, the FSF's "brief final review" of hyperbola
> should have been de-prioritized, queued behind the ones which
> were already fully evaluated by the community
The downside of that could be an even bigger blocking of the process if
my hypothesis is right.

> the point of the 2018 changes and the "brief final review", was
> that the community would do all of the difficult and
> time-consuming work - the FSF only needs to read the mailing
> list messages, and can largely trust the reviewers findings
> the FSF's role needs to be no more than to double-check what
> the "application manager" has documented
The issue here may be precisely the amount of work needed to do this
double-check.

Denis.


pgpwrwKFuYzSD.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Tue, 28 Mar 2023 21:49:18 -0400
bill-auger  wrote:

> On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> > That said, there may or may not be requirements that are not in
> > the FSDG (for instance if the FSDG is not complete, or because no
> > one though of new problematic cases or issues, or just because some
> > class of problems usually never happens for one reason or another).
> 
> its probably all of those things - i prefer to be as rigorous
> as possible though - at least to sort things out, make some
> determinations, and most importantly, to docujments them and
> apply them, rather then leaving unnecessarily vague things remain
> vague and contentious - arguments about the vagueness of the
> FSDG, account for the majority of time spent on this mailing
> list - it is very inefficient
I also agree with that.

Here I insisted on having the right justification for that because even
if the result is the same in this case, the justification has
real impacts: for instance if infrastructure self-hosting was inside the
FSDG, then it would also have implications for existing distributions.

If we instead ask for things with the rationale to simplify the review,
it has no impact on existing distributions that were already reviewed.

And generally speaking that keeps things simple and we don't have to
think about the consequences of interpreting the FSDG differently.

> On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> > And I think that not self-hosting your own infrastructure is not
> > necessarily a binary situation: for instance Guix doesn't control
> > all its infrastructure (because GNU, not Guix controls part of it)
> > 
> > A requirement like that would also forbid using savannah for hosting
> > your source code, forbid secondary mirrors managed by the project,
> > etc.
> 
> to sort that out: there is a huge difference between GNU
> managing the infra for GNU projects, vs relying on a completely
> unrelated third-party, which has no obligation to provide those
> services to the project - GNU is obligated to GNU projects -
> pureos is not obligated to uruk in the same way (not in any way,
> in fact) - pureos has every right to obstruct uruk users from
> accessing their servers
Good point. The CHATONS and even states also reason like that where they
try to understand compatibility with their charter or their laws,
with other entities terms of services, state laws, with the business
model of the entity, etc.

In this case non-gnu Savannah is probably OK too even if it's not GNU
(depending on the usage of Savannah, more on that later).

> likewise, hosting your source code on a third-party forge is
> still very different - i would recommend against that; but still,
> the project has sufficient autonomy using forges - they can
> decide what goes in or out of it, fix bugs, and so on - i would
> consider that as sufficiently providing and maintaining that
> source code - but in this case, the majority of the software in
> uruk, is literally "not provided" nor maintained by that distro
> - the distro maintainers have zero control over the majority of
> the software that their users use
I think that here a "SASS" criteria fits way better because it really
depends on how you use a forge.

If you use the forge as git hosting (that could also include mirroring
your git repository across different forges for backup purposes only),
then the project might not need to be able to modify the way it works
(as long as it doesn't bring in other issues like surveillance, nonfree
JavaScript, etc).

If somehow the project depends on computing done in the forge, then
SASS applies and it's a good idea to have the project be be in control
of the forge somehow.

There are also ways to deal with untrustworthy forges in some ways,
like to sign the commits with gpg signatures for instance, but that
seems to be out of the scope of the FSDG as the FSDG also accepts
distributions with known security issues that aren't fixed (like
Dynebolic or Replicant 6.0).

Anyway I've started to document the status of security in various
FSDG distros to inform users and encourage security, but I also need
help:
https://libreplanet.org/wiki/Group:Software/FSDG_distributions/Security

> i think that discrepancy is very significant - the distro should
> have complete autonomy over all distributed software - all that
> uruk would need to do, is to mirror the pureos repos, to gain
> complete autonomy to filter it, or replace packages with
> bug-fixed versions, etc
>
> that may be a adequate clarification, what i would add to the
> "complete distros" section:
> 
> > Distro maintainers must have complete autonomy over all software
> > that they distribute.
> 
> i really dont think that is expecting too much - i would tend to
> see it as essential, if i were choosing a distro
If the question here is to make the review faster, I don't see any
issue so far.

If instead the question here here is what is FSDG compliant, there
is the issue of defining that 

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> That said, there may or may not be requirements that are not in
> the FSDG (for instance if the FSDG is not complete, or because no one
> though of new problematic cases or issues, or just because some class
> of problems usually never happens for one reason or another).

its probably all of those things - i prefer to be as rigorous
as possible though - at least to sort things out, make some
determinations, and most importantly, to docujments them and
apply them, rather then leaving unnecessarily vague things remain
vague and contentious - arguments about the vagueness of the
FSDG, account for the majority of time spent on this mailing
list - it is very inefficient


On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> And I think that not self-hosting your own infrastructure is not
> necessarily a binary situation: for instance Guix doesn't control all
> its infrastructure (because GNU, not Guix controls part of it)
> 
> A requirement like that would also forbid using savannah for hosting
> your source code, forbid secondary mirrors managed by the project, etc.

to sort that out: there is a huge difference between GNU
managing the infra for GNU projects, vs relying on a completely
unrelated third-party, which has no obligation to provide those
services to the project - GNU is obligated to GNU projects -
pureos is not obligated to uruk in the same way (not in any way,
in fact) - pureos has every right to obstruct uruk users from
accessing their servers

likewise, hosting your source code on a third-party forge is
still very different - i would recommend against that; but still,
the project has sufficient autonomy using forges - they can
decide what goes in or out of it, fix bugs, and so on - i would
consider that as sufficiently providing and maintaining that
source code - but in this case, the majority of the software in
uruk, is literally "not provided" nor maintained by that distro
- the distro maintainers have zero control over the majority of
the software that their users use

i think that discrepancy is very significant - the distro should
have complete autonomy over all distributed software - all that
uruk would need to do, is to mirror the pureos repos, to gain
complete autonomy to filter it, or replace packages with
bug-fixed versions, etc

that may be a adequate clarification, what i would add to the
"complete distros" section:

> Distro maintainers must have complete autonomy over all software that they 
> distribute.

i really dont think that is expecting too much - i would tend to
see it as essential, if i were choosing a distro

despite my preference on this topic, i would like to concede
this for now - i have offered a proposal to accommodate this
situation, as something of a concession - maybe that would
satisfy everyone


On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> Though for now it's probably easier to just focus on the review of uruk
> right now and for things that are not inside the FSDG, to request
> changes like that on the basis of making the review faster.

its really all we can do now - my concern now is only of the
future - it appears to me, that this review of uruk is going to
get snagged against the past unresolved problems with the FSDG
itself - it has already gotten snagged on the mis-management
problem; but there are others lurking ahead on the path - the
kernel in that repo is another major unresolved conflict for
this work-group

indeed, most of the review could be done now, and i think that it
should be; but IMHO this distro should not be able to pass review
on the face of it, due to the current circumstances - the FSDG
status of pureos is contingent on the resolution of two major
long-standing unresolved conflicts - i am not comfortable
bringing in another with the same contingencies, until those
conflicts get resolved

in fact i am not pleased to be involved in this work-group at
all, until those conflicts get resolved

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Mon, 27 Mar 2023 10:56:47 -0400
bill-auger  wrote:

> On Mon, 27 Mar 2023 16:31:51 +0200 Denis wrote:
> > As I understand, self-hosting has a completely different meaning
> > here: it's not about hosting your own infrastructure and it has
> > nothing to do with infrastructure at all.
> 
> i really think it implies both - the word "provide" would make
> no sense, if the distro does not provide the software, but
> refers users to a third-party, who has no obligation to provide
> anything to those users

Self-hosting is kind of defined as:
> In particular, a free system distribution should be self-hosting.
> This means that you must be able to develop and build the system with
> tools that the system provides you. As a result, a free system
> distribution cannot include free software that can only be built by
> using nonfree software.

So if you install Replicant on a device, you can't build Replicant (the
system) with tools that the system provides you. This most likely
applies to LibreCMC and ProteanOS too: You probably don't have packages
in LibreCMC that enable you to build LibreCMC on a computer running
LibreCMC, though I'm not aware of somebody that tried to do that[1].

Then we have:
> We make an exception to this requirement for small system
> distributions, which are distros designed for devices with limited
> resources, like a wireless router for example. Free small system
> distributions do not need to be self-hosting or complete, because it
> is impractical to do development on such a system, but it must be
> developable and buildable on top of a free complete system
> distribution from our list of distributions, perhaps with the aid of
> free tools distributed alongside the small system distribution itself.

So here "small" fits well for cases like LibreCMC where some supported
devices have 8MiB of storage space, so that makes it "impractical to
do development on such a system". You could probably add external
storage, mount an NFS share, etc, though that is not very practical as
probably not all devices have usb host.

Here I don't think these two paragraph have something to do with where
the web server of the project homepage is running.

That said, there may or may not be requirements that are not in
the FSDG (for instance if the FSDG is not complete, or because no one
though of new problematic cases or issues, or just because some class
of problems usually never happens for one reason or another).

And I think that not self-hosting your own infrastructure is not
necessarily a binary situation: for instance Guix doesn't control all
its infrastructure (because GNU, not Guix controls part of it), but Guix
is part of the GNU project and GNU probably controls all or at least
most of its infrastructure.

A requirement like that would also forbid using savannah for hosting
your source code, forbid secondary mirrors managed by the project, etc.

Though a possible way to improve that would be to see if/how the FSDG
could rely on the "GNU ethical repository criteria" for instance and
require a better grade than F. Though the downside is that it would
require to review the forges being used as well.

Also having parts about "SASS" would probably be a better fit than
requiring things about self-hosting your own infrastructure.

If we'd want to define infrastructure self-hosting, there is a
collective called CHATONS / KITTENS that has a charter about hosting
that defines the CHATONS obligations toward users, that could probably
be reused somehow to define infrastructure self-hosting requirements[2]
as they have to self-host to provide services to its users (which are
not self-hosted as the CHATON host things for users).

And inside that charter there are clauses like that:
> the CHATON must have root access on the operating system running the
> final online services;

So here if some trusted entity that isn't the distribution (like the
FSF for instance) provides a mirror or some space to host files operated
by the project:
- If we have some not-SASS requirements, here it's not SASS so it should
  be OK.
- If we have some the-distro-needs-to-self-host-its-infrastructure
  requirement it's not OK anymore because this is not self-hosting.

If needed, extra requirements could probably then be added (if they
make sense) to for instance make sure that users are not spied on by the
mirrors for instance, that the mirror content is under the distro
control somehow, etc.

Though a document detailing all that would probably also be useful for
other cases, like hosting releases, websites and so on for projects
(like GNU software or other projects that want to use such criteria).

At least some GNU toolchain components (through Sourceware) have a
separate infrastructure from GNU, so there may already be some
requirements or information somewhere about the infrastructure that
could be reused.

Though for now it's probably easier to just focus on the review of uruk
right now and for things that are not inside the 

Re: [GNU-linux-libre] review of uruk

[bill-auger]

the mailing list appears to be functional - i was able to
subscribe to the uruk mailing list today - the mailman website
(https://lists.tuxfamily.org/) is currently broken - i assume
that the host is having a temporary problem

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Mon, 27 Mar 2023 17:12:13 -0700 Jason wrote:
> In addition, the IRC channel and mailing lists mentioned on
> urukproject.org appear to be unavailable.

to be clear, that is part of the "actively maintained" criteria
- as those channels are the only contact information given on the
project website; this currently fails that criteria

just to note, this is another good example of why to avoid using
third-party services to host critical infra - the "actively
maintained" criteria considers communication to be critical -
o/c there is no criteria about using third-party services for
that, as long as users do not need to run non-free software to
communicate with the project - its just a very good idea

i see it as a natural corollary to software freedom; and that is
why i would prefer to hold the "complete distro" criteria to
it's strict interpretation - software users need to be able to
control their own computing - likewise, software projects need
to be able to control their own infrastructure, for all of the
same reasons

Re: [GNU-linux-libre] review of uruk

[Jason Self]

As I look through Uruk, the ISO files appears to be downloadable from
SourceForge but I'm not finding the source code for those. Where is
that located in order to generate them? I don't seem to find any
information on urukproject.org or the SourceForge project.

In addition, the IRC channel and mailing lists mentioned on
urukproject.org appear to be unavailable. Where do community members
interact?


pgpxEi3FW4lfj.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> Here the issue is that I fear that no one will commit to do the full
> review, but small parts were already reviewed by different people

no single person needs to commit to do the entire review - one
person needs to commit to over-see the process, collect the
findings, manage the checklist, organize the discussions, then
open a licensing ticket when all is done (and pester the FSF if
it is ignored for 5 years), and so on


On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> I've started to look a bit into it[2], but I'm unsure if it's the right
> approach (like does it reviews the right things?) and I've questions on
> how to automatize all that.

i thought about automation too; but that itself would be a lot
of work to implement, and the results would always be dubious -
at best it could be a guide; but thats a lot of effort to put
into a guide

i added the review checklist to that page, and moved it out of
the "incoming" name-space - the page should remain, even after it
is no longer "incoming", though maybe the extended notes could
be deleted eventually

https://libreplanet.org/wiki/Uruk


On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> My main concern here is to find a process that can easily be checked
> later on by someone else.

that was somewhat the idea for the checklist - any detected
problems should be summarized on the checklist - the wiki
change history could be reviewed at any later time


On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> Here the fact that Hyperbola comes before liberty-bsd is compatible
> with that hypothesis because maybe Hyperbola was way faster to check.
> Hyperbola is also way easier to understand than a BSD distribution

notwithstanding, the FSF's "brief final review" of hyperbola
should have been de-prioritized, queued behind the ones which
were already fully evaluated by the community

the point of the 2018 changes and the "brief final review", was
that the community would do all of the difficult and
time-consuming work - the FSF only needs to read the mailing
list messages, and can largely trust the reviewers findings
the FSF's role needs to be no more than to double-check what
the "application manager" has documented

freenix and liberty-bsd were already ready and waiting before
hyperbola even applied - they should have been accepted first;
which means that hyperbola should still be waiting - that would
have been fair - the FSF and this work-group have been very
unfair to some distros - we should not ignore that any longer,
or make any excuses

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Fri, 24 Mar 2023 18:25:46 -0700
alimiracle  wrote:

>  > After a quick glance of the Uruk website, technologies such as   
> Docker, SourceForge, GitHub and CloudIDE invites to take a closer
> look: cloude ide is not part of uruk distro
> its part of uruk project
> and docker is free
> but if the  ide and docker image must removed we will remove it
Personally I don't see the issue with the docker image if what's inside
that image is FSDG compliant.

> As you know Pure is a free distribution as the FSF says
> We used it because we thought Pure was completely free
> Honestly, I'm starting to doubt pure's credibility
> What do you advise us to do, do we remove and replace the browser or
> is there another more practical solution
I started to look how to contribute to PureOS, but all I found is a
policy that requires to upstream changes in Debian whenever possible.

Beside that, it seems possible to contribute to PureOS to fix FSDG
compliance issues, but I'm unsure of the way to do that.

In Trisquel for instance, I've tested the process for real, and
some of the freedom issues I've reported were not fixed because of the
lack of time, but as soon as I sent patches to fix these issues, the
patches were discussed and integrated relatively rapidly.

So at least in the cases I found, at the time, patches were the
way that worked best.

So for PureOS we probably need to find a way to get these fixed in some
ways, and maybe if someone sends patches in addition of the bug
reports, maybe getting things fixed would work. Or maybe there is
another process for that?

> far be it from me to only complain about a problem, without
> offering to help solve it - over the previous thread, i did not
> see anyone step forward and volunteer to review uruk
> 
> it would be hypocritical for the work-group to also be idle, in
> this time when the FSF is under-staffed
I think we also need to find a way that works for us (people
interested in reviewing distros).

Reviewing a full distro can be very time consuming. And the amount of
changes uruk does is pretty small, so that would be a great opportunity
to find ways that work and reuse them afterward on bigger distros.

Uruk is indirectly based on Debian and I don't know well enough Debian
tools, so I'm unsure what parts of the review can be automatized.

For instance there is a document[1] that has a checklist on what to
check with things like that:
[ ] Programs commonly known to have freedom issues are liberated or
excluded
[ ] No non-free firmware or binary blobs
[ ] All software under a free license with source code provided 
[ ] Documentation under a free license
[ ] Other "Information for practical use" under a free license
[ ] All "non-functional" data must be freely distributable

As I understand all that require to check packages, so we could link
each package to a software in the free software directory. And it would
also be a good opportunity to add some of the Uruk specific software
there. 

I've started to do that in some not-yet automated way[2].

But then I'm unsure how to know what changed between an original
package and the modification by Uruk. Do you know how to do that?

I'm also unsure how to check an installer ISO: Do you know where to
find infos about rebuilding the installer images?

I've also no idea how to check if the packages binaries correspond to
the source code, though I could probably find how to do that.

What I'm interested in here would be to use this occasion to at least
start understanding what tools and/or process that could work to
automatize the check of Debian based distributions, and that would work
too without without much trust (that could be useful with companies
that are more difficult to trust because the requirement of not going
bankrupt or profit requirements could in some case take precedence on
FSDG compliance).

> the work-group has clearly lost a good deal of momentum in the
> past years; so the most pertinent topic to discuss at this time,
> is: could we accomplish this now? - are there any volunteers?
Here the issue is that I fear that no one will commit to do the full
review, but small parts were already reviewed by different people, so
if we find a way to bring more people in to collaborate and split all
that in smaller parts, it might be doable to have it fully reviewed.

I've started to look a bit into it[2], but I'm unsure if it's the right
approach (like does it reviews the right things?) and I've questions on
how to automatize all that.

My main concern here is to find a process that can easily be checked
later on by someone else. For instance if an FSF employee or
volunteer could check the work fast, then we'd have more probability of
having that done: my hypothesis is that if it's fast enough to check a
distribution, it has a good probability to be added to the list.

What bill-auger wrote seems to confirm this hypothesis:
> we would also be remiss if we did not recognize that freenix and
> liberty-bsd were ready 

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Mon, 27 Mar 2023 16:31:51 +0200 Denis wrote:
> As I understand, self-hosting has a completely different meaning here:
> it's not about hosting your own infrastructure and it has nothing to do
> with infrastructure at all.

i really think it implies both - the word "provide" would make
no sense, if the distro does not provide the software, but
refers users to a third-party, who has no obligation to provide
anything to those users

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Fri, 24 Mar 2023 18:35:54 -0700
alimiracle  wrote:

> The problem is not only with docker
> All programs that have a package manager
> like python, node, ruby, rust and php
Indeed, and many more. Even some games have builtin package managers.

There is an article about it in the Libreplanet wiki[1]: The goal is to
get some help from less technical users that could coordinate to
bug-report in affected distributions: if 1 package is known to have an
issue, multiples distributions are most likely affected.

References:
---
[1]https://libreplanet.org/wiki/Group:Software/research/ExternalRepositories

Denis.


pgpvzcsu1fqQI.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

Hi,

On Fri, 24 Mar 2023 23:13:47 -0300
Alexandre Oliva  wrote:
> - free distros need to take responsibility for what they recommend and
> offer to users, outsourcing that responsibility to third parties, even
> ones committed to observing the same rules, is a potential pitfall
> when an upstream distribution changes its own alignment.  A free
> distro must be able to fix freedom problems itself, without depending
> on a third party to do so.
> 
> - if an upstream distribution changes its alignment, the downstream
> distro may find itself needing to urgently find hosting for a sizable
> repository.  that creates a potential conflict of priorities.  it pays
> to work on that ahead of time.
> 
> - self hosting one's own computing and data sets a good example for
> the community at large.  the growing disregard for this aspect of
> computing autonomy in parts of the larger free software communities
> is a serious problem that drives a lot of people into behaviors that
> promote dependency rather than freedom.
> 
> There is likely a lot more, but these are ones that come to mind
> immediately.
All these issues also affect small distributions that don't have a
self-hosting requirement.

Let's call the distribution you build on (like Trisquel), the host
distribution, and the small distribution (like LibreCMC or Replicant)
the target distribution.

The issue here is that usually target distributions (like LibreCMC) can
be built on several host distributions, so people probably assume it's
always the case.

In practice this doesn't apply anymore for Replicant as it tend to be
really strict about the distribution it can be built on.

There are bigger issues though:
- When the host distribution version stops being maintained and that
  people find issues in it, it might be difficult to fix them if the
  target distribution doesn't start maintaining the host distribution.
- The host distribution repositories could disappear. For instance
  PureOS green disappeared. If someone has a copy of the repository I'd
  be extremely interested in it.

That could be fixed relatively easily though:
(1) The FSF or another organization/project could probably mirrors all
of the FSDG compliant distributions and also keeps archives of the
older versions of the distributions somehow.
(2) If there are new versions of the host distribution, it would still
be possible to either contact the host project to keep maintaining
the old version. If not it might be possible to fork it (especially
if all the source code is mirrored already).

The only maintenance that is really required would probably be to
be able to get some bug reports on FSDG compliance issues and fix them.

Denis.


pgp1w5I2kIXgZ.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Fri, 24 Mar 2023 21:36:36 -0400
bill-auger  wrote:

> On Sat, 25 Mar 2023 02:10:43 +0100 Denis wrote:
> > So if there is something related to chromium it will most likely be
> > in the PureOS repository.
> 
> yes - that appears to be the 'main' repository of pureos
> 
> FWIW, that alone conflicts with the FSDG "self-hosting"
> requirement - i believe that the consensus regarding that
> requirement, is that the distro must manage all of it's own
> infra, not to rely on the infra of another distro

As I understand, self-hosting has a completely different meaning here:
it's not about hosting your own infrastructure and it has nothing to do
with infrastructure at all.

The meaning here is closer to the one used by compilers: it means that
a software (or distribution) can build itself.

For instance GCC is self-hosting because you can build GCC with
GCC.

Replicant isn't self hosting because you can't build Replicant from
within Replicant (because building Replicant requires an x86_64
computer running specific GNU/Linux distributions).

The same applies to LibreCMC, and ProteanOS: nobody managed to build
LibreCMC from LibreCMC yet, and ProteanOS is meant to be really small
as I understand so that doesn't look possible either. And with a device
that has 8MiB of storage, it would be extremely difficult to install all
the dependencies necessary for building packages.

The issue here is that since these distributions cannot build
themselves, they needs to depends on another FSDG compliant or at least
on a fully free distribution (depending on the interpretation of the
FSDG), else you would need nonfree software dependencies.

In the case of both uruk and Parabola, they reuse packages from other
distributions. Uruk doesn't need to filter PureOS packages because
PureOS is FSDG compliant. Like all FSDG compliant distributions it can
(and even does) contain bugs. And bugs can be fixed by working with
PureOS directly.

In the case of Parabola FSDG compliance bugs can't be fixed in Arch
Linux so this requires some filtering / blacklist system that isn't
needed in Uruk.

And in both cases you can build Arch Linux packages in Parabola and
PureOS packages in Uruk.

For the later, the mechanism is actually integrated into the
distribution, so it's way better: you just need to make sure
/etc/apt/sources.list has the source repositories enabled and then
apt-get source can get the source and some command like dpkg
build-package (I don't recall the exact commands) can build the
packages you want.

As for Parabola, it lacks such mechanism, so users need to download the
Arch Linux package definitions from Arch Linux and not from Parabola.

Denis.


pgp62Nlq4D7Oz.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Sat, 25 Mar 2023 09:12:01 +0300 Jean wrote:
> I suggest that you make a message very conclusive in itself so that
> readers may understand how Chromium is related to your withdrawal of
> the offer to participate in the review.

my reason is personal - i have grown weary of discussing it - in
this case, it appears that any conclusions regarding chromium
in the context of uruk, could not be addressed by the uruk
maintainers - only the pureos maintainers could do anything about
it; and thie issue has already been thoroughly discussed with
the pureos maintainers - in my lonely opinion, pureos and guix
are out of compliance with the FSDG, both knowingly and
willingly - therefore, i automatically have the same opinion of
uruk, if it is effectively "pureos in disguise"

for those interested, simply search this mailing list for
"chromium" - i have stated many many times, on this list and
others, my opinion and the crisis facing the FSDG, which hinges
largely on a resolution of that topic

here is a few starting points

https://lists.nongnu.org/archive/html/gnu-linux-libre/2019-10/msg00012.html
https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg3.html

Re: [GNU-linux-libre] review of uruk

[Jean Louis]

* bill-auger via gnu-linux-libre  [2023-03-24 
18:30]:
> On Fri, 24 Mar 2023 11:24:56 +0200 tct wrote:
> > $ cat /etc/apt/sources.list
> > deb https://repo.pureos.net/pureos/ byzantium main
> > deb http://packages.urukproject.org nannar main
> 
> if chromium is in that repo, i withdraw my offer to participate
> in the review

I suggest that you make a message very conclusive in itself so that
readers may understand how Chromium is related to your withdrawal of
the offer to participate in the review.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [GNU-linux-libre] review of uruk

[Alexandre Oliva]

Hello, Ali,

On Mar 24, 2023, alimiracle  wrote:

> These requirements were developed in order not to use repositories
> from non-free distributions

I don't speak for the FSF and I don't know exactly what motivated the
inclusion of this requirement in the FSDG, but I can think of reasons
that go beyond what you suggest above:

- free distros need to take responsibility for what they recommend and
offer to users, outsourcing that responsibility to third parties, even
ones committed to observing the same rules, is a potential pitfall when
an upstream distribution changes its own alignment.  A free distro must
be able to fix freedom problems itself, without depending on a third
party to do so.

- if an upstream distribution changes its alignment, the downstream
distro may find itself needing to urgently find hosting for a sizable
repository.  that creates a potential conflict of priorities.  it pays
to work on that ahead of time.

- self hosting one's own computing and data sets a good example for the
community at large.  the growing disregard for this aspect of computing
autonomy in parts of the larger free software communities is a serious
problem that drives a lot of people into behaviors that promote
dependency rather than freedom.

There is likely a lot more, but these are ones that come to mind
immediately.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Fri, 24 Mar 2023 18:42:16 -0700 alimiracle wrote:
> These requirements were developed in order not to use repositories from 
> non-free distributions

i believe that the intention was to ensure that the distro is
self-sustaining, self-reliant, etc - if pureos decides to cease,
and shuts down its repo server, uruk would immediately cease to exist,
or would have a lot of work to do, before it met the "Complete Distro"
criteria again

that is in the first section of the FSDG:
> In particular, a free system distribution should be self-hosting.
> This means that you must be able to develop and build the system
> with tools that the system provides you. 

i bring attention specifically to the word "provides" - to require users
to get software from another project, is not "providing"


On Fri, 24 Mar 2023 18:42:16 -0700 alimiracle wrote:
> we use fsdg repo

that is a separate criteria, relating to several other checklist items:
* Programs commonly known to have freedom issues are liberated or excluded
* No non-free firmware or binary blobs
* All software under a free license with source code provided
* Documentation under a free license
* Other "Information for practical use" under a free license
* All "non-functional" data must be freely distributable

notice again the word "provided"

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Fri, 24 Mar 2023 09:34:14 +0300 Jean wrote:
> Enlighten me, who is in charge of the workgroup?

the FSF licensing manager is in charge of the FSDG - in 2018, the
work-group was formalized as an integral part of the endorsement
process - the work-group itself has no manager - anyone may
participate, without asking - just join in, and share your
findings

for each evaluation, a manager is elected for that one
evaluation - there is a protocol to follow, and the manager
should double-check the findings of the reviewers - everything
is explained on the wiki

https://libreplanet.org/wiki/Incoming_distros

of course, you could review it independently - but why? -
please share anything you learn with the group - all information
will be collected for the checklist

Re: [GNU-linux-libre] review of uruk

[alimiracle]

>FWIW, that alone conflicts with the FSDG "self-hosting"
>requirement - i believe that the consensus regarding that
>requirement, is that the distro must manage all of it's own
>infra, not to rely on the infra of another distro

These requirements were developed in order not to use repositories from 
non-free distributions

we use fsdg repo
have fun and be free
ali miracle

Re: [GNU-linux-libre] review of uruk

[bill-auger]

On Sat, 25 Mar 2023 02:10:43 +0100 Denis wrote:
> So if there is something related to chromium it will most likely be in
> the PureOS repository.

yes - that appears to be the 'main' repository of pureos

FWIW, that alone conflicts with the FSDG "self-hosting"
requirement - i believe that the consensus regarding that
requirement, is that the distro must manage all of it's own
infra, not to rely on the infra of another distro

Re: [GNU-linux-libre] review of uruk

[alimiracle]

> Docker uses a repository with nonfree software (docker hub). It has
> things like Microsoft Windows images that are clearly nonfree.
The problem is not only with docker
All programs that have a package manager
like python, node, ruby, rust and php

have fun and be free
ali miracle

Re: [GNU-linux-libre] review of uruk

[alimiracle]

> After a quick glance of the Uruk website, technologies such as 
Docker, SourceForge, GitHub and CloudIDE invites to take a closer look:

cloude ide is not part of uruk distro
its part of uruk project
and docker is free
but if the  ide and docker image must removed we will remove it

> While testing the Uruk 3.0 Live image, I've noticed that Firefox ESR 
is the default browser.
>I tried to make an account in the bug tracker to report this freedom 
issue, but I didn't receive the confirmation e-mail:

thnx for you
we will fix the bug tracker
as for Firefox
As you know Pure is a free distribution as the FSF says
We used it because we thought Pure was completely free
Honestly, I'm starting to doubt pure's credibility
What do you advise us to do, do we remove and replace the browser or is 
there another more practical solution

Repeat it again the problem is from Pure, not from us
have fun and be free
ali miracle

على 3/24/2023 2:24 AM، كتب tct:
La 23.03.2023 21:41, bill-auger a scris:
setting aside discussion of the FSF's role in this, new distros
are not going to be reviewed without community participation

far be it from me to only complain about a problem, without
offering to help solve it - over the previous thread, i did not
see anyone step forward and volunteer to review uruk

it would be hypocritical for the work-group to also be idle, in
this time when the FSF is under-staffed

the work-group has clearly lost a good deal of momentum in the
past years; so the most pertinent topic to discuss at this time,
is: could we accomplish this now? - are there any volunteers?

It's laudable the effort being put into maintaining a candidate such as 
Uruk for the list of free GNU/Linux distributions.


After a quick glance of the Uruk website, technologies such as Docker, 
SourceForge, GitHub and CloudIDE invites to take a closer look:


https://www.urukproject.org/dist/en.html#docker
https://sourceforge.net/projects/urukos/files/3.0
https://blog.urukproject.org/fr/index.php/posts/uruk-cloudide
https://github.com/azzenabidi/UrukCloudIDE

While testing the Uruk 3.0 Live image, I've noticed that Firefox ESR is 
the default browser.


I tried to make an account in the bug tracker to report this freedom 
issue, but I didn't receive the confirmation e-mail:


https://urukproject.org//bt/login_page.php

The problem is that Firefox offers to install the non-free DRM plugin 
and add-ons from the Mozilla catalogue, many of them being proprietary 
and promoted on the main page such as: Video DownloadHelper, Enhancer 
for YouTube, and ImTranslator.


https://addons.mozilla.org/en-US/firefox/

Perhaps Uruk has changed the upstream distro since the FSF evaluation, 
and a new evaluation is required, or perhaps the upstream distro has 
changed its policy. It seems that Firefox ESR is packaged by PureOS:


Package: firefox-esr
Version: 91.13.0esr-1~deb11u1
Installed-Size: 212318
Maintainer: Maintainers of Mozilla-related packages 


Architecture: amd64
http://repo.pureos.net/pureos/dists/byzantium/main/binary-amd64/Packages.xz

And Uruk uses the PureOS repository as its main one:

$ cat /etc/apt/sources.list
deb https://repo.pureos.net/pureos/ byzantium main
deb http://packages.urukproject.org nannar main

I hope this helps and that the freedom issues can be confirmed and fixed.

Thanks,

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Fri, 24 Mar 2023 10:15:09 -0400
bill-auger via gnu-linux-libre  wrote:

> On Fri, 24 Mar 2023 11:24:56 +0200 tct wrote:
> > $ cat /etc/apt/sources.list
> > deb https://repo.pureos.net/pureos/ byzantium main
> > deb http://packages.urukproject.org nannar main  
> 
> if chromium is in that repo, i withdraw my offer to participate
> in the review

I've looked at http://packages.urukproject.org and for now it doesn't
seem to contain anything related to chromium.

So if there is something related to chromium it will most likely be in
the PureOS repository.

Denis.


pgpSgScUmVJWV.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

Hi,

On Fri, 24 Mar 2023 11:24:56 +0200
tct  wrote:
> https://www.urukproject.org/dist/en.html#docker
Docker uses a repository with nonfree software (docker hub). It has
things like Microsoft Windows images that are clearly nonfree.

But as-is that would only be an issue in PureOS because PureOS provides
docker, and users can bugreport to pureOS and get it fixed there, so
it's probably not something blocking here. Though people need to
bugreport about it in all FSDG distributions shipping a docker package.

Parabola has a (quick and dirty) patch to deactivate that nonfree
docker.io repository, that I did but I'd need more RAM to manage to
build the package with these patches, or to look how to build on a
Parabola server and sign the packages locally, or to find a way to
increase the tmpfs inside the build chroot. The package works fine when
built manually (with makepkg) though.

The issue is also that my patches do the job, but I don't know go, so I
didn't manage to keep the compatibility with non-patched docker command
line.

To summarize, this cannot work with a patched docker:
> docker run alimiracle/urukos /bin/bash
because the non-patched docker assume that the default repository is
docker.io and we can't have docker.io as default as it contains nonfree
software.

With the Parabola patch, that could be modified to:
> docker run registry-1.docker.io/alimiracle/urukos /bin/bash

And if someone manage to fix my patch, that could be modified to
something like that:
> docker run docker.io/alimiracle/urukos /bin/bash
this would also works with non-patched docker.

So once docker gets patched in FSDG distributions, that instruction
would probably need to get modified to take that into account somehow
(like point to 1 command for FSDG distros and another for non-FSDG
distros or mention where it works or doesn't work).

I've already reviewed the PureOS docker image (by reviewing its build
instructions) and it should be a 100% pureOS image. So it should be as
FSDG-compliant as PureOS.

> https://sourceforge.net/projects/urukos/files/3.0
I've looked a bit at it but I'm still unsure if sourceforge is OK
or not for FSDG distributions: It has the worst grade ("Unacceptable)
in the GNU ethical repository criteria[1], and the notes with it is that
"Important site functionality doesn't work without JavaScript, or with
LibreJS enabled. (C0)"[2] and the proposed updates[3] to this criteria
still have the same grade and comment[4] for sourceforge.

However it doesn't tell if nonfree javascript is required though. But
if it is, and that you need to run nonfree software to download uruk or
contribute to uruk for instance, it will most likely be considered as
steering users toward nonfree software.

To know for sure, someone will probably need to try to download uruk
with javascript blocked and see if it works, and/or look at the licenses
of files required to do the download.

And the issue here is that there might be some chicken and egg: if the
issue is the lack of space, that could probably be fixed by asking for
some space to the FSF, or other similar organization, but they might
want the distribution to be certified first.

Other organization might work too. For instance Replicant uses OSUOSL
for its releases (https://ftp2.osuosl.org/) and there doesn't seem to
require any JavaScript. Pushing files just requires ssh / sftp.

> https://blog.urukproject.org/fr/index.php/posts/uruk-cloudide
> https://github.com/azzenabidi/UrukCloudIDE
I've not looked at that yet. Though Github also has 'F'[2] GNU ethical
repository criteria.

The issue with all that is also that we need to be efficient somehow and
do a good job without spending too much time on it, and make it easy to
check our work. 

So it might be way easier to have the distribution fix that instead of
requiring the reviewers and/or the FSF to do research, think hard about
the implication of a distribution hosting software on sourceforge, and
using github to host some of the software related to the distribution.

> $ cat /etc/apt/sources.list
> deb https://repo.pureos.net/pureos/ byzantium main
> deb http://packages.urukproject.org nannar main

If we assume that the PureOS repository is a third party repository
that it itself FSDG compliant, and so that any issues can be fixed by
bugreporting to PureOS, we'd need to only review the uruk repository.

There seems to be 2 architectures supported somehow:
https://packages.urukproject.org/dists/nannar/main/binary-i386/Packages.bz2
https://packages.urukproject.org/dists/nannar/main/binary-amd64/Packages.bz2

But https://sourceforge.net/projects/urukos/ only mentions x86_64 and
PureOS doesn't support i686. So we could probably just review amd64.

So if we just take the amd64 Pakcages.bz2 we have the following
packages:
> $ bzgrep "^Package" Packages.bz2 | awk '{print $2}' | sort -u
> aia
> background-nannar
> calamares
> caribou
> caribou-antler
> caribou-dbgsym
> cinnamon
> cinnamon-common
> cinnamon-control-center
> 

Re: [GNU-linux-libre] review of uruk

[tct]

La 23.03.2023 21:41, bill-auger a scris:

setting aside discussion of the FSF's role in this, new distros
are not going to be reviewed without community participation

far be it from me to only complain about a problem, without
offering to help solve it - over the previous thread, i did not
see anyone step forward and volunteer to review uruk

it would be hypocritical for the work-group to also be idle, in
this time when the FSF is under-staffed

the work-group has clearly lost a good deal of momentum in the
past years; so the most pertinent topic to discuss at this time,
is: could we accomplish this now? - are there any volunteers?


It's laudable the effort being put into maintaining a candidate such as 
Uruk for the list of free GNU/Linux distributions.


After a quick glance of the Uruk website, technologies such as Docker, 
SourceForge, GitHub and CloudIDE invites to take a closer look:


https://www.urukproject.org/dist/en.html#docker
https://sourceforge.net/projects/urukos/files/3.0
https://blog.urukproject.org/fr/index.php/posts/uruk-cloudide
https://github.com/azzenabidi/UrukCloudIDE

While testing the Uruk 3.0 Live image, I've noticed that Firefox ESR is 
the default browser.


I tried to make an account in the bug tracker to report this freedom 
issue, but I didn't receive the confirmation e-mail:


https://urukproject.org//bt/login_page.php

The problem is that Firefox offers to install the non-free DRM plugin 
and add-ons from the Mozilla catalogue, many of them being proprietary 
and promoted on the main page such as: Video DownloadHelper, Enhancer 
for YouTube, and ImTranslator.


https://addons.mozilla.org/en-US/firefox/

Perhaps Uruk has changed the upstream distro since the FSF evaluation, 
and a new evaluation is required, or perhaps the upstream distro has 
changed its policy. It seems that Firefox ESR is packaged by PureOS:


Package: firefox-esr
Version: 91.13.0esr-1~deb11u1
Installed-Size: 212318
Maintainer: Maintainers of Mozilla-related packages 


Architecture: amd64
http://repo.pureos.net/pureos/dists/byzantium/main/binary-amd64/Packages.xz

And Uruk uses the PureOS repository as its main one:

$ cat /etc/apt/sources.list
deb https://repo.pureos.net/pureos/ byzantium main
deb http://packages.urukproject.org nannar main

I hope this helps and that the freedom issues can be confirmed and fixed.

Thanks,
--
tct

Re: [GNU-linux-libre] review of uruk

[Jean Louis via gnu-linux-libre]

* bill-auger  [2023-03-23 22:42]:
> it would be hypocritical for the work-group to also be idle, in
> this time when the FSF is under-staffed
> 
> the work-group has clearly lost a good deal of momentum in the
> past years; so the most pertinent topic to discuss at this time, 
> is: could we accomplish this now? - are there any volunteers?

I did not know that participants in this mailing list are supposed to
be the actual work group, so that is the problem of the organization. 

Any person who subscribes to this list shall be given the policy or
rules of the workgroup, purposes or expectations. 

Am I part of the workgroup to review if system distribution is fully
free operating system? Not that anybody informed me. I feel here as
observer of lack of activity and complains that workgroup doesn't do
it's purposes.

Enlighten me, who is in charge of the workgroup?

Then I can do my review independently.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [GNU-linux-libre] review of uruk

[bill-auger via gnu-linux-libre]

On Fri, 24 Mar 2023 11:24:56 +0200 tct wrote:
> $ cat /etc/apt/sources.list
> deb https://repo.pureos.net/pureos/ byzantium main
> deb http://packages.urukproject.org nannar main

if chromium is in that repo, i withdraw my offer to participate
in the review

[GNU-linux-libre] review of uruk

[bill-auger]

setting aside discussion of the FSF's role in this, new distros
are not going to be reviewed without community participation

far be it from me to only complain about a problem, without
offering to help solve it - over the previous thread, i did not
see anyone step forward and volunteer to review uruk

it would be hypocritical for the work-group to also be idle, in
this time when the FSF is under-staffed

the work-group has clearly lost a good deal of momentum in the
past years; so the most pertinent topic to discuss at this time, 
is: could we accomplish this now? - are there any volunteers?