 |
We had no problems related to any changes we made as recommended by Ferdnyc when we did the December monthly builds for all of the distros but we did not personally load them all to check. If a user has trouble with running since they almost always run as non-root (which we rarely do!) they probably would have reported so by now. The removing of unnecessary execute bits must be working, the cin desktop icon must be working, and the execstack was no problem for any of the builds. EXCEPT freebsd was not rebuilt and we do not know if that will be a problem but will fix that iif a user finds a need for a new freeBSD version. Also, as stated previously Centos 7, still used Python 2 (issue 0000011), so if a user reports a problem, they can send email or easily search on the web to create a soft link and resolve the problem. |
 |
"Regarding the .desktop file, the Encoding= key is fully deprecated by the current standard. " (And has been since spec 0.9.5, which dates back to roughly 2005/2006.) https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.5.html#deprecated-items |
|
|
Regarding the .desktop file, the Encoding= key is fully deprecated by the current standard. According to https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html the method for encoding strings for certain locales (though UTF-8 _should_ be the default) would be: Comment[fr.UTF-8]=Éditeur multimédia |
|
|
Re: (1), replaced COPYING with updated GPL2 after much contemplation. Sticking with the status quo. Re: (2), "The X- categories ... probably_ no POINT in having it there" -- since we had to modify cin.desktop again anyway, deleted the X-Multimedia part. I forgot we needed Encoding=UTF-8 for the French accent graves in the file. |
|
|
"But for the purposes of our package review — well, _nothing_ is "required", the notification here is merely informational, but we only look at the main LICENSE file itself." Actually, I take that back somewhat. While we certainly only get _involved_ when the text of the LICENSE file is outdated (policy recommending that we notify the upstream project), we do EXAMINE the license statements of every source file in the tree. Which is how we know that, in the case of Cinelerra-GG (from our rpm .spec file): ======== # The Cinelerra-GG codebase is licensed GPLv2+ # The GREYcstoration plugin is licensed CeCILL v2.0 # The Google SHA1 implementation is licensed BSD 3-clause # The Neophyte theme is licensed Creative Commons CC-BY 4.0 # The freeverb components and the Tapeworm font are in the public Domain License: GPLv2+ and CeCILL and BSD and CC-BY and Public Domain ======== ...That determination was only possible because the incorporated source files, extracted from other projects (and used in full accordance with their license terms) contained boilerplate license statements. So, as I said earlier, point to consider. |
|
|
Re: (2), The X- categories are permitted to define extensions to the standard list, any X-named category is implicitly valid and legal. So there's certainly no harm in having it there. There's also _probably_ no POINT in having it there, admittedly, but point is there's really no urgency one way or the other, as long as it's listed as X-Multimedia. As far as the license goes, it's of course ultimately up to the project how the license is applied. IANAL, but my understanding is that the boilerplate is not required for the license to be valid or enforceable, and in fact it's merely a "recommendation" by the FSF that the boilerplate be used. In fact, in the text of GPLv3 they state the recommendation as: ======== How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found. <one line to give the program's name and a brief idea of what it does.> Copyright (C) <year> <name of author> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. Also add information on how to contact you by electronic and paper mail. ======= [From: https://opensource.org/licenses/GPL-3.0 ] So, it would be sufficient in theory to display merely the copyright and authorship lines. That being said, it's easy to imagine reasons why it might be beneficial to have the full boilerplate statement in a source file, especially in cases where it ends up getting removed from the context of the project and used in isolation somewhere else (either in accordance with or in violation of the license terms). Ultimately, it is only a header comment, and if someone truly finds it a distraction most advanced code editors have some ability to automatically fold such comment blocks if so configured. But for the purposes of our package review — well, _nothing_ is "required", the notification here is merely informational, but we only look at the main LICENSE file itself. The code headers are, as I said, entirely the project's choice to deal with in whatever manner you see fit. As with most such things whenever an undertaking intersects with the law, I'm sure you can find someone who will advise you that any course of action is absolutely required to protect your efforts, and someone else who will claim that the same course of action will completely sabotage those efforts. "The nice thing about standards is that there are so many of them to choose from." —Andrew S. Tanenbaum |
|
|
Just a short add on for other people who may be reading this. We have tested the "noexecstack" additional add on Fedora (obviously since that it was we use!) and Mint18 and Ubuntu16. The big concern for the builds on 16 or so distros at the end of the month is always impact on one of them. FreeBSD is a different animal and again, not an area of much expertise. Slackware can be difficult also so we will probably start the "end of the month builds a day early in case of problems". |
|
|
Thank you again for passing this information along so well documented for my/our understanding. (1) I am still looking into the GPL license and how to best fix/incorporate it. Hoping to put into a single file instead of every routine because it gets in the way for programming. The monitor display is a resource, just like RAM, and using it up for repetitive information is not helpful. (2) your desktop patch was applied; but I did miss reading about the X-Multimedia so might have to delete that instead (3) gg did rework the executable bits being set but in a different manner for now (4) he fixed the execstack issue by forcing the noexecstack option on the load; it seems that that should already be the default since generally this is usually "needless" and not good practice The files listed used png's for the themes and opengl for the chromakeyhsv and the source code can not be easily revised. Any technical requotes above may be technically not quite right. These improvement suggestions are welcome; it is not our area of expertise and is just something gg was roped into having to do to get the software out there. |
|
|
Ah, shoot. I didn't realize my "#digit" numbering in the original report would be translated into issue references. If anyone is able to edit the report text and remove those links, just so it's less confusing, that'd be appreciated. I'll try to remember not to do that in the future. (Mantis _really_ needs a Preview feature for the report/note editor. *sigh*) |
|
|
|
- Anonymous
