Bug#825951: nmu: pam-krb5-migrate_0.0.11-3

[Sam Hartman]

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

nmu pam-krb5-migrate_0.0.11-3 . ALL . -m "Rebuild for new krb5 admin libraries"

As part of the krb5 transition.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#825952: nmu: libauthen-krb5-admin-perl_0.17-1

[Sam Hartman]

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

nmu libauthen-krb5-admin-perl_0.17-1 . ALL . -m "rebuild for new krb5 admin 
libs"

as part of krb5 transition.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#827208: libgssapi-krb5 changes versions for some functions in .symbols

[Sam Hartman]

source: krb5
source-version: 1.14.2+dfsg-1

> "Lars" == Lars Uebernickel  writes:

Lars> Package: libgssapi-krb5-2 Version: 1.14.2

Lars> Dear maintainers,

Lars> Some functions in libgssapi-krb5-2.symbols have different
Lars> versions than they did in 1.10. For example,
Lars> gss_init_sec_context().

This isn't a bug.
Some functions gained new, backward-compatible behavior changes.  The
symbols file is updated so that if you build against this version of
krb5,o you require the new version of libgssapi-krb5-2 so you can be
guaranteed the new functionality is available.
Since the functions are still  are backward-compatible,old applications
will continue to work.

Bug#828946: krb5: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Sam Hartman]

For my notes, iftex.sty is in texlive-generic-extra on my system.
I did the most recent build for sid in a chroot including the arch all
packages, so it's more likely to be something changing than a
then-missing-build-dep-indep, but I'll take a look while at Debconf.

Bug#829044: krb5-admin-server failed to start because of read-only filesystem

[Sam Hartman]

This doesn't sound like a bug to me.
You modified the krb5 configuration to log to /var/log/kadmind.log, but
didn't make the corresponding change to the systemd unit.
krb5 by default logs to syslog; if you chose to configure your system
that way it would work as shipped.
Am I missing something?

--Sam

Bug#769710: krb5-admin-server: kadmind tries to start before LDAP is available (combined with krb5-kdc-ldap)

[Sam Hartman]

It belongs in krb5-kdc-ldap as with the krb5-kdc overried.
Really same structure.
I just missed the need when making that change.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769907: general: non-sysvinit init systems are made of fail

[Sam Hartman]

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

Didier> Systems cross-craded from Ubuntu to Debian are absolutely
Didier> not supported, and I wouldn't be surprised if some of the
Didier> issues you're seeing are in some way related to this.

I've seen both these issues on pure Debian systems.

And I do consider both of them likely to be significant problems on
upgrades from wheezy.
I've been burned by both of the identified issues on multiple systems.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769907: general: non-sysvinit init systems are made of fail

[Sam Hartman]

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

Didier> Steve's suggestions stands though: separated and actionable
Didier> bugs for these two issues filed on the corresponding
Didier> packages are way more helpful than a general "non-sysvinit
Didier> init systems are made of fail".

sure.
My assumption of what it means when someone files a general bug is that
they're hoping for help from all of us figuring out where the bug
belongs.

In that spirit.
The first issue (fstab now fatally blocks boot) is something the systemd
maintainers have considered (as I understand it) and rejected.
I don't know that filing a bug that will be immediately wontfixed will
be helpful.
I don't think sending that issue to the TC is advised.

The second issue seems more actionable.
I wonder if we can get a bit more detail so we can retitle and reassign.

In my case, I've found that with systemd I tend to get a lot less output
in some cases than I do with sysvinit, but I haven't figured out what is
going on well enough to produce something actionable so I didn't bother
trying.
If others are seeing that it's perhaps worth exploring.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

[Sam Hartman]

> "Ron" == Ron   writes:


Ron> I'd be kind of sad if that stopped being possible again for the
Ron> final released version of Jessie, and we had to skip yet
Ron> another release before being able to do this on Debian again.
Ron> It may not be the best and final answer, but it has some
Ron> advantages over the proposed alternative, like being able to
Ron> work with existing m-a packages without needing to rebuild
Ron> custom versions of everything, and actually working on Debian
Ron> today.

I personally think that this use case--building on non-native hardware
not for bootstrap but for things where that really just is the wrong
answer is an important use case for our toolchains.
I'm not saying it is an important use case for the debian archive.
However for debian developers using debian and for our downstreams, this
seems like it can be very valuable.

In particular, I want to take the Debian archive or one of our
downstreams, build a cross tool chain, and build additional packages
against that archive that would work with the packages in that archive.
As an example, I'd like to build some of the prerelease moonshot
packages (http://www.project-moonshot.org/) for some arm boards and I
don't want to build on those boards.
I want the resulting packages to be usable by anyone without needing to
install some magic cross toolchain libraries.

I don't care which mechanism ]is used to produce this.
I understand how to doo this with the method being removed in Jessie.
I can't even understand if this is possible with the default method.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

[Sam Hartman]

> "Dimitri" == Dimitri John Ledkov  writes:

Dimitri> Comparing squeeze and jessies - have things regressed? if
Dimitri> yes, how?  As far as I expect, the way one uses debian
Dimitri> source packaging to produce cross toolchains has not
Dimitri> changed, nor has been affected by changes in jessie, in
Dimitri> comparison to squeeze.

Can you give a pointer to documentation of this--the mechanism that
works in squeeze and jessie?
>From the IRC conversation today I think the answer *may* be no that's
not written up anywhere, but I'm
not sure.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Josselin" == Josselin Mouette  writes:

Josselin> Sam Hartman  wrote: Bill, in his role
Josselin> of policy editor said that he believed there was not a
Josselin> consensus.  He cited a specific set of messages that he
Josselin> believes were not properly addressed.

>> From the beginning, I have been puzzled by your approach to this
>> issue.
Josselin> With this paragraph, I think I’m beginning to understand
Josselin> how you want to treat the issue. And I can’t say I think
Josselin> it is constructive.

Josselin> Bill used his position as a policy editor to reject a
Josselin> change, not because it was against consensus or against
Josselin> the policy process, but because it was against his own
Josselin> opinion. Not as policy editor, but as menu maintainer.

First, I definitely understand your frustration with the process.  It
 sounds like you expect to have confidence that policy
 editors  follow the community's needs and do not allow their personal
 biases to influence their decisions.  It sounds like you're frustrated
 because you don't see that happening here.

I strongly value building robust processes.  When we treat matters as
confrontations between people, we build frustration, we drive people
away, and we poison the atmosphere of the community.  However, it's also
important that we  address peoples frustrations.  I hope we can get to a
point where we all believe that if there were a similar issue in the
future, it would be resolved much more quickly.

We all have biases.  So, before focusing on blaming people or deciding
they are not acting in good faith, I'd like to focus on looking at what
we can do to have reasonable results even in the case of biases and bad
decisions from time to time.  I think we would all be less frustrated if this
issue had been quickly resolved in a couple of weeks even if Bill had
displayed some bias in his initial call.

When I read Bill's message, he was claiming to act as a policy editor
*not* as a menu maintainer.  So, yes I'll start by assuming that he is
doing what he said he's doing and discard that assumption very
reluctantly.

Now, does Bill have biases?
Almost certainly.
Bill did state his own objections early in the discussion; one of the
messages he pointed to that he claims was not addressed was his own
message.
Would bill have  focused so much on finding objections if he  didn't
dislike the proposal so much?  Probably not.  Would Bill have been more
willing to decide that objections were handled if he liked the proposal
better?  Many people would be more sympathetic to proposals they liked.

Should Bill have recused?
Your current process does not describe when policy editors should
recuse.
One thing we may learn here is that we need to be more clear about how
we handle recusals.

Again, my hope is that we can work on our processes and our
understanding of how we address issues like this.  I think that we could
get to a place where it takes a couple of weeks to resolve these sorts
of disagreements in most cases.
I think we can also do a better job of understanding what we expect.

However, I also recognize that it's possible we'll find ourselves in a
situation where a member of the community is not meeting the
expectations we've jointly agreed.  I think in such cases that the
discussion about that member should be with the DPL.
I also think separating the discussion of how to handle the issue from
discussions of specific members of the community is valuable.  As a TC
member I'm going to focus on the process and the specific technical
proposal, *not* on the personalities.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Russ's role

[Sam Hartman]

>>>>> "Bill" == Bill Allombert  writes:

Bill> On Mon, Jul 20, 2015 at 10:34:47AM -0400, Sam Hartman wrote:
>> You said:
>> Hi.  As a matter of fact finding.  Russ's message, which Charles
>> sites implies to me that Russ was swamped and didn't have time to
>> do the commit.  By seconding, he had already done the review.

Bill> Seconding a bug does not imply doing a consensus search, even
Bill> for a policy editor.

We are not in agreement on this issue.
I've quoted the text from your process document that explains people
seconding a proposal are expected to evaluate consensus as well as
evaluate the technical quality of the proposal.
I've also explained my review of whether that happened in this instance.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

Just as an FYI, I'm in Prague at an IETF meeting and that's taking up
most of my time, so it may be this weekend before I get a chance to try
your patch.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> 1. The TC - not the policy process, not the policy editors, and
Ian> not the consensus on debian-policy - has the ultimate
Ian> responsibility to set technical policy.  (Constitution 6.1(1))

Ian> So in the TC the question of whether the policy process was or
Ian> was not followed does not dispose of the question of what the
Ian> policy text should actually be.

We are in strong agreement on this point.

Ian> It would therefore be quite wrong for the TC to confine itself
Ian> to discussions of whether the policy process was followed.

Also agreed.

Ian> 
Ian> More so, whether the policy process was followed is of no
Ian> bearing when we afre considering the technical and social
Ian> merits of the competing options.

Ian> The TC should be looking at the merits of the competing
Ian> options.


I actually think that whether the process is followed has very strong
bearing when considering the social merits of the competing options.
We are a volunteer project.
We thrive when people feel their contributions are valued, when they
feel they can make a difference.
There is a significant cost to the project when we reject contributions
that people have spent a lot of time working on.  People tend to
question whether allocating their time on these activities is valuable,
tend to question whether the project's values are aligned with their
values.

So, between two reasonable technical options, choosing the one that
values the time and work people have put in serves a significant social
good that helps build and strengthen our community.

I  think that there is a huge social benefit to fairness.  I find that I
am more willing to spend energy on organizations where I have rescourse
if I believe that fairness of process has not been met.
So I think it's absolutely critical that there be a way you can get a
process decision reviewed.
We can debate whether the TC is the right place for that.  I'll note
that reviewing a consensus call/a consensus process requires deep
knowledge of the technical issues involved.  If you take a look at
documents like RFC 7282 that discuss what it means to have rough
consensus, you'll find they are filled with judgment calls about the
technical issues.  So whoever does review this sort of call needs to
have significant technical skill.


I also think process has technical bearing.  I value consensus-based
processes because I believe they tend to produce superior technical
results.  I think that debian-policy has a wider set of skills than the
TC, and the members contributing to the discussion on debian-policy have
spent more time understanding the issue than the current TC members
involved in this discussion.
If the TC found itself coming to a different conclusion than an informed
rough consensus of debian-policy, it should carefully consider whether
that is the right course.

However, I absol/absolutely agree that the TC is responsible for the
content of policy and we cannot (or at least should not) delegate that
responsibility.
Even if the TC finds that the process is followed, the TC must evaluate
whether it has any objections to the resulting policy.

I think the key area where we differ is that I would give preference
other things being mostly equal to  upholding the work done in
debian-policy.  As I understand it, you would vote for the option you
thought technically best.  I wouldn't do that because I think the social
costs are important and because I recognize a real chance I might be
technically wrong.

I do think the form of the question posed to the TC has some importance.
I would be thinking about this somewhat differently if someone had asked us to
review menu policy because they had specific technical concerns with the
policy that was adopted.

You note that discussions of whether someone followed a process tend to
be acromonious.  We're in agreement there.  I've been frustrated when
I've seen people making this about Bill or about Charles and whether
they abused rights/responsibility.

I've tried to be careful to make this be about the process and not to
judge specific members of the community.  I'd be really happy if others
would join me in that.

My experience is that having discussions about process tends and whether
it is followed in specific cases tends to allow you to better understand
your requirements and understand gaps in shared expectations.
I find that  tends over time to significantly remove acromony.  As an
exampleI tend to feel a sense of relief that replaces frustration when I
understand that the reason someone isn't doing what I want is that they
have different expectations.  We can get down to the business of seeing
if there are mutually compatible expectations to be had.
It's quite obvious to me that Bill and Charles have different
expectations here, and I think there's significant acromony that can be
avoided if the community is able to clarify which expectations

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
>> I think the key area where we differ is that I would give
>> preference other things being mostly equal to upholding the work
>> done in debian-policy.  As I understand it, you would vote for
>> the option you thought technically best.  I wouldn't do that
>> because I think the social costs are important and because I
>> recognize a real chance I might be technically wrong.

Ian> I'm not sure precisely what social costs you are referring to.

Ian> Perhaps you mean disappointment on the part of people who have
Ian> spent effort to build consensus in debian-policy in order to
Ian> make progress in a controversial area.  But if there are
Ian> serious objections, which a participant wishes to take to the
Ian> TC, it seems to me that such a consensus (if it exists) has
Ian> probably been achieved by wearing down the sceptics rather than
Ian> by convincing them (or perhaps by the absence of the opponents
Ian> to begin with).

Having such serious objections that have not been adequately considered
means you don't have rough consensus at least in the ways I judge rough
consensus.
It was perhaps not obvious in some of my mail, but  I did:

* evaluate each objection Bill raised in his mail where he reverted the
  change to see if I thought it was addressed at a process level.

* Evaluate each of those objections as a TC member to see if I thought
  it was in my technical judgment a problem with the proposal.

* Try to explain the objections to the rest of the TC so they could make
  their evaluation using their technical judgment (including pointers if
  they want to  dig more deeply)

Doing all of those are important to me.

With regard to the current issue it's my opinion that we have no serious
issues that have not been considered.  It's my opinion that in my
technical judgment I'm comfortable with the resolution to the issues
that were considered.
If you or anyone else wants me to look at some specific issue either
from a process standpoint or to make a judgment about whether I think
the resolution is reasonable, please start another thread on the bug.
If I have not already voted I'll do so.

I'm still in the process of doing my own technical evaluation of the
proposal to see if I come up with any technical objections I consider
serious enough to raise.  It'll be awkward from a TC internal process
standpoint if I do because the ballot is frozen at this point, but I've
completed enough of my evaluation that I don't anticipate any such
objections.  I'll be done before I vote and will definitely be able to
complete within the voting period even if Don calls for a vote now.


Ian> Or perhaps you mean disappointment on the part of the policy
Ian> editors.  

I do not.  Your reasons are somewhat similar to mine.



Ian> To put it another way: the policy editors have cast themselves
Ian> as referees, not judges or designers.  

Agreed to some extent.  The policy editors do have some role as
consensus judges, but to a large extent they have delegated that to
those seconding proposals according to their process document.  In
practice, I suspect they do a fair bit of consensus judging themselves.


Ian> For the TC to do the
Ian> same would mean that - when the question is controversial and
Ian> has a strong political element - the actual decision would be
Ian> simply be based on which side has the most effort and best
Ian> tactics in a mailing list flamewar.

I would urge you to read RFC 7282.  I understand this is not the IETF
and even the IETF has not chosen to bind itself to that document.
However it displays some of the level of thought required in judging
rough consensus.
A judge of consensus is very much responsible for thinking about the
technical issues and making sure they have adequately been considered.
A judge of consensus is very much responsible for making sure the
process does not turn into who-shouts-loudest.

Someone reviewing a consensus process probably isn't in a position to
fix a process where participants were driven away in frustration
(silencing their objections) but should detect this sort of thing and
claim the process failed to reach consensus when significant viewpoints
were excluded.

However, I think the TC has very important roles beyond just judging
consensus.
We need to decide what the policy is.  We can and in my opinion should
factor in the opinions of others in doing that.

As a practical matter the debian-policy list does a lot of that.
When debian-policy properly takes up an issueit's important to me that
the TC value the work they have done.  Part of that to me is that we
should have a re

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> I made efforts to keep the wording mild, but I think that
Charles> it was an error.
>> From your attiude as the lead person behind the Debian Menu, it
>> is clear that
Charles> it has no future.  For one decade, you have taken no
Charles> leadership to build this future.  As a consequence, I think
Charles> that the next step is to plan its replacement and
Charles> deprecation.  Maybe the TC will come to this conclusion.

That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

Unless someone objects
I propose that the following text also be included in option b:

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


I'd like to be able to vote on that option, but I suspect there's no one
who favors B who doesn't favor that text.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

Hi.
I attempted the following:

* Built with the patch applied on a jessie chroot
* installed s3ql

* On a wheezy system mkfs.s3ql, mount and  add some data.  unmount.

* On my patched jessie system run s3qladm upgrade

So far so good.

Then run fsck.s3ql.
It looks like it has trouble with the old metadata:
Backing up old metadata...
Uncaught top-level exception:
Traceback (most recent call last):
  File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 710, in _extractmeta
  return safe_unpickle(b64decode(buf), encoding='latin1')
File "/usr/lib/s3ql/s3ql/backends/common.py", line 629, in
safe_unpickle
encoding=encoding, errors=errors)
  File "/usr/lib/s3ql/s3ql/backends/common.py", line 613, in
  safe_unpickle_fh
  raise pickle.UnpicklingError('opcode %s is unsafe' %
  opcode.name)
  _pickle.UnpicklingError: opcode NEWOBJ is unsafe

  During handling of the above exception, another
  exception occurred:

  Traceback (most recent call last):
File "/usr/bin/fsck.s3ql", line 9, in 
load_entry_point('s3ql==2.11.1',
'console_scripts', 'fsck.s3ql')()
  File "/usr/lib/s3ql/s3ql/fsck.py", line 1224, in
main
cycle_metadata(backend)
  File "/usr/lib/s3ql/s3ql/metadata.py", line
121, in cycle_metadata
cycle_fn("s3ql_metadata_bak_%d" % i,
"s3ql_metadata_bak_%d" % (i + 1))
  File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
line 290, in copy
self._copy_or_rename(src, dest, rename=False,
metadata=metadata)
  File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
line 299, in _copy_or_rename
meta_raw = self.backend.lookup(src)
  File "/usr/lib/s3ql/s3ql/backends/common.py",
line 46, in wrapped


It may be as simple as ignoring unsafe pickles in old metadata.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Yeah, just looks like metadata backup issue

[Sam Hartman]

I deleted the backup metadata by hand from s3 and fsck and mount work
fine.
I realize that's not exactly a supported operation, but it seemed likely
to work and I think gives confidence that the only problem with the
patch seems to be with regard to old metadata carried forward.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#755520: CVE-2014-4343 in krb5: double-free in SPNEGO initiators

[Sam Hartman]

I'm not at ietf this week.
If you corner me on Jabber I'm happy to coordinate on an unstable
upload.

If you get a go ahead from security for any of this I'm happy to help
with a stable upload


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681419: Alternative dependencies on non-free packages in main: counterargument

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> And from a practical point of view, I would prefer to make a
Ian> choice that significantly eases collaboration with the GNU
Ian> Project to one that slightly eases collaboration with
Ian> proprietary software vendors.

The more interesting question to me is what makes things easier for our
users.

I think that one of the key differences we've hadwith  the GNU project
actually is very close to this point.
Last time I looked at why the GNU project didn't recommend Debian, a lot
of it came down to things like our  installer offers to turn on the
non-free section and that our documentation talks about using debian
with proprietary software.

Traditionally, we've enabled  our users when they choose to use
proprietary software.  We've taken the position that Debian will remain
free, but if we can do so while writing free software, we will enable
our users to do whatever they want even if their principles and goals
are different than ours.

So, when evaluating something like this, I agree with Ian that making
things easier for proprietary software vendors is not a concern.
However, making things easier for our users, even when they choose to
use proprietary software is a significant concern.
Advertizing proprietary software seems bad.  Accurately documenting what
proprietary software can satisfy the needs of some program in metadata
seems like it helps our users.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Initial draft of resolution

[Sam Hartman]

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


>> Background/Rationale (Constitution 6.1.5):
>> 
>> 1. In #750135, the Technical Committee was asked by Manuel
>> Fernandez Montecelo who should be the maintainer of the Aptitude
>> project. He had been actively committing until his commit access
>> was removed by Daniel Hartwig. Manuel and Daniel took over
>> development of Aptitude in 2011 with the support of Christian
>> Perrier, an admin for the Aptitude alioth project. There was
>> friction between Manuel and Daniel, which eventually resulted in
>> Manuel's commit access being revoked by Daniel. Since then,
>> Daniel has become inactive, and did not comment on the issue when
>> requested by the Technical Committee.

Didier> That reads like a correct description of events as they have
Didier> been presented to us.

>> 2. During the discussion of this issue, Christian Perrier
>> proposed that he and Axel Beckert could watch the social aspects
>> of Aptitude development and restore Manuel's commit
>> access. Christian still has administrative rights and believes he
>> has the technical power to implement his proposal. However he
>> wants review from a broader audience before implementing that
>> proposal.

Didier> Ditto.

Didier> Did you intend to have these two paragraphs part of the
Didier> actual decision, or not?

Note that nothing in this resolution is formal at all.
We provide background and some advice to the aptitude process.
Only things that are part of the decision are things that are agreed by
the technical committee.
Yes, I believe it's important that we get a summary of our rationale and
background as something that  the TC agrees to, so yes, I believe that
should be part of the decision.

If we had a part of this resolution that had any force--that was a
statement of policy, a resolution of conflicting juristictions,
overiding a maintainer, deciding a matter delegated to us, I'd prefer to
keep the part of the text with actual force short.

>> Advice (Constitution 6.1.5):
>> 
>> 1. The Technical Committee agrees that Christian has the power to
>> implement his proposal and encourages him to do so.

Didier> I'd replace "agrees" with "acknowledges", but beware of my
Didier> en_CH !

To me agrees is more active, more supportive.
However I don't care at all about this.

>> 2. The committee agrees that restoring Manuel's commit access is
>> a good step to move Aptitude development forward. Since there is
>> a clear way to accomplish this goal within the existing Aptitude
>> project support that approach.
s:support:we support:
I'll go make that change.

Didier> I don't understand this second sentence. Is there some
Didier> punctuation hiccup?

>> 3. We hope that Christian and Axel will work to managed the
>> social aspects of the Aptitude project, working to recruit new
>> developers, building a stronger Aptitude development community,
>> and establishing policies and procedures that promote a
>> collaborative team. Sometimes the skills necessary to grow a
>> community ar different than the skills to develop a
>> project. Through this approach we hope the Aptitude community
>> will gain both sets of skills.

Didier> Although I don't disagree with the paragraph, I'm not overly
Didier> comfortable with formalizing our hopes in a resolution. I'd
Didier> rather drop the complete paragraph from the actual decision,
Didier> eventually moving it to a non-formal part (either pre- or
Didier> post- decision).

Again, I'm hoping that the TC as a whole will support this so I want it
 to be part of the resolution.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784651: moonshot-ui: depends on libgee-dev which is deprecated

[Sam Hartman]

Ah, and I see you did actually file the removal request, so yeah this is
RC under any evaluation.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784651: moonshot-ui: depends on libgee-dev which is deprecated

[Sam Hartman]

> "Emilio" == Emilio Pozuelo Monfort  writes:

Emilio> Control: severity -1 serious We want to remove libgee2 from
Emilio> unstable RSN, and there are only a few rdeps now, so I'm
Emilio> bumping the severity of the bugs.

For future reference, I don't think it's actually legitimate to bump the
severity of an rdep removal to RC until *after* you remove the rdep.
However, as maintainer, I'll say this is fine as serious by request of
maintainer.

I don't think this is a problem, I just need to rebuild and upload.
I'll try to get to that in a day or two.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Bug #741573:Process Approach vs Others

[Sam Hartman]

[moving back to the bug, because we're starting to discuss the issue
rather than a TC communications matter.]


>>>>> "Bdale" == Bdale Garbee  writes:
Bdale> I hear you, I just don't have any idea what to do differently
Bdale> on this specific issue in response to knowing how you feel
Bdale> about it.

I made a specific proposal in #741573.  
I'd be a lot happier if you'd say "No, I think we've already reached
agreement that the policy team didn't have consensus., so we don't need to
evaluate whether the process was followed."
I wouldn't agree with that, but sometimes people disagree with you.  I'm
OK with that outcome.

If we've already agreed that the policy team didn't have consensus,  my
preference would be to ask the policy community whether they want us to
take up the issue, rather than just asserting a decision from on high.
That is, we communicate to them that we believe that they didn't have
consensus rather than just jumping to a conclusion.
I don't think we need to vote for that if we have internal rough
consensus, although I'd be fine voting on that if we wish to do so.

However:

Bdale> Sam Hartman  writes:
Bdale> I really think the only difference here might be in how much
Bdale> of the process to date we've each been involved with.  When
Bdale> this first hit the TC, I recall discussion about whether
Bdale> policy process had run its course or not and my belief was
Bdale> that we had consensus after input from Russ that in fact
Bdale> policy process had failed here and it was appropriate for the
Bdale> TC to intervene.  I would have to go do more digging and
Bdale> reading to substantiate that assertion than I have time for
Bdale> this afternoon, but that's the position I *thought* we agreed
Bdale> we were in.

I've been reading this bug since the beginning even though I was not on
the TC.
I recall things differently.
Charles referred his question.
Ian jumped immediately to the technical discussion.
I wrote to Ian and the bug noting that he was jumping to the technical
discussion without considering the question Charles brought to the TC.
Ian wrote back  saying that it was inappropriate for the TC to consider
the question of whether the policy team had a consensus.
My perception is that everyone else ignored Charles and I and continued
on with the technical discussion.

Somewhere along that discussion a couple of TC members (I think you may
have been one) pointed out that going through the bug and determining
whether the policy team had consensus would be huge work.

So, if anything  the consensus of the TC prior to the resignations was
that it was not important to consider the question of whether the policy
team followed their process.

However a few things have happened since then:

* There has been a membership change in the TC.

* There's been a bunch of discussion within the TC and broader in the
  project that we might want to do a better job of working with folks.

* The policy team updated its process.  I don't know how extensive the
  update is, but it's my opinion that under the current process it's
  fairly easy to determine whether the policy team has consensus.
I proposed how to do so on this bug.
It may have been easy to do under the old process; I haven't researched
  that.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Bug #741573:Process Approach vs Others

[Sam Hartman]

>>>>> "Kurt" == Kurt Roeckx  writes:

Kurt> On Wed, May 27, 2015 at 09:19:07PM -0400, Sam Hartman wrote:
>> [moving back to the bug, because we're starting to discuss the
>> issue rather than a TC communications matter.]
>> 
>> 
>> >>>>> "Bdale" == Bdale Garbee  writes:
Bdale> I hear you, I just don't have any idea what to do differently
Bdale> on this specific issue in response to knowing how you feel
Bdale> about it.
>> 
>> I made a specific proposal in #741573.  I'd be a lot happier if
>> you'd say "No, I think we've already reached agreement that the
>> policy team didn't have consensus., so we don't need to evaluate
>> whether the process was followed."  I wouldn't agree with that,
>> but sometimes people disagree with you.  I'm OK with that
>> outcome.
>> 
>> If we've already agreed that the policy team didn't have
>> consensus, my preference would be to ask the policy community
>> whether they want us to take up the issue, rather than just
>> asserting a decision from on high.  That is, we communicate to
>> them that we believe that they didn't have consensus rather than
>> just jumping to a conclusion.  I don't think we need to vote for
>> that if we have internal rough consensus, although I'd be fine
>> voting on that if we wish to do so.

Kurt> I also feel that we should check that the policy change
Kurt> process has been followed as documented or not.  So from
Kurt> reading the policy bug, it seems some of the Policy Editors
Kurt> think that there is a consensus but that Bill Allombert
Kurt> doesn't agree that there is one.

Kurt> The Policy Change Process does not document on how to handle
Kurt> conflicts between the Policy Editors.

That's true, but  I proposed a way for the TC to resolve conflicts based
on our internal discussions of consensus and based on  my reading of the
policy process at
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=497;bug=741573

Yes, there's some interpretation on the part of the TC in doing that.
However, 1) I think that's always part of our job and 2) we have a lot
of constitutional room in how we approach policy it being one of our
primary mandates.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#787880: moonshot-ui: FTBFS with valac 0.28

[Sam Hartman]

committed upstream, there will be a new upstream version 0.7.2 for this
within a day.
Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

package: s3ql
severity: grave
version: 2.11.1+dfsg-1
Justification: Renders filesystem unusable and data accessible

Hi.
I'm upgrading a system from wheezy to jessie.
Wheezy ships s3ql 1.11, jessie ships version 2.11.

I have a filesystem that I can easily mount and fsck in wheezy, but when
I try to run the jessie s3qladm upgrade command I get:
Getting file system parameters..

File system revision too old to upgrade!

You need to use an older S3QL version to upgrade to a more recent
revision before you can use this version to upgrade to the newest
revision.

Uncaught top-level exception:
Traceback (most recent call last):
  File "/usr/bin/s3qladm", line 9, in 
  load_entry_point('s3ql==2.11.1', 'console_scripts', 's3qladm')()
File "/usr/lib/s3ql/s3ql/adm.py", line 96, in main
options.cachedir))
  File "/usr/lib/s3ql/s3ql/adm.py", line 316, in upgrade
  print(get_old_rev_msg(param['revision'] + 1, 's3qladm'))
File "/usr/lib/s3ql/s3ql/adm.py", line 224, in 
get_old_rev_msg
''' % { 'version': REV_VER_MAP[rev],
KeyError: 17


It's critical that there be a documented procedure that works for
upgrading from the version in wheezy to the version in jessie using
tools in jessie.


There was another upgrade at version 2.5, which is not in either wheezy
or jessie.  However, it needs to be possible to upgrade from one Debian
release to the next using the software in Debian.


I believe this problem is important enough to fix in a Jessie point
release and would be happy to help with any process issues that come up
in making that happen.


pgpzqVzXEaqi0.pgp
Description: PGP signature

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:


Nikolaus> I agree that this is unfortunate, but preserving backwards
Nikolaus> compatibility over so many upstream versions just for
Nikolaus> Debian wheezy users did not seem worth the time.

I totally understand that it's a lot of work and totally get that you
might not want to do that work.
However, Debian as a project balances  stability and upgrade tradeoffs
across the project, and this is one of those areas where a project goal
may require more work to be put into a package for that package to be
suitable for inclusion in a Debian release.

No one is obligated to do that work, but Debian's philosophy is
generally that if the work to make upgrades work well can't be done,
then a package should not be included in releases.


If a package is not going to provide an upgrade from one debian release
to the next, it should not generally be in the Debian release.
It would be fine for it to continue to be in unstable.

We need to figure out if someone is willing to commit to doing the
necessary work for stretch   and if not probably leave s3ql in unstable
but pull from stretch and investigate whether it should be pulled from
Jessie in a point release.

s3ql tends to get used for backups and other things where availability
is quite important and saying "oops, you don't get your data when you
upgraded," is kind of a big deal.
If Debian users can't count on maintaining access to their data after
the upgrades, then we probably want to warn them about that up front,
and  the experience may not be good enough to actually recommend that
people store data in s3ql.

I understand that as an upstream author you might well want a more rapid
deployment cycle than Debian's release process.
That's fine.  I'm not judging anything here.
I'm just saying that if software's going to be in a Debian release it
needs to live up to what that means.


Nikolaus> Theoretically, it is possible to do all the upgrades in
Nikolaus> one step and integrate that into Jessie's s3ql package,
Nikolaus> but that would be a major coding effort.


Nikolaus> I guess it would have been better to package S3QL 2.x as a
Nikolaus> new s3ql2 package instead of it replacing the s3ql
Nikolaus> package. But I don't think there is a way to recticify
Nikolaus> that now - or is there?

But then people still lose their data from wheezy->jessie.

So, you talked about it being a lot of work to do the upgrade in one
step.
Why does that need to happen?
Why can't the upgrade be handled in two steps and we just package  the
necessary parts to do all the steps?

How much harder  are we talking about than getting the s3qladm and s3ql
libraries from the 2.5 version of s3ql into Jessie?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

al. And I was one of them.
To the best of my knowledge no one counter-seconded the proposal in this 
way. 
So again, the process was followed.

Another thing is discussing the matter. Yes, I ack that there where some 
people who didn't like the idea, much in the same way that there are people 
who like the idea. No one of the two system is the panacea, so of course 
there 
would be always some kind of disagreement. But my position in that regard 
is 
that we had a rough consensus.

Hope that clarifies my previous mail :)

And from Russ Allbery:
> You are copied on this message because you raised objections noted by
> the policy editors during the discussion of menu policy or seconded the
> proposal in #707851.  The TC is currently evaluating a request to review
> that proposal and the process surrounding it.

> If you seconded the proposal, I'd like to confirm that as part of your
> second, you believed that there was rough consensus and that objections
> that were raised had been addressed.  That is, please confirm that you
> evaluated not just the quality of the proposal, but also evaluated the
> discussion.

Hi Sam,

I did try to evaluate both the quality of the proposal and outcome of the
discussion, and thought that the people who had raised objections were in
the rough.  I may not have done a very good job of that, though.  (Also, I
felt like the proposal was a good path forward, which doesn't make me a
particularly unbiased judge of consensus.)


Sam hartman
Speaking only for myself


pgpjsVADEZVn4.pgp
Description: PGP signature

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Bill" == Bill Allombert  writes:

Bill> On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote:
>> In March of 2014, Charles Plessy asked the Debian Technical
>> Committee to review one of the policy editors decisions to revert
>> changes to how policy talks about the Debian Menu and MIME
>> support.  See http://bugs.debian.org/741573 for the TC process
>> and https://bugs.debian.org/707851.  for the process within
>> debian-policy.
>> 
>> One of the issues is the question of whether the Debian Policy
>> community reached consensus around the proposal.  I've
>> investigated this question as part of trying to understand how I
>> will vote within the TC process.

Bill> I want to point out that I have split the menu policy changes
Bill> in 3 parts, so that the less controversial part could be
Bill> decided separately, see #742532.  However nobody was
Bill> interested in seconding this. So I am let to believe there is
Bill> no actual consensus on this.

I agree that there doesn't seem to be consensus on your proposed split.

I don't think I can infer anything about the overall proposal's support
from lack of support for the split.  As an example, if I had high
confidence that I could get consensus on the entire proposal, I would
not generally support handling the less contraversial parts first.

If you handle the less-controversial parts first, it's easy to get into
a situation where that's all you solve.  When you do that because you
honestly can't get consensus on more than the less-controversial parts,
the process is working.  However, sometimes those sort of splits can
create dynamics where you get less of a solution than you might hope.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Charles" == Charles Plessy  writes:

Charles> Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a
Charles> écrit :
>> >>>>> "Bill" == Bill Allombert  writes:

Charles> Also, the question is not whether the FreeDesktop menu
Charles> should be described in the Policy or not, or how to split
Charles> the proposal in 3, 4 or 42 parts.  It is not even on
Charles> whether the Debian menu should be a "must" or a "should",
Charles> because for that as well, we got a "rough consensus", where
Charles> at the end of the process there was only a single person
Charles> opposing the change.  Neither it is about re-starting a
Charles> search for people disagreeing (or shall I restart a GR on
Charles> systemd ?).  The question is whether a single individual
Charles> can engage in confrontational commit wars to block changes
Charles> in Debian.

I hear your frustration that a proposal you worked on has been blocked
for over a year by the actions of one person.
For myself, though, I'd like to think of the questions differently,
because I'd like to grow from this experience.

Bill, in his role of policy editor said that he believed there was not a
consensus.  He cited a specific set of messages that he believes were
not properly addressed.
I do think it is the job of policy editors to be involved in judging
consensus.
I've been in the position of judging consensus, and made unpopular
calls.
It's hard.  You know you'll face others with strong negative feelings.
You're typically worried about whether you're making the right call.
You're typically hopeful that others will clearly see your point even
when they disagree.  You're frustrated when that doesn't happen.

While I disagree with Bill, I respect him when he makes a hard call like
that.

I agree with Charles though that one person should not be able to block
the process.

My hope for improvement is in how we handle things when a policy editor
or someone else in a similar role in the project claims we don't have
consensus.  What do we expect from our consensus judgers moving forward
in such situations?  What do we expect from ourselves as advocates of
proposals?  What is the process?

I'd like to share a couple of my thoughts.  I'm nervous that in doing so
I'll bias the discussion more than I like.  However, I'm more concerned
that unless I give some constructive examples of  what I'm talking
about, it will be hard to move forward.

A lot of my experience with consensus process is in the IETF.  There, if
you're in a position to judge consensus, you have an obligation to help
try and build the consensus when you judge that there is not consensus.
If you're in a position to judge consensus, you have an obligation to
lead the discussion, to focus on areas of disagreement, and to see if
your consensus call is correct.  There's an expectation that when you
call a lack of consensus, getting to consensus is going to be a
priority, and you're going to put in significant time to help.

Should some or all of the above be part of what we expect from policy
editors?

On another axis of the discussion, what's the appeals process?  Where do
you go when the discussion stalls or reaches an impass?  (In general,
that should not be the immediate reaction to a call of lack of
consensus; such a call is generally the start of a very fast-paced
discussion.)
Charles tried the TC in this instance.
I think the TC has the expertise to review the technical aspects of
these matters.  I think that's actually important to reviewing a
consensus discussion, and is most of the skills you'd need to review
this sort of consensus evaluation.

However, I think the TC might be more effective in situations like this
if it better understood its role.  There was significant disagreement
between the members of the TC Charles brought the issue to and Charles
about what the role of the TC should be.  During the process, the TC
membership changed, and today, I'd say that the TC is probably unsure
what its role should be here.  For reasons I don't fully understand, the
TC process was slower than I'd like.

I hope by focusing on questions like these we can grow from this
experience and be better positioned to resolve future situations where
we're unsure about consensus.  I hope we can treat everyone with
respect--those judging consensus, those reviewing that decision, those
disagreeing with that decision, and those who just want to see forward
progress.

thanks for your consideration.

--Sam


pgpBzAxfRoxkW.pgp
Description: PGP signature

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:


Nikolaus> I agree. There shouldn't have been an s3ql package in
Nikolaus> Wheezy. This was when I was young and inexperienced with
Nikolaus> Debian packaging. However, the situation is different for
Nikolaus> Jessie. Now that it is much more mature, there will be
Nikolaus> issues in keeping the stretch S3QL fully backwards
Nikolaus> compatible with Jessie S3QL.

I don't understand.
do you mean perhaps no issues or a managable number of issues or
something like that?

>> So, you talked about it being a lot of work to do the upgrade in
>> one step.  Why does that need to happen?  Why can't the upgrade
>> be handled in two steps and we just package the necessary parts
>> to do all the steps?

Nikolaus> That would mean to package ~5 intermediate S3QL
Nikolaus> versions. Not a big deal in terms of work (since these
Nikolaus> versions were already in testing at some point), but do
Nikolaus> you think that would be acceptable for a point release?

>> How much harder are we talking about than getting the s3qladm and
>> s3ql libraries from the 2.5 version of s3ql into Jessie?

Nikolaus> I don't understand the question.

Ah.
Looking at the debian news file, the only announced upgrade is  at
version 2.5 between 1.11 and 2.11.1.

So, for example, I've installed s3ql 2.7-1 on a jessie system and it
seems happy to upgrade my wheezy filesystem. (Note that some of the
tests failed during the build of 2.7-1 on Jessie I had to build with
DEB_BUILD_OPTIONS=nocheck, so some work is required)

It sounds like you believe that many intermediate versions are required.
What am I missing?  It looks to me like only one intermediate version is
needed.  Can we get that into Jessie?  I don't know, but I'd be happy to
talk to the release team and make my best argument for it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Charles" == Charles Plessy  writes:

Charles> Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a
Charles> écrit :
>> 
>> Bill, in his role of policy editor said that he believed there
>> was not a consensus.

Charles> Hi Sam,

Charles> I think that what you wrote does not reflect what happened:

Charles>  - Russ gave me the green light for committing the changes,
Charles> see
Charles> <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.
Charles> Only Policy Editors can decide that a change will be
Charles> committed, thus it is my understanding that Russ, as a
Charles> Policy Editor, judged that there was consensus.
I agree with that.

Charles>  - Without consulting with the other Policy Editors, Bill
Charles> reverted the commit.  This solo action was done out of the
Charles> usual process for seeking consensus before changing the
Charles> Policy.

Well, I'd phrase it as Bill, in his role as policy editor felt that Russ
had misjudged consensus.
My understanding is that the process is silent on this: it neither
permits nor forbids this.

I actually think you want the process to permit policy editors to
disagree with each other in this way.
There's some question about how to handle a disagreement when it arises.
Immediately reverting is an option that tends to maximize frustration,
especially if it is not explicitly called out in the process.

>> A lot of my experience with consensus process is in the IETF.
>> There, if you're in a position to judge consensus, you have an
>> obligation to help try and build the consensus when you judge
>> that there is not consensus.  If you're in a position to judge
>> consensus, you have an obligation to lead the discussion, to
>> focus on areas of disagreement, and to see if your consensus call
>> is correct.  There's an expectation that when you call a lack of
>> consensus, getting to consensus is going to be a priority, and
>> you're going to put in significant time to help.
>> 
>> Should some or all of the above be part of what we expect from
>> policy editors?

Charles> I totally share this point of view.  (This is why after
Charles> leading the release of the Policy version 3.9.5.0, seeing
Charles> that I would not have time to do the same within a year or
Charles> two, I quitted as a Policy Editor).

OK.
If there's general agreement on this, it might be a good idea to get
this expectation into  the process document and reference that from the
delegation.
Naturally as part of that you'd want to make sure that the policy
editors are comfortable with the responsibility the community is asking
them to take up.

>> On another axis of the discussion, what's the appeals process?

Charles> The only appeal I would see would be through the DPL, since
Charles> he appoints and replaces the Policy Editors, who are DPL
Charles> delegates.

Well, I'll note that's not what you did; you brought the issue to the TC
rather than the DPL.
I'll also note that our constitution explicitly limits the DPL's actions
with regard to a decision of a delegate.

I think the DPL is who you'd bring an issue to if you thought an editor
was consistently not meeting the responsibility of the post.  I think
the DPL has no formal power to reverse a specific decision.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Russ's role

[Sam Hartman]

You said:
> 
> I think that what you wrote does not reflect what happened:
> 
Charles>  - Russ gave me the green light for committing the changes, see
Charles>.  
Only Policy
Charles>Editors can decide that a change will be committed, thus it is my 
understanding
Charles>that Russ, as a Policy Editor, judged that there was consensus.

Bill>This is not my understanding. It seemed clear that Russ did not have time 
to do
Bill> such review but trusted you as former policy editor. However I really did 
not
Bill> expect you to use commit right you should not have had anymore to
Bill> force the isssue.

Hi.
As a matter of fact finding.
Russ's message, which Charles sites implies to me that Russ was swamped
and didn't have time to do the commit.  By seconding, he had already
done the review.
That's consistent with what he said in this bug about his second (quoted
in my mail to debian-policy last week)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784783: krb5-admin-server: install failure during dpkg --configure

[Sam Hartman]

I'm confused about this.
The krb5-kdc/debconf template is included in the krb5-kdc package, which
is a dependency of krb5-admin-server.
That should mean that krb5-kdc is configured (and thus the template
available) prior to krb5-admin-server.
Russ and ben, am I missing something here?

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Initial draft of resolution

[Sam Hartman]

Proposed for your consideration and checked into git for your editing:

Background/Rationale (Constitution 6.1(5)): 

1. In #750135, the
technical committee was asked by Manuel Fernandez Montecelo who should
be the maintainer of the aptitude projectp.  He had been actively committing 
until his commit access was removed by Daniel Hartwig.  Manuel  and Daniel took 
over development of aptitude in 2011 with the support of Christian Perrier, an 
admin for the aptitude alioth project.  There was friction between Manuel and 
Daniel, which eventually resulted in  Manuel's commit access being revoked by 
Daniel.  Since then, Daniel has become inactive, and did not comment on the 
issue when requested by the technical committee.

2) During the discussion of this issue, Christian proposed that he and
Axel Beckert could watch the social aspects of aptitude development
and restore Manuel's commit access.  Christian still has
administrative rights and believes he has the technical power to implement his 
proposal.  However he wants review from a broader audience before implementing 
that proposal.


Advice (Constitution 6.1.5):

1.  The technical committee agrees that Christian has the power to implement 
his proposal and encourages him to do so.

2.  The committee agrees that restoring Manuel's committ access is a
good step to move Aptitude development forward.  Since there is a
clear way to accomplish this goal within the existing Aptitude project
support that approach.

3.  We hope that Christian and Axel will work to managed the social
aspects of the Aptitude project, working to recruit new developers,
building a stronger Aptitude development community, and establishing
policies and procedures that promote a collaborative team.  Sometimes
the skills necessary to grow a community ar different than the skills
to develop a project.  Through this approach we hope the Aptitude
community will gain both sets of skills.

4.  We thank Manuel for bringing this matter to our attention and
apologize for our delay in resolving this matter.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

Is your realm actually called EXAMPLE.COM?
my guess is that somehow the realm in kdc.conf was incorrect and so that
stanza is not being used.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

OK, so the default_realm in /etc/krb5.conf matches the realm in kdc.conf
and yet the kdc is not using /var/lib/krb5kdc.

Ben, any thoughts here?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

No, I cannot reproduce.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

The database (principal and principal.*) live under /var/lib.
The ACL and stash file live in /etc/krb5kdc.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

> "Erik" == Erik Haller  writes:

Erik> What is telling kadmind to use the /etc/krb5kdc directory?
Erik> configure script? Because the /etc/krb5kdc/kdc.conf points ->
Erik> /var/lib  and it runs just fine with the databases under
Erik> /etc.

That's the big question, yes.

The only thing I know of that normally causes this is when the realm the
 KDC thinks it is serving for is not the same as the realm it's actually
 serving for and the config stanza gets ignored.

I'm hoping one of the other maintainers (Ben) will comment on other
things to check.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

Yeah, but the config file should override that.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

Do you see any differences in /etc/krb5.conf or /etc/krb5kdc/kdc.conf in
the successful vs unsuccessful situations?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Sam Hartman]

control: tags -1 moreinfo


I took the following steps:

1) create a new sid chroot.

2) apt-get update

3) apt-get install krb5-user

As part of 3 krb5-config got installed and because of my DNS I was
prompted to configure my krb5.conf.  I entered the realm I was going to
create (EXAMPLE.COM) but specified no kerberos or admin servers when
prompted.

4) apt-get install krb5-admin-server

5) krb5_newrealm

I then looked and confirmed that the database was in /var/lib/krb5kdc

so, at least for me, the software works as intended.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762194: Automatic switch to systemd on wheezy->jessie upgrades (thoughts)

[Sam Hartman]

Thanks.
I found this post of your to be really thought-provoking and useful and
an example of the sort of discourse we should strive to when discussing
these issues.
I think the discussion of switching default inits in the future is
something to particularly consider.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#776981: unblock: krb5/1.12.1+dfsg-17

[Sam Hartman]

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

Please unblock package krb5

This version includes the upstream official patch for
mitkrb5-sa-2015-001, a series of security vulnerabilities made public
today.  I've received permission from the security team to upload a
backport of this patch to stable-security.

diff --git a/debian/.git-dpm b/debian/.git-dpm
index 423df28..237c3b1 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-877ad027ca2103f3ac2f581451fdd347a76b8981
-877ad027ca2103f3ac2f581451fdd347a76b8981
+769a3f26c919339002ef2936592a90d144d0e238
+769a3f26c919339002ef2936592a90d144d0e238
 00dec38e79dd6436e9efed873df00e6ea11fdd0e
 00dec38e79dd6436e9efed873df00e6ea11fdd0e
 krb5_1.12.1+dfsg.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index 226cc36..c8a284c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+krb5 (1.12.1+dfsg-17) unstable; urgency=high
+
+  * MITKRB5-SA-2015-001
+- CVE-2014-5352: gss_process_context_token() incorrectly frees context
+- CVE-2014-9421: kadmind doubly frees partial deserialization results
+- CVE-2014-9422: kadmind incorrectly validates server principal name  
+  - CVE-2014-9423: libgssrpc server applications leak uninitialized bytes
+
+
+ -- Sam Hartman   Tue, 03 Feb 2015 10:29:35 -0500
+
 krb5 (1.12.1+dfsg-16) unstable; urgency=medium
 
   * Import upstream patches for CVE-2014-5353 and CVE-2014-5354,
diff --git a/debian/patches/series b/debian/patches/series
index 9d19440..721cb89 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -26,3 +26,4 @@ upstream/0025-Fix-build-on-systems-without-RTM_OLD.patch
 upstream/0026-Remove-rtm_type_name.patch
 upstream/0027-Fix-LDAP-misused-policy-name-crash-CVE-2014-5353.patch
 0028-Support-keyless-principals-in-LDAP-CVE-2014-5354.patch
+upstream/0029-MITKRB5-SA-2015-0001.patch
diff --git a/debian/patches/upstream/0029-MITKRB5-SA-2015-0001.patch 
b/debian/patches/upstream/0029-MITKRB5-SA-2015-0001.patch
new file mode 100644
index 000..c8183a3
--- /dev/null
+++ b/debian/patches/upstream/0029-MITKRB5-SA-2015-0001.patch
@@ -0,0 +1,397 @@
+From 769a3f26c919339002ef2936592a90d144d0e238 Mon Sep 17 00:00:00 2001
+From: Sam Hartman 
+Date: Tue, 3 Feb 2015 10:26:16 -0500
+Subject: MITKRB5-SA-2015-0001
+
+Topic: Vulnerabilities in kadmind, libgssrpc, gss_process_context_token
+
+CVE-2014-5352: gss_process_context_token() incorrectly frees context
+
+CVSSv2 Vector: AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C
+
+CVSSv2 Base Score:  9.0
+
+Access Vector:  Network
+Access Complexity:  Low
+Authentication: Single
+Confidentiality Impact: Complete
+Integrity Impact:   Complete
+Availability Impact:Complete
+
+CVSSv2 Temporal Score:  7.0
+
+Exploitability: Proof-of-Concept
+Remediation Level:  Official Fix
+Report Confidence:  Confirmed
+
+CVE-2014-9421: kadmind doubly frees partial deserialization results
+
+CVSSv2 Vector: AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C
+CVSSv2 Base Score:  9.0
+CVSSv2 Temporal Score:  7.0
+
+CVE-2014-9422: kadmind incorrectly validates server principal name
+
+CVSSv2 Vector: AV:N/AC:H/Au:S/C:P/I:P/A:C/E:POC/RL:OF/RC:C
+CVSSv2 Base Score:  6.1
+CVSSv2 Temporal Score:  4.8
+
+CVE-2014-9423: libgssrpc server applications leak uninitialized bytes
+
+CVSSv2 Vector: AV:N/AC:L/Au:N/C:P/I:N/A:N/E:H/RL:OF/RC:C
+CVSSv2 Base Score:  5.0
+CVSSv2 Temporal Score:  4.4
+
+Patch-Category: upstream
+---
+ src/kadmin/server/kadm_rpc_svc.c| 12 +++-
+ src/lib/gssapi/krb5/context_time.c  |  2 +-
+ src/lib/gssapi/krb5/export_sec_context.c|  5 +
+ src/lib/gssapi/krb5/gssapiP_krb5.h  |  1 +
+ src/lib/gssapi/krb5/gssapi_krb5.c   |  2 +-
+ src/lib/gssapi/krb5/inq_context.c   |  2 +-
+ src/lib/gssapi/krb5/k5seal.c|  2 +-
+ src/lib/gssapi/krb5/k5sealiov.c |  2 +-
+ src/lib/gssapi/krb5/k5unseal.c  |  2 +-
+ src/lib/gssapi/krb5/k5unsealiov.c   |  2 +-
+ src/lib/gssapi/krb5/lucid_context.c |  5 +
+ src/lib/gssapi/krb5/prf.c   |  4 
+ src/lib/gssapi/krb5/process_context_token.c | 17 -
+ src/lib/gssapi/krb5/wrap_size_limit.c   |  2 +-
+ src/lib/gssapi/mechglue/mglueP.h|  1 -
+ src/lib/kadm5/kadm_rpc_xdr.c|  2 ++
+ src/lib/rpc/auth_gssapi_misc.c  |  1 -
+ src/lib/rpc/svc_auth_gss.c  | 25 ++---
+ 18 files changed, 42 insertions(+), 47 deletions(-)
+
+diff --git a/src/kadmin/server/kadm_rpc_svc.c 
b/src/kadmin/server/kadm_rpc_svc.c
+index 3837931..f4d2a7c 100644
+--- a/src/kadmin/server/kadm_rpc_svc.c
 b/src/kadmin/server/kadm_rpc_svc.c
+@@ -4,7 +4,7 @@
+  *
+  */
+ 
+-#include 
++#include 
+ #include 
+ #include  /* for gss_nt_krb5_name */
+ #include 
+@@ -296,14 +

Bug#773778: libverto-libev1: set_flags implementation broken

[Sam Hartman]

This looks simple and I'll put together a request.  My understanding is
that unless we call this RC because it totally breaks libkrad, that I
need to file for a pre-approved change, and that such a change must be
approved by Jan 5.

I should be able to put together the unblock by Monday or so.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774190: unblock: libverto/0.2.4-2

[Sam Hartman]

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

Please unblock package libverto

Hi.  It turns out that verto_setflags is broken against the
libverto-libev module, which is the one Debian uses basically all the
time.  As a result, krb5-kdc cannot act as an OTP preauth server.  The
fix is quite simple and I request pre-approval to upload it.  I could
make an argument that this is RC against libverto as it breaks a
significant feature of krb5-kdc.

diff --git a/debian/changelog b/debian/changelog
index 0bed159..5716c01 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libverto (0.2.4-2) unstable; urgency=medium
+
+  * Fix libverto-libev's setflags handling, Closes: #773778
+  - Without this fix, RADIUS support in krb5-kdc is entirely broken,
+which prevents Debian from being a server for OTP preauth.
+  * 
+
+ -- Sam Hartman   Mon, 29 Dec 2014 20:17:46 -0500
+
 libverto (0.2.4-1) unstable; urgency=low
 
   * Update to new upstream
diff --git a/src/verto-libev.c b/src/verto-libev.c
index 2eb08fc..9c7c324 100644
--- a/src/verto-libev.c
+++ b/src/verto-libev.c
@@ -106,7 +106,9 @@ libev_ctx_set_flags(verto_mod_ctx *ctx, const verto_ev *ev,
 if (verto_get_flags(ev) & VERTO_EV_FLAG_IO_WRITE)
 events |= EV_WRITE;
 
+ev_io_stop(ctx, (ev_io*) evpriv);
 ev_io_set(((ev_io*) evpriv), verto_get_fd(ev), events);
+ev_io_start(ctx, (ev_io*) evpriv);
 }
 }
 
@@ -131,7 +133,6 @@ libev_ctx_add(verto_mod_ctx *ctx, const verto_ev *ev, 
verto_ev_flag *flags)
 } w;
 ev_tstamp interval;
 
-
 w.watcher = NULL;
 *flags |= VERTO_EV_FLAG_PERSIST;
 switch (verto_get_type(ev)) {






unblock libverto/0.2.4-2

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760754: Debian freeradius consider all files in modules/ folder, also *.dpkg-* ones...

[Sam Hartman]

I'd recommend holding on  on fixing this bug until we get freeradius 3
into the archive.

We'll still have some sort of problem for policy.d.
It may be worth bringing this up on the upstream development list.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783271: When configuring custom logging in /etc/krb5.conf,, xrb5 services are unable to write to these log files as they are not, permitted in the service configuration used by systemd

[Sam Hartman]

It's my plan to close this as not a bug; Russ's explanation for how to
relax the permissions check seems entirely reasonable as a solution.
--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780264: Bug #780264 : Improved fix for M2Crypto incompatibility

[Sam Hartman]

Hi.
I'll be on vacation the rest of this week and will review on my return
monday.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752409: krb5: Modify the control file for bootstrapping without LDAP

[Sam Hartman]

These still aren't in a state wwhere both patches can be applied right?
I wonder whether it would be better to close these bugs and open new
bugs when you're actually in a position that applying a complete patch
would be useful to you and would not break the package working with dak,
debhelper or anything else?

--sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#764669: kinit without username, behaviour changes betweek wheezy and jessie

[Sam Hartman]

I'm sort of horrified if krb5-auth-dialogue actually calls kinit rather
than using APIs directly.
But that's not really related to this bug.

just kinit seems to work fine for me  with 1.12.1+dfsg-9
so I'd like more detail on what goes wrong.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781108: unblock: krb5/1.12.1+dfsg-19

[Sam Hartman]

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

Please unblock package krb5

The previous package failed to mark some directories as optional in the systemd 
unit files, so for example if you don't have /etc/ssl/private, then krb5-kdc 
and krb5-admin-server fail to start.


(include/attach the debdiff against the package in testing)
diff --git a/debian/changelog b/debian/changelog
index 566e140..093c3bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+krb5 (1.12.1+dfsg-19) unstable; urgency=medium
+
+  * mark systemd unit directories as optional, Closes: #780831
+
+ -- Sam Hartman   Fri, 20 Mar 2015 16:22:33 -0400
+
 krb5 (1.12.1+dfsg-18) unstable; urgency=high
 
   * Import upstream patch for CVE-2014-5355, Closes: #778647
diff --git a/debian/krb5-admin-server.service b/debian/krb5-admin-server.service
index 8b544e2..ae742f4 100644
--- a/debian/krb5-admin-server.service
+++ b/debian/krb5-admin-server.service
@@ -6,9 +6,9 @@ Description=Kerberos 5 Admin Server
 Type=simple
 ExecStart=/usr/sbin/kadmind -nofork $DAEMON_ARGS
 EnvironmentFile=-/etc/default/krb5-admin-server
-InaccessibleDirectories=/etc/ssh /etc/ssl/private  /root
+InaccessibleDirectories=-/etc/ssh -/etc/ssl/private  /root
 ReadOnlyDirectories=/
-ReadWriteDirectories=/var/tmp /tmp /var/lib/krb5kdc /var/run /run
+ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run
 CapabilityBoundingSet=CAP_NET_BIND_SERVICE
 
 [Install]
diff --git a/debian/krb5-kdc.service b/debian/krb5-kdc.service
index 88aad48..5af09a5 100644
--- a/debian/krb5-kdc.service
+++ b/debian/krb5-kdc.service
@@ -8,9 +8,9 @@ PIDFile=/var/run/krb5-kdc.pid
 ExecReload=/bin/kill -HUP $MAINPID
 EnvironmentFile=-/etc/default/krb5-kdc
 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $DAEMON_ARGS
-InaccessibleDirectories=/etc/ssh /etc/ssl/private  /root
+InaccessibleDirectories=-/etc/ssh -/etc/ssl/private  /root
 ReadOnlyDirectories=/
-ReadWriteDirectories=/var/tmp /tmp /var/lib/krb5kdc /var/run /run
+ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run
 CapabilityBoundingSet=CAP_NET_BIND_SERVICE
 
 [Install]

unblock krb5/1.12.1+dfsg-19

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781311: gss_delete_sec_context breaks openssl usage in other libraries

[Sam Hartman]

package: moonshot-gss-eap
version: 0.9.2-3
severity: grave

Whenever the last gss-eap security context is deleted, the gss-eap
mechanism shuts down openssl including freeing x_data, error strings,
and engines.
In practice this tends to mean that any other library in the same
process using openssl will fail.
So, for example if you use GSS-API to authenticate a TLS-protected
session, then that session will fail.

This is grave because it breaks unrelated packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781312: CA certificates cannot handle internal space

[Sam Hartman]

package: moonshot-gss-eap
version: 0.9.2-3
severity: serious
justification: Broken interoperability with the UK's production Moonshot
infrastructure.

It turns out that despite code designed specifically to permit internal
white space in CA certificates in moonshot trust anchors, the length
check in util_moonshot.c will reject a CA certificate whose base64
encoding includes whitespace.

Unfortunately, JISC Assent, the production Moonshot infrastructure in
the UK, includes internal space in the cross-organizational certificates
it generates.

So, using this version of the software, you cannot interact with those
credentials.


--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781108: unblock: krb5/1.12.1+dfsg-19

[Sam Hartman]

Of this already seems to have migrated into testing

On March 28, 2015 2:57:33 PM EDT, Niels Thykier  wrote:
>Control: tags -1 confirmed moreinfo
>
>On 2015-03-24 16:51, Sam Hartman wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> 
>> Please unblock package krb5
>> 
>> The previous package failed to mark some directories as optional in
>the systemd unit files, so for example if you don't have
>/etc/ssl/private, then krb5-kdc and krb5-admin-server fail to start.
>> 
>> [...]
>> 
>> unblock krb5/1.12.1+dfsg-19
>> 
>> [...]
>
>Ack, please go ahead and upload this.
>
>Thank,s
>~Niels

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

Bug#741573: Requesting input on TC deliberations about menu system and policy

[Sam Hartman]

Dear Charles,

Last Thursday, the TC met.  As part of that meeting we discussed
#741573.  See the logs at
http://meetbot.debian.net/debian-ctte/2015/debian-ctte.2015-03-26-18.59.log.html
.

Currently the plan is that Keith is  going to  propose some text within
the policy process that he believes might be a reasonable way forward.

You'd expressed some concern about the approach the TC is taking and we
were hoping to seek your input on where you think we are and on whether
we're moving forward in a reasonable way.

Speaking only for myself, it seems to me that there are a couple of
challenges that make it somewhat difficult to address the question of
whether the process was followed directly.  
Steve  claimed that the policy process is not a rough consensus process
and that the fact that Bill objected  in-and-of-itself might be
sufficient to argue that there was not consensus.
The process.txt document dated Spetember 14, 2014 does not support
Steve's claim.  I have not read previous versions of that document, and
I don't know which version of the process the TC should look at here.

Secondly, we've seen some argument within the TC that the policy
proposal might be technically flawed.  While I don't think we want to
second guess the process, at the end of the day we(the TC) have to be
comfortable with our technical policy.  I'd hope that if someone takes a
technically valid approach different than the one we would take, we'd
support the people doing the work taking the approach they favor.
However, if a valid process reaches a conclusion we think has
significant technical flaws, I would not ebxpect us to agree with that.

I haven't yet seen an explanation of the technical flaw that may exist
in the original policy proposal.

I think we'd rather see something everyone is happy with than have a
fight about process, but there does seem to be a number of people on the
TC who care strongly about respecting the work done within the
debian-policy list.

We'd really appreciate your input on where this stands and thoughts
about our current approach.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Menu Systems: Thoughts about Next Steps

[Sam Hartman]

Having reviewed the  policy team's process.txt document and having
reviewed Charles's comments, I'm much less sanguine when I think about
the approach for resolving the menu system discussion  that we discussed
last Thursday.

Keith may well have an approach that improves over both the status quo
and the version Russ committed.
However, he can rebase his diff   and propose it against whatever the
policy is when it gets to that point in the process.

I think there's significant value in  actually looking at the process
issue.

How would people feel about:

* Someone reads  #707851 to confirm  the facts presented.  In
  particular, confirm the seconds were made.

* We contact those who seconded confirming that by seconding they
  believed both that the proposal was good and that rough consensus was
  reached as described in the current process.txt document.

* We make an explicit call for unresolved  objections  to debian-policy,
  Bill and debian-ctte, giving people a couple of weeks.

* We ask those who seconded to help us understand whether objections
  that are raised were discussed, and if so, what the resolution was
  during the debian-policy discussion.

I get the impression that Steve at least believes that the proposal in
#707851 is not technically sound.  He may have raised that before either
here or in #707851.  At this point I have not read all the bug log for
either this bug or #707851, and it's long enough I probably never will.
Certainly if the TC believes the proposal is unsound that's going to
factor into what we do.

My hope is that an eventual resolution to this issue contains the
following points:

* Encourage Keith any anyone else who has improvements in this space to
  bring them up within the policy process, regardless of where we leave
  this issue.

* States that we expect those raising concerns about consensus to
  clearly articulate the objections they believe are unresolved.  Once a
  proposal has received enough positive interest, we expect those who do
  not articulate concerns and work so that their concerns are understood
  to stand aside rather than blocking the consensus process.  We hope
  the policy editors will hold themselves to the highest standard with
  regard to this point.  (wordsmithing required)

My thoughts about the rest of the resolution will depend on what
objections we find, our evaluation of soundness, etc.

I'd be interested in comments about this approach and peoples' feelings
about whether that's what we should do.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779557: Including additional users file doesn't work without full path to the file in the INCLUDE statement

[Sam Hartman]

Can you please reproduce with the 2.2.5 packages in Debian
testing/jessie?
I suspect this is likely fixed between 2.1.12 and 2.2.5 or has to do
with directory definitions in configs between distributions.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769972: Read before Voting: Note from hartmans about new member ballots

[Sam Hartman]

>>>>> "Don" == Don Armstrong  writes:

Don> ===BEGIN

Don> The Technical Committee recommends that Sam Hartman (hartmans)
Don> be appointed by the Debian Project Leader to the Technical
Don> Committee.

Don> A: Recommend to Appoint Sam Hartman (hartmans) B: Further
Don> Discussion

Don> ===END


Hi folks.  First, I am honored that you would consider me as a potential
member of the TC.  I am filled with joy at serving with the five
remaining members of the TC: Don, Steve, Bdale, and Keith are some of
the people I most respect in the project.I don't know Andreas as well
but would be delighted to get to know him better and work together.

However, since I put in my application a few months ago, I've become
aware of some issues that cause me to question whether my thoughts about
the TC are compatible enough with the existing members that I'd be a
good fit for the kind of TC you're trying to create.

I regret bringing this up at such a late point, although I couldn't come
up with any better options.  I didn't want to just have a discussion
with Bdale and the DPL.  I didn't feel comfortable engaging the TC as a
whole when it wasn't even public that I'd put in my name.

Unfortunately I'm just about to run out of the office.  I will send out
a note later today after I return outlining the thoughts I have.  My
hope is that you'll read the note and think we would make a good fit and
we can all work together to create the best TC we can.  However, if
after reading that note TC members decide I'm not the best fit (or
decide they'd like to discuss further with me), then I'll be happy as
well.  I think it more important that we be honest and open than that
any one person get selected.

Thanks for your consideration, and I'm sorry if there was a better way
to handle this.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775277: krb5-kdc: kpropd init scripts missing from package

[Sam Hartman]

> "Michael" == Michael Weiser  writes:

Michael> Hi, Mark and I have built and used our own local packages
Michael> with this patch applied for some revisions now (at least
Michael> -17, -18 and -19) and all seems fine. But it it is quite a
Michael> hassle to rebuild those local packages on every Debian
Michael> update.

Michael> Since we have provided a full, self-contained patch that
Michael> seems to solve the issue for good, can you please review
Michael> and comment on it so we can make some progress on getting
Michael> it included into the Debian package?

Unfortunately, Debian 8.0 is in the final release freeze.  After the
release of Debian 8.0 later this month, we'll take a look for inclusion
in the next Debian release.  That's going to be a couple of years out
though.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Ivan Baldo  writes:
>> What should happen if installing a package and then when it tries
>> to start its service it fails?

>> Currently the most common behaviour seems to be that the
>> installation fails.

>> But is that the best outcome?

Russ> Currently, Policy leaves this to the discretion of the package
Russ> maintainer.  To change that, what will be needed here is not
Russ> just an argument that other behaviors besides failing
Russ> installation might be desirable, but that there is a
Russ> compelling need to standardize this behavior across the entire
Russ> archive instead of leaving it to the discretion of the
Russ> maintainer.

I find this issue tends to come up a lot more than it used to.  The
issue is that systemd units tend to track a lot more errors than init
scripts.  So, in Jessie, there tend to be a lot more cases where a
package will fail to install under the same situations where in wheezy
it'd install fine.  The problem is made more complex by debhelper, which
makes it somewhat annoying (especially in dh 7 mode) to express this
maintainer preference.  So, you have a lot of dh7 packages that suddenly
got much more picky because people created service units.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Status of #750135 (Maintainer of aptitude package)

[Sam Hartman]

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


Didier> Given the situation (an unresponsive Daniel, a proposal from
Didier> people with powers to push the situation forward), I'd be
Didier> more inclined to say yes to Christian, without a formal
Didier> resolution.

Given that Christian has asked for additional support before moving
forward, I'd prefer to give him that.  I think the resolution should be
non-binding.  Something along the lines of We observed this fact.
Christian asked for input on whether this would be a good way forward.
The TC believes it would be.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

Ian, I'd like to encourage you to use less loaded words than "destroy."
When I hear that term and disagree with your analysis, my emotional
reaction is strong enough that I stop reading.
Your term is loaded enough that you lose the opportunity to try and get
me to think about whether you are right.
If your goal is to ask us to think about your position and engage in
reasoned discourse, you would be better served with more factual, less
emotional statements.
I understand that the emotional content is important too.  I'd recommend
carrying that by talking about your own emotional state rather than
using emotional words about the concept.
For example when I heard you describe that you were so upset you needed
to leave the conversation at Debconf, I heard someone being open and
honest about how much they care about the issue.

I think I may be following what Ian's saying.


If we adopt Keith's proposal without updating policy 9.6--we retainIs
the SHOULD have menu entries for all command line apps, but move the
metadata format to .desktop, we have a number of problems.  We have no
way to express the category information and some of the other metadata
from the trad menu that's kind of important for its expanded scope.

So, it's not clear what should happen.

If we revise 9.6 and  adopt Keith's proposal then we're basically
adopting the XDG menu's scope, but taking away the place where the
broader information could go.

In effect we leave menu entries that do belong on the trad menu but do
not belong on the XDG menu no where.

Depending on how we do things we may also significantly complicate the
runtime dependencies of light-weight windowmanagers if we force them to
parse .desktop files and do image conversion.


In effect by adopting Keith's proposal with an update to 9.6, we're
saying that as a matter of technical policy decided by the TC, there are
some menu entries on the trad menu that do not belong on any menu at
all.

We're leaving the specifics to the individual maintainers.  However, I
can see that if you value the scope of the trad menu, you'd be really
frustrated by that  decision.

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
Ian> Consensus"):
>> Having such serious objections that have not been adequately
>> considered means you don't have rough consensus at least in the
>> ways I judge rough consensus.

Ian> Thanks for your thoughtful response and care when reading.

Ian> However, I'm afraid I think this is rather muddled thinking.
Ian> Consensus is a question about what proprtion of people hold
Ian> certain opinion.  It doesn't involve a value judgement.
Ian> Whereas, `adequately considered' involves a value judgement.

Ah, yes, we do not agree on what consensus is.
I think I understand your position well at this point and I thank you
for sharinge.
While I think your view on what consensus is differs from the consensus
view of consensus, I can certainly see where you are coming from.

If there are areas where you think additional discussion would be
valuable, I'd be happy to engage.  For this point though, I think I
understand our disagreement, and while I respect  where you are coming
from I'll need to do what I think is best.

--Sam

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Hi.
I'd appreciate it if you would look at the restatement at the bottom and
help me make sure I'm understanding the technical implications of the
proposal we're considering.

>> I think I may be following what Ian's saying.

Ian> I agree with what you say in this summary except that I would
Ian> go further:

>> If we adopt Keith's proposal without updating policy 9.6--we
>> retainIs the SHOULD have menu entries for all command line apps,
>> but move the metadata format to .desktop, we have a number of
>> problems.  We have no way to express the category information and
>> some of the other metadata from the trad menu that's kind of
>> important for its expanded scope.
>> 
>> So, it's not clear what should happen.

Ian> The dominant interpretation of this proposal is that that this
Ian> information should simply be removed from Debian.

That doesn't make sense to me.
Without an update to section 9.6, we're saying that we agree with the
trad menu's scope, but want the data represented in .desktop files.

I personally think that would be bad technically, but I don't see how
you get from that to "delete".  You might get quickly to "the TC is
spewing nonsense because a bunch of interface work needs to be done to
make what they've asked us to do possible."
However I consider that different from "delete"

>> In effect by adopting Keith's proposal with an update to 9.6,
>> we're saying that as a matter of technical policy decided by the
>> TC, there are some menu entries on the trad menu that do not
>> belong on any menu at all.

Ian> Worse than that, the TC would be saying that - the trad menu
Ian> metadata database - currently in Debian [1] - which people have
Ian> been working on for many years - and want to keep working on
Ian> should be deleted.

I don't think so.
I think we'd be saying that people should evaluate each trad menu entry
against the newly revised 9.6 and if the package maintainer believed the
information  was worth keeping then it should be converted to .desktop.

I don't think you'd be happy with that result, but I think that is what
we'd be saying with Keith's draft including the section 9.6 update.

Some information would be deleted; we'd be updating the scope.
However other information would be converted.

I'm not trying to argue emotional loading here.  I honestly want to know
if I'm missing something here and whether more is deleted than I expect.

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> On Aug 28 2015, Ian Jackson  
wrote:
Nikolaus> [ things about the menu system ]

Nikolaus> This really has become a farce. This issue been open for
Nikolaus> more than a year. Sam rephrased the entire issue earlier
Nikolaus> this year in terms of consensus and has just finished his
Nikolaus> analysis. And now it seems the discussion is restarting
Nikolaus> again from the point where it started last year.

My understanding is that we're going to make a minor revision to option
D and vote.  Steve and Don wanted to see option D on the ballot, and
Keith is incorporating some of my feedback.

I don't think this discussion is what is blocking progress; I think
we're just waiting on Keith at this point, and some other TC members
including myself have agreed to help out if he gets busy.

Bug#741573: Voting on Debian Menu Policy next Tuesday

[Sam Hartman]

hi.
Keith and I hashed out proposed changes to option D on IRC.
Unless there are significant concerns raised by TC members, I plan to
call for votes on the following ballot next Tuesday.

Whereas:

   1. The Debian Policy Manual states (§9.6) that 'The Debian menu
  package provides a standard interface between packages providing
  applications and "menu programs"'. It further states that 'All
  packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications'.

   2. All details about menu system requirement are delegated to the
  Debian Menu sub-policy and Debian Menu System manuals (the
  "Debian menu system").

   3. An external specification, the Freedesktop Desktop Entry
  Specification (the ".desktop spec"), with native support in many
  X desktop environments, has appeared since the Debian Menu
  system was developed. The .desktop spec offers a fairly strict
  super-set of Debian Menu system functionality.

   4. The .desktop specification has significant technical benefits
  for users over the Debian menu system. The .desktop
  specification works together with the freedesktop.org mime type
  and icon specifications to provide operations expected by
  desktop users from other environments, such as Mac OS X or
  Windows. As such, applications must provide a .desktop file to
  operate well in most desktop environments.

   5. The Debian Technical Committee has been asked to resolve a
  dispute between maintainers of Debian Policy over a change that

  i. incorporates the description of the FreeDesktop menu system
 and its use in Debian for listing program in desktop menus
 and associating them with media types

 ii. softens the wording on the Debian Menu system to reflect that
 in Jessie it will be neither displayed nor installed by
 default on standard Debian installations.

 Therefore:


OPTION A:

   1. The Technical Committee adopts the changes proposed by Charles
  Plessy in ba679bff[1].

   2. Further modifications to the menu policy are allowed using the
  normal policy modification process.

[1]: 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


OPTION B:

   1. Considers that the policy procedure resulted in consensus, and
  adopts the changes proposed by Charles Plessy in ba67bff.[1]

   2. Further modifications to the menu policy are allowed using the
  normal policy modification process.

[1]: 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


OPTION C:

  1. The Technical Committee adopts the changes proposed by Bill
 Allombert.[1]

  2. Further modifications to the menu policy are allowed using the
 normal policy modification process.

[1]: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446


OPTION D:

   The Technical Committee has reviewed the underlying technical
   issues around this question and has resolved that Debian will be
   best served by migrating away from our own Debian Menu System and
   towards the common Freedesktop Desktop Entry Specification, and
   that menu information for applications should not be duplicated in
   two different formats.

   To encouage this change, we make menu files optional, ask that
   packages include .desktop files as appropriate and prohibit
   packages from providing both menu and .desktop files for the same
   application.

Using its power under §6.1.1 to decide on any matter of technical
policy, and its power under §6.1.5 to offer advice:

   1. The Technical Committee resolves that packages which provide
  applications customarily designed for use within a desktop
  environment should provide a .desktop file conforming to the
  Freedesktop Desktop Entry Specification.

   2. Packages may provide menu files at the pleasure of the
  maintainer, but packages providing a .desktop file shall not
  also provide a menu file for the same application.

   3. We further resolve that "menu programs" should not depend on the
  Debian Menu System and should instead rely on .desktop file
  contents for constructing a list of applications to present to
  the user.

   4. We advise the maintainers of the 'menu' package to update that
  package to reflect this increased focus on .des

Bug#741573: Comparison of Options AB and D

[Sam Hartman]

Hi.
So, after working with Keith yesterday on his option, I think I have a
much better understanding of what the tradeoffs are.
I'd like to present these to the TC as we're about to vote.

I'm ignoring ballot option C (afirm the status quo)  in this.

I'm also treating options A and B as the same; the only difference
between them is whether the TC explicitly states that the policy process
reached consensus on the text.


Both Ballot options emphasize the XDG desktop format over the existing
menu format.

Both ballot options remove the requirement that applications provide
menu entries for traditional command-line apps, instead leaving it to
the maintainer.

You could read option AB as leaving both the traditional menu and
.desktop in place for the foreseeable future.  The traditional menu would
have entries only for packages where the maintainers feel that's
valuable, and would be used by people who install the text-based menu
(if that's still around) or who run a non-desktop Window manager.  In
this option the TC recommends that the menu package automatically
translate .desktop files to menu entries.


Option D goes further.  Option D requires that packages drop their
traditional menu entries if they ship .desktop files.  (That's done on a
per-application not per-package basis).  Under option D you must use
desktop entries and not provide traditional menu entries if you want to
appear on the desktop menus.  This means all the common GUI apps will
disappear from the traditional menu until the traditional menu starts
parsing desktop entries.

The belief behind option D is that having two formats for the same rough
type of information is harmful and that the TC has chosen to set policy
that will move us away from that.

Option D is fairly harsh for people using traditional non-desktop window
managers.  Packages will probably start pulling traditional menu files,
but we have no one signed up to do the work of getting .desktop files to
work with these.  (We could adopt the Arch Linux solution, or we could
adopt something in the menu package, or some combination, but someone
has to do the work.)
Option D doesn't currently have any transition language.  We're in
effect saying that the traditional menu and non-desktop window managers
are a marginal enough use case that it's OK if they break unless someone
does the work to keep them running.

Ian is correct that we lose data under option D.  We lose the
traditional menu categorization of all the menu entries that get dropped
because those apps have .desktop files.  That might come back if we
define ways to encode that in .desktop files, but again we're saying
that if no one does the work it's OK to lose that.

However option D does force the issue.  We don't linger along with the
traditional menu and XDG menu having different support for the common
GUI applications.  We either get consistency or dropped behavior.  That
dropped behavior could in the worst case be the non-desktop window
managers ability to provide useful menus by default.  On the other hand
if people put in the work we could get a much more consistent experience
than we do today.  And option D does have a nice property of aligning
incentives to do work with those who will benefit from it.

Option D does not provide specific policy text.  It does point out what
changes (fairly small) would need to be made to the text from Option AB
(Charles's proposal).  My assumption is that the policy editors could
come up with text given the existing proposal and the note in option
option D if we were to decide on option D.  Presumably if debian-policy
couldn't even come to consensus on how to adopt text for option D given
a TC decision for option D, someone could NMU policy to implement the TC
decision.

All the options do permit the policy process to make further changes.
So, for example if we approve option D, debian-policy could relatively
quickly come up with text that implements option D, and then if someone
wanted to propose a specific transition plan, they could see if they
could get consensus behind it.



pgpJpZ5OqU_Ks.pgp
Description: PGP signature

Bug#741573: Comparison of Options AB and D

[Sam Hartman]

>>>>> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> On Aug 29 2015, Sam Hartman  wrote:
>> Option D goes further.  Option D requires that packages drop
>> their traditional menu entries if they ship .desktop files.
>> (That's done on a per-application not per-package basis).

Nikolaus> That would be a pretty ridiculous situation. So package
Nikolaus> maintainers would be free to ship .desktop files as well
Nikolaus> menu files for their favorite third menu system, but they
Nikolaus> *must not* ship menu files for the traditional debian
Nikolaus> menu?

correct.

Nikolaus> Surely there is no need to single out the traditional menu
Nikolaus> as something that must not be used. It's sufficient if
Nikolaus> policy mandates the use of .desktop files, anything beyond
Nikolaus> that ought to be entirely up to the maintainer.

I think the argument in favor of this need is that we're trying to force
a transition of the traditional menu to .desktop as a metadata format.

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

>>>>> "Steve" == Steve Langasek  writes:

Steve> On Fri, Aug 28, 2015 at 09:13:33AM -0400, Sam Hartman wrote:
>> If we adopt Keith's proposal without updating policy 9.6--we
>> retainIs the SHOULD have menu entries for all command line apps,
>> but move the metadata format to .desktop, we have a number of
>> problems.  We have no way to express the category information and
>> some of the other metadata from the trad menu that's kind of
>> important for its expanded scope.

>> So, it's not clear what should happen.

>> If we revise 9.6 and adopt Keith's proposal then we're basically
>> adopting the XDG menu's scope, but taking away the place where
>> the broader information could go.

>> In effect we leave menu entries that do belong on the trad menu
>> but do not belong on the XDG menu no where.

>> Depending on how we do things we may also significantly
>> complicate the runtime dependencies of light-weight
>> windowmanagers if we force them to parse .desktop files and do
>> image conversion.


>> In effect by adopting Keith's proposal with an update to 9.6,
>> we're saying that as a matter of technical policy decided by the
>> TC, there are some menu entries on the trad menu that do not
>> belong on any menu at all.

Steve> If this is the message that the ballot option is sending,
Steve> then I agree that it's concerning.  I'm aware there are some
Steve> maintainers of desktop environments who view this as the
Steve> goal; my support for Keith's proposal was predicated on the
Steve> belief that this would /not/ be the outcome, but instead that
Steve> we were describing a path forward by which existing menu
Steve> system entries would be translated into .desktop files and
Steve> the semantics would be preserved.

Steve> The XDG .desktop format allows applications to specify that
Steve> they should or should not be shown in particular environments
Steve> using the OnlyShowIn/NotShowIn keywords.  I assumed it would
Steve> be straightforward to declare a new OnlyShowIn value that
Steve> menu consumers could key on if they wish to show the
Steve> traditional menu heirarchy, and that this could be
Steve> implemented without causing any problems for the existing
Steve> desktop environments.

Steve> Have I overlooked something that makes this approach
Steve> untenable?  Should the ballot option be extended to make this
Steve> a more explicit recommendation?

Since writing that message to Ian, I've thought more about this and
there's been a bit of rewording.  So, I do believe that Keith's draft
more follows what you are talking about.  I think that what Keith came
up with yesterday makes it clear that this is the recommended path
forward.  I think that's especially true if we surface the notes in the
keith_draft.txt as you suggested in another note.

However, we're pushing a fairly harsh transition time table with the
current option D.  At the same time we're recommending the trad menu
package support .desktop files, we are recommending that people pull
trad menu files from packages that also have .desktop files.  That very
quickly gets you into the situation where popular applications like
iceweasel disappear from the older window managers.

Several people have expressed doubts about whether the Menu maintainer
will ever follow our recommendation (and it is only advice) to support
.desktop files.

If no one does the work, itmay be that the trad menu disappears.

I think based on comments you made in the Systemd discussion you may be
OK with that outcome: obligating people who care about the trad menu to
do the work of making it viable for Stretch, although I may be
misremembering who had what positions and your analysis may differ in
this situation.

I think option D is reasonable and will definitely vote it above FD.  I
may or may not rank it first.  If I do it will be exactly because we're
pushing for that transition and trying to move to one metadata format.
If I do not it will be because I think that demanding packages drop menu
files if they keep .desktop files is premature at this time.

Bug#741573: Comparison of Options AB and D

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> A. This comes very close to design work which the CTTE
Nikolaus> should not be doing. If there's a conflict between two
Nikolaus> crappy designs and the CTTE is asked to rule, then you
Nikolaus> should pick the less crappy one or decline to rule, not
Nikolaus> create an entirely new design.

I agree that we should not pick an entirely new design.
Here though, option D  does not pick an entirely new design.
It explains what (if we approve option D) is our objection to option
A/B, explains the small fix and rules on that basis.

If that's too close to design work; if you actually want the TC to only
choose with no comment from the options before it; if you want us not to
raise objections and actually set policy as we are charged with in the
constitution, then you will find absolutely no one willing to serve on
the TC.
Nikolaus> D. Even if you were supposed to do design work, were asked
Nikolaus> to do so in this case, and I forget someone who benefits
Nikolaus> from this forced transition, was it really worth delaying
Nikolaus> a decision for more than a year and a release cycle? It's
Nikolaus> not that overruling Bill a year ago would somehow made a
Nikolaus> forced transition later on impossible.


Fuck no!  There's no sanity in the length this process has taken within
the TC.
Things are not working here; we have some real problems, and we are not
responsive at least in my opinion.
On that at least we can agree.

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

> "Keith" == Keith Packard  writes:

Keith> Thinking about this tonight, I've rewritten option D as AB +
Keith> patch.

Keith> As you can see, this makes packages shipping menu and
Keith> .desktop files for the same application buggy, makes all
Keith> packages using the Debian Menu System buggy, and advises that
Keith> the Debian Menu System be changed to read both menu and
Keith> .desktop files.

Keith> I think the following version is functionally equivalent to
Keith> the existing option D, and makes it clear that we're trying
Keith> to take your suggestion and push further in the same
Keith> direction.

Keith> OPTION D':

I ask you to retain the following two paragraphs that explain why we
prefer option D should we adopt this:
   The Technical Committee has reviewed the underlying technical
   issues around this question and has resolved that Debian will be
   best served by migrating away from our own Debian Menu System and
   towards the common Freedesktop Desktop Entry Specification, and
   that menu information for applications should not be duplicated in
   two different formats.

   To encourage this change, we make menu files optional, ask that
   packages include .desktop files as appropriate and prohibit
   packages from providing both menu and .desktop files for the same
   application.

(I've corrected the spelling of encourage)

Keith> Using its power under §6.1.1 to decide on any matter of
Keith> technical policy, and its power under §6.1.5 to offer advice:

Keith>1. The Technical Committee adopts the changes proposed by
Keith> Charles Plessy in ba679bff[1].

Keith>2. In addition to those changes, the Technical Committee
Keith> resolves that packages providing a .desktop file shall not
Keith> also provide a menu file for the same application.

Keith>3. We further resolve that "menu programs" should not
Keith> depend on the Debian Menu System and should instead rely on
Keith> .desktop file contents for constructing a list of
Keith> applications to present to the user.

Keith>4. We advise the maintainers of the 'menu' package to
Keith> update that package to reflect this increased focus on
Keith> .desktop files by modifying the 'menu' package to use
Keith> .desktop files for the source of menu information in addition
Keith> to menu files.

Keith>5. Discussion of the precise relationship between menu
Keith> file section/hints values and .desktop file Categories values
Keith> may be defined within the Debian Menu sub-policy and Debian
Keith> Menu System.

Keith>6. Further modifications to the menu policy are allowed
Keith> using the normal policy modification process.

Keith> [1]:
Keith> 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479


With those two rationalle paragraphs restored I support the reworded
option D and would rank it in the same place as the existing option D.
With them removed, I would rank D below FD.

Bug#797533: New CTTE members

[Sam Hartman]

I'd like to have a discussion about what we want from TC members before
we make a call for nominations.
The biggest question I have is how much time do we expect TC members to
have available for the TC.
i think we've been having a lot of trouble that seems like it has a high
probability of being related to insufficient bandwidth in TC members.
So, I think it would be good to better understand our expectations in
this regard before we make a call for nominations.

I think this is important enough that I'd be OK running with 6 members
for a while if it delays things.

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

> "Keith" == Keith Packard  writes:

Keith> Do you think the reworded version is easier to understand in
Keith> the context of the overall process? That was my major concern
Keith> here.

I think a bit.
My big question is whether you think we'd still be able to call for a
vote tomorrow if we make this change.

I think we're well into the point of diminishing returns (which is why i
won't drop option B--I don't think we need it but I so don't want to
have to redo the vote because someone other than me wanted it and we
remove it from the ballot)

So, my recommendation is if you still feel comfortable with me making a
CFV tomorrow push the change, else do not.

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

OK.
I'd really appreciate hearing from anyone now who needs more time before
a CFV.

Bug#797533: New CTTE members

[Sam Hartman]

> "Don" == Don Armstrong  writes:

Don> I think attendance at meetings as well as participation in
Don> threads, drafting, and voting is a requirement.

Don> I think that this amounts to between 1-6 hours a month of work;
Don> hopefully towards the low end of that spectrum for all but the
Don> most unusual of months.

Ah. So, We'd been coming at this from very different places.
I'm just throwing some random thoughts out there now.  I've been
convinced that we have an important discussion to have, but I have no
idea what position I'll be taking by the end of it.

I'll start with my goals:

1) Improve our response time to issues like the Aptitude bug and menu
policy

2) Have enough spare cycles that we can be doing some
introspection--thinking about how we could function better, developing
internal policies and procedures, helping write down advice for people
working with us.

3) Have somewhat more engagement in internal discussions.

In terms of time, I was assuming 1-6 hours a week or soaveraging out
around 2-3 hours a week when things are busy and say an hour when they
are not, and had been concerned that I was not really living up to what
I expected.  I don't think I could do what I've done in a couple of
hours a month, and I don't think we could get better response times than
we've had over the years even with 6 hours a month especially if it were
in large clumps within the month.


One problem with bursty time allocations is that if you don't spend
enough time to keep the issues in your head, you spend a lot of time
rebuilding context.

I wonder if it would help to work from the other direction.
What sort of turn around time would we expect for bugs like the menu
policy and the aptitude  maintainer issue?

For an issue, someone has to put in a fair bit of leg work, going
through and summarizing discussions, understanding the state before
something got to the TC, etc.

However everyone else has to follow things enough to  have an informed
opinion.

Also, discussions work better if people have time aligned enough to
respond within a day or so than if you're not sure if silence after a
week means that everyone agrees or no one has gotten around to reading
yet.

I fully understand that my assumptions may not be reasonable.  That's
one of the things you often find when you examine your assumptions.
Even if we want to find people who have more time it may be a gradual
transition over a few nomination cycles to get there.

I do think making our desires clear is important.  Part of it is letting
people know what they are getting into so they can decline if the fit
isn't right for them.  However, note that it works both ways: being on a
body where you wish people were able to spend more time can be just as
frustrating as being on a body where you're not able to keep up.  Also,
setting desires can help people discuss time allocation with their
management when they are talking about the impact of the TC.

so, I have no idea where we'll end up, but I think this will be a good
thing to ponder.

Bug#741573: CFV: Debian Menu Systems

[Sam Hartman]

In preparing this CFV, I have made one change to option D: I replaced
encouage with encourage because I believe that fixes a typo.


I'd like to call for votes on the following resolution:

Whereas:

   1. The Debian Policy Manual states (§9.6) that 'The Debian menu
  package provides a standard interface between packages providing
  applications and "menu programs"'. It further states that 'All
  packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications'.

   2. All details about menu system requirement are delegated to the
  Debian Menu sub-policy and Debian Menu System manuals (the
  "Debian menu system").

   3. An external specification, the Freedesktop Desktop Entry
  Specification (the ".desktop spec"), with native support in many
  X desktop environments, has appeared since the Debian Menu
  system was developed. The .desktop spec offers a fairly strict
  super-set of Debian Menu system functionality.

   4. The .desktop specification has significant technical benefits
  for users over the Debian menu system. The .desktop
  specification works together with the freedesktop.org mime type
  and icon specifications to provide operations expected by
  desktop users from other environments, such as Mac OS X or
  Windows. As such, applications must provide a .desktop file to
  operate well in most desktop environments.

   5. The Debian Technical Committee has been asked to resolve a
  dispute between maintainers of Debian Policy over a change that

  i. incorporates the description of the FreeDesktop menu system
 and its use in Debian for listing program in desktop menus
 and associating them with media types

 ii. softens the wording on the Debian Menu system to reflect that
 in Jessie it will be neither displayed nor installed by
 default on standard Debian installations.

 Therefore:


OPTION A:

   1. The Technical Committee adopts the changes proposed by Charles
  Plessy in ba679bff[1].

   2. Further modifications to the menu policy are allowed using the
  normal policy modification process.

[1]: 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


OPTION B:

   1. Considers that the policy procedure resulted in consensus, and
  adopts the changes proposed by Charles Plessy in ba67bff.[1]

   2. Further modifications to the menu policy are allowed using the
  normal policy modification process.

[1]: 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


OPTION C:

  1. The Technical Committee adopts the changes proposed by Bill
 Allombert.[1]

  2. Further modifications to the menu policy are allowed using the
 normal policy modification process.

[1]: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446


OPTION D:

   The Technical Committee has reviewed the underlying technical
   issues around this question and has resolved that Debian will be
   best served by migrating away from our own Debian Menu System and
   towards the common Freedesktop Desktop Entry Specification, and
   that menu information for applications should not be duplicated in
   two different formats.

   To encourage this change, we make menu files optional, ask that
   packages include .desktop files as appropriate and prohibit
   packages from providing both menu and .desktop files for the same
   application.

Using its power under §6.1.1 to decide on any matter of technical
policy, and its power under §6.1.5 to offer advice:

   1. The Technical Committee adopts the changes proposed by Charles
  Plessy in ba679bff[1].

   2. In addition to those changes, the Technical Committee resolves
  that packages providing a .desktop file shall not also provide a
  menu file for the same application.

   3. We further resolve that "menu programs" should not depend on the
  Debian Menu System and should instead rely on .desktop file
  contents for constructing a list of applications to present to
  the user.

   4. We advise the maintainers of the 'menu' package to update that
  package to reflect this increased focus on .desktop files by
  modifying the 'menu' package to use .desktop files for the
  source of menu information in addition to menu files.

   5. Dis

Bug#741573: CFV: Debian Menu Systems

[Sam Hartman]

>>>>> "Sam" == Sam Hartman  writes:

Sam> In preparing this CFV, I have made one change to option D: I
Sam> replaced encouage with encourage because I believe that fixes a
Sam> typo.


Sam> I'd like to call for votes on the following resolution:

On the menu system resolution, I vote:

D>B>A>Z>C

That was a tough decision.  It's unusual that we choose to adopt such a
sharp transition strategy and make one side of an interface buggy before
the other side is ready.  However, I believe that stretch will be a
better release if we don't have some programs consuming traditional menu
files and others consuming desktop files.  I believe that in this
instance if people are not willing to step up to do the work, then we'd
be better off moving forward removing traditional menu entries from
packages that also provide .desktop entries.  However, if we're wrong,
we leave debian-policy the option to adjust things and adopt a more
gradual plan should they desire.


pgpuRdYTqUTzD.pgp
Description: PGP signature

Bug#806928: krb5-kdc: Remove DES from supported_enctypes in default kdc.conf

[Sam Hartman]

I tend to agree with the change you propose.

However, note that the DES keys are harmless with allow_weak_crypto set
to false.
They won't be used.
The advantage of the current configuration is that if you discover you
need DES, you can turn it on without rekeying your realm.
That said, you don't need DES unless you're using OpenAFS, and at this
point I think it's safe to say that OpenAFS's security isn't secure.
So, I would tend to agree with your proposed change, but wanted to get
it into the bug log that I think the current configuration's only harm
is extra space in your database.

--Sam

Bug#806928: krb5-kdc: Remove DES from supported_enctypes in default kdc.conf

[Sam Hartman]

> "Benjamin" == Benjamin Kaduk  writes:

Benjamin> I'm not really sure that the Debian packaging should even
Benjamin> be in the business of setting default supported_enctypes
Benjamin> (or other things, perhaps).  Upstream seems to be doing
Benjamin> okay at it, with 3des and arcfour removed for 1.14.

If there's a reasonable default let's have a commented out entry in what
 we ship.

When I did that work, upstream's choices in this area were  quirky; as
an example there seemed to be resistance to adding rc4 by default.

Bug#792853: debian-policy: please disallow colons in upstream_version

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a
Charles> écrit :
>> * Charles Plessy , 2015-09-24, 21:53: >-
>> : ~ (full stop, plus, hyphen, colon, >+
>> : ~ (full stop, plus, hyphen,
>> 
>> Remove :, too.

Charles> Thanks for the proofreading.

Charles> With this correciton, are there people seconding the
Charles> proposed change ?


I'm totally fine with the text.
It's hard to say there's sufficient support to judge consensus with so
little discussion, but I'll second under the following rationale.

This issue has been talked about so much, and the controversial parts
are already part of a TC decision.
If there were problems with the wording I expect someone would have
jumped up by now.
So, yeah, I think I can second.


pgpaKFTj7xQth.pgp
Description: PGP signature

Bug#792853: debian-policy: please disallow colons in upstream_version

[Sam Hartman]

>>>>> "Guillem" == Guillem Jover  writes:

Guillem> Hi!
Guillem> On Mon, 2015-09-28 at 09:21:04 -0400, Sam Hartman wrote:
>> >>>>> "Charles" == Charles Plessy  writes:
>> 
Charles> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a
Charles> écrit :
>> >> * Charles Plessy , 2015-09-24, 21:53: >- >>
>> : ~ (full stop, plus, hyphen, colon, >+ >>
>> : ~ (full stop, plus, hyphen,
>> >> 
>> >> Remove :, too.
>> 
Charles> Thanks for the proofreading.
>> 
Charles> With this correciton, are there people seconding the
Charles> proposed change ?
>> 
>> 
>> I'm totally fine with the text.  It's hard to say there's
>> sufficient support to judge consensus with so little discussion,
>> but I'll second under the following rationale.
>> 
>> This issue has been talked about so much, and the controversial
>> parts are already part of a TC decision.

Guillem> Hrmmm, what TC decision? Are you perhaps mixing up issues
Guillem> here?

I sure am.
However, I've also read the upstream colons discussion and can second
that with no problems what so ever:-)

(I will not second the other issue unless someone calls for seconds.)


pgpzxLjq16rOd.pgp
Description: PGP signature

Bug#800913: nama: ChainSetup fails rendering all sound operations useless

[Sam Hartman]

Package: nama
Version: 1.078-2
Severity: grave
Justification: renders package unusable

Whenever anything tries to generate chains, which happens so you can play or 
record any sound, I get:
error caught while generating setup: Undefined subroutine called at /usr/share/p
erl5/Audio/Nama/ChainSetup.pm line 533.

That would be:
open my $fh, ">", Audio::Nama::setup_file();

So, the problem is not Audio::Nama::setup_file.  First, note that it is an 
anonymous sub not found in the error; we'd be told if Audio::Nama::setup_file 
was missing.
Also, I evaled that iand it returns the expected value.
I also decomposed line 533, stored Audio::Nama::setup_file in a temporary and 
that worked fine and the error is on the open not setting the temporary.

What seems to be happening here is that open is breaking somehow.
I ran under the perl debugger and waited until we got to line 533.

Then I ran
OPEN BAR, ">/tmp/bar"

and got the same undefined subroutine error.
So, something somewher is messing up open/file io in general.
I did some grepping and couldn't find it.
My Perl is too old to know how you can do magic this black.

--Sam





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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nama depends on:
ii  ecasound   2.9.1-4
ii  libanyevent-perl   7.070-3
ii  libdata-section-perl   0.26-1
ii  libevent-perl  1.23-1+b1
ii  libfile-copy-link-perl 0.140-1
ii  libfile-find-rule-perl 0.33-1
ii  libfile-homedir-perl   1.00-1
ii  libfile-slurp-perl .19-4
ii  libgraph-perl  1:0.96-1.1
ii  libmodern-perl-perl1.20140107-1
ii  libparse-recdescent-perl   1.967009+dfsg-1
ii  libterm-readline-gnu-perl  1.24-2+b1
ii  libtext-format-perl0.59-1
ii  libyaml-tiny-perl  1.64-1
ii  perl   5.20.2-3+deb8u1
ii  procps 2:3.3.9-8

nama recommends no packages.

Versions of packages nama suggests:
ii  libaudio-ecasound-perl  1.01-3+b1
ii  perl-tk 1:804.032-3+b3

-- no debconf information

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Sam Hartman]

> "Marvin" == Marvin Renich  writes:

Marvin> As discussed on debian-devel starting at [1], I would like a
Marvin> comment added to Section 6.4 "Best practices for maintainer
Marvin> scripts" that recommends preventing the postinst script from
Marvin> returning failure when a service fails to start.

I strongly support this practice.

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Yeah, but there's a significant factor that reduces things somewhat.
In the past, /etc/init.d/foo failing would often cause postinst to
break.
However, in the past, there were a lot of failures that were not
detected by the init.d script.
We have two intentional decisions conflicting:

1) systemd tries to be a lot better about reporting service status than
our previous infrastructure

2) We had the decision on a number of people to not hide failures by
causing installation to fail.

I actually think the folks in category 2 weren't typically hiding a lot
of service failures, because  it was fairly common for the init script
to mask that, but it did tend to hide failures like missing
configuration files etc.

I certainly know that when deploying units for krb5 I had to mask a
bunch more failures to get behavior consistent with the previous
packages.

Given the above, I think a discussion on -devel (which has happened) and
a discussion on-policy is sufficient.

--Sam

Bug#797533: New CTTE members

[Sam Hartman]

> "Josh" == Josh Triplett  writes:


Josh> Assuming that the "often results in FD" holds true, and that
Josh> this doesn't encourage snap judgements, this seems like a very
Josh> good idea to me.

I think that except in very special circumstances coming to any decision
other than FD
would be really problematic.
It's almost certain that two hours after an issue is received someone's
going to feel (and probably be) unheard if a decision is made.
Even if it's the right decision, the social costs of making it and not
giving people a chance to explain their position are likely to be really
high.

At that point, I'd see it more like overrule maintainer pending longer
discussion.

Josh> (That said, I would suggest in particular that the ctte
Josh> exercise extreme caution if the bug log does not show evidence
Josh> of a maintainer response that demonstrates an irreconcilable
Josh> situation.  The ctte should still be a *last* resort.)

I disagree here too.
Making TC binding decisions should remain a last resort.
I think we could do a much better job getting involved somewhat earlier
in some cases.
As an example, I think that involving the TC in the cross-tool-chain
mess *earlier* would have been a great idea, but involving us asking to
help the issue/enhance communication.
I think one tc member described this issue as being involved both too
early and too late at the same time, and I tend to agree.

Bug#797533: New CTTE members

[Sam Hartman]

> "josh" == josh   writes:

josh> That's not a bad plan, actually.  The three standard options
josh> could be, in effect, "preliminary injunction against the
josh> maintainer to avoid immediate harm, but we still need to talk
josh> about this more", "dismissed as completely inappropriate to
josh> have taken to the TC at all", or "we need further discussion
josh> before we can even offer an opinion".

Sure, and I'd also argue that someone on the TC should believe that an
option other than FD should win before holding a vote.
We don't need more process for process's sake.
But having something like this in place and an understanding on the TC
that if k TC members (probably k = 1) feel this is reasonable calling
for such a vote is a fine thing to do.

--Sam

Bug#803083: CVE-2015-2695 in libgssapi-krb5-2, SPNEGO context aliasing

[Sam Hartman]

Also, do you want to fix the not a DD problem?

Bug#803083: CVE-2015-2695 in libgssapi-krb5-2, SPNEGO context aliasing

[Sam Hartman]

Do I need to do anything here?
I have availability this evening and Wednesday evening.

Bug#595817: pam-ssh-agen-auth deb package

[Sam Hartman]

I have not looked at the specifics of this package.
I know that I want something that has a similar user interface for sudo.
I have no idea though whether this implementation is any good and don't
have time to investigate.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

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

Didier> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit
Didier> :
>> But _forbidding_ maintainers who want to from shipping a second
>> file, if that somehow makes the experience of menu users better
>> than what the fdo menu would have given them? Sorry, but that
>> seems petty and silly.

Didier> For context, the exact phrasing of the TC decision is
Didier> "packages providing a .desktop file shall not also provide a
Didier> menu file for the same application."

Didier> This translates to "this situation constitutes a bug", but
Didier> doesn't specify an explicit patch for the Debian Policy (aka
Didier> doesn't explicitly lay down the severity of the bug). I'd
Didier> argue that in the absence of a new Debian Policy version
Didier> incorporating the TC decision, such situations would be
Didier> 'serious' bugs. Can we work towards ironing an adequate
Didier> wording?

No, i don't think so at all.
It's quite clear from the TC minutes that serious was not intended, and
 there's no evidence that shall from the TC means the same
 thing as must in the policy.

When I read the message I feel a great frustration because I'm hoping
that we can work with respect.  It sounds like you are trying to build
up an interpretation that was never intended and create a bad
consequence for the status quo to drive resolution.
I do not support that.  I fully realize that it's easy to assume
motivations different than intended.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> So, I'm with Guillem on this one.


Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.

OK.
Then why don't you build consensus behind a patch to do that?
The TC's decision can be changed by the normal policy process.
If you can get people to agree with a proposal that permits both
.desktop and .menu files then you can replace the TC decision.

For myself, I think that forcing a transition to .desktop will create a
longer Debian long-term.  I believe that the TC's approach provides a
useful push for that in this situation.
I realize that it is a fairly forceful approach and it's not something
that Debian does often.
It seems to be a case where the broader community might disagree with
the TC and if that's the case, then I would be happy with that result.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

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

Wouter> On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote:
>> >>>>> "Wouter" == Wouter Verhelst  writes:
>> 
>> 
Wouter> So, I'm with Guillem on this one.
>> 
>> 
Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.
>> 
>> OK.  Then why don't you build consensus behind a patch to do
>> that?  The TC's decision can be changed by the normal policy
>> process.  If you can get people to agree with a proposal that
>> permits both ..desktop and .menu files then you can replace the
>> TC decision.

Wouter> Per §4.1.4, Only through a 2:1 supermajority
Wouter> GR. Alternatively, it could also by replaced by the TC
Wouter> voting a second time on the subject, changing or clarifying
Wouter> its original decision (an outcome I would favour, but hey,
Wouter> I'm not a member of the TC).

Normally that would be true.

However, the TC included the following language in its decision:

   6. Further modifications to the menu policy are allowed using the
  normal policy modification process.


My understanding is that Keith, Don and I at least intended that
language to allow the policy process to change or replace our decision.
I've run into three people now who did not find that clear.  If the
policy editors asked us to clarify that part of the decision I would
support doing so.  If the policy editors find that language clear enough
that they would feel comfortable merging a proposal that went against
the TC decision if it got enough seconds, etc, then I would find the
current language sufficient.

Bug#775277: should we split krb5-kpropd into a separate package?

[Sam Hartman]

I'm sorry.
I thought I had responded long ago on this, but apparently not.
I think the package split makes sense.

Bug#750135: Call for Vote: Resolution on Aptitude Maintainer

[Sam Hartman]

I here-by call for a vote  on the following text (option A); the other
option is FD.
I will be out much of the next two weeks so if the vote becomes
resolved I'd appreciate it if someone could step in and announce the
decision.

Background/Rationale:

1. In #750135, the Technical Committee was asked by Manuel Fernandez
   Montecelo who should be the maintainer of the Aptitude project.

   Manuel Fernandez Montecelo had been actively committing until his
   commit access was removed by Daniel Hartwig.
  
   Manuel Fernandez Montecelo and Daniel Hartwig took over development
   of Aptitude in 2011 with the support of Christian Perrier, an admin
   for the Aptitude alioth project.
  
   There was friction between Manuel Fernandez Montecelo and Daniel
   Hartwig, which eventually resulted in Manuel Fernandez Montecelo's
   commit access being revoked by Daniel Hartwig.
  
   Since then, Daniel Hartwig has become inactive, and did not comment
   on the issue when requested by the Technical Committee.

2. During the discussion of this issue, Christian Perrier proposed
   that he and Axel Beckert could watch the social aspects of Aptitude
   development and restore Manuel Fernandez Montecelo's commit access.

   Christian still has administrative rights and believes he has the
   technical power to implement his proposal, but requested the advice
   of the technical committee before doing so.

Using the power of the technical committee to provide advice (§6.1.5):

1. The Technical Committee agrees that Christian has the power to
   implement his proposal and encourages him to do so.

2. We hope that Christian and Axel will work to manage the social
   aspects of the Aptitude project, working to recruit new developers,
   building a stronger Aptitude development community, and
   establishing policies and procedures that promote a collaborative
   team.

3. We thank Manuel Fernandez Montecelo for bringing this matter to our
   attention and apologize for our delay in resolving this matter.


pgp0sKXFzeHJt.pgp
Description: PGP signature

Bug#750135: Call for Vote: Resolution on Aptitude Maintainer

[Sam Hartman]

>>>>> "Sam" == Sam Hartman  writes:

Sam> I here-by call for a vote on the following text (option A); the
Sam> other option is FD.  I will be out much of the next two weeks
Sam> so if the vote becomes resolved I'd appreciate it if someone
Sam> could step in and announce the decision.

I vote A -> FD on the vote for #750135.


pgpFXtdDXc9PM.pgp
Description: PGP signature

Bug#741573: Bug #741573:Process Approach vs Others

[Sam Hartman]

>>>>> "Don" == Don Armstrong  writes:

Don> On Wed, 27 May 2015, Sam Hartman wrote:
>> >>>>> "Bdale" == Bdale Garbee  writes:
Bdale> I hear you, I just don't have any idea what to do differently
Bdale> on this specific issue in response to knowing how you feel
Bdale> about it.
>> 
>> I made a specific proposal in #741573.  I'd be a lot happier if
>> you'd say "No, I think we've already reached agreement that the
>> policy team didn't have consensus., so we don't need to evaluate
>> whether the process was followed."

Don> I don't think we need to decide whether there was consensus or
Don> whether the process was followed. I'm also not sure whether
Don> deciding that issue would result in any actual difference in
Don> the outcome of this particular issue:

Don, my concern is that I don't have the information I need to make a
decision between option B and option C.
I have a deeper long-term concern if the TC as a whole doesn't value the
process question: I don't think I could  be part of such a TC.

To recap, In order to figure out which wayp I would vote I'd want to:

 * Evaluate whether the claimed seconds were legitimate. I can do that
   on my own.

* Contact the people seconding and confirm that as part of seconding the
  proposal  they believed there was consensus.

* Provide a period (say a couple of weeks) in which Steve, Bill and
  others either on the TC or on the policy team could raise technical
  objections to Charles proposal.

I'll point out that we've been arguing for around two months about
whether to do something that takes two weeks of time.  You have not
explained your reasoning, so I'm not able to evaluate whether the time
is afactor in your concerns.  Those on the TC who have explained why
they think what I'm proposing is a bad idea seem to be saying that they
don't want to spend the additional time to do that work.  I'm frustrated
when I think that we've spent far more time discussing whether it is
worth collecting this information than it would have taken to collect
that information.

To be clear, I don't see a huge difference in option A and B.  I do see
a huge difference in voting on option A now vs stating a process we're
going to use that respects the policy team and following that process.

So, my preference would be to delay the vote and collect the information
in the bullet points above.
If you want a vote now and want an option on the ballot, how about:

D) The TC chooses to collect input from those seconding the proposal,
from the debian-policy list and from the TC.  

If you want something that better explains what input we want to collect
from each party I'd be happy to draft that.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org