Re: Git Branch Names / DEP-14

[Simon McVittie]

On Tue, 05 Nov 2019 at 20:40:43 -0800, Russ Allbery wrote:
> My normal use of experimental does not involve maintaining unstable and
> experimental branches simultaneously.
...
> I know some people do more of a two-branch setup

One common reason to need to use experimental more actively is if your
upstream has a relatively long-running "latest feature development"
branch that is explicitly not suitable to be in a stable release, such
as dbus 1.odd.z, GNOME 3.odd.z, and Linux/Xorg/Mesa release candidates.

dbus and GNOME both use the versioning scheme popularized by pre-2.6
Linux kernels, where version x.even.z is considered stable and will
receive security fixes, but version x.odd.z is not security-supported,
and is only suitable for use in contexts where you can guarantee to
replace it with the next stable branch as soon as it becomes available.

smcv

Re: Git Packaging Round 2: When to Salsa

[Simon McVittie]

On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> It does, it's specifically mentioned as a branch that will be
> rewinded. See the “Branch management for next and pu after a feature
> release” section.

gitworkflows(7) describes how git.git works, as an example of the workflow
of a particular project, rather than mandating particular workflows for
all projects:

This document attempts to write down and motivate some of the workflow
elements used for git.git itself. Many ideas apply in general

In git.git, next and pu are branches themselves, not prefixes for families
of branches. This means that branches called next/foo and pu/bar cannot
exist in git.git. The workflows and naming used to develop git, dpkg and
(for example) GNOME are all entirely valid, but they aren't the same.

(git's workflow also uses a single maint branch for updates to the latest
stable version, which is fine if you only ever support one stable version
at a time - presumably that's the case for git? - but doesn't work as-is
if you want to support two stable branches at the same time, like Debian
buster and stretch at the moment.)

gitworkflows(7) also mentions branches of the form ai/*. I'm not sure
what "ai" means. From context, these seem to be topic branches used to
integrate new features into next, and seem to be non-rebasing but it
isn't entirely clear to me?

smcv

Re: Integration with systemd

[Simon McVittie]

On Fri, 01 Nov 2019 at 14:16:37 +0100, Ansgar wrote:
> Possibly also tmpfiles, but without an init system nothing would start
> the service and it would have to be invoked manually.  Maintainer
> scripts might use it though to setup directories in /var/lib or similar
> locations.

Yes, that's roughly what I had in mind.

Some container managers (I'm thinking particularly of Docker and
bubblewrap here) already include a minimal process-reaper to act as pid
1 in the container, which is one side of what init traditionally does;
it wouldn't seem like a huge leap for container managers to have some
relatively minimal startup management (either running "hook" scripts
during container setup, or implementing things like the tmpfiles.d spec
themselves) to provide the other side of what init does.

Arguably, things like Docker already have the most minimal possible
service management: it runs the container's entry-point command, whether
that's a web server, an interactive shell or even a full init system,
then cleans up the rest of the container after that entry point exits.

smcv

Re: Summary: Git Packaging Round 2

[Sam Hartman]

TL;DR: I'd feel a lot more comfortable if a couple of people would
explicitly review wether I correctly captured the discussion in the
summary.

So, we've received a number of comments on aspects of the discussion.
That plus the original discussion leads me to believe we really are
interested in this issue and that there's community interest in moving
forward.

But many of the comments have explicitly said they didn't follow the
discussion.  The summaries are half the check that the facilitator is
doing a good job in a consensus discussion.  The other half is having
some people involved sanity check the summary.

It would really help me have the confidence to move forward if a couple
of people did that:

* If you were involved enough that you can read the summary and say
  "Yeah, that's more or less what happened," please please do that. (If
  you think I got something wrong in the summary, then please say that too)

* If you're willing to read the summary and compare against the actual
  discussion, I'd greatly appreciate that, especially if we cannot get
  people involved to confirm from their memory.  If you do that, I
  recommend using a threaded mail reader  and being prepared to skip
  reading subthreads that get too repetative or off-topic.  When I did
  my re-read to prepare the summary, I trimmed out most of the
  discussion of non-free services from my re-read.  With that trimmed,
  it took me an hour and a half to take notes on the entire discussion.
  I do understand that's a significant time investment to ask others to
  make.

* If you aren't able to spend that time or have personal recollections,
  but think the level of review I and others have already done is
  adequate, please say that.

Thanks,

--Sam

Re: Summary: Git Packaging Round 2

[Sean Whitton]

Hello,

On Wed 06 Nov 2019 at 11:10AM -05, Sam Hartman wrote:

> * If you were involved enough that you can read the summary and say
>   "Yeah, that's more or less what happened," please please do that. (If
>   you think I got something wrong in the summary, then please say that too)

I read almost all the mail from the discussion and when I read your
summary I did not think that anything was incorrect.  HTH!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944261: ITB: python-seaborn -- Python data visualization library

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-scie...@lists.debian.org

* Package name: python-seaborn
  Version : 0.9.0
  Upstream Author : Michael Waskom 
* URL : https://seaborn.pydata.org
* License : BSD-3-clause
  Programming Lang: Python3
  Description : Python data visualization library

Seaborn is a Python data visualization library based on matplotlib. It
provides a high-level interface for drawing attractive and informative
statistical graphics.

This will be maintained within the Debian Science Team.

Re: Secureboot: how to use MOK

[Ansgar]

Steve Langasek writes:
> On Sun, Oct 27, 2019 at 10:45:49AM +0100, Florian Weimer wrote:
>> * Thomas Goirand:
>> I don't think secure boot provides any benefit at all if you store the
>> kernel module signing key on the same machine.
>
> Generate the MOK certificate with EKU 1.3.6.1.4.1.2312.16.1.2.  This
> indicates that the key should only be trusted for kernel modules, not for
> kernels or other EFI applications (bootloaders etc).  The value is honored
> by shim, grub (via shim), and the kernel (but not by the firmware - but the
> firmware itself doesn't trust the MOK anyway, so this doesn't matter).
>
> This does not eliminate all attacks that involve getting access to the
> private key on the machine; but it does prevent the presence of MOK + DKMS
> being used to attack the firmware.

I thought the Linux kernel did not call `ExitBootServices()` and this is
the reason we have to require all modules to be signed by default.  (Or
even if it did, this applies to all modules loaded before.)  So the
Linux kernel should be able to chainload anything, just like shim.

So why does this prevent attacks on the firmware?  It shouldn't matter
if you can sign the kernel or any module run in the same context as the
kernel.

Ansgar

Re: Git Branch Names / DEP-14

[Ansgar]

Simon McVittie writes:
> On Tue, 05 Nov 2019 at 20:40:43 -0800, Russ Allbery wrote:
>> My normal use of experimental does not involve maintaining unstable and
>> experimental branches simultaneously.
> ...
>> I know some people do more of a two-branch setup
>
> One common reason to need to use experimental more actively is if your
> upstream has a relatively long-running "latest feature development"
> branch that is explicitly not suitable to be in a stable release, such
> as dbus 1.odd.z, GNOME 3.odd.z, and Linux/Xorg/Mesa release candidates.

In such cases it might be even more appropriate to have branches like
"debian/1.odd" if they better represent the actual history, in
particular if the "debian/1.odd+2" is not a descendant of
"debian/1.odd", but an independent branch.

(One can otherwise force the new branch to be a descendant by "fake"
merges, but that is not a good idea for various reasons: it creates an
incorrect history and confuses tools that now think commits were
applies when they really were not.)

Ansgar

Re: [confirmation] Summary: Git Packaging Round 2 [plus weak vs strong team ownership question/proposal]

[Nicholas D Steeves]

Hi,

I confirm the summary seems fair and reasonable with one
question/proposal (see below in line).

Sam Hartman  writes:

> * Exploring what current social conventions are around pushing to other
>   people's repositories in the debian group on salsa and documenting
>   them.  This is more about documenting what people do than about
>   documenting what permissions people have.
>
[snip]
> If you are a Debian Developer packaging a package for inclusion in
> Debian, you should store your packaging information in one repository
> per package on salsa.debian.org in the debian group.  That is you should
> create a repository under https://salsa.debian.org/debian .
>
[snip]
> If you are not a Debian Developer, you cannot directly create a
> repository in the debian group.  If you're willing to wait for a Debian
> Developer to create a repository for you and grant you access, do that.
> If that wait would be long enough to frustrate you or demotivate you,
> you should create a repository in a your personal namespace on
> salsa.debian.org and store your package there.
>

Thank you for /\ the above /\ point for non-DDs.

> By creating a repository in the debian group, you grant access to all
> developers.  That way people performing NMUs can directly commit their
> changes.  It will also make it easier if you later orphan the package to
> preserve version control history, URIs and merge request history.
>

I think it might be worth adopting the weak vs strong team ownership
convention that the Debian Python Team uses, namely

* Team in Maintainers is a strong statement that fully collaborative
  maintenance is preferred. Anyone can commit to the vcs and upload
  as needed. A courtesy email to Uploaders can be nice but not
  required.

* Team in Uploaders is a weak statement of collaboration. Help in
  maintaining the package is appreciated, commits to vcs are freely
  welcomed, but before uploading, please contact the Maintainer for
  the green light.


https://debian-python.readthedocs.io/en/latest/dpmt-policy.html#maintainership

Would this address the concerns of everyone=no_one's responsbility in
the Debian salsa group (old collab-maint)?  If so, the question becomes
which email address to use for the Debian/collab-maint group :-)


Sincerely,
Nicholas


signature.asc
Description: PGP signature

Usage of DEP5

[Andreas Tille]

Hi,

in a change to UpstreamMetadata in Wiki[1] Thorsten Glaser wrote:

   These fields must still be allowed, as not all packagers wish to use DEP 5.

I admit I'm astonished about this.  From my point of view DEP5 was
decided to be good packaging practice and I assumed that not changing to
DEP5 would be a matter of "not important for me to spent my time on a
DEP5 conversion".  However, I'm reading Thorstens statement as an
explicit wish to not use DEP5.  I wonder what other reasons might exist
to explicitly stick to the non-machine readable format.

I would love to see another discussion here to reach more uniformity in
Debian packaging and rise importance of DEP5 by recommending it in
Debian Policy.

Kind regards

  Andreas.

[1] https://wiki.debian.org/UpstreamMetadata?action=diff&rev1=134&rev2=135

-- 
http://fam-tille.de

Re: Usage of DEP5

[Scott Kitterman]

On Thursday, November 7, 2019 1:26:42 AM EST Andreas Tille wrote:
> Hi,
> 
> in a change to UpstreamMetadata in Wiki[1] Thorsten Glaser wrote:
> 
>These fields must still be allowed, as not all packagers wish to use DEP
> 5.
> 
> I admit I'm astonished about this.  From my point of view DEP5 was
> decided to be good packaging practice and I assumed that not changing to
> DEP5 would be a matter of "not important for me to spent my time on a
> DEP5 conversion".  However, I'm reading Thorstens statement as an
> explicit wish to not use DEP5.  I wonder what other reasons might exist
> to explicitly stick to the non-machine readable format.
> 
> I would love to see another discussion here to reach more uniformity in
> Debian packaging and rise importance of DEP5 by recommending it in
> Debian Policy.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://wiki.debian.org/UpstreamMetadata?action=diff&rev1=134&rev2=135

Although I use it for simple packages, for complex ones I think it makes 
debian/copyright maintenance much harder (many more things to get wrong).  
It's totally optional and should absolutely stay that way.  

The purpose of debian/copyright is to support license compliance.  Anything 
beyond that isn't relevant to its purpose within Debian.  While I recognize 
that the structured format has benefits for some people, I don't think it 
matters much within the project.

Let's stick to making rules we actually need.

Scott K


signature.asc
Description: This is a digitally signed message part.

Re: Usage of DEP5

[Russ Allbery]

Andreas Tille  writes:

> I admit I'm astonished about this.  From my point of view DEP5 was
> decided to be good packaging practice and I assumed that not changing to
> DEP5 would be a matter of "not important for me to spent my time on a
> DEP5 conversion".  However, I'm reading Thorstens statement as an
> explicit wish to not use DEP5.  I wonder what other reasons might exist
> to explicitly stick to the non-machine readable format.

There are some types of debian/copyright files that are kind of annoying
to express in the machine-readable format, mostly because the copyright
state requires some discussion or is easier to express as free-form text.
I think most of those cases have reasonable solutions with some work, but
it's quite a bit more work than adding an upstream metadata file.

This seems like a fairly marginal case, and I don't have a strong opinion
about the wiki comment, but we've talked about making machine-readable
copyright more strongly encouraged from time to time and there are always
objections from folks who are still not convinced it solves any problems
for them and who find it harder to work with for whatever reason.

-- 
Russ Allbery (r...@debian.org)  

Re: Usage of DEP5

[Ole Streicher]

Andreas Tille  writes:
> I would love to see another discussion here to reach more uniformity in
> Debian packaging and rise importance of DEP5 by recommending it in
> Debian Policy.

I would really support that. A recommendation does not mean that there
may be some exceptional cases where DEP5 is not applicable, although I
think that DEP5 is flexible enough to cope with almost all cases.

It is always an advantage to follow standardized procedures as they make
the communication between us simpler and allow for standardized tools to
process them, inclusion in the UDD etc.

@Andreas: Independently of how this goes for the Debian Policy,
recommending DEP5 would be a good thing for the policies of Debian
Science and friends (astro, med). This could even allow to display the
(source) license(s) on the blends web pages.

Best regards

Ole