Bug#819530: transition: icu
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
Reply to: