Hi, Maximiliano! Thnaks for your comment.
2017-02-11 19:16 GMT+09:00 Maximiliano Curia <m...@gnuservers.com.ar>: > ¡Hola Nobuhiro! > > El 2017-02-11 a las 15:48 +0900, Nobuhiro Iwamatsu escribió: >> >> Control: tags 811980 + patch > > >>> This package fails to build with GCC 6. GCC 6 has not been released yet, >>> but it's expected that GCC 6 will become the default compiler for stretch. > > >>> Note that only the first error is reported; there might be more. You can >>> find a snapshot of GCC 6 in experimental. To build with GCC 6, you can set >>> CC=gcc-6 CXX=g++-6 explicitly. > > >>> You may be able to find out more about this issue at >>> https://gcc.gnu.org/gcc-6/changes.html > > >> I create a patch which update symboles file. Could you check this patch? > > > I've considered requesting the removal of libusbtc08 as I'm no longer using > it, it seems that there aren't any users for it, and upstream stopped > distributing their source code for the newer versions > (https://www.picotech.com/downloads/linux). > > If you want to take care of libusbtc08 as is and/or work with upstream > please consider taking over this package. > > In any case, I'm listed in the https://wiki.debian.org/LowThresholdNmu, feel > free to upload the fix without asking for permission. > > Happy hacking, I see. I will NMU. > >> --- libusbtc08-1.7.2/debian/libusbtc08-1.symbols 2015-08-27 >> 05:37:20.000000000 +0900 >> +++ libusbtc08-1.7.2/debian/libusbtc08-1.symbols 2017-02-11 >> 15:30:30.000000000 +0900 >> @@ -67,9 +67,6 @@ >> _ZN13PicoUsbDevice4InitEv@Base 1.7.2 >> _ZN13PicoUsbDevice5CountEt@Base 1.7.2 >> _ZN13PicoUsbDevice9EnumerateEPPS_jt@Base 1.7.2 >> - (optional=gccinternal)_ZN13PicoUsbDeviceD0Ev@Base 1.7.2 >> - (optional=gccinternal)_ZN13PicoUsbDeviceD1Ev@Base 1.7.2 >> - (optional=gccinternal)_ZN13PicoUsbDeviceD2Ev@Base 1.7.2 > > No need to drop optional fields (these are the default destructors, and > might show up again in a future version of gcc). > Indeed. > ... > >> - (optional=gccinternal)_ZTV13PicoUsbDevice@Base 1.7.2 > > Mmh, this one should probably stay, as the class is still present and > contains virtual methods > > Most likely you would need a second upload after processing all the buildds > logs, it might make sense to use the pkg-kde-tools symbolshelper for this. > OK, I will check with pkg-kde-tools symbolshelper too. > Happy hacking, Best regards, Nobuhiro -- Nobuhiro Iwamatsu iwamatsu at {nigauri.org / debian.org} GPG ID: 40AD1FA6
