Debian Bug report logs - #819530
transition: icu

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Laszlo Boszormenyi (GCS)" <gcs@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: transition: icu

Date: Wed, 30 Mar 2016 07:38:58 +0200

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

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.

As it affects the system from Boost C++ libraries (several packages
build depends on it) to LibreOffice, it's not uploaded to experimental
even. But my local build tests on amd64 shows that Boost 1.58 could be
built and transiently some packages that build depends on Boost.
The biggest one is LibreOffice which could be built of course. In
short, I compiled ICU 57.1 and installed it -> compiled and installed
Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.
May I proceed with the upload, targeting experimental first?

Regards,
Laszlo/GCS
[1] http://cldr.unicode.org/index
[2] http://cldr.unicode.org/index/downloads/cldr-28
[3] http://cldr.unicode.org/index/downloads/cldr-29
[4] http://www.unicode.org/versions/Unicode8.0.0/#Summary

Message #10 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: "Laszlo Boszormenyi (GCS)" <gcs@debian.org>, 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Wed, 30 Mar 2016 14:09:48 +0200

On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote:
> Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.

Including the tests?

But then again, the broken help on the last transition and the crashes
in some other one before that were not catched by the tests either ;)

I asked, noone tried with 57 yet for LO.

> May I proceed with the upload, targeting experimental first?

Not from the RT, but...

Well, uploading to experimental is fine anytime I think, that also has
the advantage that you already cleared NEW when this is supposed to start
in unstable.

And people can try with experimental.

Regards,

Rene

Message #15 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Rene Engelhard <rene@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Wed, 30 Mar 2016 14:46:02 +0200

On Wed, Mar 30, 2016 at 2:09 PM, Rene Engelhard <rene@debian.org> wrote:
> On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote:
>> Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.
>
> Including the tests?
 I did the tests in a chroot, without any shell environmental
settings. If the tests are run automatically, then yes. Sorry, my
computer is such slow I just started the building and left it alone
for several hours (stopped all daemons and only the console was used).
As far as I can remember, this time it was more quicker, built the
debs after eleven hours or so. But I still have the build log
somewhere, will check that and report back.

> But then again, the broken help on the last transition and the crashes
> in some other one before that were not catched by the tests either ;)
>
> I asked, noone tried with 57 yet for LO.
 That's why I would like to be extra safe - don't want to cause any
trouble if you do any testing / transition in experimental already.

>> May I proceed with the upload, targeting experimental first?
>
> Not from the RT, but...
>
> Well, uploading to experimental is fine anytime I think, that also has
> the advantage that you already cleared NEW when this is supposed to start
> in unstable.
 Sure. The first step would be to binNMU Boost 1.58 as itself is
build-depends on ICU.

> And people can try with experimental.
 Do you have a local test environment for LibreOffice for example?
Say, some big and/or Chinese document to open and test?

Regards,
Laszlo/GCS

Message #20 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Rene Engelhard <rene@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Wed, 30 Mar 2016 18:26:05 +0200

On Wed, Mar 30, 2016 at 2:09 PM, Rene Engelhard <rene@debian.org> wrote:
> On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote:
>> Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.
>
> Including the tests?
 Ah, checked the build log[1] and the tests were not run this time.
Maybe that's the reason it finished in eleven hours now. Root cause
seems to be this test:
$ /usr/lib/jvm/default-java/bin/java -version 2>&1 | tail -n 1 | awk
'{ print $$1 }'
/usr/lib/jvm/default-java/bin/java: error while loading shared
libraries: libjli.so: cannot open shared object file: No such file or
directory

I still have the dirty package directory, will try to run all the
tests as just fixed the runtime library linking for Java 8.

Cheers,
Laszlo/GCS
[1] wget http://www.barcikacomp.hu/gcs/libreoffice_5.1.2~rc1-1_amd64.build.gz

Message #25 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Rene Engelhard <rene@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Thu, 31 Mar 2016 08:27:20 +0200

Hi Rene,

On Wed, Mar 30, 2016 at 2:09 PM, Rene Engelhard <rene@debian.org> wrote:
> On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote:
>> Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.
>
> Including the tests?
 It seems the tests are OK. I got hundreds of lines like:
-- cut --
[SLC] unoxml
[SLC] writerfilter
[SLC] writerperfect
[PKG] instsetoo_native_setup
[CUS] postprocess/images
[CHK] odk
[CUT] services
[CHK] sal
[BIN] instsetoo_native
[BIN] postprocess
[CHK] dbaccess
[GAL] arrows
[GAL] computers
-- cut --

But I don't know the color codes and abbreviation meaning. The only
errors I get:
-- cut --
[CUT] sc_condformats
No protocol specified
W: Unknown node under /registry/extlang: deprecated
W: Unknown node under /registry/grandfathered: comments
W: Unknown node under /registry/grandfathered: comments
No protocol specified
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

Failures !!!
Run: 1   Failure total: 1   Failures: 0   Errors: 1

Error: a unit test failed, please do one of:
make CppunitTest_cppcanvas_emfplus CPPUNITTRACE="gdb --args"
    # for interactive debugging on Linux
make CppunitTest_cppcanvas_emfplus VALGRIND=memcheck
    # for memory checking
make CppunitTest_cppcanvas_emfplus DEBUGCPPUNIT=TRUE
    # for exception catching

[builddir]/libreoffice-5.1.2~rc1/solenv/gbuild/CppunitTest.mk:90:
recipe for target
'[builddir]/libreoffice-5.1.2~rc1/workdir/CppunitTest/cppcanvas_emfplus.test'
failed
make[1]: *** [[builddir]/libreoffice-5.1.2~rc1/workdir/CppunitTest/cppcanvas_emfplus.test]
Error 1
[CUT] sc_new_cond_format_api
-- cut --

It _seems_ test suite problems like 'no protocol specified', 'invalid
number of arguments' and not failures of the tests itself. But if you
know more, please share it with me.

As Boost C++ library 1.60 is in NEW[1], do you have experience with
it? I think it would be better to wait until it's accepted and re-run
my tests with ICU 57.1 version. What do you think?

Regards,
Laszlo/GCS
[1] https://ftp-master.debian.org/new/boost1.60_1.60.0%2Bdfsg-1.html

Message #30 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Thu, 31 Mar 2016 09:28:13 +0200

Hi,

On Thu, Mar 31, 2016 at 08:27:20AM +0200, László Böszörményi (GCS) wrote:
>  It seems the tests are OK. I got hundreds of lines like:

OK.

> [builddir]/libreoffice-5.1.2~rc1/solenv/gbuild/CppunitTest.mk:90:
> recipe for target
> '[builddir]/libreoffice-5.1.2~rc1/workdir/CppunitTest/cppcanvas_emfplus.test'
> failed
> make[1]: *** [[builddir]/libreoffice-5.1.2~rc1/workdir/CppunitTest/cppcanvas_emfplus.test]
> Error 1

unset DISPLAY. debian/rules already does that[1] and that fixed it for me
so I wonder why you got it. ran make check manually or so?

> It _seems_ test suite problems like 'no protocol specified', 'invalid
> number of arguments' and not failures of the tests itself. But if you
> know more, please share it with me.

Yep.

> 
> As Boost C++ library 1.60 is in NEW[1], do you have experience with

Nope

> it? I think it would be better to wait until it's accepted and re-run
> my tests with ICU 57.1 version. What do you think?

The main usage of boost is the headers (and ttbomk date-time and system
- and filesystem in 5.2 - shouldn't be affected by ICU changes, should it?)
Of course you never know.

But I guess the RT will not want to have a boost and a icu transition at the
same time anyway, so...

Regards,

Rene

[1] http://anonscm.debian.org/cgit/pkg-openoffice/libreoffice.git/commit/?id=e3430f742f8c0e572af50051da836e3d9877338f
> 
> Regards,
> Laszlo/GCS
> [1] https://ftp-master.debian.org/new/boost1.60_1.60.0%2Bdfsg-1.html

Message #35 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Rene Engelhard <rene@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Thu, 31 Mar 2016 20:25:59 +0200

On Thu, Mar 31, 2016 at 9:28 AM, Rene Engelhard <rene@debian.org> wrote:
> On Thu, Mar 31, 2016 at 08:27:20AM +0200, László Böszörményi (GCS) wrote:
> unset DISPLAY. debian/rules already does that[1] and that fixed it for me
> so I wonder why you got it. ran make check manually or so?
 Yes, 'make check' was issued by hand in a previously built tree.
After I unset DISPLAY before the tests, all passed successfully. A
full build takes about half a day on my machine if I stop everything
and use console only.

>> it? I think it would be better to wait until it's accepted and re-run
>> my tests with ICU 57.1 version. What do you think?
>
> The main usage of boost is the headers (and ttbomk date-time and system
> - and filesystem in 5.2 - shouldn't be affected by ICU changes, should it?)
> Of course you never know.
 Boost C++ libraries also build depends on ICU.

> But I guess the RT will not want to have a boost and a icu transition at the
> same time anyway, so...
 Well, it wouldn't be a parallel transition in the traditional sense
due to the following:
- Boost 1.60 targets _Sid_,
- until boost-defaults (separate source package) is not updated,
packages will not even know 1.60,
- ICU 57.1 would target _experimental_.

Thanks for the help,
Laszlo/GCS

Message #40 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Jonathan Wiltshire <jmw@debian.org>

To: "Laszlo Boszormenyi (GCS)" <gcs@debian.org>, 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Sun, 03 Apr 2016 12:43:34 +0100

Control: tag -1 moreinfo

On 2016-03-30 06:38, Laszlo Boszormenyi (GCS) wrote:
> May I proceed with the upload, targeting experimental first?

Within reason you can do what you like in experimental; come back when 
you want to do the transition into Stretch.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

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

Message #47 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: "Laszlo Boszormenyi (GCS)" <gcs@debian.org>, 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Thu, 21 Jul 2016 19:02:36 +0200

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

Message #52 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Fri, 22 Jul 2016 07:26:15 +0000

Hi Emilio,

On Thu, Jul 21, 2016 at 5:02 PM, Emilio Pozuelo Monfort
<pochu@debian.org> wrote:
> 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?
 Back in time I had big hardware problems and only tested LibreOffice,
which was successful. HW issues is softened by Martin F. Krafft and
Jeffrey Walton since DebConf'16. Catching up with my backlog and the
big rebuild session planned to this weekend.
Meanwhile Ubuntu took my ICU package from experimental and made it
default without any additional patch to their upcoming Yakkety Yak
release[1]. This is a good sign that it doesn't have any problem, but
better to wait my own results. Is amd64 / i386 rebuilds enough or
should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?

Cheers,
Laszlo/GCS
[1] https://launchpad.net/ubuntu/yakkety/+source/icu

Message #57 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Fri, 22 Jul 2016 10:34:30 +0200

On 22/07/16 09:26, László Böszörményi (GCS) wrote:
> Hi Emilio,
> 
> On Thu, Jul 21, 2016 at 5:02 PM, Emilio Pozuelo Monfort
> <pochu@debian.org> wrote:
>> 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?
>  Back in time I had big hardware problems and only tested LibreOffice,
> which was successful. HW issues is softened by Martin F. Krafft and
> Jeffrey Walton since DebConf'16. Catching up with my backlog and the
> big rebuild session planned to this weekend.

Ok, cool.

> Meanwhile Ubuntu took my ICU package from experimental and made it
> default without any additional patch to their upcoming Yakkety Yak
> release[1]. This is a good sign that it doesn't have any problem, but
> better to wait my own results. Is amd64 / i386 rebuilds enough or
> should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?

Just one architecture is enough. Of course if you can / want to test in more,
that's fine.

Cheers,
Emilio

Message #62 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Mon, 25 Jul 2016 08:48:47 +0200

On Fri, Jul 22, 2016 at 10:34 AM, Emilio Pozuelo Monfort
<pochu@debian.org> wrote:
> On 22/07/16 09:26, László Böszörményi (GCS) wrote:
>>  Back in time I had big hardware problems and only tested LibreOffice,
>> which was successful. HW issues is softened by Martin F. Krafft and
>> Jeffrey Walton since DebConf'16. Catching up with my backlog and the
>> big rebuild session planned to this weekend.
>
> Ok, cool.
 With the help of the mentioned two persons, I was able to start the
ICU transition in merit locally.

>> Meanwhile Ubuntu took my ICU package from experimental and made it
>> default without any additional patch to their upcoming Yakkety Yak
>> release[1]. This is a good sign that it doesn't have any problem, but
>> better to wait my own results. Is amd64 / i386 rebuilds enough or
>> should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?
>
> Just one architecture is enough. Of course if you can / want to test in more,
> that's fine.
 I could do 100 compilations the following way. Up-to-date pbuilder
chroots were used for both amd64 and i386, meaning 50 packages
rebuilt:
- first ICU 57.1 itself still buildable for Sid,
- then dependency level 1 was transitioned,
- dependency level 2 was not able to transition without the boost1.58
transitioned itself,
- after this I chose to transition boost1.60 and as libxml2 also
needed for some builds, I transitioned that as well,
- then level 2 could transition except nodejs, see below,
- started level 3, for the time being I tested cyrus-imapd and php7.0
successfully.

The nodejs issue is reproduced in a clean Sid chroot. The problem lies
in one of its self-tests trying to reach a non-existent domain. If
internet - DNS - access is possible, the test get 'ENOTFOUND' as it
excepts. But in my rebuild chroots not even DNS access was allowed,
meaning the error code became 'EAI_AGAIN' (ie. no DNS could be
reached, try again later). This was the reason of the assert and thus
FTBFS; just for the record it's in
test/parallel/test-net-better-error-messages-port-hostname.js:11:10.

As you were right and mentioned my transition history in our
discussion at DebConf'16, please feel free to raise any questions you
may have. I'm also open to do any additional tests you ask for.

Cheers,
Laszlo/GCS

Message #67 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Mon, 25 Jul 2016 18:08:28 +0200

On 25/07/16 08:48, László Böszörményi (GCS) wrote:
> On Fri, Jul 22, 2016 at 10:34 AM, Emilio Pozuelo Monfort
> <pochu@debian.org> wrote:
>> On 22/07/16 09:26, László Böszörményi (GCS) wrote:
>>>  Back in time I had big hardware problems and only tested LibreOffice,
>>> which was successful. HW issues is softened by Martin F. Krafft and
>>> Jeffrey Walton since DebConf'16. Catching up with my backlog and the
>>> big rebuild session planned to this weekend.
>>
>> Ok, cool.
>  With the help of the mentioned two persons, I was able to start the
> ICU transition in merit locally.
> 
>>> Meanwhile Ubuntu took my ICU package from experimental and made it
>>> default without any additional patch to their upcoming Yakkety Yak
>>> release[1]. This is a good sign that it doesn't have any problem, but
>>> better to wait my own results. Is amd64 / i386 rebuilds enough or
>>> should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?
>>
>> Just one architecture is enough. Of course if you can / want to test in more,
>> that's fine.
>  I could do 100 compilations the following way. Up-to-date pbuilder
> chroots were used for both amd64 and i386, meaning 50 packages
> rebuilt:
> - first ICU 57.1 itself still buildable for Sid,
> - then dependency level 1 was transitioned,
> - dependency level 2 was not able to transition without the boost1.58
> transitioned itself,
> - after this I chose to transition boost1.60 and as libxml2 also
> needed for some builds, I transitioned that as well,
> - then level 2 could transition except nodejs, see below,
> - started level 3, for the time being I tested cyrus-imapd and php7.0
> successfully.
> 
> The nodejs issue is reproduced in a clean Sid chroot. The problem lies
> in one of its self-tests trying to reach a non-existent domain. If
> internet - DNS - access is possible, the test get 'ENOTFOUND' as it
> excepts. But in my rebuild chroots not even DNS access was allowed,
> meaning the error code became 'EAI_AGAIN' (ie. no DNS could be
> reached, try again later). This was the reason of the assert and thus
> FTBFS; just for the record it's in
> test/parallel/test-net-better-error-messages-port-hostname.js:11:10.

That shouldn't block the transition. FWIW I see #830242 and #831243 opened aobut
this.

Please let us know the results once you have built the rest of the rdeps. If
things look good, we can start this very soon.

Cheers,
Emilio

Message #72 received at 819530@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Mon, 1 Aug 2016 09:14:21 +0200

On Mon, Jul 25, 2016 at 6:08 PM, Emilio Pozuelo Monfort
<pochu@debian.org> wrote:
> On 25/07/16 08:48, László Böszörményi (GCS) wrote:
>> The nodejs issue is reproduced in a clean Sid chroot. The problem lies
>> in one of its self-tests trying to reach a non-existent domain. If
>> internet - DNS - access is possible, the test get 'ENOTFOUND' as it
>> excepts. But in my rebuild chroots not even DNS access was allowed,
>> meaning the error code became 'EAI_AGAIN' (ie. no DNS could be
>> reached, try again later). This was the reason of the assert and thus
>> FTBFS; just for the record it's in
>> test/parallel/test-net-better-error-messages-port-hostname.js:11:10.
>
> That shouldn't block the transition. FWIW I see #830242 and #831243 opened aobut
> this.
 It's a different issue, but the same kind: network access. I don't
know if I may put my JavaScript Maintainer hat on and fix these or
just go with the ICU transition...

> Please let us know the results once you have built the rest of the rdeps. If
> things look good, we can start this very soon.
 Kudos to Martin and Jeffrey I could finish the transition locally on
i386, amd64 rebuilds still going on. Despite the updated hardware,
some packages still need several hours to compile. :-/
The transition page[1] currently not available, but what I've learnt:
1) level 1 rdeps can be binNMUed,
2) there should be a level 1.5 rdeps binNMU with libxml2, boost1.58
and boost1.60,
3) remainder of level 2 rdeps can go as is,
4) there will be FTBFS of some packages, details below,
5) I only finished i386 rebuilds, amd64 transitioned packages to level
4 and I do continue with the remaining ones,
6) HHVM which is amd64 only also transitioned successfully.

0ad will fails as it looks for Python 2, but it's not in its build
depends. Previously probably dh-python pulled it in, but it's Python 3
for a while - Python 2 is no longer installed.

gnustep-base fails because of network access in
Tests/base/NSURLHandle/test00.m :
test00[10563:10563] Load failed: further tests may fail.  Reason:
Unable to connect to www.gnustep.org:80 ... No such file or directory

Not a build failure, but during the transition of gnustep-gui I've
seen this warning:
dh_installdocs: WARNING: --link-doc between architecture all and not
all packages breaks binNMUs

haskell-blogliterately fails due to a Haskell stack problem, the build
dependencies can't be installed:
libghc-pandoc-dev : Depends: libghc-juicypixels-dev-3.2.7.2-81d4d
which is a virtual package and is not provided by any available
package

openjfx fails due to a long shell command line:
-- cut --
make[4]: Entering directory
'/build/openjfx-8u102-b14/modules/web/build/linux/Release/WebCore'
make[4]: execvp: /bin/sh: Argument list too long
Makefile.TargetJava:7704: recipe for target 'obj/jfxwebkit.gch/c++' failed
make[4]: *** [obj/jfxwebkit.gch/c++] Error 127
[...]
* Where:
Build file '/build/openjfx-8u102-b14/build.gradle' line: 2541

* What went wrong:
Execution failed for task ':web:compileNativeLinux'.
> Process 'command 'perl'' finished with non-zero exit value 2
-- cut --

frog fails with:
-- cut --
libtool: link: g++ -DSYSCONF_PATH=\"/etc\"
-DPYTHONDIR=\"/usr/lib/python2.7/dist-packages/frog\" -std=c++0x -g
-O2 -fstack-protector-strong -Wformat -Werror=format-security -fopenmp
-I/usr/include/libxml2 -I/usr/include -I/usr/include/libxml2 -fopenmp
-I/usr/include/libxml2 -I/usr/include/libxml2 -I/usr/include/libxml2
-I/usr/include/libxml2 -I/usr/include/python2.7 -Wl,-z -Wl,relro -o
.libs/frog Frog.o  ./.libs/libfrog.so -lucto -lfolia -lmbt
-ltimblserver -lticcutils -ltimbl -L/usr/lib/i386-linux-gnu -licui18n
-licuuc -licudata -licuio -lxml2 -L/usr/lib -lpython2.7 -fopenmp
/usr/lib/libmbt.so: undefined reference to
`TiCC::split_at(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
/usr/lib/libmbt.so: undefined reference to
`TiCC::split_at_first_of(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
-- cut --
The mentioned library and functions come from the mbt package, maybe
an uncoordinated transition of an other package?

yi would fail due to a hidden ICU dependency of a module in
haskell-yi-rope , which needs to be binNMUed before.

Other packages are fine. Please advise other tests if needed.

Regards,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-icu.html

Message #77 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Mon, 1 Aug 2016 18:49:50 +0200

Control: tags -1 confirmed

On 01/08/16 09:14, László Böszörményi (GCS) wrote:
> Not a build failure, but during the transition of gnustep-gui I've
> seen this warning:
> dh_installdocs: WARNING: --link-doc between architecture all and not
> all packages breaks binNMUs

Please file an RC bug for this.

> haskell-blogliterately fails due to a Haskell stack problem, the build
> dependencies can't be installed:
> libghc-pandoc-dev : Depends: libghc-juicypixels-dev-3.2.7.2-81d4d
> which is a virtual package and is not provided by any available
> package
> 
> openjfx fails due to a long shell command line:
> -- cut --
> make[4]: Entering directory
> '/build/openjfx-8u102-b14/modules/web/build/linux/Release/WebCore'
> make[4]: execvp: /bin/sh: Argument list too long

Please file an RC bug.

> frog fails with:
[...]
> The mentioned library and functions come from the mbt package, maybe
> an uncoordinated transition of an other package?

No idea. Can you file a bug against frog?

> Other packages are fine. Please advise other tests if needed.

Let's start this.

Cheers,
Emilio

Message #96 received at 819530@bugs.debian.org (full text, mbox, reply):

From: nisse@lysator.liu.se (Niels Möller)

To: 819530@bugs.debian.org

Subject: Bad interation with libstdc++ transition.

Date: Wed, 26 Oct 2016 22:39:08 +0200

Hi,

as a user, I experience a pretty bad interaction between this transition
and the recent libstdc++ transition.

I have a system with a mix of packages from stable and testing, which
usually works fine. However, upgrading to the latest libstdc++ at this
point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
don't fully understand, I usually don't care much about C++). What I see
is that apt-get install -t testing libstdc++6 would have to uninstall
*lots* of stuff, including build-essential, texlive, libreoffice and
most of kde. So I don't want to do that at this time.

Directly broken packages on my system are

$ aptitude search -F '%c %p %V' '?and(?installed,?reverse-breaks(?and(?name("libstdc\\+\\+6$"),?version("6\\.2\\..*"))))'
i libboost-date-time1.55.0 1.55.0+dfsg-3 
i libkolabxml1             1.0.2-2       
i libreoffice-core         1:4.3.3-2+deb8
i libstdc++6               4.9.2-10      
i libstdc++6:i386            

This is the background, and now I would like to upgrade to libicu57,
because that blocks upgrade of wget, making it a "kept back" packet.
Dependency chain: wget-1.18 -> libpsl5 -> libicu57.

Now the interesting part: libicu57 has a dependency on libstdc++6 (>=
5.2). So it doesn't need gcc-6, gcc-5 is good enough. But the
libstdc++6 packages for gcc-5 are no longer in the archive, the only
versions available as far as I can find are 4.9.2-10 (which I have
installed), and 6.2.0-6, and the latter one breaks half of the world, as
described above. And then non-existence of version 5.x (x >= 2) of
libstdc++6 makes the libicu upgrade depend on upgrading libstdc++6 to
gcc-6, even though it shouldn' have to.

I've looked at the mirror I use, I'd expect libstdc++6 version 5.x to be
located in main/g/gcc-5/, but it's not there. I don't really understand
the process, but I guess the packages were deleted when gcc-6 migrating
to testing?

I don't know what to do about it, maybe it is an issue for the release
team, but I though I should raise the problem here first. To untangle
the transitions, one would need an libicu57 with a libstdc++6 dependency
which can be satisfied by some package which (i) is older than gcc-6 and
(ii) is actually installable from the package archive. Options I see
(not sure what's possible):

* Recompile libicu57 with gcc-4. 

* Resurrect gcc-5 libstdc++6 library packages in the archive.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. 
Internet email is subject to wholesale government surveillance.

Message #101 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Niels Möller <nisse@lysator.liu.se>, 819530@bugs.debian.org

Subject: Re: Bug#819530: Bad interation with libstdc++ transition.

Date: Thu, 27 Oct 2016 00:47:48 +0300

On Wed, Oct 26, 2016 at 10:39:08PM +0200, Niels Möller wrote:
> Hi,
> 
> as a user, I experience a pretty bad interaction between this transition
> and the recent libstdc++ transition.
> 
> I have a system with a mix of packages from stable and testing, which
> usually works fine. However, upgrading to the latest libstdc++ at this
> point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
> don't fully understand, I usually don't care much about C++). What I see
> is that apt-get install -t testing libstdc++6 would have to uninstall
> *lots* of stuff, including build-essential, texlive, libreoffice and
> most of kde. So I don't want to do that at this time.
>...

This sounds like a problem in apt to me, and I've seen issues like
that before.

What does apt say for
  apt-get install -t testing libstdc++6 build-essential
?

If it gives an error, manually add the packages it cannot install on the 
commandline, until you either found the actual dependency problem or apt
found a way forward.

When apt found a way forward, and if it still wants to remove packages 
you want to keep, also add them on the commandline.

> Regards,
> /Niels

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #106 received at 819530@bugs.debian.org (full text, mbox, reply):

From: nisse@lysator.liu.se (Niels Möller)

To: Adrian Bunk <bunk@stusta.de>

Cc: 819530@bugs.debian.org

Subject: Re: Bug#819530: Bad interation with libstdc++ transition.

Date: Thu, 27 Oct 2016 07:43:41 +0200

Adrian Bunk <bunk@stusta.de> writes:

> This sounds like a problem in apt to me, and I've seen issues like
> that before.
>
> What does apt say for
>   apt-get install -t testing libstdc++6 build-essential
> ?

The following packages have unmet dependencies:
 perl : Depends: perl-base (= 5.20.2-3+deb8u6) but 5.24.1~rc3-3 is to be installed
        Depends: perl-modules (>= 5.20.2-3+deb8u6)
        Recommends: rename but it is not going to be installed
 perl-base : Breaks: perl (< 5.24.1~rc3~) but 5.20.2-3+deb8u6 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

> If it gives an error, manually add the packages it cannot install on the 
> commandline, until you either found the actual dependency problem or apt
> found a way forward.

If I add perl too, it's back to uninstalling kde.

> When apt found a way forward, and if it still wants to remove packages 
> you want to keep, also add them on the commandline.

I tried that earlier, but gave up since the number of dependency
problems just seemed to grow. But if I keep doing that, without giving
up, I eventually find a resolution not uninstalling lots of packages
by using

apt-get install -t testing libstdc++6 build-essential perl kde-standard \
  juk libtag1v5 libtag1v5-vanilla akregator kio libkf5libkdepim-plugins \
  libkf5libkdepim5 libkf5wallet5 libkwalletbackend5-5 libkf5notifications5 \
  phonon4qt5 k3b vlc

Thanks! (Now remaining problem is that I don't have the needed 1GB+ available
space on /var, but I'll sort that out one way or the other).

I still think it's unfortunate that the libicu upgrade requires all of that.

Thanks for the help,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Message #111 received at 819530-done@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 819530-done@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Fri, 4 Nov 2016 22:24:52 +0100

On 01/08/16 18:49, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 01/08/16 09:14, László Böszörményi (GCS) wrote:
>> Not a build failure, but during the transition of gnustep-gui I've
>> seen this warning:
>> dh_installdocs: WARNING: --link-doc between architecture all and not
>> all packages breaks binNMUs
> 
> Please file an RC bug for this.
> 
>> haskell-blogliterately fails due to a Haskell stack problem, the build
>> dependencies can't be installed:
>> libghc-pandoc-dev : Depends: libghc-juicypixels-dev-3.2.7.2-81d4d
>> which is a virtual package and is not provided by any available
>> package
>>
>> openjfx fails due to a long shell command line:
>> -- cut --
>> make[4]: Entering directory
>> '/build/openjfx-8u102-b14/modules/web/build/linux/Release/WebCore'
>> make[4]: execvp: /bin/sh: Argument list too long
> 
> Please file an RC bug.
> 
>> frog fails with:
> [...]
>> The mentioned library and functions come from the mbt package, maybe
>> an uncoordinated transition of an other package?
> 
> No idea. Can you file a bug against frog?
> 
>> Other packages are fine. Please advise other tests if needed.
> 
> Let's start this.

And this is finally finished.

Cheers,
Emilio

Message #114 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: László Böszörményi (GCS) <gcs@debian.org>, 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Fri, 4 Nov 2016 22:51:53 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 04, 2016 at 10:24:52PM +0100, Emilio Pozuelo Monfort wrote:
> And this is finally finished.

Umh, though there is still the old version libicu55 on s390x, due to
xerces-c - #833754

-- 
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 (application/pgp-signature, inline)]

Message #119 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Mattia Rizzolo <mattia@debian.org>, 819530@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Sat, 5 Nov 2016 00:00:11 +0100

Control: reopen -1

On 04/11/16 23:51, Mattia Rizzolo wrote:
> On Fri, Nov 04, 2016 at 10:24:52PM +0100, Emilio Pozuelo Monfort wrote:
>> And this is finally finished.
> 
> Umh, though there is still the old version libicu55 on s390x, due to
> xerces-c - #833754

Oh, I knew about that, but thought it had been fixed because the tracker
disappeared from 'pending transitions'. Now I realise that was because there is
a new one in 'planned transitions' because of the new package in experimental,
which causes the other one to disappear.

Let's reopen this.

Cheers,
Emilio

Message #126 received at 819530@bugs.debian.org (full text, mbox, reply):

From: Kayla Morni Mohd <mrskaylamornimohdx@bigpond.com>

Subject: Dear Benficiary

Date: Mon, 14 Nov 2016 09:30:00 +1100 (AEDT)

[Message part 1 (text/plain, inline)]

Greeting !
Dear Benficiary
I want to inform you that my bank have prepare your your fund amount 
$3.8Million Usd, in Atm Debit Card and ready to post to your address. 
Reply back for more delivery direction it is very important notice.
Yours Faithful
Kayla Morni Mohd

[Message part 2 (text/html, inline)]

Message #133 received at 819530-done@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Mattia Rizzolo <mattia@debian.org>, 819530-done@bugs.debian.org

Subject: Re: Bug#819530: transition: icu

Date: Tue, 24 Jan 2017 18:23:09 +0100

On 05/11/16 00:00, Emilio Pozuelo Monfort wrote:
> Control: reopen -1
> 
> On 04/11/16 23:51, Mattia Rizzolo wrote:
>> On Fri, Nov 04, 2016 at 10:24:52PM +0100, Emilio Pozuelo Monfort wrote:
>>> And this is finally finished.
>>
>> Umh, though there is still the old version libicu55 on s390x, due to
>> xerces-c - #833754
> 
> Oh, I knew about that, but thought it had been fixed because the tracker
> disappeared from 'pending transitions'. Now I realise that was because there is
> a new one in 'planned transitions' because of the new package in experimental,
> which causes the other one to disappear.
> 
> Let's reopen this.

xerces-c got finally fixed. Let's close this.

Cheers,
Emilio

Send a report that this bug log contains spam.