On Thursday, 26 March 2020 3:45:21 AM AEDT Marc Haber wrote:
> Software packages like kubernetes, docker, and many of the other "hip
> tools of the day" are moving way too fast for our release scheme.
It is worth remembering that Debian is not only a stable release.
Statically built Golang apps ar
On Thursday, 26 March 2020 7:38:12 AM AEDT Bernd Zeimetz wrote:
> ... you would know that it is only tested with the
> exact versions of the libraries as it was released with.
>
> Choosing different versions is prone to introduce subtle bugs and should
> never be done and accepted if that k8s vers
Most Sarrracenia stuff is tied to AMQP, but next-gen messages are called
v03 (version 3) they use a JSON payload
for all the information, and that makes it somewhat protocol independent.
There is also a 500 line MQTT demo
that implements a file replication network, using the same JSON messages,
and
I was looking into the email approach more and maybe I found a few
improvements:
- each communicating agent has an exim instance
- there are a few dns servers that replicate their configuration between
each other (to provide redundancy)
- these servers store subscriptions of the agents for each to
>
>
> I work in telecom for meteorology, and we ended up with a general method
> for file copying (catchphrase: rsync on steroids*.) ( *every catchphrase is
> a distortion, no dis to rsync, but in certain cases we do work much faster,
> it just communicates the idea.) Sarracenia (
> https://github
Russ Allbery schrieb:
> Michael Lustfield writes:
>
>> One last thing to consider... NEW reviews are already an intense
>> process. If this package hit NEW /and/ we allowed vendored libs, you
>> could safely expect me to never complete that particular review. I doubt
>> I'm the only one; that's e
Sean Whitton wrote:
> I am not sure, however, that your argument applies to security updates
> to our stable releases. These updates are almost always a matter of
> backporting small fixes, rather than updating to new upstream releases.
> And for backported fixes, vendoring makes things much hard
Hi,
> As a person who originally introduced Kubernetes to Debian I can say that it
> is indeed a lot of work to maintain this package and to reuse packaged
> libraries. But I've demonstrated that it is possible at least to some extent.
if you've maintained k8s you would know that it is only tes
Hello Simon,
Not speaking for the whole FTP Team in this mail, but maybe I can help a
bit.
On Wed 25 Mar 2020 at 05:47PM +00, Simon McVittie wrote:
> On Wed, 25 Mar 2020 at 09:04:52 -0700, Sean Whitton wrote:
>> On Wed 25 Mar 2020 at 08:58PM +05, Andrey Rahmatullin wrote:
>> > On Wed, Mar 25, 20
Quoting Keith Packard (2020-03-25 19:07:33)
> Simon McVittie writes:
>
> > One thing that the ftp team clarified somewhat recently is that in
> > most cases, we must track all the copyright notices that exist in
> > the upstream source, and copy them into d/copyright.
>
> As an example, I've g
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libcompiler-lexer-perl
Version : 0.23
Upstream Author : Masaaki Goshima (goccy)
* URL : https://metacpan.org/release/Comp
Simon McVittie writes:
> One thing that the ftp team clarified somewhat recently is that in
> most cases, we must track all the copyright notices that exist in the
> upstream source, and copy them into d/copyright.
As an example, I've got a package in the new queue with a 5077 line
copyright fil
On Wed, 25 Mar 2020 at 09:04:52 -0700, Sean Whitton wrote:
> On Wed 25 Mar 2020 at 08:58PM +05, Andrey Rahmatullin wrote:
> > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote:
> >> maintainers are incentivized
> >> to dot every i and cross every t in the copyright file even if it isn'
❦ 25 mars 2020 15:57 +01, Jonas Smedegaard:
>> rpm packages record the package license information in a one-line License:
>> field.
>
> Is your point that 9 lines can be reduced to one, or that 100 lines can
> be reduced to one?
>
> It is legal in Debian to write debian/copyright files looking l
On Tue, 24 Mar 2020 20:37:16 +, Jeremy Stanley
wrote:
>If this represents the actual state of building Kubernetes, it's
>unclear to me why Debian would package it at all. I don't see the
>value to users in consuming Kubernetes from a Debian package if the
>result is compromising on Debian's vi
Hello,
On Wed 25 Mar 2020 at 08:58PM +05, Andrey Rahmatullin wrote:
> On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote:
>> I think part of the problem might be this vicious cycle: the NEW queue
>> is an asynchronous gatekeeper/progress blocker, which gives maintainers
>> a strong in
On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote:
> I think part of the problem might be this vicious cycle: the NEW queue
> is an asynchronous gatekeeper/progress blocker, which gives maintainers
> a strong incentive to get things accepted first time (because a NEW
> rejection will d
Hello,
On Wed 25 Mar 2020 at 03:43PM +00, Simon McVittie wrote:
> I think part of the problem might be this vicious cycle: the NEW queue
> is an asynchronous gatekeeper/progress blocker, which gives maintainers
> a strong incentive to get things accepted first time (because a NEW
> rejection will
Le mardi 24 mars 2020 à 19:08:23+, Janos LENART a écrit :
> [snip]
> I do think there is a good case for Kubernetes to be an exception from 4.13
> for
> now, just like other Go packages effectively are.
Using other examples to say "people do bas stuff elsewhere so I'm
entitled to do the same"
On Wed, 25 Mar 2020 at 15:32:20 +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > Or you can look at the Redhat approach as a minimal working one.
> > You know it can be done much easier and still work: in Redhat.
>
> (in case it hasn't already been discussed in this
* Andrey Rahmatullin:
> Or you can look at the Redhat approach as a minimal working one.
> You know it can be done much easier and still work: in Redhat.
I think you are referring to a Fedora process, not a Red Hat process.
The Red Hat process does not seem much simpler than what ftpmaster are
do
On 25.03.20 15:14, Tomas Pospisek wrote:
> I can be sure that if stuff lands in Debian then I won't get screwed
> by weird, dirty, missleading, underhanded licensing rules, which
> seems to be the standard outside the Open Source world and even on
> its fringes.
The only thing you can be sure about
On Wed, Mar 25, 2020 at 03:57:29PM +0100, Jonas Smedegaard wrote:
> > > >> I'd contest this. Whenever Open Source standards come up in a
> > > >> discussion, Debian is always the gold reference. You know it can be
> > > >> done
> > > >> right and it is: in Debian.
> > > > Or you can look at the Re
Quoting Andrey Rahmatullin (2020-03-25 15:46:10)
> On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> > On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> > >> On 25.03.20 14:43, Christian Kastner wrote:
> > >>
> > >>>
On March 25, 2020 1:43:26 PM UTC, Christian Kastner wrote:
>Russ,
>
>On 25.03.20 03:25, Russ Allbery wrote:
>> I'll repeat a point that I made earlier but put a bit of a sharper
>point
>> on it: We should thoughtfully question whether the current approach
>to
>> license review that we as a proj
On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> >> On 25.03.20 14:43, Christian Kastner wrote:
> >>
> >>> This is not to say that licensing is an unimportant issue --
On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> >> On 25.03.20 14:43, Christian Kastner wrote:
> >>
> >>> This is not to say that licensing is an unimportant issue --
On 25.03.20 15:19, Andrey Rahmatullin wrote:
> On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
>> On 25.03.20 14:43, Christian Kastner wrote:
>>
>>> This is not to say that licensing is an unimportant issue -- it clearly
>>> is. But our analyze-and-document down-to-the-file approach
On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> On 25.03.20 14:43, Christian Kastner wrote:
>
> > This is not to say that licensing is an unimportant issue -- it clearly
> > is. But our analyze-and-document down-to-the-file approach is on the
> > other extreme end of the spectrum
On 25.03.20 14:43, Christian Kastner wrote:
> This is not to say that licensing is an unimportant issue -- it clearly
> is. But our analyze-and-document down-to-the-file approach is on the
> other extreme end of the spectrum, and it causes lots of tiresome work
> that nobody apart from us seems to
Russ,
On 25.03.20 03:25, Russ Allbery wrote:
> I'll repeat a point that I made earlier but put a bit of a sharper point
> on it: We should thoughtfully question whether the current approach to
> license review that we as a project ask ftpmasters to do is a correct
> investment of project resources
On Tue, Mar 24, 2020 at 07:25:49PM -0700, Russ Allbery wrote:
> I'll repeat a point that I made earlier but put a bit of a sharper point
> on it: We should thoughtfully question whether the current approach to
> license review that we as a project ask ftpmasters to do is a correct
> investment of p
On 24/03/2020 23:05, Simon McVittie wrote:
> On Tue, 24 Mar 2020 at 15:14:02 -0700, Russ Allbery wrote:
>> I think this calculus is not entirely obvious.
> Thank you for applying some much-needed nuance to this issue. I suspect
> the ideal policy is neither "never use vendored dependencies" nor
>
On Wed, 25 Mar 2020 at 08:41:45 +0100, Florian Weimer wrote:
> De-vendoring sources might still be an advantage because applications
> can be fixed with a bin-NMU, but it's a lot of work. The resulting
> divergence from upstream can result in additional bugs. On the other
> hand, there are projec
* Vincent Bernat:
> ❦ 24 mars 2020 16:30 -07, Russ Allbery:
>
>> On the other hand (and I don't follow this community closely, so apologies
>> if I have the details wrong here), my impression is that the Go community
>> is not planning to support shared libraries, loves its staticly-linked
>> bin
35 matches
Mail list logo
