Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding
Package: sponsorship-requests Severity: wishlist Xchroot 2.7.4 has also come with many new features. Dbus session creation and /dev/shm mounting satisfy the need even of exigent GUI programs like the Otter browser. It has a /media and subdirectory automounter which is especially useful for mirroring mounts of removable media. It is even possible to run a whole desktop session like KDE, Gnome or Xfce in an xchroot container. Desktop link creation for the GUI menu is included. The program has evolved much since Debian fellows have initially persuaded me to make the program open source. That time there was interest in the development of xchroot regarding Debian.
Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding
Package: sponsorship-requests Severity: wishlist Dear Bart Martens, Dear mentors, I have now applied the necessary changes for package "xchroot" to get sponsored: https://mentors.debian.net/package/xchroot dget -xu https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.7.5-1.dsc Changes since the last upload: The changelog now contains only one entry with reference to making the ITP bug #721447 closed. Version number is -1 as required. version 2.7.5 has a more robust xauth mechanism and fixes a fallacy when X-authorization is given on a per user or local basis rather than by a MIT-MAGIC-COOKIE-1: Now xchroot can generate the cookie on the fly if none is encountered: https://www.elstel.org/ViewRSS.php?guid=7470#7470 Regards, Elmar Stellnberger
Bug#932915: RFS: qcoan/2.0-6
Hi Adam Thanks for the work you have put into qcoan. I hope that we will get someone else to have a look at the program soon. I have now added the missing dependency for qcoan. Regards, Elmar Am 30.07.19 um 06:16 schrieb Adam Borowski: On Mon, Jul 29, 2019 at 02:02:58PM +0200, Elmar Stellnberger wrote: I have now changed something in the dependencies and hope that this will work better for you. Alas: qmake -qt=qt5 qcoan.pro Project ERROR: Unknown module(s) in QT: core gui widgets After adding qtbase5-dev, it builds. But unfortunately, due to hardware problems, I cannot really continue. All my machines that both 1. work and 2. are adequate for mucking with gui stuff, are on a different continent; unless situation improves I won't be able to review this in quite a while. Thus, I'm afraid it'd be best to ask someone else for now. Meow!
Bug#932915: RFS: qcoan/2.0-6
I have now changed something in the dependencies and hope that this will work better for you. Am 28.07.19 um 02:02 schrieb Adam Borowski: On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote: This is a strange error. I have tested the package locally on Debian 10 as well as on Debian 8 and Debian 9 via the OpenSuSE build service. Well, "Debian 9" is oldstable, while all new packages must go to unstable (and at most get backported later). That's a difference of two major releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although it did already see the flurry of post-Buster upload). No wonder the package fails to build. For the obs it tests building the package in a previously empty chroot and installs only the packages given via the build dependencies. Consequently I can exclude that there is some missing dependency. Also, I see that that OpenSuSE build service uses some hacked up homebrewed dependency resolution -- it likely has a different behaviour than native Debian tools, which also may be the culprit. I´m afraid you will have to research what causes that error message on your computer. The official archive requires all packages to be buildable on unstable using sbuild; pbuilder may also work -- it has different defaults (notably, doesn't strip alternative build-dependencies) but those don't apply to your package. I haven't started the real review yet -- just tried if it builds -- but I already see that the -dbg package is obsolete; these are built automatically since quite a while ago. On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote: * Package name: qcoan Version : 2.0-6 Meow!
Bug#932915: RFS: qcoan/2.0-6
I have now installed a plain Bullseye chroot with debootstrap, installed all packages in build-depends and then run dpkg-buildpackage and see it builds without any problem. There needs to be something messed up with your build environment. Please have a look! Am 28.07.19 um 02:02 schrieb Adam Borowski: On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote: This is a strange error. I have tested the package locally on Debian 10 as well as on Debian 8 and Debian 9 via the OpenSuSE build service. Well, "Debian 9" is oldstable, while all new packages must go to unstable (and at most get backported later). That's a difference of two major releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although it did already see the flurry of post-Buster upload). No wonder the package fails to build. For the obs it tests building the package in a previously empty chroot and installs only the packages given via the build dependencies. Consequently I can exclude that there is some missing dependency. Also, I see that that OpenSuSE build service uses some hacked up homebrewed dependency resolution -- it likely has a different behaviour than native Debian tools, which also may be the culprit. I´m afraid you will have to research what causes that error message on your computer. The official archive requires all packages to be buildable on unstable using sbuild; pbuilder may also work -- it has different defaults (notably, doesn't strip alternative build-dependencies) but those don't apply to your package. I haven't started the real review yet -- just tried if it builds -- but I already see that the -dbg package is obsolete; these are built automatically since quite a while ago. On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote: * Package name: qcoan Version : 2.0-6 Meow!
Bug#932915: RFS: qcoan/2.0-6
This is a strange error. I have tested the package locally on Debian 10 as well as on Debian 8 and Debian 9 via the OpenSuSE build service. For the obs it tests building the package in a previously empty chroot and installs only the packages given via the build dependencies. Consequently I can exclude that there is some missing dependency. I´m afraid you will have to research what causes that error message on your computer. https://build.opensuse.org/package/show/home:estellnb:elstel/qcoan Regards, Elmar Am 27.07.19 um 06:45 schrieb Adam Borowski: On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote: * Package name: qcoan Version : 2.0-6 Changes since the last upload: The package is now available under GPLv3 I'm afraid it fails with: dh_testroot rm -f build-qt/* changelog.Debian.gz dh_clean debian/rules build #find .. # -> ../SOURCES, ../BUILD/ - .at.bz2 extracted here, current dir, ../qcoan_2.0-0.dsc, ../qcoan_2.0-0.diff.gz, ../DEBS, ../OTHER qmake qcoan.pro qmake: could not find a Qt installation of '' make: *** [debian/rules:23: build] Error 1 Meow!
Bug#932915: RFS: qcoan/2.0-6
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "qcoan": * Package name: qcoan Version : 2.0-6 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/coan/ * License : GPLv3 Section : devel To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qcoan Alternatively, one can download the package with dget using this command: dget -xu https://mentors.debian.net/debian/pool/main/q/qcoan/qcoan_2.0-6.dsc More information about qcoan can be obtained from https://www.elstel.org/coan/. Changes since the last upload: The package is now available under GPLv3 Regards, Elmar Stellnberger
Bug#932913: RFS: confinedrv/1.7.7-4
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "confinedrv": * Package name: confinedrv Version : 1.7.7-4 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/qemu/ * License : GPLv3 Section : utils To access further information about this package, please visit the following URL: https://mentors.debian.net/package/confinedrv Alternatively, one can download the package with dget using this command: dget -xu https://mentors.debian.net/debian/pool/main/c/confinedrv/confinedrv_1.7.7-4.dsc More information about confinedrv can be obtained from https://www.elstel.org/qemu/. Changes since the last upload: The package is now available under GPLv3 Regards, Elmar Stellnberger
Bug#932911: RFS: bundsteg/1.2-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "bundsteg": * Package name: bundsteg Version : 1.2-2 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/bundsteg/ * License : GPLv3 Section : utils To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bundsteg Alternatively, one can download the package with dget using this command: dget -xu https://mentors.debian.net/debian/pool/main/b/bundsteg/bundsteg_1.2-2.dsc More information about bundsteg can be obtained from https://www.elstel.org/bundsteg/. Changes since the last upload: The package is now available under GPLv3 Regards, Elmar Stellnberger
Bug#932909: RFS: xchroot/2.3.4-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "xchroot": * Package name: xchroot Version : 2.3.4-2 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/xchroot/ * License : GPLv3 Section : x11 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xchroot Alternatively, one can download the package with dget using this command: dget -xu https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.3.4-2.dsc More information about xchroot can be obtained from https://www.elstel.org/xchroot/. Changes since the last upload: The package is now available under GPLv3 Regards, Elmar Stellnberger
Bug#904612: packaging of qcoan fully revised
The packaging quality of qcoan has been highly improved since my original RFS. There are no more lintian errors that should be resolved and with the advice from wRAR at #debian-mentors I have improved the package internals (no nested .tar.bz2, debian/install list). see: https://mentors.debian.net/package/qcoan
Bug#904612: RFS: qcoan/2.0-3 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "qcoan" * Package name: qcoan Version : 2.0-3 Upstream Author : Elmar Stellnberger estel...@elstel.org * URL : https://www.elstel.org/coan/ * License : C-FSL v1.1 Section : devel It builds those binary packages: qcoan - Automaton and Turing Machine Simulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qcoan Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qcoan/qcoan_2.0-3.dsc More information about qcoan can be obtained from https://www.elstel.org/coan. Regards, Elmar Stellnberger
Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Hi Gianfranco, Hi Tobias,
Hi all Readers of this Debian Mentor Request,
Am 2016-08-25 um 13:12 schrieb Gianfranco Costamagna:
Now this is an additional restriction: you need to provide everything
that is necessary to run your software under an OSS based system (with
exceptions given for the kernel modules).
I think this is a GPL-3 restriction, if you mean "Tivoization"
https://en.wikipedia.org/wiki/Tivoization
Sounds good to me. Then I am going to analyse GPL-3 and see if I can
adopt it for my programs.
(and this is a good reason to stay away from GPL-3)
... just the other way round
Another issue is that I do not want to 'register' i.e. sell my
personal data to a company I do not trust just in order to fetch
their GPL-ed sources.
also not part of GPL.
what?
sorry I don't follow this sentence ;)
some minor issues that would remain (like obtaining the sources without
undue obstacles) ..., however likely nothing that could stop me from
adopting GPL-3 for my programs.
>>> The problem about additional GPL-2 clauses seems to be that they
>>> can be dropped at any time. An unpleasant contributor can do so any
>>> time and I would not be able to incorporate his changes if I wanna
>>> keep the additional freedoms I wanna guarantee for the upstream
>>> version.
>> They can be dropped (and, in fact, ignored completely) only if they
>> introduce additional restrictions conficting with the GPL itself. If
>> you're granting additional rights, you're free to grant them only
>> under a certain condition ("you're free to relicence this software
>> under a different license but you must keep this statement in tact").
> I guess so
Anyone else who could assert me that an additional GPL-3 clause would
do what I want: i.e. give an additional right to relicense to a group
called original authors only; let this be called GPL-3 + relicensing by
authors. The GPL-3 amendment would more or less be the same as #7 of
C-FSL and a statement to tag the GPL-3 abbreviation with the relicensing
by authors flag.
Is it really true that this can not be interpreted as restriction
just because any contributor would have to consent in giving the
original authors this additional right. It means that someone who does
not consent is not allowed to apply changes because then the whole
license would need to turn invalid.
Finally I would like to ask anyone who knows about another issue with
C-FSL to share it with me as the programs in question will likely be
available under C-FSL + GPL-3 + relicensing by authors for some ongoing
time.
up to now I have noted the following issues for C-FSL:
* explicitly allow unchanged redistribution
* version number to use as default: v1.1
* mention online URL in the license
see: https://www.elstel.org/license/C-FSL-v1.0.txt
Regards,
Elmar
Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Am 2016-08-25 um 12:39 schrieb Andrew Shadura:
On 25 August 2016 at 11:53, Elmar Stellnberger wrote:
Am 2016-08-25 um 10:45 schrieb Gianfranco Costamagna:
I see many GPL-2 similar-looking licenses, with some special exceptions,
e.g.
"In addition to the above license, you can relicense this software in
whatever
form you want, with a special exception: you can't do foo and bar if you
change the
license"
The problem about additional GPL-2 clauses seems to be that they can be
dropped at any time. An unpleasant contributor can do so any time and I
would not be able to incorporate his changes if I wanna keep the additional
freedoms I wanna guarantee for the upstream version.
They can be dropped (and, in fact, ignored completely) only if they
introduce additional restrictions conficting with the GPL itself. If
you're granting additional rights, you're free to grant them only
under a certain condition ("you're free to relicence this software
under a different license but you must keep this statement in tact").
Yes, that is a good point and it certainly proves that GPL would work
in this regard; but what about the other two issues:
> I do also know that the KDE team had a problem with their license
> when Apple came to publish their respective amendments in the sources
> of Safari. They do not run and will never run on OSS and this makes
> Apple publishing their sources rather useless to the OSS community.
Now this is an additional restriction: you need to provide everything
that is necessary to run your software under an OSS based system (with
exceptions given for the kernel modules).
> Another issue is that I do not want to 'register' i.e. sell my
> personal data to a company I do not trust just in order to fetch
> their GPL-ed sources.
also not part of GPL.
Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Am 2016-08-25 um 10:45 schrieb Gianfranco Costamagna: I see many GPL-2 similar-looking licenses, with some special exceptions, e.g. "In addition to the above license, you can relicense this software in whatever form you want, with a special exception: you can't do foo and bar if you change the license" The problem about additional GPL-2 clauses seems to be that they can be dropped at any time. An unpleasant contributor can do so any time and I would not be able to incorporate his changes if I wanna keep the additional freedoms I wanna guarantee for the upstream version.
Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Am 2016-08-25 um 06:52 schrieb Tobias Frost: Am Mittwoch, den 24.08.2016, 22:06 +0200 schrieb Elmar Stellnberger: The license in use, C-FSL v1.0 will still need to be reviewed. A predecessor license C-FSL v0.8 had already been discussed on debian-legal some time ago. However v1.0 has been reworked basing on the input I had received from there and should now hopefully be without issues. I think one recommendation has not been followed. If not, I *strongly* recommend: PLEASE Do not run your own license. See https://people.debian.org/~bap/ dfsg-faq.html §5 I took me some time to locate this license (please put it somewhere and link to it). The license is online under https://www.elstel.org/license. The URL may be a bit hard to find and if you like I can link it from https://www.elstel.org/software/. You are right; the URL should probably be referred to in the license itself. If you have any further improvements towards locating the license then please let me know. I located it then in the header of the xchroot script, and as I only had 5 minutes to take a look, I come only to this sentence: "If a specific version number is mentioned then usage rights include this version as well as any newer version which will always be similar in spirit to this license. The term Convertible Free Software license may be abbreviated as C-FSL." - This will fail the the tentacle of evil test. - What happens if there is no version number attached? Choose any? Choose latest? It should not fail the tentacle of evil test as the user of the program may choose which version of the license to execute: the version mentioned with the programme or any newer version. It quasi gives any new author the right to re-license within C-FSL. As the original author never looses his/her copyright he can always re-license (whatever the previous license may look like: BSD/GPL/...); i.e. you can never (fully) shield against the case of an evil author re-licensing proprietarily under any given license of the universe - with BSD that is not even intended. The right to switch to a newer version is up to anyone who receives a program under C-FSL and it does not forbid to keep an elder version of the license if you prefer that. This is due to the principal of legal certainity taking precedence over correctness of law and it is a basic principle in any legal system I know. The clause has just been invented to alleviate me from the pain of having to re-publish existing programs with a newer version of the license (in which case both versions can be applied forever). no version number attached: you have a good point in it as we had already discussed v0.8 of the license which was never meant to be executed in practice; I should have included the version to default to 1.0 at least; not sure what it would take to make this good. "3. It is your obligation that the changed version of your sources will be available to the public for free within the time frame of a month at least if there is no undue hindrance by the authors to make it available. " As distribution is not limited to the people using the stuff, this is non-free. Fails Desert Island Test and Dissident Tests. You have a good point in this! Thanks for your input. I should mention: "You may always distribute a product under C-FSL in unchanged form. ..."; otherwise if you change or execute the term 'use' would clearly apply to my believe. (I have stopped here... Above is not a complete analysis of any section, also not up to 3.I) PLEASE do not run your own license. Yes, I know that usage of an own license is discouraged due to the many issues that may arise. However I do certainly have a point in creating this license as I wanna keep the right to re-license which is not included by GPL. BSD on the other hand has no provisions against making software licensed under BSD non-free be it by the application of patents, DRM or other stuff. I do also know that the KDE team had a problem with their license when Apple came to publish their respective amendments in the sources of Safari. They do not run and will never run on OSS and this makes Apple publishing their sources rather useless to the OSS community. Another issue is that I do not want to 'register' i.e. sell my personal data to a company I do not trust just in order to fetch their GPL-ed sources. -- tobi If anyone here would be ready to further investigate C-FSL I will highly appreciate your effort in doing so. Why not have a discussion at debian-legal? I`d personally like to get the issues with it resolved as soon as possible. Otherwise if you believe that I do not have sufficient stance to do so by the software I have currently released then I would need to wait ... Elmar
Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Package: sponsorship-requests Subject: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone! Severity: wishlist Dear mentors, I am looking for a sponsor for my package "confinedrv": * Package name: confinedrv Version : 1.7.7-3 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/qemu * License : C-FSL v1.0 Section : utils It is a little script with a man page wrapped into a package: confinedrv - mirror an existing drive but with confined access rights on a per-partition basis (ro/rw/zero/err); there is also a possibilty to use image files for the MBR as well as individual paritions. Every now and then I receive an email of people who like and successfully deploy the program. That is why I think it would be beneficial to promote this little helper script for device mapper into Debian and other distributions. It also shows that the script has proven quite useful in many situations. To access further information about this package, you may also visit the following URL: https://mentors.debian.net/package/confinedrv Alternatively, one can download the package with dget using this command: dget [-x] https://mentors.debian.net/debian/pool/main/c/confinedrv/confinedrv_1.7.7-3.dsc Information about confinedrv can be obtained from the documentation that ships with the package as well as online under https://www.elstel.org/qemu. What will also need to be analysed: The license in use, C-FSL v1.0 will still need to be reviewed. A predecessor license C-FSL v0.8 had already been discussed on debian-legal some time ago. However v1.0 has been reworked basing on the input I had received from there and should now hopefully be without issues. If you decide to review the license do not do it just for confinedrv but for all programs offered by elstel.org: bundsteg (printing with inner margin), xchroot (chroot for X11), debcheckroot (security aware alternative for debsums), dbschemacmd (tool to normalize database schemata), coan for Linux/Qt (coming soon; simulate deterministic / non-deterministic FA, PDA, Turing Machines) pubkey and SHA512SUMS.signed for all programs at elstel.org (DNSSEC/DANE supported) can be found at: https://www.elstel.org/software/SHA512SUMS.signed https://www.elstel.org/auxil/estellnb.pubkey.asc ( also: https://www.elstel.org/auxil/estellnb-offline.pubkey.asc ) Changes since the last upload: none; this package has been uploaded newly. Kind Regards, Elmar Stellnberger
Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots
Am 12.11.2013 10:24, schrieb Andrew Shadura: Hello, On 12 November 2013 10:22, Elmar Stellnberger wrote: O.K. That is actually what is to be done next. There are some people whom I know and who I am going to consult. It will at last be necessary in my very own interest to assert that the license will work in practice as intended. I hope you are going to accept the results if and only if I consult someone who is a lawyer. Again, thanks for your contribution to the license. It was actually necessary to make it fit for practical usage. Unfortunately, it's still unfit for use. Could you tell me in a short why you do think so. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52821cfa.9020...@gmail.com
Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots
O.K. That is actually what is to be done next. There are some people whom I know and who I am going to consult. It will at last be necessary in my very own interest to assert that the license will work in practice as intended. I hope you are going to accept the results if and only if I consult someone who is a lawyer. Again, thanks for your contribution to the license. It was actually necessary to make it fit for practical usage. Yours Sincerely, Elmar Stellnberger P.S. I hope my postings to the OSI license-discuss mailing list from last week will get posted soon. Am 12.11.2013 07:41, schrieb Bart Martens: Hi Elmar, It's OK that you write your own non-free license, but this license in particular has, in my opinion, too many serious flaws to allow it in section non-free. I suggest to get professional legal advice or to use an existing well-known license. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5281f348.1050...@gmail.com
Bug#728716: xchroot: packaging as non-free
Am 08.11.2013 18:04, schrieb Paul Tagliamonte: Email ftpmas...@ftp-master.debian.org with your license, and the ftpteam will disucss if we can distribute it safely. If so, you can upload it to non-free. Ask your sponsor for more information on that. Please note that non-free is *not* Debian (the distribution), but is mearely software hosted on Debian boxes, and given small amounts of infra (such as the BTS). We will *not* autobuild the package on the buildd network, and you won't see project members coming to help fix RC bugs (it's more likely it'll be removed if bugs are not tended to quickly). Cheers, Paul If you know about any issue, please report it to me (estel...@elstel.org) before it should get uploaded to non-free or any other branch. On Fri, Nov 08, 2013 at 06:03:35PM +, Elmar Stellnberger wrote: You're free to try to get it into non-free. Thanks! Paul How to apply for acceptance in non-free? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527ff003.8050...@gmail.com
Bug#728716: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
Am 08.11.2013 16:33, schrieb Paul Tagliamonte: On Fri, Nov 08, 2013 at 04:15:30PM +, Elmar Stellnberger wrote: "specific to someone": Well this is an unavoidable necessity in order to Maybe, but specific clauses like this clearly violate OSD #3 and #5 (#3: if your downstream “A” is a “public distribution” and A’s downstream “B” isn’t, B cannot distribute them under the same terms as it got them from A under). Well we could crop out this special facilitation but that would make the license less fit for practical purposes. I do not want to sacrifice practical fitness towards perfectly strict OSI compliance. To be clear, not satisfying OSD 3 & 5 (DFSG 3 and 5 as well) this will *NOT* be fit for Debian main. You're free to try to get it into non-free. Concerning OSD conformance please see for the discussion at http://projects.opensource.org/pipermail/license-discuss/2013-November/001358.html. #3: It does clearly allow derived works; shielding of copyright notices does not contradict this. #5: Additional facilitation in certain use cases does not discriminate against people or groups of people. Please do also read the argumentation at license-discuss about it. Thanks! Elmar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527fbd34.5070...@gmail.com
Bug#728716: xchroot: packaging as non-free
You're free to try to get it into non-free. Thanks! Paul How to apply for acceptance in non-free? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527d2777.2020...@gmail.com
Bug#728716: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
Am 07.11.2013 20:21, schrieb Thorsten Glaser: However it is not an OSD criterium Independent on whether it is or not (it’s not explicitly listed, as are other things people have commented on, but some of these things can be inferred from the OSD), I said in my first eMail that I’d do a general comment on the S-FSL, no (pure) OSI review. That is right. I wanna have a license that should suffice the need of all parties or at least will be acceptable to them. (For that matter, I’m also lead developer of both a BSD and a GNU/Linux distribution, *and* a Debian Developer, too, that’s why I have feet in multiple camps.) However if there is some broader effort to establish new features I would simply consider it good style to notify the upstream maintainers. The software below could change. I agree, but it’s much better to just _request_ it. Sensitive people will upstream their patches anyway (if upstream is reachable), since not doing so massively increases maintenance burden, especially when keeping up with active upstream development. That should be resolved in the new upcoming S-FSL version 1.3.6. "specific to someone": Well this is an unavoidable necessity in order to Maybe, but specific clauses like this clearly violate OSD #3 and #5 (#3: if your downstream “A” is a “public distribution” and A’s downstream “B” isn’t, B cannot distribute them under the same terms as it got them from A under). Well we could crop out this special facilitation but that would make the license less fit for practical purposes. I do not want to sacrifice practical fitness towards perfectly strict OSI compliance. Someone who obfuscates his modifications can hardly claim possession on my work. Of course not, only on their changes, but that is generic. move it to another place; i.e. from the help->about menu to some obfuscated place which should not happen either That will make it a forbidden invariant section. You cannot, in OSS, prevent people from doing so, period. (In this case you’d probably be better off with the GNU AGPL, because it does what-you-really-want in a more OSS way than what you’re trying to do.) No back-stabbing changes on copyright notices should be required. If a certain level of tradeoff in this area can not be achieved then you will have to package as non-oss. development. Top down in its primary sense simply requires some sort of privileges and control. But too much of it and you can’t call it OSS any more. should be improved in the upcoming 1.3.6 revision. That is where I argue with homomorphism. You can strip a full context diff into a no context diff. Consequently the no context diff is a derived work of the full context diff. Oh, but copyright law does not work this way. For example, I own all of my (copyrightable) sentences in this eMail that I wrote, but none that you wrote. You own all those you wrote, but none that I wrote. If someone cites a sentence I wrote in this eMail, it doesn’t mean you’ve got any rights in the thing that other person writes citing my sentences. Well it does. By changing any part of the program you will specify implicit consent with the terms stated in the license. It has been proven to work for the DEC SRC M3 license and it will work on S-FSL too. If it is independent work I believe it should be distributed as such. i.e. as standalone file rather than as a patch. In your scenarios, patches are standalone files. To me a patch is something that refers to the part which is to be patched. Ah. That’s a rather narrow definition. I have a combination of a Debian source package (with all red tape this requires) whose debian/rules unpacks a *.deb then runs forward ed(1) diffs on the contents and regenerates some things like md5sums then repacks it. The debian/rules script is a patch, as are those forward ed diffs. Yet, they are not derived works of the .deb that’s binpatched, only the result is. Hm. Actually, maybe the better term for these is “compiler”, as this sounds awfully like what gcj does when compiling *.jar files into *.so DLLs. But it’s still oftentimes referred as patch… I hope it will not be necessary to define what a patch is. Well and I do not want to talk about compilers because that is in some of a way too specific for my needs. It was one of the design goals of that license to protect software which is not compiled in the same way as other. Contracts with the authors of the patches? That is not viable in practice. I will simply dump any patch like this or disallow your contribution! The license is here to assert that this is not necessary. But in Open Source, the right of the user to fork the code (e.g. if they disagree with upstream) is basic. improved in the upcoming revision v1.3.6. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527d0e22.5060...@gmail.com
Bug#728716: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
Hi mirabilos, Am 07.11.2013 17:34, schrieb Thorsten Glaser: FWIW, the GMane thread view for the Debian bug on this is: http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/1099104 The bugreport is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728716 although I’d have put it into the ITP bug #721447 instead. Elmar Stellnberger dixit: What about binaries? such as python, bash or perl. As the license says nothing about binaries I would presume that it is not forbidden to derive such binaries as long as the No, binaries are derived works. Yes, they are and the license does currently not give any restriction about them except for the naming convention (Perhaps we should mention there that derived works should contain a shorthand for the derivation process if it was automatic like mysw-version-gccbin.). Or what would you expect to be in there concerning binaries? If automatic derivations need special treatment ahead of this then what would it be? However at some point we do strongly recommend to get all changes incorporated into the main line. I believe it would really become a problem if the software is unmaintained or incompatible upstreams. However for this case we can either This has led to catastrophes, but also to improvements (full forks). I think you’re too restrictive here, especially for the all of the OSS ecosystem. Hmm, with this license it is the responsibility of the original authors to decide about this: either branch or integration into mainline. If an S-FSL developer does not have the resources for such work he can any time specify 'free branching'. one; not which one. The way I conceive things it is a right of the user to know who has changed what. Everyone who does a change to the software will be There’s CVS for it ;) I did not give any restrictions to where the changelog should be located; or did I? It could as well be an automatic git, cvs or svn history. At least it should be available in some sort to the upstream maintainers which should be possible to organize even for incompatible technologies. Do you think we need to specify these possibilities explicitly? Perhaps, yes. You are not the first to ask me. and drop everything to the community we have a huge quality problem as no one feels responsible for the outcome. I don’t think forcing people like this would help. [ desert island ] As far as I have studied law if there is a force majeure that prevents you from notifying the original authors or if there is some unreasonable burden to do so then you do not need to do that. - and on a desert island force majeure is Yes, but this is a metaphor for less “majeure” things. Please do not assume special provisions for the “desert island”, otherwise the test’s metaphor will obviously fail – it’s used to help comprehend the issue *behind* the test, not for its own good. The relevance of the desert island test needs to be examined, yet. It can only be infringed for non-public distributors. However it is not an OSD criterium (#1-#10). It would also pass for an individual. However if there is some broader effort to establish new features I would simply consider it good style to notify the upstream maintainers. The software below could change. upstream party will thus be o.k.. Note also that public distributors do not need to notify at all; only 'closed' distributions which obfuscate their sources need to. Consequently I would regard this as minor infringement. You don’t define “public distributors”, and this will make some parts of the licence specific to certain people _and not their downstreams_ which is an issue. Well, yes I do. It is in paragraphs 6. and 7. (ui; that should be numbered). "specific to someone": Well this is an unavoidable necessity in order to enforce bringing patches to the attention of upstream maintainers. Someone who obfuscates his modifications can hardly claim possession on my work. Well, we have allowed this for individuals who do not share their modifications/patches at all which is again "specific to certain use cases". My arguments against these issues are: It may be specific to use cases and organizational issues but it is not specific to people or groups of people. Furthermore you could simply leave these facilities out and the license would still work under OSD#1-#10. […] program and finally coded it in the first place. Invention includes primary requirements engineering. S-FSL assumes a proper software engineering and […] I think your ideas are really right, but trying to put them into this form will not work out. People do get along with the already-approved licences plus *asking* (but not legally requiring) to e.g. keep the “powered by FusionForge” comment on the output HTML, plus *reminding* people that things used in academic papers *must* be cited/acknowledged properly and that this-and-that is the correct citation for this piece of OSS software
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Dear Gergely Nagy, Dear members of Debian-legal Do you know a license somehow similar in spirit than mine which I could use? It would be nice to have something that oblidges 'closed distributions' to publish at least their sources as required by some software in RHEL which is what puts the CentOS distribution for the broad public into live. Thanks for Your Review, Elmar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52788da1.80...@gmail.com
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
S-FSL v1.3.3 uploaded at http://www.elstel.org/license/ Having clearly considered your critics I have published a reworked edition of S-FSL which should more strictly adhere to the terms of OSS-software. As you can understand and as I have already partially described there are still issues to me which discourage me from using an existing license like f.i. GPL or BSD. The new license is posted here for public review. We could possibly allow any distribution to distribute patches without notifying the "original authors" as far as the term "distribution" can be defined clearly and doubtlessly (i.e. to only apply this restriction to individuals and organizations who do not distribute their software for free to the public; if that would help us). That will not be possible, due to DFSG#3 (derived works): "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." Which means that whoever gets the software through Debian MUST be able to redistribute it under the very same terms Debian did. Furthermore, there are many distributions derived from Debian, asking all of them to send you patches whenever they make the tiniest modification (even to packaging!) is not going to work, neither for you, nor for Debian, nor for any of the distributions based on it. Now nothing that can be called a 'public distribution' needs to send out patches. The patches as well as the patched programs do automatically become subject to the same license. I would strongly suggest you reconsider your license, or at least this requirement, as it will never, ever work as you expect it to: people will just not use your software, because requiring them to send patches back no matter what is so huge a pain in the backside that noone in their right mind will do it. It's a much smaller effort to find an alternative (like schroot, in this case) or roll your own. Furthermore, there's this part of the license: "If you want to develop a separate branch of this program you need to ask the original authors for permission." That goes against DFSG#4, which permits the author to require distribution under a different name, but still requires the license to allow distributing patched versions. The quoted paragraph prevents that, so much so, that it's far too strict even for non-free: if we ever want to do a non-maintainer upload for whatever reason, it's not possible, because that may very well mean "develop a separate branch", and thus require asking for permission. now the term separate branch is clearly defined. It means publishing under a different name(ing convention). Furthermore, the quoted paragraph also has a loophole: it only requires one to ask the original authors for permission, it does not say that the permission needs to be granted too. In a strict reading of the text, just asking for permission and not waiting for an answer is ok. Even better, asking, but receiving a negative answer is still ok, because one asked. that loophole has been eliminated; thx. Going further: "Distribution of the program by third parties must be done free of charge apart from fees for the physical reproduction of the data medium" This goes against DFSG#1: "The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale." While this part may be okay for non-free, it definitely is a no-go for main. The exceptions given do not matter. 'exception' can now be any software or additional service as long as xchroot is not distributed outside of a distribution; that should suffice. The way distribution is defined is also a bit odd: "The term distribution describes shipping of a given set of software and its documentation with adherent materials." So if I strip away parts of the software (like documentation), and publish that, does that count as distribution? Strictly reading the license: no, because adherent materials are not shipped with it. replaced by and/or; forgetting about docs should no more matter "Availablity free of charge or costs includes tools, software and manuals needed to download or obtain the distribution in a finally usable state as well as the possibility to verify the integrity of the download securely but not general connectivity to the internet." This part is also quite vague. Lets imagine the following scenario: there's Joe Average user, installing GNU/Linux for the first time. He has absolutely no idea how to do it, so he buys a book about the topic. To install additional software, such as those covered by this license, he uses tools and techniques described in the manual, for which he paid for. In this case, the distribution is not allowed to let Joe Average install programs covered by this li
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Am 04.11.13 17:56, schrieb Paul Tagliamonte: Control: tag -1 moreinfo On Mon, Nov 04, 2013 at 05:31:40PM +0100, Elmar Stellnberger wrote: The xchroot S-FSL v1.3.1 license would need some legal review. It was especially designed for distributions available free of charge like Debian. The license has been revised thouroughly and should not pose any restrictions concerning re-distribution by Debian or any other free distro. The author plans to publish more software under this or a reworked version of the S-FSL license. This license will be considered non-free in Debian. Please re-upload targeting non-free or change the license terms. o It forces distribution of changes to third parties. Is it really a problem? If yes then I can add an exception for distributors like Debian. However what I want is being noticed somehow about changed versions of my programmes. This is to collect new use cases and get updates quickly incorporated (Early versions of my program were heavily rewritten and patched as googeling has shown; though that time not even granted explicitly.). Being notified by third party users about their concerns and changes would yield major contribution to the future development. (There are no copyright issues though since the actual code added by me so far has been completely different from the diversions found out there; though it has been very useful in extracting new use cases.). o One may not change for the software (or use it in a commercial product), or be used *from* non-free software as a plugin (etc). The phrasing in here is odd. Well this is already the standard for the GPL-license: GPL programs as far as being compiled can not be incorporated into commercial software; you have to use L-GPL. Why not establish a similar standard for protecting intellectual property also for programs written in a script language? (i.e. this is the reason why I called it S-FSL). If the phrasing is odd we will have to rework it; it is my intention to have a license clear to everyone; not only to lawyers. I strongly encourage you to not write your own license terms. Please consider using a well-known and understood license. Well to me it is an issue under which license to publish. I do not want to burden my distributor unncessarily but actually want to retain as much rights as possible because writing, maintaining the software and supporting also casual users is a major effort. Cheers, Paul Many Thanks for your Commitment, Elmar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5277d7c7.3030...@elstel.org
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Package: sponsorship-requests Subject: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian! Severity: wishlist Dear mentors, I am looking for a sponsor for my package "xchroot": * Package name: xchroot Version : 2.3.2-9 Upstream Author : Elmar Stellnberger * URL : https://www.elstel.org/xchroot * License : S-FSL v1.3.1 Section : x11 It is a little convenience bash script with man page wrapped into a package: xchroot - extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots I am sure you will like it; also good for packaging with multiple OS versions. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xchroot Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.3.2-9.dsc More information about xchroot can be obtained from https://www.elstel.org/xchroot. Changes since the last upload: Today I have fixed a lot of warnings shown by the pacakge evaluation of mentors Note: The xchroot S-FSL v1.3.1 license would need some legal review. It was especially designed for distributions available free of charge like Debian. The license has been revised thouroughly and should not pose any restrictions concerning re-distribution by Debian or any other free distro. The author plans to publish more software under this or a reworked version of the S-FSL license. Kind Regards, Elmar Stellnberger
Re: Suggestion of new program: execute mathematical set operations on lists
Am 03.11.13 15:43, schrieb Frank Stähr: Am Mittwoch, den 30.10.2013, 16:21 + schrieb Elmar Stellnberger: Well, I had once programmed a tool like this called mset (multiset) Yes, it seems to be possible to combine set and multiset operations by an option (i. e. -m switches to multisets), I didn’t thought of that. Of course, your answer is not the one I wanted to here (wanted to program it ;-)), but still better than double work. Good luck with leutils in the future, perhaps I think of another nice project for me. Frank Hi Frank, If you want we can share our sources, agree upon a license for them, discuss the future UI and then program what hasn`t been implemented yet. However don`t expect a tool which is ready to publish, yet. I have just written that as a few-hourer for a specific purpose and not used it much afterwards. However if you can contribtue with further use-cases testing and development work let us tackle a (multi-)set utility for Linux which can then be published along with some other useful utilities like f.i. dircmp, a console directory comparison. Cheers, Elmar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52768f55.8080...@gmail.com
Re: Suggestion of new program: execute mathematical set operations on lists
Well, I had once programmed a tool like this called mset (multiset) and it is still on my hard disk though releasing it would require some kind of testing and quality assurance (I call the package leutils). First of all the xchroot package I have just released would need to get accepted before I can go on publishing and packaging more of my software stock. For the meanwhile you can use the following programs: sort -u, comm, join, uniq, column, paste, colrm, etc. which do almost provide an equivalent functionality if you use them in the right way: comm: set difference, intersection, union, delta sort -u: set union, etc. Elmar Stellnberger 2013/10/30, Frank Stähr : > Hello everybody, > > I am not yet looking for a sponsor, but going to program a tiny tool. > Because I am unexperienced and don’t want to do all the work for > nothing, first of all: > > Is this tool senseful, is there a certain need for it? I am very > interested in your opinions, hoping that this list is the right place > for that. > > > And here it is: setop takes as inputs several lists/sets, calculates > desired (mathematical) set operations on them and outputs the final set > (or depending on operation resulting number of elements, answer yes/no, > …). > > For example: File A contains 3 3 2 5 1 (each number an extra line). Then > setop A > would result in 1 2 3 5. This is equivalent to > sort | uniq > > With a file B containing 5 90 2 7 the command > setop -i A B > would yield 2 5. > > Here, -i stands for intersection. Of course, there is no limitation to > numbers, elements can be any non-empty strings. > > Other operations are union, symmetric difference, difference, contains > element, is subset, cardinality and so on. As you can see on > <http://www.catonmat.net/blog/set-operations-in-unix-shell-simplified/> > nearly all these operations can already be done with other tools, but > the according command lines are mostly very tortuous. There doesn’t seem > to be a tool that directly works with sets. > > I even exactly know what options setop (name ok?) should have and what > it can do (how it is used), but am waiting for some responses from you > before programming. > > I would be very grateful for your feedback, > Frank > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/1383147779.1944.30.camel@storch-desktop > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAHgGK3RSDQ_=avjuyqvf6fyq7m4kgaaowndwmwr1qs1aoy2...@mail.gmail.com
upload of xchroot-2.3.2-1 vanishes
Dear Debian Mentors, Having filed an ITP bug for xchroot as required (721447) and uploaded xchroot-2.3.2-1 with the correct key to mentors.debian.net by dput more than a day ago the package still has not appeared in my personal folder at https://mentors.debian.net/packages/my. Even before ~ 2013-10-23 I had tried to upload an elder version of the program which did also never appear in my personal packages folder. Having sent an email to supp...@mentors.debian.net as recommended in such a case I have not got any response up to now. Can you help me with this issue? Yours Sincerely, Elmar Stellnberger xchroot_2.3.2-1_i386.mentors.upload Successfully uploaded xchroot_2.3.2-1.dsc to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.2.orig.tar.gz to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.2-1.debian.tar.gz to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.2-1_all.deb to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.2-1_i386.changes to mentors.debian.net for mentors. Original-Nachricht Betreff: uploaded package is not in my packages folder Von: estel...@elstel.org An: supp...@mentors.debian.net Half a day ago I have uploaded xchroot-2.3.1-1 with dput but the package has not yet appeared in my personal folder; the day before I had uploaded an older version of xchroot and even this one has never appeared in my personal package folder. I had also successfully converted a RFP into an ITP for xchroot. The xchroot_2.3.1-1_i386.mentors.upload says the following: Successfully uploaded xchroot_2.3.1-1.dsc to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.1.orig.tar.gz to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.1-1.debian.tar.gz to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.1-1_all.deb to mentors.debian.net for mentors. Successfully uploaded xchroot_2.3.1-1_i386.changes to mentors.debian.net for mentors. What was going wrong here? Elmar sources: https://www.elstel.org/xchroot -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahggk3r8m7puwtucod7jxnjpo4e1bk2xejqujrd7b4vjq+1...@mail.gmail.com
RFS: xchroot-v2.3
name of the package: xchroot license: QPL-like; see for the program header or run the program with --license short description: extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots long description: xchroot is a little convenience bash script that will allow you to run X-based programs in your chroot environment. You may also chroot to a new environment without touching any of its files either by using aufs and unionfs. You may backup your temporary changes on exit and kill of xchroot as squashfs and incrementally restore them. download URL: http://www.elstel.org/xchroot https://www.elstel.org/xchroot why you should prefer packaging xchroot from elstel over xchroot from mosquito: * the program is known to deliver good quality since years and is also officially recommended by the openSUSE build service guide * the program is being actively developed; completely new features are planned. * there is a good online documentation for the program which does also leverage usage by casual users and users new to Linux * the incremental --save and --restore options not supported by mosquito will make life of packagers easy and leverage usage from read-only root file systems like roots on blue ray * unionfs as well as aufs support guarantee for a broad applicability; f.i. when dual booting between a distribution that only supports unionfs * support also for casual users why you should not package xchroot from mosquito: * no accomplished cleanup, kill -9 of processes, bugs and fallacies I do not want to talk about. * writing a completely different program and then giving it the same name as an already existent program will confuse innocent users (mine has already been there for years and it has been published under the name xchroot for a much longer time.) * the program has not been tested well under different conditions * no unionfs, no socat, no incremental restore, no good automounting support. * no backward compatibility with Debian 6.0.x * the authors did not respond at all on my request to join the work on elstel and to put xchroot under a better, generally accepted license P.S.: I believe it would also be good choice to support this script under the rescue console. When chrooting to a debian installation you will otherwise have to mount a lot while mounting everything of use is still too much for manual usage. This is a very common task for maintenance activities; I even do that when running grub-install. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5221d514.5000...@elstel.org
