Ian Jackson writes:
> […] In the case of a pretrained neural network, the source code is the
> training data.
>
> In fact, they are probably not redistributable unless all the training
> data is supplied, since the GPL's definition of "source code" is the
> "preferred form for modification". For
added additional information to bug #382390
https://bugs.kde.org/show_bug.cgi?id=382390
__
MyTwitterPage:
http://twitter.com/OpenSimFan
MyInstagrampage:
http://instagram.com/dutchglory
MyFacebookpage
Dear -devel,
seems so as the discussion is more quiet than I've anticipated...
So as an optimist, I'm assuming this is because the proposal has
kind of rough consensus, so I will plan now for the next steps.
The discussion can and should of course continue, especially as it is
vacation time atm.
Package: wnpp
Severity: wishlist
Owner: Ruben Undheim
* Package name: python-gdsii
Version : 0.2.1
Upstream Author : Eugeniy Meshcheryakov
* URL : https://pythonhosted.org/python-gdsii/
* License : LGPL-3+
Programming Lang: Python
Description : Library
Package: wnpp
Severity: wishlist
Owner: Ruben Undheim
* Package name: netgen-lvs
Version : 1.5.105
Upstream Author : Tim Edwards
* URL : http://opencircuitdesign.com/netgen/
* License : GPL
Programming Lang: C
Description : Netlist comparison - Layout v
Hi,
I am curious about how to change an already existing git tag afterwards
(means: change the commit it points to).
Locally, I can change an existing tag, and then create it newly.
But I cannot push it to the remote repo (get
"! [rejected]139 -> 139 (already exists) "
There is -
Holger Wansing wrote:
> I am curious about how to change an already existing git tag afterwards
> (means: change the commit it points to).
> Locally, I can change an existing tag, and then create it newly.
> But I cannot push it to the remote repo (get
> "! [rejected]139 -> 139 (a
git push --tags --force - if one have the needed rights and the remote
settings allow it.
Cheers Alf
Hi,
Alf Gaida wrote:
> git push --tags --force - if one have the needed rights and the remote
> settings allow it.
This goes at least so far, that I get a clear error message:
remote: GitLab: You are not allowed to change existing tags on this project.
Thanks anyway
Holger
--
Holger Wansin
Hi Holger,
Am 12.08.18 um 14:17 schrieb Holger Wansing:
> Hi,
>
> Alf Gaida wrote:
>> git push --tags --force - if one have the needed rights and the remote
>> settings allow it.
>
> This goes at least so far, that I get a clear error message:
>
> remote: GitLab: You are not allowed to change
Hello again,
My previous mail didn't result in any feedback, so let me try again
with some more detailed questions that might be easier to discuss
related to the PAM configuration of su (and su-l).
As people are likely aware, the su takeover has now happened and
login (src:shadow) no longer ships
On 2018-08-12 14:35:22 +0200 (+0200), Carsten Schoenert wrote:
[...]
> that's a feature.
> Normally you don't want this and nobody can delete tags unintentionally
> as there is normally no reason to change history on a public git tree.
> The normal case is to create new tag with the according commi
2018-07-30 22:36 Adrian Bunk:
And the next burden will be if riscv64 gets added in bullseye.
Not likely, I think, since for example there's almost no hardware
available for end-users to buy (or to use for buildds), and this will
probably be the case at least until the freeze [*].
Another reas
Nearly 3 months ago there was a mass bug filing on packages with dead alioth
lists as maintainer. Many of these bugs are still open with no maintainer
response
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Alists.alioth.debian.org;submitter=debian.axhn%40manchmal.in-ulm.de
(no
On Sun, Aug 12, 2018 at 07:13:06PM +0100, peter green wrote:
> Nearly 3 months ago there was a mass bug filing on packages with dead
> alioth lists as maintainer. Many of these bugs are still open with no
> maintainer response
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Alis
Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-make-generator-function
Version : 1.1.0
Upstream Author : Jordan Harband
* URL : https://github.com/ljharb/make-generator-function
* License
Package: wnpp
I'm orphaning libtool.
It currently has 1 RC bug, and the last NMU at least seems to
cause a regression.
Kurt
Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-has-object-spread
Version : 1.0.0
Upstream Author : Renée Kooi
* URL : https://github.com/goto-bus-stop/has-object-spread
* License : Apach
On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote:
> 2018-07-30 22:36 Adrian Bunk:
>>
>> And the next burden will be if riscv64 gets added in bullseye.
>
> [*] Unlike other arches, this one is not restricted to a single vendor
>so hardware can be annouced at any time from une
Package: wnpp
Severity: wishlist
Owner: Ximin Luo
* Package name: lizzie
Version : 0.5
Upstream Author : featurecat
* URL : https://github.com/featurecat/lizzie
* License : GPL-3
Programming Lang: Java
Description : GUI for analyzing games in real time
peter green wrote...
> Nearly 3 months ago there was a mass bug filing on packages with dead
> alioth lists as maintainer. Many of these bugs are still open with no
> maintainer response
Yeah, but also a lot of people have already reacted. I got a lot of
e-mails sent to -close lately ...
> (note
Dear Tobias,
> [1] https://pad.riseup.net/p/debian-salvaging-packages-keep
Thanks for moving forward with your proposal. I'll have a poke at the
Etherpad in the upcoming days or so.
Whilst you outline a plan of sorts, do you have any rough timetable
in your head that you would like to share? Tha
22 matches
Mail list logo
