Re: Next meeting -- one week early, 5th April @ 7pm UTC

2022-03-30 Thread Elana Hashman

On 2022-03-29 14:43, Matthew Vernon wrote:



Due to both the current interpersonal situation and the impeding
DebConf22 CfP, can we have our meeting a week early?  Please let me 
know

if you can't.



* DebConf22 CfP -- what sort of talk do we want to submit?


FWIW, I'm afraid I won't be at DebConf (given the situation in
Ukraine, I don't want to be committing to travel to Kosovo this year).


Due to the pandemic, I'm still not resuming cross-Atlantic travel, so I
can only attend DebConf virtually :)

- e



Re: Next meeting -- one week early, 5th April @ 7pm UTC

2022-03-29 Thread Elana Hashman

On 2022-03-29 13:11, Sean Whitton wrote:

Hello,

On Tue 29 Mar 2022 at 01:01pm -07, Sean Whitton wrote:


Due to both the current interpersonal situation and the impeding
DebConf22 CfP, can we have our meeting a week early?  Please let me 
know

if you can't.


I think I'm the only person who is somewhere that doesn't observe DST,
so we should move it to 6pm UTC, right, going forward?


I'm fine leaving it where it is fwiw, it's less likely to hit conflicts
at this time for me.

- e



Bug#1004611: Resignation & call for votes to elect the Chair

2022-02-20 Thread Elana Hashman
On Sun, Jan 30, 2022 at 02:10:08PM -0700, Sean Whitton wrote:
> Package: tech-ctte
> 
> [resubmitting as a bug; please vote here rather than on the ML -- sorry]
> 
> Dear committee members,
> 
> As the membership of the committee has changed, according to convention
> I hereby resign as Chair, effective one week from now, and call for
> votes to elect the Chair of the Technicall Committee.  In accordance
> with the Debian Constitution, the vote runs until all members have
> voted, or until my resignation takes effect.
> 
> FAOD, I would like to continue in the role if the committee agrees.
> 
> The ballot:
> 
> ===BEGIN
> 
> A: Christoph Berg 
> B: Helmut Grohne 
> C: Elana Hashman 
> D: Simon McVittie 
> E: Niko Tyni 
> F: Matthew Vernon 
> G: Sean Whitton 
> H: Gunnar Wolf 
> 
> ===END

My apologies for failing to vote here; I didn't mean to ignore this.
It's been an interesting month for me.

For transparency, I would have voted:

G > A = D = E = H > C > B = F

Congrats Sean on your reelection :)

- e


signature.asc
Description: PGP signature


Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

2022-01-18 Thread Elana Hashman
On Fri, Jan 14, 2022 at 11:56:20AM -0700, Sean Whitton wrote:
> 
> ===BEGIN
> The Technical Committee recommends that Matthew Vernon  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Matthew Vernon 
> F: Further Discussion
> ===END

I vote:

H > F

- e


signature.asc
Description: PGP signature


Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

2022-01-18 Thread Elana Hashman
On Fri, Jan 14, 2022 at 11:55:17AM -0700, Sean Whitton wrote:
> 
> ===BEGIN
> The Technical Committee recommends that Helmut Grohne  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Helmut Grohne 
> F: Further Discussion
> ===END

I vote:

H > F

- e


signature.asc
Description: PGP signature


Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-22 Thread Elana Hashman
On Wed, Oct 13, 2021 at 08:13:08PM +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote (belatedly, for the record):

yes > FD

- e

> 
>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-22 Thread Elana Hashman
On Wed, Oct 20, 2021 at 12:30:54PM -0700, Sean Whitton wrote:
> Hello,
> 
> I hereby call for votes on the following ballot to resolve #994275.  The
> voting period starts immediately and lasts for up to one week, or until
> the outcome is no longer in doubt (Constitution 6.3.1).
> 
> === Resolution A ===
> 
> The Technical Committee resolves:
> 
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
> 
> 2. The which(1) program must not print any deprecation warnings.
> 
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
> 
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
> 
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
> 
> === Resolution B ===
> 
> As Resolution A, except strike point (2) and renumber succeeding items.
> 
> === End Resolutions ===
> 
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion


I vote:

B > A > F

- e


signature.asc
Description: PGP signature


Bug#985270: Resignation + Call for votes for new Chair

2021-03-15 Thread Elana Hashman
On Mon, Mar 15, 2021 at 10:30:59AM +0100, Margarita Manterola wrote:
> Package: tech-ctte
> 
> [Resending as a bug rather than a mailing-list email. Sorry!]

Resending to the bug instead of the mailing list... oops

> Dear TC members,
> 
> As is traditional when committee members change, I am calling for the election
> of a new Chair of Debian Technical Committee by announcing my resignation as
> chair effective one week from now. In accordance with Section 6.1.7 of the
> Debian Constitution, the vote runs until all members have voted, or until my
> resignation takes effect.
> 
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Margarita Manterola
>  B : David Bremner
>  C : Niko Tyni
>  D : Gunnar Wolf
>  E : Simon McVittie
>  F : Sean Whitton
>  G : Elana Hashman
>  H : Christoph Berg
> 
> ===END===

I vote:

B > F > C = D = E > A = G > H

- e


signature.asc
Description: PGP signature


Re: Resignation + Call for votes for new Chair

2021-03-15 Thread Elana Hashman
On Mon, Mar 15, 2021 at 10:29:29AM +0100, Margarita Manterola wrote:
> Dear TC members,
> 
> As is traditional when committee members change, I am calling for the election
> of a new Chair of Debian Technical Committee by announcing my resignation as
> chair effective one week from now. In accordance with Section 6.1.7 of the
> Debian Constitution, the vote runs until all members have voted, or until my
> resignation takes effect.
> 
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Margarita Manterola
>  B : David Bremner
>  C : Niko Tyni
>  D : Gunnar Wolf
>  E : Simon McVittie
>  F : Sean Whitton
>  G : Elana Hashman
>  H : Christoph Berg
> 
> ===END===

I vote:

B > F > C = D = E > A = G > H

- e


signature.asc
Description: PGP signature


Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-03-08 Thread Elana Hashman

On 2021-03-06 11:11, Jakub Wilk wrote:

* Elana Hashman , 2021-02-17, 11:06:
Would you be able to research some representative slice of popular 
packages that would be affected by the policy change (at least 10) and 
share the on-disk sizes with compression vs. without?


Not exactly what you asked Niels for, but...

A few months ago I recompressed whole buster/main/amd64 to see what
the effect of ditching --compress-debug-sections would be.
Raw data for this experiment is available here:
https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-20200708.tsv.xz
The columns are:
* file name
* original .deb size
* recompressed .deb size
* original installed size
* recompressed installed size

Note that some of the .deb size savings might be caused by the fix for
#868674 (for packages that haven't been rebuilt since the fix).


Hi Jakub,

This is very helpful. Using this file, I have calculated the following 
three aggregates:


1. % size between original and recompressed .deb
2. % size between original and recompressed install size
3. size difference in bytes between original and recompressed install 
size


I then performed a quartile analysis on it.

Recompressed size is X% of original .deb:

Min 3.97%
25% 65.45%
Median 74.73%
75% 82.64%
Max 105.01%

Installed size of recompressed is X% of original installed size:

Min 100.06%
25% 230.72%
Median 256.76%
75% 292.76%
Max 4267.38%

Size difference between recompressed and original installed size, is X 
bytes:


Min 20480 (20KB)
25% 89088 (90KB)
Median 404480 (404KB)
75% 2461184 (2.5MB)
Max 5728869376 (5.72GB)


So I think we can conclude the following:

- In essentially all cases, recompressed deb has a size improvement over 
the original.
- In all cases, the installed size of the debug symbols is larger, 
usually about 2-3x the original installed size.
- In all but the largest cases, that size difference is negligable. 
However, the large cases have quite an extreme difference.


Hence, I think the tail end of large packages will guide this decision, 
and Josh very helpfully provided an analysis of those already!



Because of the extreme difference for the large packages, and because 
many of those packages are relatively popular, I think I am inclined to 
maintain the status quo, i.e. with --compress-debug-section enabled by 
default. I am open to being convinced otherwise :)


Cheers,

- e



Bug#982987: tech-ctte: Call for votes for new CTTE member

2021-02-17 Thread Elana Hashman
On Wed, Feb 17, 2021 at 12:45:05PM -0600, Gunnar Wolf wrote:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I have not worked with or interacted with Christoph. Hence, I abstain
from voting.

- e


signature.asc
Description: PGP signature


Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-02-17 Thread Elana Hashman
Hi Niels,

Most of the arguments in this and previous bugs are anecdotal. It would
be helpful to provide a concrete analysis of the disk space savings that
compression provides, and whether it is a reasonable default.

There is a discussion about KDE debug symbols requiring 10Gi of disk
space a decade ago, but not what the original compressed size was, for
example...

Would you be able to research some representative slice of popular
packages that would be affected by the policy change (at least 10) and
share the on-disk sizes with compression vs. without?

Personally, I think if there is not much difference in size, it would
make sense to not compress as the default. If there are orders of
magnitude in difference, the status quo probably still makes sense, as
it does provide benefits.


Matthias,

You and the original report mention "tooling issues". Can you please
provide some examples of tools that do not currently support working
with compressed symbols and the resulting effects on developer workflow?

Thanks,

- e


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-31 Thread Elana Hashman
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> Dear Technical Committee members,
> 
> I call for votes on the following ballot to resolve #978636.  The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
> 
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

I vote:

Y > F > N

- e


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-21 Thread Elana Hashman
On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:
> 
> I caution folks from speculating too much on the maintainer's
> motivations and reasoning while they haven't yet had a chance to share
> their perspective on the bug. :)
> 
> From what I can see reading through both #964139 and #960780, no
> technical rationale has been given for why the script was removed, only
> a statement that the removal was intentional.[0]
> 
> It would be much appreciated if Michael Biebl or another maintainer from
> the Utopia team could add some context here.
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62

The maintainer, Michael Biebl, reached out to the tech-ctte privately. I
have summarized his reasoning for why he dropped support for elogind and
the init script that prompted this bug:


Less than 1% of users are installing sysvinit-core, with a steady
downward trend.[1]

If we require packages to maintain sysvinit support, then this cements
sysvinit/sysv-rc as the least common denominator for packages and blocks
the use of many of systemd's features, such as timers. This results in
an OS that is less integrated than it could be, which hurts the vast
majority of users who do not use sysvinit.

Trying to support multiple init systems generates a lot of additional
work for maintainers, who are already stretched thin. Time and energy
are limited resources, and triaging and root-causing bugs from
supporting multiple init systems take a lot of time; maintaining an init
script comprises only a small part of the support burden.

elogind is very difficult to support in its current state (see the
following bugs: [2] [3] [4] [5]), which is why Michael does not want to
maintain support for it.

[1] https://qa.debian.org/popcon.php?package=sysvinit
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968379
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959920


Feel free to direct any questions to me.

- e


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Elana Hashman
On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote:
> 
> On Wed, 18 Nov 2020 at 23:33, Josh Triplett  wrote:
> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> > Even if someone else offers to shoulder some of that load, that does not
> > eliminate the maintenance burden; in some cases, it may not even reduce
> > the maintenance burden.
> 
> Thank you for this.  This puts into very straightforward words a
> feeling I've had for ages but couldn't word well.
> 
> In many projects I maintain outside Debian, I very frequently see this
> belief that if someone else contributes the work to make something
> possible (or it is otherwise perceived as "trivial" work), that
> there's no work for the maintainer, when it actually *does* increase
> the maintenance burden, often in ways the contributor cannot or will
> not see (or in some extreme cases, refuses to).

I caution folks from speculating too much on the maintainer's
motivations and reasoning while they haven't yet had a chance to share
their perspective on the bug. :)

From what I can see reading through both #964139 and #960780, no
technical rationale has been given for why the script was removed, only
a statement that the removal was intentional.[0]

It would be much appreciated if Michael Biebl or another maintainer from
the Utopia team could add some context here.

- e

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62


signature.asc
Description: PGP signature


Bug#965080: Resignation + Call for votes for new Chair

2020-07-18 Thread Elana Hashman
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Philip Hands
>  B : Margarita Manterola
>  C : David Bremner
>  D : Niko Tyni
>  E : Gunnar Wolf
>  F : Simon McVittie
>  G : Sean Whitton
>  H : Elana Hashman 
> 
> ===END===

I vote:

B = C > A = D = E = F > G = H


- e


signature.asc
Description: PGP signature