Re: dpkg-source unpack failures

2014-07-06 Thread Guillem Jover 
Hi!

On Sat, 2014-07-05 at 22:19:28 +0200, David Suárez wrote:
> El Lunes, 30 de junio de 2014 19:10:03 David Suárez escribió:
> > El Lunes, 30 de junio de 2014 04:29:43 Guillem Jover escribió:
> > > David, would it be possible to do a simple dpkg-source unpack run over
> > > the stable archive, with the security update (dpkg 1.16.15), to check
> > > if there's any regressions there?
> > 
> > Not problem, just give me some time :)
> 
> Here goes.
> 
> Failures:
> 
>   lldpad_0.9.44-1
>   foremost_1.5.7-4
>   dwm_6.0-4
>   usbredir_0.4.3-2
>   katoob_0.5.9.1-3
>   herculesstudio_1.3.0-2
>   kvpm_0.8.6-2+deb7u1
>   getfem++_4.1.1+dfsg1-11
> 
> Logs at 

Great! David, thanks for doing that.

For the release-team, I've filed or updated now bug reports for these
issues affecting stable:

  dwm_6.0-4 #722994
  foremost_1.5.7-4  #753184
  getfem++_4.1.1+dfsg1-11   #753921
  herculesstudio_1.3.0-2#753922
  katoob_0.5.9.1-3  #753219
  kvpm_0.8.6-2+deb7u1   #753175
  lldpad_0.9.44-1   #753235
  usbredir_0.4.3-2  #753927

Would you in principle allow uploads for all these (the provided patches
just fix the patch headers), I could send them attached if you want? Or
I guess you might want to handle each one separately anyway? As I've
mentioned in the bug reports I'm prepared to help handle the uploads if
needed, sponsoring or similar (for example the foremost one), given that
the “regression” was introduced with a dpkg upload.

(For a bit more, unnecessary, context the thread starts at
.)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140706170148.gb30...@gaara.hadrons.org

Re: dpkg-source unpack failures

2014-07-06 Thread Adam D. Barratt 
On Sun, 2014-07-06 at 19:01 +0200, Guillem Jover wrote:
> On Sat, 2014-07-05 at 22:19:28 +0200, David Suárez wrote:
> > El Lunes, 30 de junio de 2014 19:10:03 David Suárez escribió:
> > > El Lunes, 30 de junio de 2014 04:29:43 Guillem Jover escribió:
> > > > David, would it be possible to do a simple dpkg-source unpack run over
> > > > the stable archive, with the security update (dpkg 1.16.15), to check
> > > > if there's any regressions there?
[...]
> For the release-team, I've filed or updated now bug reports for these
> issues affecting stable:
[...]
> Would you in principle allow uploads for all these (the provided patches
> just fix the patch headers),

In principle that sounds okay, yes. (Although now rather too late for
7.6.)

> I could send them attached if you want? Or
> I guess you might want to handle each one separately anyway?

Yes, separate bug reports would be preferable; it's far easier to keep
track of that way.

If the version of the packages in unstable are also affected, those
should be resolved beforehand.

Regards,

Adam


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

Re: backport of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles

2014-07-06 Thread Johannes Schauer 
Hi,

Quoting Alexander Wirt (2014-04-26 20:36:29)
> > We would like to add build profile support [1] to packages in the archive
> > and because build profiles add a new syntax to Build-Depends, tools like
> > dpkg and apt need to be able to understand it as they would otherwise throw
> > an error.  Support for build profiles was integrated into a number of tools
> > already and most of them already migrated into testing. You can see [1] for
> > an overview.
> >
> > Because of this syntax change, packages that use this syntax can only be
> > uploaded once tools in Debian stable support it because the build
> > infrastructure runs Debian stable. One option would be to wait until the 
> > jessie
> > release but we fear that if we go that route we might discover too late 
> > that we
> > missed to patch one important tool and in the worst case have to wait for 
> > yet
> > another release until packages with build profiles can be uploaded.
> >
> > I'm writing to this list because a backport is probably more easy than 
> > plugging
> > the build-profile commit on top of the current stable versions of dpkg and 
> > apt?
> >
> > What do you think? Would you support releasing a build profile enabled 
> > version
> > of dpkg and apt and python-apt into backports so that dak and wanna-build 
> > can
> > support build profiles before jessie happens?
> It is and was always backports policy to prevent backporting packages which
> do have too much impact on the stable system. And to be honest, apt do fall
> into that category. Unless someone has some really really good reasons I
> won't accept apt into backports.

Please reconsider adding packages with the attached three minimal patches for
dpkg, apt and python-apt to backports. In contrast to a full backport these
patches add the ability to parse the new build profile syntax with minimal
impact.  In particular no code for using build profiles is added. We already
tried to update the build infrastructure via other means (stable update, custom
repositories, local installation), but were faced with resistance from the
relevant teams (SRM, DSA, FTP). Each of them has good reasons. We believe that
backports is a good way to enable the build profile syntax on Debian build
infrastructure.

cheers, josch and Helmut
diff -Nru dpkg-1.16.12/debian/changelog dpkg-1.16.12~bpo70+1/debian/changelog
--- dpkg-1.16.12/debian/changelog	2013-09-30 16:52:48.0 +0200
+++ dpkg-1.16.12~bpo70+1/debian/changelog	2014-07-06 10:35:00.0 +0200
@@ -1,3 +1,19 @@
+dpkg (1.16.12~bpo70+1) wheezy-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Minimal support for restriction list Build-Depends syntax extension
+  - the syntax is described at https://wiki.debian.org/BuildProfileSpec
+  - dpkg will correctly parse and interpret build profile annotations
+in build dependencies of source packages
+  - it will not allow to set any build profiles and will always assume
+that no build profile is set
+  - this allows dpkg to not throw an error when encountering source packages
+that make use of build profiles in stable versions of Debian with dpkg
+version 1.17.2 or later in which full support for build profiles
+was implemented
+
+ -- Johannes Schauer   Wed, 30 Apr 2014 09:00:31 +0200
+
 dpkg (1.16.12) stable; urgency=low
 
   * Fix value caching in Dpkg::Arch by not shadowing the variables.
diff -Nru dpkg-1.16.12/man/deb-src-control.5 dpkg-1.16.12~bpo70+1/man/deb-src-control.5
--- dpkg-1.16.12/man/deb-src-control.5	2013-09-30 16:47:56.0 +0200
+++ dpkg-1.16.12~bpo70+1/man/deb-src-control.5	2014-07-06 10:18:59.0 +0200
@@ -177,8 +177,9 @@
 of packages separated by vertical bar (or "pipe") symbols, "|". The
 groups are separated by commas. Commas are to be read as "AND", and pipes
 as "OR", with pipes binding more tightly. Each package name is
-optionally followed by a version number specification in parentheses and an
-architecture specification in square brackets.
+optionally followed by a version number specification in parentheses, an
+architecture specification in square brackets, and a profile specification
+in angle brackets.
 
 The syntax of the
 .BR Build\-Conflicts ,
@@ -188,7 +189,8 @@
 fields is a list of comma-separated package names, where the comma is read
 as an "AND". Specifying alternative packages using a "pipe" is not supported.
 Each package name is optionally followed by a version number specification in
-parentheses and an architecture specification in square brackets.
+parentheses, an architecture specification in square brackets, and a profile
+specification in angle brackets.
 
 A version number may start with a ">>", in which case any later version
 will match, and may specify or omit the Debian packaging revision (separated
@@ -200,6 +202,10 @@
 separated by whitespace. Exclamation marks may be prepended to each of the
 names, meaning "NOT".
 
+A profile specification consists of one or m