Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 16.39 +0200, raingloom ha scritto: > > I think this might be the result of that survey? > https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core yes, this is it it seems here was no progress, since then
Re: 02/02: gnu: syncthing: Prepare for cross-compiling.
On Sun, Aug 15, 2021 at 04:42:19PM -0400, Leo Famulari wrote: > On Mon, Apr 26, 2021 at 02:33:56PM -0400, guix-comm...@gnu.org wrote: > > efraim pushed a commit to branch master > > in repository guix. > > > > commit b33f5d7ff0627424a06fd0416761cd81c350e20a > > Author: Efraim Flashner > > AuthorDate: Mon Apr 26 21:30:15 2021 +0300 > > > > gnu: syncthing: Prepare for cross-compiling. > > > > * gnu/packages/syncthing.scm (syncthing)[arguments]: Add custom > > 'pre-build phase to not set a local GOBIN directory. Adjust custom > > 'build and 'install phases accordingly. > > This commit broke splitting the package into two outputs "out" and > "utils". I meant to file a bug report, not send this to guix-devel: https://bugs.gnu.org/50071
Re: 02/02: gnu: syncthing: Prepare for cross-compiling.
On Mon, Apr 26, 2021 at 02:33:56PM -0400, guix-comm...@gnu.org wrote: > efraim pushed a commit to branch master > in repository guix. > > commit b33f5d7ff0627424a06fd0416761cd81c350e20a > Author: Efraim Flashner > AuthorDate: Mon Apr 26 21:30:15 2021 +0300 > > gnu: syncthing: Prepare for cross-compiling. > > * gnu/packages/syncthing.scm (syncthing)[arguments]: Add custom > 'pre-build phase to not set a local GOBIN directory. Adjust custom > 'build and 'install phases accordingly. This commit broke splitting the package into two outputs "out" and "utils". When everything is working, the utils output should look like this: -- $ tree /gnu/store/zansw6f7i61glpa2f5hsbpazwg6qfi2v-syncthing-1.15.1-utils /gnu/store/zansw6f7i61glpa2f5hsbpazwg6qfi2v-syncthing-1.15.1-utils ├── bin │ ├── stcompdirs │ ├── stcrashreceiver │ ├── stdisco │ ├── stdiscosrv │ ├── stevents │ ├── stfileinfo │ ├── stfinddevice │ ├── stfindignored │ ├── stgenfiles │ ├── stindex │ ├── strelaypoolsrv │ ├── strelaysrv │ ├── stsigtool │ ├── stvanity │ ├── stwatchfile │ ├── uraggregate │ └── ursrv └── share ├── doc │ └── syncthing-1.15.1 │ └── LICENSE └── man ├── man1 │ ├── stdiscosrv.1.gz │ └── strelaysrv.1.gz ├── man5 │ ├── syncthing-config.5.gz │ └── syncthing-stignore.5.gz └── man7 ├── syncthing-bep.7.gz ├── syncthing-device-ids.7.gz ├── syncthing-event-api.7.gz ├── syncthing-faq.7.gz ├── syncthing-globaldisco.7.gz ├── syncthing-localdisco.7.gz ├── syncthing-networking.7.gz ├── syncthing-relay.7.gz ├── syncthing-rest-api.7.gz ├── syncthing-security.7.gz └── syncthing-versioning.7.gz 8 directories, 33 files -- The broken state looks like this: -- $ tree /gnu/store/b1jz5rnwjgzvl7hd99rd1r5958rwxh5x-syncthing-1.15.1-utils /gnu/store/b1jz5rnwjgzvl7hd99rd1r5958rwxh5x-syncthing-1.15.1-utils └── share ├── doc │ └── syncthing-1.15.1 │ └── LICENSE └── man ├── man1 │ ├── stdiscosrv.1.gz │ └── strelaysrv.1.gz ├── man5 │ ├── syncthing-config.5.gz │ └── syncthing-stignore.5.gz └── man7 ├── syncthing-bep.7.gz ├── syncthing-device-ids.7.gz ├── syncthing-event-api.7.gz ├── syncthing-faq.7.gz ├── syncthing-globaldisco.7.gz ├── syncthing-localdisco.7.gz ├── syncthing-networking.7.gz ├── syncthing-relay.7.gz ├── syncthing-rest-api.7.gz ├── syncthing-security.7.gz └── syncthing-versioning.7.gz 7 directories, 16 files --
Re: issue tracking in git
Pjotr Prins writes: > On Fri, Aug 13, 2021 at 06:19:23PM +0200, Giovanni Biscuolo wrote: >> Hi Adriano and Ricardo, >> >> I'm also _very_ interested in keeping issues in the same repo as code >> and I'm really envious of Fossil users [1] :-D > > As a new initiative we are discussing/designing a gemini + git issue > tracker. I'm interested in follow your initiative, please announce it as soon as it's published somewhere! Thanks! Gio' [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Regarding copyright assignment to FSF
Hi, On Thu, Aug 12, 2021 at 12:18:20PM +1000, Damien Zammit wrote: > On 11/8/21 11:01 pm, Ludovic Courtès wrote: > > It would be interesting to consider dropping the copyright assignment > > requirement for Hurd/Mach/MiG. For what remains primarily a hobby > > project, this looks to me like a hindrance more than anything else. > > I imagine it is slightly inconvenient for new contributors, but not a > hindrance in my opinion. The fact that this process potentially or apparently took (or rather, has been taking) months for Sergey (I don't know when it was initiated), is a pretty good indicator that it is more than a nuisance. > It ensures that FSF has complete control of the licensing. I don't mind that, but I also think the Hurd is not a tactical FSF asset anymore that needs to be kept under tight control. The FSF has enough copyright in the Hurd that it can enforce it whenever it likes, even if other people's copyrighted code (as is already the case with the pfinet stack) is added. Finally, the GPLv2+ code can always be licensed to GPLv3+ once all the GPLv2only code has been removed, no copyright assignments are required there, either. So if the Hurd maintainers would like to drop the requirement (as has been done with GCC and glibc in recent months), I would support that. Michael
Re: Regarding copyright assignment to FSF
> On 2021-08-12 12:18:20 +1000, Damien Zammit wrote: > On 11/8/21 11:01 pm, Ludovic Courtès wrote: This seem somewhat off-topic for the lists, so I’m open to suggestions on what other forum to use (should anyone wish to continue this thread.) My suggestion is, as usual, to use a Usenet newsgroup, such as comp.misc, for the purpose. (See http://www.aioe.org/ for a free, no registration needed, IPv4-only newsserver; or http://www.eternal-september.org/ for free registration, IPv6 + IPv4 one.) >> It would be interesting to consider dropping the copyright assignment >> requirement for Hurd/Mach/MiG. For what remains primarily a hobby >> project, this looks to me like a hindrance more than anything else. > I imagine it is slightly inconvenient for new contributors, but not a > hindrance in my opinion. I’m going to concur; there’s some delay, sure, but not that much of actual effort on the part of the new contributor. Unless, of course, one’s employer is uncooperative, but I’m afraid that can’t be helped. > It ensures that FSF has complete control of the licensing. And enforcement. I’d argue that in a better world, no copyright assignment would be necessary (nor would be GPL, but that’s another matter), as anyone would be able to bring an infringement case to the court entirely by themselves. As it is, however, some considerations apply. As I understand it (though IANAL), there’re two parts to this story. First of all, copyright enforcement is, in general, a process that itself requires certain effort. Do you have time to spare on filing a suit? Will you have some more to see it through? Do you know a good lawyer to hire, or do you have the necessary skills to represent yourself in the court? What remedy will you seek? Moreover, /copyleft/ enforcement is tricky by itself. Copyright was devised, basically, as a legal tool for author to sue his publisher for royalties. As such, even though that does seem to slowly change, the first question of the court for your newly- brought GPL-infringement case would be: what sum, in your opinion, does the company owe you? Are you prepared to answer that? Given the above, I’m inclined to think that assigning copyright to a party legally prepared to fight for it to be a sensible choice /whether it is required or not./ And /especially/ for hobby projects; for I presume that for something you do for living, you’ll be quite in position to estimate damages arising from someone infringing your copyright. From here, we may try to rank different charities on how well they handle their enforcement cases. My guess is that FSF will come near the top. The other part concerns one’s employer, and the terms of the contract. For instance, the contract I’m currently under says that I’m entitled to copyright on any and all works I create, /unless/ I’ve been specifically directed by the employer to create any given work. From what I’ve heard, however, some contracts allow the /employer/ (variant: school) to claim copyright over any work created by the employee during the term of the contract. In this case, it’s arguably better for all parties involved to have the employer’s position clarified and known. Copyright assignment is one, though perhaps not the only, way it can be done. -- FSF associate member #7257 http://am-1.org/~ivan/
Re: Regarding copyright assignment to FSF
Michael Banck writes: > Hi, > > On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote: >> Michael Banck writes: >> >> > I don't mind that, but I also think the Hurd is not a tactical FSF asset >> > anymore that needs to be kept under tight control. The FSF has enough >> > copyright in the Hurd that it can enforce it whenever it likes, even if >> > other people's copyrighted code (as is already the case with the pfinet >> >> I wouldn’t be so sure about that. >> >> 1. Without copyright assignment of all code involved, enforcement >>becomes much harder. > > I don't think "much harder" can be quantified in a meaningful way, > seeing how parts of the Hurd aren't under the FSF copyright at this > point, anyway. A real life example is GNU Guix. There are (probably) more than hundred copyright holders (ain't I right, Ludo?). Is it possible enforce the copyright of that package? All copyright holders must cooperate to enforce GPL, which is probably impossible. >> 2. The Hurt still provides capabilities other OS’es don’t — while >>maintaining POSIX compatibility. We’ve seen audacity basically >>being taken over by a company in the past months, so the danger of >>losing Hurd to proprietarization rather got bigger than smaller. > > Nobody proposes that the FSF relicenses the Hurd to a non-copyleft > license before relinquishing the copyright assignment mandate, so I > don't see how the Hurd continueing to be under a GPLv2+ license will > ever be able to be taken proprietary. When copyright is not enforced, there is no difference between a GPL licensed and a public domain software. When a company sees that the copyright isn't enforced of a GPLed, it can take the program and make it proprietary. > I'm not going to respond further on this thread, this is starting to get > off-topic really quick and if there are further things to be discussed, > gnu-system-discuss or whatever other mailing list is likely the better > place. > > > Michael NOTE: I am not a lawyer. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 Get it with: gpg --recv-keys 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 See https://emailselfdefense.fsf.org/ to learn more and protect your emails and yourself from surveillance. Please send me encrypted messages whenever possible. Never send me Microsoft Office attachments, they use secret proprietary format so I'll fail to read and trash them; send them in plain text if possible or in formats like ODF and PDF if your document contains images or videos. See http://www.gnu.org/philosophy/no-word-attachments.html to learn more. Please don't send HTML emails, use plain text. HTML emails are usually vulnerable, about thousand times larger than plain text and look ugly to me. They contain trackers, so whenever someone opens a messsage he is tracked by third-party. See http://www.asciiribbon.org to learn more. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: PGP signature
Re: Regarding copyright assignment to FSF
Hi, On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote: > Michael Banck writes: > > > I don't mind that, but I also think the Hurd is not a tactical FSF asset > > anymore that needs to be kept under tight control. The FSF has enough > > copyright in the Hurd that it can enforce it whenever it likes, even if > > other people's copyrighted code (as is already the case with the pfinet > > I wouldn’t be so sure about that. > > 1. Without copyright assignment of all code involved, enforcement >becomes much harder. I don't think "much harder" can be quantified in a meaningful way, seeing how parts of the Hurd aren't under the FSF copyright at this point, anyway. > 2. The Hurt still provides capabilities other OS’es don’t — while >maintaining POSIX compatibility. We’ve seen audacity basically >being taken over by a company in the past months, so the danger of >losing Hurd to proprietarization rather got bigger than smaller. Nobody proposes that the FSF relicenses the Hurd to a non-copyleft license before relinquishing the copyright assignment mandate, so I don't see how the Hurd continueing to be under a GPLv2+ license will ever be able to be taken proprietary. I'm not going to respond further on this thread, this is starting to get off-topic really quick and if there are further things to be discussed, gnu-system-discuss or whatever other mailing list is likely the better place. Michael
Re: Regarding copyright assignment to FSF
On Sat, Aug 14, 2021 at 8:43 AM Michael Banck wrote: > The fact that this process potentially or apparently took (or rather, > has been taking) months for Sergey (I don't know when it was initiated), > is a pretty good indicator that it is more than a nuisance. Well, this is partly my own fault: I've been postponing trying to scan the signed papers (I can hack on kernel internals alright, but ask me to deal with a scanner and I'm lost). But that being said, the FSF has also been consistently slow to respond, so it would take months even if I had done everything promptly. Sergey
Re: issue tracking in git
On Fri, Aug 13, 2021 at 06:19:23PM +0200, Giovanni Biscuolo wrote: > Hi Adriano and Ricardo, > > I'm also _very_ interested in keeping issues in the same repo as code > and I'm really envious of Fossil users [1] :-D As a new initiative we are discussing/designing a gemini + git issue tracker. Rather than submitting to one central issue tracker the goal is to create a distributed issue tracker (no conflicts and you can own - and remove - your comments if you run a gemini server). It is early days, but it ought to give a new perspective on issue tracking. Pj.
