Bug#896710: Bug#912853: transition: icu
On 14/11/2018 18:59, Steve McIntyre wrote: > On Wed, Nov 14, 2018 at 05:01:58PM +, Steve McIntyre wrote: >> On Wed, Nov 14, 2018 at 05:52:30PM +0100, Hector Oron wrote: >>> Hey Steve, >>> >>> Missatge de Steve McIntyre del dia dc., 14 de nov. >>> 2018 a les 17:11: >>> Digging further and installing some debug symbols, I get to a problem in libfreetype6: (sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$ gdb util/.libs/hb-shape core ... Core was generated by `/home/steve/debian/harfbuzz/harfbuzz-2.1.1/build-main/util/.libs/hb-shape ../te'. Program terminated with signal SIGBUS, Bus error. #0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at ./freetype-2.8.1/src/truetype/ttgxvar.c:2122 2122if ( a->minimum > a->def || >>> >>> Thanks! >>> Did you check if version in experimental (freetype-2.9.1) fixes it? >> >> No, that's as far as I went. As I said, it's not clear if the problem >> is in harfbuzz or in freetype. I don't know the code of either well >> enough and I've got other stuff to look at already... > > Although - I've just seen the discussion in #896710 which looks very > relevant... :-) Yes, and there's https://launchpadlibrarian.net/364945452/freetype_2.8.1-2ubuntu1_2.8.1-2ubuntu2.diff.gz Also this is fixed in 2.9.1, see #898983. Cheers, Emilio
Bug#896710: Bug#912853: transition: icu
On Wed, Nov 14, 2018 at 05:01:58PM +, Steve McIntyre wrote: >On Wed, Nov 14, 2018 at 05:52:30PM +0100, Hector Oron wrote: >>Hey Steve, >> >>Missatge de Steve McIntyre del dia dc., 14 de nov. >>2018 a les 17:11: >> >>> Digging further and installing some debug symbols, I get to a problem >>> in libfreetype6: >>> >>> (sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$ gdb >>> util/.libs/hb-shape core >>> ... >>> Core was generated by >>> `/home/steve/debian/harfbuzz/harfbuzz-2.1.1/build-main/util/.libs/hb-shape >>> ../te'. >>> Program terminated with signal SIGBUS, Bus error. >>> #0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at >>> ./freetype-2.8.1/src/truetype/ttgxvar.c:2122 >>> 2122if ( a->minimum > a->def || >> >>Thanks! >>Did you check if version in experimental (freetype-2.9.1) fixes it? > >No, that's as far as I went. As I said, it's not clear if the problem >is in harfbuzz or in freetype. I don't know the code of either well >enough and I've got other stuff to look at already... Although - I've just seen the discussion in #896710 which looks very relevant... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#912853: transition: icu
On Wed, Nov 14, 2018 at 05:52:30PM +0100, Hector Oron wrote: >Hey Steve, > >Missatge de Steve McIntyre del dia dc., 14 de nov. >2018 a les 17:11: > >> Digging further and installing some debug symbols, I get to a problem >> in libfreetype6: >> >> (sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$ gdb >> util/.libs/hb-shape core >> ... >> Core was generated by >> `/home/steve/debian/harfbuzz/harfbuzz-2.1.1/build-main/util/.libs/hb-shape >> ../te'. >> Program terminated with signal SIGBUS, Bus error. >> #0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at >> ./freetype-2.8.1/src/truetype/ttgxvar.c:2122 >> 2122if ( a->minimum > a->def || > >Thanks! >Did you check if version in experimental (freetype-2.9.1) fixes it? No, that's as far as I went. As I said, it's not clear if the problem is in harfbuzz or in freetype. I don't know the code of either well enough and I've got other stuff to look at already... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#912853: transition: icu
Hey Steve, Missatge de Steve McIntyre del dia dc., 14 de nov. 2018 a les 17:11: > Digging further and installing some debug symbols, I get to a problem > in libfreetype6: > > (sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$ gdb > util/.libs/hb-shape core > ... > Core was generated by > `/home/steve/debian/harfbuzz/harfbuzz-2.1.1/build-main/util/.libs/hb-shape > ../te'. > Program terminated with signal SIGBUS, Bus error. > #0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at > ./freetype-2.8.1/src/truetype/ttgxvar.c:2122 > 2122if ( a->minimum > a->def || Thanks! Did you check if version in experimental (freetype-2.9.1) fixes it? Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#912853: transition: icu
Hey folks,
On Tue, Nov 13, 2018 at 07:03:37PM +0100, Hector Oron wrote:
>Missatge de Emilio Pozuelo Monfort del dia dt., 13
>de nov. 2018 a les 18:44:
>>
>> On 13/11/2018 17:45, László Böszörményi (GCS) wrote:
>> > Please note that src:harfbuzz currently has a problem on armhf, it
>> > failed to build three times in line. The reason is known: the
>> > arm-arm-01 named buildd always failed to build it[1]. Can you schedule
>> > its build on an other armhf machine or a buildd admin (in Cc) can do
>> > it? There's no sense trying to build it on the mentioned box again and
>> > again or even later. If possible, please set that src:harfbuzz
>> > shouldn't be tried to build on the arm-arm-01 machine in the future.
>>
>> That will be investigated. The problem is that arm-arm-01 is an arm64
>> machine,
>> building armhf packages. harfbuzz doesn't like that.
>
>Indeed, Steve is working on that topic, re-building armhf/armel on
>arm64 and already found some issues. I pinged him about it in IRC,
>however I CC him on this one as it might be valuable for his work.
Trying this locally:
...
(sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$
./util/hb-shape
../test/shaping/data/in-house/fonts/d23d76ea0909c14972796937ba072b5a40c1e257.ttf
--shaper=ot --verify --variations=FVTT=1 --unicodes U+0072
Bus error
There is an alignment problem causing the failure. It would be nice if
the test wrapper code, or libtool or whatever didn't lose/hide the
"Bus error" diagnostic message. :-(
Digging further and installing some debug symbols, I get to a problem
in libfreetype6:
(sid-armhf)steve@mjolnir:~/debian/harfbuzz/harfbuzz-2.1.1/build-main$ gdb
util/.libs/hb-shape core
...
Core was generated by
`/home/steve/debian/harfbuzz/harfbuzz-2.1.1/build-main/util/.libs/hb-shape
../te'.
Program terminated with signal SIGBUS, Bus error.
#0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at
./freetype-2.8.1/src/truetype/ttgxvar.c:2122
2122if ( a->minimum > a->def ||
(gdb) bt
#0 TT_Get_MM_Var (face=0x1c66d78, master=master@entry=0x0) at
./freetype-2.8.1/src/truetype/ttgxvar.c:2122
#1 0xf78b4ef2 in tt_set_mm_blend (face=0x1c66d78, num_coords=3,
coords=0x1c67490, set_design_coords=)
at ./freetype-2.8.1/src/truetype/ttgxvar.c:2332
#2 0xf78ae540 in FT_Set_MM_Blend_Coordinates (face=0x1c66d78, num_coords=3,
coords=0x1c67490) at ./freetype-2.8.1/src/base/ftmm.c:277
#3 0xf7a69b16 in hb_ft_font_set_funcs (font=0x1c66828) at
../../src/hb-ft.cc:845
#4 0x006fc300 in font_options_t::get_font (this=0xff863648) at
../../util/options.cc:717
#5 0x006fa060 in shape_consumer_t::init
(font_opts=0xff863648, buffer_=0x1c66680, this=0xff8636c4)
at ../../util/shape-consumer.hh:44
#6 main_font_text_t, 2147483647, 0>::main
(this=0xff863638, argc=,
argv=) at ../../util/main-font-text.hh:75
#7 0x006fa8a8 in main (argc=7, argv=0xff864964) at ../../util/hb-shape.cc:192
(gdb) p a
$1 = (FT_Var_Axis *) 0x1c67512
(gdb) p *a
$2 = {name = 0x1c6758a "UPWD", minimum = 0, def = 0, maximum = 22937600, tag =
1431328580, strid = 256}
Whether that's a bug in freetype or in the code here using it. I'm not
sure without digging a lot further.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
Bug#912853: transition: icu
Hello, Missatge de Emilio Pozuelo Monfort del dia dt., 13 de nov. 2018 a les 18:44: > > On 13/11/2018 17:45, László Böszörményi (GCS) wrote: > > Please note that src:harfbuzz currently has a problem on armhf, it > > failed to build three times in line. The reason is known: the > > arm-arm-01 named buildd always failed to build it[1]. Can you schedule > > its build on an other armhf machine or a buildd admin (in Cc) can do > > it? There's no sense trying to build it on the mentioned box again and > > again or even later. If possible, please set that src:harfbuzz > > shouldn't be tried to build on the arm-arm-01 machine in the future. > > That will be investigated. The problem is that arm-arm-01 is an arm64 machine, > building armhf packages. harfbuzz doesn't like that. Indeed, Steve is working on that topic, re-building armhf/armel on arm64 and already found some issues. I pinged him about it in IRC, however I CC him on this one as it might be valuable for his work. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#912853: transition: icu
On 13/11/2018 17:45, László Böszörményi (GCS) wrote: > Please note that src:harfbuzz currently has a problem on armhf, it > failed to build three times in line. The reason is known: the > arm-arm-01 named buildd always failed to build it[1]. Can you schedule > its build on an other armhf machine or a buildd admin (in Cc) can do > it? There's no sense trying to build it on the mentioned box again and > again or even later. If possible, please set that src:harfbuzz > shouldn't be tried to build on the arm-arm-01 machine in the future. That will be investigated. The problem is that arm-arm-01 is an arm64 machine, building armhf packages. harfbuzz doesn't like that. In the meantime, I retried the build and an armhf machine picked it up. Emilio
Bug#912853: transition: icu
Hello László, Missatge de László Böszörményi (GCS) del dia dt., 13 de nov. 2018 a les 17:46: > > On Mon, Nov 12, 2018 at 4:05 PM Emilio Pozuelo Monfort > wrote: > > On 11/11/2018 11:24, László Böszörményi (GCS) wrote: > > > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS) > > > wrote: > > >> I'd like to upload ICU 63.1 which was recently released for Buster. > > > I still miss the last three packages rebuilt, but I don't expect any > > > problems with those. > > > First, my methodology was to build the related packages both on i386 > > > and amd64 (32 and 64 bit) to detect all possible problems in advance. > > > If a package failed due to ICU, I've patched it. If the reason was not > > > clear, rebuilt the package for Sid to check that result as well. > > > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults > > > point to it, then all other packages. > > Please go ahead with this. I will ack the boost transition once this is > > built. > Please note that src:harfbuzz currently has a problem on armhf, it > failed to build three times in line. The reason is known: the > arm-arm-01 named buildd always failed to build it[1]. Can you schedule > its build on an other armhf machine or a buildd admin (in Cc) can do > it? There's no sense trying to build it on the mentioned box again and > again or even later. If possible, please set that src:harfbuzz > shouldn't be tried to build on the arm-arm-01 machine in the future. I have blacklisted it in arm-arm-01, however someone had give it back and it is building (update built!) in arnold now. Regards > Thanks, > Laszlo/GCS > [1] https://buildd.debian.org/status/logs.php?pkg=harfbuzz&arch=armhf -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#912853: transition: icu
On Mon, Nov 12, 2018 at 4:05 PM Emilio Pozuelo Monfort wrote: > On 11/11/2018 11:24, László Böszörményi (GCS) wrote: > > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS) > > wrote: > >> I'd like to upload ICU 63.1 which was recently released for Buster. > > I still miss the last three packages rebuilt, but I don't expect any > > problems with those. > > First, my methodology was to build the related packages both on i386 > > and amd64 (32 and 64 bit) to detect all possible problems in advance. > > If a package failed due to ICU, I've patched it. If the reason was not > > clear, rebuilt the package for Sid to check that result as well. > > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults > > point to it, then all other packages. > Please go ahead with this. I will ack the boost transition once this is built. Please note that src:harfbuzz currently has a problem on armhf, it failed to build three times in line. The reason is known: the arm-arm-01 named buildd always failed to build it[1]. Can you schedule its build on an other armhf machine or a buildd admin (in Cc) can do it? There's no sense trying to build it on the mentioned box again and again or even later. If possible, please set that src:harfbuzz shouldn't be tried to build on the arm-arm-01 machine in the future. Thanks, Laszlo/GCS [1] https://buildd.debian.org/status/logs.php?pkg=harfbuzz&arch=armhf
Bug#912853: transition: icu
On Mon, Nov 12, 2018 at 4:05 PM Emilio Pozuelo Monfort wrote: > On 11/11/2018 11:24, László Böszörményi (GCS) wrote: > > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS) > > wrote: > >> I'd like to upload ICU 63.1 which was recently released for Buster. > > I still miss the last three packages rebuilt, but I don't expect any > > problems with those. > > First, my methodology was to build the related packages both on i386 > > and amd64 (32 and 64 bit) to detect all possible problems in advance. > > If a package failed due to ICU, I've patched it. If the reason was not > > clear, rebuilt the package for Sid to check that result as well. > > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults > > point to it, then all other packages. > Please go ahead with this. I will ack the boost transition once this is built. Small update and a problem I might caused. ICU needs to be bootstrapped via icu-le-hb. But the latter build depends on src:harfbuzz which should have been binNMUed with the new ICU (63.1-3) package version. The only package that can be affected over icu-le-hb itself is openttd. I've filed bugs for the ICU update request with the proposed patches. Only sword is updated at the time of writing and it's own transition with bibletime and xiphos said to be ongoing. It is said that nodejs will upload its new major upstream release which handles this ICU transition as soon as it's accepted from the NEW queue and built fine for experimental. The libkiwix maintainer also choose to use the new upstream release for the transition, but it will need its zimlib build dependency updated, which sits in the NEW queue as well. Cheers, Laszlo/GCS
Bug#912853: transition: icu
Control: tags -1 confirmed On 11/11/2018 11:24, László Böszörményi (GCS) wrote: > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS) > wrote: >> I'd like to upload ICU 63.1 which was recently released for Buster. > I still miss the last three packages rebuilt, but I don't expect any > problems with those. > First, my methodology was to build the related packages both on i386 > and amd64 (32 and 64 bit) to detect all possible problems in advance. > If a package failed due to ICU, I've patched it. If the reason was not > clear, rebuilt the package for Sid to check that result as well. > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults > point to it, then all other packages. > > level 1 > widelands FTBFS, patched it. > > level 2 > boost1.63 (sid only) FTBFS due to Python issue already filed as #902921 > hfst-ospell FTBFS, patched it. > mozjs60 FTBFS, unrelated linking issue, not yet filed > nodejs FTBFS, ICU issue is patched, SSL self test problem already > filed as #902512 > openttd FTBFS, patched it > ruby-charlock-holmes FTBFS, patched it > sword FTBFS, patched it > tarantool FTBFS due to cURL issue already filed as #913380 > > level 3 > hhvm (sid only) FTBFS due to self test problem already filed as #907305 > libfolia FTBFS, patched it > libkiwix FTBS, patched it > ncmpcpp FTBFS, patched it > > level 4 > gnucash FTBFS due to self test problem > haskell-blogliterately build dependencies are uninstallable, can't test > kopanocore FTBFS due to PHP problem already filed as #911360 > odil FTBFS for unknow problem and under investigation > ucto FTBFS, patched it > xiphos FTBFS, can be related to #913070 (sword transition) > > level 5 > frog FTBFS, patched it > > I have to leave soon, but plan to file the ICU FTBFS bugs and patches > in the evening. > The last three package rebuild probably will happen tomorrow. There's > no more problem expected, but even if that may happen, I can patch > that quick. Please go ahead with this. I will ack the boost transition once this is built. Cheers, Emilio
Bug#912853: transition: icu
On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS) wrote: > I'd like to upload ICU 63.1 which was recently released for Buster. I still miss the last three packages rebuilt, but I don't expect any problems with those. First, my methodology was to build the related packages both on i386 and amd64 (32 and 64 bit) to detect all possible problems in advance. If a package failed due to ICU, I've patched it. If the reason was not clear, rebuilt the package for Sid to check that result as well. The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults point to it, then all other packages. level 1 widelands FTBFS, patched it. level 2 boost1.63 (sid only) FTBFS due to Python issue already filed as #902921 hfst-ospell FTBFS, patched it. mozjs60 FTBFS, unrelated linking issue, not yet filed nodejs FTBFS, ICU issue is patched, SSL self test problem already filed as #902512 openttd FTBFS, patched it ruby-charlock-holmes FTBFS, patched it sword FTBFS, patched it tarantool FTBFS due to cURL issue already filed as #913380 level 3 hhvm (sid only) FTBFS due to self test problem already filed as #907305 libfolia FTBFS, patched it libkiwix FTBS, patched it ncmpcpp FTBFS, patched it level 4 gnucash FTBFS due to self test problem haskell-blogliterately build dependencies are uninstallable, can't test kopanocore FTBFS due to PHP problem already filed as #911360 odil FTBFS for unknow problem and under investigation ucto FTBFS, patched it xiphos FTBFS, can be related to #913070 (sword transition) level 5 frog FTBFS, patched it I have to leave soon, but plan to file the ICU FTBFS bugs and patches in the evening. The last three package rebuild probably will happen tomorrow. There's no more problem expected, but even if that may happen, I can patch that quick. Regards, Laszlo/GCS
Bug#912853: transition: icu
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I'd like to upload ICU 63.1 which was recently released for Buster. The packaging already bootstrapped with icu-le-hb (Layout Engine using the HarfBuzz library) in experimental. Rebuilding of dependent packages are in progress. I can report the following so far. Level 1 widelands FTBFS, but I've a patch. Level 2 boost1.63 FTBFS due to an unrelated, Pyhon 3.7 problem probably related to the already reported case in #902921 [1]. I think it's going to be removed thus didn't investigated further. hfst-ospell FTBFS and while I've a patch, it's already fixed in its new, 0.5.1 release. mozjs60 FTBFS due to an unrelated problem, confirmed in a clean Sid environment as well. nodejs FTBFS on x86 only and while I've a patch it will still fail to build due to its test suite problems already reported in #902512 [2]. openttd FTBFS on x86 only and upstream has a patch that can be backported easily. Other packages are in build testing. I don't expect too much problems and fixing build failures are quite easy. This has to be done with the Boost 1.67 transition which is already scheduled. I don't think this would delay that too much as my testing is done with the ICU transitioned boost1.67 package and boost-defaults set to it. It seems more and more applications start to use it as their ICU dependency for Unicode 11.0 support including Firefox and Chromium browser. Would be nice if Buster can be shipped with this ICU release. Regards, Laszlo/GCS [1] https://bugs.debian.org/902921 [2] https://bugs.debian.org/902512
