[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#819530: transition: icu



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


Reply to: