Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

[Sam Hartman]

>>>>> "Thomas" == Thomas Schmitt <scdbac...@gmx.net> writes:

    Thomas> Hi,
Thomas> Sam Hartman wrote:
>> Why do we care if it mounts on a third mac?

Thomas> I care in my role as upstream of xorriso.

OK.
I'd ask that when interacting with end users, you be more clear about
what you're trying to do.
I'd be really frustrated if I was trying to get Debian installed and you
walked me through a long debugging session to help you with cd burning
software, and at the end of the day I still couldn't get Debian
installed.

--Sam

Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

[Sam Hartman]

Why does mountability matter anyway?
The interesting question is whether it boots on the target system,
right?  Why do we care if it mounts on a third mac?

Bug#850967: Why did you want us to keep this open?

[Sam Hartman]

Dear Matthias:

Hi.  As I understand our IRC conversation, you asked me to keep the TC
bug regarding mips binutils open even after your upload.
First, I want to confirm that understanding.

Second, what are you hoping for from the TC at this point?  I think
you've resolved the issue that came to us, and absent your request I'd
normally close this bug.
We're happy to help, but would appreciate guidance on how we could be of
assistance.

--Sam

Bug#850887: To the right bug this time: Why do you want us to keep this open?

[Sam Hartman]

I posted this to the wrong bug, now reposting:
Dear Matthias:

Hi.  As I understand our IRC conversation, you asked me to keep the TC
bug regarding mips binutils open even after your upload.
First, I want to confirm that understanding.

Second, what are you hoping for from the TC at this point?  I think
you've resolved the issue that came to us, and absent your request I'd
normally close this bug.
We're happy to help, but would appreciate guidance on how we could be of
assistance.

--Sam

Bug#830344: Project Roadmap question - Call for votes

[Sam Hartman]

>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.


I vote 2>1=4>3

I'm happy to be part of a discussion of what the roadmap process is ,
but I don't understand it well enough to know whether I'd be a good
member of the initial team.


signature.asc
Description: PGP signature

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

[Sam Hartman]

Do you have _kerberos._tcp DNS entries along with the _kerberos._udp
entries?
Does that help if not?

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

[Sam Hartman]

So, your experience is that with _kerberos._tcp entries but no
_kerberos._udp entries it works.

However, with _kerberos._udp and _kerberos._tcp entries both, it fails?
If so, that's a bug.
With modern (say post Windows XP), I'd imagine that TCP only will be
fine.
However, if adding the UDP entries causes a failure, I definitely should
work with upstream.

--Sam

Bug#830344: Project Roadmap question - Call for votes

[Sam Hartman]

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

>> 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.


Sam> I vote 2>1=4>3

Sam> I'm happy to be part of a discussion of what the roadmap
Sam> process is , but I don't understand it well enough to know
Sam> whether I'd be a good member of the initial team.

In the interest of closing this vote, and in acknowledgement that we
seem to continue to have an energy problem, I change my vote to 3>2>1=4
if and only if that change makes the vote no longer in doubt.

Now you can all fight about whether I can do that:-)


signature.asc
Description: PGP signature

Bug#836388: When cache is present, job run from incorrect working directory

[Sam Hartman]

package: gitlab-ci-multi-runner
version: 1.4.2+dfsg-1
severity: important

Hi.
If a job includes a cache, then it appears that the initial working
directory is  some directory inside the cache, *not* the top of the
project directory.

In trying to diagnose build failures I produced the following job:

install_test:
  dependencies:
- snapshot_package
  stage: test
  variables:
DEBIAN_FRONTEND: noninteractive
  cache:
key: "$CI_BUILD_NAME"
paths:
  - apt_cache
  script:
- ' if [ -d apt_cache/cache ]; then cd apt_cache/cache& cf - . | (cd 
/build/unstable/var/cache/apt&& tar xpf - ); fi'
- 'if [ -d apt_cache/lists ]; then cd apt_cache/lists& cf - . |( cd 
/build/unstable/var/lib/apt/lists && tar xpf - ) ; fi'
- mkdir /build/unstable/sbuild_out
- git status
- pwd
- env
- ls apt_cache
- cp sbuild_out/*.deb /build/unstable/sbuild_out
- schroot --directory / -c unstable apt-get update
- schroot --directory / -c unstable -- apt-get -y --allow-downgrades -o 
DPkg::Options::="--force-confold" install ./sbuild_out/*.deb
- mkdir -p apt_cache
- cp -a /build/unstable/var/cache/apt/. apt_cache/cache
- cp -a /build/unstable/var/lib/apt/lists/. apt_cache/lists
  tags:
- debian


And I get the following output:
[0KRunning with gitlab-ci-multi-runner dev (1.4.2)[0;m
[0;m[0KUsing Docker executor with image runner:latest ...
[0;m[0KPulling docker image runner:latest ...
[0;m[0;33mWARNING: Cannot pull the latest version of image runner:latest : 
Error: image library/runner not found
[0;m[0;33mWARNING: Locally found image will be used instead.
[0;mRunning on runner-99528d3b-project-1-concurrent-0 via gitlab-runner...
[32;1mFetching changes...[0;m
Removing sbuild_out/
HEAD is now at 84b1436 We're getting closer
[32;1mChecking out 84b14360 as master...[0;m
[32;1mChecking cache for install_test...[0;m
[32;1mDownloading artifacts for snapshot_package (150)...[0;m
Downloading artifacts from coordinator... ok  [0;m  id[0;m=150 
responseStatus[0;m=200 OK token[0;m=
[32;1m$ if [ -d apt_cache/cache ]; then cd apt_cache/cache& cf - . | (cd 
/build/unstable/var/cache/apt&& tar xpf - ); fi[0;m
[32;1m$ if [ -d apt_cache/lists ]; then cd apt_cache/lists& cf - . |( cd 
/build/unstable/var/lib/apt/lists && tar xpf - ) ; fi[0;m
[32;1m$ mkdir /build/unstable/sbuild_out[0;m
[32;1m$ git status[0;m
HEAD detached at 84b1436
Untracked files:
  (use "git add ..." to include in what will be committed)

../
../../sbuild_out/

nothing added to commit but untracked files present (use "git add" to track)
[32;1m$ pwd[0;m
/builds/hadron/hadron-operations/apt_cache/cache
[32;1m$ env[0;m
CI_PROJECT_NAME=hadron-operations
CI_BUILD_TOKEN=
HOSTNAME=runner-99528d3b-project-1-concurrent-0
CI_PROJECT_URL=https://gitlab.hadronindustries.com/hadron/hadron-operations
CI_BUILD_BEFORE_SHA=84b143607c165d0dd2e9382d16b20764bc0402e6
CI_SERVER_VERSION=8.11.0
CI_BUILD_ID=151
OLDPWD=/builds/hadron/hadron-operations
CI_PROJECT_ID=1
CI_RUNNER_ID=2
CI_PIPELINE_ID=576
CI_BUILD_REF_NAME=master
CI_BUILD_REF=84b143607c165d0dd2e9382d16b20764bc0402e6
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
CI_BUILD_STAGE=test
CI_PROJECT_DIR=/builds/hadron/hadron-operations
CI_RUNNER_TAGS=debian
PWD=/builds/hadron/hadron-operations/apt_cache/cache
CI_SERVER_NAME=GitLab
CI_PROJECT_PATH=hadron/hadron-operations
GITLAB_CI=true
CI_SERVER_REVISION=346e677
SHLVL=1
CI_BUILD_NAME=install_test
HOME=/root
CI_SERVER=yes
CI=true
CI_PROJECT_NAMESPACE=hadron
DEBIAN_FRONTEND=noninteractive
CI_BUILD_REPO=https://gitlab-ci-token:@gitlab.hadronindustries.com/hadron/hadron-operations.git
CI_RUNNER_DESCRIPTION=Debian Packaging Runner
_=/usr/bin/env
[32;1m$ ls apt_cache[0;m
ls: cannot access 'apt_cache': No such file or directory
[31;1mERROR: Build failed: exit code 1
[0;m

I can wor around this by changing to CI_PROJECT_DIR, but it seems fairly
clear that I'm starting in the wrong place.

Bug#836156: improper handling of source+binary changes triggering binary builds

[Sam Hartman]

>>>>> "Stephan" == Stephan Sürken <abs...@debian.org> writes:

Stephan> Hi Sam,
Stephan> On Di, 2016-08-30 at 21:27 -0400, Sam Hartman wrote:
>> package: mini-buildd version: 1.0.12 severity: normal
>> 
>> reprepro 4.17.1-1

Stephan> fwiw, I am assuming yor mini-buildd instance runs on an
Stephan> (older) sid (or is it jessie+backports?).

Older stretch.

Stephan> There are currently a bunch of (other) problems on current
Stephan> sid I am trying to work out.

Noticed that and decided now would not be the time to upgrade:-)


>> As an aside, this is coming from a trusted builder and a trusted
>> chroot; it would be really convenient if there were a way to
>> convince mini-buildd to accept binaries signed by a particular
>> key along with sources.

Stephan> Ok, sounds reasonable. Maybe you could add a wishlist bug
Stephan> for this?

Will do.

>> What actually happens is far more annoying.
Stephan> (...)
>> I find that the size, sha-1 and md5 of the .deb are not what is
>> expected.

Stephan> That sounds strange - I don't recall such an behaviour
Stephan> (afaiu it). Will retest binary uploads in my current stint
Stephan> ;).

Stephan> On your mini-buildd instance, is this limited to one
Stephan> special package or a general problem?

I don't know.  We normally do source only uploads.
Actually, it may be arch all handling.  The package in question only
produced an arch all binary.
So, the most direct thing to test would be a binary+source upload of a
package producing only an arch all deb.

Bug#836388: [pkg-go] Bug#836388: When cache is present, job run from incorrect working directory

[Sam Hartman]

>>>>> "Dmitry" == Dmitry Smirnov <only...@debian.org> writes:

Dmitry> On Friday, 2 September 2016 10:01:14 AM AEST Sam Hartman wrote:
>> If a job includes a cache, then it appears that the initial
>> working directory is some directory inside the cache, *not* the
>> top of the project directory.

Dmitry> Please discuss upstream. From the description of the problem
Dmitry> I'd say it is an upstream issue. I don't understand the
Dmitry> problem well enough to help. Besides it may be worth trying
Dmitry> the latest version...

I appreciate that you won't be able to help directly, but I'm really
frustrated when I am told to "discuss with upstream."  We, Debian, have
agreed to provide a coherent operating system that works together.
Part of what we sign up to do when we agree to maintain packages is to
do a fair bit of upstream coordination.
I don't know where the upstream bug tracker is.  I don't have an account
there.
I don't wish to get an account there.  I don't wish to evaluate whether
Debian has applied patches that matter in this space.  I know we've
significantly changed how the runner image is constructed for example,
and I don't think that matters in this instance.
But the agreement we make to our users is that we provide a single
consistent interface for them to report bugs.
If you don't have the skills to work on this issue it's entirely
reasonable to forward it upstream.
It's also greatly appreciated that you let me know that if I want a
faster response I  might want to deal with upstream directly.


--Sam

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Sam Hartman]

> "Raphael" == Raphael Hertzog  writes:

Raphael> It would seem natural to orphan it and to let the new
Raphael> maintainer deal with updating it to version 3.x.

I think 3.x is likely to be new packaging and entirely breaks
compatibility with the 2.x config.

If we orphan 2.x someone might fix the RC bug and get it back into
testing.
At this point I think releasing stretch with 2.x would be worse than
releasing stretch without freeradius.

Bug#837000: kerberos-configs: FTBFS: Undefined subroutine ::read_config called at ./genblob line 9.

[Sam Hartman]

> "Lucas" == Lucas Nussbaum  writes:

Lucas> Hi,

Lucas> During a rebuild of all packages in sid, your package failed
Lucas> to build on amd64.

Lucas> Relevant part (hopefully):
>> fakeroot debian/rules binary ./genblob >tmp & tmp config-blob
>> Undefined subroutine ::read_config called at ./genblob line
>> 9.  debian/rules:17: recipe for target 'config-blob' failed make:
>> *** [config-blob] Error 2

Lucas> The full build log is available from:
Lucas> 
http://people.debian.org/~lucas/logs/2016/09/06/kerberos-configs_2.3_unstable.log

Lucas> A list of current common problems and possible solutions is
Lucas> available at http://wiki.debian.org/qa.debian.org/FTBFS
Lucas> . You're welcome to contribute!

Lucas> About the archive rebuild: The rebuild was done on EC2 VM
Lucas> instances from Amazon Web Services, using a clean, minimal
Lucas> and up-to-date chroot. Every failed build was retried once to
Lucas> eliminate random failures.

Looks like a . removed from cwd bug in perl.
Kerberos-configs is a bit over-due for some love anyway.
The fix is easy, but I'll go fold in a bunch of other bugs while I get
to it.


--Sam

Bug#836156: improper handling of source+binary changes triggering binary builds

[Sam Hartman]

package: mini-buildd
version: 1.0.12
severity: normal

reprepro 4.17.1-1

The CI on our source control runs

sbuild -d sid-hadron-snapshot --arch-all --source .

Producing a changes file that includes binaries and sources.
If that succeeds in passing some tests, we upload to mini-buildd.

I expected it to throw away the binaries and run its own build.
As an aside, this is coming from a trusted builder and a trusted chroot;
it would be really convenient if there were a way to convince
mini-buildd to accept binaries signed by a particular key along with
sources.

What actually happens is far more annoying.
What I know for sure is that if I do a source upload not including the
binaries  the sources get installed into the repo, but the binaries
never do.

I tried to debug it.
reprepro include is failing, but I don't seem to get the output from
reprepro itself in daemon.log.
When I unpack the buildresult by hand and run the same reprepro include
command,
I find that the size, sha-1 and md5 of the .deb are not what is
expected.

My guess is that the older deb from the initial .changes is getting left
in incoming or somewhere where reprepro finds it and because of the
rebuild it doesn't match what is expected.

Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc

[Sam Hartman]

package: sbuild
version: 0.70.0
severity: normal


what happened:
$ sbuild --source --no-arch-any --no-arch-all -c unstable -d
sid-hadron-snapshot .
dh clean  
   dh_testdir
   dh_auto_clean
   dh_clean
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building hadron-ci in
hadron-ci_0.1~00+git5e45a12.tar.xz
dpkg-source: info: building hadron-ci in hadron-ci_0.1~00+git5e45a12.dsc
E: dsc: amd64 not in arch list or does not match any arch wildcards:
all -- skipping


what I expected:
I expected to produce a source package and a _source.changes in a clean
chroot.

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Sam Hartman]

> "Josip" == Josip Rodin  writes:

Josip> On Tue, Aug 30, 2016 at 11:20:50AM +0200, Raphael Hertzog wrote:
>> Josip, do you really still care about this package?

Josip> I'm pretty sure I told Sam to take it over a few years
Josip> back...?

O, if that's what you were trying to say, that is very different from
 what I heard.

Regardless, I have move on from the job that had a lot of dependence on
FreeRadius, and can't give it attention either.

--Sam

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Sam Hartman]

> "Raphael" == Raphael Hertzog  writes:

Raphael> On Thu, 14 Jul 2016 22:09:52 + Santiago Vila 
 wrote:
>> I have the ok from the Release Managers to consider this issue as
>> RC for stretch. I'm going to wait at least one week before
>> raising this to "serious".

Raphael> So nobody fixed this issue and freeradius is now gone from
Raphael> testing :-(


In my opinion freeradius 2.x is better gone from Debian.

In my previous job I was willing to put in the effort to maintain
freeradius 3.x if some other developer  was willing to put together
debian/copyright and do the DFSG audit.
That never happened, although someone did 90% of the work and went
silent.

Unfortunately, my new job doesn't involve FreeRADIUS at all.

I think requesting removal of freeradius 2.x would be preferable to
orphaning it.

Bug#836193: Improper handling of arch all only package

[Sam Hartman]

package: mini-buildd
version: 1.0.12
severity: normal

I uploaded  the source of an arch all package (no arch any in the
resulting build) and got:

2016-08-30 22:06:57,398 mini_buildd.packager (0039): ERROR   :
Exceptio\
n DEBUG (Package 'hadron-ci_0.2' FAILED: 1 mandatory architecture(s)
missing: a\
md64):
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mini_buildd/packager.py", line
  287, in\
 run
package.install()
  File "/usr/lib/python2.7/dist-packages/mini_buildd/packager.py", line
  140, in\
 install
self.repository.mbd_package_install(self.distribution, self.suite,
self.cha\
nges, self.success)
  File
  "/usr/lib/python2.7/dist-packages/mini_buildd/models/repository.py",
  lin\
e 1183, in mbd_package_install
raise Exception("{n} mandatory architecture(s) missing:
{a}".format(n=len(m\
issing_mandatory_archs), a=" ".join(missing_mandatory_archs)))
Exception: 1 mandatory architecture(s) missing: amd64


I'll admit that sbuild isn't great with that situation either; I've
filed some bugs there too.

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

[Sam Hartman]

package: tech-ctte
In #741573, the TC produced a two-part decision.
We approved specific wording regarding .desktop policy.  That was folded
into a policy NMU.

We also approved the decision that packages should not include both a
menu file and a desktop file.

The action to draft language for that has stalled in the policy process.

At the August, 2015 meeting, we agreed to champion our decision in the
policy process and propose specific language.
Also at that meeting we agreed to prioritize that work below helping out
with an init system policy.

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

[Sam Hartman]

Obviously, there's a level at which I agree with you.
When this came around last time, I wanted us to issue advice.

The advice I wanted to issue isn't the advice you wished we issued, but
it would have at least been advice.

However, I was the only one on the TC who wanted to touch the issue.
It was quite clear from the IRC meeting that  I didn't have the support.
I think the TC did reach a consensus not to touch the general question
and give advice there.


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.

I don't think having a formal vote to confirm the TC consensus to say
nothing does much
good.
I do think such an outcome would accurately represent the current
thinking of the TC as a body.
I haven't seen anyone who has reviewed the log claim otherwise.


I also don't think asking for a formal vote in a situation where there
is a clear consensus is the right way to ask someone to change their
mind.
I think the TC is making the wrong call here.
So do you.



I guess I don't mind that you're bringing that up again.  I'll be
delighted if it changes peoples' minds.

I don't entirely know what I'm saying.  Perhaps just expressing
disappointment in this overall process.

--Sam

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

[Sam Hartman]

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

Sam> Obviously, there's a level at which I agree with you.  When
Sam> this came around last time, I wanted us to issue advice.

This was something I intended to send to Ian privately, not to the bug.
Apologies for the spam and for emphasis that probably doesn't help the
public discussion.

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

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:


Again, I'm fine with your current ballot.
As stated, I don't think the TC should (and am skeptical of can) decide
on the DFSG-freeness of a package directly.
We could mediate, but it's clear we don't want to here.

I do think there are things we could do in this space.
We could set policy consistent with the DFSG on what the definition of
source code in Debian is.

So, I think there are things that we might be permitted to do related to
this issue.
We could always issue a statement.

It's just that I think when all the circumstances are considered, we
shouldn't do any of those things for this bug, given our IRC discussion.

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

[Sam Hartman]

I'd be willing to vote on the ballot you propose.
I disagree with your rationale for why this bug is not for the TC to
decide.
But I agree that this bug is not for the TC to decide at this time.
So, if that's all we're voting on, and I don't need to agree with your
rationale to vote C, I'm fine with your ballot.

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

[Sam Hartman]

Dear joseph:

This message will be hurried: I'm on a train and approaching my stop.


Thanks for your detailed message.  I don't agree with all of it, but I
find it a lot easier to interact with than some of the requests we've
gotten related to this issue.

Here are some factors to consider:

1)  It's not clear to several TC members that the FTP team has decided
on this question.  It seems fairly clear how they would decide if they
did decide, but from a process standpoint, it's important to have a
formal dialogue with them before they are overruled.

2) It's not clear constitutionally that the TC can overrule the ftp
team's decision regarding whether something is DFSG-free.  Even if we
could, it's not clear that is a technical decision in our scope.
So, asking the TC to overrule such a decision is asking for the hardest
political choice possible in such a situation--a really hard sell within
the project and the TC.

3) We'd need a rationale for overruling someone.  That might not be a
strict requirement, but if we're going to say that "browserified
javascript" is DFSG-free, what exactly are we saying?  There was a
discussion of what is source code, with a number of different
considerations brought up.  Something that was responsive to that part
of the discussion would be a lot more likely to move things forward than
simply an assertion.  I don't even have a clear enough understanding of
what browserified means to have any understanding of what a ruling based
on those terms would mean.  Put another way, the TC is more comfortable
acting when it's building a coherent policy that fits together.  To gain
traction, a ruling almost certainly needs to fit into some intellectual
framework about what source means.  It's quite unlikely that we'd decide
something was source simply because it would be inconvenient for us and
our users if it were not source.
User convenience is something we're likely to consider, but "source is
what we need source to be so things work well for users," is going to be
a really improbable sell.

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

[Sam Hartman]

Dear Pirate:

I hear that you're fairly frustrated by the response you're getting from
the TC.

Speaking as someone who has read extensively the earlier bug log, I
think that your cause would be advanced by getting an additional primary
advocate who has a better understanding of what the TC can do, what the
TC is likely to do, and who can more articulately ask for things to
advance your position.
If Joseph were more involved in Debian, I'd suggest him as a
possibility.

You're asking questions that don't make sense from a p.process
standpoint, doing things that have a very low probability of making
anyone happy, and not responding to advice people have given you on how
to move forward.

Bug#838393: PCA on a repository insufficient to update uploaders

[Sam Hartman]

So, I can see a couple of easy fixes:

1) have _uploaders be a class variable rather than an instance variable

or

2) store a list ofweakrefs to extant demon objects

then provide a class method to invalidate all the uploaders caches.

Bug#835086: RFP: nextcloud -- self-hosted cloud services

[Sam Hartman]

> "Xavier" == Xavier Bestel  writes:

Xavier> Le mardi 20 septembre 2016 à 19:38 +0200, Moritz Mühlenhoff
Xavier> a écrit :
>> On Mon, Aug 22, 2016 at 12:02:59PM +0200, Xavier Bestel wrote:
>> > 
>> > Package: wnpp > Severity: wishlist
>> > 
>> > * Package name: nextcloud
Xavier> [...]
>> > Given that Nextcloud is an Owncloud fork, with the same people
>> > behind it, and that Owncloud upstream has always had a
>> difficult > relationship with distro maintainers, there may be
>> problems for > packaging that correctly.  > But Nextcloud is
>> still a highly relevant package for Debian.
>> 
>> Nack. It's not an important package if we can't support it
>> properly.  Let's not repeat the owncloud disaster.

Xavier> OK, I understand the "official" debian point of view.

I don't think this is an official Debian POV, simply the opinion of some
Debian contributors...  Well, I think it is the official Debian POV that
in order to include a package, we need to be able to support it.
Whether we will or will not be able to support nextcloud is up to
interpretation.

>From a user standpoint, having something that has the functionality of
opencloud/nextcloud is quite important in the enterprise space.
However, we do need to be able to get things to work.

--Sam

Bug#838393: PCA on a repository insufficient to update uploaders

[Sam Hartman]

package: mini-buildd
version: 1.0.12


Hi.
I'd expect that if I change the extra keyrings configuration in the
repository, and then prepare/check/activate the repository, then any new
uploaders would be able to upload.

I've found that I need to restart the demon (I used systemctl, although
perhaps starting/stopping the daemon in the web interface would have
been sufficient).


It looks like what's happening is that the cache mapping repository
identities to uploader keyrings is stored on the demon object in the
_uploaders field and this isn't being refreshed when a repository is
reconfiged.

You could argue that cache is a demon thing, and so it is proper
behavior, but it's very confusing.
I think it would be worth having repository reactivation trigger
refreshing that cache.


--Sam

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

> "Bart" == Bart Schouten  writes:

>> I agree on this too.  To the extent it should be considered
>> time-limited, it should be «until N releases after sysvinit is
>> removed» or somesuch, if that happens.

Bart> In legal terms, in law, it would be considered that the burden
Bart> of proof lies with those who want to remove it.

Bart> Asking the supporters of those scripts to prove that they
Bart> still need them would be considered an unreasonable burden.

I'm nervous of going too far down the path of legalisms.

Asking those who need the scripts to prove (or even say) they still need
them is not what we want.

However if someone is having difficulty maintaining the scripts or they
are broken, it is reasonable for them to ask for help, and if no one
steps forward, eventually the scripts will become buggy enough that the
normal severity bug of a package without an init script is better than
the state of a package with a broken init script.

Similarly, if the community of people who care about sysvinit  is
unwilling to spend the time keeping it working, eventually sysvinit as a
whole will be unmaintained and buggy.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

Ian, quick question for you because you might know the answer off the
top of your head.  Does running stretch with sysvinit as your init
system work reasonably well, or at least work well enough that there are
a small number of bugs we will likely be able to fix in the stretch time
frame?  What I say below is predicated on the assumption that init
scripts are basically functional for stretch.  If that's not true I'd
need to rethink my position.


I think we want to reaffirm that policy section 9.3.2 and section 9.3.3
represent current policy for init scripts, quoting particularly the
following text from section 9.3.2:

 Packages that include daemons for system services should place scripts
 in `/etc/init.d' to start or stop services at boot time or during a
 change of runlevel.
I think it is also reasonable to reaffirm that this is Debian policy
 until changed through the policy process or by the TC.

I don't want to make a blanket statement that it's a bug not to include
an init script.  The systemd package includes a number of daemons and
services and installs no init scripts, and no really, that actually is
the right answer for that package.  Policy should basically means bug of
normal severity.  (I've always wished that the policy people would be a
bit more nuanced especially when taking a term from RFC 2119, which
more-or-less already includes the nuanced language they need, but
people seem to do a fairly good job of accepting the nuances even though
that's not quite what policy says.)

I do *not* want to get into describing all the cases where it is a bug
to not include an init script, nor do I want to get into all the cases
where it isn't.  The TC tried to do that during the systemd discussion
with text for the L and T varients of options.
I think they did about as well as they could, but I think a policy
should better captures the reality of the situation than the TC's
previous best efforts.

I think including 6.1.5 language saying that we encourage maintainers to
merge patches adding support for init systems including init scripts
would be valuable.
I think we have such language floating around from previous resolutions
to re-use.

Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful

[Sam Hartman]

package: debian-policy
severity: normal

Hi. As part of reviewing an issue for the technical committee, I just
read policy section 9.3 in its entirety.

Section 9.3.1 really seems to be showing its age.  That section covers
runlevels and the sequencing numbers after S and K in rc.d links without
reference to dependency-based boot ordering, init systems other than
sysinit, etc.


In an ideal world I'd encourage that section to be updated to talk about
how boot ordering works on modern Debian.
Absent that, I'd recommend significantly trimming the section to just
cover the fact that there are run levels and that there are these
numbers after S and K and not go into what the numbers after S and K
mean.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

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

Ian> Sam Hartman writes ("Re: Bug#835507: Please clarify that
Ian> sysvinit support decision is not going to expire"):
>> Ian, quick question for you because you might know the answer off
>> the top of your head.  Does running stretch with sysvinit as your
>> init system work reasonably well, or at least work well enough
>> that there are a small number of bugs we will likely be able to
>> fix in the stretch time frame?  What I say below is predicated on
>> the assumption that init scripts are basically functional for
>> stretch.  If that's not true I'd need to rethink my position.

Ian> I am running stretch with sysvinit on my laptop.  It seems to
Ian> work for me.  I haven't conducted any kind of systematic
Ian> survey.

That's the rough estimate I thought you could provide easily and was
looking for.

That's good enough that I definitely support reaffirming policy 9.3.2
and 9.3.3.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

>>>>> "Ansgar" == Ansgar Burchardt <ans...@debian.org> writes:

Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
>> I think we want to reaffirm that policy section 9.3.2 and section
Ansgar> 9.3.3
>> represent current policy for init scripts, quoting particularly
>> the following text from section 9.3.2:     Packages that
>> include daemons for system services should place
Ansgar> scripts
>>   in `/etc/init.d' to start or stop services at boot time or
Ansgar> during a
>>   change of runlevel.

Ansgar> Does this really represent current policy?

Ansgar> As far as I can tell Policy still assumes that sysvinit is
Ansgar> the default init system and everything else is an "alternate
Ansgar> init system" (9.11).

There are many problems with regard to policy and init systems.  I
believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still
our current policy and still solid.

The rest of policy in this area really needs to be updated, but if you
see specific problems with those sections, please explain them.  I did a
complete review this morning and they seemed fine to me, especially if
you take more of an RFC 2119 interpretation of SHOULD than we
classically have admitted we take in policy.

Bug#841372: Kerberos config update for CS.CMU.EDU

[Sam Hartman]

control: severity -1 important
justification: As maintainer, I'd like to consider this issue
important.  If not promptly resolved, it will create an operational
inconvenience on an ongoing basis for years.

--Sam

Bug#841372: Kerberos config update for CS.CMU.EDU

[Sam Hartman]

Jeff, I've just uploaded kerberos configs 2.6.
If you  delete /etc/krb5.conf and then install krb5-config 2.6 and
confirm that the entry there works for you, I'll fill out paperwork to
request an unblock for stretch.
(I don't think this will make it for the auto migration)

Bug#842497: krb5: [INTL:de] German translation is missing

[Sam Hartman]

I'm aware of no issue.
I'll look into it; will be packaging 1.15~beta1 soon, and this is almost
certainly a packaging error, not an intentional change.
Or rather, I'm sure the change is not intended; it's alomst certainly
just that the file somehow got dropped.

Bug#843593: Please add support for ESP partitions

[Sam Hartman]

package: fai
version: 5.2
tags: patch
severity: wishlist

It's impossible to use FAI to install for a platform/system that
requires UEFI because FAI does not currently support setting up a
extended system partition as required by the UEFI spec.
This patch adds code to do that.

I did not update the documentation in this patch, because I'm not that
familiar with all the documentation I'd need to touch.
An example disk_config might look something like:

#
#

disk_config disk1 disklabel:gpt bootable:1 esp:1 fstabkey:uuid align-at:1M

primary /boot/efi 300vfat  defaults
primary /  300-  ext4  rw,barrier=0,noatime,errors=remount-ro 
tuneopts="-c 0 -i 0"


>From 06a30575b8c473da89a031587debd8f6f350ba6b Mon Sep 17 00:00:00 2001
From: Sam Hartman <hartm...@debian.org>
Date: Mon, 7 Nov 2016 16:41:12 -0500
Subject: [PATCH] Add support for ESP partitions

UEFI requires a special vfat partition on which the boot loader and
potentially other UEFI information lives.  Parted represents this with
an esp flag.  Add support for this in setup-storage.
---
 lib/setup-storage/Commands.pm | 2 ++
 lib/setup-storage/Parser.pm   | 8 
 2 files changed, 10 insertions(+)

diff --git a/lib/setup-storage/Commands.pm b/lib/setup-storage/Commands.pm
index 31898ca..6190343 100755
--- a/lib/setup-storage/Commands.pm
+++ b/lib/setup-storage/Commands.pm
@@ -1344,6 +1344,8 @@ sub setup_partitions {
   if ($part->{size}->{preserve} || $part->{size}->{resize});
 # set the bootable flag, if requested at all
 $flags .= ",boot" if($FAI::configs{$config}{bootable} == $part_id);
+# set the ESP flag, if requested at all
+$flags .= ",esp" if($FAI::configs{$config}{esp} == $part_id);
 # set the bios_grub flag on BIOS compatible GPT tables
 $flags .= ",bios_grub" if($FAI::configs{$config}{disklabel} eq "gpt-bios"
   && $FAI::configs{$config}{gpt_bios_part} == $part_id);
diff --git a/lib/setup-storage/Parser.pm b/lib/setup-storage/Parser.pm
index 943eaa5..d58afe9 100755
--- a/lib/setup-storage/Parser.pm
+++ b/lib/setup-storage/Parser.pm
@@ -144,6 +144,7 @@ sub init_disk_config {
 virtual=> 0,
 disklabel  => "msdos",
 bootable   => -1,
+esp=> 0,
 fstabkey   => "device",
 preserveparts => 0,
 partitions => {},
@@ -690,6 +691,13 @@ $FAI::Parser = Parse::RecDescent->new(
   ($FAI::device =~ /^PHY_(.+)$/) or
 ::internal_error("unexpected device name");
 }
+| /^esp:(\d+)/
+{
+  # specify a partition that should get the ESP flag set
+  $FAI::configs{$FAI::device}{esp} = $1;
+  ($FAI::device =~ /^PHY_(.+)$/) or
+::internal_error("unexpected device name");
+}
 | 'virtual'
 {
   # this is a configuration for a virtual disk
-- 
2.9.3

Bug#843597: More robust capability handling

[Sam Hartman]

package: fai
version: 5.2

Currently, the sample configuration namespace has a shell script to
restore the common capabilities found in base files; see
scripts/DEBIAN/20-capabilities.

This approach is brittle because as new packages in the base system gain
capabilities, everyone's configuration space needs to be updated.

tar does support saving and restoring capabilities.
If base file tars are created using
tar --xattrs --xattrs-include=security.capability -cf blah blah

and restored with
tar -xf filename --xattrs --xattrs-include=security.capability

Then capabilities are directly preserved.

I understand that you may want to preserve the script in the
configuration space because you cannot guarantee how people create base
files.
However for restore of base files, please include the xattrs options.

Bug#843716: Acknowledgement (setup-storage fails with fai-diskimage and btrfs)

[Sam Hartman]

control: tags -1 patch
control: severity -1 normal

Actually, the problem is somewhat simpler than that.
>From e4511f8ea11c047bf19f13c7b99d9c18f8736d89 Mon Sep 17 00:00:00 2001
From: Sam Hartman <hartm...@debian.org>
Date: Tue, 8 Nov 2016 18:49:38 -0500
Subject: [PATCH] Fix handling of btrfs single volume devices

---
 lib/setup-storage/Commands.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/setup-storage/Commands.pm b/lib/setup-storage/Commands.pm
index 6190343..0e0b625 100755
--- a/lib/setup-storage/Commands.pm
+++ b/lib/setup-storage/Commands.pm
@@ -332,7 +332,7 @@ sub build_btrfs_commands {
   $FAI::configs{$config}{volumes}{$volume}{mount_options} = 
$FAI::configs{$c}{partitions}{$p}{mount_options};
   $FAI::configs{$c}{partitions}{$p}{mount_options} = '-';
   $FAI::configs{$config}{volumes}{$volume}{fstabkey} = 
$FAI::configs{$c}{fstabkey};
-  if ($device =~ m|^/dev/nvme|) {
+  if ($device =~ m:^/dev/nvme|^/dev/loop:) {
 $FAI::configs{$config}{volumes}{$volume}{devices}{$device . "p" . $p} 
= {};
   } else {
 $FAI::configs{$config}{volumes}{$volume}{devices}{$device . $p} = {};
-- 
2.9.3

Bug#842497: krb5: [INTL:de] German translation is missing

[Sam Hartman]

> "Chris" == Chris Leick  writes:

Chris> Package: krb5 Version: 1.14.3+dfsg Severity: minor Tags: l10n


Chris> Hi,

Chris> I've seen, that the German translation isn't included in
Chris> version 1.14.3. Is there an issue with the translated file?
Chris> Please let me know, if I can help. The translation was sent
Chris> with Bug 816548.

Hi.
As best I can tell we're shipping src/po/de.po in our builds.
Is it possiblee that the issue is we're shipping the German translations
but not using them?
I am testing a fix if that's the case.

Bug#843597: More robust capability handling

[Sam Hartman]

>>>>> "Thomas" == Thomas Lange <la...@informatik.uni-koeln.de> writes:

>>>>> On Mon, 07 Nov 2016 17:36:41 -0500, Sam Hartman
>> Currently, the sample configuration namespace has a shell script
>> to restore the common capabilities found in base files; see
>> scripts/DEBIAN/20-capabilities.
Thomas> In this script, I'm doing the same things that are done in
Thomas> the postinst script of the package.

No, you're doing what the postinst script did on the day you wrote that
config script.
First, there's no guarantee that you'll notice when the packages in
question change.
Secondly, even if you do update the examples, each FAI user has to
update every one of their configuration spaces.
That tends to produce unexpected behavior over time.

Thomas> Also there was a bug in tar which added some xattr or
Thomas> capabilities even no were defined when creating the tar
Thomas> file. Have a look at #819978. IIRC this was one reason to no
Thomas> use xattrs with tar by default.  -- regards Thomas

That seems to be dealing with --acls not --xattrs
--xattrs-include=security.capability.

At least with the stretch tar, I do not get default ACLs when I use
--xattrs --xattrs-include=security.capability.

Bug#843597: More robust capability handling

[Sam Hartman]

Hi.
Looking at ftar in current fai,
it looks like it already is fairly aggressive about using tar --xattrs
for extraction.
If my reading of the code is correct, this bug should probably be closed
as never having been an issue.

--Sam

Bug#843209: Please permit class directory-like feature for fai-diskimage

[Sam Hartman]

> "Thomas" == Thomas Lange  writes:

Thomas> Just as a short note. There's the commands fai-deps(8) which
Thomas> can be used to define dependencies inside classes. It's
Thomas> available in FAI but not used (means called) by default.

So does the above mean that  in addition to creating class/*.deps files
I'd need to arrange for fai-deps to get called by fai-diskimage?
--Sam

Bug#843639: Please add EFI support

[Sam Hartman]

package: fai
version: 5.2
tags: patch
severity: wishlist

This patch adds EFI support to the simple configuration space.  I've
tested in my configuration space but it's possible I mangled something
transforming to the default config space.

to test,  set up a disk_config with an ESP say in the EFI_DISK class and
run something like

fai-diskimage -c DEBIAN,EFI_DISK,GRUB_EFI,AMD64  /tmp/image.raw

Then to boot
apt-get install ovmf #from non-free:-(
kvm -drive file=/usr/share/ovmf/OVMF.fd,readonly,if=pflash -snapshot -m
1024 -hda /tmp/image.raw


>From 62a518ac2cf6a6911483c55aa2a4961911fa93da Mon Sep 17 00:00:00 2001
From: Sam Hartman <hartm...@debian.org>
Date: Tue, 8 Nov 2016 08:42:01 -0500
Subject: [PATCH] Add GRUB_EFI class

Add a class to install an EFI boot loader on a GPT-partitioned system
with an ESP.

Change the class misc logic not to assert GRUB_PC if GRUB_EFI is
defined.  For now, though, prefer GRUB_PC to GRUB_EFI.
---
 examples/simple/class/60-misc |  4 +-
 examples/simple/package_config/DEBIAN |  3 ++
 examples/simple/scripts/GRUB_EFI/10-setup | 67 +++
 3 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100755 examples/simple/scripts/GRUB_EFI/10-setup

diff --git a/examples/simple/class/60-misc b/examples/simple/class/60-misc
index 22a30c0..9733dcb 100755
--- a/examples/simple/class/60-misc
+++ b/examples/simple/class/60-misc
@@ -1,4 +1,6 @@
 #! /bin/bash
 
 ifclass -o CENTOS SLC && exit 0
-ifclass -o I386 AMD64 && echo GRUB_PC
+if ifclass -o I386 AMD64 ; then
+ifclass -o GRUB_PC GRUB_EFI ||echo GRUB_PC
+fi
diff --git a/examples/simple/package_config/DEBIAN 
b/examples/simple/package_config/DEBIAN
index d5730e9..bdec0d6 100644
--- a/examples/simple/package_config/DEBIAN
+++ b/examples/simple/package_config/DEBIAN
@@ -16,6 +16,9 @@ isc-dhcp-client
 PACKAGES install GRUB_PC
 grub-pc
 
+PACKAGES install GRUB_EFI
+grub-efi
+
 PACKAGES install LVM
 lvm2
 
diff --git a/examples/simple/scripts/GRUB_EFI/10-setup 
b/examples/simple/scripts/GRUB_EFI/10-setup
new file mode 100755
index 000..0f8d9e6
--- /dev/null
+++ b/examples/simple/scripts/GRUB_EFI/10-setup
@@ -0,0 +1,67 @@
+#! /bin/bash
+# support for GRUB version 2
+
+error=0; trap 'error=$(($?>$error?$?:$error))' ERR # save maximum error code
+
+# This script assumes that fthe disk has a GPT partition table and
+# that the extended system partition (ESP) is mounted on /boot/esp.
+# When building a disk image, we don't change the NVRAM to point at
+# the boot image we made available, because the disk image is likely
+# not installed on the current system.  As a result, we force
+# installation into the removable media paths as well as the standard
+# debian path.
+
+set -a
+
+# do not set up grub during dirinstall
+if [ "$FAI_ACTION" = "dirinstall" ] ; then
+exit 0
+fi
+# during softupdate use this file
+[ -r $LOGDIR/disk_var.sh ] && . $LOGDIR/disk_var.sh
+
+if [ -z "$BOOT_DEVICE" ]; then
+exit 189
+fi
+
+# disable os-prober because of #788062
+ainsl /etc/default/grub 'GRUB_DISABLE_OS_PROBER=true'
+
+# skip the rest, if not an initial installation
+if [ $FAI_ACTION != "install" ]; then
+$ROOTCMD update-grub
+exit $error
+fi
+
+$ROOTCMD grub-mkdevicemap --no-floppy
+GROOT=$($ROOTCMD grub-probe -tdrive -d $BOOT_DEVICE)
+
+
+# Check if RAID is used for the boot device
+if [[ $BOOT_DEVICE =~ '/dev/md' ]]; then
+raiddev=${BOOT_DEVICE#/dev/}
+# install grub on all members of RAID
+for device in `LC_ALL=C perl -ne 'if(/^'$raiddev'\s.+raid\d+\s(.+)/){ 
$_=$1; s/\d+\[\d+\]//g; print }' /proc/mdstat`; do
+   echo Install grub on /dev/$device
+   $ROOTCMD grub-install --no-floppy --force-extra-removable "/dev/$device"
+done
+
+elif [[ $GROOT =~ 'hostdisk' ]]; then
+cat > $target/boot/grub/device.map <

Bug#843593: Please add support for ESP partitions

[Sam Hartman]

> "Thomas" == Thomas Lange  writes:

Thomas> I found the thread on the linux-fai mailing list and also
Thomas> the code that added efi support into setup-storage. In the
Thomas> end we remove the code from FAI, since it was not needed any
Thomas> more.

Thomas> It's much easier to get a partition of type ESP. Just create
Thomas> a disk gpt disk label, a partition of type vfat that is
Thomas> mounted to /boot/efi and set the boot flag on this partition
Thomas> using the bootable:1 keywork in the disk_config line. This
Thomas> will result in a partition type of esp. This is the normal
Thomas> parted behaviour. It should look like this:

I've confirmed this works.
That doesn't allow you to create an esp partition on a non-gpt or a
gpt-bios disk.
I'm fine if you want to say that's rare enough that people need to set
the flag in a hook rather than permitting it in fai-setupstorage.
Today, I actually do create an ESP on bios disk labels, which is a
perfectly supported UEFI configuration, but gpt would be totally fine
for my uses so I'm fine if you want to close this.

Bug#843209: Please permit class directory-like feature for fai-diskimage

[Sam Hartman]

package: fai
version: 5.2
severity: wishlist.

FAI has a great feature in the class directory that allows a
configuration space to infer classes from things such as the installed
hardware.
This is not currently available from fai-diskimage.
I'd really like to have a feature like that for fai-diskimage.

My recommendation is that the class script be run for fai-diskimage, and
that there be some way for a script to determine if it is producing a
diskimage so that scripts that do things like output classes based on
the current machine would not run.

An alternative would be to have a directory parallel to class that was
only used for diskimage.
A far less desirable alternative would be for the cloud team to wrap
fai-diskimage for this purpose.
We'll almost certainly wrap fai-diskimage, but I was hoping that our
wrappers would focus on things like uploading images, not on stuff like
this.

You said you didn't see the point for disk-images.
You don't infer things from the current environment, but you infer
aspects of configuration from other aspects of configuration to improve
maintainability, and simplicity of calling the interface.
Here are examples where this is useful.

* inferring either GRUB_PC or GRUB_EFI from AMD64 and whether the
  provider in question currently uses EFI

* Any of GCE or EC2 implying CLOUD

* Implying classes from release.  For example, as we moved from wheezy
  to jessie, SYSTEMD might be implied.  It seems likely that there will
  be similar future-such that will be triggered either by Debian
  release, or by the time frame and provider


For non-cloud work, I think I'll want this feature in my own
fai-diskimage usage.
Inside my employer, Hadron, we'll have a number of classes related to
things like whether a desktop is installed, whether we're building an
installer image, or an image to be given to hardware vendors to be
burned into systems before they are delivered to us.
Only a couple of these configurations will be supported at any given
time, but to ease comprehension of the configuration space and to deal
with code evolution, these will be  split into classes.
I'd prefer that people calling fai-diskimage provide in one top-level
class corresponding to one of the supported top-level configurations.


--Sam
I'm happy to work on an implementation once you figure out what
approaches you'd be willing to accept.

Bug#841372: Kerberos config update for CS.CMU.EDU

[Sam Hartman]

Your timing is dreadful.:-)
I just uploaded a new krb5-config and am not 100% sure I'll have time to
get in another one for stretch before the freeze.
I considered dropping the kdc lines and depending on SRV records for
cs.cmu.edu, but decided that you were picky enough that you would have
sent in an update request if you wanted one:-(

I'll see what I can do.

I need to wait for 2.5 to get into testing before uploading a 2.6
because 2.5 is really needed.

Bug#833057: does downgrading e2fsprogs to the jessie version help?

[Sam Hartman]

Does the e2fsprogs in jessie produce an image that works with syslinux
and vmdebootstrap?

Bug#805154: Please reconsider tagging this bug wontfix

[Sam Hartman]

I do understand that the proposed fix is inadequate.  You'd need to not
include nobarrier on the esp partition.

However, the performance of vmdebootstrap is really fairly bad compared
to other image creation solutions I've used in the past, and it does
significantly impact the test/development cycle.
If you don't want to develop a patch fine, but perhaps help or no tags
would be more appropriate than wontfix.

Bug#845256: raid5 metadata, discards and other issues

[Sam Hartman]

package: lvm2
version: 2.02.167-1

This bug is opened to document some problems discovered in an IRC
conversation on #debian-devel between Sam Hartman and Bastian Blank

The problem seemed to be that often (although not in all the time in
Sam's experience)
lvcreate --type raid5 -L 128g -n volumename vgname
produced a volume with a bogus raid metadata bitmap.
In particular, lvchange -an volumename& -ay volumename would
fail
with errno -22 trying to read the bitmap
Looking at the _rmeta_0 volumes, the bitmap looked like garbage; among
other things the BITM magic number was absent.

Doing something like
dd if=/dev/zero of=/dev/mapper/vgname-volumename_rmeta_0 (through n for
each rmeta volume)
would permit the volume to be activated one more time.

Thes volumes failed to activate with linux 4.8.0-1-amd64 at all,
claiming an unknown feature flag.
However, at least in Sam's experience, zeroing all the metadata and
activating the volume gets good metadata  written out including a good
bitmap on 4.8.0-1-amd64

Bastian was unable to produce a raid5 logical volume at all on
4.8.0-1-amd64.
Sam's theory was that lvcreate does not properly zero the metadata
volume on create, and that since the segment allocation is predictable,
Bastian's system was reusing the same metadata extents after an upgrade
from 4.7 to 4.8.

Sam is able to create raid5 volumes on 45.8.0-1-amd64.

However, as part of this process, Sam discovered that even with
issue_discards set to 1, lvremove does not issue discards for the data
segments of a raid5 volume.

To test do something like

# create volume
dd if=/etc/motd bs=1024k seek=1
dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd
lvremove vgname/volumename
#immediately recreate volume with same params
dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd


the 4.7 issues can probably be ignored since it is an old kernel we
never shipped.  I think that the failing to zero metadata and failing to
discard are important to investigate.

Bug#846088: Alladin License in krb5

[Sam Hartman]

Hmm.
So,  first, the file refers to a modified copy of the Alladin free
public license, from a kit for implementing filesystems.
I'm kind of boggled that someone would start from the Alladin license,
but since I have no idea what modifications they made, I have no idea
whether it's free.

However the author of the software in question was working for the part
of MIT responsible for Kerberos around that period of time.
I suspect this is a simple case of someone cut their work from
one project to another and failing to fix up the license header.
MIT is fairly good about getting copyright assignments so this can
probably be cleared up.


--Sam

Bug#846088: Info received (Bug#846088: Alladin License in krb5)

[Sam Hartman]

To be clear I've contacted upstream off-list and we'll see what we find
in the next few days.

Bug#843593: Please add support for ESP partitions

[Sam Hartman]

Hi.
I've done some more research.

It turns out that being able to create an ESP partition on a bios disk
label is a lot more useful than I thought it is.  In the cloud space
(and when I'm creating an image to be burned onto real hardware)
I tend to resize the partition table and filesystems to fit the disk.

For a bios disk label that's easy.  You just resize the partition  and
the filesystem.

For GPT, there's this thing that you need to move to the end of the
disk.
You can get the parted command line to do that, but I have not yet
figured out to get libparted to do that.

So, if you aren't going to have bigger than 2T disks, bios disk labels
are a lot easier to work with even for UEFI boot than GPT.
If you are using UEFI and bios disk labels, you do need to be able to
set the esp flag.

Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing

[Sam Hartman]

My understanding of the current plan is that we're adding openssl 1.1.0
to unstable, but will make a decision about whether to drop libssl1.0.2
later.

That's really frustrating for the rest of the ecosystem--our users and
our upstreams, and I'd ask the release team to commit now to 1.0.2 being
available for stretch.


At least one of the clusters of packages I'm involved in--shibboleth and
moonshot will require some real upstream porting effort.
That's under way in a time scale that will work for  buster, but is very
unlikely to meet the stretch freeze timeline.

It's possible that resources could be reprioritized and that with a
fairly agressive scramble, we could get things working with OpenSSL 1.1
in time for stretch.
However money and time are finite.
That would take away from other priorities and would have significant
risks in terms of stability.

Debian matters in the larger ecosystems, and we owe it to our upstreams
and our users to decide now whether we're asking people to make those
sort of mad scrambles.
I think we should not.  Regardless, decisions now matter.

Thanks for your consideration,

--Sam

Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0

[Sam Hartman]

> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> control: tags -1 patch
Sebastian> On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote:
>> OpenSSL 1.1.0 is about to released.  During a rebuild of all
>> packages using OpenSSL this package fail to build.  A log of that
>> build can be found at:
>> 
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/moonshot-gss-eap_0.9.5-1_amd64-20160529-1451

Sebastian> this builds now. Do you have anything to verify?

Hi.
I'm sorry I didn't get a chance to respond to your other mail.
upstream has dealt with moonshot-gss-eap and moonshot-ui and I plan to
address the bugs there with a new upstream version.
We'll probably need to build-dep on libssl1.0 until the entire cluster
builds with 1.1; I think having two related libraries in the same
address space use different versions of ssl will be problematic.

Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing

[Sam Hartman]

>>>>> "Sebastian" == Sebastian Andrzej Siewior <sebast...@breakpoint.cc> writes:

Sebastian> On 2016-10-31 11:16:38 [-0400], Sam Hartman wrote:
>> At least one of the clusters of packages I'm involved
>> in--shibboleth and moonshot will require some real upstream
>> porting effort.  That's under way in a time scale that will work
>> for buster, but is very unlikely to meet the stretch freeze
>> timeline.

Sebastian> Do you want me to look into moonshot-gss-eap? The other
Sebastian> moonshot-* package with the RC bug won't be part of
Sebastian> current testing. I didn't find anything that matches
Sebastian> shibboleth.

Hi.
I'm really sorry I didn't get a chance to respond earlier. I was
traveling.
Shibboleth comprises opensaml, xmltooling, heavily depends on
xml-security-c and shibboleth-sp2.
Ferenc Wágner (copied) has been handling the Shibboleth packaging and
has an understanding of where the upstream efforts are.  There's been
discussion on pkg-shibboleth-...@lists.alioth.debian.org.
The area that I tdon't think anyone has examined in the moonshot cluster
is libradsec, which also depends on libevent fairly heavily.

Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc

[Sam Hartman]

> "Johannes" == Johannes Schauer  writes:

Johannes> Do you know a situation when it would be beneficial to let
Johannes> sbuild create the source package *again* after it has
Johannes> already been produced for sbuild?

Sbuild can take a directory as input.
I tend to use it in that way for CI-driven builds from git repositories.
Sometimes I want source uploads, sometimes I want a binary upload.
(In this case I ended up wanting a source upload because of another bug
in mini-buildd, although in other cases I'd just want a source upload).
As an example, I might want to run
gbp buildpackage --git-export-dir=somewhere --git-builder=sbuild
--source --no-arch-any --no-arch-all
to prepare an upload to debian (after testing my tree some other way).
Does sbuild add that much in that situation?
No, but it sure doesn't hurt, and consistency is nice.

Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc

[Sam Hartman]

I want consistency between the case where there is a binary build and
the case where there is a source build.
I want --source because I want the source package to be included in the
.changes.
I want to use one tool, (sbuildh) rather than having my scripts care
about how it is being called.

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

[Sam Hartman]

For what it's worth, I think the policy question here is not a
significant one.

Holger is right that we should either fix policy or fix both
(tasksel-data and blends-tasks).
I think that is a bug that should get hashed out.  I don't think it is
all that timely, and I don't think it matters much how we handle things.
It seems clear that if we want the data available for tasksel, then when
tasksel runs, both tasksel-data and blends-tasks need to be installed.
How to align policy and implementation is something we should eventually
figure out.

I think the far more important question is whether the presentation of
blends is what our users need.

Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client

[Sam Hartman]

I've played with systemd-networkd a bit.
It seems capable enough to handle this use case, but it has some
significant drawbacks.
It's not very backward compatible with expected sysadmin patterns.  That
is, as a sysadmin, I'd expect ifup and ifdown to work.  I expect to be
able to do things like ifdown eth0& eth0 to bounce the network on
an instance.
And with systemd-networkd, that doesn't work.
Also, since it uses a different DHCP implementation, you end up with an
entirenly different set of ways of configuring dhcp client options and
dhcp scripts.
So, while it works, it's a big change--probably too big to introduce for
stretch images.

I'll also caution against systemd-resolved.  I have had very bad success
with the legacy DNS proxy included in systemd-resolved.

Networkmanager does play less destructively with /etc/network/interfaces
than systemd-networkd, although that only means they play well on the
same system.  But only one of them manages a given interface.
I've chosen to use networkmanager on several of my cloud images, but I'm
not sure it is playing great with cloudinit.

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

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:


Didier> That code is now in Debian (experimental), so yes, I do
Didier> expect you to act in good faith and report bugs you see. You
Didier> are obviously quite versed in how 'global' works, and that's
Didier> undoubtedly valuable to produce the best possible 'global'
Didier> package.

Ron,  I would prefer that Didier use a different tone.
However, it's my opinion as someone who will be voting on this that
Didier is essentially right that your view of this situation and of the
responsibilities of a Debian maintainer are inconsistent with the
project as a whole.
You have continued to try and frame the discussion in the terms you
would prefer.
I have considered those terms, and I do not find framing the discussion
in those terms compelling.

In the language similar to the  IETF, used only because we're both familiar with
it, the technical issues surrounding global-6 and the question of
evidence regarding htags have been considered.  My judgment of the
discussion is that the rough consensus here is that those issues are not
significant compared to failing to upgrade global in six years.  That
is, we in this discussion have reach an informed opinion that those
issues are not significant enough to block.  It is my opinion you are in
the rough.

I think the question before the TC is (and is properly) how should
global-6 be maintained and whether you are the person to do that.

You have tried to frame it arguing that the version number doesn't
matter.
I absolutely agree.
However, the time at which Debian has last synced with upstream does
matter.
Six years is a long time.
Moreover, I believe that the standard you've used to evaluate whether
failing to sync for six years was acceptable is inconsistent with best
practices of the project.

--Sam

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

[Sam Hartman]

> "Colin" == Colin Watson  writes:


Colin> As a maintainer who has sometimes had cause to do similar
Colin> things, I'm concerned at the standard being applied here.
Colin> Could you perhaps review the history around groff 1.18.1.1 ->
Colin> 1.20 for comparison?  This is a case that's all over and done
Colin> with seven years ago, so should be free of emotive
Colin> associations by now, and the history can be read through
Colin> reasonably quickly.

Colin> Here are some references: https://bugs.debian.org/196762
Colin> https://bugs.debian.org/374569
Colin> https://lists.gnu.org/archive/html/groff/2007-11/msg00011.html

Reading this first reference was enough for me to identify several
differences I believe are key.

First, upgrading to new upstream is presumed good, not always good.
My concern with Ron's position is mostly that  he wants the people
requesting a new upstream to justify that rather than wanting the htags
users to justify not breaking htags.

I think it was fairly obvious to everyone involved in the groff
discussion that the multibyte patch was required for Japanese man pages
among other things.
That is, I think there is evidence of the importance of the groff
multibyte patch in a way there's not evidence of heavy htags CGI use
here.
Put another way, the record presents evidence sufficient to overcome the
presumption that upgrading is good.

Second, you were responsive and pro-active.  You reached out to the
multibyte patch author.
You tried to forward port it yourself.

Third, there was an eventual way forward.  It was clear that groff would
eventually get to UTF-8 support good enough that we could use it.

So for these reasons, I think the groff situation is different in ways
that matter at least to my analysis.

Bug#850834: dpkg --unpack produces zero-byte file, but dpkg -x works

[Sam Hartman]

package: dpkg
version: 1.18.10


Hi.  For a non-debian archive, I've been packaging up some disk images
into debian packages, because we tend to use debs for software
distribution.

It's not working very well.
When I run dpkg -x hadron-installer-efi_0.10_all.deb /tmp/foo,
I get
root@mini-buildd:/tmp# ls -l /tmp/foo/usr/share/hadron-installer/
total 8388608
-rw-r--r-- 1 root root 8589934592 Jan 10 09:52 installer-efi.raw


But when I run dpkg -I I get less promising results.

root@mini-buildd:/tmp# dpkg -i /tmp/hadron-installer-efi_0.10_all.deb
Selecting previously unselected package hadron-installer-efi.
(Reading database ... 155174 files and directories currently installed.)
Preparing to unpack .../hadron-installer-efi_0.10_all.deb ...
Unpacking hadron-installer-efi (0.10) ...
Setting up hadron-installer-efi (0.10) ...
root@mini-buildd:/tmp# ls -l /usr/share/hadron-installer
total 0
-rw-r--r-- 1 root root 0 Jan 10 09:52 installer-efi.raw


The only interesting note from the build is that  I'm using gzip to
compress the deb.  We find that the default compression is unacceptably
slow, and gzip does well enough for our needs.
Here's the part of the buildlog.
   dh_md5sums
   debian/rules override_dh_builddeb
make[1]: Entering directory '/<>'
dh_builddeb  -- -Zgzip
dpkg-deb: building package 'hadron-installer-efi' in 
'../hadron-installer-efi_0.10_all.deb'.
dpkg-deb: building package 'hadron-installer-legacy' in 
'../hadron-installer-legacy_0.10_all.deb'.
make[1]: Leaving directory '/<>'
 dpkg-genchanges --build=any,all >../hadron-installer-images_0.10_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build hadron-installer-images-0.10
dpkg-buildpackage: info: binary-only upload (no source included)

Build finished at 2017-01-10T15:24:59Z

While this is not something we're releasing, there's no significant
proprietary interest.  I'd be happy to give you access to the resulting
deb, more of the build log, whatever is necessary.
The deb is over 2g in size, but I'm happy to make it available.
For debian developers, I've placed a URI to the deb in
master.debian.org:~hartmans/dpkg-bug-url
I would prefer that URI not be posted in public simply to avoid exposing
our infrastructure.

Again, I'm happy to assist in any way I can and would appreciate any
help you can provide.

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

[Sam Hartman]

I heard back from doko today.  We can expect a reply tomorrow.  We also
talked briefly about the issue.

Realistically, i cannot imagine the TC coming to any final decision on
something like this in under three weeks.  That timeline seems fairly
aggressive actually.

However, I think the TC could act much more quickly in an interim
capacity.
I personally believe that having packages building is a better interim
state than the status quo.  There are risks to an interim measure.  We
could have packages in the archive that build but fail to function
correctly.  Depending on what we do long term, we could end up replacing
packges currently in Stretch with packages we can no longer rebuild.
I personally think that when I weigh those risks against my estimate of
their probability, I think it makes sense to adopt an interim measure.

Roughly I propose to override the maintainer and permit an NMU to be
made for this issue.
The decision stands until the maintainer fixes the bug or Stretch
releases, or another resolution is passed (presumably with a more
permanent decision).
Yes, that means that the maintainer could reintroduce the bug and revert
the NMU immediately on the release of Stretch.
First, I hope even the TC can act quickly enough that we're not using an
interim measure then.
Second, I think that's actually appropriate.  The justification for an
interim measure is the impending freeze.  Once we get Stretch out, this
issue is still important, TC involvement may be necessary, but there is
no reason to cut process corners.


I propose to be very agressive in calling for a vote on the following
ballot.
I plan to call for a vote in 24 hours if I get support from at least one
TC member and no objections from within the TC or release team.
In that assumption is a belief that I'll have a chance to review the
patch and the upstream bugzilla discussion prior to calling for a vote.
If I don't have time to do that, I will delay, although I would not
object to someone else who has done the review calling for a vote.
Also, within that time, we should hear from doko.  His input may change
my thinking even for an interim measure.

I want to stress this is only my interim thinking.
This is in the TC git; feel free to fix/amend as necessary.


In #850887, the Debian Technical Committee was asked to choose a
solution for #840227, a bug that prevents a significant number of
packages from building on the mips architecture.  Given the upcoming
Stretch freeze, this issue is urgent.

As an interim measure, using its powers under section 6.1.4 of the
Debian Constitution, the Technical Committee overrules Matthias
Klose's decision to revert the NMU of binutils fixing #840227.  The
committee requests Lisandro Damián Nicanor Pérez Meyer to make a new
NMU fixing #840227.

The committee requests the release team to support the interim nature of this 
solution and if a permanent solution is adopted before the release of Stretch, 
to consider including that solution in Stretch even if the freeze criteria 
would not normally permit such consideration.

In addition, the committee requests the stable release managers for Stretch to 
consider including the eventual upstream solution for this issue into a stretch 
update.

This interim decision stands until the release of Stretch, until it is replaced 
by resolution, or until the binutils maintainer fixes #840227 in some other 
manner.



Choice 1:  Approve the Resolution (3:1 majority)

Choice 2: Reject this Interim Measure

Choice 3: Further Discussion



I've included a separate reject and FD choice to distinguish "we need
more info for deciding on an interm solution even" from "we have enough
info and this approach is bad."


signature.asc
Description: PGP signature

Bug#850887: Decide proper solution for binutils' mips* bug

[Sam Hartman]

Hi.
I'd really appreciate comments from debian-release on this issue.
Would debian-release like us to take this up?
If so, I have a proposal for how to fast-track this situation, but I am
only comfortable doing that if the release team is involved.

Bug#850887: TC Involvement: MIPS and binutils

[Sam Hartman]

>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> 
>>>>> writes:

Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote:
>> Hi.
>> 
>> As you are probably aware, the question of what to do about
>> linking on mips and stretch has been referred to the TC.  There's
>> a reasonable probability that we're going to want to move very
>> quickly on this issue, and I wanted to reach out to you and see
>> how we could best work with you to collect your input.
>> 
>> I'd be happy to set up an IRC discussion, to set up a phone call,
>> etc.  I think that might work better than an email discussion,
>> because the email discussion might involve a number of round
>> trips.  I'd be happy to work one-on-one and summarize
>> results/provide logs back to the entire TC, or to set up
>> something open to as many people as we can.  Also if there's a TC
>> member you'd rather work with than me, I'm sure we'd be happy to
>> facilitate this.
>> 
>> I'm hoping that you will be able to quickly work with us to
>> understand this issue and your position.

Lisandro> Hi Sam! I think an IRC discussion will be the best choice
Lisandro> here as my phone lines are really not reliable at all :-(

Lisandro> I'll be online from 17:30 UTC onwards, nick lisandro on
Lisandro> freenode.

that was to doko not you.
I'd be happy to chat, but you've articulated your position fairly well.
If there's stuff not in the bug you'd like me to know about I'd be happy
to set things up, but from the bug logs, your position seems fairly
simple.
Let's see if my summary is accurate:

* This bug is creating a number of ftbfses, particularly for
  larger//more complex libraries on mips.

* You have a preferred minimal work-around you tried to upload

* Doko requested you not upload something until it was patched upstream.

* You want a solution sooner than that.

Is that approximately correct?

Bug#850887: TC Involvement: MIPS and binutils

[Sam Hartman]

Hi.

As you are probably aware, the question of what to do about linking on
mips and stretch has been referred to the TC.
There's a reasonable probability that we're going to want to move very
quickly on this issue, and I wanted to reach out to you and see how we
could best work with you to collect your input.

I'd be happy to set up an IRC discussion, to set up a phone call, etc.
I think that might work better than an email discussion, because the
email discussion might involve a number of round trips.
I'd be happy to work one-on-one and summarize results/provide logs back
to the entire TC, or to set up something open to as many people as we
can.
Also if there's a TC member you'd rather work with than me, I'm sure
we'd be happy to facilitate this.

I'm hoping that you will be able to quickly work with us to understand
this issue and your position.

Thanks for your consideration,

--Sam

Bug#850887: Decide proper solution for binutils' mips* bug

[Sam Hartman]

As a FYI, Matthias wrote to me in IRC just now indicating that  he plans
to upload a patch in the next couple of days.
(He needs to get to the location where he has the right environment
before preparing the upload).

As such, I'm planning on holding off on calling for any votes.

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

[Sam Hartman]

> "Ian" == Ian Jackson  writes:


Ian> You should explicitly state whether you want this NMU to be
Ian> DELAYED.

Good point.
I think we don't want a delay.
Updated the ballot in git.

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

[Sam Hartman]

> "Josh" == Josh Triplett  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.

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

[Sam Hartman]

I'll note that the practice of hard-coding paths is fairly common.


One common cause for this is programs that don't want to rely on PATH
for calling exec.  Systemd is a particularly interesting example.
ExecStart and related arguments in systemd units are required to include
full paths.

I am very uncomfortable with the idea of setting policy here.  I find I
tend to agree with Daniel's position a bit more than Ian's.
In particular, I definitely think that for closely-related versions of
software, making sure the same versions are used is helpful.
I've hurt myself more by having parts of something built in /usr/local
than I have not being able to override things for debugging.
However, I
think that both parties have valid points.
So, I'd be much more comfortable if we wanted to help make people more
aware of the tradeoffs than I would setting policy.

Bug#841294: Global Ballot Thoughts

[Sam Hartman]

Like you I want to see global6 for stretch.
I'm not sure I want to see it bad enough to override someone.
I'd rank doing so above FD though but below a pure advice option.

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

[Sam Hartman]

> "Ron" == Ron   writes:

Ron> Hi OdyX,

Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud wrote:
>> Hi there,
>> 
>> I've been mostly VAC, and only now found enough time to properly
>> read through this bug log. In the interest of transparency and to
>> help the TC reach a consensus (also through understanding what
>> the other members' understanding, ideas and positions are), here
>> comes my current understanding of the problem at hand.
>> 
>> As preamble, I will upfront state that I have _not_ looked in the
>> precise details of the so-called 'htags' functionality, as, the
>> rest will show, my current viewpoint on the problem is that it
>> doesn't matter.

Ron> If we run with your proposal, what are you actually suggesting
Ron> we tell the people who'd be upset by the loss of htags without
Ron> notice in Stretch?  Because I don't really see how you've
Ron> addressed that here.

Ron, thanks for working with the process.

I think that one thing you sometimes find when you try and build
consensus is that your conception of the problem and even the values by
which a solution should be judged is not shared.

As I understand it, you believe we should be evaluating the technical
options and that preserving things that work is of high value.

I think a lot of us believe that get newest code  is a presumptive value
especially over the multiple releases time frame.

That is, I disagree with you that I need to address the question of
htags and figure out whether htags users are being impacted.
That might have been true for one release.
But over a longer time frame, the really strong presumption is that we
prefer a version that is being actively developed to one that isn't.
That if people won't step forward and maintain htags, it goes awy.

That's a presumption.  If someone gets evidence that htags is heavily
used, we can consider that.
We might even go so far given sufficient evidence to decide that forking
global and never taking a new upstream was the right answer for our
users.  That would take a lot of evidence.

I disagree with your approach that the people wanting to remove htags
need to show that it is being used.  I disagree with your view that over
the timescales involved, people wanting a new upstream need to justify
that.

Yes, removing htags creates a regression.

Yes, I'm effectively saying "If you're using htags, sucks to be you.  If
you're willing to spend effort maintaining a version of htags that is
secure, then we might be able to bring it back.

Yes, it's possible that we'll learn we broke things and need to revert.

But I think what you're getting here from a lot of people is a belief
that our community norm strongly favors active development and new
software.  And sometimes when features are effectively not maintained in
a manner that we can package them, they go away.

I don't think it's reasonable to defer this to upstream and wait until
upstream removes htags.

I have tried to understand the technical issues.  I'm not sure I'm 100%
in agreement in your analysis there, but I'm fairly close.  However, I
haven't found the technical issues tend to affect my analysis of what
Debian should do.


I'd strongly urge you to work on a global6 package.  I don't care
whether it's called global or global6.  I don't think it should include
insecure cgi scripts that are enabled by default.  I'd be fine if it
didn't include htags at all.
I'm not saying upload that package now; I'm not saying where to upload
it.
(Although I wouldn't object to an upload to experimental or unstable)
I think having that package ready and keeping options open as long as
possible would help preserve our ability to work through this process.
I hope that would go a long way to addressing people's feelings of
frustration.

Thanks for your consideration,

--Sam

Bug#841294: Global Ballot Thoughts

[Sam Hartman]

I'd really like to see the TC offer at least the following advice:

1) We believe that strong evidence is required to hold back integrating
new versions of software like global.  The burden of proof is on those
who propose not to update, not on those who would like Debian to contain
current upstream features.

2) This burden has not been met with regard to htags and regressions
related to htags.

3) Delays in discussion of this issue over the year suggest that having
more people involved in maintaining the global package would help
address  a perception that the maintainer is blocking forward progress.

I don't think I'd support giving global to someone else.  I don't think
we even need to say "Ron you did something bad."  I do think that Ron
contributed to  a harmful perception that damages those who would use and
contribute to global in Debian.
I think taking steps like involning others in the process would be good
in fighting that perception and would be good for the package at a
technical level.
If we can find a path forward that gets a new global into Debian, I'd be
happy only offering advice.  If we get stuck doing that, I think we need
to overrule something.

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

[Sam Hartman]

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.

Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools

[Sam Hartman]

So,
can we (Debian) support SSL 1.1 with Shibboleth?
That is, are the patches something you're comfortable integrating as
Debian?

Bug#842497: [INTL:de] German translation is missing again

[Sam Hartman]

> "Chris" == Chris Leick  writes:


Chris> Hi,

Chris> It seams, that the German translation isn't included in
Chris> version 1.15-1. Is there an issue with the translated file?
Chris> Please let me know, if I can help. The

You filed a substantially similar bug on the previous version and never
replied to my question there.

Why does it look to you like the German translation is not included?
As best I can tell it is being included.

Bug#841294: Global Ballot Thoughts

[Sam Hartman]

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

Ian> Sam Hartman writes ("Bug#841294: Global Ballot Thoughts"):
>> Like you I want to see global6 for stretch.  I'm not sure I want
>> to see it bad enough to override someone.  I'd rank doing so
>> above FD though but below a pure advice option.

Ian> Why are you prepared to override[0]

I am not prepared to override  those seeking global6 either.

Ian> but not prepared to override

Ian>   Ron Lee

Because in this instance I believe giving advice is going to be
sufficient to get action.
If some reasonable version of global6 doesn't happen post haste, I could
change my mind in the order of a week or two.

Ian> Have you been reading debian-project ?
No.

Bug#841294: Global Ballot Thoughts

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> I know that you do not _set out_ reinforce Ron's position of
Ian> power over his victims.  That is not your goal.  You are trying
Ian> to come to an amicable settlement.  You are trying to get
Ian> everyone to be nice.

Ian> But when people are being oppressed, it is quite wrong to make
Ian> the feelings of the perpetrator a primary consideration.  First
Ian> help the victims, by relieving them from the grasp of their
Ian> oppressor.

I disagree with the idea that this situation is about an aggressor and
victims.
I agree such situations exist.  I do not think this situation currently
is such a situation.

That is key to my position.

I do not think engaging furthure on this point will serve this
discussion.

Bug#841294: Global Ballot Thoughts

[Sam Hartman]

So, does someone want to propose a resolution so we can move this
forward?

Bug#846002: blends-tasks must not be priority:important - ballot proposal

[Sam Hartman]

Is our intent to override the maintainer or provide advice?
I don't care what the answer is but perhaps we want to be clear.
I'm fine with this ballot beyond that.
Perhaps we want to override the blends-tasks maintainers to the extent
that they disagree with the tasksel maintainers?

Bug#766298: An update on trust router and release status

[Sam Hartman]

There was a trust router release in October.
At one level, this release is probably functional enough that it would
be nice to have included in stretch.
At another level,there have been enough upstream bugs files that I
don't think it's stable enough to include and support for the lifetime
of stretch.

However, I think  we're in a good position to put something into
experimental (and then stretch-backports) very soon.  Also, now that
freeradius 3 is in Debian, we should be able to get that infrastructure
enabled.
I think shortly after the release of buster, we can close this bug and
let moonshot-trust-router migrate into testing.

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

[Sam Hartman]

> "Ole" == Ole Streicher  writes:

Ole> We already have more that 5700 popcon-counted installations
Ole> with the blends selection in the installer. This should give
Ole> some base for that.

Hi.
Speaking with my TC hat on.
I don't find quoting popcon stats useful.  You've used them to support
the claim both that this is important and that users don't find it
confusing.
I understand your reasoning for why you believe that the popcon stats
argue this is not confusing.
I think your reasoning rests of the false assumptions that users are
likely to report bugs when they find something confusing.
In my experience that's not the case.  Instead, they are likely to get
grumpy and decrease their overall confidence in some software.
Users cannot be counted on to proactively report confusing aspects of
software.

I find the claim that this is important because of the popcon numbers
vaguely dubious as well, but it's harder to justify my concern.

At least for me though, every time you quote popcon numbers, I take you
less seriously.

Bug#858970: please add /etc/krb5.conf.d

[Sam Hartman]

control: -1 severity wishlist
> "Timo" == Timo Aaltonen  writes:

Timo> Please add /etc/krb5.conf.d directory to the package and an
Timo> include directive in krb5.conf so that other packages can
Timo> provide snippets under the directory. 

Bug#859243: please include tmpfiles.d snippet for OTP rundir

[Sam Hartman]

my initial reaction is that it seems like freeipa should stick freeipa
sockets in  /run/freeipa not /run/krb5kdc.
However, it looks like the OTP plugin in the MIT code looks at this
patch although it doesn't create a socket there.
Note to myself for when I look at this bug after stretch release.

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

[Sam Hartman]

It's almost certainly impossible to get 1.15.1 into a point release of
stretch.
I think though the interesting question is whether this fix should go
into stretch.
In general, only important or release critical fixes  can be included
after the freeze.
When you filed this bug as normal rather than important, I assumed you
were saying that when you considered the severity it really met the
criteria for important severity.
I was on the fence about the issue, and decided to take your lead.
Without real users actually claiming the issue met the criteria for
important, I wasn't going to push for it or do the work to prepare a fix
for stretch.


So, how big of a deal is this for you and your organization?  How easy
is the work around of not relying on DNS to deploy?

Bug#860767: Failure to bind to addresses on some ipv4 only configurations

[Sam Hartman]

package: krb5-kdc
version: 1.15-1
severity: important
tags: fixed-upstream

krb5-kdc can fail to work at all on some systems where getaddrinfo(NULL)
returns a v6 wildcard address.
Depending on kernel modules and socket configuration, you can get
address family not supported  even though v4 is working.

You'd think that  you could then explicitly configure a wildcard
address.
That doesn't work because pktinfo ends up not being used on an
explicitly configured wildcard address.
See upstream bugs  8530 and 8531

Bug#860520: Voting for TC Chair

[Sam Hartman]

> 
> 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 > F >  D > C = E  = A = G


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

[Sam Hartman]

> ===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 B > A

My vote is not a comment on any specific candidate.
As I've examined this process, I've grown increasingly  uncomfortable
with it.
One thing worked better this year than any year I've previously been
involved in: the TC got a larger pool of nominees to choose from.
Unfortunately, for me, that underscored some deeper problems in the
process.

* For the most part, the TC is choosing based on name recognition.
  Private discussion within the TC suggested this is how some members
  were making their decisions.  That's not an approach that lends itself
  to increasing diversity or to building the best organization.

* The TC doesn't have information (and doesn't seem to know how to get
  information) to do better than name recognition plus a brief search of
  contributors.debian.org.  I don't know how to solve this.

* The TC takes too long.  The time from when people are nominated to
  when the election results come out is enough to sap the joy and
  interest from potential candidates.
  People join the TC burned out.
  It goes down hill from there.

I look forward to serving with David, and if anything this year's
process may be slightly better than previous years.
That said, I just couldn't bring myself to affirmatively support this
process.
I am not trying to block the process.  If this were a consensus action
not a vote, my approach would be to "stand aside," rather than to
"block" or "be part of the consensus."


signature.asc
Description: PGP signature

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

[Sam Hartman]

OK.
OK.
If a couple of folks indicate this is an issue for them then it's a
simple enough fix it could be uploaded during the stretch lifecycle.

Bug#871908: dgit fails to work when .git is a reference not a directory

[Sam Hartman]

Hi.  I will check this later today once I finish catching up from
debconf at $dayjob.

That said:

1) I did already confirm that if you handle .git correctly, everything
else works.  That is, I moved the git directory to be a directory,
changed .git/config to remove a no-longer-necessary override of the
working tree, and dgit (up through push) worked great.


2)
If you want to produce a test case for this, her's how; it's easy.

I assume you already have a dgit-compatible repository in /git/package

git init subproject_test
cd subproject_test
git submodule add /git/package package
cd package
git checkout master

You'll be in a directory configured as I described in the original bug
report.


But again, yes will test later today.

Bug#871908: dgit fails to work when .git is a reference not a directory

[Sam Hartman]

Hi.
I tested with  dgit 4.1 and it worked well enough to dgit build-source.
I did not check through a full push mostly because I don't have any
packages to push ATM.
However if it works that well, I think it is conclusive.

Bug#871909: dgit gbp-build fails if user specifies --git-builder

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Mon, Aug 14 2017, Ian Jackson wrote:

>> There are three situations I think:
>> 
>> 1. fetch.  There is a pristine-tar branch available somewhere.
>> You want to avoid downloading the .orig, and instead use
>> origtargz from the pristine-tar branch.

Sean> This is what Sam wants.

Not really.
What I want is I have a clone of a maintainer branch of a dgit
repository. It's got a pristine-tar branch.  For whatever reason I don't
have the tarball checked out.

I guess I might end up doing a dgit pull before my push, I haven't used
dgit often enough to know whether I am going to want that regularly or
not.

What I know I want today is a way to generate the tarball so that dgit
build-source or dgi- sbuild will succeed.

origtargz works great for this: I didn't know of its existence.

>> 2. push.  You have a local pristine-tar branch and are making a
>> new upstream version.  You do not have the .orig as a file.  You
>> want to synthesize the .orig for the upload.

Sean> gbp already has very good support for this.  I don't think it
Sean> would be wise to add anything to dgit.

This is very close to my use case.
I'm happy to use gbp's support for this so long as I can use sbuild as a
builder alongside gbp.


>> 3. origless workflow.  You have a pristine-tar branch and want to
>> avoid having origs hanging around.

Sean> I don't know of anyone who does this -- people don't usually
Sean> think of pristine-tar as a tool for this purpose.

Well, I consider orig.tar.gzs and dscs to be cached items: it's OK to
delete them at any time.
So, I tend te delete them regularly assuming that they can be
regenerated.
But I don't mind needing to regenerate them.

Running origtargz before dgit sbuild is probably fine for me, although
I'll note that it was nice that gbp buildpackage did this for me.

Bug#871720: stretch-pu: package krb5/1.15-1

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I'd like to propose an update for a couple of bugs in krb5.  There's
one security DOS that DSA and I decided is not worth an advisory.
The other bugs are regressions over the krb5 in Jessie.  They were fixed before 
stretch released, but I wanted to get a bit more experience with the patch.  
The patches have been in an Ubuntu SRU and unstable/buster for a while and so I 
think we have confidence in them now.

Improved v6 support broke some v4-only configurations.

Also, OTP support broke if you were using KDC location via SRV
records.  Since that's basically how everyone locates KDCs these days,
that meant OTP was fairly close to completely broken.

Diff attached produced by
git diff debian/1.15-1..debian/1.15-1+deb9u1 debian

I'm using a DPM work flow, and that diff seems to be the cleanest diff
for actually reviewing the changes of a debdiff or a diff of the full
git trees.

Even so, it appears that git has changed how much data it includes in
index lines in diffs and so there's a bit of churn in the existing patches.  
I've reviewed the entire diff and the churn is just in indexb lines.

diff --git a/debian/.git-dpm b/debian/.git-dpm
index c6910273e0..ac1df21a22 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-7f866a47894f28f3065936d45de17e3e2df9ab18
-7f866a47894f28f3065936d45de17e3e2df9ab18
+ae9e8a761c3518843c4b94484c3d095320f1f7bd
+ae9e8a761c3518843c4b94484c3d095320f1f7bd
 33a6a841b455f9d0fbc6a1bd5463d3960d5b95fe
 33a6a841b455f9d0fbc6a1bd5463d3960d5b95fe
 krb5_1.15.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index ab1e7df019..06e64454e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+krb5 (1.15-1+deb9u1) stretch; urgency=high
+
+  * CVE-2017-11368: Remote authenticated attackers can crash the KDC,
+Closes: #869260
+  * Upstream patches to fix startup if getaddrinfo() returns a wildcard v6
+address, and to fix handling of explicitly specified v4 wildcard
+address; regression over previous versions, Closes: #860767
+  * Fix SRV lookups to respect udp_preference_limit, regression over
+previous versions with OTP, Closes: #856307
+
+ -- Sam Hartman <hartm...@debian.org>  Wed, 09 Aug 2017 12:19:50 -0400
+
 krb5 (1.15-1) unstable; urgency=medium
 
   [ Benjamin Kaduk ]
diff --git a/debian/patches/0010-Initial-German-translations.patch 
b/debian/patches/0010-Initial-German-translations.patch
index e7d5011e59..0c7d198a54 100644
--- a/debian/patches/0010-Initial-German-translations.patch
+++ b/debian/patches/0010-Initial-German-translations.patch
@@ -13,7 +13,7 @@ modified 2016-11-04 to actually build the German catalogue.
  create mode 100644 src/po/de.po
 
 diff --git a/src/po/Makefile.in b/src/po/Makefile.in
-index fdaf872..6753447 100644
+index fdaf872a16..6753447dc7 100644
 --- a/src/po/Makefile.in
 +++ b/src/po/Makefile.in
 @@ -18,7 +18,7 @@ ETSRCS=  
$(BUILDTOP)/lib/gssapi/generic/gssapi_err_generic.c \
@@ -27,7 +27,7 @@ index fdaf872..6753447 100644
  .po.mo:
 diff --git a/src/po/de.po b/src/po/de.po
 new file mode 100644
-index 000..fd199b3
+index 00..fd199b372a
 --- /dev/null
 +++ b/src/po/de.po
 @@ -0,0 +1,9301 @@
diff --git a/debian/patches/debian-local/0001-Debian-HURD-compatibility.patch 
b/debian/patches/debian-local/0001-Debian-HURD-compatibility.patch
index 790400e806..bd93b76813 100644
--- a/debian/patches/debian-local/0001-Debian-HURD-compatibility.patch
+++ b/debian/patches/debian-local/0001-Debian-HURD-compatibility.patch
@@ -18,7 +18,7 @@ Patch-Category: debian-local
  8 files changed, 30 insertions(+)
 
 diff --git a/src/clients/ksu/ksu.h b/src/clients/ksu/ksu.h
-index ee8e9d6..695305f 100644
+index ee8e9d6a0f..695305fe7d 100644
 --- a/src/clients/ksu/ksu.h
 +++ b/src/clients/ksu/ksu.h
 @@ -56,6 +56,10 @@
@@ -33,7 +33,7 @@ index ee8e9d6..695305f 100644
  extern int optind;
  extern char * optarg;
 diff --git a/src/include/k5-int.h b/src/include/k5-int.h
-index 6499173..63c509a 100644
+index 64991738a3..63c509a2a1 100644
 --- a/src/include/k5-int.h
 +++ b/src/include/k5-int.h
 @@ -580,6 +580,9 @@ extern char *strdup (const char *);
@@ -47,7 +47,7 @@ index 6499173..63c509a 100644
  #ifdef HAVE_SYS_FILE_H
  #include/* prototypes for file-related
 diff --git a/src/kadmin/ktutil/ktutil_funcs.c 
b/src/kadmin/ktutil/ktutil_funcs.c
-index 20a348c..b8b61ce 100644
+index 20a348c805..b8b61cef84 100644
 --- a/src/kadmin/ktutil/ktutil_funcs.c
 +++ b/src/kadmin/ktutil/ktutil_funcs.c
 @@ -33,6 +33,10 @@
@@ -62,7 +62,7 @@ index 20a348c..b8b61ce 100644
   * Free a kt_list
   */
 diff --git a/src/lib/gssapi/spnego/spnego_mech.c 
b/src/lib/gssapi/spnego/spnego_mech.c
-index 9d6027c..585d8a6 100644
+index 9d6027ce80..585d8a6581 100644
 --- a/src/lib/gssapi/spnego/spnego_mech.c
 +++ b/src/lib/gssapi/spnego/spnego_mech.c
 @@ -65,6

Bug#871908: dgit fails to work when .git is a reference not a directory

[Sam Hartman]

> "Ian" == Ian Jackson  writes:


That bug appears to be about a case where there are submodules in the
repository I give to dgit as input.
My case is different.
I have a super-repository of a lot of related packages with each
submodule corresponding to one complete Debian package.
It seems like this case is

1) different

and 2) easier than

that other bug.

In particular, dgit never needs to deal with more than one git
repository, it never needs to interact with subproject commits, etc.

If you agree, what would be a title that's more clear about the issue
here?
If not, what am I missing?

Bug#871908: dgit fails to work when .git is a reference not a directory

[Sam Hartman]

package: dgit
version: 3.12


If you git clone --recursive a project including submodules, you tend to
get all the submodule git directories under .git/modules in the master
git directory.
Then you get a .git file in the submodule working tree that looks a lot
like this:
hartmans@permutation-city:libradsec(1082)> cat .git
gitdir: ../.git/modules/radsecproxy


dgit fails with this... for example:

hartmans@permutation-city:libradsec(564)> dgit -wdd --dpm gbp-build
--git-builde
r=sbuild -c sid
dpkg-buildpackage: info: source package libradsec
dpkg-buildpackage: info: source version 0.0.5-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Sam Hartman
<hartm...@debian.org>
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean  --with autoreconf --parallel
   dh_testdir -O--parallel
   dh_auto_clean -O--parallel
   dh_autoreconf_clean -O--parallel
   dh_clean -O--parallel
mkdir .git/dgit: Not a directory at /usr/share/perl5/Debian/Dgit.pm line
216.


(As a side note the only reason I'm using gbp-build rather than sbuild
is to deal with pristine-tar.  If dgit would support pristine-tar I
could avoid gbp entirely)


Thanks for a great product!

--Sam

Bug#871909: dgit gbp-build fails if user specifies --git-builder

[Sam Hartman]

package: dgit
version: 3.12

What I'm really trying to do is to have dgit build my package with
sbuild, checking out the pristine-tar if necessary.
Why do I like that better than dgit fetch to guarantee I have the
tarball?
Well, perhaps I trust my local state more than the archive (I understand
I'll eventually get an error if they disagree) or perhaps I want to
avoid the download for bandwidth reasons.

I tried dgit gbp-build --git-builder=sbuild but that fails because dgit
passes -uc and -us to sbuild, which doesn't recognize them as options.

Recommendation: if the user passes --git-builder as a gbp-build option,
perhaps dgit shouldn't pass builder-specific options.

Alternatively, you can say that I shouldn't pass git-builder, but if
you're going to say that, I'd appreciate some mechanism to accomplish my
pristine-tar goal.
I guess I can also run gbp buildpackage without dgit, and that'll mostly
work for me, but it seems not entirely desirable.

Bug#872056: jessie-pu: package krb5/1.12.1+dfsg-19+deb8u2

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi. I'd like to get some security updates that were not serious enough
for a DSA into jessie.  The security team encouraged me to make this
request, so they are in the loop, but have not reviewed the diff or the 
specific set of cves fixed.

Diff produced with git diff dgit/dgit/jessie debian after looking at
git diff --numstat dgit/dgit/jessie to make sure that all the changes
outside of debian were because of new applied patches.  Also confirmed
that dgit quilt-fixup shows no changes between the produced source
package and my tree.

I've confirmed this builds, but have not reviewed the diffs
line-by-line (although all these changes are shipping in stretch or
sid now) and have not finished my testing.
I'll do both of those things before uploading.

diff --git a/debian/changelog b/debian/changelog
index d90f21581b..6aa052a1c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+krb5 (1.12.1+dfsg-19+deb8u3) jessie; urgency=high
+
+  * CVE-2017-11368: Remote authenticated attackers can crash the KDC,
+Closes: #869260
+  *  fix for CVE-2016-3120 (kdc crash on restrict_anon_to_tgt), , Closes:
+#832572
+  * fix for CVE-2016-3119: remote DOS with ldap for authenticated
+attackers, Closes: #819468
+  * Prevent requires_preauth bypass (CVE-2015-2694), Closes: #783557
+  
+ -- Sam Hartman <hartm...@debian.org>  Sun, 13 Aug 2017 18:02:34 -0400
+
 krb5 (1.12.1+dfsg-19+deb8u2) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff --git a/debian/patches/fix-ldap-null-deref-on-empty-arg-cve-201.patch 
b/debian/patches/fix-ldap-null-deref-on-empty-arg-cve-201.patch
new file mode 100644
index 00..f1f5ff13a8
--- /dev/null
+++ b/debian/patches/fix-ldap-null-deref-on-empty-arg-cve-201.patch
@@ -0,0 +1,37 @@
+From: Greg Hudson <ghud...@mit.edu>
+Date: Mon, 14 Mar 2016 17:26:34 -0400
+X-Dgit-Generated: 1.12.1+dfsg-19+deb8u3 
f7e4ca67d86a5a5b280b859072bbc5015a2ddd27
+Subject: Fix LDAP null deref on empty arg [CVE-2016-3119]
+
+In the LDAP KDB module's process_db_args(), strtok_r() may return NULL
+if there is an empty string in the db_args array.  Check for this case
+and avoid dereferencing a null pointer.
+
+CVE-2016-3119:
+
+In MIT krb5 1.6 and later, an authenticated attacker with permission
+to modify a principal entry can cause kadmind to dereference a null
+pointer by supplying an empty DB argument to the modify_principal
+command, if kadmind is configured to use the LDAP KDB module.
+
+CVSSv2 Vector: AV:N/AC:H/Au:S/C:N/I:N/A:C/E:H/RL:OF/RC:ND
+
+(cherry picked from commit 08c642c09c38a9c6454ab43a9b53b2a89b9eef99)
+
+ticket: 8383
+version_fixed: 1.14.2
+
+(cherry picked from commit b5abd8c4872d7a024d49439342a6643f774afb1c)
+
+---
+
+--- krb5-1.12.1+dfsg.orig/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c
 krb5-1.12.1+dfsg/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c
+@@ -268,6 +268,7 @@ process_db_args(krb5_context context, ch
+ if (db_args) {
+ for (i=0; db_args[i]; ++i) {
+ arg = strtok_r(db_args[i], "=", _val);
++arg = (arg != NULL) ? arg : "";
+ if (strcmp(arg, TKTPOLICY_ARG) == 0) {
+ dptr = >tktpolicydn;
+ } else {
diff --git a/debian/patches/fix-s4u2self-kdc-crash-when-anon-is-rest.patch 
b/debian/patches/fix-s4u2self-kdc-crash-when-anon-is-rest.patch
new file mode 100644
index 00..4b63bd8ee0
--- /dev/null
+++ b/debian/patches/fix-s4u2self-kdc-crash-when-anon-is-rest.patch
@@ -0,0 +1,51 @@
+From: Greg Hudson <ghud...@mit.edu>
+Date: Tue, 19 Jul 2016 11:00:28 -0400
+X-Dgit-Generated: 1.12.1+dfsg-19+deb8u3 
862d5e532d03db566ee2955f69e008a253d39dec
+Subject: Fix S4U2Self KDC crash when anon is restricted
+
+In validate_as_request(), when enforcing restrict_anonymous_to_tgt,
+use client.princ instead of request->client; the latter is NULL when
+validating S4U2Self requests.
+
+CVE-2016-3120:
+
+In MIT krb5 1.9 and later, an authenticated attacker can cause krb5kdc
+to dereference a null pointer if the restrict_anonymous_to_tgt option
+is set to true, by making an S4U2Self request.
+
+  CVSSv2 Vector: AV:N/AC:H/Au:S/C:N/I:N/A:C/E:H/RL:OF/RC:C
+
+(cherry picked from commit 93b4a6306a0026cf1cc31ac4bd8a49ba5d034ba7)
+
+ticket: 8458
+version_fixed: 1.14.3
+
+(cherry picked from commit 85c3046d42eeb821967ad5625fcb08e8c6177b1a)
+
+---
+
+--- krb5-1.12.1+dfsg.orig/src/kdc/kdc_util.c
 krb5-1.12.1+dfsg/src/kdc/kdc_util.c
+@@ -688,7 +688,7 @@ validate_as_request(kdc_realm_t *kdc_act
+ return(KDC_ERR_MUST_USE_USER2USER);
+ }
+ 
+-if (check_anon(kdc_active_realm, request->client, request->server) != 0) {
++if (check_anon(kdc_active_realm, client.princ, request->server) != 0) {
+ *status = "ANONYMOUS NOT ALLOWED";
+ return(KDC_ERR_POLICY);
+  

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

[Sam Hartman]

I'm not actually sure I particularly want it removed from the system.
It's fair that it should be removed on purge though and I'll at least do
that.

Bug#868035: krb5: [patch]: ldap sasl auth support

[Sam Hartman]

Thanks for bringing this to my attention.
I'll definitely fix, although I'll end up applying a somewhat different
patch because of the build profiles support included in 1.15.1.  SASL,
like LDAP would create a cycle in stage1 builds.

I expect a new version soon.
I don't have a good test environment for this, so I'm unlikely to check
it myself.