Bug#866712: moonshot-gss-eap FTBFS on arm64: libeap/src/utils/common.h:429:0: error: "__bitwise" redefined [-Werror]

[Sam Hartman]

I'm starting the process of updating to new upstream.
I think that is reasonably likely to fix this.  If not, I'll look into
the issue after the update.
I'm OK if moonshot-gss-eap falls out of testing for a few weeks.

--Sam

Bug#869260: CVE-2017-11368

[Sam Hartman]

I can absolutely prepare a stable point update request for stretch.
Is there still going to be a last point release to jessie?
If so I'll look into that too; I'd definitely like to get an update in.

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Sam Hartman]

I'll remove it in purge.; there's another bug open effectively for that.
However, I think it is generally a good thing if the file exists.
Because of the dpkg bug we no longer install it, but I think our users
are better served by leaving the file on upgrades.

Bug#869260: CVE-2017-11368

[Sam Hartman]

Take a look at  the stretch branch of
git://git.debian.org/git/pkg-k5-afs/debian-krb5-2013.git

Shall I upload that to stable-security?

Bug#869260: CVE-2017-11368

[Sam Hartman]

Actually, on that note, why does this bug merit a DSA?
It like the other bugs is a simple KDC crash from an authenticated
attacker.
It seems like it should be handled the same.

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

[Sam Hartman]

   === Resolution ===

   The Technical Committee recognises that circumstances change in ways
   that make previous resolutions no longer appropriate.  In 2012, it was
   resolved that the nodejs package should not provide /usr/bin/node due to
   the historical conflict with the ax25-node package.  Node.js is still
   quite popular and the ax25-node package is no longer in stable, testing
   or unstable so the requirement for nodejs to not provide /usr/bin/node
   no longer applies.

   The Committee therefore resolves that:

   1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.

   This means Debian's normal policies and practices take over and the
   nodejs package is free to provide /usr/bin/node.  The migration should
   be managed according to Debian's usual backwards-compatibility
   arrangements.

   === End Resolution ===

   R: Approve resolution and repeal the CTTE decision from 2012-07-12.
   F: Further Discussion

I vote R>F


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Petter" == Petter Reinholdtsen  writes:

>> I think shortly after the release of buster, we can close this
>> bug and let moonshot-trust-router migrate into testing.

Petter> Did this time arrive?
Mostly.
I'm working through all the moonshot software  and updating it to new
upstream versions.
moonshot-ui has a new version in experimental.
Working on moonshot-gss-eap, then will work on moonshot-trust-router.

I don't see a reason not to let the new moonshot-trust-router into
testing at least for now.
Near the freeze I'll coordinate with upstream about whether we're
willing to support that version of the protocol for a full Debian
release.

Petter> There is also the OpenSSL 1.1 issue, bug #828441.  -- Happy
Petter> hacking Petter Reinholdtsen

Yep.
That shouldn't be a big problem.

Bug#872760: asterisk-opus: uninstallable in unstable

[Sam Hartman]

Package: asterisk-opus
Version: 13.7+20161113-3
Severity: grave
Justification: renders package unusable


The asterisk package in unstable provides
asterisk-1fb7f5c06d7a2052e38d021b3d8ca151

but asterisk-opus depends on asterisk-fa819827cbff2ea35341af5458859233

It looks like this is a system that is very locked to the specific
build of asterisk.  I wonder whether merging the asterisk and
asterisk-opus package using the 3.0 package format's features for
additional source component tarballs might not be a more appropriate
packaging strategy.  Meanwhile, this is clearly broken as it cannot be
installed.

Bug#863260: kstart: k5start does not recognize network changes

[Sam Hartman]

I wonder if your nss stack is somehow caching something about the
network and the name servers and that kstart process is no longer able
to resolve KDCs.
It would be interesting to set KRB5_TRACE to a file, run kstart such
that it is failing and see what specifically is not working.
My bet is on DNS

Bug#862051: Refer #862051 to ctte

[Sam Hartman]

> "David" == David Bremner  writes:

David> Philip Hands  writes:
>> I presume we'd want to continue providing /usr/bin/nodejs for
>> people that have switched to using that, so that might as well
>> continue to be the name of the binary, since that gives us a
>> 'node' symlink that is self-documenting.

David> That sounds plausible to me. I don't think it matters which
David> one is the symlink. For some some reason, on my own system I
David> have a shell script called node in my path that execs nodejs,
David> that also seems to work fine.

I to agree that node can refer to node.js.

Bug#836127: Call for Votes for new TC member

[Sam Hartman]

===BEGIN
The Technical Committee recommends that Niko Tyni  be
appointed by the Debian Project Leader to the Technical Committee.

N: Recommend to Appoint Niko Tyni 
F: Further Discussion
===END

I vote N>F


signature.asc
Description: PGP signature

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Sam Hartman]

control: severity -1 normal

Will remove this file early in buster.

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious
Helmut> libgssapi-krb5-2 is a shared library package and contains
Helmut> /etc/gss/mech.d/README. The latter filename does not depend
Helmut> on the soname of the library and thus does not change when
Helmut> the soname changes.

Hi.

I'm going to start by  explaining why that file is there and asking for
your help in figuring out what to do.
I'm then going to argue that this is not an RC bug (probably not even a
bug at all).
But I'm more interested in finding a solution that works for us both
than simply closing bugs because I can.

The issue is that older versions of krb5 had two related problems with
regard to /etc/gss/mech.d:

1) They only supported a config file for reading mechanism config, not
an entire directory

2) Because of a bug in how I set prefix, they read /usr/etc/gss/mech not
/etc/gss/mech as that config file.

Nothing shipped /usr/etc/gss/mech on Debian--it's clearly not
FHS-compatible.

However, there are some gss mechanism packages, mostly not in Debian,
that need to configure themselves even on older krb5.
I needed a way to figure out whether the gss library was new enough to
read /etc/gss/mech.d.

So I dropped a README in that directory.  Code that detects that file
and uses it as a flag not to create and write /usr/etc/gss/mech has
escaped.  The main culprit is moonshot-gss-eap (especially versions not
in Debian), but I've recommended the approach to others and not tracked
where all it might be being used.

I think we can move away from that approach for stretch +1, but I really
kind of need that file to be there, and I'm quite uncomfortable trying
to get the replaces/conflicts/provides dance correct this late in the
stretch cycle.


So, that's why I care about the file for stretch, and why I want to be
careful about a fix.

I claim this is not a violation of policy 8.2.  In particular, It seems
very likely that if the soname of libgssapi_krb5 changes, you'll need
different mechanism configuration for the new version.  It seems very
unlikely that the same mechanism will work for GSS v2 and v3.  So, I'd
expect the directory to be /etc/gss3/mech.d or /etc/gss/mech3.d, and if
the readme were retained, I'd expect it to be in that new directory in
the new library.

That said, I'll note that libgssapi_krb5.so.2 has been stable since
before the release of Kerberos 1.0 back in 1995.  A change in gss's
soname is going to be a huge massive pain in all sorts of ways if it
ever happens, and I don't think having to deal with one README is going
to even make the headache list.

You said that you're running into dpkg issues.
I'm sympathetic to that, but I'd like to find a way that your needs and
mine can both be met.

--Sam

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

[Sam Hartman]

There's a new upstream for moonshot-trust-router that I believe should
work with openssl 1.1.
Realistically, I should be able to deal with moonshot-gss-eap #848680
within a month.
I think it may be more like two months to deal with both
moonshot-gss-eap and moonshot-trust-router, both of which have new
upstreams.
Right now, neither is in testing.  I expect Buster to be the first
release to include moonshot-trust-router and definitely plan to get
moonshot-gss-eap back into testing for Buster, but I'm not bothered if
moonshot-trust-router spends a month FTBFS because you remove openssl
1.0.


--Sam

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

[Sam Hartman]

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


Didier> For good reasons, Debian forcibly introduced a special-case
Didier> when Node.js first appeared in a stable release through only
Didier> shipping it under /usr/bin/nodejs.  That forced hundreds of
Didier> projects to cope with that, probably often through
Didier> supporting both /usr/bin/node and /usr/bin/nodejs I suspect.

Right.
I think we introduced the special case for good reason, so I think we
should have a good reason to remove it.
When we introduce an interface, we should only break it with cause.
I don't personally think the esthetic cleanlyness of removing one
symlink from the filesystem and the infrastructure from the source
package to create it is worth the cost of breaking people who have come
to depend on the interface we created.

There is a significant difference between this and cleaning up
maintainer scripts.
Here we created the interface not just within our own packaging, but
also for our users to use.

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

[Sam Hartman]

> "Thorsten" == Thorsten Glaser  writes:

Thorsten> Hi,
>> * Restore /usr/bin/node following CTTE #862051 Let's try to drop
>> /usr/bin/nodejs before buster.  Replaces and Conflicts
>> nodejs-legacy.  Closes: #754462.

Thorsten> please do NOT completely replace an ABI between releases.
Thorsten> Leave /usr/bin/nodejs there for at least one more release.


I agree.
Even if you get everything in Debian fixed, you won't know about user
scripts that have been designed around what Debian does.
Giving people a release to deal with transitions is a great thing to do
when there's no good reason not to.
Maintaining a symlink for a release seems a low cost.

For that matter I really can't see a good reason to ever drop the
symlink.

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

[Sam Hartman]

OK, let's give the security team some context.

RFC 2744 specifies some kind of unfortunate behavior for  error
handling.

gss_init_sec_context and gss_accept_sec_context have an in/out context
parameter (pointer to pointer).
You initialize the pointed to value to null the first time through.
It gets set to some allocated context handle.
But you'll probably call gss_init_sec_context and gss_accept_sec_context
in a loop.

It gets unclear what should happen if it fails after the first time.
Are you supposed to call the free function or not?
The fact that I can 't remember how you figure out what you should do is
an indication of how obscure it is.

A lot of applications screw this up and either leak or double free
sometimes.
I'm a little confused why double free is a big deal, because I'd think
you'd end up calling gss_delete_sec_context on NULL in that case and it
could just ignore a delete of null.

Anyway, the upstream change  forces the code to follow a SHOULD in RFC
2744 and leave it up to the caller to free the context always.

The code was correct before and after this change.  However, after this
change more application code is expected to be correct.  Code that isn't
correct is likely to just leak memory.

However, this is a behavior change.  It's possible that if we bring this
back to stable we'll find it causes some theoretically broken
application to be broken in practice as well as theory.

--Sam

Bug#876927: moonshot-ui FTBFS with vala 0.36

[Sam Hartman]

I suspect the version in experimental with work with vala 0.36, but will
confirm that.

Bug#872760: asterisk-opus: uninstallable in unstable

[Sam Hartman]

OK, if the checksum doesn't change regularly, I can understand why  the
current arrangement makes sense.

It would bxe great to get asterisk-opus rebuilt though:-)

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

[Sam Hartman]

I just uploaded the jessie update after fixing the extra comma in the
changelog.  I did run tests covering these security updates.  I found
that some of the tests included in make check were already failing on
jessie and were still failing after this update.  It looks like this may
be related to patches being pulled into what became the jessie release
without all the corresponding testsuite changes also being pulled in.
As an example I got a segfault in some of the profile tests and the
GSS-API s4u tests cause a crash calling a method that doesn't seem to
exist on the krb5 mechanism in this version.  Everything I found
app.appears to be testsuite (rather than functional code) problems
already in jessie and appears far from the code being touched by this
update.

--Sam

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

[Sam Hartman]

Wait...
Is that actually even legal under RFC 1964?
Doesn't this lead to leaks for correctly written applications?

--Sam

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

[Sam Hartman]

Ah, looked at the commit.
Yeah.
This makes sense.

This is somewhat of a behavior change.
Do we want to just bring this into unstable, or do we want to backport
it to stable releases?
It seems like there is a possibility of problems in either direction.

Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Sam Hartman]

> "Julien" == Julien Puydt  writes:

Julien> Hi, Le 31/08/2017 à 13:52, Jérémy Lal a écrit :
>> How about printing a "nice" warning explaining it would be a good
>> idea to move to /usr/bin/node ? Then in next next release drop
>> the nodejs symlink.

Julien> May I suggest to have /usr/bin/nodejs print a nice
Julien> deprecation warning to use /usr/bin/node, and just *never*
Julien> remove it?

Having it print a deprecation warning will break pipes or other
situations where stdout and stderr are captured.
I'd just use a symlink.
We have release notes and debian/news for warnings if we believe that's
the right approach.

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

[Sam Hartman]

> "Dominique" == Dominique Dumont  writes:

Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser wrote:
>> > How about printing a "nice" warning explaining it would be a
>> good idea to > move to /usr/bin/node ?
>> 
>> That will break scripts that do:
>> 
>> x=$(nodejs somescript)

Dominique> This kind of script won't break if the deprecation
Dominique> warning is sent to STDERR


Sigh.
I wish I had seen your message before your earlier reply.
This breaks too in more complex situations involving ssh, things like
expect scripts and the like.
There are cases where people mix stderr and stdout.  There are cases
where people treat any unexpected output on stderr as a failure in
automated scripts.

The next level you can look at is considering whether /dev/stdin in a
tty and printing the warning to either stderr or /dev/tty only in that
case.
And that will reduce the breakage but not remove it.
And yes, when you actually have something it's important to deprecate,
accepting some level of breakage and adopting one of those strategies is
the right thing.

It's just not worth it in this case.
People who use more than Debian are very quickly going to learn that
/usr/bin/node is preferred to /usr/bin/nodejs.
As several people have already pointed out we've far exceeded the amount
of effort in considering whether to deprecate or remove the link that
will be spent maintaining the link until the end of time.
In one sense we've already lost:-)

Bug#829671: Custom real addition doesn't seem to work

[Sam Hartman]

Hi.
d-i preseeding.
I'd be happy  to work with you if we can remove that from the equation.

I'd also be interested in why DNS srv lookups aren't good enough for
you.
If I had krb5-config to do again, I probably wouldn't support adding
realms at all.

The goals of krb5-config may not be entirely what you are hoping for.
I'm happy to engage in a design discussion about what those goals should
be, but let me explain my current thinking.

Above all, it's desirable to respect any changes that the user has made
to krb5.conf.

We only add a realm, never updating it if it is there.

The config script wants  to make sure that servers are not updated for
the right realm.  So, it tracks two wvalues.
There's krb5/add_servers, which is a boolean about whether to add
servers
and krb5/add_servers_realm, which is the realm about which that boolean
is asked.
If krb5/add_servers_realm ever differs from the default realm, then we
forget any questions about servers we've asked previously because we're
asking them about a different realm.

>For seeding a config I'd expect you to need to set read_config to false,
default_realm to your realm, add_servers to true and add_servers_realm
to your default realm.

I'd be very open to discussing better ways to do this.

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

[Sam Hartman]

Hi.
It looks like there hasn't been much traffic on this issue in the last
couple of weeks.

My analysis is that the key technical point here is whether it's
acceptable to treat unknown devices as possible modems.

It sounds like:

1) We don't have a good white list of modems.

2)  We don't have an adequate blacklist of modems.  Ian argues we never
will have an adequate blacklist of modems.

It sounds like Aleksander is saying that from Modemmanager's standpoint
assuming unknown devices aren't modems would produce an unacceptable
user experience.

Ian is saying that even if we do everything we can to reduce the false
positive rate, treating some non-modems as modems has unacceptable
consequences.

Have I got that right?

In going forward, I think it is important to consider that
Modemmanager's needs and Debian's needs may be different here.
In the case of Modemmanager as an upstream project, it may be desirable
to give the best experience for users who do have modems.
However, for Debian and for the Technical committee, we need to consider
what experience we want to give all our users and as a result value
damage caused by false positives more highly than the upstream project
might.

--Sam

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

[Sam Hartman]

> "Aleksander" == Aleksander Morgado  writes:

>> In going forward, I think it is important to consider that
>> Modemmanager's needs and Debian's needs may be different here.
>> In the case of Modemmanager as an upstream project, it may be
>> desirable to give the best experience for users who do have
>> modems.  However, for Debian and for the Technical committee, we
>> need to consider what experience we want to give all our users
>> and as a result value damage caused by false positives more
>> highly than the upstream project might.

Aleksander> Would the new approach satisfy Debian's needs?

So, I'm only one member of the Debian technical committee.

I suspect that since the matter has been referred to us, we're likely to
rule.
I haven't seen other TC members   give opinions.  Myf suspicion is that
we're likely to try and give general guidelines to the Debian
modemmanager maintainers and let them choose a specific solution.

I'd be happy with guidelines that  said something along the lines of
by default, programs in Debian should not access a  serial device unless
they have high confidence that such a device is the kind of device they
are trying to use.
I know that sounds horrible and we'd have to word-smith it into
something that people could understand without being part of this
conversation.

I'd expect that if the guideline were along those lines, the Debian
modemmanager maintainer would conclude that the new approach was
sufficient.  I suspect if someone brought it back to us later we'd
support such a conclusion from the maintainer.

If you don't see action before then, I expect we'll have some internal
discussion in our next meeting near the end of October.

--Sam

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Hi.  In #877024, the TC was asked to rule on whether modemmanager should
continue to probe USB devices that might not be modems.

There's been significant involvement from upstream leading to a new
optional behavior that is less aggressive about probing unknown devices.

Would it help the maintainer for the TC to rule on this issue?

Do you have any input into the TC process you would like to give?

Thanks,

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Unfortunately, krb5-config is used fairly widely by software not in
Debian.
In the past krb5 has been fairly conservative, which in this case would
mean having krb5-multidev depend on krb5-multidev-bin for a release.
If we did that we would have a solution for buster+1 to make
krb5-multidev m-a installable.

Obviously we could be less conservative here.

I'd rather find a more clever solution.
Is there any way to map back from CC to something useful as an
installation architecture?
I'd prefer something that worked both for gcc and llvm.

My hope is to do something like

* install krb5-config.mit

* have that be a script that calls krb5-config.mit.tripple

* Each package only includes krb5-config.mit.tripple for the appropriate
  architecture.

If we can make that work, does that make people happy?
Do we have any thoughts on how to make that work?

Bug#882867: krb5-kdc: cannot write to default log location

[Sam Hartman]

Hi.
When I install krb5-kdc, it logs to syslog not to /var/log/krb5kdc.log.
Where in the files installed by the krb5-kdc package are you seeing
configuration to install to /var/log/krb5kdc.log.
I agree upstream configures (or in some cases recommends configuring)
things that way, but I'm not seeing that in the Debian package.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

As you can tell I did not get around to looking at this last weekend.
The US holiday ended up taking up more time than I anticipated, and then
I got sick.  This week my day job is taking up all my time; hope to have
some Debian cycles next week.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

So, I'm uncomfortable making a long-term promise to support krb5-config
in a multi-arch environment.
Today, the multi-arch change is easy to work with.
However, it seems entirely reasonable that the recommended cppflags and
cflags  might differ between architectures, and I don't know that I want
to sign up for the work involved in supporting that long-term.

This sounds like a wishlist bug on the face of it.  But it sounds like
you view it as more important.
so, why don't you take this opportunity to try and sell me on how cool
multi-arch is for krb5 dev packages and why it provides Debian with neat
enough capabilities that I want to commit to supporting it.

Regardless of how convincing you are, I can apply this patch for now,
but I may label multi-arch support for the -dev packages as experimental
and subject to future removal if it proves to require more effort than
the package maintainers want to spend.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Thanks.
I'll take a look next week.
This looks very promising.
Unless I'm missing something, I think you've done a lot of the work
regardless of whether we want to wrap krb5-config architecture scripts
or wrap a script that calls cross-pkg-config.


Why do you want to replace krb5-config with pkg-config?
That seems like a good option if we can sell upstream on the idea, but
something requiring more thought otherwise.

Are there advantages/simplicities in coding that led you to that
approach?  I'd like to understand so I can evaluate.

less good options
i'm a bit concerned that getting the behavior of all the different
--libs options for the different types of Kerberos apps will be a bit
fiddly.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

>> But how can we link this output to CC?

Russ> That's a trickier question, since I'm not sure Autoconf or
Russ> make alway exports the current compiler as the CC environment
Russ> variable in all the ways krb5-config is called now.  But at
Russ> least we do have a fighting chance of picking up the correct
Russ> compiler, and worst case we fall back to the default compiler.

Also, if we're moving away from krb5-config, the only strong requirement
is that krb5-config work correctly on the native architecture.
We'd like it to work in other cases, but if we're OK telling people who
are cross-compiling to use pkgconfig then it's OK if krb5-config is
imperfect.
While I think we can do better, even just having unqualified
krb5-config.mit be for the native architecture would not make things
worse than today.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

control: tags -1 -patch
control: severity -1 wishlist


> "Russ" == Russ Allbery  writes:

Russ> Hugh McMaster  writes:
>> The packages krb5-multidev and libkrb5-dev are not multi-arch
>> installable.

>> A diff of the i386 and amd64 variants of krb5-multidev reveals a
>> file conflict in /usr/bin/krb5-config(.mit).

>> The -L$libdir option causes this conflict, due to the hard-coded
>> /usr/lib/ path.

>> On Debian, this path is not needed to link with libraries in
>> /usr/lib/. So I have attached a patch removing this
>> option, 
Russ> Removing this option will break krb5-multidev.  It will no
Russ> longer be possible to build software against MIT Kerberos with
Russ> only krb5-multidev but not libkrb5-dev installed, which is the
Russ> whole point of krb5-multidev.

In particular, it is not -L /usr/lib/triplet, but
/usr/lib/triplet/mit-krb5, which for obvious reasons is not included by
default in the Debian linker.

Russ, I'm feeling really embarrassed that I didn't notice wthis.


Russ> I'm not sure how best to fix this other than no longer using
Russ> krb5-config and shipping a pkgconfig script or something.

we do ship a pkg-config script and that handles this correctly.
How does pkg-config figure out which arch you're building for?

I wonder if there is some way we can detect what arch to use from what
CC is set to.

Eventually we may get to a place where we can remove krb5-config from
krb5-multidev and depend on pkgconfig, but as Russ hints I don't think
we are there today.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

So, I finally got a chance to look at this.
It sounds like you're taking a significantly different approach than we
had discussed earlier.

What we had talked about is parsing the output of $CC.  For example
asking gcc what tripple it was built for and going from there.

But what you did is assume that the gcc path encodes the tripple with
the special case of supporting -m32 assuming that it is the first option
in $CC (and not say in $CFLAGS).

It looks like this was probably a bit easier to code, but looks like it
has the following weaknesses:

* Assumes that -m64 is always on a x86_64 system rather than using gcc
-m64 to build for x86_64 on an 686 system.

* assumes that -m32 and -m64 are only used on x86 architectures

* Mishandles setups where rather than set all the compiler variables, a
  directory including cross tools is prepended to PATH

Are there advantages beyond implementation simplicity over what we
talked about previously?

Bug#848680: moonshot-gss-eap cannot migrate to openssl 1.1.0 prior to xmltooling

[Sam Hartman]

control: affects -1 moonshot-gss-eap
control: block -2 with -1


Hi.
I will shortly be uploading a version of moonshot-gss-eap that is happy
to build against either openssl 1.1 or openssl 1.0.
Unfortunately, it won't actually build against openssl 1.1 because
dependencies on libxmltooling-dev will force it to openssl 1.0.

So, in order to have a moonshot-gss-eap that builds against openssl 1.1,
we'll need to get xmltooling fixed.

Bug#848680: Bug#859831: moonshot-gss-eap cannot migrate to openssl 1.1.0 prior to xmltooling

[Sam Hartman]

>>>>> "Cantor," == Cantor, Scott <canto...@osu.edu> writes:

Cantor,> On 10/30/17, 4:36 PM, "Pkg-shibboleth-devel on behalf of
Cantor,> Sam Hartman"
Cantor,> 
<pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org
Cantor,> on behalf of hartm...@debian.org> wrote:

>> So, in order to have a moonshot-gss-eap that builds against
>> openssl 1.1, we'll need to get xmltooling fixed.

Cantor,> The version of Shibboleth that supports 1.1 will be out
Cantor,> some time next year, and I can't put much of a time frame
Cantor,> on it beyond that. I doubt it will be June, but I also
Cantor,> doubt it will be January.

Nod. I've actually been following this list and am aware of where things
stand.
Assuming that  the SSL maintainers move at the speed they are hoping to
move, Shibboleth will be pulled from Debian testing in about a month.

My understanding is that the patches already exist, but effort didn't
exist within Debian to do a good job of taking those patches ourselves
at least the last time this was discussed on the list.

Moonshot can technically be built without Shibboleth.  That kind of
cripples especially the acceptor, but it does build.  I'll talk to the
moonshot community about whether it would be better for Moonshot to
remain out of testing (it got pulled because of an arm64 issue) or
whether having a crippled version that works well as a client but not
great as a server would be better.

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Like Ian, I honestly don't know what the rules are in this situation.

Wou/ld it be reasonable for him to make an NMU to experimental, and then
if there is no objection after testing to unstable?
In parallel, it seems desirable to see if any of the maintainers are
active.

--Sam

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Sam Hartman]

>>>>> "Benjamin" == Benjamin Kaduk <ka...@mit.edu> writes:

Benjamin> On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
>> 
>> There are basically three "strengths" of random numbers available
>> now:
>> 
>> Weak: /dev/urandom Medium: getrandom(flags=0) Strong:
>> /dev/random, getrandom(flags=GRND_RANDOM)
>> 
>> k5_get_os_entropy() has switched from weak/strong depending on
>> the "strong" flag to always medium.  I think what you actually
>> want is medium/strong.

Benjamin> At high risk of opening up the RNG debate that I did not
Benjamin> want to revisit, the current stance of upstream krb5 seems
Benjamin> to fall into what I'll call the "Schneier worldview", that
Benjamin> a fully-seeded well-designed CSPRNG can produce arbitrary
Benjamin> amounts of random output with no need to track "entropy
Benjamin> depletion" or similar (emphasis on fully-seeded).  So the
Benjamin> question (for them) is not "strong" or "weak", but rather
Benjamin> "fully seeded" or "not seeded yet".

OK, I'm happy with this model.  It's certainly along the lines of what I
had in mind when I wrote some of the interfaces we're talking about.

Benjamin> In this worldview, if
Benjamin> you have to choose between /dev/random and /dev/urandom,
Benjamin> (1) /dev/random is the only thing that actually provides
Benjamin> the guarantee you want, but (2) /dev/random is incredibly
Benjamin> painful for using "all the time", so you're tempted to use
Benjamin> /dev/urandom for cases where it's "less important", like
Benjamin> session keys, but reserve /dev/random for times when you
Benjamin> really care about the "fully seeded" property, like
Benjamin> long-term keys.  When those were the only choices, the
Benjamin> 'strong' flag made sense.

Benjamin> Now, we have getrandom(), which is a great API and is
Benjamin> pretty much exactly what you want (again, at least in this
Benjamin> worldview).  IIUC Ted says that you should "just use
Benjamin> getrandom" for your entropy needs and not worry about
Benjamin> /dev/*random.  I don't know whether he takes a stance on
Benjamin> the GRND_RANDOM flag, though.

And I think that's fine for kadmind.
I think there's a very real practical question about whether you want
the KDC to fail to start if your RNG is not seeded.
Having your KDCs be unavailable from a cold start of an environment is a
really big thing.

Benjamin> Anyway, I mention this all in the hope that we can just
Benjamin> drop this line or discussion and let upstream krb5 decide
Benjamin> what properties they want from a CSPRNG, and not try to
Benjamin> revisit that design.

To the extent that it impacts our jobs as system integrators to actually
provide an enterprise system that has availability, I don't think we
can.


Benjamin> To answer Sam's questions, in the above worldview, the
Benjamin> right answer for the KDC and the right answer for kadmind
Benjamin> are the same -- just use getrandom().  It provides the
Benjamin> output of a high-quality CSPRNG, and is guaranteed to
Benjamin> block until fully seeded.  In this worldview, the
Benjamin> cryptographic quality of the (fully seeded) urandom pool
Benjamin> is more than adequate, so there's no need to ever pass
Benjamin> GRND_RANDOM.

To be clear I'm fine with that as far as it goes.
My concern is simply that we (Debian) need to consider the availability
question.

I know that upstream did not seriously consider that question when we
first adopted the Schneier world view.  I don't know if upstream has
adequately considered that since, and if they have whether their design
tradeoffs are the same as we as Debian have.

I do really appreciate your reframing the question though because I
think availability vs strength will be an easier design discussion than
quality of random numbers and entropy.

Benjamin> I'm certainly open to having krb5 ship a proof-of-concept
Benjamin> wait-for-entropy.service in unstable for a while, though
Benjamin> it seems like something better suited for libc or systemd
Benjamin> core for the long term.

Benjamin> If we need to for stretch, it would presumably be easy
Benjamin> enough to just add a stanza to the KDC's unit file to
Benjamin> increase the timeout (though how do we know what sort of
Benjamin> timeout is "long enough"?).

Agreed.

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Sam Hartman]

I'm returning from vacation and jumping into the middle of this.

Back in the day when I wrote the code that became k5_get_os_entropy we
viewed two cases:

* kadmind.  There we're likely to sometimes be generating long-term
  shared secrets, and it seemed like strong random numbers were
  important.

* krb5kdc, where we were generating session keys used for a few hours.

It seems like the change to use the getrandom syscall or other code
changes have moved all the code  to prefer strong random numbers.
That seems problematic at startup for the KDC.

Even if we do develop  a target indicating that the RNG is seeded, do we
really want to block the KDC starup on waiting for this target?

I see a few issues here:

1)  What's the right behavior for the KDC?

2) What's the right behavior for kadmind?

3) Do we want to provide such a service in krb5-kdc or elsewhere?

4) What do we want to do about stretch?  It sounds like we need a fix
that's small enough that we can backport it to stretch and not make the
SRMs grumpy.

--Sam

Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

[Sam Hartman]

> "Niels" == Niels Thykier  writes:
control: tags -1 -moreinfo

(I hope this supplies the info you need; obviously retag if you have
more questions.)


Niels> Hi Sam,

Niels> Thanks for the bug report.

Niels> It sounds like you rather want krb5-kdc not to start on
Niels> initial installation.

That's not what I want at all.

I want to try and start it, but I don't want a failure to start to be
considered an error that causes package installation to fail.
This ended up being effectively what happened with the  sysvinit script,
but systemd is much more pro-active at noticing unit start errors.


--Sam

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Dear Ian:

I wanted to make you aware of a status update.
The maintainer who has been doing most of the uploads on modemmanager
stepped down after receiving my query.  First, I'd like to extend my
thanks to Michael for his hard work on modemmanager in the past and all
the things he continues to do for Debian.  Second, I'm glad that he
stepped aside when it was time to do so: doing that is an important part
of staying healthy.

As a matter of process, it's not clear that there's an active maintainer
of modemmanager.  Speaking as an individual, but not as a TC member (I
haven't talked to anyone else), I think it would be reasonable to treat
modemmanager as a package that is under-maintained at the moment in
which you've found a bug you care about, approaching things and
balancing the same as you might in any similar situation.

With more of a TC hat on, I am very reluctant to rule on this issue
without an active modemmanager maintainer.  I don't think there is a
compelling need to do so, and I don't want to rule out the possibility
of a modemmanager maintainer coming along later and presenting an
argument about how we should balance this issue.
I don't think the lack of a ruling will be a blocking force at the
current time.


I won't stand in the  way of other members who do want to rule on this
issue.  However, I cannot imagine getting to a point where  I'd vote
anything other than FD or defer on this issue right now

Also, as may be obvious from my previous post today, I was shaken by
some of the meta issues here.  I am much more focused at the moment on
thinking about the TC process and our community than I am about this issue.


signature.asc
Description: PGP signature

Bug#871698: upstream patch

[Sam Hartman]

I think that until the upstream release we could just increase the
length and get a fair distance.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Hi.

I like the approach of  making krb5-config not dynamic, but I'd prefer
to discover the behavior of the compiler rather than to  base our
interactions on its filename.


My plan is to use the following:
CC=${CC-cc}
tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//' 
)`
if [ x$tripple = x ]; then
echo >&2 Failed to find installation architecture
exit 2
fi


Expect an upload shortly; let me know how it works for you.

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>> ...  Given the background of build-profiles, I'm very much in
>> favor of introducing the equivalent usage as Gentoo USE flags,
>> which was its main intention! :) It could make Debian a viable
>> source-based distribution to use or base on, could make many of
>> the embedded specific distribution solutions obsolete, ...

Adrian> Who would then implement, maintain and support this in all
Adrian> packages?

No one.  People would implement and test the feature where it was
sufficiently useful to implement and test.  I don't think all of the use
flags combinations are tested in source distributions that have them
today.

Even so, users find those flags useful enough to spend a fair bit of
work on them.

A build profile seems like a great way to express the flag, and like
many things in Debian, the work would fall on those who would benefit
from it.

So, I do support the use of build profiles for use flags.
I also believe there's sufficient utility for downstreams and users to
justify this.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

>>>>> "Hugh" == Hugh McMaster <hugh.mcmas...@outlook.com> writes:

Hugh> Hi Sam, Apologies for the delay in replying. Somehow your
Hugh> message landed in my spam folder.

Hugh> On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote:
>> My plan is to use the following: CC=${CC-cc} tripple=`$CC
>> -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//'
>> )` if [ x$tripple = x ]; then     echo >&2 Failed to find
>> installation architecture     exit 2 fi

Hugh> This seems to work well for development on the host
Hugh> architecture and when setting CC="gcc -mXX". It may not work
Hugh> so well for cross-compiling, where some packages set
Hugh> CC_FOR_BUILD, BUILD_CC or some other random variable.

In the GNU model, I think that's the wrong thing to do.
I also note that every solution we've discussed has this defect.

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:


Adrian> For many use flags the only benefit is an unused library
Adrian> less on the system when the flag is disabled, and this also
Adrian> applies to the proposed nosystemd profile discussed in this
Adrian> bug.

Agreed.

Adrian> Support for nosystemd in only 95% of all libsystemd-using
Adrian> packages would still result in libsystemd being installed -
Adrian> if just one maintainer would refuse to apply a nosystemd
Adrian> patch, the people working on nosystemd in Debian basically
Adrian> have to rely on CTTE overruling the maintainer.

I disagree with this.
First, that's only true if the package in question is essential, or if
the user needs to install the package in question.

In a world where users never modify, patch or rebuild source you're
absolutely right that this only provides utility if you get 100%
coverage.

users include organizations that are willing to rebuild packages
(patching them if necessary) to meet regulatory, security, or other
requirements.  Users also include downstream distributions and their
users who  are willing to patch software.

In this world, there is siginificant utility to minimizing the number of
patches users apply.
95% coverage would be much easier to deal with than no support at all.

I feel fairly strongly about this because I have been that downstream.
I've been in situations where I was trying to get some feature into
Debian or another project.  I suspect my future includes a fair number
of cases where the future I care about involves being able to build
without some feature because doing so makes regulatory accreditation
much easier for me.

Perhaps it's not worth Debian's time to work with me.
However I'm frustrated when you claim that this only has utility to me
when Debian gets 100% coverage: minimizing divergence has real value.
Does it have enough value to justify some change to Debian?  I think we
should consider that on a case by case basis like we always do.


In the particular case of systemd, I don't have any interest in working
to make it easier to build on Linux without libsystemd installed.  I'd
probably accept patches that did not significantly increase the
complexity of my packages if they did that, but would not go write such
patches.

Bug#887810: krb5-multidev: "krb5-config.mit --cflags gssapi" returns wrong include directory

[Sam Hartman]

I am testing a fix.
My apologies for the sloppy change.

Bug#777579: Database ends up in wrong location if krb5.conf an kdc.conf differ

[Sam Hartman]

Thanks for your additional information.
I think we have a good understanding of how  this bug happens in the
case where kdc.conf and krb5.conf have conflicting realm information or
where kdc.conf does not supply the realm that the KDC is actually
serving.
My recommendation is that we look into ways to change the software so
the database ends up in the right place if the config files conflict.
It's likely you'll get other bad side effects, but this seems
particularly problematic.

--Sam

Bug#829671: Can we start depending on /etc/krb5.conf.d

[Sam Hartman]

Hi.

A while back krb5-config received a request to support /etc/krb5.conf.d
especially for custom realm configuration that requires more than just
DNS.

It looks like the Heimdal in unstable supports krb5.conf including a
config directory.  How would you feel about turning this on in the
krb5.conf shipped by krb5-config?

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Sam Hartman]

As a FYI, I did some experiments with kvm, and I do seem to have enough
entropy to get the KDC started there.

I have not played with Xen recently.  It's a bit harder to set that up,
and I'm unsurprised that might be more tricky to get randomness with
than kvm.

Bug#819017: Prod

[Sam Hartman]

My last query on this issue proposed a way forward: installing a
conffile.
I never received a reply.
If I have not received a reply by the next time I triage bugs, I'll
close this.

Bug#829749: Is there a better way to handle Kerberos ldap configuration

[Sam Hartman]

Hi.

Mostly for the slapd maintainer.
Currently krb5-kdc-ldap ships an OpenLDAP schema file for the Kerberos
schema.
I just noticed that we don't ship the ldif file for the newer format
slapd config and will be fixing that in my next upload.

Currently in order to take advantage of either, the administrator needs
to grab the schema or ldif out of /usr/share/doc/krb5-kdc-ldap and
manually process it.

Is there some way we could do better than this?  How do we handle
optional schemas in Debian?  If we don't have a better way, would you
consider a patch to support the Kerberos schema in the Debian slapd
package?

Bug#777579: Retitling

[Sam Hartman]

control: retitle -1 Database ends up in wrong location if krb5.conf an  
kdc.conf differ

control: severity -1 normal
control: tags -1 -moreinfo

I reread the long bug log.
We were never able to reproduce the user's problem.
However, the closest we were able to get is that if krb5.conf and
kdc.conf differ in what the realm should be, the results are confusing:
database in /etc/krb5kdc.

This is confusing behavior and we should look at changing it.
One solution would be to accept that without a config file stash and acl
file belong in /var/lib and then change osconf.hin to put the database
in /var/lib/krb5kdc without a config file.
We could also make a slightly more invasive patch and codify our
behavior in the code.

Ben/Russ, any thoughts?

--Sam

Bug#829749: Is there a better way to handle Kerberos ldap configuration

[Sam Hartman]

>>>>> "Ryan" == Ryan Tandy  writes:

Ryan> Hi Sam,
Ryan> On Mon, Jul 16, 2018 at 05:02:34PM -0400, Sam Hartman wrote:
>> Mostly for the slapd maintainer.  Currently krb5-kdc-ldap ships
>> an OpenLDAP schema file for the Kerberos schema.  I just noticed
>> that we don't ship the ldif file for the newer format slapd
>> config and will be fixing that in my next upload.

Ryan> Great, thanks!

>> Currently in order to take advantage of either, the administrator
>> needs to grab the schema or ldif out of
>> /usr/share/doc/krb5-kdc-ldap and manually process it.

Ryan> Yes.

>> Is there some way we could do better than this?  How do we handle
>> optional schemas in Debian?  If we don't have a better way, would
>> you consider a patch to support the Kerberos schema in the Debian
>> slapd package?

Ryan> What do you mean by "support"? I would be reluctant to add new
Ryan> schemas in an automated way - this should be an explicit
Ryan> action by the administrator. Our default configuration just
Ryan> includes the few most widely used schemas.

So, I agree administrator action should be required.
However, especially with the schema managed over the ldap protocol, I
find the process of updating a schema moderately tedious.
Mostly I'm wondering if you have considered helping the administrator
out by having a simple command they can run to enable a schema once they
have decided to do so.

Ryan> A couple of thoughts on the rest of the bug:

Ryan> Schemas are best considered as static data, rather than
Ryan> user-editable configuration. From this perspective, /usr is
Ryan> the right place for them.  (In fact, we have a long-term
Ryan> wishlist item of moving the default schemas away from /etc,
Ryan> too.)

Agreed.

Ryan> Shipping your schema uncompressed would be one way to reduce
Ryan> friction for slapd administrators but of course has a cost in
Ryan> disk space. I do think shipping the .ldif in addition to the
Ryan> .schema will already be a major usability improvement, so
Ryan> thanks for doing that!

O definitely; it was a bug we weren't doing so.  I noticed we were
shipping an ldif, but forgot it was the Novell Edirectory format not the
OpenLDAP format.

Bug#829671: Can we start depending on /etc/krb5.conf.d

[Sam Hartman]

>>>>> "Brian" == Brian May  writes:

Brian> Sam Hartman  writes:
>> A while back krb5-config received a request to support
>> /etc/krb5.conf.d especially for custom realm configuration that
>> requires more than just DNS.
>> 
>> It looks like the Heimdal in unstable supports krb5.conf
>> including a config directory.  How would you feel about turning
>> this on in the krb5.conf shipped by krb5-config?

Brian> The concept sounds fine to me. I may be restricted in how
Brian> much time I can spend on such a project however.  -- Brian
Brian> May 

No problem.
I'll lookinto it and see what's involved both on the Heimdal and MIT
side.

Bug#863260: kstart, systemd and dns

[Sam Hartman]

control: tags -1 help

Apologies for the long delay.

It looks like the problem here is in fact DNS.
It sounds like the k5start process cannot look up the IP of the KDC even
after the network comes back.

Other processes like dig function, but those processes are not making
periodic requests of the same domain entry  within the same process
while the network is down and after it comes up.

Ben and I still have not managed to reproduce this situation.

--Sam

Bug#829749: Is there a better way to handle Kerberos ldap configuration

[Sam Hartman]

> "Ryan" == Ryan Tandy  writes:

Ryan> I had not, actually. Assuming our default slapd configuration,
Ryan> adding a schema is just:

Ryan>  ldapadd -H ldapi:// -Y EXTERNAL -f /path/to/schema.ldif

Ah, looking back at my notes, you're right.  Adding the schema was easy.
The hard parts were:

* setting up a separate database because I wanted the Kerberos stuff
  isolated

* Setting up the right indexes

* Configuring access control and the appropriate SASL stuff.

And sadly, a lot of that was custom enough that I can't think of good
automation.

OK, it doesn't look like there's much to do for this bug.  I'll think
about leaving the schema and ldif decompressed.

Bug#887937: krb5-user: Should krb5-user depend on/recommend krb5-k5tls?

[Sam Hartman]

I think we should add a recommends or suggests relationship.  I'm
reluctant to add a hard dependency.  There are two issues.  The first is
that it pulls in code for people who don't need it; that's minor.  The
second issue is that krb5-k5tls is GPL-incompatible at least as we build
it because it links against OpenSSL.  The main krb5 libraries are GPL
compatible and linked to a lot of GPLed software.
So I'd prefer not to have a hard dependency.

Bug#892593: [PATCH] libverto: FTCBFS / Please add a pkg.libverto.noglib build profile

[Sam Hartman]

this approach seems a bit strange.
Why would we want a package specific build profile rather than excluding
glib from a stage1 build of libverto.

Also, note that I'm about to update to a new version of libverto and
start building for libevent.
I wonder if for bootstrapping we want to pick one single event backend
and build against that in a stage 1 build?

I need to check this, but the probable reason that I included the event
backends in the -dev package is that it is permissible to  link directly
against a plugin.
I think policy strongly implies that if a -dev package is going to have
a .so symlink for a shared library it needs to have a hard depends on
that package.
Obviously we could remove the depends when we're not building against
glib on the glib plugin, although I think that technically means that
the -dev package has different functionality depending on what build
profile is used.
Which I think is problematic for some people's view of the build profile
spec.
I think this may be an argument for revising that.

Thoughts?

Bug#892593: [PATCH] libverto: FTCBFS / Please add a pkg.libverto.noglib build profile

[Sam Hartman]

So, in general, I think picking  a single event backend should be fine.
Most applications work with all event backends; krb5 certainly does.

I'm fairly uncomfortable with the idea of using an extension package
namespace here though because  it seems like you'll need to break this
cycle on every new bootstrap, and so it seems like you want something
that can be auto-detected or similar.
krb5 took a patch for a stage1 build profile to avoid ldap and libsasl.
It seems like it's desirable to update both krb5 and libvirto to
something modern that makes sense, whatever that is.
I have not been following any of this particularly closely.

--Sam

Bug#911481: libkrb5support0:i386 has broken dependencies

[Sam Hartman]

control: tags -1 moreinfo
control: severity -1 normal

Hi.  Your bug is a little short on details, and I was not able to
reproduce.  I took a new sid chroot, added i386 as an architecture, and
installed libkrb5support0:i386 by


apt install libkrb5support0:i386
I ended up with krb5 1.16.1-1 and libkeyutils1 1.5.9-9.3

I suggest you look into why libkeyutils1 is not able to be installed in
your situation.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

Actually directly switching on vendor seems fairly bad.

However, to the extent that downstream changes can be encapsulated into
options/deltas that someone might want, I think it may often be
reasonable to carry the delta in Debian.

So imagine that Ubuntu and several other downstreams care more about
security and hardening than they do about backward compatibility and
they choose to change a number of gcc and other tool defaults in support
of that.  I realize my example is not entirely hypothetical, but I want
to emphasize I have not researched to get all the details right, because
it doesn't matter.

Especially if multiple downstreams or individual users who build from
source might want the change, I think carrying the delta in  the Debian
source package can be valuable.  It needs to be balanced against a lot
of other concerns.

However, I do tend to agree with Ian that actually turning on that delta
in a specific vendor environment may be best carrief as a
vendor-specific source package.

That said, even there there are tradeoffs.
As an example, Ubuntu tries to use unmodified Debian source packages
where possible.  In some cases I think that the maintenance advantages
of doing this and the slight but real political pressure it creates to
push changes upstream to Debian may justify switching on dpkg-vendor.

I think my point here is that there's a lot of complexity, and I'm not
even convinced it would be desirable to recommend against using
mechanisms like dpkg-vendor.
I think what we can hopefully all agree on is that the dpkg vendor patch
series as bad.
Perhaps before we go and recommend something specific we can actually
write up some of these tradeoffs and give people the information they
need to make informed decisions.

And yes, in many cases dgit is the answer.  That said, if I were
maintaining the same package both for Debian and for the downstream I
work on, I might well value having a single source tree enough to use
dpkg-vendor or lsb-release or something to switch.

Bug#904558: What should happen when maintscripts fail to restart a service

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian>  * If the maintainer has no particular reason to diverge the
Ian> right answer is usually to fail the postinst with init systems
Ian> that do not provide service supervision; but to not fail the
Ian> postinst with ones that do.  (I think from earlier messages
Ian> that this is how the default implementations already work.)

So, it's not really the case that this is the default for init systems
today, and that actually has some important historical significance and
implications for perceived user-facing changes.

It's absolutely been the case that if an init script (init.d lsb script)
fails, the default behavior was to fail the postinst.

However, start-stop-daemon did not detect a lot of failures, especially
after fork.
So, there are all sorts of  things that caused daemons to fail to start
that used to not cause postinst failures.

I don't know what the default is today, but certainly for Jessie and for
a lot of the stretch cycle, dh_installinit would fail the postinst
whenever systemctl failed to start or restart a service.

Now, depending on how you wrote your service units, you might get the
same behavior as with sysvinit.  But you probably didn't do that.
So, suddenly, a whole bunch more conditions started showing up  as
things that caused postinst to fail.

If somewhere in stretch and with the migration from dh_installinit for
service units fto dh_systemd_*, we managed to change the default, then
we're probably reasonably close to what happened in the pre-systemd
days.  And that was reasonably OK.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

>>>>> "Wouter" == Wouter Verhelst  writes:

Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
>> That said, even there there are tradeoffs.  As an example, Ubuntu
>> tries to use unmodified Debian source packages where possible.
>> In some cases I think that the maintenance advantages of doing
>> this and the slight but real political pressure it creates to
>> push changes upstream to Debian may justify switching on
>> dpkg-vendor.

Wouter> I disagree with that, because it forgets why you're pushing
Wouter> things to Debian.

Wouter> The point of pushing things upstream is so that you as well
Wouter> as upstream end up being the same, and the maintenance
Wouter> difference disappears. By switching on dpkg-vendor, you're
Wouter> *not* the same; instead, you're hiding your difference. This
Wouter> is not generally helpful; it simply moves the maintenance
Wouter> burden from Ubuntu to Debian (where it simply does not
Wouter> belong).

I think that we're agreed that evaluating the maintenance burden is
exactly the right criteria.


Imagine a case where the same folks are maintaining a package for
multiple distributions and where the difference is small but important.
In such a case I think our users and the free software community might
best be served by a single repository and switching on something a lot
like dpkg-vendor.

Imagine a case where  it's a different set of people doing the work for
Debian than the distribution that wants the change.  The Debian
maintainers are not  in a good position to test the change and have no
desire to do so.  There, switching on vendor seems like the wrong
option.

We're a group of volunteers; we encourage cross-project collaboration
and working together.  I  believe that the primary consideration should
be what reduces the burden on those doing the work.  There are secondary
considerations of course.

--Sam

Bug#904558: What should happen when maintscripts fail to restart a service

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> the error path is most important were packages that provide a
Simon> system-level API to other packages, so their failures are
Simon> likely to cause other packages to fail to configure (such as
Simon> local DNS caches and authentication services like LDAP); and
Simon> packages that provide remote access, so their failures need
Simon> to be fixed before a potentially remote sysadmin logs out to
Simon> prevent the sysadmin from being locked out longer-term (like
Simon> sshd).

As a maintainer of one of the more important packages (krb5-kdc and
krb5-admin-server), ;I'd like to chime in here.  krb5-kdc provides
enterprise level authentication and if it fails may well take out
authentication for an entire environment.

Even so,  I've found that causing upgrades to fail does far more harm
than good even for this package.

Here is my experience based on my own observations and based on bug
reports and helping people diagnose problems in krb5:

* The vast majority of failures are when krb5-kdc gets installed on a
  system where it is not actually needed, or where it was partially
  configured for  a test.  In these cases, breaking an kupgrade does
  much more harm than good.  It may break other services, because those
  services may end up in a half-configured state, so a service that is
  not critical for a given system may break critical services for that
  system.

* When krb5 is a critical service, it's failure is going to be quite
  obvious regardless of whatever the maint script does.

* It is almost always the case that debugging  the situation involves
  installing some package and that  the first thing I end up doing is
  walking a user through adding exit 0 at the top of postinst in
  /var/lib/dpkg/info before going forward.  Even if  I don't need some
  additional tool, I've been burned by other parts of the system being
  in half-configured state.

* Leaving large chunks of the system in half-configured states is about
  one of the worst things you can do for system stability.  It's not
  something we test very often, and the interactions are very difficult
  to predict.

If I understood the cause of an error in a maintainer script and knew
that it indicated a problem that the sysadmin needed to fix (and one
that likely indicated krb5 was important on this system) I would be open
to returning a failure in postinst.
In almost all other situations I'd rather simply let the service fail to
start.


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> But in the general case, I feel that downstream packaging
Wouter> changes belong downstream, not in Debian; therefore it is
Wouter> best to recommend that, in the general case, packages in
Wouter> Debian do not switch on dpkg-vendor.

Right.  Where as I believe it's not that clear cut and would rather
simply outline a bullet list of tradeoffs for maintainers to consider.

I'd be OK with a general case recommendation though; it's just not how
I'd do it if I were writing text.

And for the record, there are times when I've chosen to ship debian
directories upstream because it was the right thing in that case.
And I've dropped the upstream directory when circumstances changed.
There though, I agree with you that there is a dominant answer: don't
ship debian directories upstream.

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

latest upgrade of libkrb5-3 (1.16.1-1 -> 1.16.2-1)
>> automount starts but dies immediately after accessing a
>> automounter point.
>> 
>> Automount is configured to authenticate via GSSAPI using system
>> keytab.  After the GSSAPI authentication succeeded, any access to
>> a configure automount entry causes automount to die with an
>> assertion failure (followed by an abort()):

Adrian> Thanks for your report.

Adrian> I'm moving this bug report to libkrb5-3 since this is the
Adrian> change that triggered your regression for assessment whether
Adrian> the bug is there.

Adrian, I'm guessing you're looking at this with your QA hat on?
How well do you understand autofs?  Any chance you could help put
together a repo?  If you don't know autofs-ldap well, I can learn it
just as well as anyone, but if you do happen to know it well, help would
be appreciated.
In the latest krb5 package, the debian/tests directory contains a
slapd-gssapi test which happens to set up LDAP well enough that you can
SASL authenticate it.
So, my guess is that adapting that test to  set up an autofs-ldap that
uses gss auth to ldap probably isn't too incredibly hard.
I don't know autofs at all, and for example I don't know how to set up
the directory to have the right info.

If you or the submitter can easily help, it would be appreciated.
If not, I'll look into it.

--Sam

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

I'd value the autofs configuration much more than the directory setup
instructions.
I have no desire to go install centos7 to debug a Debian bug:-) and have
some familiarity with setting up LDAP.
What I don't have is familiarity configuring autofs.

Bug#919427: emacspeak eterm does not speak several key commands

[Sam Hartman]

package: emacspeak
severity: important
tags: patch
version: 47.0+dfsg-6

Hi.  several of the key eterm commands don't speak.
I'm opening a bug that I already have a patch for; expect a merge
request shortly.

Bug#877469: NMU diff for 1.0.23-3.1

[Sam Hartman]

Uploaded to delayed/5

diff --git a/debian/changelog b/debian/changelog
index 3f9833c..76020bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+node-websocket (1.0.23-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't run dh_nodejs against libjs-websocket, because that is an arch
+all package with no ABI dependencies.  We don't want shared library
+dependencies on an arch all package because it breaks the ability to
+do binary NMUs for library transitions, Closes: #877469
+
+ -- Sam Hartman   Tue, 11 Dec 2018 08:50:44 -0500
+
 node-websocket (1.0.23-3) unstable; urgency=medium
 
   * Team Upload
diff --git a/debian/rules b/debian/rules
index e347699..a49f49e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,9 @@ export DH_OPTIONS
 override_dh_auto_test-arch:
tap test/unit
 
+# We do not need abi dependencies for a source all package
+override_dh_nodejs:
+   dh_nodejs -pnode-websocket
 override_dh_install-arch:
dh_install
chmod 644 
$(CURDIR)/debian/node-websocket/usr/lib/nodejs/websocket/build/Release/*.node


signature.asc
Description: PGP signature

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sam Hartman]

>>>>> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> On 2018-12-11 18:26:24 [-0500], Sam Hartman wrote:
>> Fixing moonshot-gss-eap and getting a new moonshot-ui is next up
>> for me for Debian weekend tasks.

Sebastian> This means an upload from exp to unstable?

I'm not sure if that's enough, but it's certainly part of it.
There may be a bit of porting involved.

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sam Hartman]

Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
for Debian weekend tasks.

Bug#916699: Run minissdpd debconf question insufficiently detailed for an advanced user to answer it

[Sam Hartman]

package: minissdpd
version: 1.5.20180223-3

Hi.  Minissdpd got pulled in on an upgrade from stretch to buster by
something--I haven't bothered to check why.  I have my debconf priority
set to medium and I got asked whether I wanted to start minissdpd
automatically.
That's fine: I asked for more questions and I got them.
However, the question didn't explain what minissdpd was, why I might
want it, and on a typical system what the consequences of not running it
might be.

You need to write debconf questions targeted both at someone who
explicitly asks for your package and that roughly knows what it is as
well as for someone who gets a package pulled in by someone else.  I'm a
fairly advanced user; I know what UPNP is c.  So, I'm not asking you to
make a medium/low priority question something a novice user could
answer, but I am asknig you to include enough detail that I can probably
answer it and definitely know what to google.
It wasn't even clear that the question was from the minissdpd package.

--Sam

Bug#915007: opensaml2 FTBFS with xmltooling 3

[Sam Hartman]

Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the
removal requests.
They are both basically broken in unstable, so there's no reason to
block.

Bug#915007: opensaml2 FTBFS with xmltooling 3

[Sam Hartman]

Built fine I have not yet tested against moonshot

On December 3, 2018 8:52:10 AM EST, "Cantor, Scott"  wrote:
>On 12/1/18, 4:48 AM, "Pkg-shibboleth-devel on behalf of wf...@niif.hu"
>on behalf of wf...@niif.hu> wrote:
>
>> Please let me know if you need any help; for example I can see that
>> version 3 of the resolver uses pkg-config for finding the SP, which
>is
>> cool in principle but nobody tested it in Debian yet, so that may
>> uncover bugs lower in the stack.
>
>Finding the SP is probably fine, but both the SP and that library had a
>lot of very difficult to test changes to the autoconf handling around
>GSS-API, and that's where your problems will probably crop up.
>
>-- Scott
>
>
>___
>Pkg-shibboleth-devel mailing list
>pkg-shibboleth-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shibboleth-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#916047: csound: regression in String handling

[Sam Hartman]

package: csound
version: 1:6.12.2~dfsg-1
severity: important
justification: Regression over stretch with insidious and
hard-to-diagnose consequences



I noticed that  my orchestras were failing on several sound files after
upgrading to buster, and tracked it down to some cases of  filenames
being input in the score file.

Consider the following orchestra and score:

Orchestra:

0dbfs=1
sr=44100
nchnls=4
instr 1, 10
Sfile strget p4
amic = 0
a1, a2 diskin Sfile, 0.997, -2.3

vincr amic, a1
outq amic, amic, amic, amic
endin


Score:


i 10.000244140625 10.135534524917603 -1 "/home/hartmans/.cache/djcli/Bobina - 
Music Box (Album Mix).wav" 1 1.0 10.135534524917603 0.0 422.2395255249176 1.0 0 
50 1.0
f0 20.0


Stretch Behavior:
(csound 6.08)
0dBFS level = 1.0
orch now loaded
audio buffered in 256 sample-frame blocks
ALSA output: total buffer size: 1024, period size: 256 
writing 1024 sample blks of 64-bit floats to dac 
SECTION 1:
B  0.000 .. 10.136 T 10.136 TT 10.136 M:  0.0  0.0  0.0  0.0
new alloc for instr 10:
WARNING: instr 10 uses 4 p-fields but is given 13
diskin2: opened '/home/hartmans/.cache/djcli/Bobina - Music Box (Album 
Mix).wav':
 48000 Hz, 2 channel(s), 19778664 sample frames
B 10.136 .. 20.000 T 20.000 TT 20.000 M:  0.87332  0.87332  0.87332  0.87332
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score.  overall amps:  0.87332  0.87332  0.87332  0.87332
   overall samples out of range:0000
0 errors in performance
Elapsed time at end of performance: real: 19.972s, CPU: 0.963s
3446 1024 sample blks of 64-bit floats written to dac
hartmans@mount-peerless:djutils(6)>
Buster behavior:

0dBFS level = 1.0
orch now loaded
audio buffered in 256 sample-frame blocks
ALSA output: total buffer size: 1024, period size: 256
writing 1024 sample blks of 64-bit floats to dac
SECTION 1:
WARNING: Buffer underrun in real-time audio output
B  0.000 .. 10.136 T 10.136 TT 10.136 M:  0.0  0.0  0.0  0.0
new alloc for instr 10:
WARNING: instr 10 uses 4 p-fields but is given 13
INIT ERROR in instr 10 line 7: diskin2: /home/hartmans/.cache/djcli/Bobina - 
Music Box (AlbumMix).wav: failed to open file (No Error.)
 from file test.orc (1)
a1  a2  diskin  Sfile   0.997   -2.2998224  0   0   
0   0   0   0   
  B 10.136 - note deleted.  i10 had 1 init errors
B 10.136 .. 20.000 T 20.000 TT 20.000 M:  0.0  0.0  0.0  0.0
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score.  overall amps:  0.0  0.0  0.0  0.0
   overall samples out of range:0000
1 errors in performance
Elapsed time at end of performance: real: 20.006s, CPU: 0.901s
3446 1024 sample blks of 64-bit floats written to dac
hartmans@mount-peerless:djutils(7)>



Somehow in the buster code path, The space between Album and Mix has
been removed and the filename has become corrupted.
Note that the buster code path works fine if  you hard code the sound
file name in the instrument.
It's something to do with the score file that is problematic.

I apologize that the score is a bit complex; it's obviously extracted
From some more complex code.  My typical orchestra is quite complex and
I wanted to get things down to an debuggable minimal example, but I also
wanted to  use the production score file.
I'm also attaching the score as a mime attachment because it is a rather
long line.


score
Description: Binary data


signature.asc
Description: PGP signature

Bug#916066: csound regression: zir opcode appears entirely broken; hangs instrument

[Sam Hartman]

package: csound
version: 1:6.12.2~dfsg-1

I was experiencing strange failures with orchestras with csound 6.12 and
eventually I've tracked it down to the zir opcode to read a value from
zk-space at i-time.

It's fairly basic: the zir.csd from the csound examples fails to print
out anything  in the instrument that runs zir.
Based on what I've seen the instrument hangs (or aborts without a note
aborted message).

This is bad because it doesn't look like there's any way to read a
zk-value at I time without that opcode.
I guess you could play reinit games, but ugh.

Interestingly, Debian doesn't seem to be shipping zir.csd or really most
of the examples.
We used to, as I got them somewhere, and they're really useful.
I'm not seeing any license problems, so it would be cool if we either
shipped them or documented why not.
Anyway for completeness I'm attaching zir.csd.

This works on stretch.


; Select audio/midi flags here according to platform
; Audio out   Audio in
-odac   -iadc;;;RT audio I/O
; For Non-realtime ouput leave only the line below:
; -o zir.wav -W ;;; for file output any platform



; Initialize the global variables.
sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

; Initialize the ZAK space.
; Create 1 a-rate variable and 1 k-rate variable.
zakinit 1, 1

; Instrument #1 -- a simple instrument.
instr 1
  ; Set the zk variable #1 to 32.594.
  ziw 32.594, 1
endin

; Instrument #2 -- prints out zk variable #1.
instr 2
  ; Read the zk variable #1 at i-rate.
  i1 zir 1

  ; Print out the value of zk variable #1.
  print i1
endin





; Play Instrument #1 for one second.
i 1 0 1
; Play Instrument #2 for one second.
i 2 0 1
e

Bug#915639: Apologies for shibboleth-resolver FTBFS

[Sam Hartman]

Hi.

I am not sure how I managed to produce the binary package for amd64.  I
*thought* that I used sbuild in a clean sid chroot to do so, but it's
quite clear from trying to reproduce that that I failed.  I'm somewhat
baffled because my work flow makes it hard for something not coming out
of sbuild with a clean chroot to end up in the right place to be
uploaded, but it's certainly the case that the dsc I uploaded simply
does not work.

I regret that the package was so broken and that I managed not to catch
it.  I did intend to avoid the obvious failure of building on my host
system, and I thought I had a work flow that was not vulnerable to
screwing that up.
Anyway, apologies that you had to waste your time on my error.

Bug#867945: Working on porting to libsecret

[Sam Hartman]

I'm working on porting moonshot-ui from gnome-keyring to libsecret.
It's somewhat involved because upstream needs to support both
interfaces--they have a long tail of operating systems they need to work
on.  Also, the existing code could use some refactoring to be cleaner.

I'm probably 70% of the way through coding this but the results will
need to be tested.
I anticipate being able to get moonshot-ui back into buster testing
(without gnome-keyring) in time to make the freeze.

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

So what's happening here is  that a k5_mutex_lock is getting  an invalid
argument error calling  a series of wrappers that basically all boil
down to pthread_mutex_lock.
So, basically somehow pthread_mutex_lock is getting passed a bad mutex.
This appears to be happening in the credentials cache code.

There are no thread support changes between 1.16.1 and 1.16.2.
There is one ccache related change which I'll include below related to
memory ccaches.
Do you know what type of credential cache  is being used here?

>From 6d784809fe07c2d5f60c1a692bcac08b0d40f0a7 Mon Sep 17 00:00:00 2001
From: Greg Hudson 
Date: Sun, 1 Jul 2018 00:12:25 -0400
Subject: [PATCH] Fix bugs with concurrent use of MEMORY ccaches

A memory ccache iterator stores an alias into the cache object's
linked list of credentials.  If the cache is reinitialized while the
iterator is active, the alias becomes invalid.  Also, multiple handles
referencing the same memory ccache all use aliases to the same data
object; if one of the handles is destroyed, the other contains a
dangling pointer.

Fix the first issue by adding a generation counter to the cache and to
cursors, incremented each time the cache is initialized or destroyed.
Check the generation on each cursor step and end the iteration if the
list was invalidated.  Fix the second issue by adding a reference
count to the cache object, counting one reference for the table slot
and one for each open handle.  Empty the cache object on each destroy
operation, but only release the object when the last handle to it is
destroyed or closed.

Add regression tests for the two issues to t_cc.c.

The first issue was reported by Sorin Manolache.

(cherry picked from commit 146dadec8fe7ccc4149eb2e3f577cc320aee6efb)

ticket: 8202
version_fixed: 1.16.2
---
 src/lib/krb5/ccache/cc_memory.c | 164 +---
 src/lib/krb5/ccache/t_cc.c  |  51 +
 2 files changed, 154 insertions(+), 61 deletions(-)

diff --git a/src/lib/krb5/ccache/cc_memory.c b/src/lib/krb5/ccache/cc_memory.c
index c5425eb3ae..8cdaff7fb3 100644
--- a/src/lib/krb5/ccache/cc_memory.c
+++ b/src/lib/krb5/ccache/cc_memory.c
@@ -102,18 +102,20 @@ extern krb5_error_code krb5_change_cache (void);
 typedef struct _krb5_mcc_link {
 struct _krb5_mcc_link *next;
 krb5_creds *creds;
-} krb5_mcc_link, *krb5_mcc_cursor;
+} krb5_mcc_link;
 
 /* Per-cache data header.  */
 typedef struct _krb5_mcc_data {
 char *name;
 k5_cc_mutex lock;
 krb5_principal prin;
-krb5_mcc_cursor link;
+krb5_mcc_link *link;
 krb5_timestamp changetime;
 /* Time offsets for clock-skewed clients.  */
 krb5_int32 time_offset;
 krb5_int32 usec_offset;
+int refcount;   /* One for the table slot, one per handle */
+int generation; /* Incremented at each initialize */
 } krb5_mcc_data;
 
 /* List of memory caches.  */
@@ -122,6 +124,12 @@ typedef struct krb5_mcc_list_node {
 krb5_mcc_data *cache;
 } krb5_mcc_list_node;
 
+/* Iterator over credentials in a memory cache. */
+struct mcc_cursor {
+int generation;
+krb5_mcc_link *next_link;
+};
+
 /* Iterator over memory caches.  */
 struct krb5_mcc_ptcursor_data {
 struct krb5_mcc_list_node *cur;
@@ -132,7 +140,23 @@ static krb5_mcc_list_node *mcc_head = 0;
 
 static void update_mcc_change_time(krb5_mcc_data *);
 
-static void krb5_mcc_free (krb5_context context, krb5_ccache id);
+/* Remove creds from d, invalidate any existing cursors, and unset the client
+ * principal.  The caller is responsible for locking. */
+static void
+empty_mcc_cache(krb5_context context, krb5_mcc_data *d)
+{
+krb5_mcc_link *curr, *next;
+
+for (curr = d->link; curr != NULL; curr = next) {
+next = curr->next;
+krb5_free_creds(context, curr->creds);
+free(curr);
+}
+d->link = NULL;
+d->generation++;
+krb5_free_principal(context, d->prin);
+d->prin = NULL;
+}
 
 /*
  * Modifies:
@@ -150,16 +174,12 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 {
 krb5_os_context os_ctx = >os_context;
 krb5_error_code ret;
-krb5_mcc_data *d;
+krb5_mcc_data *d = id->data;
 
-d = (krb5_mcc_data *)id->data;
 k5_cc_mutex_lock(context, >lock);
+empty_mcc_cache(context, d);
 
-krb5_mcc_free(context, id);
-
-d = (krb5_mcc_data *)id->data;
-ret = krb5_copy_principal(context, princ,
-  >prin);
+ret = krb5_copy_principal(context, princ, >prin);
 update_mcc_change_time(d);
 
 if (os_ctx->os_flags & KRB5_OS_TOFFSET_VALID) {
@@ -185,61 +205,59 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 krb5_error_code KRB5_CALLCONV
 krb5_mcc_close(krb5_context context, krb5_ccache id)
 {
-free(id);
-return KRB5_OK;
-}
-
-static void
-krb5_mcc_free(krb5_context context, krb5_ccache id)
-{
-krb5_mcc_cursor curr,next;
-krb5_mcc_data *d;
+krb5_mcc_data *d = 

Bug#919236: Inappropriately broad default CA for EAP configuration

[Sam Hartman]

package: freeradius
tags: security
version: 3.0.17+dfsg-1
severity: important
justification: Inappropriately broad default authorization

The debian freeradius package changes the default eap configuration to
use the default list of Debian certification authorities as the default
CAs for verifying client certificates for incoming EAP connections.

The package leaves the following notice in
/etc/freeradius/3.0/mods-available/eap:

#  See also:
#
#  http://www.dslreports.com/forum/remark,9286052~mode=flat
#
#  Note that you should NOT use a globally known CA here!
#  e.g. using a Verisign cert as a "known CA" means that
#  ANYONE who has a certificate signed by them can

And then proceeds to do something even worse: it sets the default CA to
the entire list of Debian trusted CAs.

As discussed by the freeradius docs, you want the default for EAP
certificates to be an organization-specific CA.

--Sam

Bug#919234: ttls fails with tls 1.3, enabled by default

[Sam Hartman]

package: freeradius
severity: important
version: 3.0.17+dfsg-1
justification: regression that totally breaks connectivity
tags: upstream


I've cc'd Kurt because he requested openssl 1.3 test results a while
back.

While writing automated tests for moonshot-gss-eap, I discovered that
by default freeradius will not constrain  the version of TLS in use
(probably good), but that its ttls implementation fails with TLS 1.3.
Things work fine if I explicitly set the max TLS version to 1.2.

Based on the errors I suspect that  the issue had to deal with the
handling of the ttls TLS session ticket used by TTLS for fast
reauthentication.
My suspicion (and recollection from the spec) is that ttls knows more
about session internals than it should.

As a quick fix, I think the ttls code should limit the maximum TLS
version to 1.2 until the code can be fixed to work with 1.3.


Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
really like to be able to use tls 1.3 with radsec.
Also, I strongly recommend making this change in code not in config
files.  People tend not to update their configs once they get one
working.

To reproduce, grab the moonshot-gss-eap sources.
Comment out the TLS_MAX_VERSION on line 366 of
debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
source package.

Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

[Sam Hartman]

control: forwarded -1
https://github.com/FreeRADIUS/freeradius-server/issues/2385

I'll try to get a patch for this if we don't hear something interesting
from upstream soon.
I think I'm in a better position than most in Debian to write such a
patch.
However I'm fairly busy.

Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration

[Sam Hartman]

control: tags -1 help

> "Michael" == Michael Stapelberg  writes:

Michael>Can you send a patch please? It€™s been like
Michael> that since before I touched the package.

My suspicion is that it's removing parts of a patch.  In fact, it looks
like most of what's needed is to remove snakeoil-certs.diff from the
patch series.
Yes, doing that requires the user run make in /tec/freeradius/3.0/certs,
but they really probably do want a different certificate hierarchy for
EAP.

I really don't think I'm going to be able to provide more on this prior
to the buster release.  I'm struggling trying to get through my own list
of things to fix in my packages.

Bug#924260: NMUDIFF for csound 1:6.12.2~dfsg-3.1

[Sam Hartman]

Dear maintainer, I've uploaded the following patch to csound to
delayed/2.  Rationale for the short delay: we've already discussed the
change and you've reviewed my merge request, and the release team
requested that I upload in a timely manner.

diff --git a/debian/changelog b/debian/changelog
index 84a4831..72a6859 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix diskgrain, syncgrain and syncloop when sample rate of sample
+differs from orchestra, Closes: #924260
+
+ -- Sam Hartman   Thu, 21 Mar 2019 10:31:29 -0400
+
 csound (1:6.12.2~dfsg-3) unstable; urgency=medium
 
   * Fix FTBFS on mips by avoiding a deadlock
diff --git 
a/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch 
b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
new file mode 100644
index 000..d5f3033
--- /dev/null
+++ b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
@@ -0,0 +1,58 @@
+From: veplaini 
+Date: Mon, 11 Mar 2019 09:11:40 +
+Subject: applied diskgrain fix to syncgrain andsyncloop
+
+---
+ Opcodes/syncgrain.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index cb0b2bd..1dc1973 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -96,15 +96,16 @@ static int32_t syncgrain_process(CSOUND *csound, syncgrain 
*p)
+ int32_t numstreams = p->numstreams, olaps = p->olaps;
+ int32_t count = p->count, j, newstream;
+ int32_t datasize = p->datasize, envtablesize = p->envtablesize;
++MYFLT  pscale =  p->sfunc->gen01args.sample_rate/CS_ESR;
+ 
+-pitch  = *p->pitch * p->sfunc->gen01args.sample_rate/CS_ESR;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(p->sfunc->gen01args.sample_rate/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+ grsize = p->sfunc->gen01args.sample_rate * *p->grsize;
+ if (UNLIKELY(grsize<1)) goto err1;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
+@@ -249,7 +250,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ int32_t loopsize;
+ int32_t firsttime = p->firsttime;
+ MYFLT   sr = p->sfunc->gen01args.sample_rate;
+-
++MYFLT pscale = sr/CS_ESR;
+ /* loop points & checks */
+ loop_start = (int32_t) (*p->loop_start*sr);
+ loop_end = (int32_t) (*p->loop_end*sr);
+@@ -260,7 +261,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ /*csound->Message(csound, "st:%d, end:%d, loopsize=%d\n",
+   loop_start, loop_end, loopsize); */
+ 
+-pitch  = *p->pitch * sr/CS_ESR;;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(sr/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+@@ -268,7 +269,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (loopsize <= 0) loopsize = grsize;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/diskgrain-prate-scaling.patch 
b/debian/patches/diskgrain-prate-scaling.patch
new file mode 100644
index 000..9f21a6e
--- /dev/null
+++ b/debian/patches/diskgrain-prate-scaling.patch
@@ -0,0 +1,30 @@
+From: veplaini 
+Date: Sat, 9 Mar 2019 14:03:22 +
+Subject: diskgrain prate scaling
+
+---
+ Opcodes/syncgrain.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index d7c461e..cb0b2bd 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -455,7 +455,7 @@ static int32_t filegrain_init(CSOUND *csound, filegrain *p)
+ p->pscale = p->sr/CS_ESR;
+ 
+ if (*p->ioff >= 0)
+-  sf_seek(p->sf,*p->ioff * CS_ESR, SEEK_SET);
++  sf_seek(p->sf,*p->ioff * p->sr, SEEK_SET);
+ 
+ if (LIKELY(sf_read_MYFLT(p->sf,buffer,p->dataframes*p->nChannels/2) != 
0)) {
+   p->read1 = 1;
+@@ -518,7 +518,7 @@ static int32_t filegrain_process(CSOUND *csound, filegrain 
*p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (grsize > hdataframes) grsize = hdataframes;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * p->pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/series b/debian/patches/series
index

Bug#926477: dgit accepts short keyid even though debsign does not

[Sam Hartman]

Package: dgit
Version: 8.3
Severity: important

Dear Maintainer,

Someone wrote in a forum that I can't quote here something along the
lines of it should be a bug for any Debian package to accept a
short-form GPG keyid.  I agree.


Dgit still accepts short-form keyids (and it doesn't look like this
has been fixed in the repo) even though tools it calls does not.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt 1.8.0~rc4
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.64.0-1
ii  devscripts  2.19.3
ii  dpkg-dev1.19.5
ii  dput1.0.3
ii  git [git-core]  1:2.20.1-1
ii  git-buildpackage0.9.13
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.5
ii  libjson-perl4.0-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-5+b7
ii  libwww-perl 6.36-1
ii  perl5.28.1-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.9p1-5

Versions of packages dgit suggests:
ii  sbuild  0.78.0-2

-- no debconf information

Bug#870428: libverto1: Upstream has moved

[Sam Hartman]

I apologize for dropping the ball on this so long.
It looks like there is a 0.3.0 release of verto, which was folded into
krb5.
However, It looks like there's not an upstream tarball on github for
anything past 0.2.6.

Because I dropped the ball so much I'm under tight time pressure to get
an update into Debian buster.  I'm going to package 0.2.6, but if you
either get me an official 0.3.0 tarball by Thursday or alternatively let
me know that the changes between 0.2.6 and 0.3.0 are so critical I
should go generate my own make dist even though I'm not upstream, I'll
try to get 0.3.0 in.

--Sam

Bug#870428: Info received (Bug#870428: libverto1: Upstream has moved)

[Sam Hartman]

Sigh.
I'm just confused.
Got the 0.3.0 tar ball fine.

Bug#870428: libverto1: Upstream has moved

[Sam Hartman]

>>>>> "Robbie" == Robbie Harwood  writes:

Robbie> Sam Hartman  writes:
>> I apologize for dropping the ball on this so long.  It looks like
>> there is a 0.3.0 release of verto, which was folded into krb5.
>> However, It looks like there's not an upstream tarball on github
>> for anything past 0.2.6.

Robbie> I'm confused by this comment.

I was totally confused myself and was just wrong.
I sent you a note to that effect, but I think it only went to your CMU
address.

Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second

[Sam Hartman]

I don't know about official policy, but I think you could make your bug
not RC by detecting whether the current system can support the package
in some reasonable wail and failing more gracefully than with SIGILL.

It's not a requirement that all packages work on all systems.
Open-vm-tools doesn't do squat if you aren't running on top of vmware;
pcscd is remarkably useless without a smartcard reader; etc.
I think it ought to be fine to have a package that is only useful with
some given hardware provided that  you're reasonable about detecting
requirements, and that  you don't place stronger requirements than are
actulaly needed by your package.

--Sam

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

[Sam Hartman]

Status is that I didn't find the time to get moonshot-trust-router dealt
with before buster and so I had deprioritized it.
There is in fact a new upstream, and it does fix the issue.
Blocking on moonshot-trust-router is silly: no one wants the version in
unstable anyway.
Is it possible to remove openssl and make moonshot-trust-router
uninstallable?
In my mind the only reason to keep moonshot-trust-router around now is
to avoid needing to take a trip through new again when I do fix it post
buster.

If you really need me to go deal with moonshot-trust-router now, I'll do
that, but my preference for my Debian time is to focus on buster
issues.  

Bug#924260: Csound: regression in diskgrain stretch->buster when file sr != orchestra sr

[Sam Hartman]

package: csound
severity: important
justification: Stretch regression with no work around without code
changes
version: 1:6.12.2~dfsg-3
tags: patch, fixed-upstream, upstream

Hi.  In https://github.com/csound/csound/issues/1119
I reported an issue.

In stretch, if you want to deal with a file that doesn't match the
orchestra sample rate in diskgrain, you have to do all the work in your
orchestra.
Between stretch and buster upstream tried to improve it but got a couple
of things wrong:

* Most seriously, they handle the initial file seek according to the
  orchestra sr not the file sr.  So there will be a jump of
  uncontrollable length when the first file buffer is exausted.

* They scale the pitch but not the pointer read rate, so the orchestra
  still has to know about the gap.

This is fixed in f23c45efcef upstream.
I confirmed that code change works against the upstream code base and
the Debian code base.

I'd like to try and get an unblock to get this into buster.  I want your
support obviously before trying to do that.  I'm happy to do everything
(prepare a package; upload; file an unblock), simply write the unblock
justification, sit back and let you deal, or accept that you don't think
this is worth trying to get an unblock for.
My justification for the unblock is that it's a well-constrained change,
something that is possible in stretch is entirely impossible in the
current buster code, and there is an easy fix.

--Sam


signature.asc
Description: PGP signature

Bug#925242: unblock: csound/1:6.12.2~dfsg-3.1

[Sam Hartman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package csound

Upstream csound introduces a regression over stretch.  If you're using
the synchronous granular synthesis opcodes and the sample rate of your
samples differs from the sample rate you're playing at, it is
impossible to make things sound right in buster.

So, for one synthesis technique that worked in stretch, you get into situations 
where it doesn't work in buster and there is no work around.

The upstream fix is simple: scale the pointer read rate along with
pitch scaling that upstream already introduced.  #924260 includes
details and a pointer to the upstream issue which includes even more
detailed analysis and upstream's fix.  This is just a backport of the
two upstream patches.  I've confirmed the fix with my DJ software.  I
have received permission to upload an NMU from the maintainer (again
see #924260 ) and will upload once I get a confirmation from the
release team that this looks good.
diff --git a/debian/changelog b/debian/changelog
index 84a4831..41d2499 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix diskgrain, syncgrain and syncloop when sample rate of sample
+differs from orchestra, Closes: 924260
+
+ -- Sam Hartman   Thu, 21 Mar 2019 10:31:29 -0400
+
 csound (1:6.12.2~dfsg-3) unstable; urgency=medium
 
   * Fix FTBFS on mips by avoiding a deadlock
diff --git 
a/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch 
b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
new file mode 100644
index 000..d5f3033
--- /dev/null
+++ b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
@@ -0,0 +1,58 @@
+From: veplaini 
+Date: Mon, 11 Mar 2019 09:11:40 +
+Subject: applied diskgrain fix to syncgrain andsyncloop
+
+---
+ Opcodes/syncgrain.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index cb0b2bd..1dc1973 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -96,15 +96,16 @@ static int32_t syncgrain_process(CSOUND *csound, syncgrain 
*p)
+ int32_t numstreams = p->numstreams, olaps = p->olaps;
+ int32_t count = p->count, j, newstream;
+ int32_t datasize = p->datasize, envtablesize = p->envtablesize;
++MYFLT  pscale =  p->sfunc->gen01args.sample_rate/CS_ESR;
+ 
+-pitch  = *p->pitch * p->sfunc->gen01args.sample_rate/CS_ESR;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(p->sfunc->gen01args.sample_rate/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+ grsize = p->sfunc->gen01args.sample_rate * *p->grsize;
+ if (UNLIKELY(grsize<1)) goto err1;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
+@@ -249,7 +250,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ int32_t loopsize;
+ int32_t firsttime = p->firsttime;
+ MYFLT   sr = p->sfunc->gen01args.sample_rate;
+-
++MYFLT pscale = sr/CS_ESR;
+ /* loop points & checks */
+ loop_start = (int32_t) (*p->loop_start*sr);
+ loop_end = (int32_t) (*p->loop_end*sr);
+@@ -260,7 +261,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ /*csound->Message(csound, "st:%d, end:%d, loopsize=%d\n",
+   loop_start, loop_end, loopsize); */
+ 
+-pitch  = *p->pitch * sr/CS_ESR;;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(sr/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+@@ -268,7 +269,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (loopsize <= 0) loopsize = grsize;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/diskgrain-prate-scaling.patch 
b/debian/patches/diskgrain-prate-scaling.patch
new file mode 100644
index 000..9f21a6e
--- /dev/null
+++ b/debian/patches/diskgrain-prate-scaling.patch
@@ -0,0 +1,30 @@
+From: veplaini 
+Date: Sat, 9 Mar 2019 14:03:22 +
+Subject: diskgrain prate scaling
+
+---
+ Opcodes/syncgrain.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index d7c461e..cb0b2bd 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -455,7 +455,7 @@ static int32_t filegrain_init(CSOU

Bug#921458: Handling build-depends-indep for non-x86 source packages

[Sam Hartman]

> "Alex" == Alex Bennée  writes:

Alex> Hi,

Alex> The following bug has come up and we would like some input
Alex> from the multiarch and cross developers on how best to handle
Alex> this case.

Alex> In an ideal world all cross compilers would be available on
Alex> all release architectures but I think it will be a while
Alex> before we get there. My own efforts to get just all the cross
Alex> binutils cleanly building on arm64 have stalled somewhat so in
Alex> the meantime is there anything we can do to keep
Alex> build-dependencies working on all arches?


Let me make sure I'm understanding the concern.

You want to build an arch: all firmware package so qemu can be used on
any host for a particular target.

In order to do that you need a compiler for the target, so you want that
target to be a  build-depends-indep for the package building the
firmware.

As a result that firmware package  will not be buildable on an arch that
is missing the cross compiler in question.
That seems inherent: if you need an arm compiler and m68k doesn't have
an arm compiler, you aren't going to be able to use m68k to build your
arm firmware.

Presumably since you're bringing up the issue something beyond that
breaks.  Do you run into testing migration or other issues if a
build-depends-indep package is not available on all arches?
What exactly is going wrong?

Bug#926656: git-debrebase docs are intimidating

[Sam Hartman]

I don't know.
As I said in my mail I'm not even sure there's a problem here.

Let me give a bit of background here.
Ian and I had what I thought was a really exciting call about git and
source packages and stuff.

It sounded like Ian hopes we'll some day get rid of patches-unapplied
data models from our processes.  To do that, there needs to be something
to replace gbp pq in terms of simplicity and something that the average
developer can understand.  I said that I really didn't think git-dpm
counted; I liked git-dpm but found gbp pq lots simpler.  Ian nominated
git-debrebase as a gbp pq replacement.

I said I'd look.
My conclusion is that it's certainly a git-dpm replacement, and I'll
look at whether it is as easy to use in practice as gbp pq, but then I
wrote that note saying that I think its docs are harder to approach.

I think the one explicit concrete suggestion I'd make is to make it so a
casual user can read git-debrebase (1) without git-debrebase(5)
Or something so there's one man page that a user can start with that
tells them enough to get going, and that they can approach git-debrebase
without dgit.

Rationale:

1) dgit is more complex and has more failure modes because as we all
know, turning a git tree into a quilt dsc is really hard.

2) I think we're hoping eventually that pushing to salsa does the
dgit-like-thing (possibly by calling dgit) and users don't need to do
that themselves.

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

control: severity -1 serious

justification: libvirtd upgrades from stretch to buster break causing
apt to fail and requiring the admin to get the systemd units into a
consistent state before things can continue


Unfortunately based on discussion so far this is a complex bug to fix.
Ubuntu's solution is to drop the sysv scripts and to drop  Also= lines
in some of the units.

The systemd maintainers proposed that dropping Also as well as some
changes to move toward dh_systemd_start being used even when sysvinit
scripts are present would help this situation.  Unfortunately it at
least doesn't look like those changes are in debhelper for buster.
Systemd folks, do you have any suggestions  on how to approach this for
buster?



signature.asc
Description: PGP signature

Bug#905772: [Pkg-libvirt-maintainers] Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

Guido let me know if  you need any help or prod me on IRC if I'm needed.
Will certainly test the result, but if you get stuck would be happy to
spend time on this.

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

>>>>> "Guido" == Guido Günther  writes:

Guido> Hi,
Guido> On Mon, Apr 15, 2019 at 02:38:27PM -0400, Sam Hartman wrote:
>> control: severity -1 serious
>> 
>> justification: libvirtd upgrades from stretch to buster break
>> causing apt to fail and requiring the admin to get the systemd
>> units into a consistent state before things can continue
>> 
>> 
>> Unfortunately based on discussion so far this is a complex bug to
>> fix.  Ubuntu's solution is to drop the sysv scripts and to drop
>> Also= lines in some of the units.

Guido> Did you reproduce this bug on a stretch->buster upgrade?
Guido> Cause I just did that and didn't encounter any errors.

I've run into this on two active server upgrades--servers that were
running VMs,
but I haven't been able to reproduce on a clean install.
It's frustrating: on my machines where I really want the upgrade to be
smoothe this bit me, but on all my toy tests, it didn't happen.
What I think may be necessary is for virtlogd to be active.
So it may be necessary to actually get libvirtd running and actually
running a VM to use the socket before the issue comes up.
Alternatively, it's possible some other change has fixed this in the
last month.
I'll certainly say that a month ago ran into this on two different VM
servers.