Re: [GNU-linux-libre] review of uruk
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
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
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
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
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
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
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
