ABI changes analysis for the new releases of the Linux kernel

[Ponomarenko Andrey]

Hello,

This is a tracker of ABI changes in the new upstream releases of the Linux 
kernel (defconfig, x86_64): https://abi-laboratory.pro/tracker/timeline/linux/

The tracker performs backward binary compatibility analysis of all public 
exported symbols and data types (declared in the ".ksymtab" and  ".ksymtab_gpl" 
sections of the vmlinux binary + system calls) and lists all added/removed 
symbols.

The source code of the tool is published on github: 
https://github.com/lvc/kernel-abi-tracker

The tool can be used to analyze downstream kernels as well. See README of the 
project. It's better to use ABICC 2.0 Beta or newer to improve performance of 
the analysis.

Enjoy!

E ai, Vai Encarar?

[Pague Menos]

html {width: 100%}
body {background-color: #ff; margin: 0px; padding: 0px; font-family: Arial, 
Helvetica, sans-serif;}









Especial Corridinha Pague Menos - Caso não esteja visualizando as 
imagens, acesse aqui














 



 
Os produtos podem sofrer variação de sabores e são 
destinados aos atletas que se inscreverem no site oficial da corrida Para mais 
informações sobre a corrida, acesse http://wwwnoblucombr 
Para esclarecer dúvidas ou enviar sugestões, acesse nossa central 
de relacionamento ou escreva para falecom@supermercadospaguemenoscombr ou ligue 
para (19) 3466-8100 – ramal 1009 



  Não deseja mais receber nossas mensagens? Acesse esse link

Difference in behaviour between pbuilder and sbuild

[Scott Leggett]

Hi,

I've recently tried using sbuild rather than pbuilder (inspired by a
blog post[0]), and found that the invocation of dh_installdocs differs
between the two tools. My .docs file has this line:

  doc/mpls/

However this directory also contains a .gitignore file. sbuild's
invocation of dh_installdocs results in this command:

  cd 'doc/mpls//..' && find 'mpls' \( -type f -or -type l \) -and ! \
  -empty -print0 | LC_ALL=C sort -z | xargs -0 -I {} cp --reflink=auto \
  --parents -dp {} \
  /<>/debian/quagga-doc/usr/share/doc/quagga-doc

While pbuilder's invocation of dh_installdocs results in this command:

  cd 'doc/mpls//..' && find 'mpls' \( -type f -or -type l \) -and ! \
  -empty -and ! \( -regex .\*\\.git.\* -or -regex .\*\\.gitignore.\* \) \
  -print0 | LC_ALL=C sort -z | xargs -0 -I {} cp --reflink=auto \
  --parents -dp {} \
  /build/quagga-1.1.0/debian/quagga-doc/usr/share/doc/quagga-doc

Note that pbuilder automatically ignores VCS files.

The consequence of this difference is that for sbuild to produce a
package without the .gitignore I need this extra override:

  dh_installdocs --exclude=.gitignore

So my question is: why is there a difference, and which is "correct"?
And does this mean that if I use pbuilder, upload a package, and it is
later built from source on a buildd, it can have have lint I can't
reproduce locally?

The package versions used are git-buildpackage_0.6.22,
sbuild_0.72.0-2~bpo8+2, pbuilder_0.226.1~bpo8+1.

  [0] https://people.debian.org/~stapelberg/2016/11/25/build-tools.html

-- 
Regards,
Scott.


signature.asc
Description: Digital signature

Re: Difference in behaviour between pbuilder and sbuild

[Mattia Rizzolo]

[ disclaimer: pbuilder maintainer here - totally biased ]

On Mon, Nov 28, 2016 at 09:52:39PM +1100, Scott Leggett wrote:
> (inspired by a blog post[0]),
>   [0] https://people.debian.org/~stapelberg/2016/11/25/build-tools.html

I'll only say that 1) I fail to see where is this extrem complications
in the toolchain the author is suggesting 2) neither use of sbuild nor
pbuilder is mandatory to build packages

> I've recently tried using sbuild rather than pbuilder
> and found that the invocation of dh_installdocs differs
> between the two tools. My .docs file has this line:
> 
>   doc/mpls/
> 
> However this directory also contains a .gitignore file. sbuild's
> invocation of dh_installdocs results in this command:
> 
>   cd 'doc/mpls//..' && find 'mpls' \( -type f -or -type l \) -and ! \
>   -empty -print0 | LC_ALL=C sort -z | xargs -0 -I {} cp --reflink=auto \
>   --parents -dp {} \
>   /<>/debian/quagga-doc/usr/share/doc/quagga-doc
> 
> While pbuilder's invocation of dh_installdocs results in this command:
> 
>   cd 'doc/mpls//..' && find 'mpls' \( -type f -or -type l \) -and ! \
>   -empty -and ! \( -regex .\*\\.git.\* -or -regex .\*\\.gitignore.\* \) \
>   -print0 | LC_ALL=C sort -z | xargs -0 -I {} cp --reflink=auto \
>   --parents -dp {} \
>   /build/quagga-1.1.0/debian/quagga-doc/usr/share/doc/quagga-doc
> 
> Note that pbuilder automatically ignores VCS files.

I can very much assure you such difference has nothing to do with the
builder used.
You either have different build-deps installed that behaves differently,
or you're actually building different source packages.  Or in pbuilder
*you* (it's not done by pbuilder itself) are exporting DH_ALWAYS_EXCLUDE
from somewhere and you're not doing it in sbuild.

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

Test instance of our infrastructure

[Ian Jackson]

We are running a multitude of services.

Our usual approach to these services is that we fix things when they
break, test our client code against the live instance (with perhaps a
special area of the database - eg the `experimental' suite).  I have
found writing server-side software in this environment is awkward.  My
own service has a test suite which sets up a stunt environment, but
inevitably stunt environments in test suites are much less like the
real thing than a staging instance.

Should we not have public test instances of all these things ?

I suggest we should declare (perhaps as a DEP?) a systematic scheme
which recommends to infrastructure operators answers to the following
questions:
  - how to address the test instance of each service
  - relationships between test instances of different services
  - access control
  - availability policy
  - usual contents of a test instance
  - hosting arrangements

My starting points for answers to these questions are something like
this:

 * Most of our services are addressed via domain names,
   *.debian.org or *.debian.net.  Test instance of a service are
   correspondingly at *.infratest.debian.{org,net}.

 * Test instances should talk to the test instances of other
   services.  For example bugs.infratest.debian.org should track
   package data from ftp.infratest.debian.org.

 * Access control should be identical to the live service by default,
   but enhanced access will be available on a much more relaxed basis
   (depending on the service).  Passwords to access, and secret keys
   held by, test instances will be different.

 * Test instances should normally be up, but may be down or broken
   or something when they are being worked on.

 * Test instances will get a copy of the corresponding real instance
   copied to them on a monthly basis.  We will filter the data to make
   it more manageable, on the basis of package names and/or dates.
   Any confidential data will not be copied.

 * I don't know about hosting arrangements.  We should ask DSA's
   opinion.  I think that test instances should run on a different
   host to the live instance, so that security bugs in test instances
   are not so much of a concern.

If we wrote some of this down then infrastructure operators (like me,
wrt the dgit git server) can start to think about implement it.  I
think it will be work at first but make a lot of things easier.

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: Difference in behaviour between pbuilder and sbuild

[Johannes Schauer]

[ disclaimer: sbuild maintainer here - totally biased ]

Quoting Mattia Rizzolo (2016-11-28 12:06:19)
> On Mon, Nov 28, 2016 at 09:52:39PM +1100, Scott Leggett wrote:
> > (inspired by a blog post[0]), [0]
> > https://people.debian.org/~stapelberg/2016/11/25/build-tools.html
> I'll only say that 1) I fail to see where is this extrem complications in the
> toolchain the author is suggesting

this also escapes me. I would never claim sbuild to be less complex than
pbuilder. Of course sbuild is much more complex and thus it is much more
awesome than pbuilder.  ;)

In all seriousness - sbuild is a beast in itself. Lots of code is just to
preserve the ability to build packages independent of the Debian release
running inside the chroot. Things would be *much* easier if we could just
assume that apt 1.4 was available inside the chroot. The rest of the
complication comes from the support of multiple chroot backends - from schroot
to qemu or lxc.

My personal reason to prefer sbuild over pbuilder is just that if I find a bug
in sbuild then I know how to fix it (it's very readable Perl). Writing bash for
pbuilder is one of my greatest nightmares. :D

> 2) neither use of sbuild nor pbuilder is mandatory to build packages

In fact I like that we have two popular builders. It's much easier to find bugs
if there are multiple implementations of a mechanism that is intended to do the
same thing. As long as there are people maintaining it, I see no reason to drop
either.

> I can very much assure you such difference has nothing to do with the builder
> used.  You either have different build-deps installed that behaves
> differently, or you're actually building different source packages.  Or in
> pbuilder *you* (it's not done by pbuilder itself) are exporting
> DH_ALWAYS_EXCLUDE from somewhere and you're not doing it in sbuild.

If you really somehow export DH_ALWAYS_EXCLUDE somewhere, then the reason this
does not show up in sbuild is, that sbuild only allows certain variables from
your environment to "leak" into your build. Which variables those are is
determined by the "environment filter" which is a list of regular expressions.
Only environment variables matching at least one of these regexes are passed on
into the build. The default set of regexes does not contain a regex that
matches DH_ALWAYS_EXCLUDE. See "ENVIRONMENT_FILTER" in sbuild.conf for more
information.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Difference in behaviour between pbuilder and sbuild

[Scott Leggett]

On 2016-11-28.12:06, Mattia Rizzolo wrote:
> [ disclaimer: pbuilder maintainer here - totally biased ]
> 
> On Mon, Nov 28, 2016 at 09:52:39PM +1100, Scott Leggett wrote:
> > (inspired by a blog post[0]),
> >   [0] https://people.debian.org/~stapelberg/2016/11/25/build-tools.html
> 
> I'll only say that 1) I fail to see where is this extrem complications
> in the toolchain the author is suggesting 2) neither use of sbuild nor
> pbuilder is mandatory to build packages
> 

Hi Mattia,

No offence intended - I've used pbuilder for quite a while and was just
trying a different tool. :)

> You either have different build-deps installed that behaves differently,
> or you're actually building different source packages.  Or in pbuilder
> *you* (it's not done by pbuilder itself) are exporting DH_ALWAYS_EXCLUDE
> from somewhere and you're not doing it in sbuild.
> 

You're right, thanks for the tip. I added DH_ALWAYS_EXCLUDE to my
~/.bashrc a long time ago and forgot about it. Removing it from my
~/.bashrc produces the same behaviour in pbuilder as in sbuild.

But that means that pbuilder is carrying my local environment over to
the build environment - so the build environment is no longer pristine.
Is that behaviour intentional?

-- 
Regards,
Scott.


signature.asc
Description: Digital signature

Re: Difference in behaviour between pbuilder and sbuild

[Henrique de Moraes Holschuh]

On Mon, Nov 28, 2016, at 11:09, Johannes Schauer wrote:
> If you really somehow export DH_ALWAYS_EXCLUDE somewhere, then the reason

Then that package is subtly broken :-)

When one needs DH_ALWAYS_EXCLUDE for a build to work, that's fine: it is
there to be used...  but it has to be set and exported inside
debian/rules.

-- 
  Henrique de Moraes Holschuh 

Re: Difference in behaviour between pbuilder and sbuild

[Mattia Rizzolo]

On Mon, Nov 28, 2016 at 11:17:21PM +1100, Scott Leggett wrote:
> No offence intended - I've used pbuilder for quite a while and was just
> trying a different tool. :)

None taken :)

> But that means that pbuilder is carrying my local environment over to
> the build environment - so the build environment is no longer pristine.
> Is that behaviour intentional?

Yes it is.
I mean, it's a feature that never existed, it's not planned, and I don't
think will happen anytime soon.  I'd also argue that if you need to
clean up your environment like that either the package is fauly, or the
build host is.

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

Re: Using clean build scripts from pkg-ruby-extras repo

[Simon McVittie]

On Mon, 28 Nov 2016 at 12:57:35 +0530, Pirate Praveen wrote:
> Features:
> 1. It will build in a clean chroot using sbuild,
> 2. it will run autopkgtest in an lxc container,
> 3. it will offer to run autopkgtest of any or all reverse dependencies,
> 4. it will also offer to rebuild all or any reverse build dependencies.

Over the next few weeks I intend to try to get a release out for my
build tool Vectis (ITP: ), which does
builds in a virtual machine using a clean sbuild chroot. Its aim is to
have the equivalent of your ./setup step run in a throwaway virtual
machine (prepared using vmdebootstrap and autopkgtest-virt-qemu's setup
script), so that the entire build environment can be refreshed at any time
and without being root (you only need to be root once, to run vmdebootstrap
and get an autopkgtest VM, and even that can be avoided if you have an
out-of-band way to download a known-good VM image).

Running autopkgtests, either directly in a VM for the desired target
system or in LXC under a Debian stable VM, is also on the to-do list.

(The reason one might want to run autopkgtests under LXC even though VM
isolation is available is to make sure they will pass on ci.debian.net,
which uses LXC - one of my design principles here is to try to ensure
that anything that works in Vectis will also work on real Debian
infrastructure.)

Your recursive rebuild/test of rdeps is an interesting feature that I
hadn't thought of, and I'll look into adding that at some point.

S

Bug#846095: ITP: ruby-useragent --HTTP User Agent parser

[Abhijith PA]

Package: wnpp
Severity: wishlist
Owner: Abhijith PA 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: ruby-useragent
  Version : 0.16.8
  Upstream Author : Garry Shutler 
* URL : https://github.com/gshutler/useragent
* License : Expact
  Programming Lang: Ruby
  Description : HTTP User Agent parser


-- 
Abhijith PA abhij...@openmailbox.org
Debian Maintainer http://newbeast.ml

4096R/ED9C28EF:EF13 EA26 A698 FF35 FD7C 902E 863D 4DF2 ED9C 28EF





signature.asc
Description: OpenPGP digital signature

Re: Bits from the Stable Release Managers

[Holger Levsen]

Hi Adam,

thanks for this update!

On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote:
>* The update must be built in an (old)stable environment or chroot

afaik source only uploads work as well, dont they? (and technically the
above obviously includes this, but I think it would be nice to
explicitly mention source uploads work too.)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Difference in behaviour between pbuilder and sbuild

[Johannes Schauer]

Hi,

Quoting Mattia Rizzolo (2016-11-28 13:39:46)
> On Mon, Nov 28, 2016 at 11:17:21PM +1100, Scott Leggett wrote:
> > But that means that pbuilder is carrying my local environment over to the
> > build environment - so the build environment is no longer pristine.  Is
> > that behaviour intentional?
> Yes it is.  I mean, it's a feature that never existed, it's not planned, and
> I don't think will happen anytime soon.  I'd also argue that if you need to
> clean up your environment like that either the package is fauly, or the build
> host is.

I'd argue that the task of "clean up your environment" (build dependencies as
well as environment variables) is *exactly* what chrooted package builders like
sbuild and pbuilder should do.  After all, if it was easy to manually run
package builds in a clean environment then we wouldn't need them. Instead, we
use sbuild or pbuilder because it is tedious to repeatedly and manually:

 - run debootstrap
 - copy sources
 - chroot into the new rootfs
 - install build dependencies
 - run the package build
 - tear down the rootfs

The reason that sbuild does not drop *all* environment variables is, that it's
easier to write:

DEB_BUILD_OPTIONS=nocheck sbuild

Than to invent more command line parameters to pass common environment
variables that are intended to influence the package build.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Bits from the Stable Release Managers

[Philipp Kern]

On 2016-11-28 14:38, Holger Levsen wrote:

thanks for this update!

On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote:

   * The update must be built in an (old)stable environment or chroot


afaik source only uploads work as well, dont they? (and technically the
above obviously includes this, but I think it would be nice to
explicitly mention source uploads work too.)


Packages are only built when accepted from p-u-NEW. We require binary 
uploads to be able to review the binary debdiffs (see e.g. the binary 
debdiff links on [1]).


Kind regards
Philipp Kern

[1] https://release.debian.org/proposed-updates/stable.html

Re: Bits from the Stable Release Managers

[Julien Cristau]

On 11/28/2016 02:38 PM, Holger Levsen wrote:
> Hi Adam,
> 
> thanks for this update!
> 
> On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote:
>>* The update must be built in an (old)stable environment or chroot
> 
> afaik source only uploads work as well, dont they? (and technically the
> above obviously includes this, but I think it would be nice to
> explicitly mention source uploads work too.)
> 
> 
source only uploads work for stretch and up.  There are no arch:all
autobuilders for wheezy and jessie.

Cheers,
Julien

Re: Let's stop using CVS for debian.org website

[Ian Jackson]

Jonas Smedegaard writes ("Re: Let's stop using CVS for debian.org website"):
> Quoting Holger Levsen (2016-11-24 10:43:40)
> > $ git clone --depth 1 https://anonscm.debian.org/cgit/webwml/webwml2git.git
> > Cloning into 'webwml2git'...
> > fatal: The remote end hung up unexpectedly
> > fatal: protocol error: bad pack header

I get this too.

> Can you get these related data points too? - relevant for those with 
> limited internet bandwidth (as is the case for some translators):
> 
>   * amount of data transfered over the wire for initial full git clone

231658055 bytes ie 220 Mby, via HTTPS.  [1]
227047513 bytes ie 216 Mby, via SSH.  [1a]

>   * amount of data transfered over the wire for shallow git clone

75485138 bytes ie 71 Mby, via SSH.  [1a] with --depth 1 added

>   * amount of data transfered over the wire for CVS clone

471085959 bytes ie 449 Mby.  [2]

Note however that with CVS it is possible to clone only subtrees.
That makes a huge difference for many use cases.

For example, cvs co only webml/english/devel:

1793649 bytes ie 1.71 Mby.  [2] with cvs clone ... webwml/english/devel

>   * disk space used for CVS clone

501 Mby.

Thanks,
Ian.


[1]
  rm -rf t.* t webwml2git; strace -ffot git clone 
https://anonscm.debian.org/cgit/webwml/webwml2git.git
  grep connect t.* |less
  cat t.* |perl -ne 'next unless m/^recv\(5,/; next if m/ = -1 EAGAIN [^=]+$/; 
die "$_ ?" unless m/ = (\d+)$/; $total+=$1; END { print $total,"\n" }' 

[1a]
  rm -rf t.* t webwml2git2; strace -ffot git clone 
mariner:/volatile/iwj/d/webwml2git webwml2git2
  grep connect t.* |less
  cat t.* |perl -ne 'next unless m/^read\(3,/; next if m/ = -1 EAGAIN [^=]+$/; 
die "$_ ?" unless m/ = (\d+)$/; $total+=$1; END { print $total,"\n" }'

[2]
  rm -rf t t.* webwml; strace -ffot cvs -d cvs.debian.org:/cvs/webwml co webwml
  grep connect t.* |less
  cat t.* |perl -ne 'next unless m/^read\(3,/; next if m/ = -1 EAGAIN [^=]+$/; 
die "$_ ?" unless m/ = (\d+)$/; $total+=$1; END { print $total,"\n" }'


-- 
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: Bits from the Stable Release Managers

[Mattia Rizzolo]

On Mon, Nov 28, 2016 at 03:47:09PM +0100, Julien Cristau wrote:
> source only uploads work for stretch and up.  There are no arch:all
> autobuilders for wheezy and jessie.

Well, it doesn't even work for stretch, actually.
There are no autobuilders for stretch, and dak is rejecting such
uploads.

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

Re: Bits from the Stable Release Managers

[Holger Levsen]

On Mon, Nov 28, 2016 at 03:47:09PM +0100, Julien Cristau wrote:
> source only uploads work for stretch and up.  There are no arch:all
> autobuilders for wheezy and jessie.

ic. does that mean than arch:any only uploads work for wheezy+jessie?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bits from the Stable Release Managers

[Julien Cristau]

On 11/28/2016 05:18 PM, Mattia Rizzolo wrote:
> On Mon, Nov 28, 2016 at 03:47:09PM +0100, Julien Cristau wrote:
>> source only uploads work for stretch and up.  There are no arch:all
>> autobuilders for wheezy and jessie.
> 
> Well, it doesn't even work for stretch, actually.
> There are no autobuilders for stretch, and dak is rejecting such
> uploads.
> 
stretch isn't stable yet, as far as I know.

Cheers,
Julien

Bug#846142: ITP: casacore-data-lines -- Table of spectral lines for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-lines
  Version : 1.0
* URL : https://github.com/casacore/lines-table
* License : CC0
  Description : Table of spectral lines for casacore

 This package contains a table with the spectral line frequencies for the use
 with casacore.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-lines.git

Best regards

Ole

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

On Sat, Nov 26, 2016 at 09:35:46AM +0800, Paul Wise wrote:
> On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote:
> 
> > currently working with an ACME backwards compatibilty window of 6-12 months,
> > but probably not longer than that.
> 
> I note that letsencrypt 0.4.1-1 (before the rename to certbot) is
> available in Ubuntu xenial, which is scheduled for 5 years of support,
> terminating in 2021.
> 
> https://people.canonical.com/~ubuntu-archive/madison.cgi?package=letsencrypt+certbot
> https://wiki.ubuntu.com/Releases

Ubuntu developers have told us that they're likely to take a Xenial SRU to
Certbot 0.9.3 shortly:

https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978
 

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

On Fri, Nov 25, 2016 at 12:48:35PM +0100, Christian Seiler wrote:
 
> Note that per backports rules, $RELEASE_N-backports must track
> $RELEASE_N_PLUS_1, so if you remove certbot from Stretch, you'll
> also have to remove it from jessie-backports.

Thank you for pointing this out Christian. This policy removes what might have
been the simplest option, and seems to mean that we'll want to work hard on a 
plan
where Certbot is in Stretch in a way that works both for us upstream and for
the Debian release team.

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

On Thu, Nov 24, 2016 at 05:37:05PM +0200, Adrian Bunk wrote:
> On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> > On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
> > > So if you, as an upstream maintainer, have a change that is needed for
> > > compatibility with changes in network APIs and the change is reviewable
> > > by humans, a stable update could be possible. It's still on a
> > > case-by-case basis, so you would need to ask and the Release Team cannot
> > > approve what they do not know about.
> > 
> > There are more cases where Debian stable is getting new upstream
> > releases.
> > It's mostly to keep up with the security (MySQL, PHP),
> >...
> 
> These are long-term supported upstream stable branches.
> 
> Debian cannot just sacrifice stability by throwing the latest upstream 
> release of some random packages into stable.

That's not what we asked for; we're only interested in having a subset of our
upstream releases taken into Debian stable, and only after we know from
extensive field testing that they're not breaking anything.

We'd be willing to consider defining an upstream stable release series to
formalize this, if the Debian community views that as especially important.

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Re: Let's stop using CVS for debian.org website

[Bálint Réczey]

Hi,

2016-11-24 12:20 GMT+01:00 Jonas Smedegaard :
> Quoting Holger Levsen (2016-11-24 10:43:40)
>> As some people fear the size of the git repo, I've done a test:
>>
>> cloning took 5-6min (granted over a fast network connection) and requires
>> 628mb of diskspace in the end.
>>
>> however, cloning using --depth 1 did not work :(
>>
>> $ git clone --depth 1 https://anonscm.debian.org/cgit/webwml/webwml2git.git
>> Cloning into 'webwml2git'...
>> fatal: The remote end hung up unexpectedly
>> fatal: protocol error: bad pack header
>>
>> however if I clone locally (well using file://…) with --depth 1 I can
>> see that it needs 454mb diskspace.
>>
>> Not too bad IMO.
>
> Interesting data points.
>
> Can you get these related data points too? - relevant for those with
> limited internet bandwidth (as is the case for some translators):
>
>   * amount of data transfered over the wire for initial full git clone
>   * amount of data transfered over the wire for shallow git clone
>   * amount of data transfered over the wire for CVS clone
>   * disk space used for CVS clone

I have just learned a new trick which would help people with limited bandwidth.

It is not a subtree clone, but the result is practically the same and
the downloaded data is minimal:
$ git archive --remote=ssh://git.debian.org/git/collab-maint/ffmpeg.git
master debian/ | tar xvf -

It does not work with GitHub, but does perfectly with git.debian.org.

Cheers,
Balint

Credit: http://stackoverflow.com/a/25771130

sbuild vs pbuilder (and dgit)

[Ian Jackson]

Scott Leggett writes ("Difference in behaviour between pbuilder and sbuild"):
> I've recently tried using sbuild rather than pbuilder (inspired by a
> blog post[0]),
>
>   [0] https://people.debian.org/~stapelberg/2016/11/25/build-tools.html

I'm derailing this because I had not seen this blog post.
I took have found this a rather annoying situation.

While in theory a dgit user can build their sources for upload any way
they like, in practice it is best to let dgit have control over
building source packages for upload, for two main reasons:
 - the .gitignore anomaly
 - the need to maybe do quilt fixup or maintainer->dgitview conversion

But I don't want dgit users to have to change build too.  dgit can
currently drive sbuild very well.  dgit can also drive gbp.
Right now I am wrestling with making dgit able to drive pbuilder.

I have never really understood the point of debuild.

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: Difference in behaviour between pbuilder and sbuild

[Ian Jackson]

Scott Leggett writes ("Difference in behaviour between pbuilder and sbuild"):
> I've recently tried using sbuild rather than pbuilder (inspired by a
> blog post[0]), and found that the invocation of dh_installdocs differs
> between the two tools. My .docs file has this line:
...
> The consequence of this difference is that for sbuild to produce a
> package without the .gitignore I need this extra override:

I wonder if this is happening because pbuilder and sbuild are building
the _source package_ differently, and then re-extracting and building
the resulting source package ?

There is a historical anomaly about .gitignore in source packages.[1]


If that's not the reason, then this seems really wierd.  debhelper(7)
mentions --ignore= but I can't see how that would get onto your
dh_installdocs command line.

>   dh_installdocs --exclude=.gitignore
> 
> So my question is: why is there a difference, and which is "correct"?
> And does this mean that if I use pbuilder, upload a package, and it is
> later built from source on a buildd, it can have have lint I can't
> reproduce locally?

I think it is wrong that dh_installdocs's behaviour depends on whether
you are using pbuilder.

AFAICT from the docs, there is nothing saying a .gitignore would be
excluded.  So you should excluded it yourself.



[1] Several tools like to drop .gitignore from source packages,
especially if they have been created by the Debian maintainer.

However IMO you should ship the .gitignore in the source package.

Given the abysmal mess of git workflows and tools and competing repos
and what have you in Debian, there are several ways your source
package might be converted back into a git tree.  Someone who does
that wants your .gitignore.

Unfortunately someone somewhere decided that .gitignore was a `VCS
file' which ought not normally to be included in `3.0 (quilt)' source
packages.  In particular, often nothig generates patches for upstream
.gitignore files.


Ian.

PS: I infer that you are not using dgit.  Probably, you should be.

-- 
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: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
 
> Peter, there's one more question embedded within what you have already
> asked:
>
> - would new versions of python-certbot and python-acme require new python
> libraries? If yes (or maybe), then the answer would be: go with
> stretch-backports.  But if you can use whatever will be in next Debian
> stable, it might be feasible to negotiate with Debian release team to push
> the new upstream releases via s-p-u. (However I am not speaking for or on
> behalf of the release team.)

We believe that we can avoid having new versions of python-certbot and
python-acme depend on new version of Python libraries. In general, we've been
trying to relax our dependencies upstream, rather than adding new ones.

Over the course of five years it's possible that we'll add new features that
do use new libraries or versions of libraries, but I think we can ensure
that the features are optional and the depenencies are not strict (ie,
they're only Recommends: or Suggests: in Debian packaging terms)

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Bug#846155: ITP: python-distro -- Linux OS platform information API

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-distro
  Version : 1.0.1
  Upstream Author : Nir Cohen
* URL : https://github.com/nir0s/distro
* License : ASLv2
  Programming Lang: Python
  Description : Linux OS platform information API

distro (for: Linux Distribution) provides information about the Linux
distribution it runs on, such as a reliable machine-readable ID, or
version information.

It is a renewed alternative implementation for Python's original
platform.linux_distribution function, but it also provides much more
functionality which isn't necessarily Python bound like a command-line
interface.

This package is a new dependency for pip 9.0.1.  I will maintain this
package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlg8hjAACgkQEm61Y6dL
Br9yiQ//eIBSrjI1H4H4WDcJknCJJF8Xv1OHsKqP9Kz3MDTtSgDItl/hyOzxeebs
LNhiTQGe4rdrZsUFfPdcw4XPzSjsqBR5GYifEIIwzextaVwkyDNryKnM8ICeuV7B
XKrLeXnc6GkPq61kf79XoJLOfTAnnbhHQQHakZhTAI4JnNSpnpi98xburu+Y3YtY
eY2gVQAgfrGbwmEE3twWJh8MW0357D7LY6TnOS0mB1b09qBsNzIkDCUwsfm1zRg5
EKb39w2PUjRQVpuKWXdU96GBSMoCTMIMcOtQ9qjNlOBQ8MjWvvY1t1EKDGa/MeP1
uBPYxyZ6nxfceWf6GvL3/NIa8Gz/YdcJMJtkO1Xe3xQnP/SGOMd3PSTJ5YI4EFWR
VLiQThczYKZ8U1l6yyWpR9GmojGpgslI9Pm6X0E50dM/cLvDR0mRGvxB4FUC1ie6
LZiKiHOWQ/Ta7D2TaBpTlYr418viy+lbsfZiixkzD7RVQD9gcarz3kdmbgzb/Pcq
Uy9F6zYdt9X2vNgicE2SxpzGYcDTKqQ3nOg/Uic9Vxc4n5Hrzbz84o0Rb9CQzBGs
QBniwko/EzPTcTWGtWI/V0OyJztcbBqa5qWeZx9QjgZIsoyk7MpOUFSnP4jCvqEF
e6cERQmHnIonzDjoYfLil9siKvoDYVgtQx0t1s+kyWZnKN6fcd0=
=bPTT
-END PGP SIGNATURE-

Bug#846159: ITP: dnss -- Tool for encapsulating DNS over HTTPS or GRPC

[Alberto Bertogli (debian)]

Package: wnpp
Severity: wishlist
Owner: Alberto Bertogli (debian) 

* Package name: dnss
  Version : 0.0~git20161126.0.162090e-1
  Upstream Author : Alberto Bertogli 
* URL : https://blitiri.com.ar/git/r/dnss/
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool for encapsulating DNS over HTTPS or GRPC

dnss is a tool for encapsulating DNS over more secure protocols, like HTTPS or
GRPC.

In HTTPS mode, it can act as a DNS-over-HTTPS proxy, using
https://dns.google.com (or any other with the same API) as a server.

For GRPC, it can act as a proxy that listens to DNS requests and pass them on
to a server using GRPC, and also as a GRPC server which resolves the queries
using a normal, fixed DNS server.

Re: [debian-mysql] [MBF] mysql meta-packages

[Stefan Fritsch]

Hi Robie, hi Kristian,

On Sunday, 27 November 2016 14:11:11 CET Kristian Nielsen wrote:
> Future compatibility between MariaDB client library and MySQL server, or
> wise versa, is rather more likely than other kinds of compatibility. This is
> because there is generally a strong desire to have the client-server
> protocol be both forwards- and backwards-compatible.

thank you both for the information, this sounds quite good. I will switch to 
libmariadbclient for stretch. For stretch+1, we'll see how things develop 
upstream.

Cheers,
Stefan

Re: [debian-mysql] [MBF] mysql meta-packages

[Robie Basak]

On Mon, Nov 28, 2016 at 10:12:14PM +0100, Stefan Fritsch wrote:
> thank you both for the information, this sounds quite good. I will switch to 
> libmariadbclient for stretch. For stretch+1, we'll see how things develop 
> upstream.

Can you not use default-libmysqlclient-dev and maintain build-time
compatibility with both?


signature.asc
Description: PGP signature

Re: [debian-mysql] [MBF] mysql meta-packages

[Stefan Fritsch]

On Monday, 28 November 2016 21:37:05 CET Robie Basak wrote:
> On Mon, Nov 28, 2016 at 10:12:14PM +0100, Stefan Fritsch wrote:
> > thank you both for the information, this sounds quite good. I will switch
> > to libmariadbclient for stretch. For stretch+1, we'll see how things
> > develop upstream.
> 
> Can you not use default-libmysqlclient-dev and maintain build-time
> compatibility with both?

Yes, that's what I meant. Sorry.

Cheers,
Stefan

ITP: golang-github-akavel-rsrc -- Tool for embedding binary resources in Go programs

[liang]

Package: wnpp
Severity: wishlist
Owner: Liang Yan 

* Package name: golang-github-akavel-rsrc
  Version : 2+git20151103.6.ba14da1-1
  Upstream Author : Mateusz Czapliński
* URL : https://github.com/akavel/rsrc
* License : MIT
  Programming Lang: Go
  Description : Tool for embedding binary resources in Go programs.

 It is based on ideas presented by Minux, currently work on arch "386" and
  experimental for "amd64".

Re: sbuild vs pbuilder (and dgit)

[Sean Whitton]

Hello,

On Mon, Nov 28, 2016 at 05:39:46PM +, Ian Jackson wrote:
> I have never really understood the point of debuild.

It's just a modernising wrapper for dpkg-buildpackage, since that
the command line API of dpkg-buildpackage can't be altered.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Let's stop using CVS for debian.org website

[Sean Whitton]

Hello Bálint,

On Mon, Nov 28, 2016 at 06:33:34PM +0100, Bálint Réczey wrote:
> It is not a subtree clone, but the result is practically the same 

It wouldn't permit making new commits, though.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Let's stop using CVS for debian.org website

[Bálint Réczey]

Hi Sean,

2016-11-28 23:23 GMT+01:00 Sean Whitton :
> Hello Bálint,
>
> On Mon, Nov 28, 2016 at 06:33:34PM +0100, Bálint Réczey wrote:
>> It is not a subtree clone, but the result is practically the same
>
> It wouldn't permit making new commits, though.

This is true, those who don't have good access can't make new commits
to the remote repository by pushing changes, but they can make the
"subtree clone" a local repository and send the patches to the others
for review.

They could also push their changes by creating a full clone on
git.debian.org/home/.../
and integrating their patches created using the "subtree clone" there.

Cheers,
Balint

Re: Bits from the Stable Release Managers

[Iustin Pop]

On 2016-11-27 20:42:26, Adam D. Barratt wrote:
>* The bug should be of severity "important" or higher

Quick question: assuming all the other conditions are met (minimal patch,
clean debdiff, etc.), this seems to discourage normal bugs fixing. Is
that intentional (i.e. there must be significant breakage), or more
about "we don't want random bugs fixed"?

Just curious.

thanks,
iustin


signature.asc
Description: PGP signature

Re: Test instance of our infrastructure

[Holger Levsen]

Hi Ian,

On Mon, Nov 28, 2016 at 12:04:17PM +, Ian Jackson wrote:
> Should we not have public test instances of all these things ?

seems like a great idea, thanks for bringing this up! a few minor comments:

> I suggest we should declare (perhaps as a DEP?)

or a wiki page, at least at first…?
 
>  * Most of our services are addressed via domain names,
>*.debian.org or *.debian.net.  Test instance of a service are
>correspondingly at *.infratest.debian.{org,net}.
 
I'm not sure .debian.net should be included, probably those services
should be moved to .debian.org first?

>  I think it will be work at first but make a lot of things easier.

I agree. And even if we cannot agree (or do!) this as a project at
first, individual instances can do this now, already. eg, there *is*
http://jenkins-test-vm.debian.net:8080/ though there is none for
piuparts nor reproducible builds stuff… - patches welcome! ;-)

(and btw, jenkins.d.net is being moved slowly to .debian.org, see
https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/TODO -
help much welcome!)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#846176: ITP: restic -- restic backup program

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: "Félix Sipma" 

* Package name: restic
  Version : 0.3.0
  Upstream Author : Alexander Neumann 
* URL : https://restic.github.io/
* License : BSD
  Programming Lang: Go
  Description : restic is a backup program which allows saving multiple 
revisions of files and directories in an encrypted repository stored on 
different backends.

I think this backup program will be a nice addition to Debian. I will need a 
sponsor.


signature.asc
Description: PGP signature

Re: Bits from the Stable Release Managers

[Santiago Vila]

On Mon, Nov 28, 2016 at 03:11:17PM +0100, Philipp Kern wrote:
> On 2016-11-28 14:38, Holger Levsen wrote:
> > thanks for this update!
> > 
> > On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote:
> > >* The update must be built in an (old)stable environment or chroot
> > 
> > afaik source only uploads work as well, dont they? (and technically the
> > above obviously includes this, but I think it would be nice to
> > explicitly mention source uploads work too.)
> 
> Packages are only built when accepted from p-u-NEW. We require binary
> uploads to be able to review the binary debdiffs (see e.g. the binary
> debdiff links on [1]).

Hmm. But is that not a step backwards?

Should we all now stop making source-only uploads for stable,
like this one, because now it will not work anymore?:

https://packages.qa.debian.org/b/base-files/news/20160911T221708Z.html

Thanks.

Bug#846185: ITP: ixo-usb-jtag -- Firmware for USB JTAG programmers

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: ixo-usb-jtag
  Version : 0.0.0+git20160908
  Upstream Author : Tim 'mithro' Ansell 
* URL : https://github.com/mithro/ixo-usb-jtag
* License : GPL-2+
  Programming Lang: C
  Description : Firmware for USB JTAG programmers

This firmware allows a USB-capable microcontroller to act like an Altera
USB-Blaster JTAG pod. Which in turn may allow you to use tools you'd
normally use with the Altera USB-Blaster, including UrJTAG and openocd.

Supported hardware: The Cypress FX2 EZ-USB family, or an FTDI FT245 in
combination with a CPLD. Builds are included for the hdmi2usb project's
boards (Digilet Atlys and Numato Opsis).

Bug#846191: ITP: node-json-stable-stringify -- deterministic JSON.stringify()

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-json-stable-stringify
  Version : 1.0.1
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/json-stable-stringify
* License : Expat
  Programming Lang: JavaScript
  Description : deterministic JSON.stringify() with custom sorting
to get deterministic hashes from stringified results



signature.asc
Description: OpenPGP digital signature

Re: Test instance of our infrastructure

[Niels Thykier]

Ian Jackson:
> We are running a multitude of services.
> 
> [...]
> 
> Should we not have public test instances of all these things ?
> 
> [...]
> 
> My starting points for answers to these questions are something like
> this:
> 
>  [...]
> 
> If we wrote some of this down then infrastructure operators (like me,
> wrt the dgit git server) can start to think about implement it.  I
> think it will be work at first but make a lot of things easier.
> 
> Ian.
> 

Hi Ian,

I would love to see something like this happen.

I am happy to setup a lintian and a britney for the test infrastructure
(provided a server to do this).  For both cases, we can set them up
using the main archive as source until there is an test archive[1] (ftp
+ wanna-build).

To be honest, I suspect we can bootstrap a test instance of most
services very easily that way and then re-configure them as their
integrations get their test instance ready.


As an additional plus, we can use the test infrastructure as DSA's play
ground for testing their upgrades to the next stable release!  Can we
have all this before 5th of Feb please? ;)

Thanks,
~Niels

[1] Obviously, the test Britney should discard its results rather than
feeding them to the production instance of DAK.  But that is a rather
small part and in some glue code rather in Britney itself.