Re: Induction of new members to the technical committee

[Adam D. Barratt]

On Thursday, December 22, 2005 7:22 AM, Martin Zobel-Helas <[EMAIL PROTECTED]>
wrote:

> Hi Manoj,
>
> On Tuesday, 20 Dec 2005, you wrote:
[...]
>> So I hereby propose that this committee recommend to the
>>  the Debian project leader the following individuals to be candidates
>>  for induction into the technical committee (as per section 6.2.2 of
>>  the constitution)
[...]
> actually, i would like to know how this persons have been
> appointed/selected? Will this work like any other vote, so anyone can
> be recommented? Or does the CTTE need to assign this person by it's
> own?

As noted in Manoj's message, section 6 of the constituion covers the
Technical Committee. Section 6.2 specifies that appointments are made by the
Committee and/or DPL subject to the conditions of that section.

Cheers,

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical committee removal/induction changes

[Adam D. Barratt]

On Friday, January 06, 2006 11:09 AM, Ian Jackson
<[EMAIL PROTECTED]> wrote:

> Anthony Towns writes ("Re: Technical committee removal/induction
> changes"):
>> So should we be on the private ctte list now? How does that happen?
>
> I'm waiting for Branden to formally approve you.  Has he done so and
> his mail got lost ?

http://lists.debian.org/debian-project/2006/01/msg00013.html was CCed
to -ctte. aiui it never made it to the list as Branden isn't subscribed.

Cheers,

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#681687: missing mime entry

[Adam D. Barratt]

On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote:
> On 21.07.2012 09:11, Steve Langasek wrote:
> 
> > Now, I think providing a tool to auto-translate .desktop files into mailcap
> > entries is a perfectly appropriate way to go about solving this bug, if
[...]
> The new mime support maintainer team, which took over the package just a
> few days ago, did ask the release team, if it would be possible to still
> apply this patch for wheezy [2].
[...]
> [2] https://lists.debian.org/debian-release/2012/07/msg01048.html

As far as I can tell, that's very much not what that message says.  In
fact, it doesn't appear to request anything of the release team at all.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1342906842.13223.130.ca...@jacala.jungle.funky-badger.org

Bug#681687: missing mime entry

[Adam D. Barratt]

On Sun, 2012-07-22 at 15:24 +0200, Michael Biebl wrote:
> On 21.07.2012 23:40, Adam D. Barratt wrote:
> > On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote:
> >> On 21.07.2012 09:11, Steve Langasek wrote:
> >>
> >>> Now, I think providing a tool to auto-translate .desktop files into 
> >>> mailcap
> >>> entries is a perfectly appropriate way to go about solving this bug, if
> > [...]
> >> The new mime support maintainer team, which took over the package just a
> >> few days ago, did ask the release team, if it would be possible to still
> >> apply this patch for wheezy [2].
> > [...]
> >> [2] https://lists.debian.org/debian-release/2012/07/msg01048.html
> > 
> > As far as I can tell, that's very much not what that message says.  In
> > fact, it doesn't appear to request anything of the release team at all.
> 
> Well, Charles did not specifically ask the release team, but he CCed the
> release team

Well, he hit "reply all" on a thread that was already CCed to the
release team.  I'm not sure it would otherwise have been copied.

> and his email contains:
> 
> > 4) Postpone any other change on the main branch until either #681687 (tech.
> >comittee) is solved or Wheezy released.
> 
> This reads to me as if Charlees is waiting for a decision from the ctte.

Agreed.  It's still not even implicitly a request for release team
comment on the solution imo, but let's leave that particular horse in
peace before the discussion gets any more circular. :-/

> If Steve and other members of the ctte consider such a tool as an
> approriate way to solve this bug, would the release team also
> acknowledge this approach or not?

If it's the solution that the TC decide on to resolve the issue, it
sounds like something we could work with, at least imho, from what I've
seen so far.  I've CCed -release for any further comments, as I don't
know how many members of the team are following -ctte and/or this bug.

For clarity, the current proposal would be
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779
 , or something similar?

[...]
> From past experience we still have around 5 months until we release.
> This should be enough time to get this ready for wheezy. And as said, if
> unsurmountable problems turn up which can't be addressed within say two
> months, we can simply drop the converter again and then add back the
> evince mime file.

With my release hat on, it feels like "there's still a while until we
release" is being used more often recently as a justification for trying
to get larger scale changes incorporated or fixes delayed.  While I'm
not implying that's the intention in this case, I do think we need to be
wary of saying "there'll be plenty of time to fix that still".


Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1342968190.13223.156.ca...@jacala.jungle.funky-badger.org

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 05.02.2013 23:55, Don Armstrong wrote:

On Wed, 06 Feb 2013, Cyril Brulebois wrote:
Daniel Baumann  
(05/02/2013):

> or:
>
>   * apply the following tested and working patch from #699742 in
> debian-installer, […]

Except that this “tested and working patch” doesn't fix anything. 
Same

issue, as seen by Michael and myself.


Is it the intention of the Release Managers not to accept a newer
version of syslinux into wheezy? [That is, if the CTTE were to decide
to require some "fix" to d-i, we'd also have to override the RMs?]


Given that the syslinux packages in sid are a different major upstream
version from those in wheezy, with a raw diffstat of

 621 files changed, 36622 insertions(+), 15023 deletions(-)

and that upstream version has been in unstable for a little over a week 
in
total, I'm certainly uncomfortable that accepting the new version at 
this
point would be in the best interest of the release. We've already said 
"no" to
changes in other packages which were significantly smaller and didn't 
carry

the possibility of affecting something as key as the installer.

Shipping an installer that was built with a differing version of 
syslinux
than we eventually ship also causes me concern, since the first update 
to d-i in
a point release will obviously be rebuilt against wheezy's syslinux. 
This
introduces a situation that we can't reasonably test beforehand, as we 
could no
longer be confident that the released version of the wheezy installer 
could be

correctly booted on all of our architectures.

(tl,dr; right now, "yes, we believe the changes are too potentially 
disruptive".)


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9700fa19d26232d0f5501dc6bcb64...@mail.adsl.funky-badger.org

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 06.02.2013 14:17, Anthony Towns wrote:

On 5 February 2013 22:48, Julien Cristau  wrote:

Package: tech-ctte


- the debian-installer source package, which builds the installer 
images

  for debian's releases, build-depends on syslinux
- the release freeze for wheezy started in June 2012, and is now in 
its

  final stages
- one of the prerequisites for the release is a release candidate 
for

  the installer
- the syslinux maintainer uploaded new upstream versions of his 
package
  to unstable, which were unsuitable for wheezy, in November 2012, 
and

  again at the end of January 2013
- the latest of these uploads breaks the installer, [...]


Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?


It's a build-dependency in the (debian-installer) source package, so 
will naturally be pulled from whichever suite that package is being 
built in.


I assume it could instead be downloaded from a mirror during the build 
process, similarly to udebs, but my understanding was that we were 
trying to reduce the use of such mechanisms within the d-i build, rather 
than adding more of them.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/04032ab1f0c375283034de970b7df...@mail.adsl.funky-badger.org

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 07.02.2013 14:46, Joey Hess wrote:

Cyril Brulebois wrote:

Joey Hess  (07/02/2013):
> This can be done easily, just upload d-i to t-p-u. d-i uploads are
> already built with udebs from testing, for similar reasons.
>
> There seems to be an unholy fear of using t-p-u for anything these 
days,
> which I don't really understand. Even when not using it causes 
massive

> and unnecessary logjams in unstable during the freeze.




Yes, that's a good example of spreading FUD aboput using t-p-u, 
rather

than just using it and dealing with any breakage.


If you want to describe being concerned with dak refusing to import the 
result of a britney run due to the version constraints being broken FUD, 
sure. Note that I didn't say it was a reason not to use tpu, just a 
pre-condition in this case.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/802784afd7484f8e74647b4d60188...@mail.adsl.funky-badger.org

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 08.02.2013 03:16, Steve Langasek wrote:

On Thu, Feb 07, 2013 at 04:26:49PM +, Ian Jackson wrote:

How about this for a disposal:


I would vote for the below with reservation or modifications.  Thanks 
for

drafting this, Ian.


Is there an "out" missing in the first sentence? (If not, what 
modifications?)


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ccf0c4b44fe574520d7622c071df9...@mail.adsl.funky-badger.org

Bug#700759: Shared library policy on private libs

[Adam D. Barratt]

On 21.02.2013 16:06, Phillip Susi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/21/2013 10:32 AM, Sam Hartman wrote:

It's less of an issue for Ubuntu, but for Debian it's going to
block testing migrations of the depended package until the
depending package updates.


That could be fixed in Britney to detect this case and allow the
migration of the depended on package.


Apologies if I'm missing something here, but is that a definition of 
"fixed" that involves intentionally allowing the migration of package A 
to make package B uninstallable in testing?


Regards,

Aam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/33321527eaff155bb478dcc254bc5...@mail.adsl.funky-badger.org

Bug#700759: Shared library policy on private libs

[Adam D. Barratt]

On Thu, 2013-02-21 at 15:12 -0500, Phillip Susi wrote:
> On 2/21/2013 11:37 AM, Adam D. Barratt wrote:
> > Apologies if I'm missing something here, but is that a definition
> > of "fixed" that involves intentionally allowing the migration of
> > package A to make package B uninstallable in testing?
> 
> Exactly.  Because making package B uninstallable is much more
> acceptable than making it unrunnable.

No. Both situations are buggy and neither of them is acceptable in
testing.

[There are situations where we do knowingly introduce uninstallability
to testing, but those are always short term and to "unblock" a greater
problem such as a large transition. We'd rather never have to do so and
it certainly shouldn't be expected to be a standard part of the
transition for a particular package.]

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1361515699.12026.17.ca...@jacala.jungle.funky-badger.org

Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit

[Adam D. Barratt]

On 15.04.2013 12:49, Thomas Goirand wrote:

I would
also like to point that the tone from Ganneff isn't acceptable. From
someone who is both DSA, FTP Master and DAM


I'm sure both DSA and Joerg will be surprised to discover you've 
appointed him to the team...


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/7abdca63ef5d5213b47207bf15232...@mail.adsl.funky-badger.org

Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit

[Adam D. Barratt]

On 15.04.2013 12:49, Thomas Goirand wrote:

The following DDs have already agreed with my view on the mater:

[...]

- Mehdi Abaakouk


I may be missing something here, but Mehdi doesn't appear to be a DD 
according to db.d.o.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/65c4c3116e6266781cce8e31e6ecc...@mail.adsl.funky-badger.org

Re: Comman bugs in wheezy AMD 64bit

[Adam D. Barratt]

On Sat, 2013-06-22 at 23:27 +0530, Rupesh Reddy wrote:
> Sir I have already mentioned that package management is not good in
> debian based distributions than rpm based distributions then you have 

You were already asked - multiple times now - to post support questions
to a support list (e.g. debian-u...@lists.debian.org) rather than to the
Technical Committee list. Please take heed of that advice.

Additionally, please don't multi-post (an identical message was sent to
at least deity@).

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1371924616.19215.11.ca...@jacala.jungle.funky-badger.org

Bug#727708: Both T and L are wrong, plea for something simpler

[Adam D. Barratt]

On Fri, 2014-02-07 at 13:22 -0800, Steve Langasek wrote:
> On Fri, Feb 07, 2014 at 07:44:31PM +0100, Ansgar Burchardt wrote:
> > Steve Langasek  writes:
> > > The Policy maintainers are the maintainers of the policy document, they 
> > > are
> > > not "maintainers of the relevant software" in this context.
> 
> > No, but they are "maintainers of the relevant documentation", that is
> > the Policy. And they don't just maintain the package, see the delegation
> > text.
> 
> Assuming that by "the delegation text" you're referring to
> 
> (which is the most recent one I'm aware of), note that the set of
> responsibilities listed as being delegated does *not* include *deciding*
> technical policy.


was posted earlier today and indicates that "the Debian Policy team
defines Debian's technical framework, including the structure and
contents of the Debian archive, design issues of the operating system,
as well as technical requirements that all packages must satisfy."

(Various issues with the appropriateness of that text have already been
raised elsewhere.)

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1391811873.5649.16.ca...@jacala.jungle.funky-badger.org

Bug#744246: ftp.debian.org: update python-apt to support build-profiles

[Adam D. Barratt]

On Thu, 2014-07-17 at 20:46 +0200, Helmut Grohne wrote:
>  * SRM deemed our patches too invasive. Thread starts at:
>https://lists.debian.org/debian-dpkg/2014/04/msg00034.html

I'm confused.

The only message from anyone on the release team in that thread (i.e.
me) says, in its entirety:

"
fwiw, if you're looking for a Release Team opinion on something that's
already public, CCing me personally often isn't the best way of getting
one.

Aside from the fact that you may well (or may not, of course) get an
answer more quickly than waiting for me to work through my mail pile,
more eyes on anything affecting core packages is always a benefit.
"

Is that really the correct reference?

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405624020.21522.2.ca...@jacala.jungle.funky-badger.org

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

[Adam D. Barratt]

On Sat, 2014-11-29 at 20:40 +0100, Svante Signell wrote:
> This is another nail in the Universal OS coffin: Let's move to devuan,
> please!

You are of course free to do that. This discussion is about what Debian
should do, however. If you wish to discuss Devuan, please do so in a
more appropriate forum.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417292348.2472.4.ca...@adam-barratt.org.uk

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

[Adam D. Barratt]

On Sat, 2014-11-29 at 21:27 +0100, Svante Signell wrote:
> But it does not seem like you are realizing what is
> happening unfortunately. Debian will not be as it was historically due
> to this issue. Maybe the new DDs are to young to learn from history?

Please don't patronise people. Just because someone disagrees with you,
it doesn't mean that they're naive and unseeing and would be so much
better off if you could just lift the mist from in front of their eyes.

I'll stop contributing to the noise myself now, apologies to everyone
else.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417293389.2472.6.ca...@adam-barratt.org.uk

Re: bastardizing packages or stepping down

[Adam D. Barratt]

Hi,

Making no comment on the remainder of the mail:

On 2015-03-05 10:38, Michael Tokarev wrote:

And since I can't do my work, I'm stepping down from being
busybox maintainer, and am kindly asking the release team
to remove my name from debian/control file in busybox, so
that people don't blame me for things I can't do.


I don't believe it would be appropriate for us to do so. We have no 
control or say in who maintains packages (beyond that available to any 
other DD or interested contributor).


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/3096c5baa7a53b477a9cf7fb151e7...@mail.adsl.funky-badger.org

Re: bastardizing packages or stepping down

[Adam D. Barratt]

Hi,

Bah, so much for a quick response that I thought was simple and 
uncontroversial. :-)


On 2015-03-05 12:08, Sam Hartman wrote:

Adam, let's assume for the moment I've got that right.  I'm trying to
connect with the frustration I'd feel if I were told that I didn't even
have the power to distance myself from something I couldn't in good
conscious claim to support.
I hope that there's some way that michael can approach stepping away
from the package in jessie if he wants to.
If what you're saying is that his proposed mechanism for doing that is
the wrong one, would you be willing to help him out and suggest a
mechanism you believe to be more appropriate?


Yes, I'm specifically saying that I don't believe the Release Team has 
the authority to do what Michael is asking of us, nor do I believe we 
should do so. (Individual DDs who are part of the team can of course do 
so. Apologies if this seems like splitting hairs, but I think the 
distinction is important.)


The way I'd expect a voluntary change of maintainership to be made would 
be via an upload either by the existing maintainer, another member of 
the maintainer team (where appropriate) or the new maintainer (or I 
guess $RANDOMDD as a "QA upload with maintainer's consent" or similar).


I'm certainly not saying that Michael shouldn't be able to remove 
himself, simply that I'd feel uncomfortable with the Release Team as an 
entity doing so.



(Perhaps you'd approve an
ublock for an upload that simply changed maintainer to debian-qa?)


For the record, the Maintainer: listed in the package is debian-boot; 
Michael's in Uploaders. If it's really that much of an issue then I 
imagine they could be persuaded to remove his name from the package and 
in that case I can't see that getting it migrated under those 
circumstances would be a huge problem.



If what you're saying is that you see no mechanism for him to step away
from a package he no longer feels he can maintain because he and the
release team disagree with the desired contents of that package in
Jessie


I'm not sure the Release Team has expressed any particular opinion on 
the desired contents of the package beyond deferring to the d-i RM. I 
admit that I haven't gone back and checked through the full history of 
the unblock requests though, so I may have missed something.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/31296833bbe23bf2ae79747b8b488...@mail.adsl.funky-badger.org

Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Sat, 2015-10-31 at 00:02 +0100, Kurt Roeckx wrote:
> On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote:
> > On Tue, 20 Oct 2015, Don Armstrong wrote:
> > > If there's something specific that you'd like the CTTE to try to do
> > > beyond what I've just reported now, let me know.
> > 
> > Let me know if you'd like the CTTE to do something beyond what I've
> > already done.
> 
> I guess I would like to know what the options are.  The way I see
> it:
> - The release team makes a decision
> - The release team asks someone else to make the decision
> - Someone makes a policy of what is acceptable, not the current
>   situtation where there don't seem to be any rules.

If one of those things happened and the resulting decision was that new
OpenSSL upstream releases don't get blanket exceptions, would that be
the end of this discussion?

> - The DPL removes that power from their delegation.
>   (One can argue that the DPL didn't have the power to delegate
>that in the first place.)

I have to admit that this really doesn't fill me with confidence that
the aim is to get "a decision", rather than force a particular decision.

Regards,

Adam

Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Wed, 2015-10-21 at 15:02 -0500, Don Armstrong wrote:
> It certainly doesn't seem reasonable to expect the SRMs to review line
> by line, but maybe a summary of the changes would help them make a
> decision?
[...]
> SRMs: what would be the best way for Kurt to move forward? Would a list
> of the specific bug fixes and additional features be enough for an
> initial yes/no, given the review process upstream?

As you may have deduced, and mindful of the upcoming TC meeting, I
haven't yet found sufficient tuits to look over the scale and reach of
the changes properly. I'm hoping to have some quiet time over the
weekend that I can devote to looking in to this however.

Regards,

Adam

Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

[dropped explicit CCs to RT and TC members]

On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote:
> On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> > So from what I'm gathering, this looks like a case where there isn't
> > enough eyeballs to adequately review this particularly set of updates,
> > coupled with the importance of making sure that these updates are
> > correct and don't cause any unintended issues.
> 
> There is always the case that one persons bug is an other persons
> feature.  But those new upstream versions have been in stable and
> testing for a while now without actually breaking anything.

(I'm assuming "unstable".)

Even a naively filtered diff - excluding documentation and tests -
between the 1.0.1k tag and HEAD on upstream's stable branch is much
larger than I'd imagined (1091 files changed, 73609+, 68591-), but
paging through it there's a significant amount of "no-op" changes such
as

-   seed_len,
-   param_len;
+ seed_len, param_len;

that git diff is sadly too dumb to be able to ignore (or I'm too dumb to
be able to drive it to do so).

Do we have an approximate idea of how far divorced from upstream's
1.0.1e/k releases the corresponding packages in wheezy and jessie
currently are? 

Regards,

Adam

Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Sun, 2015-12-06 at 11:46 +0100, Moritz Mühlenhoff wrote:
> Hi,
> Personally I'm in favour of following the openssl point updates and I'd

Noted, thanks for the input.

> like to add an additional data point to the discussion:
> 
> CVE-2015-3196 was already fixed as a plain bugfix in an earlier point
> release, but the security impact was only noticed later on, so following
> the point updates would have fixed this bug five months ago.

In isolation, that's an argument for accepting new upstream versions of
most packages into stable, as there'll always be bugs for which the full
impact may not be immediately apparent.

Regards,

Adam

Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Tue, 2015-12-15 at 21:19 +0100, Kurt Roeckx wrote:
> On Tue, Dec 15, 2015 at 08:00:59PM +0000, Adam D. Barratt wrote:
> > [dropped explicit CCs to RT and TC members]
> > 
> > On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote:
> > > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> > > > So from what I'm gathering, this looks like a case where there isn't
> > > > enough eyeballs to adequately review this particularly set of updates,
> > > > coupled with the importance of making sure that these updates are
> > > > correct and don't cause any unintended issues.
> > > 
> > > There is always the case that one persons bug is an other persons
> > > feature.  But those new upstream versions have been in stable and
> > > testing for a while now without actually breaking anything.
> > 
> > (I'm assuming "unstable".)
> 
> I really meant stable.  stable has a newer version than oldstable
> from the same 1.0.1 series.

Okay.

However 1.0.1q hasn't been in stable at all, which is presumably what
you'd be proposing introducing to oldstable at this juncture. (and which
we'd therefore need to introduce to stable first, if we were to agree to
follow that path.)

Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
according to NEWS/CHANGES don't immediately look crazy.

Regards,

Adam

Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote:
> However 1.0.1q hasn't been in stable at all, which is presumably what
> you'd be proposing introducing to oldstable at this juncture. (and which
> we'd therefore need to introduce to stable first, if we were to agree to
> follow that path.)

Picking this up again (I hadn't realised the above was so many weeks
ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k
really needs a newer upstream version to be in Jessie first. We also
likely only have two opportunities to get a package in to "Wheezy
proper" before it moves to LTS status - likely a point release in March
and then a "mop up" after the EOL of the base suite.

> Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
> according to NEWS/CHANGES don't immediately look crazy.

Comparing those against the package changelog and Security Tracker and
ignoring changes which are apparently only relevant if SSLv2 is enabled
leaves us with:

  *) dhparam: generate 2048-bit parameters by default.
 [Kurt Roeckx and Emilia Kasper]

  *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
 This changes the decoding behaviour for some invalid messages,
 though the change is mostly in the more lenient direction, and
 legacy behaviour is preserved as much as possible.
 [Emilia Käsper]

  *) In DSA_generate_parameters_ex, if the provided seed is too short,
 return an error
 [Rich Salz and Ismo Puustinen ]

  *) Build fixes for the Windows and OpenVMS platforms
 [Matt Caswell and Richard Levitte]

The last of those is obviously irrelevant. Have there been any reports
of issues related to the other fixes listed?

Regards,

Adam

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

[Adam D. Barratt]

[this doesn't appear to have reached the tech-ctte list yet, so I'm 
replying from the BTS archive]


On 2017-03-09 9:41, Pirate Praveen wrote:

Package: tech-ctte

[...]

I request CTTE to declare this bug as not RC.


That's not something that the Technical Committee has a remit to do.

The determination as to whether a bug is release-critical is delegated 
to the Release Team. So far as I can tell you haven't approached them to 
discuss this, so you can't be asking the TC to override a decision by a 
delegate either, as there hasn't explicitly been one.


Regards,

Adam