Re: [Trisquel-users] Minimal Installation
I know there's the option to do that and that's great but I'm an amateur when it comes to the nitty gritty of GNU/Linux and I know that there are many people whose knowledge is similar. It would be so much easier just to have a minimal installation option in the installer for less technical people and customize from there.
Re: [Trisquel-users] Minimal Installation
Use network install, do not install DE, only core packages and utilities, reboot, log in to console and build from here.
Re: [Trisquel-users] FSDG and pip
Right. Those things (add-ons and Firefox and Thunderbird and other Mozilla-branded things like the Rust programming language as well as other things) are all good candidates to be handled in a cross-distro way as well. Currently the FSF-endorsed distros each solve that problem on their own which results in duplication of effort.
Re: [Trisquel-users] FSDG and pip
Most that I'm aware of already are, though there's sometimes a problem of them not being available for Python 3 (in particular Pygame and Pyglet; note, both of these libraries work with Python 3, so this is a packaging problem in both cases). I tend to think of my own libraries (sge, xsge_*, tmx) as important, and those aren't included, but I'm probably the only developer on the planet who uses those. ;)
[Trisquel-users] Minimal Installation
Since Trisquel 9.0 will presumably be based on Ubuntu 18.04, I'm wondering if there will be a minimal install option, ie; web browser and basic utilities only. I'm very new to Trisquel and while it is a great OS, it took a while to uninstall the packages I didn't need which would end up breaking something in the system and so now I just use the menu editor to hide the programs i dont want but i'd just rather them gone. I'd also like to get other people's opinions on whether they prefer a full OS or a minimal one. Thanks.
Re: [Trisquel-users] Wi-Fi disconnecting very often
what is the output of: sudo lshw -class network just so we know what wifi chip etc is in use.
Re: [Trisquel-users] I want to help
> https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/CONTRIBUTING.md Note that this[1] is required for trisquel-builder to work with Flidas. For some reason I get an error when I try to view "Changes", but the modified files are here[2][3][4] and using those to replace the versions in the master branch got it working for me. > but there doesn't seem to be any issues open. Are you looking at GitLab? There are open issues here.[5] [1] https://devel.trisquel.info/trisquel/trisquel-builder/merge_requests/3 [2] https://devel.trisquel.info/kpengboy/trisquel-builder/blob/flidas-update/hooks/G10trisquel [3] https://devel.trisquel.info/kpengboy/trisquel-builder/blob/flidas-update/pbuilderrc [4] https://devel.trisquel.info/kpengboy/trisquel-builder/blob/flidas-update/hooks/D10trisquel [5] https://trisquel.info/en/project/issues signature.asc Description: PGP signature
Re: [Trisquel-users] FSDG and pip
It occurs to me that if creating a cross-distro free replacement repository is realistic, a better target might be addons.mozilla.org Firefox and Thunderbird addons are used more frequently and by non-developers, Trisquel is already attempting to maintain a free replacement[1] manually, and the issue of non-free addons is also a problem for all FSDG distros. From this page[2] it appears that, unlike PyPI, Mozilla requires a license statement and provides a clearly defined set of options: Mozilla Public License, version 2.0 GNU General Public License, version 2.0 GNU General Public License, version 3.0 GNU Lesser General Public License, version 2.1 GNU Lesser General Public License, version 3.1 MIT/X11 License BSD License All Rights Reserved Other Apart from "All Rights Reserved" and "Other" all of these licenses are free under the FSDG (and GPL-compatible), so automatic filtering should be much more realistic. Anything labeled "Other" would have to be rejected, and this would probably mean leaving out some free software, but surely not as much as what gets left out by Trisquel's manual approach. [1] https://trisquel.info/en/browser [2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Distribution/Submitting_an_add-on signature.asc Description: PGP signature
Re: [Trisquel-users] FSDG and pip
> I tend to think that PyPI is less important than you might think. Thanks, onpon4. You would know much better than I how useful pip is to developers, so I'm sure you're right. Do you mind clarifying though whether by > important libraries > should just be included in the regular repo. you mean that important libraries are already included in the repo or that they ought to be? signature.asc Description: PGP signature
[Trisquel-users] I want to help
Hello. A while back I talked about wanting to help trisquel. After a few personal problems, I think I am ready to help now. As Magic Banana suggested I read https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/CONTRIBUTING.md and https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/README.md but there doesn't seem to be any issues open. How can I help with development of Trisquel right now?
Re: [Trisquel-users] FSDG and pip
> It's a nice idea but as you've said it's hard to do in an automated way. > Some human intervention will always be needed. Yeah, you're probably right. There's so much ambiguity in the license statements that any automated approach aggressive enough to remove all proprietary software would also remove so much free software that pip would no longer be very useful, especially since a package can't be considered free unless its entire dependency tree can. > This is probably why Trisquel > is doing what it's doing; It's easier to remove it than it is to filter and > maintain it. Yes, there's the work-to-return ratio to consider. I think it was right to just remove Snap completely, for example, since it was already not very useful to people who don't want to install proprietary software. A patch that could be implemented as a package helper seemed like it might be worth it to salvage pip, but especially after reading onpon4's comment I'm beginning to doubt whether additional efforts are worth it. > Personally, I don't know that your method of warning people sufficient > because this filter only acts if they use the client program to access it. > It doesn't prevent other methods, like if someone accesses it directly. (A > similiar thing could be pointed out by filtering out non-free .debs but I > could just open my browser to look at the repo and still see them.) People > still get sent to/referred to/whatever-you-call it to that place regardless. My thinking was that if the non-free package is excluded from pip's search results then anyone who tries to install it already knows it exists, and that explaining that the package is non-free is better then letting them assume that pip is just not working and installing the package by another means. However, I see your point. Maybe it is better to just ignore the package. That's more similar to how apt behaves when you try to install an Ubuntu package rejected by Trisquel, such as $ sudo apt install chromium ... Package chromium is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: chromium-bsu:i386 chromium-bsu E: Package 'chromium' has no installation candidate > Rather, there shouldn't *be* a repo with non-free things in it. That's a good point. A non-free repo shouldn't exist, so it would be strange to rely on one. > So: Copy the > free things into a new repo, and then all FSF-endorsed distro can change the > address in their copy of pypi to access the new location. > > Effectively, this is the option #2 mentioned by RMS in: > https://lists.libreplanet.org/archive/html/libreplanet-discuss/2016-04/msg00078.html I read that thread and agreed that a new repo would be a good solution, especially since as you point out this problem is not specific to Trisquel and a free PyPI replacement could be used by all FSDG distros. I get frustrated, though, that I spend so much time agreeing that things should be done and not much time doing them. I wouldn't know where to begin creating a replacement for the PyPI repo, so I approached the problem in a way that was within my skill set. It seems not to have been a great approach, although the automatic filtering could at least reduce the amount of additional manual work needed to create a new repo. signature.asc Description: PGP signature
Re: [Trisquel-users] Re : FSDG and pip
> Maybe an issue could be filed to propose to adopt a machine-readable > license format. Maybe that of Debian's packages: > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ which > itself uses the SPDX License List, i.e., https://spdx.org/licenses/ That would be a massive improvement. There are two places in the metadata to add a license. The one here[1] is the one that does always appear to have a consistent format like License :: OSI Approved :: GNU General Public License v2 (GPLv2) License :: CeCILL-B Free Software License Agreement (CECILL-B) License :: OSI Approved :: MIT License so it seems like the inconsistently formatted licenses are deprecated, but unless someone goes and updates the licenses of older packages or PyPI removes packages that don't conform there is still this problem. Another challenge is that even with the newer license format, multiple license statements are allowed. If multiple license statements indicated dual licensing then this would not a be a problem, but this package[2] seems to indicate otherwise. In the older "license" field it says "Artistic-License-2.0 + Forced-Fairplay-Constraints", which indicates that it is non-free, but it's not machine readable. The newer, "classifiers field has two license statements: License :: OSI Approved :: Artistic License License :: Free To Use But Restricted "Artistic License" is already too vague, because it does not specify the version and version 1.0 is non FSF approved, but this could be addressed by Debian's format. However, allowing multiple license statements no matter how specific they are is a problem if one of those is a free license and the software is not free. [1] https://packaging.python.org/tutorials/packaging-projects/ [2] https://pypi.org/pypi/yamldata/json signature.asc Description: PGP signature
[Trisquel-users] Wi-Fi disconnecting very often
I tried Wicd instead of Network-manager, it's the same result. I reinstalled the ath9k driver (it's a dongle bought from technoethic which still works as far as I can tell). What else could I try ? Thank you.
Re: [Trisquel-users] FSDG and pip
linux-libre isn't even allowed to mention the name of non-free software.
Re: [Trisquel-users] FSDG and pip
I agree with onpon4. In addition, pip does not require cryptographic package signing using tools such as GPG so you could be downloading altered packages if someone breaks into the PyPI website and replaces a package with a malicious version. PyPI did in fact contain malicious packages in the past - the issue was reported online, e.g. here: https://developers.slashdot.org/story/17/09/16/2030229/pythons-official-repository-included-10-malicious-typo-squatting-modules Of course the package signing problem can also occur on code repositories such as GitLab as well if those do not impose GPG signing of commits (which I gather most do not). Of course the GNU/Linux package managers do not solve the problem if they grab code from such code repositories without verifying the cryptographic signatures of the original developers.
[Trisquel-users] Re : FSDG and pip
RMS wrote: We should look for volunteers to make replacement repositories for a couple of them, based on automatic filtering not manual vetting. https://lists.libreplanet.org/archive/html/libreplanet-discuss/2016-04/msg00078.html Maybe an issue could be filed to propose to adopt a machine-readable license format. Maybe that of Debian's packages: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ which itself uses the SPDX License List, i.e., https://spdx.org/licenses/ pip's searching capabilities would then be enhanced and could be used to reliably list the free libraries to be copied to a new 100%-free repository that the FSF could host.
