Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-20 Thread Felix Lechner

Sorry to comment so late. A meeting about this bug may already be in progress.

On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon  wrote:
> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in private.

In most places, a failure to respond would result in a default
judgment for the aggrieved party—in this case Matthew.

Here, the situation here is more complicated. There was a private
communication with the committee, but such side conversations are
unfair: How can Matthew ever feel that justice was served? I would
personally not feel closure unless I saw all such communications and
had an opportunity to respond.

Secrecy, if it is really needed, should instead be implemented by
requiring all parties involved to keep sealed records confidential.

I urge the committee to please reconsider its willingness to engage
with one party without the other present. The dignity of the Technical
Committee—Debian's highest and most hallowed body—could suffer.

Thank you!

Kind regards
Felix Lechner

Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))

2021-01-20 Thread Debian Bug Tracking System
Your message dated Wed, 20 Jan 2021 12:28:46 -0700
with message-id <87mtx35rwx@melete.silentflame.com>
and subject line CTTE decision on "kubernetes: excessive vendoring (private 
has caused the Debian Bug report #971515,
regarding kubernetes: excessive vendoring (private libraries)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org

971515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
X-Debbugs-CC: o...@debian.org
Control: block 970717 by -1

Dear Technical Committee,

Apologies that we were not able to resolve the problem without your help.

I seek your judgement regarding excessive, unnecessary and unjustifiable
vendoring of private libraries in Kubernetes package:


Some relevant argumentation can be found in


In short, myself and Golang packaging team spent years on stabilising
Golang ecosystem of packaged libraries for re-use by Golang software.

To the best of my knowledge, all packaged Golang software, regardless of its 
sophistication, use some packages libraries.
Except Kubernetes, that disconnected itself from cooperation by not using any 
packaged libraries, instead exclusively using only private libraries in 
numbers greater than any Debian package ever used.

As a former Kubernetes maintainer and a developer who originally introduced
Kubernetes to Debian, I know that it could be maintained with only few (or 
several) private libraries at most.

Current state of Kubernetes package is in violation of ftp-master's policy 
for inclusion of new packages to Debian.

Thank you.

This matter is not urgent.

 Dmitry Smirnov


We do our friends no favors by pretending not to notice flaws in their
work, especially when those who are not their friends are bound to notice
these same flaws.
-- Sam Harris

Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---

The Committee declines to overrule the maintainer and accepts the level
of vendoring used in the 'kubernetes' source package.  We also decline
to intervene in bugs requesting that vendored components in the
'kubernetes' source package be installed in binary packages in such a
way that other packages can make use of them.

Our consensus is that Kubernetes ought to be considered special in the
same way that Firefox is considered special -- we treat the package
differently from most other source packages because (i) it is very large
and complex, and (ii) upstream has significantly more resources to keep
all those moving parts up-to-date than Debian does.

In the case of Kubernetes, what this means is that instead of breaking
the package down into separate libraries connected together with dpkg
dependency relationships, as is usual, we take updates of the whole set
of sources directly from upstream and make a single upload to our

Our most basic reason for this point of view is that given how much
fewer resources we have than upstream Kubernetes, it is not feasible for
Kubernetes to make it into a stable release of Debian unless we take an
approach like this one.  The same goes for the possibility of providing
security support.  And given that a strategy for security support is
available, we do not see any reason why having the Kubernetes bundle in
a stable release alongside other copies of its vendored dependencies is
worse than not having Kubernetes in a stable release at all.

It should be noted that we think the greater resources of upstream is
relevant not only to keeping on top of patches and security fixes, but
also to license compliance.  It is our belief that there is no reason at
the present time to be concerned that non-DFSG material would find its
way into the package, because Kubernetes upstream care about ensuring
that all vendored dependencies are free software, and they have the
resources to check.  This could change in the future and it may not be
true for other upstreams.

Sean Whitton

Description: PGP signature
--- End Message ---

Next Meeting - January 20th at 18:00 UTC (in 2 hours)

2021-01-20 Thread Margarita Manterola

Dear Technical Committee members,

Our monthly meeting is scheduled to take place today, January 20th at 
18:00 UTC.

We currently have a five open bugs, we really need to make some progress 
on closing a few of those.

Topics for our agenda are:

* Review of previous meeting AIs
* #971515 - kubernetes: excessive vendoring (private libraries)
* #975075 - Should NetworkManager support elogind?
* #975381 - libinih: drop Debian's custom vendorisation
* #976462 - Should dbgsym files be compressed via objcopy 
--compress-debug-section or not?

* #978636 - move to merged-usr-only?
* Recruitment efforts

Notes from the previous monthly meeting here: 

And from our extra December meeting: