Bug#835170: transition: protobuf
On 02/09/16 11:48, Sebastiaan Couwenberg wrote: > protobuf (3.0.0-7) has been uploaded to unstable which contains a patch > to fix the ostinato build failure (#). > > Can you schedule a dep-wait to rebuild ostinato (0.8-1) with > libprotobuf-dev (3.0.0-7) once that's available on the buildds? Scheduled. Emilio
Bug#835170: transition: protobuf
protobuf (3.0.0-7) has been uploaded to unstable which contains a patch to fix the ostinato build failure (#). Can you schedule a dep-wait to rebuild ostinato (0.8-1) with libprotobuf-dev (3.0.0-7) once that's available on the buildds? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 01/09/16 22:36, Sebastiaan Couwenberg wrote: > On 08/31/2016 04:59 PM, Emilio Pozuelo Monfort wrote: >> On 31/08/16 12:00, Sebastiaan Couwenberg wrote: >>> Just for the record, osmium rebuilds are failing because most tests >>> segfault by >>> having two versions of libdap installed. Caused by the uncoordinated >>> transition >>> triggered with the upload of libdap (3.18.0-1) to unstable. gdal needs to be >>> rebuilt with the new libdap to fix the issue affecting the osmium package. >>> First >>> the libdap build failures on several release architectures need to be fixed. >> >> OK. Looks like libdap is already fixed. I'll look at its binnmus later. > > The gdal rebuilds with the new libdap are installed now, can you retry > the osmium builds with the new protobuf on amd64, i386, mips & mipsel? Done. Cheers, Emilio
Bug#835170: transition: protobuf
On 08/31/2016 04:59 PM, Emilio Pozuelo Monfort wrote: > On 31/08/16 12:00, Sebastiaan Couwenberg wrote: >> Just for the record, osmium rebuilds are failing because most tests segfault >> by >> having two versions of libdap installed. Caused by the uncoordinated >> transition >> triggered with the upload of libdap (3.18.0-1) to unstable. gdal needs to be >> rebuilt with the new libdap to fix the issue affecting the osmium package. >> First >> the libdap build failures on several release architectures need to be fixed. > > OK. Looks like libdap is already fixed. I'll look at its binnmus later. The gdal rebuilds with the new libdap are installed now, can you retry the osmium builds with the new protobuf on amd64, i386, mips & mipsel? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 31/08/16 12:00, Sebastiaan Couwenberg wrote: > On 08/31/16 11:30, Sebastiaan Couwenberg wrote: >> On 08/31/16 00:41, Emilio Pozuelo Monfort wrote: >>> On 28/08/16 18:13, Sebastiaan Couwenberg wrote: On 08/25/16 19:17, Sebastiaan Couwenberg wrote: > On 08/25/16 17:33, Sebastiaan Couwenberg wrote: >> Several packages unfortunately fail to build, some due to unrelated >> issues to the new protobuf packages. Bugs still need to be filed for >> those that weren't sid-ony due to RC bugs already. > > The bugreports have been filed, and ones specific to protobuf 3.0.0 > have > been usertagged for easy access: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org > > > Release Team, can you schedule binNMUs for the packages that rebuilt OK? >>> >>> Scheduled. >> >> Thanks, can you also nmu libphonenumber (7.1.0-4), it builds >> successfully with the changes from protobuf (3.0.0-6). >> >> And mosh (1.2.6-1) which I mistakenly marked as NOT-NEEDED which should >> have been mozc which was already rebuilt via a maintainer upload. Both scheduled. > Just for the record, osmium rebuilds are failing because most tests segfault > by > having two version of libdap installed. Caused by the uncoordinated transition > triggered with the upload of libdap (3.18.0-1) to unstable. gdal needs to be > rebuilt with the new libdap to fix the issue affecting the osmium package. > First > the libdap build failures on several release architectures need to be fixed. OK. Looks like libdap is already fixed. I'll look at its binnmus later. Cheers, Emilio
Bug#835170: transition: protobuf
On 08/31/16 11:30, Sebastiaan Couwenberg wrote: On 08/31/16 00:41, Emilio Pozuelo Monfort wrote: On 28/08/16 18:13, Sebastiaan Couwenberg wrote: On 08/25/16 19:17, Sebastiaan Couwenberg wrote: On 08/25/16 17:33, Sebastiaan Couwenberg wrote: Several packages unfortunately fail to build, some due to unrelated issues to the new protobuf packages. Bugs still need to be filed for those that weren't sid-ony due to RC bugs already. The bugreports have been filed, and ones specific to protobuf 3.0.0 have been usertagged for easy access: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org Release Team, can you schedule binNMUs for the packages that rebuilt OK? Scheduled. Thanks, can you also nmu libphonenumber (7.1.0-4), it builds successfully with the changes from protobuf (3.0.0-6). And mosh (1.2.6-1) which I mistakenly marked as NOT-NEEDED which should have been mozc which was already rebuilt via a maintainer upload. Just for the record, osmium rebuilds are failing because most tests segfault by having two version of libdap installed. Caused by the uncoordinated transition triggered with the upload of libdap (3.18.0-1) to unstable. gdal needs to be rebuilt with the new libdap to fix the issue affecting the osmium package. First the libdap build failures on several release architectures need to be fixed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 08/31/16 00:41, Emilio Pozuelo Monfort wrote: On 28/08/16 18:13, Sebastiaan Couwenberg wrote: On 08/25/16 19:17, Sebastiaan Couwenberg wrote: On 08/25/16 17:33, Sebastiaan Couwenberg wrote: Several packages unfortunately fail to build, some due to unrelated issues to the new protobuf packages. Bugs still need to be filed for those that weren't sid-ony due to RC bugs already. The bugreports have been filed, and ones specific to protobuf 3.0.0 have been usertagged for easy access: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org Release Team, can you schedule binNMUs for the packages that rebuilt OK? Scheduled. Thanks, can you also nmu libphonenumber (7.1.0-4), it builds successfully with the changes from protobuf (3.0.0-6). And mosh (1.2.6-1) which I mistakenly marked as NOT-NEEDED which should have been mozc which was already rebuilt via a maintainer upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 28/08/16 18:13, Sebastiaan Couwenberg wrote: > On 08/25/16 19:17, Sebastiaan Couwenberg wrote: >> On 08/25/16 17:33, Sebastiaan Couwenberg wrote: >>> Several packages unfortunately fail to build, some due to unrelated >>> issues to the new protobuf packages. Bugs still need to be filed for >>> those that weren't sid-ony due to RC bugs already. >> >> The bugreports have been filed, and ones specific to protobuf 3.0.0 have >> been usertagged for easy access: >> >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org >> > > Release Team, can you schedule binNMUs for the packages that rebuilt OK? Scheduled. Emilio
Bug#835170: transition: protobuf
On 08/25/16 19:17, Sebastiaan Couwenberg wrote: On 08/25/16 17:33, Sebastiaan Couwenberg wrote: Several packages unfortunately fail to build, some due to unrelated issues to the new protobuf packages. Bugs still need to be filed for those that weren't sid-ony due to RC bugs already. The bugreports have been filed, and ones specific to protobuf 3.0.0 have been usertagged for easy access: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org Release Team, can you schedule binNMUs for the packages that rebuilt OK? anfo (sid only) (0.98-4) FTBFS appstream(0.9.8-4) OK berkeley-express (1.5.1-2) OK bitcoin (sid only) (0.12.1-0.1 / 0.13.0-0.1~exp1) OK / OK clementine (1.3.1+dfsg-1) OK cubemap (1.3.1-1) OK dogecoin (1.10.0-2) OK gazebo (7.3.0+dfsg-2) FTBFS harvest-tools(1.2-2)OK ignition-transport (1.3.0-1) FTBFS imposm-parser(1.0.7+ds-3) OK libphonenumber (7.1.0-4) FTBFS litecoin (sid only) (0.10.4.0-1) FTBFS mahimahi (sid only) (0.92-1) FTBFS mixxx(2.0.0~dfsg-5) OK mosh (1.2.6-1) NOT-NEEDED mozc (2.18.2595.102+dfsg-1) OK mumble (1.2.16-2) OK ola (sid only) (0.10.2-1) FTBFS osmpbf (1.3.3-7) NOT-NEEDED ostinato (0.8-1)FTBFS pdns-recursor(4.0.1-1) OK php-pinba (sid only) (1.0.0-2) OK pink-pony(1.4.1-2) OK pokerth (sid only) (1.1.1-4) OK protobuf-c (1.2.1-1) OK r-cran-rprotobuf (0.4.3-1) OK ricochet-im (1.1.2-1) OK shogun (sid only)(3.2.0-7.3)FTBFS zbackup (1.4.4-1) OK imposm (2.6.0+ds-3) OK osmium (0.0~20160425-e2e4368-2) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 08/25/16 17:33, Sebastiaan Couwenberg wrote: Several packages unfortunately fail to build, some due to unrelated issues to the new protobuf packages. Bugs still need to be filed for those that weren't sid-ony due to RC bugs already. The bugreports have been filed, and ones specific to protobuf 3.0.0 have been usertagged for easy access: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=protobuf-3.0.0;users=pkg-protobuf-de...@lists.alioth.debian.org anfo (0.98-4) FTBFS due to a d-shlibs issue: Reported in #835425 with patch. gazebo (7.3.0+dfsg-2) FTBFS due to an issue with tinyxml2: Reported in #835427 ignition-transport (1.3.0-1) FTBFS due to incompatibility with protobuf 3.0.0: Reported in #835429 libphonenumber (7.1.0-4) FTBFS due to an issue with the maven dependencies: Reported in #835430 ola (0.10.2-1) FTBFS due to configure failing to find numpy: Reported in #835433 with patch ostinato (0.8-1) FTBFS due to incompatibility with the new protobuf: Reported in #835435 protobuf maintainers, can you provide patches for the packages that FTBFS with protobuf 3.0.0 which don't have a patch yet? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
Control: block -1 by 809290 811917 822380
On 08/23/16 16:45, Dmitry Smirnov wrote:
On Tuesday, 23 August 2016 11:32:10 AM AEST Sebastiaan Couwenberg wrote:
Dmitry, have you tested the reverse dependencies if they still build?
No... We will have to deal with fallout, if any... It is crucial to have
protobuf-3 from life cycle prospective. Also several golang dependencies
require protobuf v3 so upload actually allows to fix numerous problems.
Since someone has to test the rdeps before the Release Managers can
schedule binNMUs, I've done a round of rebuilds with protobuf (3.0.0-4).
The summary can be found below.
Some packages were already built successfully in unstable due to
maintainer uploads:
mozc (2.18.2595.102+dfsg-1)
osmpbf (1.3.3-7)
Several packages unfortunately fail to build, some due to unrelated
issues to the new protobuf packages. Bugs still need to be filed for
those that weren't sid-ony due to RC bugs already.
anfo (0.98-4) FTBFS due to a d-shlibs issue:
devlibs error: There is no package matching [libprotobuf10-dev] and
noone provides it, please report bug to d-shlibs maintainer
gazebo (7.3.0+dfsg-2) FTBFS due to an issue with tinyxml2:
/build/gazebo-7.3.0+dfsg/gazebo/util/LogPlay.cc:108:13: error:
'XML_NO_ERROR' is not a member of 'tinyxml2'
tinyxml2::XML_NO_ERROR;
^~~~
ignition-transport (1.3.0-1) FTBFS due to incompatibility with protobuf
3.0.0:
/build/ignition-transport-1.3.0/include/ignition/transport/SubscriptionHandler.hh:148:53:
error: expected primary-expression before 'const'
auto msgPtr = google::protobuf::down_cast(&_msg);
^
The buildlog contains more protobuf related errors.
libphonenumber (7.1.0-4) FTBFS due to an issue with the maven dependencies:
[ERROR] Failed to execute goal on project cpp-build: Could not resolve
dependencies for project
com.google.i18n.phonenumbers.tools:cpp-build:jar:1.0-SNAPSHOT: Cannot
access central (https://repo.maven.apache.org/maven2) in offline mode
and the artifact org.easymock:easymockclassextension:jar:debian has not
been downloaded from it before. -> [Help 1]
litecoin (0.10.4.0-1) FTBFS due to an issue with boost (#811917):
chainparams.cpp:231:72: error: ambiguous overload for 'operator='
(operand types are 'std::vector' and
'boost::assign_detail::generic_list')
base58Prefixes[EXT_SECRET_KEY] = list_of(0x04)(0x35)(0x83)(0x94);
mahimahi (0.92-1) FTBFS due to #822380:
poller.cc: In member function 'Poller::Result Poller::poll(const int&)':
poller.cc:40:80: error: 'accumulate' was not declared in this scope
[] ( bool acc, pollfd x ) { return acc or
x.events; } ) ) {
ola (0.10.2-1) FTBFS due to configure failing to find numpy:
configure: error: failed to find required module numpy
ostinato (0.8-1) FTBFS due to incompatibility with the new protobuf:
rpcconn.cpp: In member function 'void
RpcConnection::on_clientSock_dataAvail()':
rpcconn.cpp:382:9: error: 'NewCallback' is not a member of
'google::protobuf'
shogun (3.2.0-7.3) FTBFS due to #809290:
/usr/include/eigen3/Eigen/src/Core/DenseBase.h:416:7: error: static
assertion failed: THIS_EXPRESSION_IS_NOT_A_LVALUE__IT_IS_READ_ONLY
Transition: protofbuf
libprotobuf-lite9v5 (2.6.1-2) -> libprotobuf-lite10 (3.0.0-4)
libprotobuf9v5 (2.6.1-2) -> libprotobuf10 (3.0.0-4)
libprotoc9v5(2.6.1-2) -> libprotoc10(3.0.0-4)
The status of the most recent rebuilds is as follows.
anfo (sid only) (0.98-4) FTBFS
appstream(0.9.8-4) OK
berkeley-express (1.5.1-2) OK
bitcoin (sid only) (0.12.1-0.1 / 0.13.0-0.1~exp1) OK / OK
clementine (1.3.1+dfsg-1) OK
cubemap (1.3.1-1) OK
dogecoin (1.10.0-2) OK
gazebo (7.3.0+dfsg-2) FTBFS
harvest-tools(1.2-2)OK
ignition-transport (1.3.0-1) FTBFS
imposm-parser(1.0.7+ds-3) OK
libphonenumber (7.1.0-4) FTBFS
litecoin (sid only) (0.10.4.0-1) FTBFS
mahimahi (sid only) (0.92-1) FTBFS
mixxx(2.0.0~dfsg-5) OK
mosh (1.2.6-1) OK
mozc (2.18.2595.102+dfsg-1) OK
mumble (1.2.16-2) OK
ola (sid only) (0.10.2-1) FTBFS
osmpbf (1.3.3-7) OK
ostinato (0.8-1)FTBFS
pdns-recursor(4.0.1-1) OK
php-pinba (sid only) (1.0.0-2) OK
pink-pony(1.4.1-2) OK
pokerth (sid
Bug#835170: transition: protobuf
On 08/24/16 13:57, Sebastiaan Couwenberg wrote:
For hurd-i386 a patch is needed to define PATH_MAX, and on kfreebsd-*
the builds fails with:
google/protobuf/stubs/stringpiece_unittest.cc: In member function
'virtual void
google::protobuf::{anonymous}::NonNegativeLenTest_NonNegativeLen_Test::TestBody()':
google/protobuf/stubs/stringpiece_unittest.cc:788:50: error:
'EXPECT_DEATH' was not declared in this scope
EXPECT_DEATH(StringPiece("xyz", -1), "len >= 0");
The attached patch fixes the EXPECT_DEATH failure.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
expect_death.patch
Description: inode/symlink
Bug#835170: transition: protobuf
On 08/23/16 12:07, Sebastiaan Couwenberg wrote:
On 08/23/16 11:32, Sebastiaan Couwenberg wrote:
On s390x, alpha & sparc64 the build fails with:
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_AtomicIncrement(long volatile*,
long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_Store(long volatile*, long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_AtomicExchange(long volatile*,
long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_Load(long const volatile*)'
I've just submitted a patch for the FTBFS on s390x in #835302, that
should fix the last release architecture.
A similar patch is required for alpha & sparc64, which also lack
explicit support for those architectures in atomicops.h. Fortunately
these are not release architectures.
For hurd-i386 a patch is needed to define PATH_MAX, and on kfreebsd-*
the builds fails with:
google/protobuf/stubs/stringpiece_unittest.cc: In member function
'virtual void
google::protobuf::{anonymous}::NonNegativeLenTest_NonNegativeLen_Test::TestBody()':
google/protobuf/stubs/stringpiece_unittest.cc:788:50: error:
'EXPECT_DEATH' was not declared in this scope
EXPECT_DEATH(StringPiece("xyz", -1), "len >= 0");
^
On powerpcspe dh_strip fails with:
Not enough room for program headers
Ideally protobuf 3.0.0 gets fixed on the unofficial ports too, because
2.6.x built successfully there before. But they are not blockers for
this transition as s390x is.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On Wednesday, 24 August 2016 6:08:00 AM AEST Niels Thykier wrote: > Please review https://wiki.debian.org/Teams/ReleaseTeam/Transitions for > the next transition. Most of the preparation can be done in your own > cadence and you can request the slot in parallel with the final > preparation on your side. Duly noted. Thanks for this information, Niels. -- Cheers, Dmitry Smirnov. --- Perhaps is is better to be irresponsible and right, than to be responsible and wrong. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#835170: transition: protobuf
Dmitry Smirnov: > On Tuesday, 23 August 2016 8:51:23 PM AEST Adam D. Barratt wrote: >> That's not an excuse for causing disruption in unstable. > > I'm not sure when it is OK to cause disruption in unstable. For example > uploading new GCC seems to cause a lot of problems despite attempts to > mitigate FTBFS. > GCC transitions are still planned/announced ahead of time (e.g. 5.X -> 6.X) with the release team involved. That way we can plan which transitions are running in parallel with e.g. GCC (or other disruptive transitions). Secondly, in the particular case for GCC. There tends to be a lot of preparation for those. Notably an archive-wide rebuild and bugs filed against all packages that FTBFS with the new version. So while GCC transitions do break more packages on average, they are also coordinated and well-planned. > [...] >> There are other >> packages that need transitions that I'm sure the maintainers also >> believe are "crucial". > > Indeed. Yet protobuf-3 is long overdue and we absolutely must have it as its > absence caused a lot of disruption on its own... > > Apologies for inconvenience. > That is no excuse for not following the procedure. If everyone follows that pattern, unstable will become entirely broken beyond our ability to keep up and fix it. These days we have very fast transitions - among other because: * People test their packages and reverse dependencies ahead of time * They plan the transitions with the release team to avoid smashing existing transitions * Our tooling has vastly improved since "the dark ages". Please review https://wiki.debian.org/Teams/ReleaseTeam/Transitions for the next transition. Most of the preparation can be done in your own cadence and you can request the slot in parallel with the final preparation on your side. Thanks, ~Niels
Bug#835170: [Pkg-protobuf-devel] Bug#835170: transition: protobuf
On Wednesday, 24 August 2016 1:28:32 AM AEST Sebastiaan Couwenberg wrote: > On 08/23/16 16:45, Dmitry Smirnov wrote: > > On Tuesday, 23 August 2016 11:32:10 AM AEST Sebastiaan Couwenberg wrote: > >> protobuf (3.0.0-1) FTBFS pretty much everywhere. :-( > >> > >> Using -Werror may be a bit much based on the buildlogs. > > > > I think it may not be the problem in this particular case... > > I disagree. A patch is for this issue (reported by Aaron M. Ucko in > #835266) is available. Adding -Wno-error=misleading-indentation whenever > -Werror is used solves the FTBFS in my i386 sid chroot. Thank you very much for patch. I will upload it shortly. Unfortunately I'm still unable to reproduce FTBFS in clean pbuilder environment... -- Regards, Dmitry Smirnov. --- Belief means not wanting to know what is true. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#835170: [Pkg-protobuf-devel] Bug#835170: transition: protobuf
Dmitry Smirnov wrote: > On Tuesday, 23 August 2016 8:51:23 PM AEST Adam D. Barratt wrote: > > That's not an excuse for causing disruption in unstable. > > I'm not sure when it is OK to cause disruption in unstable. For example > uploading new GCC seems to cause a lot of problems despite attempts to > mitigate FTBFS. It's a very easy rule for protobuf, since protobuf has a non-trivial set of reverse build-dependencies: every ABI bump for protobuf needs a corresponding, coordinated ABI transition. For previous protobuf transitions (2.5.0, 2.6.0), please review #726165 and #760343. It's not as simple as just uploading a new release to unstable. Probably it should have been uploaded to experimental first, to check that the package would build and pass its test suite on all architectures. (E.g., see #572923 for an example of architecture-specific breakage in protobuf.) > Also do you have a clue why protobuf FTBFS on build servers? I'm unable to > reproduce the problem... I built it on amd64 in an up-to-date sid pbuilder chroot and it failed in the same manner as it did on all the buildd's. -- Robert Edmonds edmo...@debian.org
Bug#835170: transition: protobuf
On Tuesday, 23 August 2016 8:51:23 PM AEST Adam D. Barratt wrote: > That's not an excuse for causing disruption in unstable. I'm not sure when it is OK to cause disruption in unstable. For example uploading new GCC seems to cause a lot of problems despite attempts to mitigate FTBFS. Also do you have a clue why protobuf FTBFS on build servers? I'm unable to reproduce the problem... > There are other > packages that need transitions that I'm sure the maintainers also > believe are "crucial". Indeed. Yet protobuf-3 is long overdue and we absolutely must have it as its absence caused a lot of disruption on its own... Apologies for inconvenience. -- Regards, Dmitry Smirnov. --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#835170: transition: protobuf
On 08/23/16 16:45, Dmitry Smirnov wrote: On Tuesday, 23 August 2016 11:32:10 AM AEST Sebastiaan Couwenberg wrote: protobuf (3.0.0-1) FTBFS pretty much everywhere. :-( Using -Werror may be a bit much based on the buildlogs. I think it may not be the problem in this particular case... I disagree. A patch is for this issue (reported by Aaron M. Ucko in #835266) is available. Adding -Wno-error=misleading-indentation whenever -Werror is used solves the FTBFS in my i386 sid chroot. Kind Regards, Bas
Bug#835170: transition: protobuf
Your upload broke building other packages (for instance, evolution-data-server is currently unbuildable). Could you please apply this patch and push to unstable? Without this patch, protobuf failed to build in my sid sbuild; with it; the build succeeded. Thanks, Jeremy Bicha 0001-Don-t-fail-tests-because-of-misleading-indentation.patch Description: Binary data
Bug#835170: transition: protobuf
On Wed, 2016-08-24 at 00:45 +1000, Dmitry Smirnov wrote: > On Tuesday, 23 August 2016 11:32:10 AM AEST Sebastiaan Couwenberg wrote: > > > Dmitry, have you tested the reverse dependencies if they still build? > > No... We will have to deal with fallout, if any... It is crucial to have > protobuf-3 from life cycle prospective. Also several golang dependencies > require protobuf v3 so upload actually allows to fix numerous problems. That's not an excuse for causing disruption in unstable. There are other packages that need transitions that I'm sure the maintainers also believe are "crucial". Regards, Adam
Bug#835170: transition: protobuf
On Tuesday, 23 August 2016 11:32:10 AM AEST Sebastiaan Couwenberg wrote: > > Dmitry, have you tested the reverse dependencies if they still build? No... We will have to deal with fallout, if any... It is crucial to have protobuf-3 from life cycle prospective. Also several golang dependencies require protobuf v3 so upload actually allows to fix numerous problems. Apologies for inconvenience... > First the many build failures need to be resolved: > > https://buildd.debian.org/status/package.php?p=protobuf I've noticed that but I'm unable to reproduce neither on amd64 not on i386. Even now when GCC 6.2 propagated to my local mirror... I'm completely puzzled by those build failures after spending hours trying to reproduce the problem... > protobuf (3.0.0-1) FTBFS pretty much everywhere. :-( > > Using -Werror may be a bit much based on the buildlogs. I think it may not be the problem in this particular case... Thank you. -- Regards, Dmitry Smirnov. --- Faith: not wanting to know what the truth is. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#835170: transition: protobuf
On 08/23/16 11:32, Sebastiaan Couwenberg wrote:
On 08/23/16 11:10, Bas Couwenberg wrote:
The upload of protobuf (3.0.0-1) to unstable has started an uncoordinated
transition.
Dmitry, have you tested the reverse dependencies if they still build?
I'll test the affected packages maintained by the Debian GIS team and
upload them to unstable if they build successfully. I'd rather not have
to take care of the other affected packages too.
The affected packages maintained by the Debian GIS team all built
successfully with protobuf (3.0.0-1) on amd64:
imposm-parser (1.0.7+ds-3)
osmpbf (1.3.3-6)
imposm (2.6.0+ds-3)
osmium(0.0~20160425-e2e4368-2)
That leaves all the others still to be tested.
First the many build failures need to be resolved:
https://buildd.debian.org/status/package.php?p=protobuf
protobuf (3.0.0-1) FTBFS pretty much everywhere. :-(
Using -Werror may be a bit much based on the buildlogs.
Adding -Wno-error=misleading-indentation may be a quick fix for the
build failures, it's the cause on most architectures.
On s390x, alpha & sparc64 the build fails with:
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_AtomicIncrement(long volatile*,
long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_Store(long volatile*, long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_AtomicExchange(long volatile*, long)'
./.libs/libprotobuf.so: undefined reference to
`google::protobuf::internal::NoBarrier_Load(long const volatile*)'
For hurd-i386 a patch is needed to define PATH_MAX, and on kfreebsd-*
the builds fails with:
google/protobuf/stubs/stringpiece_unittest.cc: In member function
'virtual void
google::protobuf::{anonymous}::NonNegativeLenTest_NonNegativeLen_Test::TestBody()':
google/protobuf/stubs/stringpiece_unittest.cc:788:50: error:
'EXPECT_DEATH' was not declared in this scope
EXPECT_DEATH(StringPiece("xyz", -1), "len >= 0");
^
On powerpcspe dh_strip fails with:
Not enough room for program headers
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
On 08/23/16 11:10, Bas Couwenberg wrote: The upload of protobuf (3.0.0-1) to unstable has started an uncoordinated transition. Dmitry, have you tested the reverse dependencies if they still build? I'll test the affected packages maintained by the Debian GIS team and upload them to unstable if they build successfully. I'd rather not have to take care of the other affected packages too. First the many build failures need to be resolved: https://buildd.debian.org/status/package.php?p=protobuf protobuf (3.0.0-1) FTBFS pretty much everywhere. :-( Using -Werror may be a bit much based on the buildlogs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#835170: transition: protobuf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-protobuf.html The upload of protobuf (3.0.0-1) to unstable has started an uncoordinated transition. Dmitry, have you tested the reverse dependencies if they still build? I'll test the affected packages maintained by the Debian GIS team and upload them to unstable if they build successfully. I'd rather not have to take care of the other affected packages too. Kind Regards, Bas
