Re: new kubernetes packaging

❦ 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 > binaries, and makes extensive

Re: new kubernetes packaging

❦ 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 > binaries, and makes extensive

Re: new kubernetes packaging

Another question for the current kubernetes maintainer. What's your plan for the k8s.io/* libraries, eg k8s.io/api k8s.io/client-go. They are supposed to be built from src:kubernetes, but it currently doesn't. Some existing packages already embed them, like https://codesearch.debian.net/search?q=

Re: What to do when DD considers policy to be optional? [kubernetes]

On Wednesday, 25 March 2020 2:34:03 PM AEDT Michael Lustfield wrote: > With regard to the kubernetes package, I don't see anything to indicate it > was abandoned. Sorry if I did not make it clear: the package was orphaned as per #886739. The takeover was only technological. I don't dispute the own

Re: What to do when DD considers policy to be optional? [kubernetes]

Ehm... perhaps we should practice some de-escalation techniques, please. :/ On Wed, 25 Mar 2020 13:55:50 +1100 Dmitry Smirnov wrote: > On Wednesday, 25 March 2020 6:08:23 AM AEDT Janos LENART wrote: > > Debian Policy, paragraph 4.13 states: > > There are several problems with how you did it to

Regarding vendor/ libraries... [Was: Re: What to do when DD considers policy to be optional? [kubernetes]]

On Tue, 24 Mar 2020 19:25:49 -0700 Russ Allbery wrote: > 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.

Re: What to do when DD considers policy to be optional? [kubernetes]

On 2020-03-24 19:08 +, Janos LENART wrote: > Hi Dimitry, FTP masters and others, > 4. TESTING. The Kubernetes releases are meticulously tested, with far greater > technical resources that Debian can collectively muster. On how many architectures? Debian's support of multiple architectures ofte

Re: What to do when DD considers policy to be optional? [kubernetes]

On Wednesday, 25 March 2020 6:08:23 AM AEDT Janos LENART wrote: > I know Dimitry was fighting an uphill battle with kubernetes between 2016 > and 2018 and he experienced first hand the problems posed by vendored code. No. This is a incorrect. Largest chunk of work that I did on Kubernetes was in

Re: What to do when DD considers policy to be optional? [kubernetes]

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 essentially ~200 package review

Re: What to do when DD considers policy to be optional? [kubernetes]

On Wed, 25 Mar 2020 02:07:13 +0100 Marco d'Itri wrote: > On Mar 24, Russ Allbery wrote: > [...] > The main reason for mostly forbidding vendored libraries has been that > the security team rightly argues that in the event of a security issue > it would be too much work to 1) hunt each package u

Re: What to do when DD considers policy to be optional? [kubernetes]

On Mar 24, Russ Allbery wrote: > (The Rust team is trying the package everything approach with some success > but is uncovering other limitations in our processes and tools.) But "Some" success indeed. My personal experience with trying to package routinator has been awful, and there is still n

Re: email backend for fedmsg

On Wed, 25 Mar 2020 at 01:00, clime wrote: > > On Tue, 24 Mar 2020 at 22:45, Nicolas Dandrimont wrote: > > > > On Tue, Mar 24, 2020, at 21:51, clime wrote: > > > On Tue, 24 Mar 2020 at 20:40, Nicolas Dandrimont wrote: > > > > > > > > Hi! > > > > > > > > On Sun, Mar 22, 2020, at 13:06, clime wrot

Re: email backend for fedmsg

On Tue, 24 Mar 2020 at 22:45, Nicolas Dandrimont wrote: > > On Tue, Mar 24, 2020, at 21:51, clime wrote: > > On Tue, 24 Mar 2020 at 20:40, Nicolas Dandrimont wrote: > > > > > > Hi! > > > > > > On Sun, Mar 22, 2020, at 13:06, clime wrote: > > > > Hello! > > > > > > > > Ad. https://lists.debian.org

Re: new kubernetes packaging

Simon McVittie writes: > I think the API stability of the libraries is also relevant (and ABI > would be relevant too, if we had dynamically-linked Go libraries), both > in terms of intended API/ABI breaks and unintended behaviour changes and > regressions. The more stable they are, the more appe

Re: new kubernetes packaging

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 "always use vendored dependencies". Many of our pac

Re: new kubernetes packaging

Hello, On Tue 24 Mar 2020 at 03:14PM -07, Russ Allbery wrote: > What you say is true if the library is used by multiple applications in > Debian (although it's still not as good of a story with Go as it is for > C). We can backport a patch to that one library, and then rebuild the > applications

Re: new kubernetes packaging

Sean Whitton writes: > Thank you for your e-mail. I agree with you that security support is > the most pressing reason to avoid piles of vendored code, and you make > an interesting argument regarding how it can be difficult to provide > security fixes if our refusal to use vendored code means w

Re: new kubernetes packaging

Hello Janos, Thank you for your e-mail. I agree with you that security support is the most pressing reason to avoid piles of vendored code, and you make an interesting argument regarding how it can be difficult to provide security fixes if our refusal to use vendored code means we lag too far beh

Re: What to do when DD considers policy to be optional? [kubernetes]

Jeremy Stanley writes: > 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 vision and values so that they >

Re: email backend for fedmsg

On Tue, Mar 24, 2020, at 21:51, clime wrote: > On Tue, 24 Mar 2020 at 20:40, Nicolas Dandrimont wrote: > > > > Hi! > > > > On Sun, Mar 22, 2020, at 13:06, clime wrote: > > > Hello! > > > > > > Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html - > > > fedmsg usage in Debian. > > > > >

Re: email backend for fedmsg

Hi Clime, On 24-03-2020 21:51, clime wrote: > So do you have the opposite? I do some clicking action somewhere and > it will send an email to a certain mailing list to inform human > beings? Or let's not just clicking but e.g. `git push` (something that > you can still do from command line). > >

Re: email backend for fedmsg

On Tue, 24 Mar 2020 at 20:40, Nicolas Dandrimont wrote: > > Hi! > > On Sun, Mar 22, 2020, at 13:06, clime wrote: > > Hello! > > > > Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html - > > fedmsg usage in Debian. > > > > There is a note: "it seems that people actually like parsing ema

Re: What to do when DD considers policy to be optional? [kubernetes]

On 2020-03-24 19:08:23 + (+), Janos LENART wrote: > I know Dimitry was fighting an uphill battle with kubernetes > between 2016 and 2018 and he experienced first hand the problems > posed by vendored code. > > We see more and more software making excessive use of vendored > code. Pretty mu

Re: email backend for fedmsg

Hi! On Sun, Mar 22, 2020, at 13:06, clime wrote: > Hello! > > Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html - > fedmsg usage in Debian. > > There is a note: "it seems that people actually like parsing emails" This was just a way to say that fedmsg never got much of a user base

Re: What to do when DD considers policy to be optional? [kubernetes]

Hi Dimitry, FTP masters and others, I know Dimitry was fighting an uphill battle with kubernetes between 2016 and 2018 and he experienced first hand the problems posed by vendored code. We see more and more software making excessive use of vendored code. Pretty much everything that is written in

Re: What to do when DD considers policy to be optional? [kubernetes]

* Paul Wise: > On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote: > >> Kubernetes is already using Go modules. They happen to have decided to >> keep shipping a `vendor/` directory but this is not uncommon. It is >> often considered as a protection against disappearing modules. So, there >> is

Re: email backend for fedmsg

MQTT is the best thing going for interop purposes. On Tue, Mar 24, 2020 at 1:20 PM Jeremy Stanley wrote: > On 2020-03-24 13:09:35 -0400 (-0400), Peter Silva wrote: > [...] > > We could talk about the merits of various protocols (I see fedmsg > > uses ZeroMQ) but that is a deep rabbit hole... to

Re: email backend for fedmsg

On 2020-03-24 13:09:35 -0400 (-0400), Peter Silva wrote: [...] > We could talk about the merits of various protocols (I see fedmsg > uses ZeroMQ) but that is a deep rabbit hole... to me, fedmsg looks > like it is making a ZeroMQ version of a broker (which is a bit > ironic given the original point

Re: email backend for fedmsg

hi, totally different take on this... We could talk about the merits of various protocols (I see fedmsg uses ZeroMQ) but that is a deep rabbit hole... to me, fedmsg looks like it is making a ZeroMQ version of a broker (which is a bit ironic given the original point of that protocol) trying to buil

Re: What to do when DD considers policy to be optional? [kubernetes]

Hello, On Tue 24 Mar 2020 at 05:37AM -05, Michael Lustfield wrote: > The 'go vendor' approach is especially bad within the Debian context because > it > will download any/all modules that are referenced. In some cases, 'go get > [..]' > can go from downloading a single repository to downloading

Re: What to do when DD considers policy to be optional? [kubernetes]

❦ 24 mars 2020 14:18 +01, Julien Puydt: >> There are other reasons, notably that you speed up builds by having >> all the source code ready. > > Sorry, I don't know much about how go works, but : can't the developer > just have the deps ready -- and just not commit them to the repo and > not ship

Re: What to do when DD considers policy to be optional? [kubernetes]

Le mardi 24 mars 2020 à 14:03 +0100, Vincent Bernat a écrit : > > There are other reasons, notably that you speed up builds by having > all > the source code ready. Sorry, I don't know much about how go works, but : can't the developer just have the deps ready -- and just not commit them to the

Re: What to do when DD considers policy to be optional? [kubernetes]

❦ 24 mars 2020 05:37 -05, Michael Lustfield: >> > Kubernetes is already using Go modules. They happen to have decided to >> > keep shipping a `vendor/` directory but this is not uncommon. It is >> > often considered as a protection against disappearing modules. So, there >> > is nothing to be don

Re: What to do when DD considers policy to be optional? [kubernetes]

❦ 24 mars 2020 10:14 +00, Paul Wise: >> Kubernetes is already using Go modules. They happen to have decided to >> keep shipping a `vendor/` directory but this is not uncommon. It is >> often considered as a protection against disappearing modules. So, there >> is nothing to be done upstream. And

Bug#954847: ITP: setzer -- Simple yet full-featured LaTeX editor

Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: setzer Version : >0.2.1 Upstream Author : cvfosa URL : https://github.com/cvfosa/Setzer License : GPL3+ Programming Lang: Python with Gtk Descri

Bug#954844: ITP: mangohud -- An overlay for monitoring FPS, temperatures, and more

Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: mangohud Version : >0.3.1 Upstream Author : flightlessmango URL : https://github.com/flightlessmango/MangoHud License : MIT Programming Lang: C, C

Bug#954841: ITP: wev -- tool for debugging events on a Wayland window

Package: wnpp Severity: wishlist Owner: Birger Schacht * Package name: wev Version : 1.0.0 Upstream Author : Drew DeVault * URL : https://git.sr.ht/~sircmpwn/wev * License : MIT Programming Lang: C Description : tool for debugging events on a Wayland wi

Re: What to do when DD considers policy to be optional? [kubernetes]

On Tue, 24 Mar 2020 10:14:08 + Paul Wise wrote: > On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote: > > > Kubernetes is already using Go modules. They happen to have decided to > > keep shipping a `vendor/` directory but this is not uncommon. It is > > often considered as a protection ag

Re: What to do when DD considers policy to be optional? [kubernetes]

On Mon, 23 Mar 2020 18:47:18 -0700 Sean Whitton wrote: > Hello Dmitry, Janos, others, > > On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote: > > > What would be best to do in such situation? > > [...] > > I think that I would start by filing an RC bug. +1 If you run into issues, then

Re: What to do when DD considers policy to be optional? [kubernetes]

On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote: > Kubernetes is already using Go modules. They happen to have decided to > keep shipping a `vendor/` directory but this is not uncommon. It is > often considered as a protection against disappearing modules. So, there > is nothing to be done up

Re: What to do when DD considers policy to be optional? [kubernetes]

On Mon, Mar 23, 2020 at 05:32:54PM +1100, Dmitry Smirnov wrote: > Something interesting just happened. An inexperienced DD adopted a very > complicated package (kubernetes) and uploaded it with changes that would have > never been accepted by ftp-masters. file bugs then. maybe that new maintaine