Ubuntu 16.04 Xenial Xerus will be launched the 21 of April.
- Login o registrati per inviare commenti
Ubuntu 16.04 LTS Stable will be launched the 21 of April. It´s important for the Trisquel community because Trisquel is based on the LTS versions of Ubuntu. The bad thing of that is that we have to wait 2 years for newer versions. That means that probably Trisquel 8 will be launched this semester. I don´t know how fast are Trisquel developers, the first version of Trisquel I´ve use, is Trisquel 7. I hope that Trisquel 8 comes with new environments!
Trisquel 7 was released fifteen months ago. I'd love to help in order to get stable releases out faster. I know a pitiful amount of Python (still learning) but I'm pretty knowledgeable about Linux and can at least contribute documentation. Where do I sign up?
Trisquel's documentation is a wiki: https://trisquel.info/wiki/
You have invited to contribute. Just click "Edit".
The reason there are no non-LTS releases of Trisquel is the lack of manpower (it takes 4-6 months to release Trisquel after Ubuntu already). If you are knowledgeable about the inner workings of a Debian/Ubuntu system, you probably can help.
Considering how short-term STS Ubuntu releases are nowadays I'm not sure it's worth doing them anymore - 2 years between releases is an OK interval, I think.
mmmmm.... so I think that maybe this year Trisquel 8 can be launched. Look at this https://wiki.ubuntu.com/LTS
With Ubuntu MATE 16.04 releasing betas before the main release, there is no reason Ruben cannot start testing and prepping the user interface and customizations for Trisquel 8 right now. That way, we can ideally get a Trisquel 8 release within a week of 16.04. If Linux Libre can do it, why can't Trisquel?
But knowing Ruben, he will keep us in the dark for 3+ months.
And knowing you, you will not help the Trisquel project in any way (repackaging, documentation, donation, etc.). Yet, you criticize who spends the most time and energy on the project.
I'd love to help out in the repackaging or documentation area. Are you guys in need of Bash scripts for repackaging or is that pretty set? Or were you thinking in the lines of compilation?
As for documentation, what would you need? Like general setup of the OS or like some tips on setting up programs (like nginx for example) that are included in the repos and used by Trisquel users?
You may be able to write package helpers: https://trisquel.info/en/wiki/package-helpers (do you know 'sed'?).
See https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/README.md for how to setup your system and https://trisquel.info/en/issues/8038 for some bugs you can work on.
And, of course, drop by at #trisquel-dev or send messages at https://listas.trisquel.info/mailman/listinfo/trisquel-devel
As for the documentation, any manual is valuable: https://listas.trisquel.info/mailman/listinfo/trisquel-devel
Just click an "Edit"!
I'm pretty fluent in Python and the pip issue caught my eye. I'm assuming the python-pip and python3-pip packages are the culprit since they may suggest non-free software.
If Trisquel had a custom version of pip in the repos that blocked or didn't allow the installation of non-free software, would that be a benefit to people here? Of course many Python people either install via https://bootstrap.pypa.io/get-pip.py or via setuptools instead of apt.
> If Trisquel had a custom version of pip in the repos that blocked or didn't allow the installation of non-free software, would that be a benefit to people here?
I think that would be a hindrance. I believe the problem is non-free software gets listed.
I've been going through the site the past few hours and making a list of packages that don't fall under a FSF approved license. When someone tries to install a package via something like "pip install XXXX", it would reference a text file containing the packages and if that package is non-free, it will display a warning and not allow installation. This could be a block of code where it catches the user doing an install of the package or another package that requires it.
This would affect the python-pip and python3-pip packages in Trisquel 6 and above. You are free to install pip through other means, but the ones in the repos should be locked down.
This is the wrong (unnecessarily hard) way to do it. There are categories indicating specific libre licenses. Just use those categories as a whitelist.
Also, I don't think it's necessary for installation of packages not confirmed to be libre to be blocked. Just exclude them from search results and display a warning when the user attempts to install them (and ask for confirmation).
Does pip have the option to limit package installation by licence type? Plus, some packages may be "DSFG Compliant" but may have a licence that isn't FSF approved.
Your solution is to create a repository for packages which requires hosting the packages and maintaining them. Or you can just blacklist packages that are not free instead of having to handle potentially thousands of packages. I'd prefer to have a list of packages that can be updated and pip checks that when a user tries to install.
While a whitelist might be more work, it's also a solution that has 100% success.
One thing that has also to be considered is what happens if somebody changes their license.
> Does pip have the option to limit package installation by licence type?
No, but adding this in based on classifiers would be trivial.
Also, it's not installation you should be focusing on, but search.
> Plus, some packages may be "DSFG Compliant" but may have a licence that isn't FSF approved.
There are categories indicating specific licenses. Use those. They're sub-categories of "License :: OSI Approved". The list of all of them is here:
https://pypi.python.org/pypi?%3Aaction=list_classifiers
> Your solution is to create a repository for packages which requires hosting the packages and maintaining them.
No, I never suggested this, and it's unnecessary.
Since a blacklist is less work than a whitelist, it may be preferred. The pip package would include a list in a blacklist.txt file that can be updated and sent to users on apt upgrades.
The Linux Libre kernel blacklists non-free bits, so why can't our custom pip? Like I said, I'm spending the man hours on the initial blacklist.txt and will see about modifying or creating a package helper to utilize it.
> a blacklist is less work than a whitelist
No, it isn't. It's so much more tremendously difficult that I don't think it can reasonably be done that way. Do you have any idea how much software is in PyPI? There is no requirement for any package to use any trove classifier, or to list any license. So checking these would not be enough. You would have to manually check every other package for the license to see if it needs to go on the blacklist. And as new software gets uploaded, you would have to keep doing this. Any package not getting caught would completely undermine your efforts.
If you instead just whitelist based on classifiers, and possibly secondarily by recognizing particular license strings, you wouldn't need to worry about it. A package being wrongly assumed to be proprietary because it doesn't have a proper classifier on it wouldn't be a disaster.
> The Linux Libre kernel blacklists non-free bits, so why can't our custom pip?
Apples and oranges, my friend. PyPI is a software repository containing some proprietary software, not a program with blobs in it.
I disagree.
Managing a list of hundreds is easier than thousands. Sorry.
Managing thousands?! What are you talking about? If you just look at the classifiers, you don't have to manage anything, and the total number of classifiers you have to look at to check whether it is a libre license is 66. That's the total number of all trove classifiers indicating a license.
I don't know how I can be any clearer on what I'm suggesting, but somehow, I think it's gone completely over your head. You are clearly imagining going through every package, manually checking all of them, and putting all of the libre packages into a list. That's not even close to what I suggested. I suggested whitelisting classifiers and possibly specific license strings.
But if you want to spend every day looking at new uploads to PyPI manually check whether or not they're free - and I do mean every day, because this is someone else's repository that anyone can upload a new package to - rather than just utilizing the tools PyPI already provides to tell you what license a program is under... be my guest.
If I do your method and choose to whitelist instead of blacklist, does it increase my chances of the custom pip getting accepted? I just don't want to be constantly told I am wrong and I put forth all the effort to get shut down.
I'm just a passerby with zero authority but I would guess it certainly does improve odds. Because it would then guarantee (as far as the info they provide) that all listed items would be free. Which is what Trisquel is all about.
If you can free pip it would be sweet. Half measures could be just wasted effort on the other hand.
Thanks for your feedback. It is nice to get feedback from someone besides onpon4.
Abrowser uses an alternative website to the Mozilla one to handle extensions and onpon4 may suggest having something similar to handle pip packages. Technically, if a person is using pip, they do it all through the command line anyways and aren't required to browse a web page like with the Mozilla extensions.
Having either a whitelist or blacklist does require some work, but if we have an editable .txt file in the Trisquel GitLab repository for the package helper, I'm sure packages could be added to the list easily.
So if we do the whitelist route, what is the best method? Do I write a script that calls Requests on each of the category pages that we know are free, scrapes the names, and adds to a list or SQLite DB? Or would manual intervention need to happen?
What onpon4 is trying to explain (I believe) is that you never ever need a list of *packages*. Whatever its color. You only need a white list of free *licenses* so that the search only returns the packages that indicate such a license.
Yup.
I understand where he is coming from, but the PyPi categories are not 100% accurate. Browsing the site, there are packages that say they are under a "BSD Licence" or "MIT Licence" and are listed as such, but there is no link to the source (on their site or Git) and the tar.gz or .zip files do not contain any licensing information.
If a list is to be curated, would it be included within the package or would it have to reference a file or site on an external server (that can be updated with new package) for it to work? There could also be a separate page that lists the free packages (like the Abrowser plugins), but will download from the PyPi servers. This database would be created by scraping the PyPi RSS feeds or using something like Requests and an HTML parser to pull the package names and links and store them. Or you can go with my original method of keeping a smaller blacklist.txt file that blocks it at the installer.
There's just so many methods in doing this and unfortunately I'm not getting a solid "do it this way" answer.
> Browsing the site, there are packages that say they are under a "BSD Licence" or "MIT Licence" and are listed as such, but there is no link to the source (on their site or Git) and the tar.gz or .zip files do not contain any licensing information.
I think listing a classifier that says the license is the "OSI approved" "MIT license" works to place the software under that license (the Expat license). As for a "link to the source (on their site or Git)", why is that necessary? Is the source distribution on PyPI not enough? It's possible (though unlikely) for a source code download to be unavailable, but source code downloads are marked as such, so you should be able to auto-detect this.
I went through and downloaded the files that seemed vague (under "BSD" or "MIT" liceneces) and there was no LICENCE file with them and there were no headers in any source code bits with licensing information.
These files are DSFG or OSI "approved" but clearly are missing information to be fully compliant. So yeah... you cannot trust the categories on the site unfortunately.
You do realize where the trove classifiers come from, right? they come from the author of the package. I think the author of a package listing a license as a trove classifier is sufficient to grant permission to redistribute the code under that license, even if it's not the proper way to do it.
Do you trust the trove classifiers 100% then? These may be people who call things just a "BSD Licence" and there is no way to tell between a 2 and 3 clause licence because there is no LICENCE file or source repository to figure it out.
So don't count the vague ones.
EDIT: Double post
Except Trisquel 8 development has already started: https://devel.trisquel.info/trisquel/package-helpers/tree/flidas
I am a member!
Ruben just posted a very nice blog post the other day, please have a look if you have not already seen it. https://trisquel.info/en/new-cycle-what-we-achieved-and-whats-come
I updated https://trisquel.info/en/wiki/financial-information accordingly.
That makes me really happy. Now that Ruben works at the FSF, he can dedicate more time to Trisquel and the project can totally flourish. I liked that he is looking to get some test ISOs out before the final release of Trisquel 8 and that it will be out soon after Ubuntu 16.04.
When I install Trisquel, a narrator arrives with the installation. He
tells me every key I press, and it drives me nuts so I install Ubuntu
over it. How do I turn that guy off? I'd like to believe my OS has no
back doors and I don't, with Ubuntu. If I can turn off the narrator,
I'll move to Trisquel, which seemed pretty cool until the narrator wore
out his welcome. Thanks.
Wild guess here: Might https://trisquel.info/en/forum/cant-find-how-disable-trisquel-voice help ?
In System Settings, select Universal Access, and untick Screen Reader.
On the login dialogue, use 'ctrl+s' to toggle the speech.
I hate that screen reader. If you really find it unuseful for you, just remove it.
#apt purge gnome-orca
sudo apt-get purge gnome-orca
Can Fidas be botstrapped yet? (It's been a few months since I last bootstrapped anything Debian-style so I guess I should try it again soon)
The good thing about Linux is the openprinting drivers (which are mainly Epson printers) & Trisquel should include the free drivers for HP (HPLIP). Because HP printers are also very used and these drivers are free/libre, opensource & light
Though you can install hplip.....
- Login o registrati per inviare commenti