Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Philip Hands]

Helmut Grohne  writes:
...
> As such, my expectation is that moving from where we are to your idea
> is not any easier than moving from a post-DEP-17 state. Therefore, I
> do not see any need to delay DEP-17 work.

I've been wondering about this possibility too.

If a symlink flowerbed is where we decided we wanted to end up, I get
the impression that starting from post-DEP-17 would be rather easier
than starting from where we are now.

DEP-17 provides us with a detailed roadmap for the first leg of that
trip, whereas the route via reversion seems to be littered with unknowns
at present.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: Is a different opinion about a license a case for the ctte?

[Philip Hands]

Hi Andreas,

While I think you're right that this is just some example text, and
given that it was added in quite a large commit, touching many other
files, all of which are presumably under GPL, with no mention of the
intent to license that one file differently, it would be quite
surprising if that was the way that's supposed to be interpreted.

On the other hand, given that it's an example, perhaps the author wanted
to make sure people could cheerfully cut it into things that were
not GPLed?

I'd say the only way to be sure would be to ask the author(he seems
pretty active on GitHub, so seems likely to respond in a timely manner).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Philip Hands]

Christoph Berg  writes:

> Re: Chris Hofstaedtler
>> >  * which binary package should contain the util-linux rename?
>> >- bsdextrautils
>> >- something else
>> 
>> util-linux-extra. Unrelatedly, other non-essential binaries from
>> util-linux should also move into this package, but this is only
>> tangentially related.
>
> Hi,
>
> I like that package name.
>
>> >  * where should it be installed?
>> >- /usr/bin
>> >- something else?
>> 
>> /usr/bin/rename
>
>> >  * should there be a Conflicts or Breaks relation with the perl rename?
>> 
>> I think this will be necessary.
>
> The problem here is that if ul-extra contains things besides rename,
> and it conflicts with the perl rename, people will rightfully complain
> that they can't install /usr/bin/fincore-from-ul-extra and
> /usr/bin/rename-from-perl at the same time.
>
> Or would you solve that using alternatives, without the conflicts?

Is it possible to have alternatives default to installing neither option
by default?

I suspect not, but something like that might allow local admins to
install either as /usr/bin/rename while not encouraging the use of that
path in packaging scripts (which should use either rename.ul or
file-rename to get the version they really want).

I suppose the same result could be constructed with a shared
low-priority debconf question about which to use, defaulting to neither.

An approach which strikes me as inelegant, but ought to work, would be
for something essential to provide the default alternative as a script
that spits out a warning that you should be using whichever of the
specific names you really meant, or that you could define 'rename' as an
alias in your profile, or even that you might use update-alternetives to
install one of them as 'rename' system-wide.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Philip Hands]

Helmut Grohne  writes:

>  * You take issue with "rename.ul" as a program name, because it is
>inconsistent with other Linux distributions.

Regarding this, perhaps we ought to ask util-linux's upstream if they'd
be willing to install /usr/bin/rename also as /usr/bin/rename.ul[1],
thus allowing people to write scripts that are portable across distros.

Cheers, Phil.

[1] If that is done with a symlink, I presume we'd have a very slight
preference for the actual binary to be called `rename.ul`, but it
doesn't really matter how it's done as long as people can rely on
rename.ul being present, regardless of distro.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

Adam Borowski  writes:

> 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.
>
> You did not even address, or even mention, that this idea has been vetoed by
> dpkg maintainers.

Where did you get the idea that maintainers have a veto regarding TC decisions?

BTW if you were to express your opinion here:

> And as that, it's a complete non-starter.

in the form of an expression of opinion (e.g. by putting something like
"I think" in front of it) rather than presenting it as though it were a
fact, you would be much less provocative, which might lead to a more
constructive discussion overall.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

Matthew Vernon  writes:

> On 14/12/2020 21:56, Philip Hands wrote:
>
>> Could I just check if there's a point of common acceptability which both
>> sides of this discussion could live with?
>
> [...]
>
>> My suggestion for a mutually bearable solution would be that the
>> network-manager package could have its dependency on libpam-systemd
>> changed to instead be something like:
>> 
>>libpam-systemd | network-manager-nonsystemd
>
> Is this instead of the logind virtual package? I'm not quite sure what 
> problem you're trying to solve here, but I'm don't think it generalises 
> well (you'd end up with potentially lots of package that just Depend on 
> logind and maybe contain an init script); and without any input from the 
> network-manager maintainer about why they were unwilling to take the 
> patch to use the existing virtual package, I'm not sure why this should 
> be more acceptable.

If that were the way things were going, then I'd expect one to end up
with a package that bundled all the init scripts, and provided whatever
virtual packages etc. required to glue all the bits together somehow.

The details of how to do that seemed like things that should be between
the people maintaining the two sets of packages, and I wasn't worrying
about the details too much, because I was rather hoping that it wouldn't
actually be needed.

>> If you think this approach is impractical for some reason, please say
>> so, because what I have in mind as a better option does rather rely on
>> this being available as a plausible fall-back position.
>
> I'm confused as to why you don't just tell us what your better option is.

My better option was that having defined the areas of responsibility by
thinking about who'd do what in a split package setup, we might manage
to agree that the same people could take the same responsibility for
maintaining those bits in the places where they would need to be in the
packages as they stand.

For that to work, I think the maintainer would have to have the right to
declare that they didn't think the experiment was working out
(presumably because of drowning in bugs that were not being handled in a
sensible time, say) at which point the already agreed split package
setup would provide an acceptable plan B.

That would hopefully allow the maintainer to relax enough about having
some new people co-maintaining some fragments of the package to give
space for everyone to demonstrate that it was possible for them to work
together.

There's nothing specific to NM in any of that BTW, so if other packages
are in this position where constructive cooperation really ought to
work, but there's just a little too much distrust at present, then maybe
you can give this a try there.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

lorenzo  writes:

> Hi all,
>
>> My suggestion for a mutually bearable solution would be that the
>> network-manager package could have its dependency on libpam-systemd
>> changed to instead be something like:
>>
>>  libpam-systemd | network-manager-nonsystemd
>
> Please consider that apt has issues with or group depends/recommends:
> Unless the first option listed is a virtual (nonexistent) package, it
> will force an init switch on install.
> For an example (with Recommends), see #953875 #47 and below

Good point.

I was mostly interested in seeing if there might be a package split that
would provide a division of responsibility where those that want the
work done get to do it without burdoning others with a lot of effort.

The details of the dependencies surrounding those packages would of
course be important if it were eventually decided to really implement
that solution -- if it is impossible to implement with apt, then that
certainly is a problem with this approach.

Are Simon's suggested dependencies are better in this regard?

(I was rather hoping that this would end up being the sort of detail
that would get agreed between the maintainers of the packages involved,
madly optimistic fool that I am ;-) )

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

Sean Whitton  writes:

> It is difficult to think further about this without input from the
> maintainer as to how much this was a part of his motivation, and what
> experiences he has had led him to think in that way.

Hi All,

Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?

Please don't assume that I'm offering this as a preferred outcome. I
would hope that we can come up with something better than this, but I
think that agreeing that this is an acceptable and achievable baseline
would provide a foundation on which to build something better.

My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on libpam-systemd
changed to instead be something like:

  libpam-systemd | network-manager-nonsystemd

and that the init diversity folks could then take responsibility for
satisfying that optional dependency as they see fit in order to keep
network-manager available on non-systemd systems, which should insulate
the network-manager maintainer from almost all of the effort involved.

I say 'almost all' because I would imagine that non-systemd-related bugs
might be reported against network-manager occasionally, and need to be
reassigned, and one could also imagine that upstream might change things
in a way that was clearly going to break things on non-systemd systems,
in which case it would be polite if the network-manager maintainer would
open a bug mentioning that change against the network-manager-nonsystemd
package, etc.

If you think this approach is impractical for some reason, please say
so, because what I have in mind as a better option does rather rely on
this being available as a plausible fall-back position.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#971515: Status as of last tech-ctte meeting

[Philip Hands]

Tollef Fog Heen  writes:

> ]] Shengjing Zhu 
>
>> Firefox is special, since for Debian desktop users, they need a browser. Is
>> kubernetes same here?
>
> FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
> nomad, docker swarm) in stable has been keeping back development of the
  ^^

Do you really mean stable here?  I had gained the impression that there
was no prospect of Kubernetes getting into stable, regardless of the
details of how it ends up being packaged.  Have I misunderstood?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

Margarita Manterola  writes:
...
> ===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

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

[Philip Hands]

David Bremner  writes:

> ===BEGIN
> The Technical Committee recommends that Sean Whitton  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END

I vote:

  S > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

[Philip Hands]

David Bremner  writes:

> ===BEGIN
> The Technical Committee recommends that Elana Hashman  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Elana Hashman 
> F: Further Discussion
> ===END

I vote:

  S > F

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#947847: please install systemd-sysusers using update-alternatives

[Philip Hands]

Svante Signell  writes:

> On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote:
>> Simon McVittie wrote:
>> > I think we have a fairly good picture of the costs that would be
>> > incurred from using alternatives:
>>
>> Plus in the case of opentmpfiles; a pile of security issues: systemd-
>> tmpfiles addresses a number of complex races using low level
>> primitives like openat() et al. or O_PATH, while opentmpfiles is
>> implemented in shell.
>
> Do you mean that shell scripts cannot cannot handle such issues??

If you are asking that question, then I suspect that your knowledge of
the problems of shell scripting may be sufficiently limited to mean that
the only useful way to answer it would be to say:

  Yes.

> So C-code is safe by construction, do you really believe in that?

What a ludicrous question -- well done for surpassing the previous one.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Philip Hands]

Didier 'OdyX' Raboud  writes:

> Dear Technical Committee members,
>
> I call for vote immediately on the following resolution.
>
> === Resolution ===
>
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
>
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
>
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
>
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
>
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
>
> * FD: Further Discussion
>
> === End Resolution ===

I vote:

  H > M > FD > W

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Philip Hands]

Ian Jackson  writes:

...
>
>  * Declare that no-one is allowed the binary package name
>/usr/bin/dune other than the C++ library dune-common
 ^
I suspect you meant 'dune' there.

BTW I agree (having followed the thread) that the consensus on
debian-devel was that the choice of name was pretty foolish.
Foolishness made less forgivable by the fact that the name change was
prompted by a previous clash, and the new name was very obviously also
going to clash with several easily discoverable software projects.

My opinion is that if any package gets to use /usr/bin/dune, it should
be one of the other ones: As you suggest, most probably the C++ library.
The same goes for the package name.

Stéphane,

  That being the case, I would encourage you to come up with a better
  justification than what I've seen so far[1].  The sooner you do this,
  the more likely is is to have an influence on the outcome.

BTW This is just my opinion, and I'm not trying to swing the view of the
rest of the TC by stating it.  However, I suspect that I'm not alone in
thinking this, so it seems OK to say so early rather than to insist on
trudging through the more usual processes and waste a lot of time.

Cheers, Phil.

[1] It seems the Upstream didn't like the idea of another name change.
Other than that I've not noticed a particular reason for the choice
of name beyond the association between camels and dunes, which seems
pretty weak to me.  Feel free to point out if this is wrong.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Call for vote on disallowing the use dpkg's vendor series in the archive

[Philip Hands]

Tollef Fog Heen  writes:
...
> A: Approve resolution, disallowing the use of dpkg's vendor series
> F: Further Discussion

I vote A > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Philip Hands]

Adrian Bunk  writes:

> On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
>>...
>> IMO policy should recomend the use of separate source packages as the
>> prefered solution to the problem that vendor-specific patch series were
>> supposed to address.
>
> In this case please make an explicit decision on whether build-time 
> patching is the recommended replacement for vendor-specific patch 
> series, or what kinds of build-time patching will no longer be 
> permitted.
>
> The current situation in the archive is:
> - 18 packages with vendor-specific patch series
> - an unknown number of packages (e.g. src:gcc-8) that are doing 
>   vendor-specific build-time patching and/or patching based on
>   other factors like architecture
> - > 100 packages that are doing patching and/or configuration
>   based on dpkg-vendor
> - an unknown number of packages (e.g. src:gcc-8) that are doing patching 
>   and/or configuration based on other tools like lsb_release
>
> It is not clear at all which of the above exactly you want to have 
> removed from the archive and moved as permanent deltas downstream.

I think it's entirely up to the maintainers of the package (as long as
they avoid vendor-specific patch series in future).

However if someone reads the prohibition against vendor-specific patch
series, and is left wondering what is the best way to deal with this
situation, then it would probably be helpful to give them a hint.

The methods you highlight all seem to suffer from the problem that if a
downstream needs to make a vendor specific change, they need to do an
odd dance where they may have to introduce a delta in order to get the
vendor version out in a timely manner, then they need to get that into
the debian source, and perhaps prompt a no-change release of the Debian
package in order to be able to pick up the change and drop the delta.

It makes much more sense to me to have branches for the debian and
downstream patches side-by-side in one's favourite source control system,
and just build and release whatever one needs, whenever one needs it.

BTW Do we have any way of determining how many packages already deal
with vendor-specific changes in this way?

I'll admit that I've not had to deal with such packages, so feel free to
explain to me why my perception of the situation is utterly deranged.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Philip Hands]

Ian Jackson  writes:

> Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should 
> be permitted in the archive"):
>> On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
>> >   The Committee therefore resolves that:
>> > 
>> >   1. Any use of dpkg's vendor-specific patch series feature is a bug for
>> >  packages in the Debian archive (including contrib and non-free),
>> 
>> This misses an important part of the previous proposal:
>
> I think Phil was just intending to leave the recitals part alone, and
> proposing only a change to the operative part - not to delete the
> recitals.

Correct -- sorry if that wasn't clear.

>>   The Committee recognises that there is a need for packages to behave
>>   differently when built on different distributions, but this should be
>>   done as part of the build process, using current and future practices
>>   such as patches with conditional behaviour, patching of files during the
>>   build, rather than at source unpacking time.
>
> However, now that we are talking about the recitals I would like to
> suggest that the recitals should include *maintaining different source
> packages in different distributions* as one of the suggested options.
>
> IMO it is far superior to patches which are conditional (at runtime or
> at build-time) on dpkg-vendor and I would not like to see that
> perpetuated.

As you say, a separate source package seems like the right way to deal
with this situation.

IMO policy should recomend the use of separate source packages as the
prefered solution to the problem that vendor-specific patch series were
supposed to address.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Philip Hands]

Tollef Fog Heen  writes:

> ]] Philip Hands 
>
>> Tollef Fog Heen  writes:
>> 
>> >This should be implemented in Debian Policy by declaring that a a
>>^^^
>> You've this doubled 'a' on two occasions in this text.
>
> I'll fix that, thanks for spotting it.
>
>> Presumaly we would not want to see new packages adopting the use of
>> vendor-specific patch series prior to Buster.
>> 
>> Do we need to make the "SHOULD NOT" conditional on the package already
>> having a vendor-specific patch series at the time of this resolution?
>
> I think that just adds needless complexity and assumes that
> maintainers will want to add bugs to their package.  I really hope
> that's not the case, so I don't think it's worthwhile to add extra
> language for it.

Well, I was thinking that we could simply state the MUST NOT as the
general case straight away, but with a limited exception for packages
that already contain the bug now, where that exception expires with the
release of Buster.

Your approach seems to require a timely update to policy post-buster,
whereas if there's a conditional in policy there would be no urgency to
removing it, so it can be done at the convenience of the policy
maintainers.

On reflection this seems like we're straying into micro-management.
Should we really be determining the detail of how this is done in
policy?

How about this instead:

  The Committee therefore resolves that:

  1. Any use of dpkg's vendor-specific patch series feature is a bug for
 packages in the Debian archive (including contrib and non-free),
 however existing use of this feature in packages should not be
 considered release critical until after the release of Buster.

Possibly also with something like this?:

 Post-Buster this should be implemented in Debian Policy by
 declaring that a package MUST NOT contain a non-default series
 file.

 The approach adopted to allow existing usage is left to the
 discretion of the Policy Maintainers.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Philip Hands]

Tollef Fog Heen  writes:

>This should be implemented in Debian Policy by declaring that a a
   ^^^
You've this doubled 'a' on two occasions in this text.

Presumaly we would not want to see new packages adopting the use of
vendor-specific patch series prior to Buster.

Do we need to make the "SHOULD NOT" conditional on the package already
having a vendor-specific patch series at the time of this resolution?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Philip Hands]

Adrian Bunk  writes:

...
>> "The source" is what you get after steps 1 and 2.
>
> Why is "The source" what you get after dpkg applied patches,
> but before debian/rules applied patches?

I agree with Sean's point about it being a matter of definition relating
to when we invoke debian/rules, but for an alternative justification one
might look at this:

For the Debian Maintainer, what is the preferred form of modification?

It could be the source before the patches are applied (especially if
they're working on a patch to be sent upstream), but really, chances are
that it's actually the state of the source after the Debian patches are
applied.

It is almost certainly _not_ the state that source might get transformed
into at some point during the build process.

It is also almost certainly not the alternative version of the source
that results from applying a patch series that only gets applied if they
unpack the source on a different vendor's OS.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Next Meeting: Wednesday, July 18th 19:00 UTC (today) - Currently no topics

[Philip Hands]

Margarita Manterola  writes:

> On 2018-07-18 12:24, Margarita Manterola wrote:
>
>> Do we want to meet tonight and talk about the upcoming DebConf
>> presentation?  Those of us not going could help with the preparation
>> task even if not present at the conference.
>> 
>> If whoever is in charge of the presentation (who is that?) thinks this
>> is valuable, please speak up in the next few hours.
>
> Gunnar is in charge of said presentation and has stated that he doesn't 
> think
> we need a meeting for it.
>
> Today's meeting is officially canceled.

Well, that's a bit of luck, as I was sitting in a pub yesterday, and had
been ignoring mail all day (I'm on holiday with the kids, visiting old
chums in Wales, and haven't spent more than about 15 minutes near a
keyboard in the curent week.  This state is likely to continue until I
get to Debcamp (next thursday-ish IIRC -- not sure what with timezones
etc).

See (some of) you soon :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#893200: marked as done (TC Chair election)

[Philip Hands]

"Debian Bug Tracking System" <ow...@bugs.debian.org> writes:

> Your message dated Sun, 25 Mar 2018 11:14:16 +0200
> with message-id <10372274.mhgyzpu...@odyx.org>
> and subject line Re: Bug#893200: TC Chair election
> has caused the Debian Bug report #893200,
> regarding TC Chair election
> 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
> immediately.)
>
>
> -- 
> 893200: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893200
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Didier 'OdyX' Raboud <o...@debian.org>
> Subject: TC Chair election
> To: sub...@bugs.debian.org
> Date: Sat, 17 Mar 2018 10:25:28 +0100
>
> Package: tech-ctte
> Severity: normal
>
> Dear TC members,
>
> With the appointment of Simon to the TC and according to our current 
> procedures¹, I am hereby announcing my immediate vacation of the chair 
> position, triggering a new election.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===
>
> -- 
> OdyX
>
> ¹ https://salsa.debian.org/debian/tech-ctte/blob/master/procedures/
> appointment_of_the_chair.md
> From: Didier 'OdyX' Raboud <o...@debian.org>
> Subject: Re: Bug#893200: TC Chair election
> To: 893200-d...@bugs.debian.org
> Date: Sun, 25 Mar 2018 11:14:16 +0200
>
> Le samedi, 17 mars 2018, 10.25:28 h CEST Didier 'OdyX' Raboud a écrit :
>> With the appointment of Simon to the TC and according to our current
>> procedures¹, I am hereby announcing my immediate vacation of the chair
>> position, triggering a new election.
>> ===BEGIN===
>> 
>> The chair of the Debian Technical Committee will be:
>> 
>> A : Didier Raboud 
>> B : Tollef Fog Heen 
>> C : Phil Hands 
>> D : Margarita Manterola 
>> E : David Bremner 
>> F : Niko Tyni 
>> G : Gunnar Wolf 
>> H : Simon McVittie 
>> ===END===
>
> With one week passed (§6.3.1) [0], here come the vote results:
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> The winners are:
>  Option C "Phil Hands "
>  Option D "Margarita Manterola "
>  Option E "David Bremner "
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Making use of my casting vote (§A.6.8) [1,2], I hereby designate Margarita 
> Manterola  as the new TC Chair, effective immediately.

Perfect. :-)

I'd lost track of the deadline, otherwise I'd have voted for that as
well, in which case Marga would have won without a casting vote.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#880014: Call for Votes for new TC member

[Philip Hands]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> I call for votes on the following ballot to fill a vacant seat in the TC. 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 recommends that Simon McVittie  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Simon McVittie <s...@debian.org>
> F: Further Discussion
> ===END

I vote:

  S > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Philip Hands]

On Mon, 26 Feb 2018, Aleksander Morgado <aleksan...@aleksander.es> wrote:
>>>
>>> As soon as we get this merged to git master, I can tag a 1.8 beta
>>> release (e.g. 1.7.990). What do you think?
>>>
>>
>> FYI, 1.8-rc1 has been tagged with the optional filter policy support 
>> included:
>> https://lists.freedesktop.org/archives/modemmanager-devel/2018-January/006157.html
>>
>> By default it uses the DEFAULT policy (equivalent to what we were
>> doing until now). You can enable the STRICT policy passing
>> --filter-policy=STRICT on the ModemManager startup (e.g. as a patch to
>> the systemd service file).
>>
>
> Ian, any comment about this 1.8-rc1 version with the filter policies
> implemented?
>
> Also, is there any new maintainer I should talk to regarding
> integration tasks for this new version?

I've been in touch with Mathieu Trudel-Lapierre (Cc:ed) and he's still
happy to act as maintainer.  He's currently not a DD/DM so needs
sponsorship for his packages, but that should not be problem.

The @ubuntu email address that was on the package turns out to be
outdated, and was bouncing, which is why he's been out of the loop until
now.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Philip Hands]

On Thu, 22 Feb 2018, Wookey <woo...@wookware.org> wrote:
...
> Anyway, Pirate - I suggest you ask about this on debian-devel where we
> can have a pulic discussion about policy and whether there is anything
> special about this case which makes it not suitable software for the
> archive.

This would probably have been a much better approach than the course
that was taken.

The private discussion with Thorsten that was forwarded to the bug
seemed not to have been followed through to any sort of conclusion
before escalation to the TC.

Also, the questions that Don was trying to explore about why there was a
need for the dependencies in the first place went unanswered. Presumably
because the whole thing is moot now that the package has been accepted.

If that was the reason for not responding to Don, it would have been
polite to close the bug at that point.

If on the other hand one is still expecting clarification on some
outstanding point (despite the fact that the original purpose of the bug
is now gone) then it would probably be wise to say so explicitly.

In the absence of any of that, my only regret is that we didn't reject
the bug at the outset for not really having bothered with steps 1-3 here:

  https://www.debian.org/devel/tech-ctte

I'm confident that we can all learn from this experience, and hope we
will do a better job next time.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Philip Hands]

On Fri, 09 Feb 2018, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> I call for votes on the following resolution with regards to #883573.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
>
> === Resolution ===
>
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
>
> The Committee therefore resolves that:
>
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
>
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion

I vote:

  R > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Philip Hands]

On Sun, 04 Feb 2018, "Kingsley G. Morse Jr." <kings...@loaner.com> wrote:
> Hi Phil,
>
> I find I often benefit from other people's point
> of view.
>
> If you happen to have the time, and are so
> inclined, and it would be comfortable, feel free
> to elaborate on your comment in bug report #889493.
>
> I'm particularly curious why you wrote it had no
> merit.

If you look closely, you'll notice that I didn't actually write that,
but never mind.

For anything worthwhile to conceivably come out of such a bug, at least
one TC member would need to be at least a little interested in
discussing it, in which case they would certainly reopen the bug, and
we'd then continue as if I'd done nothing.

I look at that as simply changing the default state of the incoming bug
to closed[1].

Of course one would normally go to the effort of pointing out the
specific flaws in the submission, but I'm not going to do that in this
case because I wouldn't want to give the false impression that if only
you'd done a few things differently it would have been considered.

Submitting this bug demonstrates to me that you have fundamentally
misunderstood the purpose and power of the Technical Committee.  Once
that misunderstanding is rectified, you will no longer be tempted to
submit the bug in any form.  The fact that the original bug also fails
to conform with most of the bug submission guidelines is irrelevant.

To draw an analogy, you might as well spend your time writing to the
Oxford English Dictionary complaining about the inclusion of words you
don't like (although please don't, as they also have more useful things
to be doing than discarding post).

Cheers, Phil.

[1] I could imagine us doing that with all bugs in fact -- if the first
person to get to the bug doesn't see it as worth discussing they
simply close it and leave other members of the TC to reopen it if
they disagree. This is much more efficient than leaving it open
until after the next meeting, and doesn't give a false impression
about what is happening to the submitter.  I can think of a couple
of recent bugs that would have benefited from this approach ;-)
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886267: Voting for TC Chair

[Philip Hands]

On Wed, 03 Jan 2018, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Didier Raboud 
> B: Tollef Fog Heen 
> C: Phil Hands 
> D: Margarita Manterola 
> E: David Bremner 
> F: Niko Tyni 
> G: Gunnar Wolf 
> ===END===

I vote:

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

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#880014: #880014: Call for Votes for new TC member

[Philip Hands]

On Tue, 26 Dec 2017, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> I call for votes on the following ballot to fill a vacant seat in the TC. 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 recommends that Gunnar Wolf <gw...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
>
> G: Recommend to Appoint Gunnar Wolf <gw...@debian.org>
> F: Further Discussion
> ===END

I vote:

  G > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Dec 2017 TC meeting is at 'Wed Dec 20 19:00:00 UTC 2017'

[Philip Hands]

On Mon, 18 Dec 2017, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> The monthly Debian Technical Committee Meeting is happening on Wednesday:
>
> date -d 'Wed Dec 20 19:00:00 UTC 2017'
> in #debian-ctte on irc.debian.org
>
> The agenda is not short; we have 4 issues on our hands. Looking forward to a 
> productive meeting!

I'm afraid that I am quite likely to either be absent, or only partially
present, so I'll apologise now just in case.

Our household is not exactly glowing with health at this moment. I was
in bed with a fever over the weekend. Our two-year-old has been running
a fever for two days, the five-year-old seems to be threatening to go
down with the same thing. Gunde, my wife, was avoiding all that, but
then got a dose of food poisoning, which wrecked her and my sleep last
night and she seems likely to be confined to bed for at least another
day, so not a lot is getting done at present. Fun, fun, fun.

We appear to be mostly over the worst of that though, so hopefully
things will be back under control shortly. (he writes, as a small person
partially-wakes and starts making pathetic noses... )

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Philip Hands]

Aleksander Morgado <aleksan...@aleksander.es> writes:

> Hey Ian,
>
> On Thu, Oct 12, 2017 at 2:39 PM, Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
>> Aleksander Morgado writes ("Bug#877024: modemmanager should ask before 
>> messing with serial ports"):
>>> This is part of the discussion we had in the MM mailing list for such
>>> a solution:
>>> https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html
>>
>> Thanks, this looks constructive.
>>
>> Of the heuristics in that mail, most seem to me to be very sound
>> justifications for thinking that the device is safe to probe.
>>
>> The one big exception is this:
>>
>>  | * If vid is a known modem vendor (e.g. huawei, zte, sierra, u-blox,
>>  |  telit), it's a modem and we probe the tty.
>>
>> This is a hostage to the future, since of course we don't know what
>> devices might be manufactured by a particular vendor in the many-years
>> life of a Debian release.
>>
>
> Yes, this one is probably the weakest rule of all. Still not sure at
> which point to apply the rule, though. E.g. should it be applied after
> having applied all the previous rules (in that case it would be a very
> safe rule, maybe totally unneeded) or should it be applied as an OR to
> some other rule (e.g. driver is option/sierra/qcserial OR vendor is
> huawei/zte..., in this case it would be a weaker rule). Will need to
> decide this based on testing with real devices.

It's nice to see that a workable solution seems to be emerging here.

My opinion on the final wrinkle is that for Debian, in the case of
uncertainty, modemmanager should not be probing, and that guessing based
on manufacturer seems insufficiently certain.

Optimistic probing hides the fact that one doesn't _really_ know the
device is a modem.  The result being that the bug report mentioning the
features of the device that might allow an improved heuristic to be
developed is never going to be submitted.

That being the case, I agree with Ian that if such behaviour is
implemented, it would be best if it can be disabled at run-time, and that
the Debian package should then default to disabling it.

Having the option to enable it at run-time would still be useful, so
that people that know that they really do have a modem, can:

  read the package's README to discover why it doesn't work

  report a bug saying what sort of modem they have, and that it's not
  being found by the Debian default configuration of MM

  and then flick the switch to make modemmanager optimistic enough to
  find their modem (on the understanding that it might break other
  stuff they could plug in, but at least they'll know why)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; 
> urgency=medium"):
>> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
>> until it's no longer needed - be it other debian packages or other user
>> scripts.
>
> Earlier you said only "other Debian packages":
>
>My plan was to simply keep /usr/bin/nodejs around for some time
>until no debian package rely on it.
>
> Now you say "other user scripts".  I don't know how you would ever
> tell whether "other user scripts" were relying on it.  There is no way
> to for us to tell what people are doing on their computers (and nor
> should there be).

I guess that one could do something like moving the symlink into another
-legasy style package, and recomend that from the main package for one
release to keep upgrades happy. Then drop the recomendation, and wait
for popcon to show that people are not installing the package any more.
Then remove the package in testing early in a cycle and see if anyone
reports bugs about it.

That seems like rather a lot of effort though, when the alternative is
simply tolerating the existence of the two line debian/nodejs.links file.

Is there some down-side for users to having those links in place on
their systems?  If so, I don't think anyone's mentioned it yet.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Jérémy Lal <kapo...@melix.org> writes:

> 2017-08-30 11:50 GMT+02:00 Philip Hands <p...@hands.com>:
>
>> Jérémy Lal <kapo...@melix.org> writes:
>>
>> > 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>:
>> >
>> >> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
>> >> > Leave /usr/bin/nodejs there for at least one more release.
>> >>
>> >> I'll just note for the purpose of the TC discussion that as of nodejs
>> >> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs
>> →
>> >> node
>> >> symlink still exists, so at this point, I don't consider there is
>> material
>> >> for
>> >> a TC decision either way, but it's an important conversation to be had.
>> >>
>> >> Jérémy: could you maybe clarify your plan and your rationale? This would
>> >> help
>> >> putting everyone on common grounds.
>> >>
>> >
>> > I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from
>> > /usr/bin/nodejs to /usr/bin/node.
>> > My plan was to simply keep /usr/bin/nodejs around for some time until
>> > no debian package rely on it. The JavaScript debian team wiki is updated
>> > to reflect that.
>>
>> I was against the TC instructing you how to behave in detail in our
>> resolution, because I couldn't imagine that anyone would think that
>> tidiness was more important than not breaking things for our users.
>>
>> Are you really going to prove me wrong?
>>
>> How much is it costing you to keep the symlink there?
>>
>> Do you expect that cost to ever exceed the effort of responding to even
>> the first bug reported about this, when you turn out to have broken
>> someone's locally-written script?
>>
>> Actually, do you expect it to ever exceed the effort already wasted in
>> responding to this thread by you and us?
>>
>> It's pretty clear that if you do decide to go ahead and remove
>> /usr/bin/nodejs quickly, that someone is likely to kick the matter back
>> up to the TC.
>>
>> I for one will have absolutely no sympathy with your side of the case at
>> that point, not only because I think it is senseless, but also because
>> you'll have been responsible for wasting the time of all involved.
>>
>> I will also not be even slightly timid about micro-managing you the
>> second time around, since if that comes to pass you'll have demonstrated
>> the need.
>
>
> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
> until it's no longer needed - be it other debian packages or other user
> scripts.
> If it was to be really removed, it shouldn't be done without some
> deprecation
> warning and time for users to notice and change their code.

Ah, well -- that's all fine then.  Thanks for clarifying.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Jérémy Lal <kapo...@melix.org> writes:

> 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>:
>
>> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
>> > Leave /usr/bin/nodejs there for at least one more release.
>>
>> I'll just note for the purpose of the TC discussion that as of nodejs
>> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs →
>> node
>> symlink still exists, so at this point, I don't consider there is material
>> for
>> a TC decision either way, but it's an important conversation to be had.
>>
>> Jérémy: could you maybe clarify your plan and your rationale? This would
>> help
>> putting everyone on common grounds.
>>
>
> I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from
> /usr/bin/nodejs to /usr/bin/node.
> My plan was to simply keep /usr/bin/nodejs around for some time until
> no debian package rely on it. The JavaScript debian team wiki is updated
> to reflect that.

I was against the TC instructing you how to behave in detail in our
resolution, because I couldn't imagine that anyone would think that
tidiness was more important than not breaking things for our users.

Are you really going to prove me wrong?

How much is it costing you to keep the symlink there?

Do you expect that cost to ever exceed the effort of responding to even
the first bug reported about this, when you turn out to have broken
someone's locally-written script?

Actually, do you expect it to ever exceed the effort already wasted in
responding to this thread by you and us?

It's pretty clear that if you do decide to go ahead and remove
/usr/bin/nodejs quickly, that someone is likely to kick the matter back
up to the TC.

I for one will have absolutely no sympathy with your side of the case at
that point, not only because I think it is senseless, but also because
you'll have been responsible for wasting the time of all involved.

I will also not be even slightly timid about micro-managing you the
second time around, since if that comes to pass you'll have demonstrated
the need.

Be warned.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Agust 2017 TC meeting is at 'Wed Aug 16 19:00:00 UTC 2017'

[Philip Hands]

Hi Niko,

Niko Tyni <nt...@debian.org> writes:

...
> I mailed fil a (probably overly elaborate) first draft for #865929 some
> time ago but haven't heard back yet. I'm not particularly wedded to that,
> so happy to consider other options too.

Yeah, sorry, I only had time to skim-read it at the time, and then
DebConf took my attention.

I think the draft was fine (and thanks very much for writing it, as I
didn't get anywhere near doing so), but I also agree with you that
there's really not a need for a resolution, since it seems like a pretty
normal to adopt the conffile from the ashes of the obsolete package.

Also, Colin seems to be saying the same thing, here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929#57

That being the case, I just closed it.

If anyone wants to add a resolution, we can always just reopen the bug,
or simply tack it onto the closed bug, say.

BTW I started out with the above paragraph including things like "unless
anyone objects", but I'm pretty sure that nobody does, and it's a
reversible action, so I just went for it -- I hope nobody minds.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Philip Hands]

Sean Whitton <spwhit...@spwhitton.name> writes:

> On Thu, Aug 03, 2017 at 05:51:27PM +0200, Philip Hands wrote:
>> P.S. Just in case this is an oversight, rather than an intentional
>> change:
>> 
>>   Shouldn't "desktop entry" and "Debian menu entry" be somehow
>>   emphasised, to make it clear that there is a reference back to the
>>   earlier definition?
>> 
>> If you meant to get rid of that, no problem.
>
> Ah, sorry, I see what you mean now.
>
> I think it makes sense to get rid of it: IME, when emphasis is used in
> defining a term, it is not repeated when the term is later used.
>
> Do I have your approval for the patch, with the plural/singular fixed?

Yes, that's fine with me.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Philip Hands]

Hi Sean,

Sean Whitton <spwhit...@spwhitton.name> writes:

> control: tag -1 +patch
>
> Hello tech-ctte,
>
> On Thu, Aug 03, 2017 at 08:53:09AM +0200, Didier 'OdyX' Raboud wrote:
>> So yes, point 2 corresponds to your:
>> > - delete that paragraph
>> > - add a new paragraph saying "if there is a desktop file, there should
>> >   be no menu file"
>> [...]
>> That said, now that thanks to new forces, the process seems vivid and strong 
>> again, it does indeed make sense to reassign that to Policy. I'm hereby 
>> doing 
>> this, marking the TC as "affected". We'd still be happy to help on the 
>> wording, ideally during DebConf!
>
> Here is my proposed patch to policy.  Since the TC has made a decision,
> it doesn't make sense to seek seconds for this change, in the usual way.
> So instead I'd like to see "seconds" from at least three TC members
> confirming that this patch is sufficient to close this bug:
>
> diff --git a/policy.xml b/policy.xml
> index 3daa532..934a85b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8990,14 +8990,8 @@ Reloading description 
> configuration...done.
>  receive extra contributions such as translations.
>
>
> -Packages can, to be compatible with Debian additions to some
> -window managers that do not support the FreeDesktop standard, also
> -provide a Debian menu file, following the
> -Debian menu policy, which can be found in the
> -menu-policy files in the
> -debian-policy package.  It is also available
> -from the Debian web mirrors at  -
> url="https://www.debian.org/doc/packaging-manuals/menu-policy/;>https://www.debian.org/doc/packaging-manuals/menu-policy/.
> +If a package installs a FreeDesktop desktop entries, it must
> +not also install a Debian menu entry.

You appear to have a singular/plural mismatch with:

  installs a FreeDesktop desktop entries

I guess that should instead be:

  installs FreeDesktop desktop entries

(or perhaps it should be singular throughout, I'm not sure)

Cheers, Phil.

P.S. Just in case this is an oversight, rather than an intentional
change:

  Shouldn't "desktop entry" and "Debian menu entry" be somehow
  emphasised, to make it clear that there is a reference back to the
  earlier definition?

If you meant to get rid of that, no problem.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Philip Hands]

Tollef Fog Heen <tfh...@debian.org> writes:

> I call for votes on the following resolution with regards to #862051.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
>
> === Resolution ===
>
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
>
> The Committee therefore resolves that:
>
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
>
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote:   R > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Philip Hands]

Hi Colin,

Just in case it's not already clear from the replies you have received
so far, there is a consensus amongst the members of the TC that you
should do as you suggest -- this was reflected in our recent meeting:

  
http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-07-19-18.59.log.html#l-36

That being the case, I think you should just get on with fixing it,
rather than awaiting a resolution from us.  (of course if other TC
members have some objection to this suggestion, please say so).

I see no reason for you to waiting for the outcome of a discussion
about whether we need to change policy, or give you an exception to
policy, or simply say that there's nothing going on in violation of
policy.

Also, if you were to come across any additional wrinkles in the course
of fixing this, you can mention them so that we can make sure that
whatever we resolve ensures that you are able to do whatever is needed
(or perhaps suggest alternative approaches).

BTW I'd like to thank you for the clarity with which you laid out the
problem for us -- I'm sure the rest of the TC appreciate that too.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#862051: Refer #862051 to ctte

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Anthony DeRobertis writes ("Re: Bug#862051: Refer #862051 to ctte"):
>> On 07/14/2017 12:57 PM, Tollef Fog Heen wrote:
>> > Fair point.
>> >
>> >3. Once a new nodejs package providing /usr/bin/node is in the
>> >   archive, other packages in the archive are free to depend on the
>> >   nodejs package and use /usr/bin/node .
>> 
>> That should probably be a versioned Depends, at least until a stable 
>> release includes /usr/bin/node in nodejs. Otherwise upgrades may break.
>> 
>> OTOH, is this paragraph (or 2, for that matter) really needed? They're 
>> just restating (somewhat imperfectly) Policy and/or normal practice in 
>> Debian, which presumably come back into effect anyway once the 
>> 2012-07-12 decision is repealed.
>
> It would be better to simply say "following Debian's existing backward
> compatibility practices" or something, than trying to restate it all.

Quite -- I think we just need to have clause 1 in the resolution itself.

We could have some suggestions as additional notes to describe the
consequences of the revocation.

Like mentioning that where a versioned depends on nodejs is deemed
necessary, the Depends: should probably also allow nodejs-legacy as an
alternative option, since that also provides /usr/bin/node.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#865485: Voting for TC Chair

[Philip Hands]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> Package: tech-ctte
> Severity: normal
>
> Dear TC members,
>
> With the appointment of Niko to the TC and according to our current 
> procedures¹, I am hereby announcing my immediate vacation of the chair 
> position, triggering a new election. For clarity of the process, I am 
> interested to continue serving as chair.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> H: Niko Tyni 
> ===END===

I vote:

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

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new TC member

[Philip Hands]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> I call for votes on the following ballot to fill a vacant seat in the TC. 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 recommends that Niko Tyni <nt...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
>
> N: Recommend to Appoint Niko Tyni <nt...@debian.org>
> F: Further Discussion
> ===END

I vote:

  N > F

-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#860520: Voting for TC Chair

[Philip Hands]

Didier 'OdyX' Raboud  writes:

> Package: tech-ctte
> Severity: normal
>
> Dear TC members,
>
> With the appointment of David to the TC and according to our current 
> procedures¹, I am hereby announcing my immediate vacation of the chair 
> position, triggering a new election. For clarity of the process, I am 
> interested to continue serving as chair.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> ===END===

I vote:

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


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

[Philip Hands]

Margarita Manterola <ma...@debian.org> writes:

>> ===BEGIN
>> 
>> The Technical Committee recommends that David Bremner  be
>> appointed by the Debian Project Leader to the Technical Committee.
>> 
>> A: Recommend to Appoint David Bremner 
>> B: Further Discussion
>> 
>> ===END
>
> I vote A > B

So, with that vote added, option A defeats B by 4 votes, and we thus
agree to recommend David for the TC.

Mehdi, does this count as sufficiant notification of that fact?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

[Philip Hands]

I vote:

> ===BEGIN
>
> The Technical Committee recommends that David Bremner  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> A: Recommend to Appoint David Bremner 
> B: Further Discussion
>
> ===END

  A > B

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

[Philip Hands]

I call for votes on the following ballot to fill one of two vacancies in
the CTTE. Voting will begin now, and end when the outcome is no longer
in doubt or one week from now.

===BEGIN

The Technical Committee recommends that David Bremner  be
appointed by the Debian Project Leader to the Technical Committee.

A: Recommend to Appoint David Bremner 
B: Further Discussion

===END
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

[Philip Hands]

Tollef Fog Heen <tfh...@err.no> writes:

> ]] Andreas Beckmann 
>
>> On 2017-03-09 18:00, Ian Jackson wrote:
>> > To be fair to Pirate, Andreas Beckmann suggested #856606 that if
>> > Pirate disagreed with Andreas, Pirate should go to the TC.
>> 
>> The disagreement between Pirate and me is not about the RC-ness of
>> #856606, but more about the general requirement of working upgrade paths.
>> 
>> This is my understanding of Pirate's point:
>> 
>>   "Package P hasn't been part of any stable release so far, therefore
>>upgrades from earlier package versions don't have to be supported.
>>So not having a working upgrade path from version 1.2-3 in testing
>>to version 1.2-5 unstable is not a bug."
>
>>From reading through the bug log, that is my understanding of his point
> as well.
>
> The upgrade is from a previous version of gitlab that has been in
> stretch for a little under a month (it went into testing on
> 2017-02-18).  I think it's completely clear that failure to support
> upgrades (even between short-lived versions that only hit unstable) is a
> bug.  For versions that hit testing, even more so.

The problem with upgrades is due to the change of location of the
defaults which were being read from under /usr/share/doc/

Not using /usr/share/doc/ in this way is a clear improvement.

The upgradeability bug is related to the fact that the config file
includes the location of the default (*.example) files, and that has
changed, but being a conffile it can persist with the old setting into
the running of the new version's scripts.

The underlying problem is that settings that are only really useful to
the first invocation of the postinst (the paths to the *.example files)
are making their way into the package's configuration under /etc.

One ought to be able to sort out the specific upgrade bug in an updated
unstable package, but that does nothing to fix the package in stretch.

I'd expect to see more bugs related to this code.

I'm not sure if that counts as RC, but it seems clear that plastering
over the cracks with patches to the unstable package does nothing to
address the underlying problems of cruft in /etc and sloppy scripting.

Unfortunately, now we're frozen, fixing the stretch package might be a
problem, although if we agree that this is RC, then I guess we can still
fix it :-)

I'm happy to come up with a patch if that helps.[1]

Cheers, Phil.

[1] Moving the files out of /usr/share/doc/ and hard-wiring the new
paths into the postinst would do the trick (unless there is some reason
to be able to configure their location, which I cannot really imagine).

I presume those settings are used nowhere else, in which case they
should be renamed in the script, in order to avoid the export $(cat ...)
code overwriting the new settings.

Rewriting the export $(cat ...) code at the same time would be nice, but
the release managers would need to decide if they think that the
existing code is nasty enough to allow a bigger patch.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

[Philip Hands]

Andreas Beckmann <a...@debian.org> writes:

> On 2017-03-09 18:00, Ian Jackson wrote:
>> To be fair to Pirate, Andreas Beckmann suggested #856606 that if
>> Pirate disagreed with Andreas, Pirate should go to the TC.
>
> The disagreement between Pirate and me is not about the RC-ness of
> #856606, but more about the general requirement of working upgrade
> paths.

Looking at the bug, I see that the issue involves this bit of code:

  export $(cat /etc/gitlab/gitlab-debian.conf)

(and other variations thereof) used in the maintainer scripts, and
suggested in the README as something for the user to run.

It strikes me as rather fragile, and likely to misbehave in surprising
ways -- e.g. if one comments out a line in the file with '# ' then the
setting will still get set.

Is it not possible to patch the code of the package to contain the
default paths internally, so that it is not essential to populate the
environment before running things?

Failing that, how about setting the defaults and exporting them in a
wrapper script, which could also source the config file (in the more
normal way) before then invoking rake (or whatever), and then using that
in place of running rake etc. directly?

Either of these should mean that one could have an empty/missing config
file under /etc, or include comments in the config file, and still have
things work properly.

I suspect that much of the tangled code for handling the config files
would drop away if you did this, which ought to also ensure that this
bug would disappear.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

[Philip Hands]

Margarita Manterola <ma...@debian.org> writes:

> I call for votes on the following resolution with regards to #846002:
>
>  RESOLUTION 
>
> Background
>
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing 
> the
> list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
>
> Even though the debian-installer maintainer complained in May 2016 that he did
> not agree with this approach with regards to including external packages in 
> the
> default tasksel screen, the important priority remains until today.
>
> In December 2016, changes were made in the tasksel package so that it no 
> longer
> automatically displays external tasks as part of the debian-installer.
>
> The current state is that chroots created by debootstrap in unstable or 
> testing
> include the blends-tasks package, although the shipped tasks are not getting
> displayed during the default installation.
>
> In #846002, the Technical Committee was asked by Holger Levsen to rule on the
> priority of the blends-tasks package.  In the discussion that followed, the
> Committee was asked by Ole Streicher to additionally rule on whether the 
> Blends
> selection should be part of the Debian Stretch installer and who should 
> maintain
> the list of options displayed to the user in the future.
>
> Using the power of the Technical Committee to make a decision when asked to do
> so (§6.1.3):
>
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer 
> maintainers.
>
> 2. In the Committee's opinion the use of important priority is not appropriate
> for the blends-tasks package according to the definition in the Debian policy
> (§2.5).  As it was set only as a means to an end, and since it no longer does
> what was intended, we recommend that this change gets reverted.
>
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and popular
> package selections through the debian-installer in future releases.
>
>  END OF RESOLUTION 
>
> Please vote [A] for acknowledging that this is under the jurisdiction of the
> debian-installer maintainers, and [FD] for Further Discussion.

Since I feel a conflict of interest due to being a D-I team member,
I'll abstain.

If that's unhelpful for some reason, feel free to record my vote as:

  A == FD

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

...
>>> The TC has the power to decide here, and you were asked to do so. If you
>>> think that d-i took the right decision, you should decide so (and then
>>> you don't need to use your power), but not just let them decide.
>> 
>> That's what the current ballot effectively says.  We're refusing to
>> override the d-i team.
>
> No, this is a difference. I asked to decide whether the blends menu
> should go into the installer (in one or the other way), questioning the
> decision of d-i, and you (resp. those who select "A > FD") delegate the
> question back to d-i, without having a detailed technical discussion.
> Ian made the point here, IMO, and I wonder a bit why his critics remains
> unanswered.

I think this is in part a symptom of mixing up multiple questions in one
request.

There seems to be a consensus that the priority change was misguided,
and that's the thing that is primarily being decided here.

If I had had more time in the last month, I'd have put some work into
producing and testing a patch to tasksel to get the blends back in
without the priority changes.  Sadly I've not had that time, and I
suspect that we're too late for such things now.

Personally I think that Cyril's patch to strip out the blends-tasks
tasks was also a mistake -- hopefully we can now revert both the
priority change, and that reaction to it.

I do have time now, so perhaps while we're reverting those changes Cyril
will be open to persuasion that we could also patch the blends back in,
and make the menu clearer overall using my early suggestion of prefixing
the title lines with ===, but I'm certainly not willing to try and force
that decision on him with my TC stick.

The reason I've been mostly quiet on this subject is that I feel like I
have something of a conflict of interest, also being a (mostly lapsed)
D-I team member, so I've been restricting myself to attempting to
propose possible solutions.

I don't know why anyone else didn't respond to Ian's criticism, but for
my part I didn't think it was even slightly helpful for him to be in
effect pushing me further towards the conflict of interest that I'm
attempting to avoid.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Philip Hands]

Sam Hartman <hartm...@debian.org> writes:

>>>>>> "Josh" == Josh Triplett <j...@joshtriplett.org> writes:
>
> Josh> As another technical alternative, which I haven't seen
> Josh> mentioned elsewhere in this thread or related bug reports:
> Josh> when I need to override a packaged binary or file temporarily
> Josh> for debugging purposes, without forgetting to restore it
> Josh> later, I tend to use "mount --bind /my/replacement
> Josh> /usr/bin/foo".  For instance, for local testing while
> Josh> developing dh-cargo, which required a newer version of Cargo
> Josh> than packaged in Debian at the time, I built a local version
> Josh> of Cargo and did "mount --bind ~/src/cargo/target/debug/cargo
> Josh> /usr/bin/cargo".  That allowed me to easily test-build
> Josh> packages before the availability of a Debian package of a
> Josh> sufficiently new Cargo.
>
> O, cool, that's really need.
>
> And as a throw-back to an alternate Plan9 history, you could presumably
> unshare your mount namespace and even do that for a subset of the
> processes on a system, getting almost all the benefits of PATH.

I stumbled across 'proot' while looking into the background for this,
which seems to be able to provide the effect of a bind mount without
needing root privilege, and would presumably deal with Ian's original
problem quite nicely.

It's currently broken in stretch though (#847292).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Cyril Brulebois <k...@debian.org> writes:

> Philip Hands <p...@hands.com> (2016-12-24):
>> OK, this is tiresome -- you're complaining about question marks when I
>> was still exploring the options and looking for feedback -- I could
>> instead have been definite about an earlier option, but that would
>> have deprived you of choices, and would not have resulted in a patch
>> as good as it is now.
>> 
>> Please don't punish me for being open about my feelings on the various
>> commits because if you do that you'll reap the whirlwind when people
>> start lying to you to get past your superficial metrics.
>
> My initial comments weren't about those.

I've no idea what you mean by that sentence really, but it's possible
that it renders the rest of this mail totally irrelevant, so feel free
to clarify in that case.

> But they indeed add up with
> what I mentioned earlier, and this tends to confirm that december,
> with a freeze already started, is just not the right time to start
> exploring options.
>
> Sorry, but my mind is made up here: it's just too late (1) to change
> tasksel entirely, (2) to require translation updates we're already not
> getting in time, be it for screens, and for the installation guide.
>
> I'll stop repeating myself here, and start enjoying festivities.

Just in case there was any doubt, I have no problem with the decision
that this is all too late -- it was clear that might well be the outcome
when I started this, so I'm not surprised.

I was just concerned that you might be basing that decision on some
false perceptions.

Now that I've had chance to check, it seems that there was just one
commit with a question mark in the commit message:

  "move the task lists into the template (to make it preseedable?)"
  http://deb.li/3maqd

which was only there to remind me to check if I could find a way of
preseeding the Choices-C: value (seems not, BTW).

It also happens to be the commit where the '; then' was missing (which I
guess would be the obvious syntax errors you mention).

Perhaps you saw that commit being present from 09:28 on Dec 20th and
only being fixed at 22:07 on Dec 22nd and thought I was being totally
rubbish.

In fact, the reason I pushed that on the morning of the 20th was because
I knew I was going to be busy all day and wanted jenkins to also be busy
testing for me while I was out.

Of course, when I came back, I discovered that by then d-i FTBFS because
of the dejavu rename, so then I spent some time fixing that (leaving the
broken commit in place even longer).

So, if you are judging this negatively on the basis of that commit, then
you are failing to understand that the reason you saw that commit was
because I was attempting to get jenkins to do some testing for me while
I didn't have time to do it myself -- which is rather the point of
jenkins.

The reason it stayed there so long unfixed with its question mark was
because of the dejavu rename FTBFS.

I do not point this out in an attempt to change your decision in this
particular case, but rather to point out that it makes little sense to
be overly judgemental about such a commit.

The reason I've been putting effort into jenkins is so that people
(myself in particular) should be able to throw commits at jenkins and
have them tested without worrying too much about whether they are
perfect.  The hope being that this would lower the bar for contributions
by letting people play in safety while getting decent feedback about
whether their efforts were producing viable results.

Frowning at people when they then use that system for its designed
purpose seems just a tad counter productive.

Anyway, no hard feelings, and I hope you're having fun :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Cyril Brulebois <k...@debian.org> writes:

> Raphael Hertzog <hert...@debian.org> (2016-12-24):
>> I would suggest to commit this to git, do a call for translators to
>> update this new translation and then judge on the result to see if you
>> have enough translations to release it for stretch.
>> 
>> I know it's late in the release cycle, but we're not yet in deep
>> freeze and the release team has always accomodated far more invasive
>> changes to debian-installer in the past.
>
> I've already explained why this wasn't a reasonable approach in earlier
> mails over the past few days. I'm fine with asking the release team to
> accomodate for changes which are needed, but those don't qualify. Heck,
> we had obvious syntax issues in bash scripts in earlier commits, plenty
> of question marks

OK, this is tiresome -- you're complaining about question marks when I
was still exploring the options and looking for feedback -- I could
instead have been definite about an earlier option, but that would have
deprived you of choices, and would not have resulted in a patch as good
as it is now.

Please don't punish me for being open about my feelings on the various
commits because if you do that you'll reap the whirlwind when people
start lying to you to get past your superficial metrics.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Philip Hands <p...@hands.com> writes:

> Steve McIntyre <st...@einval.com> writes:
>
>> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>>Raphael Hertzog <hert...@debian.org> writes:
>>>...
>>>> So I agree with Cyril and the d-i team, we should be cautious here.
>>>>
>>>> Let's focus everybody's energy on getting Phil's patch merged instead
>>>> of continuing this discussion.
>>>
>>>The latest incarnation of which I think is close to ready:
>>>
>>>  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel
>>>
>>>I've squashed the commits together, so we now have the first (aae3196)
>>>which implements the feature, and would probably be fine as it is (once
>>>comments to the translators have been added as appropriate).
>>>
>>>The second commit (1bb1feb) adds a level of indirection in the
>>>template, with code to populate it from some new debconf settings,
>>>which allows one to then customise the menu via preseeding.  This is not
>>>in any way essential to the task in hand, but might well be useful for
>>>others.
>>
>> I'll be honest - that code scares me right now. If this was simple,
>> obvious stuff then I'd be pushing to try and get this in. But it's
>> not. Comments like
>>
>> +   # there is no need to do  this twice, and it breaks [back] behaviour 
>> if you do
>>
>> don't help, and I honestly don't understand what
>
> Fair point, and actually the code that comment applies to is only useful
> when 'db_capb backup' is enabled, which for complicated reasons[0] it is
> not at present, so I should just comment the lot out to avoid doubt.

So, for simplicity, we should just consider this version:

  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel2

I've left the fixup separate to make it easy to see that I've really
just removed the redundant if, and added some more verbose comments.

The commits in this branch should be squashed together if they ever get
into master.

The resulting code is here:

  
https://anonscm.debian.org/cgit/d-i/pkgsel.git/tree/debian/postinst?h=pu/simple_tasksel2=3739e72f563f86a4a2cf539361c791520b96fa86#n49

HTH

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Steve McIntyre <st...@einval.com> writes:

> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>Raphael Hertzog <hert...@debian.org> writes:
>>...
>>> So I agree with Cyril and the d-i team, we should be cautious here.
>>>
>>> Let's focus everybody's energy on getting Phil's patch merged instead
>>> of continuing this discussion.
>>
>>The latest incarnation of which I think is close to ready:
>>
>>  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel
>>
>>I've squashed the commits together, so we now have the first (aae3196)
>>which implements the feature, and would probably be fine as it is (once
>>comments to the translators have been added as appropriate).
>>
>>The second commit (1bb1feb) adds a level of indirection in the
>>template, with code to populate it from some new debconf settings,
>>which allows one to then customise the menu via preseeding.  This is not
>>in any way essential to the task in hand, but might well be useful for
>>others.
>
> I'll be honest - that code scares me right now. If this was simple,
> obvious stuff then I'd be pushing to try and get this in. But it's
> not. Comments like
>
> +   # there is no need to do  this twice, and it breaks [back] behaviour 
> if you do
>
> don't help, and I honestly don't understand what

Fair point, and actually the code that comment applies to is only useful
when 'db_capb backup' is enabled, which for complicated reasons[0] it is
not at present, so I should just comment the lot out to avoid doubt.

> +   db_subst pkgsel/simplified-tasksel $(echo $i | tr 
> "a-z" "A-Z") "$subst"
>
> is doing when I read the code at 2am. Can you explain this better
> please?

The template that's going to present the question to the user, is this:

=-=-=-=-
Template: pkgsel/simplified-tasksel
Type: select
Choices-C: ${CHOICES-C}
Choices: ${CHOICES}
Description: Choose type of system to install
 ${LONGDESC}
=-=-=-=-

so the loop you're looking at:

=-=-=-=-
for i in choices choices-c longdesc ; do
db_get pkgsel/simplified-tasksel/$i
local subst=$(echo $RET | sed "s#[$]{DESKTOP}#$desktop#g")
db_subst pkgsel/simplified-tasksel $(echo $i | tr "a-z" "A-Z") "$subst"
done
=-=-=-=-

does the following for each of the template variables.

 . Get the preseedable default value using db_get
 . substitute any occurrences of ${DESKTOP} with the current value of
   $desktop (so gnome unless you preseeded a different desktop)
 . do the actual substitution, which currently needs the variable name to
   be uppercased

I could make that rather simpler by naming the preseedable defaults with
uppercase names (e.g. pkgsel/simplified-tasksel/CHOICES) and uppercasing
everywhere, which would eliminate the need to do the tr.

Alternatively one could use lowercase variables in the template to get
the same effect (I didn't do that, to avoid confusing translators who
will be used to upper-case)

Anyway, it's far from clear that this code is needed, and if the extra
complication is a barrier, let's forget the preseedability aspect, and
simply concentrate on the first patch.

> To make this kind of change for stretch, we'll also need updates to
> translations directly in the installer and in the installation
> guide. I'm worried that we're doing this too late in the cycle - as
> KiBi says.

I agree.  This is the wrong time to be doing this.  If I'd had time
earlier in the cycle, I might well have done something about it then,
but ... kids, basically ;-)

Given that we're starting from where we're at, we seem to have a choice
of either adding translatable strings at this late stage, or dumping the
blends for another cycle -- neither option is perfect.

I happen to think that what I've knocked up results in a better user
experience, but then I never liked tasksel and almost never use the
defaults it presents, so I'm not really the target audience for this.

Cheers, Phil.

[0] I was trying to make it so that tasksel would have a [BACK] button,
and one could thus go:

  Oh, I wonder what "other use cases" means ...

  Argh! My eyes!

  [BACK]

  Phew! That's better, I'll have a Desktop in that case.

If you do that, and you allow the db_subst bit to be executed a second
time, it breaks, hence the:

  if [ -z "$desk_subst" ] ; then
 ...
 desk_subst=true

code.

However this all turns out to be irrelevant because the 'db_go' in here:

  https://anonscm.debian.org/cgit/tasksel/tasksel.git/tree/tasksel-debconf

where is says "intentionally unguarded" and _should_ cause the script to
abort (because of set -e) with an error code of 30 if one selects
"BACK", doesn't.

It always returns 0, regardless.

So you n

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Raphael Hertzog <hert...@debian.org> writes:
...
> So I agree with Cyril and the d-i team, we should be cautious here.
>
> Let's focus everybody's energy on getting Phil's patch merged instead
> of continuing this discussion.

The latest incarnation of which I think is close to ready:

  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel

I've squashed the commits together, so we now have the first (aae3196)
which implements the feature, and would probably be fine as it is (once
comments to the translators have been added as appropriate).

The second commit (1bb1feb) adds a level of indirection in the
template, with code to populate it from some new debconf settings,
which allows one to then customise the menu via preseeding.  This is not
in any way essential to the task in hand, but might well be useful for
others.

I have tested this, with these preseed settings, and it does what one
would hope (adding "Minimal system..." as a third option):

d-i pkgsel/simplified-tasksel/choices string standard ("${DESKTOP}") desktop, 
standard server [text-only console & 'ssh' remote access], Minimal system (adds 
no more packages), other use cases
d-i pkgsel/simplified-tasksel/choices-c string ${DESKTOP}-desktop;standard, 
ssh-server;standard, ;;, ;
d-i pkgsel/simplified-tasksel/longdesc string You can now choose between 
installing a standard desktop, a standard server, a minimal system, or 
alternatively to use the task selection menu to have finer grained control over 
installing tasks and blends.

The use of ; and ;; in the choices-c needs documenting -- ; is being
used as a separator for the tasks to be selected.  A lone ';' is being
used as a marker for the "continue to tasksel" case.  ';;' does not
match that, so converts to selecting no tasks -- I suspect leaving it
blank would work just as well, but have not tried that yet.

If anyone knows how to set choices-c via preseeding, then we might not
need (all of) the second commit.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Wouter Verhelst writes ("Bug#846002: blends-tasks must not be 
> priority:important (was Re: Bug#846002: Lowering severity)"):
>> On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
>> > How about one or both of:
>> > 
>> >   bare-bones -- nothing selected
>> >   minimal-server -- ssh and nothing else
>> > 
>> > Is there any objective way of working out what other combinations would
>> > be popular, rather than just guessing?
>> 
>> Note that the whole point of tasksel was, originally, to show just that.
>> Things have simply gotten out of hand.
>> 
>> If you're going to update tasksel, it might be good to keep that in
>> mind...
>
> Quite.  I thought Phil's original suggestion
>
>   -->  standard desktop (will install $DESKTOP)  <--
>standard server  (includes ssh)
>other use cases
>
> was good but perhaps even too long.  Anyone who wants anything ommore
> complicated can cope with tasksel.  Even someone who wants a server
> can very likely cope with tasksel.

Fair enough -- although I think it's quite good to include at least one
not-a-desktop option because it helps define what we mean by desktop.

People coming from windows are probably used to servers having a GUI,
for instance, so its probably worth mentioning that we mean that a
server won't have a GUI by default.  Of course finding a few words to
expres that in a way that's understandable to someone who's not sure
what "Desktop" is supposed to mean is not so easy.

BTW I've updated my menu hack -- it now is replacing the pkgsel.postinst
so is a much better representation of how things should work.

I tried to get the back button in tasksel to send you back to my
simple_tasksel menu, but weirdly tasksel seems not to return 10, as it
should, when you hit back.  That seems to be because the db_go inside
tasksel is not returning 30, as it should, which is very odd.  Perhaps
that's something to do with the fact that tasksel is running in the
chroot, but it should still be talking to the same debconf front end, so
I don't quite get haw that can go wrong -- the code that does all this
has not been touched in years, and I guess it worked when Joey wrote
it. Very odd.

Anyway, because of that, I've disabled the back button for now.

The menu is now:

--> standard ("${DESKTOP}") desktop   <--
standard server [text-only console & 'ssh' remote access]
other use cases

I get the feeling that the 'standard' is pretty redundant, but just
'desktop' and 'server' seems wrong too.

I'm tempted to make the third option "All Other Routes" (or whatever the
locale has on it's road signs to indicate that you're heading out of
town)

Have a play and tell me what you think -- should work with any recent
media and adding:  url=hands.com/d-i/d-i/bug/846002/preseed.cfg

The code lurks here: 
http://git.hands.com/?p=hands-off.git;a%3Dshortlog;h%3Drefs/heads/new-unified3

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

> Hi Phil,
>
> On 10.12.2016 01:03, Philip Hands wrote:
>> Just to test things out, if one adds:
>> 
>>   url=hands.com/d-i/bug/846002/preseed.cfg
>> 
>> to the kernel command line (so, hitting TAB as the installer's boot menu)
>> it will tweaks d-i to have such a menu.
>
> To me, this looks like a very nice solution! In the tasksel screen, the
> "back" button was enabled for the first time, but produced an error and
> brought me back to the list of installation steps.
>
> Going through the sofware selection a second time made the back button
> disappear. I have absolutely no experience with preseeding, so I can't
> test it more than the interactive use case.

Thanks for testing that, and don't worry about the preseeding bit.
It's far from straight-forward, even for people that know what they're
doing.

I agree that the back buttons don't work (and should do, so that one can
glance at tasksel and realise that you should bail out and select a
simple option).

I think it will need to be put into the scripts in tasksel itself to fix
that, which will also remove the bits of the script that I'm unhapy
about anyway (chrooting to set preseeds).

That being the case, there's not much point testing with preseeding, as
it's not going to be implemented like this, so this should just be
considered a demonstration for now.

Anyway, having done it, my first impression (which I'm surprised by) is
that the list is too short -- I think that it is perhaps because it is
much easier to select one option from a list than it is to decide what
combination of options one wants.

How about one or both of:

  bare-bones -- nothing selected
  minimal-server -- ssh and nothing else

Is there any objective way of working out what other combinations would
be popular, rather than just guessing?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

> On 09.12.2016 08:37, Philip Hands wrote:
>>> On Wed, 07 Dec 2016, Philip Hands wrote:
>>>> It could be much improved by making it more obvious that the heading is
>>>> a heading.  Even if we're unable to stop headings having a checkbox, we
>>>> could change the text and the hierarchy slightly to be something like
>>>> this:
>>>>
>>>>[ ]  === Debian Desktop Environments:
>>>>[x]  ... Gnome
>>> [...]
>>>> Would that cheer people up without needing a major rewrite of tasksel?
>
> This improves the situation, and could probably done quite simple at the
> same place where the ellipsis (...) is introduced:
>
> https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366
>
> One just needs to find out here that it is actually a heading.
>
>> I think that should be a select, rather than a multi-select:
>> 
>>  -->  standard desktop (will install $DESKTOP)  <--
>>   standard server  (includes ssh)
>>   other use cases
>> 
>> (or however the UI presents it)
>> 
>> The reason for the extra bits in brackets is that I've always thought
>> the tasksel menu was hiding just a little too much of what was meant by
>> the options.
>
> I would vote for that, however we would need
>
> 1. someone willing *and* competent (the latter excludes myself) to
> implement this in tasksel,

Just to test things out, if one adds:

  url=hands.com/d-i/bug/846002/preseed.cfg

to the kernel command line (so, hitting TAB as the installer's boot menu)
it will tweaks d-i to have such a menu.

I suspect that the way it works could be improved (it could probably be
plumbed into tasksel itself) but it seems to do the trick, and should
let people have a play and give feedback without needing to create new
.iso images.

I've tried it interactively, but not yet with preseeding, which will
need either this to be changed to chain into your preseed, or vice versa
(if you can work out how, feel free to give that a try and see if you
can find what it breaks :-) ).

The files that do the trick are here:  http://hands.com/d-i/bug/846002/

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Philip Hands]

Hi Shigio,

Thanks for getting involved.

Shigio YAMAGUCHI <shi...@gnu.org> writes:

> Hello all,
>
> 2016 23:32:44 +1030, Ron wrote:
>> open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern |");
>>
>> Which for those who don't speak it, is perl for "anyone can execute
>> arbitrary shell commands by typing them into a web browser", since
>> $pattern is an unsanitised, untrusted, input from the query string.
>
> This code is for Windows; it is not used in UNIX.
> Ron's quotation seems to be part of the following code:
>
> --
> [global.cgi.tmpl.in] (global-6.5.2)
> --
> if ($^O eq 'MSWin32') {
> open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern
> |");
> } else {
> open(PIPE, "-|") || exec '@globalpath@', '--result=ctags-xid',
> $flags, $pattern;

Is it not the case that this last line forks and execs global, passing
$pattern as a parameter to global's -e option, and that $pattern is
untrusted input?

Looking at global.c it seems that before it is passed on to popen, it is
run through quote_shell() which quotes any single-quotes in the string.

That seems to deal with Ron's assertion that it's exploitable, although
I have a slight feeling of impending doom about relying upon just this.

Would it not be wise to make the network-facing perl code runnable with
strict and taint turned on, if only to stop people reacting with horror
at first glance?

I presume patches would be welcome?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Raphael Hertzog <hert...@debian.org> writes:

> So I have been following this whole discussion and I would like to
> provide my input to Ole and the blends team.
>
> - adding a new important package to work-around the fact that tasksel
>   maintainers were busy/inactive was not a good move. As you all
>   noted, the list of blends does not change often enough to warrant
>   separate maintenance. And by doing that you circumvented the
>   review by the debian-installer team which clearly has made design
>   choices to keep the installer simple.
>
> - the tasksel list with or without the blends already grew and can be
>   confusing for new users, it should not be shown by default but should
>   be offered as an option in all cases. See below for my suggestion.
>
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...
>
> I'm thus suggesting that blends-tasks should be removed and merged in
> tasksel-data. At the same time, we should fix the installer to bypass
> that confusing tasksel screen that we always get by default.
>
> On Wed, 07 Dec 2016, Philip Hands wrote:
>> It could be much improved by making it more obvious that the heading is
>> a heading.  Even if we're unable to stop headings having a checkbox, we
>> could change the text and the hierarchy slightly to be something like
>> this:
>> 
>>  [ ]  === Debian Desktop Environments:
>>  [x]  ... Gnome
> [...]
>> Would that cheer people up without needing a major rewrite of tasksel?
>
> That would be a good change, yes.
>
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
>
> Install packages for a:
>
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options

I think that should be a select, rather than a multi-select:

 -->  standard desktop (will install $DESKTOP)  <--
  standard server  (includes ssh)
  other use cases

(or however the UI presents it)

The reason for the extra bits in brackets is that I've always thought
the tasksel menu was hiding just a little too much of what was meant by
the options.

The reason to use "other use cases" is that eventually I think that
option should take you to a blends menu, where the first blend could be
a fake custom ("Custom selection of tasks" or similar) blend that drops
you into tasksel.  For now the tasksel menu as it stands will clearly do
the job, and will require least work if left alone.

I think it's better to drop the minimal server option at this level as
people wanting that probably know what they're doing, and will quite
often be preseeding anyway.

In the end, I think it might be worth treating desktop and server as
blends too, to make the logic less messy, but that's probably something
to look into after stretch.

I would hope to have time to work on this -- once I stop running a
temperature with the cold that currently has me sitting in bed.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

> On 08.12.2016 09:33, Wouter Verhelst wrote:
>> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>>> But it also gives a wrong sign: Debian Pure Blends are by definition
>>> integral part of Debian itself. But even now, this is hard to understand
>>> for many people -- questions like "what is the difference between Debian
>>> Astro and Debian" are quite common, even in front of a poster describing
>>> exactly that. With having separate official images for all blends,
>>> people would even be more confused. As an example, I would take the
>>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>>> installation options -- people usually think that they have to
>>> re-install the system if they want to switch from one flavour to the
>>> other. Having similar experience with Debian would be bad for the
>>> reputation of the Blends, and for Debian in general.
>> 
>> I don't agree with this argument.
>> 
>> Yes, indeed, in Ubuntu people often don't know that they don't really
>> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
>> that really a problem?
>
> Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
> that [KXG]Ubuntu is not different from Ubuntu except for the package
> selection. I don't know how important it is for them to keep the unity
> -- maybe they don't care here much.
>
> But for Debian Pure Blends, it is important to have it clear that the
> Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
> infrastructure to do something else -- we are an integrated part.

On reflection, I agree wholeheartedly, and probably should not have
revisited the specialised CDs as an idea.  Sorry about that.

It would be depressing if Astrophysicists who used Debian-astro at work
were confused into downloading again because they fancy playing some
games at home, when the only difference between the images would be
about 5 bytes of preseed setting.

That said, it would probably be nice to make it trivially easy to set
downloaded media to default to e.g. debian-astro at the user's
preference, so that someone could do that and hand the result to a
colleague, saying "Just install that".  That's not the same thing as
publishing them like that though.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

> Hi Philip,
>
> On 06.12.2016 20:43, Philip Hands wrote:
>> Could we serve their needs with an extra debian-installer/blend 
>> preseed to deal with this, probably aliased as just 'blend' so that 
>> one could type something like:
>> 
>> blend=med
>> 
>> when booting the default media to get the desired result?
>
> I think this is really unergonomic, since people need to understand or
> remember installer boot time options. Boot prompt options are magic for
> many users, and they need to read the documentation to get this.
>
> And it is not recoverable: imagine that someone forgets to put it there
> or made a typo, he cannot go back and change this -- he has to go
> through the full installation process again.
>
> And it does not really *present* the blends to the user; he already
> needs to know what is there.
>
>> If we then made the ISOs easy to tweak, so that the default option
>> on the Debian-Med ISOs included blend=med on the command line by 
>> default, would that actually be better than what we have, and also 
>> allow us to drop the problematic tasksel items?
>
> Since I already answered this, I hope it is OK to just copy my old
> argument here:
>
> I am not convinced that it is a good solution: First, it multiplies the
> whole image creation process by the number of blends.

That's not what I had in mind -- if we make the images trivially
tunable, then one only actually needs to generate one image.  The
offering of specialised images could also be optimised by doing the edit
on the fly in the webserver.

It would certainly be a waste space on dumb mirror servers though.

> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

That's a very good point.  Fair enough.

Perhaps we need an aditional option at the boot prompt for a vanilla
install, that sets priority=critical or some such, so that one gets the
equivalent of hitting return thoughout the installer, and only get
prompted for the user & passwords, the point at which you're going to
trash your disk, and not much else.

That would deal with the case of people that might be upset by too much
choice, and then having more choice of blends would be less of an issue.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

...
> Fully Ack. I see the current solution to integrate the Blends in Stretch
> as a compromise for Stretch only; afterwards we should look to rewrite
> tasksel for a better scalability.

I think the current list of three is not much worse than it already was.

It could be much improved by making it more obvious that the heading is
a heading.  Even if we're unable to stop headings having a checkbox, we
could change the text and the hierarchy slightly to be something like
this:

[ ]  === Debian Desktop Environments:
[x]  ... Gnome
[ ]  ... Xfce
[ ]  ... KDE
[ ]  ... Cinnamon
[ ]  ... MATE
[ ]  ... LXDE
[ ]  ... LXQt
[ ]  === Common tasks:
[ ]  ... web server
[ ]  ... SSH server
[x]  ... standard system utilities
[ ]  === Special tasks (a.k.a Blends):
[ ]  ... astronomy (Debian Astro)
[ ]  ... games and fun (Debian Games)
[ ]  ... life sciences and medicine (Debian Med)

That looses the (apparently useless) print server, to avoid making the
menu any longer, and uses the line for another header (suggestions for a
better name welcome).

It also explicitly rather than implicitly selects Gnome so it's obvious
what we mean.

The desktop= preseed might be broken by that, but I suspect that it's
already broken from my recent test (I need to confirm that), so we
should probably make sure that that works and then make sure that it
also works for one to specify e.g. desktop=kde and have KDE selected by
default in this menu in that case.

I don't know how well speakup, or the other UIs might deal with '==='.

Would that cheer people up without needing a major rewrite of tasksel?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Andreas Tille <andr...@fam-tille.de> writes:

> Hi Bdale,
>
> On Tue, 06 Dec 2016 08:10:37 -0700 Bdale Garbee wrote:
>> the first piece of advice I give most new-to-Debian users I'm helping out
>> personally is to just ignore the concept of tasks and pick software they
>> actually want on their system.
>
> To solve this very problem we actually invented the tasks in Blends:  It
> simply helps picking the software users want on their system without
> browsing the n (insert number of binary packages here) descriptions
> using tools a newcomer is not even aware about.
>
> I'm aware that the target user group I have in mind and who thanked me
> for the easy way to install their packages is quite small amongst all
> users of Debian.  On the other hand Debian is quite popular in this
> target user group compared to other distributions and this is because we
> provide explicit care for this user group.

Could we serve their needs with an extra debian-installer/blend preseed
to deal with this, probably aliased as just 'blend' so that one could
type something like:

  blend=med

when booting the default media to get the desired result?

If we then made the ISOs easy to tweak, so that the default option
on the Debian-Med ISOs included blend=med on the command line by
default, would that actually be better than what we have, and also allow
us to drop the problematic tasksel items?

By easy to tweak, I mean making sure that there's enough room in the
menu files so that one could edit the ISO file directly and populate the
blend=... setting somehow.

Failing that, it's definitely possible to rebuild the images, and also
tell people about typing TAB and the 'blend=...' bit if they want to
install using standard Debian media.

I don't think that would take much to implement, and would not be adding
translatable strings to d-i, so might even be possible to do for stretch
(well, the preseed bit anyway)

If that scratches the itch, we could then drop the extra stuff from the
tasksel menu.

It also occurs to me that if we make sure that the handling of
debian-installer/blend were able to deal with pulling in extra udebs, as
one would need to in order to deal with blend=edu, one could have a new
udeb for asking about all the blends we know about, and pull that in
with something like blend=blends -- then if someone wants to be
presented with a vast menu of blends to choose from that can be done
without annoying normal users.

There could be an option for "Prompt me for all blends" in the Advanced
Menu, or we could just expect people to type blend=blends and/or produce
a "Blend-tastic!" variant of the install media.

If there's a real use case for mixing multiple blends, one could
separate them with ; as we do elsewhere, so:

  blend=med;ham;games

(we might want to call it 'blends' in that case, but I think that might
be over-complicating things)

Does that sound like it might be worth looking into?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher <oleb...@debian.org> writes:

> On 06.12.2016 10:37, Holger Levsen wrote:
>> And this *is* still pretty confusing, though admitly better than it was
>> half a year ago. 
>
> The current implementation has a popcon of >5000, without a single
> complaint or confusion documented in the web within the last six months.
> This is at least *some* empirical evidence that it is not "pretty
> confusing", and again I would ask you to show any better empirical data
> here to support your own point.

You seem to be mixing up two things here.

Holger was saying that the menu is confusing (as am I).

You're saying that because 5000 people seem to have ended up with this
package on their systems, they were not confused.

Looking at the graph for debian-astro, is seems to follow a similar
curve, so perhaps these are the people that are installing the
blends-tasks (BTW is there an easy way to check which packages are
installed together via popcon?)

There is no need for them to tick the 'Special tasks' menu item in order
to install any of the the blends, so to some tiny extent they were
confused when they did that, were they not?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Sam Hartman <hartm...@debian.org> writes:

> So, what impact does having blends-tasks have besides wasting disk
> space.
> It adds tasks to the installer menu.  Are those tasks we want on all
> system installs or not?
> If this is purely about disk space, I think it's less of an issue than
> if it provides a bad user experience.

It makes the "what do you want to install?" menu slightly worse by
introducing some more befuddling options to it.  It was already dire
though.

Before this you'd be confronted with (I'll type the text version, so
people don't need to follow links to screenshots -- please forgive
typos):

   [x]  Debian Desktop Environment
   [ ]  ... Gnome
   [ ]  ... Xfce
   [ ]  ... KDE
   [ ]  ... Cinnamon
   [ ]  ... MATE
   [ ]  ... LXDE
   [ ]  ... LXQt
   [ ]  web server
   [x]  print server
   [ ]  SSH server
   [x]  standard system utilities

So, this was already a disaster area:

  What does selecting Debian Desktop Environment, but none of the
  desktops do (it gives you Gnome, but there's no real hint here)

  How about if you deselect Debian Desktop Environment, and select Gnome
  and KDE?  (the desktop tasks all depend on task-desktop, so you get it
  anyway AFAIK, but that's not the impression given).

  What is a print server? (CUPS) web server? (apache2)

  What do you get if you install without the standard system utilities,
  does that still hold if you install a full desktop?

  Are we really expecting the people that we feel we must protect from
  package names by hiding the fact that we're talking about CUPS and
  Apache to know what LXQt is?

After adding the blends, that becomes this (having just used the daily
mini.iso downloaded this morning):

   [x]  Debian Desktop Environment
   [ ]  ... Gnome
   [ ]  ... Xfce
   [ ]  ... KDE
   [ ]  ... Cinnamon
   [ ]  ... MATE
   [ ]  ... LXDE
   [ ]  ... LXQt
   [ ]  web server
   [x]  print server
   [ ]  SSH server
   [x]  standard system utilities
   [ ]  Special tasks
   [ ]  ... astronomy (Debian Astro)
   [ ]  ... games and fun (Debian Games)
   [ ]  ... life sciences and medicine (Debian Med)

so that then prompts one to wonder:

  what the hell is "Special tasks" and what will I get if I select it?

  Do I need to select that to get Debian Med, say?
(no, it's just an empty header AFAIK)

it also buries the 'standard system utilities' item in the middle of
the list, where it makes even less sense than it did at the end.

So, I'd say that the whole thing was a car-crash anyway, and this just
dropped a cigarette in the spilling petrol.

The real problem is that there's not been the effort available in the
d-i team to come up with some better way of presenting the question.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Philip Hands]

Ron <r...@debian.org> writes:

...
> I'm not insisting that's what we should do.  But it's certainly an
> option, and it dodges the bullet of having to say "Sucks to be you"
> without any notice at all.  And it doesn't take anything away from
> the people who want "new upstream or bust" for Stretch, because it
> can still be available to them in backports.

Perhaps you'd be kind enough to either confirm or correct my perceptions
of the current situation:

  Version 6 includes a CGI script that one is expected to install in a
  manner so hopelessly insecure that we'd not accept it in Debian.

  However, it is possible to generate static content that achieves the
  same aims, but at the cost of approximately doubling the disk usage,
  and presumably also requiring more time to generate.

  Also, for people that want personal access to htags there is a
  htags-server command that brings up a dedicated server to run the CGI
  as the invoking user, by default bound to a localhost port.

  Version 6 fixes some bugs that are still present in your version 5
  package and/or provides features that are missing, but bug reports of
  sufficient quality to allow you to fix/backport to v5 are lacking.

Is that about right?

Are there any other regressions that you are aware of in v6?

Your suggestion, as I understand it, is that v6 should hit unstable
after stretch's release, and that people who are currently complaining
about bugs/missing-features in v5 (or are overly focused on numbers) can
then grab v6 out of stretch-backports.

Could you consider the relative merits of instead putting v6 into
stretch now, and dealing with the people that are currently clinging to
v5 by pointing out that:

  0) there are now other alternatives to htags that might suit them better.

  1) htags-server lets them run the CGI for local access.

  2) htags can generate static content, and thus safely provide general
 access while avoiding the need for a CGI

  3) If there is anyone that cannot do either for some reason, they can
 install global v5 from jessie, pin it to avoid upgrades, and report
 the reasons why they had to do this to the BTS.

Have I missed some vital aspect of this?

Is there a compelling reason to favour the theoretical users that might
want to stick with v5 over the actual users that we've been hearing ask
for v6?

If the TC were to achieve consensus that v6 should be in stretch, will
it be sufficient for us to inform you of that in order to make it so?

I gather from what you just wrote that it would be sufficient.

If however you are likely to insist on resolutions to override the
maintainer, or transfer the maintainership, I think you ought to be
up-front about that in order to avoid any accusations of intentional
time-wasting later on.

If you can keep your answers brief, you'll earn my gratitude.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Maintainership

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> On debian-project I posted a suggestion in respose to Zach in the
> thread about maintaintainership.  See below.
>
> Do the TC think a resolution such as that below would pass ?
>
> Supposing such a resolution were passed, would it make a practical
> difference to how you approach petitioners and maintainers ?

I think I'd probably resign from the TC, since such a resolution would
be a vote of no confidence in our judgement.

I can understand that in general people looking in from the outside
might think that they could do a better job, but it seems pretty odd for
you to suffer from that delusion, given that you actually had this job
for the vast majority of the TCs existence, and as you've already
forcefully stated, failed to act even once in similar cases.

Now you're interfering just as we appear to be settling on a consensus.

I'm sure there must be something constructive for you to be getting on
with instead.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Philip Hands]

 good idea.
>
> Possibly something nifty with apache config scripts would work. Suggestions 
> welcome.
>
>> I don't know much about this, but several of these choices seem likely
>> to be plausible choices for many if not most current users of htags.
>
> Right. I think the functionality upstream provides is fine.

It strikes me that users are likely to fall into one of two groups:

  Local access by users that do not wish to offer remote access and are
  not offering accounts on the machine to untrusted people -- these
  users should be well served by htags-server.

  People offering remote access -- these people can just squander some
  disk space in order to avoid the questionable CGI setup.

I'm failing to be convinced that there is a significant userbase that
falls between these two stools.

If v6 goes into stretch, there will need to be a NEWS item about htmake
and htconfig going away -- that could also mention that, if desperate,
one can pin the old version of the package to retain those features.

The old package is what they'd be getting otherwise anyway, after all.

Anyone that decides that they need to stick with the old version could
thus be encouraged to report bugs describing their reasons for doing so,
which could then be handled by either making the v6 package satisfy
those needs, or by packaging v5 separately, or perhaps ... by doing
nothing if such bugs fail to materialise.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Philip Hands]

Ron <r...@debian.org> writes:

> Hi Marga,
>
> On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote:
>> > Philip Hands <p...@hands.com> writes:
>> > It seems like you are tempted to drop htags anyway now, so calling the
>> > version 6 package 'global' and adding the global5 package to give people
>> > an escape route seems like the right thing to do.
>> > 
>> > That also makes it much easier to detect when people cling to version 5,
>> > since there will only be intentional installations of that package.
>> 
>> I second this proposal by Phil.  It seems to me that this is the most 
>> reasonable
>> outcome, given the current situation. This means that global gets updated to 
>> the
>> latest version, with a NEWS message stating that htags functionality has been
>> removed and that users that care about htags should install global5 instead.
>> 
>> Ron, you haven't replied to this proposal yet. Can you state your opinion
>> regarding this?
>
> Did I mess up on the CC for that somehow?  Or was there something I
> didn't address about the question(s) of going this way in:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135
>
> I can try to clarify that if there's a question in your mind that
> you don't think I touched on there.

The question that remains is what you actually intend to do.

You went into some detail about why the existing popcon figures should
not be relied upon, which is fair enough but seems not to take account
of the fact that my suggestion was for you to create a new global5
package which would not be automatically pulled in by anything (unless
the maintainers of reverse dependencies decide that it's better to
switch to depending upon global5, which should probably be
strongly discouraged).

The popcon figures for global would then still be contaminated with
whatever dragged it in in the first place, but the figures for global5
would tell you the extent to which the userbase of the global5-only
features actually exists.

Either there are real users for those features, which might persuade you
that the effort of backporting features to global5 is justified -- in
that case the exit strategy would be for the patched global5 to be the
final inheritor of the 'global' package (in stretch+1 say, replacing
the v6 package once you have the relevant feature parity).

Alternatively, if very few people install global5, you can publish an
update that reminds people that the package is going away, and asking
them to tell you why they might be upset about that, and then you either
get useful feedback, or you can remove the package with a clear
conscience.

I would think that this is a strategy that would allow you to act.

Perhaps you can explain why you apparently think doing nothing
indefinitely is better for our users.

I am aware that there are subtleties here that I may have missed, so
please don't assume that I'm intentionally ignoring what you think of as
the obvious flaws with this idea.

I really don't mind being treated as an ignoramus.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Philip Hands]

Philip Hands <p...@hands.com> writes:

...
> How viable is it to have two conflicting packages:
>
>   global5: continuing as you have it now
>(perhaps with patches to make it work for recent use cases)
>
>   global6: (with htags support removed)

Ah, I see -- I had somehow got the impression that the first was already
called global5 from comments in the thread.  Given that it's actually
called 'global' I guess that adds an extra wrinkle.  Depending upon your
preference I would expect that you select one or other version to be the
inheritor of the global name.

It seems like you are tempted to drop htags anyway now, so calling the
version 6 package 'global' and adding the global5 package to give people
an escape route seems like the right thing to do.

That also makes it much easier to detect when people cling to version 5,
since there will only be intentional installations of that package.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Philip Hands]

Ron <r...@debian.org> writes:

...
> That's basically why "just nuke htags now" is starting to look like
> a viable, and even sensible, option.  But it's tricky to know who
> might be upset by that - and we don't have a clear idea of exactly
> what we'd really gain elsewhere from that tradeoff, since most of
> the people saying "I need a new upstream" haven't actually been
> telling us what the real problem is which that fixes, even when I
> asked.

This sounds like, if you were given enough feedback, you'd be willing to
fork this to keep the old functionality available, while servicing the
needs of users of new features -- is that right?

If that is the case, and having read the rest of what you've written, it
seems that the clamour for upgrading to the latest release is a symptom
of not paying sufficient attention to the messy details.

> It's quite possible that some of those would just need a trivial
> patch to what we currently have - but with these latest changes to
> htags, I am feeling more and more like the writing is on the wall
> for its ultimate demise now - even if upstream isn't accepting
> that yet.
>
>
> But I haven't forgotten the hatemail I got for finally killing off
> svgatextmode, a whole decade after its upstream declared it an
> obsolete solution, when kms finally made it impossible to keep it
> working - so I don't underestimate what some people might cling to.

How viable is it to have two conflicting packages:

  global5: continuing as you have it now
   (perhaps with patches to make it work for recent use cases)

  global6: (with htags support removed)

If you did that, and especially if you changed a config file to include
a note that the global5 package might go away in the next release (so
that most people will see that on upgrade) then you could provoke
the feedback you want, and perhaps also make judgements based on the way
popcon figures shift over time.

Would that work for you?  

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Vincent Bernat <ber...@debian.org> writes:

> [ Unknown signature status ]
>  ❦ 18 octobre 2016 23:01 +0200, Florian Weimer <f...@deneb.enyo.de> :
>
>>>> I think it's clear that the TC believes that this package is not DFSG
>>>> free.
>>>> I think it's clear that the TC believes perl would be better if the
>>>> situation was improved.
>>>> I thought it was clear we believed perl had a DFSG issue, although IRC
>>>> discussion today makes that less clear.
>>>> I don't think the value of having the TC formally say any of those
>>>> specific things is very high.
>>>>...
>>>
>>> Please describe the relevant differences between browserified javascript 
>>> and perl that make the TC believe that the former has a DFSG issue but 
>>> the latter probably has not, in a way that I can deduct what the TC 
>>> would believe regarding the similiar problem related to SQLite.
>>
>> Configure in Perl is a build tool, and appears amenable to manual
>> patching.
>>
>> Browserified Javascript is hardly human-editable, and it is shipped as
>> part of built packages.
>
> I don't think this is the debate. The debate is around pre-minified
> versions. Those versions are also human-editable and amenable to manual
> patching.

I dispute that there was anything like a useful debate, because all
attempts to discover what "browserified" is supposed to mean have been
ignored.  Despite that, this is still the term that continues to be used
to pose the question.

There may have been the appearance of a debate in the TC, but from my
point of view that was mostly pondering what conceivable meaning
"browserified" could have that might lead to one thinking that posing
these questions made any sense whatsoever.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

"Joseph R. Justice" <jayare...@gmail.com> writes:

> To all: Should Mr's Raboud's request for interpretation be expanded to
> include clarification on whether, and if so when and how, the TC can
> require some other delegate to take a particular action or actions,

This mail seems to be prompted by a series of seriously flawed assumptions:

  That one can force volunteers to do anything.

  That anyone on the TC would be foolish enough to try and tell any
  volunteer that they must do something that they are unwilling to do.

  That if we had more powers, and for some bizarre reason were willing
  to use them, that there is any chance of obtaining a 2/3 majority in
  favour of forcing source-less, buildtool-less packages into 'main'.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Adrian Bunk <b...@stusta.de> writes:

> On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
>>  ❦  5 octobre 2016 22:49 CEST, Philip Hands <p...@hands.com> :
>> 
>> > If you fancy explaining what you think browserified means w.r.t. the
>> > Jison stuff, go ahead of course.  That might at least help to focus the
>> > discussion a bit.  Just don't feel obliged to because I said so.
>> 
>> The libjs-handlebars issue has little to share with browserified
>> JS. Browserified JS is usually just concatenated JS. Here, there is an
>> equivalent of flex/bison involved. That's quite unusual and is more a
>> build process. If the TC rules over this issue, it should drop the
>> "browserified" part. Otherwise, a negative answer would also apply to
>> more basic packages.
>>...
>
> Why is Grunt such a blocker here?
>
> If I understand it correctly, Grunt is a powerful build system that can 
> do a gazillion different things and has many dependencies.
>
> For the basic browserified JS case, could a much simpler tool like
> node-browserify-lite produce the same output?

Sadly, it seems that's not as simple as one would hope -- see:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814871

and the referenced:

  https://gitlab.com/gitlab-org/gitlab-ce/issues/14450

which seem to illustrate the tangled mess we're talking about.

BTW I must applaud Praveen's tenacity, as exhibited in these bug logs,
while getting this stuff packaged, and I do understand that it must be
really frustrating to have been swimming upstream against this for so
long only for the result to still be deemed unfit for main.

That said, I think they really are unfit for 'main' at present. :-/

(in no small part because of the fragility that is highlighted by that
upstream bug log -- if we are not able to lock down the versions of all
the packages and tools in question, by packaging them, how is this sort
of thing ever going to be brought to a point of sanity?)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

b, only for it to be removed from Squeeze+1
when grunt proves to be unpackageable?  Temporoary exceptions to enter
main are not a good idea.

Cheers, Phil.

P.S. BTW Drawing comparisons with perl Configure may be intellectually
invigorating but does nothing to address the above mess.

With browserification, the dubious output ends up running on network
facing machines (both Debian servers, and their heterogeneous web
clients) so the attack surface is vast.  The code development is
fast-moving, and the people developing it are often unsympathetic to the
idea that one might not want to upgrade to their latest version.

Perl's Configure on the other hand is slow moving with changes quite
often being things like adding support for obscure hardware that we
don't even dream about supporting e.g.:

  
http://perl5.git.perl.org/perl.git/commitdiff/86ea01eb2de6e15e79ff54031d7fabfb5f628d4e#patch1

Also, this code is only run during the build process.

You'll also note that people are routinely developing upstream by
modifying that code directly.  I've found no evidence of that at all so
far when looking at browserified code.

Personally I'd prefer it if we could rebuild Configure in Debian, but
I'm not going to make that so myself.  Campaigning for perl to be
removed from Debian doesn't strike me as a worthwhile use of one's time.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Philip Hands <p...@hands.com> writes:

> Praveen, please respond to #830986

Actually, I withdraw that request -- I doubt replying there is going to
be a productive use of your time, and is probably not going to improve
your chances of getting what you want either.

If you fancy explaining what you think browserified means w.r.t. the
Jison stuff, go ahead of course.  That might at least help to focus the
discussion a bit.  Just don't feel obliged to because I said so.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Adrian Bunk <b...@stusta.de> writes:

> Why are TC members complaining that they do not even properly understand 
> what "browserified" means, instead of using the power to give advice to 
> structure the discussion?

Probably because without a response to #830986, "browserified" either
means including Jison output into things, or it cannot possibly cover
what's being done to libjs-handlebars, either of which makes the recent
bugs against tech-ctte and ftp-master just a little astonishing.

Praveen, please respond to #830986

Without such a response, I wasn't even sure if the re-opening of the bug
was instead an attempt to get some sort of permission to let the likes
of gitlab into main, by temporarily ignoring the non-free
dependencies. (I'm not suggesting that as a way forward BTW, but it
seemed at least as plausible as what was actually being asked)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Pirate Praveen <prav...@debian.org> writes:

> On 2016, ഒക്‌ടോബർ 3 8:22:20 AM IST, "Joseph R. Justice" <jayare...@gmail.com> 
> wrote:
>>If I have misunderstood in any way Mr. Praveen's position, or if I have
>>misrepresented in any fashion whatsoever what it is he is trying to
>>express, then I sincerely apologize for my error.
>>
>>Otherwise...  I hope this is of some use, interest, in resolving this
>>issue.  If it is, then I'm glad I could help.  Thanks for your time in
>>reading this.  Be well, and thanks for all of y'all's efforts in
>>creating
>>Debian!
>
> Thank you Joseph, that is a good summary of the situation.

I think you need to try a little harder than that -- it is still unclear
to me what you are even attempting to ask for.  Unless that changes I
would think that the right response to this is to simply close the bug.

As a bare minimum, try specifying what outcome you are hoping for, with
respect to which package.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

unblocking the policy update process

[Philip Hands]

Hi Didier,

You appear to have #action'ed yourself regarding this (judging from the
agenda to the meeting just past, that you could not attend) so perhaps
we can move things along by discussing it on the list (rather than
simply waiting till next month's meeting).

Perhaps you could describe a proposed plan of action, or what the rest
of us might be able to do to help -- or whatever else comes to mind :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#830344: Project Roadmap question - Call for votes

[Philip Hands]

Margarita Manterola <ma...@debian.org> writes:

> I'm a bit saddened by the lack of traction on this topic.
> We are holding other people's work back by our lack of involvement.
>
> Therefore, I now call for a vote with the following options:
>
> 1) The TC volunteers to be the Roadmap team
> 2) The TC volunteers to be part of the regular workflow of the 
> Roadmap team, as an advisory body.
> 3) The TC shouldn't be part of the regular workflow of the Roadmap team.
> We will always be available for escalations, as usual.
> 4) Further Discussion.
>
> Additionally, I'd like to ask each TC member to state if they would like 
> to be part of the initial group for the Roadmap team if option 1 doesn't win.
>
> This is my vote:
> 3 > 2 > 1 > 4

My vote is:

  3 > 4 > 1 = 2

and I do not wish volunteer to be in the initial Roadmap team.

The rationale: While some of the potential forms that this Roadmap idea
might adopt seem to be thoroughly worthwhile, I don't have any great
enthusiasm for making them happen, and they will clearly require a good
supply of enthusiasm, so it seems best to step aside and let the
enthused get on with it.  The TC's contribution so far seems to have
only been to delay things, so that's why I'm voting not to be involved
in that capacity either.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#830344: How should the TC help with a project roadmap?

[Philip Hands]

Hi,

I managed to make time to watch the video of the roadmap BoF, so
hopefully I'm now able to respond to more than the name "roadmap*.

Some notes regarding the BoF:

Consensus:

  It strikes me that where there is consensus, the process of getting it
  on the roadmap is not really needed, so then it's just a question of
  raising awareness across the project.  I think the TC has very little
  to contribute in such cases.

Conflicting goals:

  Unless it's clear that both goals will be done unless one of them is
  stopped, and they are going to be in conflict from the start, I think
  it's normally best to let them compete.  As long as each effort is
  aware of the other, then they can decide amongst themselves which is
  going to fail in the end.  It's completely possible that of the two
  efforts, one is clearly technically superior, but the other has more
  enthusiastic people involved -- how does one choose which to stop?

GR for the roadmap:

  If we need a centrally agreed list, then this seems like the best way
  to do it, since it makes sure that a) all developers will be made
  aware of the goals, and b) the ones that succeed have enough support
  that even those that might be tempted to resist a goal should be
  persuaded that many people want it to happen.

Late conflict:

  This is a very important point.  If we can come up with a way of
  avoiding this happening it would clearly be a benefit.

The "Let me help you do what you want team":

  That encapsulates what I think might be worthwhile out of this idea.
  It emphasises letting people do things if they happen to feel the urge.

So, the problem I see with getting the TC involved with this is process
is that it emphasises the aspect of somehow seeking permission before
proceeding.

We don't really have a shortage of ideas in Debian, but we do have a
shortage of effort to implement them.  If we can make it easier for
people to go ahead and explore their idea for improving Debian, that's
great.  If we can also help them avoid pitfalls, and help them promote
their effort to get more people to help them, even better.

Of course, that doesn't really advance the idea of a centralised and
coherent roadmap.  I'm not too upset about that, since I think that
lurking in the foundations of the idea of a coherent roadmap is the
assumption that we can somehow predict which ideas are likely to
succeed, and that we can somehow tell people to work on them.  I don't
think either assumption is true, and that some good ideas will be lost
if we set up any sort of filter.

For example, If a Roadmap Team (that acted as gatekeepers to a
centralised roadmap) had been around in 2000, when the idea of
reproducible builds was mentioned on the lists, I'd guess that idea
would not have made it onto the roadmap (judging from the list
response).

If by the time 2013 came round, we had had a decade of failed attempts
to get Reproducible Builds onto the Roadmap, perhaps Lunar would have
assumed that the idea was a non-starter.  Perhaps the Roadmap Team would
remember past rejections, and respond on the basis of precedent.
Perhaps if a roadmep had been in existence for a decade or more, people
would now consider getting on the roadmap as a necessary first step for
any ambitious idea.  This all strikes me as counter-productive.

So, let's not build a discriminating filter, but rather a full-band
amplifier.  We can expect unworkable ideas to fall by the wayside, but
even then they might prompt someone to come up with a workable
replacement idea, so are not automatically a waste of time.

In fact, if someone wants to do something obviously stupid, perhaps the
only way for them to be persuaded to give up is to let them try.  Having
the TC (or anyone else) decide that the idea has no merit might well
lead to endless bickering about how there's a conspiracy to suppress
their genius.

The TC seems like it is far too likely to act as a brake on development
if people are encouraged to seek its approval.  I don't think we should be
involved (except of course as individuals on the other team, as we wish).

Cheers, Phil.

P.S. Sure, if two ideas are going to cause a conflict, then they can be
referred to the TC in the normal manner, and then we'd get involved, but
I would expect that to be a very rare event.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#830978: Browserified javascript and DFSG 2

[Philip Hands]

Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:

> In what sense couldn't everyone modify the concatenated form?

Perhaps if I frame my question from:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90

in another way, I'll get an answer.

Given the existence of the upstream source, would you really consider
editing the value of 'lexer.rules' in the post-grunt output?

See:
  
https://github.com/wycats/handlebars.js/commit/08781798f564a68abee11c74e2b98272657b2a56#diff-a13581e6dfc1c61c90703da188230cbcR123
vs:
  
https://github.com/leshill/handlebars_assets/commit/53443fa7f92c011714bd6aa5831be6074131cfca#diff-49dc26dc0a147a52074ac39c72bd99b1R2119

and if so, why would you want to do that?

Of course, one could do that, in the same way that one could apply a hex
editor to a binary file -- that does not make it source.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#830978: Browserified javascript and DFSG 2

[Philip Hands]

Pirate Praveen <prav...@onenetbeyond.org> writes:

...
>> * For Debian, therefore, the source code for a file or program is the
>>   form which can be conveniently modified and shared; specifically,
>>   the form in which upstream will accept patches.
>
> This was never the intention of dfsg, it was always about freedoms of the 
> user receiving the source code.
>
> Our only consideration for dfsg qualification would be to see if a
> user can exercise freedoms in a generally accepted way. In this case,
> would some comfortable with javascript modify the code? If they are
> able to modify the split files, they will be able to modify the
> browserified files as well without any extra complexity.

Am I right in thinking that this change in the upstream source:

  
https://github.com/wycats/handlebars.js/commit/08781798f564a68abee11c74e2b98272657b2a56#diff-a13581e6dfc1c61c90703da188230cbcR123

becomes this change in the ruby gem that subsequently goes into the package:

  
https://github.com/leshill/handlebars_assets/commit/53443fa7f92c011714bd6aa5831be6074131cfca#diff-49dc26dc0a147a52074ac39c72bd99b1R2119

and if so, are you really trying to claim that these are
indistinguishable as far as anyone working on the code
might be concerned?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#822803: Call for votes for new TC member

[Philip Hands]

> ===BEGIN
> 
> The Technical Committee recommends that Margarita Manterola  be 
> appointed by the Debian Project Leader to the Technical Committee.
> 
> MM: Recommend to appoint Margarita Manterola 
> FD: Further Discussion
> 
> ===END

I vote MM > FD

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Philip Hands]

Hi Steve,

Steve Langasek vor...@debian.org writes:

 On Sat, Nov 29, 2014 at 08:14:07PM +0100, Philipp Kern wrote:
 On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote:
  One claim is changed, see below.

  On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote:
   Hello,

   In summary:
   a) Upgrades should _not_ change init: whatever is installed should be
   kept.
   b) New installs should get systemd-sysv as default init with a debconf
   message about alternative init systems.

  Since there is no interest in adding a debconf message on new installs,
  I wish for a menu entry in the advanced part of the installer to be able
  to install a new system with sysvinit-core or upstart!

 That's even more unlikely than to add a debconf message (which would be
 package-owned). Yes, debian-installer is frozen. This would add new
 udebs, new strings, new everything. We're actually trying to release.

 Debian releases when it's ready.  If large numbers of our users are going to
 have a bad experience with jessie as a result of being switched to systemd,
 then we should take appropriate steps to address that, even if that means
 unfreezing the installer.

 I am not saying that making init systems a choice in the installer is the
 right solution here; I don't think that it is.  But I also don't think that
 the release freeze can reasonably be an argument against it.

How can someone be switched to systemd on a fresh install?

If you were pointing out an instance where upgrades could bite users,
that would be different, and might well be an RC bug.

Apparently however, you're talking about the installer, which has
nothing to do with upgrades, so cannot result in anything being
switched (well, not unless you're saying that the person is being
switched from being one sort of user to another, and might find that a
bad experience ... but then I've no idea what the appropriate steps
might be ;-) )

Cheers, Phil.

P.S. For those that think there's no choice when installing:

  https://wiki.debian.org/systemd#Installing_without_systemd

I'd suggest that anyone that knows enough to have an opinion about their
preferred init will be able to manage that simple extra step with ease.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgpN7y0zKoSNj.pgp
Description: PGP signature