Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 08:17:22PM +0200, Ralf Treinen wrote: > well, the source-only upload to jessie-backports was rejected, claiming > that architecture-independent packages have to be included. Great surprise, > that wasn't the case before. source only uploads (without arch:all binaries) to anything != (unstable, sid, experimental) have never been a thing. > I am leaving for vacation tomorrow and don't have > access to a jessie chroot now, so I cannot fix this now. If you want 5.0-3 > in backports please pick it up at > > https://anonscm.debian.org/git/pkg-ocaml-maint/packages/dose3.git > branch jessie-backports/master I'll build and upload it! Thanks :) -- 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: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 05:18:43PM +, Mattia Rizzolo wrote: > On Thu, Jul 21, 2016 at 07:17:03PM +0200, Ralf Treinen wrote: > > Fixed package is in sid (5.0-3) since Fri, 15 Jul, should migrate to > > testing soon. I just uploaded to jessie-backports. > > It migrated to testing this morning. well, the source-only upload to jessie-backports was rejected, claiming that architecture-independent packages have to be included. Great surprise, that wasn't the case before. I am leaving for vacation tomorrow and don't have access to a jessie chroot now, so I cannot fix this now. If you want 5.0-3 in backports please pick it up at https://anonscm.debian.org/git/pkg-ocaml-maint/packages/dose3.git branch jessie-backports/master -Ralf.
Bug#828966: marked as done (transition: ros-ros-comm)
Your message dated Thu, 21 Jul 2016 19:17:27 +0200 with message-id and subject line Re: Bug#828966: transition: ros-ros-comm has caused the Debian Bug report #828966, regarding transition: ros-ros-comm to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 828966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828966 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I'm filing this bug for a transition of ros-ros-comm . It is in experimental. It builds on all architectures in testing, where it built previously. Ben file: title = "ros-ros-comm"; is_affected = .depends ~ /\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d|libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/ is_good = .depends ~ /\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d)\b/ is_bad = .depends ~ /\b(libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/ All reverse dependencies test rebuilds. All rdepends are listed here: https://release.debian.org/transitions/html/auto-ros-ros-comm.html -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 08/07/16 10:55, Emilio Pozuelo Monfort wrote: > On 29/06/16 18:44, Emilio Pozuelo Monfort wrote: >> On 29/06/16 14:53, Leopold Palomo-Avellaneda wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear Release Team, >>> >>> I'm filing this bug for a transition of ros-ros-comm . It is >>> in experimental. It builds on all architectures in testing, where it built >>> previously. >> >>> All reverse dependencies test rebuilds. All rdepends are listed here: >>> https://release.debian.org/transitions/html/auto-ros-ros-comm.html >> >> This tangles with the ongoing opencv transition. Let's wait for that to >> finish >> before starting this. > > opencv migrated last night. You can proceed now. And it's done. Emilio--- End Message ---
Bug#830966: marked as done (transition: gdal)
Your message dated Thu, 21 Jul 2016 19:18:05 +0200 with message-id and subject line Re: Bug#830966: transition: gdal has caused the Debian Bug report #830966, regarding transition: gdal to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 830966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830966 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, For the Debian GIS team I'd like to transition to GDAL 2.1.1. Like the previous transition to GDAL 2.1.0 (#823335), there is no SONAME bump, only the virtual ABI package changed to account for the C++ symbol changes. All reverse dependencies rebuilt successfully with GDAL 2.1.1 from experimental as summarized below. libgdal-grass doesn't need a binNMU as the 2.1.1 version will be uploaded to unstable instead. liblas likewise doesn't need a binNMU, the version is experimental will be moved to unstable instead. Ben file: title = "gdal"; is_affected = .depends ~ "gdal-abi-2-1-0" | .depends ~ "gdal-abi-2-1-1"; is_good = .depends ~ "gdal-abi-2-1-1"; is_bad = .depends ~ "gdal-abi-2-1-0"; Transition: gdal libgdal20 (2.1.0+dfsg-3) -> libgdal20 (2.1.1+dfsg-1~exp1) gdal-abi-2-1-0 -> gdal-abi-2-1-1 The status of the most recent rebuilds is as follows. dans-gdal-scripts (0.23-6)OK fiona (1.7.0.post2-1) OK gazebo(7.0.0+dfsg-2) OK gmt (5.2.1+dfsg-6) SKIP (no C++) imposm(2.6.0+ds-3)SKIP (no C++) libcitygml(2.0-3) OK liblas(1.8.0-10) OK libosmium (2.7.2-1) SKIP (no C++) mapcache (1.4.1-3) SKIP (no C++) mapnik(3.0.11+ds-1) OK mapserver (7.0.1-3) SKIP (no C++) merkaartor(0.18.2-7 / 0.18.3~rc1-1~exp1) OK / OK mysql-workbench (6.3.4+dfsg-3) OK ncl (6.3.0-8) SKIP (no C++) node-srs (0.4.8+dfsg-2) OK openscenegraph(3.2.3+dfsg1-2) OK osmium(0.0~20160425-e2e4368-1)SKIP (no C++) pdal (1.2.0-4) OK postgis (2.2.2+dfsg-3) SKIP (no C++) pprepair (0.0~20160321-87ffae5-1)OK prepair (0.7-6) OK qlandkartegt (1.8.1+ds-6)OK qmapshack (1.6.2-1) OK rasterio (0.36.0-1) OK saga (2.2.7+dfsg-2 / 2.3.1+dfsg1-1~exp1) OK / OK sumo (0.26.0+dfsg1-1)OK thuban(1.2.2-11) OK vtk6 (6.3.0+dfsg1-1) OK xastir(2.0.8-1) SKIP (no C++) grass (7.0.4-3) SKIP (no C++) osgearth (2.7.0+dfsg-2) OK osmcoastline (2.1.3-2) OK otb (5.4.0+dfsg-2) OK pktools (2.6.7-2) OK pyosmium (2.7.1-2) SKIP (no C++) libgdal-grass (2.1.0-1 / 2.1.1-1~exp1)FTBFS / OK qgis (2.14.4+dfsg-1) OK Kind Regards, Bas --- End Message --- --- Begin Message --- On 15/07/16 11:51, Emilio Pozuelo Monfort wrote: > On 15/07/16 11:13, Sebastiaan Couwenberg wrote: >> It looks like #831336 that is preventing the rebuild of vtk6 will cause >> some delay in the testing migration of the packages involved in this >> transition. >> >> This leaves testing users of the qmapshack package affected by the >> critial issue reported in #831297. It's been fixed with the new upstream >> release in unstable, and with a patched backport in jessie-backports. >> >> I'd like to fix the version in testing with an upload to >> testing-proposed-updates including the same patch also used for >> jessie-backports, to fix the issue in the time mean time until the >> version from unstable migrates
Bug#829371: marked as done (transition: ntl)
Your message dated Thu, 21 Jul 2016 19:19:10 +0200 with message-id <7c9fd70d-e6d9-0ce8-a383-5f9f532c2...@debian.org> and subject line Re: Bug#829371: transition: ntl has caused the Debian Bug report #829371, regarding transition: ntl to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 829371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The transition is to a (much) newer version of NTL, going from version 6.2.1 to version 9.9.1. The auto-generated ntl transition page doesn't list flint-arb as a dep, but it probably should since there is a dependency chain ntl -> flint -> flint-arb. I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. There is a FTBFS for flint-arb on armhf, but it was already the case before the transition, so I don't count it as new problem. [Aside: and I'm still trying to sort things out with upstream.] I'll need to find sponsors for the various uploads needed for this transition, but that should be ok. Thanks, Snark on #debian-science Ben file: title = "ntl"; is_affected = .depends ~ "libntl5" | .depends ~ "libntl27"; is_good = .depends ~ "libntl27"; is_bad = .depends ~ "libntl5"; -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 04/07/16 14:13, Jonathan Wiltshire wrote: > On 2016-07-03 10:30, Jonathan Wiltshire wrote: >> Control: tag -1 confirmed >> >> On 2016-07-02 21:58, Julien Puydt wrote: >>> I checked that these new ntl packages make it possible to build eclib, >>> flint, linbox, singular and flint-arb on an amd64 debian box, so I >>> don't expect any new problem. >> >> Please go ahead. > > Seems to have happened, so rebuilds scheduled. This is finished. Cheers, Emilio--- End Message ---
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 07:17:03PM +0200, Ralf Treinen wrote: > Fixed package is in sid (5.0-3) since Fri, 15 Jul, should migrate to > testing soon. I just uploaded to jessie-backports. It migrated to testing this morning. -- 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: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 07:04:47PM +0200, Emilio Pozuelo Monfort wrote: > Hi, > > On 13/07/16 19:19, Ralf Treinen wrote: > > I think I have found the bug, for the moment I am waiting for confirmation > > by someone more knowledgable than me about this part of the code. > > Any progress on this? Do you have a patch? It'd be good to fix this, as at the > moment there are many packages stuck because dose thinks their build > dependencies are uninstallable. Fixed package is in sid (5.0-3) since Fri, 15 Jul, should migrate to testing soon. I just uploaded to jessie-backports. -Ralf.
Re: openjpeg / stretch
On 18/07/16 13:12, Alastair McKinstry wrote: > Hi, > > Can we downgrade the move from openjpeg1.x to openjpeg2.x ? Still > keeping it as a release goal, but RC-critical? > > I maintain (most of) the meteorology software, and the principal format > for weather data is GRIB2, which uses openjpeg as its primary > compression method. Until recently these all used jasper, with openjpeg > a possibility for some. But now I need to write patches for openjpeg2 > and the APIs are significantly different, with the result of nearly all > the met. software dropping out of testing. > > I am writing the patches, but would rather not see our users lose all > functionality if we can't replace openjpeg1 by stretch. I'd like to avoid shipping openjpeg 1 if at all possible, especially if we manage to fix most rdeps. If you can't have the fixes in time for Stretch, an option would be to backport them once Stretch is released. Cheers, Emilio
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi, On 13/07/16 19:19, Ralf Treinen wrote: > I think I have found the bug, for the moment I am waiting for confirmation > by someone more knowledgable than me about this part of the code. Any progress on this? Do you have a patch? It'd be good to fix this, as at the moment there are many packages stuck because dose thinks their build dependencies are uninstallable. Thanks, Emilio
Bug#819530: transition: icu
Hi Laszlo, On 30/03/16 07:38, Laszlo Boszormenyi (GCS) wrote: > ICU has a new major upstream release, supporting several new things > that I would like to see in Stretch: > - CLDR[1] 28 [2] and 29 [3] support, > - Unicode 8.0.0 [4] support. What's the status of this? I see it is in experimental now. Have you build-tested all the reverse-deps? Cheers, Emilio
Bug#830137: marked as done (transition: gnustep-gui)
Your message dated Thu, 21 Jul 2016 18:59:25 +0200 with message-id and subject line Re: Bug#830137: transition: gnustep-gui has caused the Debian Bug report #830137, regarding transition: gnustep-gui to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 830137: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830137 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition New upstream gnustep-gui/back bumps SONAME (change of ABI without change in API) , so we need to transition. Now with gnustep-gui/back 0.25.0 in experimental, we can start transition the existing GNUstep packages to the archive. The following source packages need to be rebuilt: edenmath.app adun.app zipper.app wrapperfactory.app volumecontrol.app viewpdf.app timemon.app textedit.app terminal.app talksoup.app systempreferences.app steptalk renaissance projectcenter.app price.app preview.app popplerkit.framework poe.app plopfolio.app paje.app mpdcon.app lynkeos.app lusernet.app helpviewer.app gworkspace gtamsanalyzer.app grr.app gridlock.app gorm gomoku.app gnustep-examples gnustep-sqlclient gnustep-dl2 aclock.app gnumail.app ftp.app etoile cynthiune.app charmap.app cenon.app camera.app batmon.app agenda.app affiche addresses-for-gnustep Ben file: title = "gnustep-gui"; is_affected = .build-depends ~ "libgnustep-gui-dev" | .depends ~ "libgnustep- gui0.24" | .depends ~ "libgnustep-gui0.24-dbg" | .depends ~ "libgnustep- gui0.25" | .depends ~ "libgnustep-gui0.25-dbg"; is_good = .depends ~ "libgnustep-gui0.25" | .depends ~ "libgnustep- gui0.25-dbg"; is_bad = .depends ~ "libgnustep-gui0.24" | .depends ~ "libgnustep-gui0.24-dbg"; --- End Message --- --- Begin Message --- On 14/07/16 16:20, Eric Heintzmann wrote: > > > Le 06/07/2016 à 22:59, Emilio Pozuelo Monfort a écrit : >> Control: tags -1 confirmed >> >> On 06/07/16 13:35, Eric Heintzmann wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> New upstream gnustep-gui/back bumps SONAME (change of ABI without change >>> in API) >>> , so we need to transition. >>> >>> Now with gnustep-gui/back 0.25.0 in experimental, >>> we can start transition the existing GNUstep packages to the archive. >> You can upload to unstable. > gnustep-gui 0.25.0-2 and gnustep-back 0.25.0-2 have been uploaded in > unstable And they are now in testing. Cheers, Emilio--- End Message ---
Processed: Re: Bug#832030: transition: givaro
Processing control commands: > tags -1 confirmed Bug #832030 [release.debian.org] transition: givaro Added tag(s) confirmed. -- 832030: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832030 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#831810: transition: libmicrohttpd
On 21/07/16 15:53, Jonathan Wiltshire wrote: > On 2016-07-19 20:19, Emilio Pozuelo Monfort wrote: >> On 19/07/16 19:01, Bertrand Marc wrote: >>> Do you know if I could have access to a testing build infrastructure ? >> >> You can ask someone (your sponsor) to request access to a porterbox for you. >> Other than that, I don't know. > > As a DM, Bertrand can request a guest account on a porterbox through > https://nm.debian.org > (log in and request a new status) Bertrand, can you do that and test the rest of the rdeps? Cheers, Emilio
Bug#832030: transition: givaro
Control: tags -1 confirmed On 21/07/16 16:52, Doug Torrance wrote: > A new upstream release of givaro (version 4.0.1) which bumps the SONAME has > recently been packaged and uploaded to experimental. Therefore, I am > requesting a transition slot. Go ahead. Cheers, Emilio
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On 21/07/16 at 16:40 +0200, Sven Joachim wrote: > On 2016-07-21 16:18 +0200, Santiago Vila wrote: > > > On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote: > > > >> Some of the new bugs are like this: > >> > >> make: *** No rule to make target 'build-indep'. Stop. > >> > >> Targets build-arch and build-indep are mandatory, and this was already > >> decided by dpkg author. This is not new, so I would raise those bugs > >> to serious now. > > > > A small clarification: What was decided by dpkg author is to drop a > > hack which enabled those packages to build successfully. > > > > The mass bug filing was announced by Niels here: > > > > https://lists.debian.org/debian-devel/2016/04/msg00023.html > > > > Quoting Niels: > > > >> We intend to do another round of MBF for this problem once we have > >> located a way to break down the remaining packages into smaller and more > >> manageable sets. > > > > I think the second round of MBF did not take place yet. > > It did, albeit a bit later than planned. See Guillem's followup this > month[1] and the list of bugs Niels has filed[2]. No, that's the list of bugs filed as part of the initial MBF (on 99 packages), as announced by Niels in April. Then later the severity was upgraded from important to serious. Lucas
Processed: Re: Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
Processing commands for cont...@bugs.debian.org: > clone 830997 -1 Bug #830997 [release.debian.org] release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC Bug 830997 cloned as bug 832029 > reassign -1 lintian Bug #832029 [release.debian.org] release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC Bug reassigned from package 'release.debian.org' to 'lintian'. Ignoring request to alter found versions of bug #832029 to the same values previously set Ignoring request to alter fixed versions of bug #832029 to the same values previously set > retitle -1 lintian: fails to detect missing build-indep target in 9 packages Bug #832029 [lintian] release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC Changed Bug title to 'lintian: fails to detect missing build-indep target in 9 packages' from 'release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC'. > thanks Stopping processing here. Please contact me if you need assistance. -- 830997: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830997 832029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832029 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832030: transition: givaro
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello! A new upstream release of givaro (version 4.0.1) which bumps the SONAME has recently been packaged and uploaded to experimental. Therefore, I am requesting a transition slot. There is currently only one reverse dependency: linbox. Linbox is RC buggy and not in testing. The version currently in sid fails to build with the new version of givaro (it requires givaro version 3.7.0). But a new upstream version of linbox exists which should work -- I plan to package this in the near future. Note that linbox is also part of the ntl transition (#829371). There are also two reverse build-dependencies: libm4rie and fflas-ffpack. A test build of libm4rie with the new version of givaro worked without problems. The fflas-ffpack in sid fails to build, but like linbox, it requires an earlier version of givaro. Also like linbox, there is a new upstream version available which should work and that I plan to package soon. Note that the givaro -> fflas-ffpack -> linbox dependency chain are all maintained by the same team upstream [1]. Thanks! Doug [1] https://github.com/linbox-team Ben file: title = "givaro"; is_affected = .depends ~ "libgivaro1v5" | .depends ~ "libgivaro8"; is_good = .depends ~ "libgivaro8"; is_bad = .depends ~ "libgivaro1v5";
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
clone 830997 -1 reassign -1 lintian retitle -1 lintian: fails to detect missing build-indep target in 9 packages thanks On 21/07/16 at 16:18 +0200, Santiago Vila wrote: > On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote: > > > Some of the new bugs are like this: > > > > make: *** No rule to make target 'build-indep'. Stop. > > > > Targets build-arch and build-indep are mandatory, and this was already > > decided by dpkg author. This is not new, so I would raise those bugs > > to serious now. > > A small clarification: What was decided by dpkg author is to drop a > hack which enabled those packages to build successfully. > > The mass bug filing was announced by Niels here: > > https://lists.debian.org/debian-devel/2016/04/msg00023.html > > Quoting Niels: > > > We intend to do another round of MBF for this problem once we have > > located a way to break down the remaining packages into smaller and more > > manageable sets. > > I think the second round of MBF did not take place yet. So: How is it > possible that you (Lucas) found so few packages that didn't build? Hi, I indeed ran into many bugs already filed by Niels, and only filed bugs for the packages where bugs were missing. It seems that, when bugs were missing, lintian was unable to detect the missing targets. So that's a bug in lintian (it fails to detect that those 9 packages are missing build-indep). Cloning accordingly. Also, the lintian page[1] includes many packages that are missing build-indep, but don't build any Architecture:all package. That's still a bug in the packages (as build-indep is required even in that case) but I wouldn't detect it as I restricted my test to packages building Arch:all binaries. Maybe it could make sense for lintian to distinguish those two cases (missing build-indep and building arch:all vs missing build-indep and not building arch:all). Finally, it seems that dpkg still has a workaround for missing build-indep for packages building only Arch:all binaries. For example, see this log for libgtk2-ex-podviewer-perl_0.18-1: > dpkg-buildpackage > - > > dpkg-buildpackage: info: source package libgtk2-ex-podviewer-perl > dpkg-buildpackage: info: source version 0.18-1 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Ryan Niebur > dpkg-source --before-build libgtk2-ex-podviewer-perl-0.18 > fakeroot debian/rules clean > dh clean >dh_testdir >dh_auto_clean >dh_clean > dpkg-buildpackage: warning: debian/rules must be updated to support the > 'build-arch' and 'build-indep' targets (at least 'build-indep' seems to be > missing) > debian/rules build > dh build >dh_testdir >dh_update_autotools_config >dh_auto_configure That's why I did not run into more failures. [1] https://lintian.debian.org/tags/debian-rules-missing-recommended-target.html Grepping my build logs for the above warning message, the following 540 packages are missing build-indep (and building only Arch:all): abicheck abntex adzapper apf-firewall apsfilter apt-dpkg-ref apticron aptoncd apt-show-source archmbox aspell-cs asql attal-themes autoconf2.59 autoconf2.64 autopsy babiloo bauble beancounter biabam bindgraph binstats biojava-live bittornado bjsonrpc bum cadubi castle-combat cdlabelgen cffi cfortran cgvg chaksem checksecurity childsplay-alphabet-sounds-bg childsplay-alphabet-sounds-ca childsplay-alphabet-sounds-de childsplay-alphabet-sounds-el childsplay-alphabet-sounds-en-gb childsplay-alphabet-sounds-es childsplay-alphabet-sounds-fr childsplay-alphabet-sounds-it childsplay-alphabet-sounds-nb childsplay-alphabet-sounds-nl childsplay-alphabet-sounds-pt childsplay-alphabet-sounds-ro childsplay-alphabet-sounds-ru childsplay-alphabet-sounds-sl childsplay-alphabet-sounds-sv clamassassin cl-babel cl-closer-mop cl-cluck cl-contextl cl-fftw3 cl-flexichain cl-getopt cli-common clipf cl-irc cl-irc-logger cl-lml2 cl-lml cl-lw-compat cl-mcclim cl-modlisp cl-pg cl-photo cl-pipes cl-portable-aserve cl-ppcre cl-ptester cl-pubmed cl-rlc cl-rt cl-split-sequence cl-xlunit cl-xmls cl-xptest coco-doc colorgcc command-not-found console-cyrillic controlaula creoleparser crip ctn-doc culmus-fancy customdeb cvs-mailcommit darcsweb dbix-easy-perl ddccontrol-db debget debian-builder debian-zh-faq debsecan deps dh-buildinfo dict-bouvier dictclient dictdlib dict-gazetteer2k dict-moby-thesaurus discover-data ditrack dkimproxy dlint dlocate dns323-firmware-tools dns-browse docbook2odf docbook5-xml docbook-simple docbook-xml doc-linux-hr doctorj drobo-utils efp elida elscreen emacs-jabber epic4-help erc essays1743 ewipe extra-xdg-menus festival-czech festival-it festvox-czech-dita festvox-czech-krb festvox-czech-machac festvox-czech-ph fig2ps file-rc filler flamethrower flexbackup flexi-streams flowscan fluid-soundfont focalinux fofix-dfsg fonts-jsmath fortunes-bg fortunes-bofh-excuses fortunes-es fortunes-fr fortunes-ru freepats fretsonfire-songs-muldjord fr
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On 2016-07-21 16:18 +0200, Santiago Vila wrote: > On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote: > >> Some of the new bugs are like this: >> >> make: *** No rule to make target 'build-indep'. Stop. >> >> Targets build-arch and build-indep are mandatory, and this was already >> decided by dpkg author. This is not new, so I would raise those bugs >> to serious now. > > A small clarification: What was decided by dpkg author is to drop a > hack which enabled those packages to build successfully. > > The mass bug filing was announced by Niels here: > > https://lists.debian.org/debian-devel/2016/04/msg00023.html > > Quoting Niels: > >> We intend to do another round of MBF for this problem once we have >> located a way to break down the remaining packages into smaller and more >> manageable sets. > > I think the second round of MBF did not take place yet. It did, albeit a bit later than planned. See Guillem's followup this month[1] and the list of bugs Niels has filed[2]. Cheers, Sven 1. https://lists.debian.org/debian-devel/2016/07/msg00130.html 2. https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=arch-all-and-any-missing-targets;users=ni...@thykier.net
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote: > Some of the new bugs are like this: > > make: *** No rule to make target 'build-indep'. Stop. > > Targets build-arch and build-indep are mandatory, and this was already > decided by dpkg author. This is not new, so I would raise those bugs > to serious now. A small clarification: What was decided by dpkg author is to drop a hack which enabled those packages to build successfully. The mass bug filing was announced by Niels here: https://lists.debian.org/debian-devel/2016/04/msg00023.html Quoting Niels: > We intend to do another round of MBF for this problem once we have > located a way to break down the remaining packages into smaller and more > manageable sets. I think the second round of MBF did not take place yet. So: How is it possible that you (Lucas) found so few packages that didn't build? Thanks.
Bug#831810: transition: libmicrohttpd
On 2016-07-19 20:19, Emilio Pozuelo Monfort wrote: On 19/07/16 19:01, Bertrand Marc wrote: Do you know if I could have access to a testing build infrastructure ? You can ask someone (your sponsor) to request access to a porterbox for you. Other than that, I don't know. As a DM, Bertrand can request a guest account on a porterbox through https://nm.debian.org (log in and request a new status) -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits
Bug#831810: transition: libmicrohttpd
Hi,
Le 19/07/2016 à 21:19, Emilio Pozuelo Monfort a écrit :
> In lack of that, do you know how much the ABI changed?
Sorry I missed that bit in my first message. To my mind (but I am not
sure), the soname bump comes from a new member in the middle of a union
struct exposed in /usr/include/microhttpd.h:
union MHD_ConnectionInfo
{
...
int /* enum gnutls_protocol */ protocol;
/**
+ * The suspended status of a connection.
+ */
+ int /* MHD_YES or MHD_NO */ suspended;
+
+ /**
* Connect socket
*/
...
}
There are also new enum constants, but they seem backward compatible.
And no symbols were removed.
Best regards,
Bertrand
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 2016-07-21 11:25, Andrew Shadura wrote: On 21/07/16 12:19, Adam D. Barratt wrote: On 2016-07-21 11:01, Adam D. Barratt wrote: Control: tags -1 -moreinfo +confirmed [...] +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Actually, hold on that. It was just pointed out to me that the patches aren't in unstable yet - that needs to happen first. Okay. The maintainer has done some work in the VCS, but it doesn't seem ready for upload yet, and he hasn't committed anything since May. Should I put an NMU with just these patches into DELAYED queue? (Stefan Cc-ed.) No preference from the SRM side. When / how the patches get applied in unstable is mostly irrelevant for us, it just needs to happen before we'll accept them for stable. Regards, Adam
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 12:19, Adam D. Barratt wrote: > > On 2016-07-21 11:01, Adam D. Barratt wrote: >> Control: tags -1 -moreinfo +confirmed > [...] >> +wpa (2.3-1+deb8u4) jessie-security; urgency=medium >> >> The distribution there should be "jessie" (and was in the earlier >> diff). With that changed, please feel free to go ahead. > > Actually, hold on that. It was just pointed out to me that the patches > aren't in unstable yet - that needs to happen first. Okay. The maintainer has done some work in the VCS, but it doesn't seem ready for upload yet, and he hasn't committed anything since May. Should I put an NMU with just these patches into DELAYED queue? (Stefan Cc-ed.) -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 +moreinfo -confirmed On 2016-07-21 11:01, Adam D. Barratt wrote: Control: tags -1 -moreinfo +confirmed [...] +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Actually, hold on that. It was just pointed out to me that the patches aren't in unstable yet - that needs to happen first. Regards, Adam
Processed: Re: Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Processing control commands: > tags -1 +moreinfo -confirmed Bug #832004 [release.debian.org] jessie-pu: package wpa/2.3-1+deb8u4 Added tag(s) moreinfo. Bug #832004 [release.debian.org] jessie-pu: package wpa/2.3-1+deb8u4 Removed tag(s) confirmed. -- 832004: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832004 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 -moreinfo +confirmed [CCing -boot@ and kibi for reference, as wpa produces a udeb. The fixes look "obviously correct" enough to me] On 2016-07-21 10:51, Andrew Shadura wrote: On 21/07/16 11:42, Andrew Shadura wrote: On 21/07/16 11:37, Andrew Shadura wrote: On 21/07/16 11:32, Adam D. Barratt wrote: I realise that none of the above are actually enabled in debian/patches/series, but that makes it even more confusing that they're in the diff. Please prepare and test a package that contains only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and provide a debdiff of that. I have redone the package, tested it and generated a debdiff. That looks much better, thanks. :-) +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Regards, Adam
Processed: Re: Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Processing control commands: > tags -1 -moreinfo +confirmed Bug #832004 [release.debian.org] jessie-pu: package wpa/2.3-1+deb8u4 Removed tag(s) moreinfo. Bug #832004 [release.debian.org] jessie-pu: package wpa/2.3-1+deb8u4 Added tag(s) confirmed. -- 832004: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832004 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:42, Andrew Shadura wrote:
> On 21/07/16 11:37, Andrew Shadura wrote:
>> On 21/07/16 11:32, Adam D. Barratt wrote:
I realise that none of the above are actually enabled in
debian/patches/series, but that makes it even more confusing that
they're in the diff. Please prepare and test a package that contains
only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and
provide a debdiff of that.
I have redone the package, tested it and generated a debdiff.
--
Cheers,
Andrew
diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog
--- wpa-2.3/debian/changelog2015-11-07 16:07:28.0 +0100
+++ wpa-2.3/debian/changelog2016-07-21 11:42:28.0 +0200
@@ -1,3 +1,17 @@
+wpa (2.3-1+deb8u4) jessie-security; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patches to address CVE-2016-4476 and CVE-2016-4477, thanks to
+Salvatore Bonaccorso (Closes: #823411):
+- WPS: Reject a Credential with invalid passphrase
+- Reject psk parameter set with invalid passphrase character
+- Remove newlines from wpa_supplicant config network output
+- Reject SET_CRED commands with newline characters in the string values
+- Reject SET commands with newline characters in the string values
+ * Refresh patches to apply cleanly.
+
+ -- Andrew Shadura Thu, 21 Jul 2016 09:01:51 +0200
+
wpa (2.3-1+deb8u3) jessie-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
---
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
2016-07-21 11:42:28.0 +0200
@@ -25,7 +25,7 @@
index f2b0926..a629437 100644
--- a/src/eap_peer/eap_pwd.c
+++ b/src/eap_peer/eap_pwd.c
-@@ -355,6 +355,23 @@ eap_pwd_perform_commit_exchange(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -301,6 +301,23 @@
BIGNUM *mask = NULL, *x = NULL, *y = NULL, *cofactor = NULL;
u16 offset;
u8 *ptr, *scalar = NULL, *element = NULL;
@@ -49,7 +49,7 @@
if (((data->private_value = BN_new()) == NULL) ||
((data->my_element = EC_POINT_new(data->grp->group)) == NULL) ||
-@@ -554,6 +571,18 @@ eap_pwd_perform_confirm_exchange(struct eap_sm *sm,
struct eap_pwd_data *data,
+@@ -500,6 +517,18 @@
u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
int offset;
diff -Nru
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
---
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
2016-07-21 11:42:28.0 +0200
@@ -25,7 +25,7 @@
index 66bd5d2..3189105 100644
--- a/src/eap_server/eap_server_pwd.c
+++ b/src/eap_server/eap_server_pwd.c
-@@ -656,9 +656,21 @@ eap_pwd_process_commit_resp(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -634,9 +634,21 @@
BIGNUM *x = NULL, *y = NULL, *cofactor = NULL;
EC_POINT *K = NULL, *point = NULL;
int res = 0;
@@ -47,7 +47,7 @@
if (((data->peer_scalar = BN_new()) == NULL) ||
((data->k = BN_new()) == NULL) ||
((cofactor = BN_new()) == NULL) ||
-@@ -774,6 +786,13 @@ eap_pwd_process_confirm_resp(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -752,6 +764,13 @@
u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
int offset;
diff -Nru
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
---
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
2016-07-21 11:42:28.0 +0200
@@ -23,7 +23,7 @@
index a629437..1d2079b 100644
--- a/src/eap_peer/eap_pwd.c
+++ b/src/eap_peer/eap_pwd.c
-@@ -866,11 +866,23 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct
eap_method_ret *ret,
+@@ -812,11 +812,23 @@
* if it's the first fragment there'll be a length field
*/
if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
diff -Nru
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
---
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:37, Andrew Shadura wrote: > On 21/07/16 11:32, Adam D. Barratt wrote: >> > I realise that none of the above are actually enabled in >> > debian/patches/series, but that makes it even more confusing that >> > they're in the diff. Please prepare and test a package that contains >> > only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and >> > provide a debdiff of that. > Oh, I'm very sorry, I think I have made a mistake while merging or > diffing something. Right, those were left-overs from a previous cherry-picking attempt, untracked by Git. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:32, Adam D. Barratt wrote: > I realise that none of the above are actually enabled in > debian/patches/series, but that makes it even more confusing that > they're in the diff. Please prepare and test a package that contains > only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and > provide a debdiff of that. Oh, I'm very sorry, I think I have made a mistake while merging or diffing something. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Processing control commands: > tags -1 + moreinfo Bug #832004 [release.debian.org] jessie-pu: package wpa/2.3-1+deb8u4 Added tag(s) moreinfo. -- 832004: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832004 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 + moreinfo On 2016-07-21 9:51, Andrew Shadura wrote: I have prepared an upload fixing CVE-2016-4476 and CVE-2016-4477. Please find the attached debdiff. I may be missing something, but what do these changes have to do with fixing either of the CVEs you mentioned? patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch | 37 + patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt | 68 + patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch | 44 + patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt | 73 + patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch | 36 patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch | 68 + patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch | 61 + patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch | 47 + patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch | 45 + patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch | 27 patches/2015-04/eap-pwd-missing-payload-length-validation.txt | 64 + patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch | 56 + patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt | 87 ++ These look like they're fixes for security issues, but not either of the ones mentioned in the changelog. Hmmm, in fact they look like copies of already existing patches. For instance, this file: patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch | 68 + appears to be a duplicate of: patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch |4 These don't appear to be security-related at all, nor mentioned in the changelog: patches/ap_config_c_fix-typo-for-capabilities.patch | 28 patches/fix-minor-issue-in-HT40-max-rate-determination.patch | 25 patches/fix-spelling-s-algorith-algorithm.patch | 25 patches/improve-BSS-selection-with-default-noise-floor-value.patch | 158 patches/select-AP-based-on-estimated-maximum-throughput.patch | 366 ++ patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch | 26 I realise that none of the above are actually enabled in debian/patches/series, but that makes it even more confusing that they're in the diff. Please prepare and test a package that contains only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and provide a debdiff of that. [ The current diff is 36 files changed, 1827 insertions(+), 14 deletions(-) As far as I can tell, the actual functional changes are: 8 files changed, 414 insertions(+) ] Regards, Adam
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I have prepared an upload fixing CVE-2016-4476 and CVE-2016-4477.
Please find the attached debdiff.
Sébastien Delafond advised me this upload is for the point release,
and isn't supposed to be handled by the Security Team.
--
Cheers,
Andrew
diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog
--- wpa-2.3/debian/changelog 2015-11-07 16:07:28.0 +0100
+++ wpa-2.3/debian/changelog 2016-07-21 09:19:43.0 +0200
@@ -1,3 +1,17 @@
+wpa (2.3-1+deb8u4) jessie; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patches to address CVE-2016-4476 and CVE-2016-4477, thanks to
+Salvatore Bonaccorso (Closes: #823411):
+- WPS: Reject a Credential with invalid passphrase
+- Reject psk parameter set with invalid passphrase character
+- Remove newlines from wpa_supplicant config network output
+- Reject SET_CRED commands with newline characters in the string values
+- Reject SET commands with newline characters in the string values
+ * Refresh patches to apply cleanly.
+
+ -- Andrew Shadura Thu, 21 Jul 2016 09:19:42 +0200
+
wpa (2.3-1+deb8u3) jessie-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch
--- wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch 1970-01-01 01:00:00.0 +0100
+++ wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch 2016-07-21 08:49:03.0 +0200
@@ -0,0 +1,37 @@
+From 9ed4eee345f85e3025c33c6e20aa25696e341ccd Mon Sep 17 00:00:00 2001
+From: Jouni Malinen
+Date: Tue, 7 Apr 2015 11:32:11 +0300
+Subject: [PATCH] P2P: Validate SSID element length before copying it
+ (CVE-2015-1863)
+
+This fixes a possible memcpy overflow for P2P dev->oper_ssid in
+p2p_add_device(). The length provided by the peer device (0..255 bytes)
+was used without proper bounds checking and that could have resulted in
+arbitrary data of up to 223 bytes being written beyond the end of the
+dev->oper_ssid[] array (of which about 150 bytes would be beyond the
+heap allocation) when processing a corrupted management frame for P2P
+peer discovery purposes.
+
+This could result in corrupted state in heap, unexpected program
+behavior due to corrupted P2P peer device information, denial of service
+due to process crash, exposure of memory contents during GO Negotiation,
+and potentially arbitrary code execution.
+
+Thanks to Google security team for reporting this issue and smart
+hardware research group of Alibaba security team for discovering it.
+
+Signed-off-by: Jouni Malinen
+---
+ src/p2p/p2p.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/src/p2p/p2p.c
b/src/p2p/p2p.c
+@@ -736,6 +736,7 @@ int p2p_add_device(struct p2p_data *p2p,
+ if (os_memcmp(addr, p2p_dev_addr, ETH_ALEN) != 0)
+ os_memcpy(dev->interface_addr, addr, ETH_ALEN);
+ if (msg.ssid &&
++ msg.ssid[1] <= sizeof(dev->oper_ssid) &&
+ (msg.ssid[1] != P2P_WILDCARD_SSID_LEN ||
+ os_memcmp(msg.ssid + 2, P2P_WILDCARD_SSID, P2P_WILDCARD_SSID_LEN)
+ != 0)) {
diff -Nru wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt
--- wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt 1970-01-01 01:00:00.0 +0100
+++ wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt 2016-07-21 08:49:03.0 +0200
@@ -0,0 +1,68 @@
+wpa_supplicant P2P SSID processing vulnerability
+
+Published: April 22, 2015
+Identifier: CVE-2015-1863
+Latest version available from: http://w1.fi/security/2015-1/
+
+
+Vulnerability
+
+A vulnerability was found in how wpa_supplicant uses SSID information
+parsed from management frames that create or update P2P peer entries
+(e.g., Probe Response frame or number of P2P Public Action frames). SSID
+field has valid length range of 0-32 octets. However, it is transmitted
+in an element that has a 8-bit length field and potential maximum
+payload length of 255 octets. wpa_supplicant was not sufficiently
+verifying the payload length on one of the code paths using the SSID
+received from a peer device.
+
+This can result in copying arbitrary data from an attacker to a fixed
+length buffer of 32 bytes (i.e., a possible overflow of up to 223
+bytes). The SSID buffer is within struct p2p_device that is allocated
+from heap. The overflow can override couple of variables in the struct,
+including a pointer that gets freed. In addition about 150 bytes (the
+exact length depending on architecture) can be written beyond the end of
+the heap allocation.
+
+This could result in corrupted state in heap, unexpected program
+behavior due to corrupte
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On 21/07/16 at 02:21 +0200, Santiago Vila wrote: > On Wed, Jul 20, 2016 at 09:47:52PM +0200, Lucas Nussbaum wrote: > > On 15/07/16 at 00:23 +0200, Santiago Vila wrote: > > > > I did some work to verify Santiago's list of affected packages, and > > identified more affected packages. The additional bugs I filed are at: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org > > > > (I didn't want to directly tag them using Santiago's tag in case some > > manual screening was wanted.) > > > > I only filed them as severity: important. Feel free to bump the severity > > to serious when you see fit. I already mentioned in the bug reports that > > severity will be set to serious at some point, and pointed to this bug. > > Thanks a lot for double-checking. > > > Some of the new bugs are like this: > > make: *** No rule to make target 'build-indep'. Stop. > > Targets build-arch and build-indep are mandatory, and this was already > decided by dpkg author. This is not new, so I would raise those bugs > to serious now. Hi, Those bugs are: • #831918 [i| | ] [src:bglibs] bglibs: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831921 [i| | ] [src:daemontools] daemontools: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831933 [i| | ] [src:mono] mono: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831944 [i| | ] [src:pyorbit] pyorbit: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831945 [i| | ] [src:pygtk] pygtk: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831950 [i| | ] [src:gnome-python] gnome-python: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831960 [i| | ] [src:pygobject-2] pygobject-2: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831961 [i| | ] [src:proftpd-dfsg] proftpd-dfsg: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831963 [i| | ] [src:netqmail] netqmail: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. I've just raised their severity to serious. > Also: Could you tag those bugs differently so that we can differentiate > them from the remaining ones? We certainly don't want the Release Managers > to think we want to add 61 more RC bugs for stretch when they are > really less than that. I'm not sure we should bother with that... they will all be RC soon anyway. Lucas
