Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On Mon, Jan 31, 2022 at 06:49:45AM -0700, Neil Mayhew wrote: > On 2022-01-29 08:59, Neil Mayhew wrote: > > On 2022-01-28 22:33, tony mancill wrote: > > > I noticed that 8.12.42 was released a couple days ago [4]. > > > My thought was to let 8.12.41 transition to testing (5 days) before > > > uploading to unstable again, in case that impacts whether/when Ubuntu > > > picks up the update. Let me know if you know otherwise. > > > > That sounds like the best approach. I don't know the details of how > > Ubuntu picks up the updates, but I have a bug report open with Ubuntu > > and I'll follow up there once 8.12.41 reaches testing. I'll mention that > > you're planning to package 8.12.42 as well. > > Ubuntu already picked up 8.12.41 automatically, so I think you could go > ahead and package 8.12.42 now. Great. I plan to do so this week.
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On 2022-01-29 08:59, Neil Mayhew wrote: On 2022-01-28 22:33, tony mancill wrote: I noticed that 8.12.42 was released a couple days ago [4]. My thought was to let 8.12.41 transition to testing (5 days) before uploading to unstable again, in case that impacts whether/when Ubuntu picks up the update. Let me know if you know otherwise. That sounds like the best approach. I don't know the details of how Ubuntu picks up the updates, but I have a bug report open with Ubuntu and I'll follow up there once 8.12.41 reaches testing. I'll mention that you're planning to package 8.12.42 as well. Ubuntu already picked up 8.12.41 automatically, so I think you could go ahead and package 8.12.42 now. It's helpful that 8.12.42 has a tag which 8.12.41 didn't. Also, the Java artefact IDs have "-SNAPSHOT" removed, so this seems like more of an official release. I noticed that the Java deps were bumped in 9a7be581. However, the bullseye versions still meet or exceed them.
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On Sat, Jan 29, 2022 at 08:59:32AM -0700, Neil Mayhew wrote: > On 2022-01-28 22:33, tony mancill wrote: > > I noticed that 8.12.42 was released a couple days ago [4]. > > My thought was to let 8.12.41 transition to testing (5 days) before > > uploading to unstable again, in case that impacts whether/when Ubuntu > > picks up the update. Let me know if you know otherwise. > > That sounds like the best approach. I don't know the details of how Ubuntu > picks up the updates, but I have a bug report open with Ubuntu and I'll > follow up there once 8.12.41 reaches testing. I'll mention that you're > planning to package 8.12.42 as well. For what it's worth, the 8.12.42 update doesn't do much for Debian and Ubuntu, so I see that as something that can be deferred and or skipped until a more substantial release is available. Particularly if it helps 8.12.41 migrate all the way through... The jar dependency bumps in [1] don't change anything because Debian uses the packaged version of the library and commons-io is already well-past 2.7 [2]. > I see that the mips64el build failed, and it was in the Java part of > the build, with a JRE panic. I don't know much about Java, > unfortunately, so I'm sorry I can't help with that. I believe that was just bad luck, meaning an extant bug in OpenJDK (maybe only on Zero), or at least not caused by libphonenumber. > Can 8.12.41 still transition to testing even with mips64el failing? No. I have already given it back for a rebuild and will keep an eye on it and mipsel. Cheers, tony [1] https://github.com/google/libphonenumber/commit/9a7be5813db8c0713c111d1c5735c777ce3838f1 [2] https://tracker.debian.org/pkg/commons-io signature.asc Description: PGP signature
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On 2022-01-28 22:33, tony mancill wrote: I noticed that 8.12.42 was released a couple days ago [4]. My thought was to let 8.12.41 transition to testing (5 days) before uploading to unstable again, in case that impacts whether/when Ubuntu picks up the update. Let me know if you know otherwise. That sounds like the best approach. I don't know the details of how Ubuntu picks up the updates, but I have a bug report open with Ubuntu and I'll follow up there once 8.12.41 reaches testing. I'll mention that you're planning to package 8.12.42 as well. I see that the mips64el build failed, and it was in the Java part of the build, with a JRE panic. I don't know much about Java, unfortunately, so I'm sorry I can't help with that. Can 8.12.41 still transition to testing even with mips64el failing?
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On Fri, Jan 28, 2022 at 09:42:43PM -0700, Neil Mayhew wrote: > On 2022-01-28 08:29, Neil Mayhew wrote: > > It looks like geocoding_data.cc is truncated and my working hypothesis > > is that it's still in the process of being generated, which in turn is > > due to race condition in the parallel build. This could explain why it > > built successfully on some architectures and not others. > > I'm able to reproduce the build failure in a non-Debian build on my local > machine with -j16. I can confirm that this is due to a race condition in the > build. The generated source file is created three times in parallel by > different make threads, and one of those threads tries to compile it while > another thread is in the middle of rewriting it. > > Based on some info in the cmake documentation[1] I think this is a bug in > the way the build is defined: > >> Do not list the output in more than one independent target that may build >> in parallel or the two instances of the rule may conflict > > [1]: https://cmake.org/cmake/help/latest/command/add_custom_command.html Thank you for getting to the bottom of it and sharing your findings. > I'll work with upstream to get this fixed. In the meantime, I'm confident > that using parallel=1 in the Debian build is the right solution for the > package. Cool. I gave it a try in [2] and bit the builds look good so far [3]. The mipsel64 build was (perhaps ironically) successfully with the prior upload, so I am confident too. I will (re)close the bug once those mipsel builds complete. > Thanks very much for working to get this release packaged. Glad to be of assistance. It was fortunate that abseil [4] is already packaged for Debian, and that libphonenumber does appear to require a more recent version of it. By the way, I noticed that 8.12.42 was released a couple days ago [4]. My thought was to let 8.12.41 transition to testing (5 days) before uploading to unstable again, in case that impacts whether/when Ubuntu picks up the update. Let me know if you know otherwise. Cheers, tony [2] https://salsa.debian.org/debian/libphonenumber/-/commit/aa17dbeb4bbac77ca9cd109101a8a1e1a2514858 [3] https://buildd.debian.org/status/package.php?p=libphonenumber [4] https://tracker.debian.org/pkg/abseil signature.asc Description: PGP signature
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On 2022-01-28 08:29, Neil Mayhew wrote: It looks like geocoding_data.cc is truncated and my working hypothesis is that it's still in the process of being generated, which in turn is due to race condition in the parallel build. This could explain why it built successfully on some architectures and not others. I'm able to reproduce the build failure in a non-Debian build on my local machine with -j16. I can confirm that this is due to a race condition in the build. The generated source file is created three times in parallel by different make threads, and one of those threads tries to compile it while another thread is in the middle of rewriting it. Based on some info in the cmake documentation[1] I think this is a bug in the way the build is defined: > Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict [1]: https://cmake.org/cmake/help/latest/command/add_custom_command.html I'll work with upstream to get this fixed. In the meantime, I'm confident that using parallel=1 in the Debian build is the right solution for the package. Thanks very much for working to get this release packaged.
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On 2022-01-28 09:23, tony mancill wrote: I'm considering setting parallel=1 for the next upload. Thoughts? I think that's a good idea. I seems likely there's a bug in the CMakeLists.txt that fails to express a dependency on the code generation step, and this is a good workaround for now. If the builders are successful with a non-parallel build I can investigate this with less urgency.
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On Fri, Jan 28, 2022 at 08:29:36AM -0700, Neil Mayhew wrote:
> On 2022-01-28 07:59, tony mancill wrote:
> > it is surprising to see it fail with this:
> > > /<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:13:
> > > error: ‘i18n::phonenumbers::{anonymous}::prefix_86_zh_descriptions’
> > > defined but not used [-Werror=unused-variable]
> > > 787278 | const char* prefix_86_zh_descriptions[] = {
> > >| ^
> > > cc1plus: all warnings being treated as errors
> > > make[3]: *** [CMakeFiles/geocoding-shared.dir/build.make:353:
> > > CMakeFiles/geocoding-shared.dir/src/phonenumbers/geocoding/geocoding_data.cc.o]
> > > Error 1
>
> That's not the original error, which is this:
>
> > [ 35%] Building CXX object
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o
> > /usr/bin/c++ -DI18N_PHONENUMBERS_USE_ALTERNATE_FORMATS
> > -DI18N_PHONENUMBERS_USE_ICU_REGEXP
> > -DI18N_PHONENUMBERS_USE_TR1_UNORDERED_MAP -I/<>/cpp/src
> > -I/<>/cpp/test -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wall -Werror -std=gnu++11 -MD -MT
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -MF
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o.d -o
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -c
> > /<>/cpp/src/phonenumbers/logger.cc
> > /<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:888498:
> > error: expected ‘}’ at end of input
> > 888498 |
> > "\xe5""\x9b""\x9b""\xe5""\xb7""\x9d""\xe7""\x9c""\x81""\xe8""\x87""\xaa""\xe8""\xb4""\xa1""\xe5""\xb8""\x82",
> > |
> > /<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:43:
> > note: to match this ‘{’
> > 787278 | const char* prefix_86_zh_descriptions[] = {
> > | ^
>
> It looks like geocoding_data.cc is truncated and my working hypothesis is
> that it's still in the process of being generated, which in turn is due to
> race condition in the parallel build. This could explain why it built
> successfully on some architectures and not others.
Got it - thank you. I checked and the amd64 buildd is using
DEB_BUILD_OPTIONS=parallel=4 whereas my local build uses parallel=8.
Since I'm not able to reproduce locally, I'm considering setting
parallel=1 for the next upload. Thoughts?
Thank you,
tony
signature.asc
Description: PGP signature
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On 2022-01-28 07:59, tony mancill wrote:
it is surprising to see it fail with this:
/<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:13:
error: ‘i18n::phonenumbers::{anonymous}::prefix_86_zh_descriptions’ defined but not used
[-Werror=unused-variable]
787278 | const char* prefix_86_zh_descriptions[] = {
| ^
cc1plus: all warnings being treated as errors
make[3]: *** [CMakeFiles/geocoding-shared.dir/build.make:353:
CMakeFiles/geocoding-shared.dir/src/phonenumbers/geocoding/geocoding_data.cc.o]
Error 1
That's not the original error, which is this:
[ 35%] Building CXX object
CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o
/usr/bin/c++ -DI18N_PHONENUMBERS_USE_ALTERNATE_FORMATS -DI18N_PHONENUMBERS_USE_ICU_REGEXP
-DI18N_PHONENUMBERS_USE_TR1_UNORDERED_MAP -I/<>/cpp/src -I/<>/cpp/test
-pthread -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -fPIC -Wall -Werror -std=gnu++11 -MD -MT
CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -MF
CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o.d -o
CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -c /<>/cpp/src/phonenumbers/logger.cc
/<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:888498:
error: expected ‘}’ at end of input
888498 |
"\xe5""\x9b""\x9b""\xe5""\xb7""\x9d""\xe7""\x9c""\x81""\xe8""\x87""\xaa""\xe8""\xb4""\xa1""\xe5""\xb8""\x82",
|
/<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:43:
note: to match this ‘{’
787278 | const char* prefix_86_zh_descriptions[] = {
| ^
It looks like geocoding_data.cc is truncated and my working hypothesis
is that it's still in the process of being generated, which in turn is
due to race condition in the parallel build. This could explain why it
built successfully on some architectures and not others.
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
On Thu, Jan 27, 2022 at 10:55:15PM -0700, Neil Mayhew wrote:
> I saw the build errors. I think I've seen them before in local dev, and I
> think they're to do with parallel builds. The file with the compilation
> error is a generated file, and I think make is trying to compile it before
> it's fully generated. I'll investigate tomorrow.
Thank you. I am looking too. I built repeatedly in a clean sid chroot
using sbuild with no observed flakiness or failures. Which is to say,
my local builds should be quite similar to what's happening on the
buildds, so it is surprising to see it fail with this:
> /<>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:13:
> error: ‘i18n::phonenumbers::{anonymous}::prefix_86_zh_descriptions’ defined
> but not used [-Werror=unused-variable]
> 787278 | const char* prefix_86_zh_descriptions[] = {
> | ^
> cc1plus: all warnings being treated as errors
> make[3]: *** [CMakeFiles/geocoding-shared.dir/build.make:353:
> CMakeFiles/geocoding-shared.dir/src/phonenumbers/geocoding/geocoding_data.cc.o]
> Error 1
BTW, I used ratt to rebuild all of the reverse dependencies, save for a
few gnome packages that are broken anyway, and libreoffice (for which
I'm going to need to tweak my sbuild setup; it runs out of disk). And I
installed the resulting binary and checked that geany (one of the
r-deps) still runs. So hopefully once this is resolved, the package is
good and will transition to testing without delay.
Thanks,
tony
signature.asc
Description: PGP signature
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
I saw the build errors. I think I've seen them before in local dev, and I think they're to do with parallel builds. The file with the compilation error is a generated file, and I think make is trying to compile it before it's fully generated. I'll investigate tomorrow.
