Re: libc recently more aggressive about pthread locks in stable ?

[Lucas Nussbaum]

On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote:
> I fear it might be bad, but
> I would love to be pleasantly surprised that people did get libpthreads
> locking right most of the time...

I wonder if it has been considered to "fix" glibc so that the misuses
that are tolerated without TSX are also tolerated with TSX? Or is that
impossible?

Lucas

Re: call for participation - Debian contributors survey, 1st ed.

[Adrian]

unsubscribe

On 07.11.2016 09:07, Stefano Zacchiroli wrote:
> TL;DR: all Debian contributors --- from bug reporters to Debian project
> members and participants in any Debian team --- are invited to take part
> in the first edition of the Debian contributors survey. To participate
> visit:
> 
>   http://debian.limequery.org/696747
> 
> The deadline for participation is: 4 December 2016, at 23:59 UTC.
> 
> 
> 
> This is the first instance of what we hope will become a recurring
> annual survey of Debian contributors. The survey is intended to help the
> Debian project and community by enabling them to understand and document
> the evolution of the project's population over time, through the lenses
> of common demographics.
> 
> In addition, each year the survey will explore a specific aspect of the
> project. The focus for this first edition is on work and labour issues,
> specifically on the extent to which Debian contributors are volunteers
> or paid to work on Debian, and on how that affects their contributions.
> 
> Participation in the survey is completely anonymous, with no logging of
> any provenance information (e.g., IP address, HTTP referrer), and all
> questions are optional.  The survey is conducted using the Free Software
> platform LimeSurvey and hosted by LimeSurvey.org.  The results of the
> survey will be analyzed as part of ongoing research work by the
> organizers and released in aggregate form only. A report discussing the
> results will be published under a DFSG-free license and distributed to
> the Debian community as soon as it's ready. The raw, disaggregated
> answers will not be distributed and will be processed under the
> responsibility of the organizers.
> 
> The survey will remain open until: 4 December 2016, 23:59 UTC.
> 
> If you have any questions, you can always reach the survey organizers
> at:
> 
> - Mathieu ONeil (mathieu.on...@canberra.edu.au)
> - Molly de Blanc (debl...@riseup.net)
> - Stefano Zacchiroli (z...@debian.org)
> 
> We thank you in advance for your participation!
> 
> For the organizers,
> 

Re: More 5 november in the release schedule

[Emilio Pozuelo Monfort]

On 09/11/16 04:16, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
>> Right. We want auto-removals to be useful for the release process, so that we
>> don't end up with a thousand of RC bugs in testing when we freeze, most of 
>> them
>> on packages that nobody cares about, not even their maintainers.
>>
>> However, we don't want auto-removals to drop your package behind your back. 
>> If
>> that happens, that's a bad thing and you should let us know so we can fix
>> things. auto-removals should notify the maintainer in advance, and only act
>> after a reasonable period of time.
>>
>> The "packages can't re-enter testing during the freeze" is an incentive so 
>> that
>> maintainers don't wait to fix a package after a few months, and so that we 
>> don't
>> have to go and remove them manually. This way you know that something is 
>> going
>> to happen if you don't act, yet you should have a reasonable amount of time 
>> to
>> do something. Hopefully this helps have a short(er) freeze, which is good for
>> everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
> 
> I guess alioth will remain on wheezy too.

dose3 is fixed now, so that's not a problem anymore. I have no idea about the
others, but I'm happy to see that respighi is not on that list!

Emilio

Re: misleading timestamps in binnmus

[Mattia Rizzolo]

On Wed, Nov 09, 2016 at 10:04:28AM +0100, Sven Joachim wrote:
> I'm afraid I don't really have a good suggestion.  Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.

Why would that break reproducibility?  reproducible builds is about
reproducing a given build, in the case of a binNMU all the data neede
for that is registered in .buildinfo, including the date of the binNMU
and the full changelog entry of it.

Just using `date -R` is good, imho.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#843758: ITP: s4cmd -- Super Amazon S3 command line tool

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: s4cmd
  Version : 2.0.1
  Upstream Author : BloomReach Inc.
* URL : https://github.com/bloomreach/s4cmd
* License : Apache
  Programming Lang: Python
  Description : Super Amazon S3 command line tool

The s4cmd tool is intended as an alternative to s3cmd for enhanced
performance and for large files, and with a number of additional
features and fixes.

It strives to be compatible with the most common usage scenarios for
s3cmd. It does not offer exact drop-in compatibility, due to a number of
corner cases where different behavior seems preferable, or for bugfixes.

The main features that distinguish s4cmd are:

- Simple (less than 1500 lines of code) and implemented in pure Python,
  based on the widely used Boto3 library.
- Multi-threaded/multi-connection implementation for enhanced performance
  on all commands. As with many network-intensive applications (like web
  browsers), accessing S3 in a single-threaded way is often significantly
  less efficient than having multiple connections actively transferring
  data at once. In general, one gets a 2X boost to upload/download speeds 
  from this.
- Path handling: S3 is not a traditional filesystem with built-in support
  for directory structure: internally, there are only objects, not
  directories or folders. However, most people use S3 in a hierarchical
  structure, with paths separated by slashes, to emulate traditional
  filesystems. S4cmd follows conventions to more closely replicate the
  behavior of traditional filesystems in certain corner cases. For example,
  "ls" and "cp" work much like in Unix shells, to avoid odd surprises.
- Wildcard support: Wildcards, including multiple levels of wildcards, like
  in Unix shells, are handled.
  For example: s3://my-bucket/my-folder/20120512//chunk00?1?
- Automatic retry: Failure tasks will be executed again after a delay.
- Multi-part upload support for files larger than 5GB.
- Handling of MD5s properly with respect to multi-part uploads.
- Miscellaneous enhancements and bugfixes:
  - Partial file creation: Avoid creating empty target files if source does
not exist. Avoid creating partial output files when commands are 
interrupted.
  - General thread safety: Tool can be interrupted or killed at any time without
being blocked by child threads or leaving incomplete or corrupt files in 
place.
  - Ensure exit code is nonzero on all failure scenarios.
  - Expected handling of symlinks (they are followed).
  - Support both s3:// and s3n:// prefixes (the latter is common with Amazon
Elastic Mapreduce).

Re: More 5 november in the release schedule

[Simon McVittie]

On Wed, 09 Nov 2016 at 17:03:45 +1100, Brian May wrote:
> Another situation: You are not listed as the maintainer of the package
> you really care about, and the real maintainer ignores the autoremoval
> notifications. Other people looking at the package bug reports (there
> may be none) may not realize it is pending autoremoval.

I would recommend  for all your
"what is going on with this package?" needs. (I have a shortcut for it
set up in my browser, so I just type "debpts hello" into the URL bar -
the name is leftover muscle-memory from when the shortcut sent me to the
older PTS interface .)

If you particularly care about a package, subscribing to it (also available
from the tracker) will get you the same notifications that maintainers get.
I am not actually the Maintainer of record for most of my packages
(because they're team-maintained and I'm just an Uploader) so I rely on
this for normal maintenance.

S

Re: Bug#843325: ITP: waf -- Tool for configuring, building, and installing projects

[Piotr Ożarowski]

[Walter Landry, 2016-11-08]
> Doing a quick search
> 
>   curl -s 
> https://codesearch.debian.net/results/22044ee2fe5c4350/packages.json | jq -r 
> '.Packages[]' | wc -l

this result is no longer available

> 
> shows 39 packages might also benefit from a central installation of
> waf.

IMHO there are 39 packages out there that should be patched to use
something else (or at least strongly suggest upstream to use something
else and watch waf changes very carefully in each new upstream release)

> Waf has had a somewhat contentious history in Debian.  It was packaged
> and then removed upon request by upstream.

it's your time, but please feel warned

> I have had a conversation with upstream (Thomas Nagy).  Nagy still
> opposes a generic 'waf' package, but is fine with giving it a specific
> version number (e.g. waf-1.9.5).

what's the benefit of having ~39 waf-version packages (with hostile
upstream) over 39 packages that bundle waf?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: DEP14 policy for two dots

[Ian Jackson]

Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> On Tue, 08 Nov 2016, Ian Jackson wrote:
> > > The reverse rule is to convert _ and % and delete all #.
> > 
> > Quoted for completeness.
> 
> Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> a reasonable extension.

Willdo, thanks.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: misleading timestamps in binnmus

[Ian Jackson]

(CCing reproducible-builds again:)

Sven Joachim writes ("Re: misleading timestamps in binnmus"):
> I'm afraid I don't really have a good suggestion.  Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.

I don't understand why using the current date would break
reproducibility.

How does one reproduce a binnmu ?

Clearly one needs a copy of the binnmu changelog stanza, because that
(a) determines the version numbers of the generated .debs and (b) is
actually included in the generated .debs.

There is no updated .dsc in the archive, but the .deb one is trying to
reproduce contains the very changelog fragment in question.  So the
procedure has to be to combine the archive's .dsc with the .deb's
binnmu changelog stanza into a new source package.

This ought to be be reproducible regardless of what date is in the
.deb's binnmu changelog stanza.  So I think the .deb's binnmu
changelog stanza can be the date of the build (or the date of the
binnmu request, or whatever is convenient).

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: misleading timestamps in binnmus

[Guillem Jover]

Hi!

On Wed, 2016-11-09 at 11:16:09 +, Ian Jackson wrote:
> Sven Joachim writes ("Re: misleading timestamps in binnmus"):
> > I'm afraid I don't really have a good suggestion.  Using current date
> > would work but obviously break reproducibility, and any other date seems
> > arbitrary.
> 
> I don't understand why using the current date would break
> reproducibility.
> 
> How does one reproduce a binnmu ?

As Mattia replied, by taking the data from the .buildinfo file:

> Clearly one needs a copy of the binnmu changelog stanza, because that
> (a) determines the version numbers of the generated .debs and (b) is
> actually included in the generated .debs.

man deb-buildinfo, Binary-Only-Changes field. :)

Thanks,
Guillem

Bug#843772: ITP: golang-gopkg-alexcesaro-statsd.v1 -- simple and efficient Golang StatsD client

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-gopkg-alexcesaro-statsd.v1
  Version : 0.0~git20160306.0.c289775-1
  Upstream Author : Alexandre Cesaro
* URL : https://github.com/alexcesaro/statsd
* License : MIT
  Programming Lang: Go
  Description : simple and efficient Golang StatsD client

This is a simple and efficient Golang StatsD client.
 
It supports all StatsD metrics: counter, gauge, timing and set, as well
as InfluxDB and Datadog tags.

It is fast and GC-friendly: all functions for sending metrics do not
allocate. It is efficient: metrics are buffered by default. It has a
simple and clean API.

I'm packaging this as an indirect dep of goiardi, a chef server written in
Golang.

Re: What to do when a maintainer is blocking maintenance for stretch?

[Ian Jackson]

Peter Colberg writes ("What to do when a maintainer is blocking maintenance for 
stretch?"):
> Improving the package would require significant changes that are not
> appropriate for a minimal NMU. With the maintainer not responding to
> anything other than MIA requests to retain their maintainer status,
> is there any other way to get the package back in shape for stretch?

The advice from Emilio to upload your proposed big changes to
DELAYED/10 is probably good.

In theory you should ask the Technical Committee to depose the
maintainer.

But there is a similarly extreme case in front of the TC now and it
seems that the TC is (at the very least) prevaricating, while the
freeze approaches.  The TC has never wrested a package from a
maintainer who claimed to want to keep maintaining the package.

I don't know what kind of record it would take to convince the TC but
apparently "no upload in six years; new upstream versions blocked for
eight years; many contributors blocked" is not clear enough for a
swift decision.  I doubt there will be a decision at all in that case
in time for stretch.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: misleading timestamps in binnmus

[Ian Jackson]

Thanks to everyone who has provided information.  I have summarised
it in #843773, against sbuild.

What version of sbuild do buildds run ?  Ie, supposing that this is
fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
we need to update jessie, or what ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: More 5 november in the release schedule

[Marvin Renich]

* Emilio Pozuelo Monfort  [161108 16:01]:
> It is true for other removals from testing, which can happen in two different 
> ways:
> 
> - The package was removed from unstable
> - The package was hinted for testing removal by the release team
> 
> Since britney doesn't enforce (atm) that build-dependencies are satisfiable in
> testing, those two cases can cause this problem. However in the former case,
> rdeps should get a FTBFS bug so you will know about the problem, and the 
> latter
> is not very frequent.

But wouldn't the FTBFS bug be filed after the removal of the build-dep,
so that it is too late for the maintainer to assist in keeping the
build-dep in the archive?  I thought this part of the thread was about
getting notification of pending, not already happened, removals so that
help could be directed in time to keep the package in the archive.  Do I
misunderstand?

...Marvin

Re: More 5 november in the release schedule

[Ian Jackson]

Marvin Renich writes ("Re: More 5 november in the release schedule"):
> Emilio Pozuelo Monfort  [161108 16:01]:
> > It is true for other removals from testing, which can happen in two 
> > different ways:
> > 
> > - The package was removed from unstable
> > - The package was hinted for testing removal by the release team
> > 
> > Since britney doesn't enforce (atm) that build-dependencies are
> > satisfiable in testing, those two cases can cause this
> > problem. However in the former case, rdeps should get a FTBFS bug
> > so you will know about the problem, and the latter is not very
> > frequent.
> 
> But wouldn't the FTBFS bug be filed after the removal of the build-dep,
> so that it is too late for the maintainer to assist in keeping the
> build-dep in the archive?  I thought this part of the thread was about
> getting notification of pending, not already happened, removals so that
> help could be directed in time to keep the package in the archive.  Do I
> misunderstand?

We've discussed several corner cases here and it's still not quite
clear if a maintainer would always get an appropriate heads-up.

It would be helpful if the release team would confirm that if

 - a contributor is trying to keep a package in testing;

 - the contributor has paid reasonable attention to the available
   information channels (tracker.d.o, PTS subscription, BTS, say) for
   the package they care about, but these did not provide timely
   notification that the package was at risk of falling out of
   stretch;

 - the contributor fixes the underlying issue(s) expeditiously;

the Release Team would consider favourably a request for an exception
(to whatever policies stand in the way of fixing the problem in
stretch).

I think such a statement would greatly alleviate some of the concerns
we have seen here.  It would be valuable for this reason even if we
currently think that such a scenario is very unlikely in practice.

If it turns out to be a more common problem and there are many
packages affected, then this would mean delays to the stretch release,
indeed.  But it would also highlight where the real problem is - ie,
not with the maintenance of the individual packages, but with our
processes for ensuring that the right information gets to the right
people.  If this _is_ a problem for stretch then we need to improve
our processes for buster, rather than throwing stuff out of stretch.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: What to do when a maintainer is blocking maintenance for stretch?

[Holger Levsen]

On Wed, Nov 09, 2016 at 12:12:43PM +, Ian Jackson wrote:
> The advice from Emilio to upload your proposed big changes to
> DELAYED/10 is probably good.
 
agreed.

> In theory you should ask the Technical Committee to depose the
> maintainer.

I disagree here. I think the next/first step should be contacting the
MIA team and trying to resolve the situation with them. *If* that fails,
contacting the TC *might* be appropriate…
 

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#843799: ITP: dcm2niix -- next generation DICOM to NIfTI converter

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: dcm2niix
  Version : 1.0.20161101
  Upstream Author : Chris Rorden
* URL : https://github.com/rordenlab/dcm2niix
* License : BSD
  Programming Lang: C++
  Description : next generation DICOM to NIfTI converter

Long-Description:
 dcm2niix is the successor of dcm2nii, a popular tool for converting images
 from the complicated formats used by scanner manufacturers (DICOM, PAR/REC)
 to the simpler NIfTI format used by many scientific tools. It works for all
 modalities (CT, MRI, PET, SPECT) and sequence types.

This package will be co-maintained by the Debian Med Team.

Re: More 5 november in the release schedule

[gregor herrmann]

On Wed, 09 Nov 2016 14:01:13 +, Ian Jackson wrote:

> If it turns out to be a more common problem and there are many
> packages affected, then this would mean delays to the stretch release,
> indeed.  But it would also highlight where the real problem is - ie,
> not with the maintenance of the individual packages, but with our
> processes for ensuring that the right information gets to the right
> people.  If this _is_ a problem for stretch then we need to improve
> our processes for buster, rather than throwing stuff out of stretch.

I don't quite understand where all this fuzz about auto-removals
suddenly comes from. The auto-removals exist since Septemer 2013 [0]
and they were also in place for the jessie freeze [1], with the small
difference that now the point-of-no-return is a month before the hard
freeze, and in jessie it started with the hard freeze.

In my experience, auto-removals before and during the jessie freeze
were very helpful to keep the freeze shorter than previous ones.
Personally, I'm not looking back to the releases were we spent month
fixing RC bugs in packages that noone cared about; with the
auto-removals from testing, they are no blockers anymore.


Cheers,
gregor


[0] https://lists.debian.org/debian-devel-announce/2013/09/msg6.html
[1] https://release.debian.org/jessie/freeze_policy.html#autoremovals

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Claudine2


signature.asc
Description: Digital Signature

Re: What to do when a maintainer is blocking maintenance for stretch?

[Mattia Rizzolo]

On Wed, Nov 09, 2016 at 03:51:12PM +, Holger Levsen wrote:
> On Wed, Nov 09, 2016 at 12:12:43PM +, Ian Jackson wrote:
> > In theory you should ask the Technical Committee to depose the
> > maintainer.
> 
> I disagree here. I think the next/first step should be contacting the
> MIA team and trying to resolve the situation with them. *If* that fails,
> contacting the TC *might* be appropriate…


He already did, and we (I) already contacted him; the maintainer in
question promptly replied (after he ignored the bug reports Peter
submitted) saying he would quickly take care of the package in question
in a matter of days, though nothing happened.

That said we already suggested Peter to just go ahead and NMU the
package, I am not sure why he haven't do it already…


Also, a personal pledge to everybody who's reading this: please don't
attach yourself to your packages like mussels on a rock.  If you realize
(or somebody else is making you realize) that you're doing a bad job on
a package *and* there is a willing adopter, just give it up; or talk to
the prospective adopter about some kind of collaboration, or something
on that line.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#843807: ITP: golang-github-mreiferson-go-httpclient -- Go HTTP client with timeouts

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: "Dr. Tobias Quathamer" 

* Package name: golang-github-mreiferson-go-httpclient
  Version : 0.0~git20160630.0.31f0106-1
  Upstream Author : Matt Reiferson 
* URL : https://github.com/mreiferson/go-httpclient
* License : Expat
  Programming Lang: Go
  Description : Go HTTP client with timeouts

This Go package provides an HTTP Transport that implements the
RoundTripper interface and can be used as a built in replacement
for the standard library's, providing:
.
 * connection timeouts
 * request timeouts
.
This is a thin wrapper around http.Transport that sets dial
timeouts and uses Go's internal timer scheduler to call the
Go 1.1+ CancelRequest() API.




The package has already been part of stable, but has been removed in 
2015 (https://tracker.debian.org/pkg/golang-mreiferson-httpclient). The 
name was slightly different back then, I'm using the opportunity to 
rename the package according to the current Go packaging standards.


This package is a dependency of rclone (https://bugs.debian.org/822793).

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: What to do when a maintainer is blocking maintenance for stretch?

[Adrian Bunk]

On Wed, Nov 09, 2016 at 06:45:43PM +, Mattia Rizzolo wrote:
>...
> Also, a personal pledge to everybody who's reading this: please don't
> attach yourself to your packages like mussels on a rock.  If you realize
> (or somebody else is making you realize) that you're doing a bad job on
> a package *and* there is a willing adopter, just give it up; or talk to
> the prospective adopter about some kind of collaboration, or something
> on that line.

And when there is no willing adopter available, an O or RFA bug against 
wnpp is the way to find an adopter.

An orphaned package maintained by QA where everyone can just upload 
without delay is better maintained than a package with an inactive 
maintainer.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: More 5 november in the release schedule

[Adrian Bunk]

On Wed, Nov 09, 2016 at 11:16:36AM +0800, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
> > Right. We want auto-removals to be useful for the release process, so that 
> > we
> > don't end up with a thousand of RC bugs in testing when we freeze, most of 
> > them
> > on packages that nobody cares about, not even their maintainers.
> >
> > However, we don't want auto-removals to drop your package behind your back. 
> > If
> > that happens, that's a bad thing and you should let us know so we can fix
> > things. auto-removals should notify the maintainer in advance, and only act
> > after a reasonable period of time.
> >
> > The "packages can't re-enter testing during the freeze" is an incentive so 
> > that
> > maintainers don't wait to fix a package after a few months, and so that we 
> > don't
> > have to go and remove them manually. This way you know that something is 
> > going
> > to happen if you don't act, yet you should have a reasonable amount of time 
> > to
> > do something. Hopefully this helps have a short(er) freeze, which is good 
> > for
> > everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports

Is anyone tracking what packages are installed from backports on
Debian machines, and the CVEs in them?

Using backports without doing that would be irresponsible.

> as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
>...

Package removals from unstable are also a potential problem, example:

==> vogler.debian.org <==
New packages removed from Debian 'testing' (the maintainer might need help):
 - freeradius - https://tracker.debian.org/pkg/freeradius
 - freeradius-common - https://tracker.debian.org/pkg/freeradius
 - freeradius-utils - https://tracker.debian.org/pkg/freeradius
 - libfreeradius2 - https://tracker.debian.org/pkg/freeradius

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806617#22
The maintainer wanted to remove this package from *unstable*.

FreeRADIUS is popular enough that people noticed before an RM: bug was 
filed, and new maintainers were found immediately.
Other packages are not that popular.

If any packages needed on these Debian machines have been removed from 
unstable, they are not on your list.

This is the reason why a ITP/RM revolving door is creating huge 
headaches for users.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: unattended-upgrades by default?

[Adrian Bunk]

On Tue, Nov 08, 2016 at 11:16:53AM +0800, Paul Wise wrote:
> On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote:
> 
> > Forced reboot on upgrade is damage.  Let's learn from errors of others.
> 
> needrestart has a mechanism (needrestart-session) to hook into user
> sessions, perhaps that could be extended to request users reboot for
> security updates.

But that does not help here.

Steve was saying:
  that's not so useful on a remote server installation where
  there's no desktop for the system to show a pop-up or similar.
and
  We're *definitely* going to do it for cloud images

Any "solution" for the reboot problem that assumes that there is a user 
who regularly logs into the machine misses the problem.

> bye,
> pabs

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: NRSS has been deprecated [#696302]

[Adrian Bunk]

On Mon, Nov 07, 2016 at 08:58:53PM +0100, Adam Borowski wrote:
> On Sun, Oct 30, 2016 at 06:55:33PM +, Clint Adams wrote:
> > On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote:
> > > A maintainer would then file "ITR: dasher" and wait for responses before
> > > requesting RM.
> > 
> > Why wouldn't you orphan first?
> 
> It answers a different question.
> 
> Orphaning means "I don't have time to maintain this package anymore but
> believe it's worth keeping for now" (as otherwise it'd be a RM).
> 
> Intending to remove means "I don't think this package is useful at all, in
> its present state nor any state within a reasonable amount of work.  Does
> anyone disagree?".

What you are suggesting is a proper process for handling all source 
removals, instead of the current practice where the maintainer can
just submit an "RM: dasher" and a few hours later the package is gone?

> We got plenty of packages orphaned for a decade that are in a good
> condition.  

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: DEP14 policy for two dots

[Ian Jackson]

Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> a reasonable extension.

Attached.  FYI I intend to implement this in dgit.

Thanks,
Ian.

>From 5c63400e9be8cb1532515764a1179730aed550fb Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Wed, 9 Nov 2016 18:36:23 +
Subject: [PATCH] DEP-14: Version -> refname mangling: Escape dots

Signed-off-by: Ian Jackson 
---
 deps/dep14.mdwn | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/deps/dep14.mdwn b/deps/dep14.mdwn
index 4c7ce63..a7328a4 100644
--- a/deps/dep14.mdwn
+++ b/deps/dep14.mdwn
@@ -3,7 +3,7 @@
 Title: Recommended layout for Git packaging repositories
 DEP: 14
 State: DRAFT
-Date: 2014-11-04
+Date: 2016-11-09
 Drivers: Raphael Hertzog 
 URL: http://dep.debian.net/deps/dep14
 Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
@@ -60,8 +60,26 @@ Version mangling
 
 When a Git tag needs to refer to a specific version of a Debian package,
 the Debian version needs to be mangled to cope with Git's restrictions.
-The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
-(`~`) needs to be replaced with an underscore (`_`).
+This mangling is deterministic and reversible:
+
+ * Each colon (`:`) is replaced with a percent (`%`)
+ * Each tilde (`~`) is replaced with an underscore (`_`)
+ * A hash (`#`) is inserted between each pair of adjacent dots (`..`)
+ * A hash (`#`) is appended if the last character is a dot (`.`)
+ * If the version ends in precisely `.lock`
+   (dot `l` `o` `c` `k`, lowercase, at the end of the version),
+   a hash (`#`) is inserted after the dot, giving `.#lock`.
+
+This can be expressed concisely in the following Perl5 statements:
+
+ y/:~/%_/;
+ s/\.(?=\.|$|lock$)/.#/g;
+
+The reverse transformation is:
+
+ * Each percent (`%`) is replaced with a colon (`:`)
+ * Each underscore (`_`) is replaced with a tilde (`~`)
+ * Each hash (`#`) is deleted
 
 Packaging branches and tags
 ===
@@ -274,3 +292,4 @@ Changes
 ===
 
 * 2014-11-05: Initial draft by Raphaël Hertzog.
+* 2016-11-09: Extended version mangling to troublesome dots - Ian Jackson.
-- 
2.10.2



-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Sun, Nov 06, 2016 at 12:03:03AM +0100, Philipp Kern wrote:
> On 2016-11-05 22:23, Adrian Bunk wrote:
> > The solution you are trying to sell is apt-transport-https as default.
> [...]
> > Your solution would be a lot of work with relatively little improvement.
> 
> Well, the client-side exists and works.
>...

Yes and no.

It works, but there is much work left if you want to make that the 
default.

David already mentioned in this discussion where apt-transport-https 
needs improvements.

I did already mention that the current footprint of adding 
apt-transport-https to the installer and small base filesystems
is currently pretty large.
As an example, the installer would require two different TLS libraries
if you just add apt-transport-https.

I would guess there are also other areas that have to be looked at
if that should become the default, like how certificate errors will
be handled in the installer.

> > BTW: The "possible low-effort improvement without tradeoff" is:
> > 
> > Is apt-transport-tor working reliably enough for general usage?
> > Are security updates available immediately through apt-transport-tor?
> > Is there a good reason why apt-transport-tor is not mentioned
> > at the frontpage of http://www.debian.org/security/ ?
> > 
> > My current impression (that might be wrong) is that the technical side
> > would be available, only documentation and perhaps PR (e.g. email to
> > debian-security-announce) are missing.
> 
> If we are limiting ourselves to mirrors run by DSA (which is what happens
> for the backends of the onion balancer), we could have the same with an
> HTTPS-based solution just fine. It'd likely raise the same scalability and
> operational questions as HTTPS. Your proposal here simply has different
> tradeoffs, not none as you claim.

Russ and me were discussing one specific tradeoff.

Let me repeat the relevant problem:
  By discouraging users from using mirrors for security.debian.org,
  Debian is presenting a nearly complete list of all computers in
  the world running Debian stable and their security update status
  and policies on a silver plate to the NSA.

Russ answered:
  It's a tradeoff with freshness of security updates.

With HTTP this tradeoff between "not giving information about Debian 
users on a silver plate to the NSA" and "providing security updates
as soon as possible" exists.

This tradeoff still exists with HTTPS.

Tor offers a solution for this specific problem that does not have
this specific tradeoff.

> Kind regards
> Philipp Kern

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: NRSS has been deprecated [#696302]

[Adam Borowski]

On Wed, Nov 09, 2016 at 11:24:37PM +0200, Adrian Bunk wrote:
> On Mon, Nov 07, 2016 at 08:58:53PM +0100, Adam Borowski wrote:
> > On Sun, Oct 30, 2016 at 06:55:33PM +, Clint Adams wrote:
> > > On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote:
> > > > A maintainer would then file "ITR: dasher" and wait for responses before
> > > > requesting RM.
> > > 
> > > Why wouldn't you orphan first?
> > 
> > It answers a different question.
> > 
> > Orphaning means "I don't have time to maintain this package anymore but
> > believe it's worth keeping for now" (as otherwise it'd be a RM).
> > 
> > Intending to remove means "I don't think this package is useful at all, in
> > its present state nor any state within a reasonable amount of work.  Does
> > anyone disagree?".
> 
> What you are suggesting is a proper process for handling all source 
> removals, instead of the current practice where the maintainer can
> just submit an "RM: dasher" and a few hours later the package is gone?

Not all removals, merely those when the situation is not obvious.

-- 
A true bird-watcher waves his tail while doing so.

Re: DEP14 policy for two dots

[Nish Aravamudan]

On 09.11.2016 [21:27:14 +], Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> > a reasonable extension.
> 
> Attached.  FYI I intend to implement this in dgit.

Thank you! We will follow the same in the Ubuntu tooling used by the Server
Team.

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Re: What to do when a maintainer is blocking maintenance for stretch?

[Johannes Schauer]

Quoting Mattia Rizzolo (2016-11-09 16:45:43)
> Also, a personal pledge to everybody who's reading this: please don't attach
> yourself to your packages like mussels on a rock.

on that topic, I am warmly recommending Enrico Zini's "semi serious stand up
comedy notes":

Compersion, n: the feeling you get when someone else also takes good care
of one of your packages. [1]

Let us all show a bit more compersion and less exclusivity. :)

Also available as a debconf15 video recording. [2]

Thanks, Enrico! That talk was excellent stuff!

cheers, josch

[1] https://www.enricozini.org/blog/2015/debian/standup-comedy-notes/
[2] 
http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/Enricos_semi_serious_stand_up_comedy.webm


signature.asc
Description: signature

Bug#843825: ITP: golang-github-ctdk-chefcrypto -- Go cryptographic routines to interact with chef servers

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-ctdk-chefcrypto
  Version : 0.0~git20161109.0.dea96d7-1
  Upstream Author : Jeremy Bingham
* URL : https://github.com/ctdk/chefcrypto
* License : Apache-2.0
  Programming Lang: Go
  Description : Go cryptographic routines to interact with chef servers

This library includes various cryptographic routines for communicating with
chef servers for golang programs and libraries. Originally part of goiardi,
it's been split out for packaging purposes.

It is being packaged as a dependency of go-chef, in turn a dependency of
goiardi, a chef server written in Go.

Re: More 5 november in the release schedule

[Wouter Verhelst]

On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> 30 days within the deep freeze should be plenty enough - and as I
> said: if the problem is more complicated, just talk to the release
> team _while the package is still in testing_.

Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
or I get a major project at work which eats up all my time, or whatnot)
and I don't notice for a while that a package that I maintain gets an RC
bug. The automated machinery throws the package out before I have time
to work on the package again. Now what?

What if I did notice, but fixing the bug takes longer than the 15 days
(and I agree that we shouldn't release with that bug, so I agree that
the severity is correct)?

15 days is a pretty short time for irreversible changes in Debian, IMO.

If the policy for the upcoming release really is (and will remain) "once
you're out, you stay out, no exceptions", then have fun releasing Debian
without me. If the release team is willing to consider exceptions when
the automated machinery was jumping the gun a little, however, then
okay, I think it might be a good idea to try this out.

Being rigid about such policies is never a good thing, though.

> The goal of autoremovals is to provide an incentive for people
> to deal with problems in their packages _early_. My experience
> with the release team is that they are very willing to consider
> many different solutions if you talk to them early enough. They
> just don't want people coming along 4 months into the freeze and
> telling them "er, yeah, my package got removed 3 months ago, and
> I just didn't care about it until now, and during the entire
> freeze it didn't really receive much testing, but pretty please
> could it be included again?"

Well, yes, that makes sense -- but there's a major difference between "I
didn't care about my packages for 3 months" and "I didn't have time for
in-depth work for more than two weeks". The former marks an inactive
maintainer; The latter is not uncommon (at least for me).

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: DEP14 policy for two dots

[Ian Jackson]

Nish Aravamudan writes ("Re: DEP14 policy for two dots"):
> Thank you! We will follow the same in the Ubuntu tooling used by the Server
> Team.

Great, thanks.

Can I ask you a rather unrelated question ?  AIUI you are working on
importing Ubuntu's history into git.  That's great.

Can you confirm what approach you have taken to the representation of
Debian source packges as git trees ?  I would like to encourage you to
use a representation which is compatible with dgit.

That is, the git tree object should look exactly like the results of
`dpkg-source -x', except that the .pc directory which dpkg-source
creates for `3.0 (quilt)' packages is deleted.

It would probably be nice if the commit history structure of imported
source packges was a bit like the dgit imports.  Or better if it were
identical, but that's probably too much to ask for because you
probably do not want to make dgit 2.x a dependency for your project.

I encourage you to try out dgit 2.x and see what you think of its
efforts for some existing source packages.  Eg `dgit clone libvirt
stretch'.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: misleading timestamps in binnmus

[Wouter Verhelst]

On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
> Is this a recommended recipe ?  AIUI a buildd doing a binnmu will not
> modify the debian/changelog file.

Are you sure? When last I checked, this was not true (it may have
changed since, however).

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: More 5 november in the release schedule [and 1 more messages]

[Ian Jackson]

gregor herrmann writes ("Re: More 5 november in the release schedule"):
> I don't quite understand where all this fuzz about auto-removals
> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
> and they were also in place for the jessie freeze [1], with the small
> difference that now the point-of-no-return is a month before the hard
> freeze, and in jessie it started with the hard freeze.

The fuss is happening because we're in a freeze again, and because a
different group of people happen to be paying attention to these
discussions.

> In my experience, auto-removals before and during the jessie freeze
> were very helpful to keep the freeze shorter than previous ones.
> Personally, I'm not looking back to the releases were we spent month
> fixing RC bugs in packages that noone cared about; with the
> auto-removals from testing, they are no blockers anymore.

Few people (if any) in this thread has suggested that the autoremovals
are a bad idea.  Most people even seem to be in favour of the "no
return" idea.

I think what is really worrying people is the fear that they might
miss something, for good reasons, and then find that their work that
they care about is thrown out of stretch.

It is difficult to address this fear with logical arguments intended
to demonstrate that "it won't happen to a responsible maintainer",
because it is so easy to think of scenarios where, at the very least,
it's hard to be sure that the right things would happen.

On the other hand, it would be really easy for the Release Team to
address this fear.  All they have to say is that if there is a really
good excuse (maintainer seriously ill; build-dependency broken and
maintainer not notified; or whatever), they will be willing to
consider exceptions.

Wouter Verhelst writes ("Re: More 5 november in the release schedule"):
> [...]  If the release team is willing to consider exceptions when
> the automated machinery was jumping the gun a little, however, then
> okay, I think it might be a good idea to try this out.

We tried this with jessie and it worked well.

> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

If your lifestyle means that you might not notice such an RC bug
because you're on holiday for two weeks, or because of a work crisis,
then there is an overall problem: your packages might actually cause
trouble (and work) for other contributors who are trying to release.

If this happens to you, please find someone to pay attention to your
packages in the meantime.  Have them subscribe to the PTS and/or look
at your DDPO.[1]

Of course if you are hit by a bus or something then I hope the release
team would be flexible.

Thanks,
Ian.

[1] I'm volunteering, provided this is an "I'm going hiking for three
weeks in the Scottish Highlands" thing, with defined dates, not a
"please permanently add this to your todo list" thing.

If you have such work crises that you will miss RC bug emails and
autoremovals, you should work on your email filtering.  Once you know
about the bug you can ask for help, of course.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: NRSS has been deprecated [#696302]

[Ian Jackson]

Adam Borowski writes ("Re: NRSS has been deprecated [#696302]"):
> On Wed, Nov 09, 2016 at 11:24:37PM +0200, Adrian Bunk wrote:
> > What you are suggesting is a proper process for handling all source 
> > removals, instead of the current practice where the maintainer can
> > just submit an "RM: dasher" and a few hours later the package is gone?
> 
> Not all removals, merely those when the situation is not obvious.

I think this is a good idea.  We should have a concept of an ITR bug.

Of course people may disagree about what's "obvious" but there are
plenty of cases where an ITR bug would be pointless makework.  For
example, obsolete transitional source packages (of which we may have
some), or source packages whose contents have been subsumed into
another source pacakge as part of a reorganisation.

The two obvious large exception classes "we are pretty sure no-one
will mind this removal" and "this is part of a larger activity where
the maintainer has provided visbility of their intentions by other
means".

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#843827: ITP: golang-github-ctdk-go-trie -- Trie implementation based on a minimal automaton for Go

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-ctdk-go-trie
  Version : 0.0~git20161027.0.6443fbc-1
  Upstream Author : Jeremy Bingham
* URL : https://github.com/ctdk/go-trie
* License : MIT
  Programming Lang: Go
  Description : Trie implementation based on a minimal automaton for Go

 This library implements tries, also known as prefix trees, using
 minimal acyclic finite-state automata for the Go programming language.

This is a dependency of my upcoming ITP goiardi, a chef server written in Go.

Re: DEP14 policy for two dots

[Nish Aravamudan]

On 09.11.2016 [23:38:30 +], Ian Jackson wrote:
> Nish Aravamudan writes ("Re: DEP14 policy for two dots"):
> > Thank you! We will follow the same in the Ubuntu tooling used by the Server
> > Team.
> 
> Great, thanks.
> 
> Can I ask you a rather unrelated question ?  AIUI you are working on
> importing Ubuntu's history into git.  That's great.

Yep, our original use-case was 'Ubuntu merges' where there is some
Ubuntu delta from the Debian package has has to be maintained and
reapplied to new Debian publications.

> Can you confirm what approach you have taken to the representation of
> Debian source packges as git trees ?  I would like to encourage you to
> use a representation which is compatible with dgit.

I think we are fairly compatible. The only difference would be the
actual git commits themselves, I think, because we treat Launchpad as
our canonical source of information, while dgit uses the Debian archive
(aiui).

> That is, the git tree object should look exactly like the results of
> `dpkg-source -x', except that the .pc directory which dpkg-source
> creates for `3.0 (quilt)' packages is deleted.

Yes, we use `dpkg-source -x --skip-patches` on an appropriate DSC file
for both Debian and Ubuntu publications. That is the tree we commit with
appropriate parents (as determined by Launchpad's publication history
and the d/changelog file).

> It would probably be nice if the commit history structure of imported
> source packges was a bit like the dgit imports.  Or better if it were
> identical, but that's probably too much to ask for because you
> probably do not want to make dgit 2.x a dependency for your project.

I will spend some time next week looking at what dgit imports look like,
but I'm guessing they are not the same currently.

> I encourage you to try out dgit 2.x and see what you think of its
> efforts for some existing source packages.  Eg `dgit clone libvirt
> stretch'.

I will do this soon, to compare, thanks!

-Nish

P.S. Totally a plug, but I will be hosting a UOS talk about the importer
and git trees next week:
http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Re: DEP14 policy for two dots

[Ian Jackson]

Nish Aravamudan writes ("Re: DEP14 policy for two dots"):
> On 09.11.2016 [23:38:30 +], Ian Jackson wrote:
> > Can you confirm what approach you have taken to the representation of
> > Debian source packges as git trees ?  I would like to encourage you to
> > use a representation which is compatible with dgit.
> 
> I think we are fairly compatible. The only difference would be the
> actual git commits themselves, I think, because we treat Launchpad as
> our canonical source of information, while dgit uses the Debian archive
> (aiui).

dgit can work on Ubuntu too, in a readonly mode.  (It would be nice to
make `dgit push' work on Ubuntu but that requires a suitable git
server, and some configration on the dgit client side.)

> > That is, the git tree object should look exactly like the results of
> > `dpkg-source -x', except that the .pc directory which dpkg-source
> > creates for `3.0 (quilt)' packages is deleted.
> 
> Yes, we use `dpkg-source -x --skip-patches` on an appropriate DSC file
> for both Debian and Ubuntu publications. That is the tree we commit with
> appropriate parents (as determined by Launchpad's publication history
> and the d/changelog file).

The --skip-patches is a vital difference.
Has the decision to use --skip-patches been definitively taken ?

I would like to beg you to reconsider this, in the strongest possible
terms.  --skip-patches generates a patches-unapplied tree.

A patches-unapplied tree:

 * produces confusing and sometimes misleading output from
   git grep, or (even if appropriate history is available)
   with git blame;

 * cannot be used with `git cherry pick ';

 * cannot be used as a basis for `git merge upstream/';

 * requires that the user not say `git diff upstream/master'
   but rather that they read patches in debian/patches;

 * cannot be directly edited by the user;

 * leaves the git tree dirty after every build with dpkg-buildpackage
   no matter how careful or tidy the package's build system.

For these reasons, dgit's interchange format is patches-applied
trees.  (dgit 2.x supports a maintainer using patches-unapplied branch
and converts it for publication during dgit push.)

I understand why many Debian maintainers like to use patches-unapplied
trees.  They make a reasonable archival format for a maintainer who:

 - understands the `3.0 (quilt)' format very well;

 - understands their own quilt/git workflow;

 - has chosen to use (and to learn) a specific Debian git workflow
   tool such as git-buildpackage;

 - is willing to read interdiffs occasionally.

These are not properties we should expect of all our users and
downstreams.  They are not even properties we should expect of all our
future developers.

dgit (and git-dpm) show that it is possible to work with, and
interchange, patches-applied git trees.

> > It would probably be nice if the commit history structure of imported
> > source packges was a bit like the dgit imports.  Or better if it were
> > identical, but that's probably too much to ask for because you
> > probably do not want to make dgit 2.x a dependency for your project.
> 
> I will spend some time next week looking at what dgit imports look like,
> but I'm guessing they are not the same currently.

If you are making patches-unapplied trees I think you cannot possibly
be representing the quilt patch stack of a `3.0 (quilt)' source
package as a series of git commits.

Representing a `3.0 (quilt)' package that way is desirable, as it
means that `git blame' and `git log' can be used to see which patches
do what.

> > I encourage you to try out dgit 2.x and see what you think of its
> > efforts for some existing source packages.  Eg `dgit clone libvirt
> > stretch'.
> 
> I will do this soon, to compare, thanks!

The dgit_2.11_all.deb binary package in Debian unstable is very likely
to be directly installable and useable on all supported Ubuntu
versions.  So I think you can just `dpkg -i && apt-get -f install'
(or apt install ./dgit.deb, if your apt can do that).

Anyway, thanks for your consideration of my points, above.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#843830: ITP: golang-github-raintank-met -- an opinionated wrapper around metric client libraries

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-raintank-met
  Version : 0.0~git20161103.0.05a94bb-1
  Upstream Author : raintank
* URL : https://github.com/raintank/met
* License : TODO
  Programming Lang: Go
  Description : a wrapper around metric client libraries for Go

 This library provides an opinionated wrapper around metric client
 libraries for Go. It supports statsd (recommended) and dogstatsd.

This is a dependency of goiardi, a chef server written in Go that
I am packaging.

Re: DEP14 policy for two dots

[Ian Jackson]

I forgot one:

Ian Jackson writes ("Re: DEP14 policy for two dots"):
> A patches-unapplied tree:
> 
>  * produces confusing and sometimes misleading output from
>git grep, or (even if appropriate history is available)
>with git blame;
> 
>  * cannot be used with `git cherry pick ';
> 
>  * cannot be used as a basis for `git merge upstream/';
> 
>  * requires that the user not say `git diff upstream/master'
>but rather that they read patches in debian/patches;
> 
>  * cannot be directly edited by the user;
> 
>  * leaves the git tree dirty after every build with dpkg-buildpackage
>no matter how careful or tidy the package's build system.

   * when built with the upstream build system (eg, for a GNU package,
 ./configure && make), silently and successfuly produces wrong
 output - perhaps dangerously wrong output, such as binaries
 lacking important security patches.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: unattended-upgrades by default?

[Paul Wise]

On Wed, 2016-11-09 at 23:06 +0200, Adrian Bunk wrote:

> Any "solution" for the reboot problem that assumes that there is a
> user who regularly logs into the machine misses the problem.

Any solution that is the same for every device is completely wrong.

Cloud images should probably auto-reboot ASAP since they will mostly be
unattended. User desktops, laptops, phones will often have a logged-in
user who can be asked to reboot. Home routers and servers with a low
period in user activity should be auto-rebooted during the period of
low user activity. Any servers managed by config management or within
an enterprise should never be auto-rebooted and probably should not
notify anyone other than the monitoring system, via reboot-required.

So there probably needs to be a debconf prompt for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, 2016-11-09 at 22:55 +0200, Adrian Bunk wrote:

> Is anyone tracking what packages are installed from backports on
> Debian machines, and the CVEs in them?

backports is unsupported by the security team, so DSA & backports users
rely on service maintainers and backporters to do the right thing.

> Using backports without doing that would be irresponsible.

Agreed, but that is the best we have right now.

> Package removals from unstable are also a potential problem, example:

Agreed.

> The maintainer wanted to remove this package from *unstable*.

Thanks for pointing this out.

> FreeRADIUS is popular enough that people noticed before an RM: bug was 
> filed, and new maintainers were found immediately.

Looks like that wasn't enough since it didn't reach unstable yet.

> Other packages are not that popular.

Even the unpopular packages have users or potential users, we need to
develop better chains of communication with those users & communities.

> If any packages needed on these Debian machines have been removed from 
> unstable, they are not on your list.

Correct:

https://bugs.debian.org/838363
  
> This is the reason why a ITP/RM revolving door is creating huge 
> headaches for users.

Agreed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: misleading timestamps in binnmus

[Cyril Brulebois]

Ian Jackson  (2016-11-09):
> What version of sbuild do buildds run ?  Ie, supposing that this is
> fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> we need to update jessie, or what ?

sbuild on buildds uses a specific version of sbuild, for reasons I'm not
going to summarize. The base version is close to what's in jessie (see the
first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).

dsa-puppet.git has:
,---[ modules/debian-org/files/apt.preferences ]---
| …
| Package: sbuild
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
| 
| Package: buildd
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
| 
| Package: libsbuild-perl
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
`---

Repository seems to live under:
  https://apt.buildd.debian.org/


KiBi.


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[James McCoy]

On Thu, Nov 10, 2016 at 12:24:20AM +0100, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> > 30 days within the deep freeze should be plenty enough - and as I
> > said: if the problem is more complicated, just talk to the release
> > team _while the package is still in testing_.
> 
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

If I understand correctly, activity on the bug resets the counter, so
you could ping it to say that you're busy right now but will look at it
in a few days or some such.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Bug#843325: ITP: waf -- Tool for configuring, building, and installing projects

[Walter Landry]

Piotr Ożarowski  wrote:
> [Walter Landry, 2016-11-08]
>> Doing a quick search
>> 
>>   curl -s 
>> https://codesearch.debian.net/results/22044ee2fe5c4350/packages.json | jq -r 
>> '.Packages[]' | wc -l
> 
> this result is no longer available

Oh bother.  I did a slightly more sophisticated search and got 36 results

  ardour, aster, aubio, audacity, avw.lv2, diodon, flowcanvas, fomp,
  fonts-sil-padauk, ganv, gmidimonitor, jackd2, jalv, kupfer, libcsp,
  lilv, lv2, lv2core, lvtk, lysdr, mda-lv2, mpv, ns3, patchage,
  pd-aubio, pugl, py3cairo, raul, serd, sord, sprai, sratom, suil,
  sushi, xmds2, xmms2
  
I searched for 'waflib/Tools' on codesearch.debian.org.

>> shows 39 packages might also benefit from a central installation of
>> waf.
> 
> IMHO there are 39 packages out there that should be patched to use
> something else (or at least strongly suggest upstream to use something
> else and watch waf changes very carefully in each new upstream release)
> 
>> Waf has had a somewhat contentious history in Debian.  It was packaged
>> and then removed upon request by upstream.
> 
> it's your time, but please feel warned
>
>> I have had a conversation with upstream (Thomas Nagy).  Nagy still
>> opposes a generic 'waf' package, but is fine with giving it a specific
>> version number (e.g. waf-1.9.5).
> 
> what's the benefit of having ~39 waf-version packages (with hostile
> upstream)

Part of the reason for this discussion is so that upstream will not be
so hostile.  Nagy was also fine if we used a different name.  Then it
would be something like firefox and iceweasel.  That is not ideal, but
it is not without precedent.

> over 39 packages that bundle waf?

There would be one waf package.  Packagers would have the option of
using the waf package.  They might prefer that over the UnpackWaf
option.  I certainly would.  The differences between the waf versions
are not so large, especially for minor versions.

Cheers,
Walter Landry

Re: More 5 november in the release schedule [and 1 more messages]

[Christoph Biedl]

Ian Jackson wrote...

> I think what is really worrying people is the fear that they might
> miss something, for good reasons, and then find that their work that
> they care about is thrown out of stretch.
>
> It is difficult to address this fear with logical arguments intended
> to demonstrate that "it won't happen to a responsible maintainer",
> because it is so easy to think of scenarios where, at the very least,
> it's hard to be sure that the right things would happen.

For me it's a bit different. If John S.(lacker) Maintainer ignored the
messages about debhelper compat 4 removal for ten and about the
openssl 1.1 transition for seven months, and in January suddenly finds
his packages got kicked out and cannot return for stretch - he had it
coming.

If however Jane R.(esponsible) Maintainer did everything right but did
not realize somebody else's non-action affects her packages as well,
through a build dependency or whatever ... until the "Your package was
removed from testing" e-mail arrives: That's quite a nuisance.

So if I, in Jane's position, could be certain I'll learn about a
pending removal that affects my packages early enough I can avoid this
(by kicking the maintainer or NMU), my concerns were neglectable. A
grace period of just a few days was sufficient. This mechanism is
implemented for install dependencies, but after reading this thread
I'm not sure it exists for other scenarios as well. 

> On the other hand, it would be really easy for the Release Team to
> address this fear.  All they have to say is that if there is a really
> good excuse (maintainer seriously ill; build-dependency broken and
> maintainer not notified; or whatever), they will be willing to
> consider exceptions.

I guess the Release Team plays tough in the first place so people do
their job *now* instead of asking for exceptions later. I'd call that
wise tactics. The e-thing still might happen if there's really, really
good reason. But creating false hope sends the wrong signal. 

Finally, there's a thing called "trust": I trust the Release Team does
this solely in order to keep the freeze time as short as possible,
everybody hates that time anyway. This trust was created by the very
people behind it, and the way they acted in the past months.

Christoph


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[Niels Thykier]

Wouter Verhelst:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
> 
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?
> 
> What if I did notice, but fixing the bug takes longer than the 15 days
> (and I agree that we shouldn't release with that bug, so I agree that
> the severity is correct)?
> 

I appreciate that you are concerned.  However, I think most people and
their packages go through the freeze just fine.

 * As James noted; sending an update to the bug will reset the timer.
   (Update early, update often - last minute pings might not make it in
time)

 * Also, if you do not have time for a given bug, please consider
   tagging it "help", so your fellow contributors know that you need
   help.  That tag shows up on all RC bugs views I know of.

 * For more extreme cases (death, mowed by bus, sudden long term
   illness, etc), the replacement maintainer can ask for an exception.
   (per [freeze policy])


Thanks,
~Niels



[freeze policy]:

"""
The release managers may make exceptions to these guidelines as they see
fit. *Such exceptions are not precedents and you should not assume that
your package has a similar exception*. Please talk to us if you need
guidance.
"""
(Emphasis from original - 3rd paragraph from the top)

https://release.debian.org/stretch/freeze_policy.html

Re: More 5 november in the release schedule

[Ole Streicher]

Wouter Verhelst  writes:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
>
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

This is a good argument for team maintenance. :-)

Cheers

Ole