Bug#905022: Bug#908589: gcc-8 documentation packages

[Guo Yixuan]

Hello Matthias and Dmitry,

Sorry for being MIA. As I'm currently busy with my life and work, I want to
give up all my packages for adoption. (I forgot about the proper procedure
here, so please kindly take over as you wish.)

Please let me know if a GPG-signed copy of this email is needed.

Thank you!
Yixuan

On Mon, Jun 24, 2019 at 5:51 PM Matthias Klose  wrote:

> On 22.06.19 01:01, Dmitry Eremin-Solenikov wrote:
> > Hello,
> >
> > вт, 21 мая 2019 г. в 16:58, Dmitry Eremin-Solenikov <
> dbarysh...@gmail.com>:
> >>
> >> Hello,
> >>
> >> I've updated gcc-doc/gcc-doc-defaults packages to support new gcc-8
> >> documentation generation. NMU Packages are uploaded to
> >> mentors.debian.net
> >> for review, git trees are put on salsa.debian.org/gcc-doc (-defaults).
> >
> > It's been nearly a month without any response. Is it an expected thing
> before
> > buster release? Or should I contact debian-mentors looking for sponsors
> > for these packages?
>
> I'm trying to stay away uploading the gcc*-doc packages.  Yes, maybe
> contacting
> debian-mentors is the right thing to do, if Guo is MIA.
>

Bug#874167: gcc-6-doc: source uploaded without binaries, caused package removal

[Guo Yixuan]

Hello,

Thank you for pointing out the reasons for the current problem. I'll update
the package according to the instructions here:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

Regards,
Yixuan

On Sun, Sep 3, 2017 at 3:38 PM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sun, Sep 03, 2017 at 09:30:08PM +0200, Adam Borowski wrote:
> > I've uploaded source+binary identical as before (as it has been in the
> > archive, any modifications would be a bad idea).  If this won't work, the
> > maintainer (Guo Yixuan) is a better person to bump the version and make
> > adjustments.
>
> I fear that it's going to be rejected…  but let's see :)
>
> > XS-Autobuild can be added -2 no matter if we need it tonight or months
> > later.
>
> Right.  But please consider adding it, as it makes only sense to have
> that stuff built on the buildds.  Also remember that XS-Autobuild is
> only the first step, you need to ask it to be whitelisted on the buildds
> https://www.debian.org/doc/manuals/developers-reference/
> ch05.en.html#non-free-buildd
>
> --
> 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  `-
>



-- 
GUO Yixuan

Bug#871220: gcc-doc-defaults: FTBFS with GCC-7

[Guo Yixuan]

Control: block -1 by 872959 872961
Control: tag -1 + pending

Hello,

On Sun, Aug 6, 2017 at 8:58 PM, Adam Borowski  wrote:
>
> > gcc-doc-defaults FTBFS since GCC-7 was made the default compiler:
>
> Which raises a question: where's gcc-7-doc?

I'm going to have a new upload, but before that, gcc-7-doc(ITP) and
gcc-6-doc
needs to be uploaded.

https://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc-defaults.git

Yixuan

Bug#870377: gcc-5-doc: FTBFS with perl 5.26: Unescaped left brace in regex is illegal

[Guo Yixuan]

On Tue, Aug 1, 2017 at 11:24 AM, Adrian Bunk <b...@debian.org> wrote:
>
> On Tue, Aug 01, 2017 at 03:59:12PM +0200, Andreas Beckmann wrote:
> > Source: gcc-5-doc
> > Version: 5.3.0-2
> > Severity: serious
> > Tags: sid buster
> > Justification: fails to build from source
> >
> > [...]
> > (cd gcc/doc && perl ../../contrib/texi2pod.pl -Dfngccint=gccint-5
-DBUGURL=http://bugs.debian.org/) < gcc/doc/invoke.texi > gcc.pod
> > Unescaped left brace in regex is illegal here in regex; marked by <--
HERE in m/^\@strong{ <-- HERE (.*)}$/ at ../../contrib/texi2pod.pl line 319.
> > debian/Makefile:198: recipe for target 'gcc.pod' failed
> > make[2]: *** [gcc.pod] Error 255
> > make[2]: Leaving directory '/build/gcc-5-doc-5.3.0'
> > debian/rules:56: recipe for target 'override_dh_auto_build' failed
> > make[1]: *** [override_dh_auto_build] Error 2
> > [...]
>
> I am surprised that gcc-5-doc is in stable and still in unstable even
> though gcc-5 is not in stable.
>
> Any objections to filing an RM bug for removing it from unstable?
>
> > Andreas
>
> cu
> Adrian

No problem. Please go ahead.

Yixuan
>
> --
>
>"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




--
GUO Yixuan

Bug#793260: [Pkg-ime-devel] Bug#793260: Bug#793260: marisa: change of type in system_error might break with GCC-5

[Guo Yixuan]

On Sep 2, 2015 12:52, "Mitsuya Shibata"  wrote:
>
> Control: owner !
>
> sorry for very late reply.
> I will tackle the bug in this weekend.

Thank you! If no renaming is needed, then you only need to bump the package
version, rebuild and upload.

Actually, after rebuilding with 5.2, there's only one symbol with cxx11 ABI
substring:
   U typeinfo for std::ios_base::failure[abi:cxx11]

Cheers,
Yixuan

Bug#790287: [Pkg-ime-devel] Bug#790287: sunpinyin: FTBFS: pod2man error (no name given for document)

[Guo Yixuan]

Control: tag -1 + pending
Control: forwarded -1
https://code.google.com/p/sunpinyin/issues/detail?id=327

So we need either
  $ pod2man -n genpyt genpyt.pod genpyt.1
 or
  $ pod2man genpyt.pod genpyt.1

 I'll try to fix this.


It's here

http://anonscm.debian.org/cgit/pkg-ime/sunpinyin.git/commit/?id=192b818ef9a328fa08a60e26e2e5a1769882ff32

Regards,
Yixuan

Bug#790287: [Pkg-ime-devel] Bug#790287: sunpinyin: FTBFS: pod2man error (no name given for document)

[Guo Yixuan]

Hello

On Sat, Jun 27, 2015 at 5:12 PM, Daniel Schepler dschep...@gmail.com
wrote:

 Source: sunpinyin
 Version: 2.0.3+git20140127-1.1
 Severity: serious

 From my pbuilder build log:

 ...
 g++ -o src/ime-core/userdict.os -c -g -O2 -fstack-protector-strong
 -Wformat -Werror=format-security -pipe -fPIC -DHAVE_CONFIG_H
 -DSUNPINYIN_DATA_DIR='/usr/lib/x86_64-linux-gnu/sunpinyin/data' -I. -Isrc
 -Isrc/ime-core -Isrc/lexicon -Isrc/pinyin -Isrc/slm -Isrc/slm/slmbuild
 -Isrc/slm/ids2ngram -Isrc/slm/tslminfo -Isrc/slm/mmseg -Isrc/slm/thread
 -Isrc/slm/tslmpack -Isrc/slm/slmprune -Isrc/slm/slminfo -Isrc/slm/tools
 -Isrc/slm/slmseg -Isrc/slm/tslmendian -Isrc/slm/getwordfreq
 src/ime-core/userdict.cpp
 g++ -o libsunpinyin.so.3.0 -Wl,-z,relro -Wl,-soname=libsunpinyin.so.3
 -shared src/portability.os src/slm/slm.os src/lexicon/pytrie.os
 src/pinyin/pinyin_data.os src/pinyin/pinyin_seg.os
 src/pinyin/shuangpin_data.os src/pinyin/shuangpin_seg.os
 src/pinyin/hunpin_seg.os src/ime-core/imi_context.os
 src/ime-core/imi_data.os src/ime-core/lattice_states.os
 src/ime-core/imi_view.os src/ime-core/imi_uiobjects.os
 src/ime-core/imi_view_classic.os src/ime-core/imi_winHandler.os
 src/ime-core/ic_history.os src/ime-core/imi_funcobjs.os
 src/ime-core/imi_options.os src/ime-core/imi_option_event.os
 src/ime-core/userdict.os -lsqlite3
 pod2man  man/genpyt.pod  man/genpyt.1
 IO::File=IO(0x1b2e190) around line 1: No name given for document
 POD document had syntax errors at /usr/bin/pod2man line 71.
 scons: *** [man/genpyt.1] Error 255
 scons: building terminated because of errors.
 debian/rules:22: recipe for target 'override_dh_auto_build' failed
 make[1]: *** [override_dh_auto_build] Error 2
 make[1]: Leaving directory '/tmp/buildd/sunpinyin-2.0.3+git20140127'
 debian/rules:14: recipe for target 'build' failed
 make: *** [build] Error 2
 dpkg-buildpackage: error: debian/rules build gave error exit status 2


So we need either
 $ pod2man -n genpyt genpyt.pod genpyt.1
or
 $ pod2man genpyt.pod genpyt.1

I'll try to fix this.

Regards,
GUO Yixuan

Bug#784199: [Pkg-ime-devel] Bug#784199: fcitx-rime: Cannot enable rime in fcitx

[GUO Yixuan]

Control: merge -1 784200
Control: reassign -1 src:librime
Control: tag -1 + pending
Control: clone -1 -2
Control: reassign -2 libyaml-cpp0.5
Control: retitle -2 dependency problem breaks librime
Control: severity -2 important

Hi,

On Sun, May 03, 2015 at 04:40:23PM -0700, Hong Xu wrote:
 Package: fcitx-rime
 Version: 0.3.1-1
 Severity: grave
 Tags: newcomer
 Justification: renders package unusable
 
 Dear Maintainer,
 
 *** Reporter, please consider answering these questions, where appropriate ***
 
* What led up to the situation?
 
 Enable rime in fcitx.
 
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 
 Open fcitx dialog, add a new IM, and choose rime to add.
 
* What was the outcome of this action?
 
 Fcitx stopped working, the list of IM is made to be blank. The following
 message were printed:
 
 (fcitx-config-gtk3:12415): GLib-GIO-CRITICAL **:
 g_dbus_connection_call_internal: assertion 'G_IS_DBUS_CONNECTION (connection)'
 failed
 =
 FCITX 4.2.8.5 -- Get Signal No.: 11
 Date: try date -d @1430693030 if you are using GNU date ***
 ProcessID: 12355
 fcitx[0x4015fb]
 /lib/x86_64-linux-gnu/libc.so.6(+0x35180)[0x7f01d1ae4180]
 /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSsC1ERKSs+0xb)[0x7f01ce99926b]
 /usr/lib/librime.so.1(_ZN4rime10ConfigData15ConvertFromYamlERKN4YAML4NodeE+0x4d2)[0x7f01c44c4eb2]
 /usr/lib/librime.so.1(_ZN4rime10ConfigData12LoadFromFileERKSs+0x16a)[0x7f01c44c56aa]
 /usr/lib/librime.so.1(_ZN4rime18InstallationUpdate3RunEPNS_8DeployerE+0x14b)[0x7f01c45da51b]
 /usr/lib/librime.so.1(_ZN4rime8Deployer7RunTaskERKSsN5boost3anyE+0x9e)[0x7f01c44b950e]
 /usr/lib/librime.so.1(RimeStartMaintenance+0xa1)[0x7f01c44aebf1]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x2157)[0x7f01c4866157]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x2666)[0x7f01c486]
 /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x115c7)[0x7f01d26b65c7]
 /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x14780)[0x7f01d26b9780]
 /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x1311c)[0x7f01d26b811c]
 /usr/lib/x86_64-linux-gnu/libfcitx-
 core.so.0(FcitxInstanceUpdateIMList+0x25d)[0x7f01d26b844d]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x300d)[0x7f01c62cf00d]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x5e4c)[0x7f01c62d1e4c]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x35c2)[0x7f01c62cf5c2]
 /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x1e5ff)[0x7f01d13535ff]
 /lib/x86_64-linux-
 gnu/libdbus-1.so.3(dbus_connection_dispatch+0x3b4)[0x7f01d1345194]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x22d8)[0x7f01d157f2d8]
 /usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x23e9)[0x7f01d157f3e9]
 /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x9fe6)[0x7f01d26aefe6]
 /usr/lib/x86_64-linux-gnu/libfcitx-
 core.so.0(FcitxInstanceRun+0x210)[0x7f01d26af710]
 fcitx[0x400fb6]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f01d1ad0b45]
 fcitx[0x401029]
 
 ** (fcitx-config-gtk3:12415): WARNING **:
 GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a 
 reply
 (timeout by message bus)
 
 (fcitx-config-gtk3:12415): GLib-CRITICAL **: g_variant_unref: assertion 'value
 != NULL' failed
 
 ** (fcitx-config-gtk3:12415): WARNING **:
 GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
 org.fcitx.Fcitx-0 was not provided by any .service files
 
 
* What outcome did you expect instead?
 
 Rime should be enabled and usable.
 
 I suspect this is a recent break in librime after libyaml-cpp is upgraded to
 0.5.2, as shown in an ArchLinux bug: https://bugs.archlinux.org/task/44428


Thanks for this report. A rebuild indeed fixes this bug, which
indicates some problem with libyaml-cpp's shlib, so I'm cloning this
bug for libyaml-cpp.

Regards,
Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758184: boinc: FTBFS due to dependency errors in Makefile

[GUO Yixuan]

On Fri, Aug 15, 2014 at 10:43:35AM +0100, Gianfranco Costamagna wrote:
 
 Hi Sebastian,
 
 Source: boinc
 Version: 7.4.14+dfsg-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the 
 past)
 
 boinc failed to build on the buildds with the following error:
 | /bin/bash ../libtool  --tag=CXX   --mode=link /usr/bin/g++ -Wall -Wextra 
 -Wshadow -Wredundant-decls -Wdisabled-optimization -Wpointer-arith 
 -Wstrict-aliasing -Wcast-align  -fPIC -DPIC -pthread -g -O2 
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 
 -funroll-loops -fforce-addr -ffast-math -Wall -L/usr/lib -rpath /usr/lib 
 -version-number 7:4:14 -Wl,-z,relro -flto -Wl,--no-add-needed -o libboinc.la 
 -rpath /usr/lib libboinc_la-app_ipc.lo libboinc_la-base64.lo 
 libboinc_la-cc_config.lo libboinc_la-cert_sig.lo libboinc_la-coproc.lo 
 libboinc_la-diagnostics.lo libboinc_la-filesys.lo 
 libboinc_la-gui_rpc_client.lo libboinc_la-gui_rpc_client_ops.lo 
 libboinc_la-gui_rpc_client_print.lo libboinc_la-hostinfo.lo 
 libboinc_la-md5.lo libboinc_la-md5_file.lo libboinc_la-mem_usage.lo 
 libboinc_la-mfile.lo libboinc_la-miofile.lo libboinc_la-msg_log.lo 
 libboinc_la-network.lo libboinc_la-notice.lo libboinc_la-opencl_boinc.lo 
 libboinc_la-parse.lo
  libboinc_la-prefs.lo libboinc_la-procinfo.lo libboinc_la-proc_control.lo 
 libboinc_la-proxy_info.lo libboinc_la-shmem.lo libboinc_la-str_util.lo 
 libboinc_la-url.lo libboinc_la-util.lo libboinc_la-procinfo_unix.lo 
 libboinc_la-synch.lo libboinc_la-unix_util.lo    
 | libtool: link: /usr/bin/g++  -fPIC -DPIC -shared -nostdlib 
 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o 
 /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o  .libs/libboinc_la-app_ipc.o 
 .libs/libboinc_la-base64.o .libs/libboinc_la-cc_config.o 
 .libs/libboinc_la-cert_sig.o .libs/libboinc_la-coproc.o 
 .libs/libboinc_la-diagnostics.o .libs/libboinc_la-filesys.o 
 .libs/libboinc_la-gui_rpc_client.o .libs/libboinc_la-gui_rpc_client_ops.o 
 .libs/libboinc_la-gui_rpc_client_print.o .libs/libboinc_la-hostinfo.o 
 .libs/libboinc_la-md5.o .libs/libboinc_la-md5_file.o 
 .libs/libboinc_la-mem_usage.o .libs/libboinc_la-mfile.o 
 .libs/libboinc_la-miofile.o .libs/libboinc_la-msg_log.o 
 .libs/libboinc_la-network.o .libs/libboinc_la-notice.o 
 .libs/libboinc_la-opencl_boinc.o .libs/libboinc_la-parse.o 
 .libs/libboinc_la-prefs.o .libs/libboinc_la-procinfo.o 
 .libs/libboinc_la-proc_control.o .libs/libboinc_la-proxy_info.o 
 .libs/libboinc_la-shmem.o
  .libs/libboinc_la-str_util.o .libs/libboinc_la-url.o 
 .libs/libboinc_la-util.o .libs/libboinc_la-procinfo_unix.o 
 .libs/libboinc_la-synch.o .libs/libboinc_la-unix_util.o   -L/usr/lib 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.9 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu 
 -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lstdc++ -lm -lc -lgcc_s 
 /usr/lib/gcc/x86_64-linux-gnu/4.9/crtfastmath.o 
 /usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o 
 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o  -pthread 
 -O2 -O3 -Wl,-z -Wl,relro -flto -Wl,--no-add-needed   -pthread -Wl,-soname 
 -Wl,libboinc.so.7 -o .libs/libboinc.so.7.4.14
 | g++: error: .libs/libboinc_la-gui_rpc_client_ops.o: No such file or 
 directory
 | make[4]: *** [libboinc.la] Error 1
 | make[4]: *** Waiting for unfinished jobs
 | Makefile:927: recipe for target 'libboinc.la' failed
 
 The missing file gets built directly after the failure:
 | libtool: compile:  /usr/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../api 
 -I../db -I../lib -I../lib/mac -I../sched -I../tools -I../vda -pthread 
 -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wshadow -Wredundant-decls 
 -Wdisabled-optimization -Wpointer-arith -Wstrict-aliasing -Wcast-align -fPIC 
 -DPIC -pthread -g -O2 -fstack-protector-strong -Wformat 
 -Werror=format-security -Wall -O3 -funroll-loops -fforce-addr -ffast-math 
 -Wall -c gui_rpc_client_ops.cpp -o libboinc_la-gui_rpc_client_ops.o 
 /dev/null 21
 | /bin/bash ../libtool  --tag=CXX   --mode=link /usr/bin/g++ -Wall -Wextra 
 -Wshadow -Wredundant-decls -Wdisabled-optimization -Wpointer-arith 
 -Wstrict-aliasing -Wcast-align  -fPIC -DPIC -pthread -g -O2 
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 
 -funroll-loops -fforce-addr -ffast-math -Wall -L/usr/lib -rpath /usr/lib 
 -version-number 7:4:14 -Wl,-z,relro -flto -Wl,--no-add-needed -o libboinc.la 
 -rpath /usr/lib libboinc_la-app_ipc.lo libboinc_la-base64.lo 
 libboinc_la-cc_config.lo libboinc_la-cert_sig.lo libboinc_la-coproc.lo 
 libboinc_la-diagnostics.lo libboinc_la-filesys.lo 
 libboinc_la-gui_rpc_client.lo libboinc_la-gui_rpc_client_ops.lo 
 libboinc_la-gui_rpc_client_print.lo libboinc_la-hostinfo.lo 
 libboinc_la-md5.lo libboinc_la-md5_file.lo libboinc_la-mem_usage.lo 
 libboinc_la-mfile.lo libboinc_la-miofile.lo 

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Mon, Jun 30, 2014 at 8:54 AM, Osamu Aoki osamu_aoki_h...@nifty.com
wrote:

 Hi,

 On Sun, Jun 29, 2014 at 02:14:49PM -0400, Guo Yixuan wrote:
  The only problem for using uversionmangle is:
 
  I: librime source:
  debian-watch-file-should-dversionmangle-not-uversionmangle line 3
  N:
  N:The version of this package contains dfsg, ds, or debian, but a
  N:misleading upstream version mangling occurs in the debian/watch
file.
  N:Since the dfsg string is not part of the upstream version and its
  N:addition is Debian-specific, the the debian/watch file should use
the
  N:dversionmangle option to remove, instead of adding in
uversionmangle,
  N:the dfsg before comparing version numbers.
  N:
  N:Refer to http://wiki.debian.org/DEHS for details.
  N:
  N:Severity: wishlist, Certainty: certain
  N:
  N:Check: watch-file, Type: source
 
  But if we use dversionmangle instead of uversionmangle,
  then the renamed origin tarball has name librime_1.1.orig.tar.gz,
   which needs to be manually renamed to librime_1.1+dfsg.orig.tar.gz.
 
  A related bug is here. [1]
 
  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748465

 Did you try the solution at the bottom?

Do you mean message #42? I can't find any solutions there...
I think a lintian override is the best solution before the removal
of debian-watch-file-should-dversionmangle-not-uversionmangle.

[1 #42] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748465#42

 Also, adding yourself to uploader, go ahead.  This means you will stay
 with us and keep working on this :-)

Thank you!

Cheers,

Yixuan

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

Hi,

On Mon, Jun 23, 2014 at 8:03 AM, Osamu Aoki osamu_aoki_h...@nifty.com
wrote:
 On Sun, Jun 22, 2014 at 12:01:49PM -0400, GUO Yixuan wrote:
  On Sun, Jun 22, 2014 at 08:27:12PM +0900, Osamu Aoki wrote:
  
   On Sun, Jun 22, 2014 at 01:45:32AM +0800, Aron Xu wrote:
On Sun, Jun 22, 2014 at 1:33 AM, GUO Yixuan culu@gmail.com
wrote:
 I'm just waiting for a confirmation on the librime-dev =
librime1-dev
 renaming, from Aron, as we discussed in a previous thread. [1]

   
As said before, I don't have strong opinion on either way.
  
   My popsition is that you have not presented enough reason to do this.
   So do not do this.
 
  I remember one possible reason: librime 1.0 breaks some ABI and API
  compatibility,

 Yes.  Thus you need to change librime0 to librime1 etc.

  so we should change the -dev package name. [1][2]

 No.  Your reference does not say so.

 This is only needed if you are having massive dependency and transition
 library in complicated arrangement which you seem not to chase.

 KISS (Keep it simple and S***) is the reason why I said no.  (I am not
 saying your method break things)

 As long as all dependency packages are binNMUed using the standard
 procedure, the same librime-dev is sufficient and simple.

 Let's review what your reference say:

  [1] https://wiki.debian.org/TransitionBestPractices

 The first reminder is:

 If there's a backward-incompatible ABI change (binary incompatibility)
 which prevents old programs from working with the new library: you need
 to change the library soname, and you need to change the library package
 name, but you usually should not change the -dev package name.
   ^

  [2]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
 Hmmm... not therer but look at:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952

 1. -DEV package names

 Package maintainer has two options when naming a shared library -DEV
 package.
 ...  This document is neutral on which method to deploy.

 You did not present rationale to do extrastep with the second option.

There seems to be something more than ABI break.
librime 1.0 modified several struct member definitions, eg., in the
definition of RimeMenu in include/rime_api.h. Is it an API break?
If yes, then we should rename, in my opinion. (By the way, other
source code imcompatibilities may exist, as indicated in the
ChangeLog, while source code compatibility is largely
maintained with the exception ...)

quote from [2]
 If it only requires a source rebuild, it is called a ABI breakage.
 When even a rebuild is not enough, and there is a source-level
 change required for applications to work with the new version
 of the library, it is called a API breakage, and a different -DEV
 package name should be chosen for the new version of the
 shared library package.

[2]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi


 I see
 librime1 (= ${source:Version}), librime1 ( ${source:Version}+1~)

 This seems binNMU unsafe.  Please drop max version limitation.


Dropped as in c84e9eb.

http://anonscm.debian.org/gitweb/?p=pkg-ime/librime.git;a=commitdiff;h=c84e9eb4e31887ab68df7fbbe4599bfed753a27a;hp=5c651d8d3974b95a8592f1bb8fec05f0bf419d70

Regards,

Yixuan

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Sun, Jun 29, 2014 at 8:32 AM, Osamu Aoki osamu_aoki_h...@nifty.com
wrote:

 Hi,

 On Sun, Jun 29, 2014 at 02:11:18AM -0400, Guo Yixuan wrote:
  On Mon, Jun 23, 2014 at 8:03 AM, Osamu Aoki osamu_aoki_h...@nifty.com
   You did not present rationale to do extrastep with the second option.
 
  There seems to be something more than ABI break.
  librime 1.0 modified several struct member definitions, eg., in the
  definition of RimeMenu in include/rime_api.h. Is it an API break?
  If yes, then we should rename, in my opinion. (By the way, other
  source code imcompatibilities may exist, as indicated in the
  ChangeLog, while source code compatibility is largely
  maintained with the exception ...)

 Very good.  this is what I wanted to hear.

   I see
   librime1 (= ${source:Version}), librime1 ( ${source:Version}+1~)
  
   This seems binNMU unsafe.  Please drop max version limitation.

 Very good.

 I added few lines to debian/rules for stable build test with
 debian/rules etc.

 I also checked source with debmake -k
 === debian/copyright checked for 260 data ===
 Pattern #00: *
   File: thirdparty/src/opencc-windows/opencc.h
 thirdparty/src/opencc-windows/opencc_types.h
 - GPL-3
 + Apache-2.0

 Pattern #02: thirdparty/include/X11/*
   File: thirdparty/include/X11/keysymdef.h
 thirdparty/include/X11/keysym.h
 - MIT
 + ISC

 Pattern #03: thirdparty/include/msvc/*
   File: thirdparty/include/msvc/stdint.h
 - BSD-3-clause
 + BSD-3-Clause

 The first one is positively wrong.  licensecheck command also agrees with
 me.

 Second one is one of the MIT but it is more like ISC than Expat.
 Usually Expat is marked as MIT. (Minor problem)
 Expat: Permission is hereby granted  ...
 ISC:  Permission to use, copy, modify, ...
 (Included MIT liocense does not match source having ISC.)

 The last one is a false positive.  Minor case difference between:
  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
  http://spdx.org/licenses/

 Also DEP-5 has been adoped as
 http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

 So I made minor adjustments in GIT for these.

 Also, what are you going to do with curl.exe etc.  I can not sponsor
 upload of package with binary blob.  In future, we need to consider
 automating this.  Please read
 http://www.eyrie.org/~eagle/notes/debian/git.html
 https://wiki.debian.org/BenFinney/software/repack


For this, I think it's easier to add a Files-Excluded line to
debian/copyright
header, and let uscan do the repacking: [1]

Files-Excluded: thirdparty/bin/curl.exe
thirdparty/src/opencc-windows/opencc.dll
thirdparty/src/opencc-windows/opencc.exe
thirdparty/src/opencc-windows/opencc_dict.exe

In addition, we should add +dfsg to the package version, so it should
be 1.1+dfsg-1, and we need to add some mangle rules to debian/watch.

[1] https://wiki.debian.org/UscanEnhancements

(Sorry I didn't have the time to do this yet.)

I took care these manually for now.

 I will push this to GIT for now:

 Oops, lintian gives me:

 E: librime source: weak-library-dev-dependency librime1-dev on librime1
 (= ${source:Version})
 N:
 N:The given package appears to be a shared library -dev package, but
 the
 N:dependency on what seems to be a corresponding shared library package
 N:does not force the same package version. To ensure that compiling and
 N:linking works properly, and that the symlinks in the -dev package
 point
 N:to the correct files in the shared library package, a -dev package
 N:should normally use (= ${binary:Version}) for the dependency on the
 N:shared library package.
 N:
 N:Sometimes, such as for -dev packages that are
 architecture-independent
 N:to not break binNMUs or when one doesn't want to force a tight
 N:dependency, a weaker dependency is warranted. Something like (=
 N:${source:Upstream-Version}), ( ${source:Upstream-Version}+1~),
 N:possibly using ${source:Version} instead, is the right approach. The
 N:goal is to ensure that a new upstream version of the library package
 N:doesn't satisfy the -dev package dependency, since the minor version
 of
 N:the shared library may have changed, breaking the *.so links.
 N:
 N:Refer to Debian Policy Manual section 8.5 (Dependencies between the
 N:packages of the same library) for details.
 N:
 N:Severity: important, Certainty: possible
 N:
 N:Check: control-file, Type: source

 Let me think ... I may have been wrong.

 Now you also need to update ibus/fcits-rime.


I think these two packages are already updated to the new API.
I'll double check it soon, and update fcitx-rime to 0.3.1.

Cheers,

Yixuan

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Sun, Jun 29, 2014 at 12:11 PM, Osamu Aoki osamu_aoki_h...@nifty.com
wrote:

 On Sun, Jun 29, 2014 at 11:30:52AM -0400, Guo Yixuan wrote:
  For this, I think it's easier to add a Files-Excluded line to
  debian/copyright
  header, and let uscan do the repacking: [1]
 
  Files-Excluded: thirdparty/bin/curl.exe
  thirdparty/src/opencc-windows/opencc.dll
  thirdparty/src/opencc-windows/opencc.exe
  thirdparty/src/opencc-windows/opencc_dict.exe

 Great!  Please update GIT.


Just pushed several commits to GIT. (So uscan + git-import-orig
should work now.)


   In addition, we should add +dfsg to the package version, so it should
  be 1.1+dfsg-1, and we need to add some mangle rules to debian/watch.

 Yep.  This is what I did before uploading.  It is in NEW.


Thank you, I just noticed it in the new queue.

If you find issues, please tell me to reupload another version.

  I think these two packages are already updated to the new API.
  I'll double check it soon, and update fcitx-rime to 0.3.1.

 Please.


I just updated fcitx-rime to 0.3.1 and it works without any obvious
problems or regressions. For ibus-rime, Qijiang did the update, which
I also tried. The only problem is that the icons in the status panel/bar
show up incorrectly, perhaps caused by some missing icon files.

By the way, can I added myself to the uploaders in librime and fcitx-rime?

Cheers,

Yixuan

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Sun, Jun 29, 2014 at 1:28 PM, Guo Yixuan culu@gmail.com wrote:

 On Sun, Jun 29, 2014 at 12:11 PM, Osamu Aoki osamu_aoki_h...@nifty.com
 wrote:

 On Sun, Jun 29, 2014 at 11:30:52AM -0400, Guo Yixuan wrote:
  For this, I think it's easier to add a Files-Excluded line to
  debian/copyright
  header, and let uscan do the repacking: [1]
 
  Files-Excluded: thirdparty/bin/curl.exe
  thirdparty/src/opencc-windows/opencc.dll
  thirdparty/src/opencc-windows/opencc.exe
  thirdparty/src/opencc-windows/opencc_dict.exe

 Great!  Please update GIT.


 Just pushed several commits to GIT. (So uscan + git-import-orig
 should work now.)


   In addition, we should add +dfsg to the package version, so it should
  be 1.1+dfsg-1, and we need to add some mangle rules to debian/watch.

 Yep.  This is what I did before uploading.  It is in NEW.


 Thank you, I just noticed it in the new queue.


The only problem for using uversionmangle is:

I: librime source:
debian-watch-file-should-dversionmangle-not-uversionmangle line 3
N:
N:The version of this package contains dfsg, ds, or debian, but a
N:misleading upstream version mangling occurs in the debian/watch file.
N:Since the dfsg string is not part of the upstream version and its
N:addition is Debian-specific, the the debian/watch file should use the
N:dversionmangle option to remove, instead of adding in uversionmangle,
N:the dfsg before comparing version numbers.
N:
N:Refer to http://wiki.debian.org/DEHS for details.
N:
N:Severity: wishlist, Certainty: certain
N:
N:Check: watch-file, Type: source

But if we use dversionmangle instead of uversionmangle,
then the renamed origin tarball has name librime_1.1.orig.tar.gz,
 which needs to be manually renamed to librime_1.1+dfsg.orig.tar.gz.

A related bug is here. [1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748465

Cheers,

Yixuan

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[GUO Yixuan]

On Sun, Jun 22, 2014 at 08:27:12PM +0900, Osamu Aoki wrote:
 
 On Sun, Jun 22, 2014 at 01:45:32AM +0800, Aron Xu wrote:
  On Sun, Jun 22, 2014 at 1:33 AM, GUO Yixuan culu@gmail.com wrote:
   I'm just waiting for a confirmation on the librime-dev = librime1-dev
   renaming, from Aron, as we discussed in a previous thread. [1]
  
  
  As said before, I don't have strong opinion on either way.
 
 My popsition is that you have not presented enough reason to do this.
 So do not do this.

I remember one possible reason: librime 1.0 breaks some ABI and API
compatibility, so we should change the -dev package name. [1][2]

quote form ChangeLog:
 15 2013-11-10  GONG Chen  chen@gmail.com
 16 
 17 * rime_api: version 1.0 breaks ABI compatiblility.
 18 
 19 the minimum changes in code required to migrate from rime 0.9 api is
 20 to initialize RimeTraits with either RIME_STRUCT or 
RIME_STRUCT_INIT macro.
 21 
 22 while source code compatibility is largely maintained with the 
exception
 23 of the aforementioned RimeTraits structure, rime 1.0 introduces a 
version
 24 controlled RimeApi structure which provides all the api functions.

[1] https://wiki.debian.org/TransitionBestPractices
[2] 
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

   In addition, because the symbol files are not useful, should we create
   a shlibs file?
  
   [1] 
   https://lists.alioth.debian.org/pipermail/pkg-ime-devel/2014-May/004168.html
  
  
  Don't think it's so useful nowadays, either use symbols or don't use
  anything in normal cases.
 
 Hmmm... I think if we drop the symbol file, packaging tool chain
 automatically generates the shlibs file.   Please look into your
 generated binary package to verify :-)  I see it there.
 
 I suggest you to add the following at the top of debian/rules file if
 you have not.  I am doing this for all my new upload (see ibus).
 
 # See dpkg-buildflags(1)
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 This also helps you to test build consistently etc.  This is good idea
 for the newer dpkg(1.16.1).
 
 See explantion in the EXAMPLES section of dpkg-buildflags(1) manpage.

Thank you! I'll check it out.

Cheers,

Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750623: [Pkg-ime-devel] Bug#750623: What is the hold-up of uploadin new package

[GUO Yixuan]

Hi,

On Sat, Jun 21, 2014 at 03:39:39PM +0900, Osamu Aoki wrote:
 Hi,
 
 Why are not we uploading the new librime?
 
 Osamu

I'm just waiting for a confirmation on the librime-dev = librime1-dev
renaming, from Aron, as we discussed in a previous thread. [1]

In addition, because the symbol files are not useful, should we create
a shlibs file?

[1] https://lists.alioth.debian.org/pipermail/pkg-ime-devel/2014-May/004168.html

By the way, the misalignment problem [2] is still under investigation,
but it shouldn't block our upload.

[2] https://code.google.com/p/rimeime/issues/detail?id=623

Cheers,

Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: librime-dev: not installable on sid

[GUO Yixuan]

Hi,

On Sat, Jun 07, 2014 at 01:18:53AM +0900, Osamu Aoki wrote:
 Hi,
 
  On Thu, Jun 05, 2014 at 07:35:56AM +0200, Ralf Treinen wrote:
  Package: librime-dev
  Version: 0.9.9-1
  Severity: grave
  User: trei...@debian.org
  Usertags: edos-outdated
  
  librime-dev can no longer be installed in sid since it depends on
  librime0  0.9.9-1+1~. However, the version of librim0 in sid is
  0.9.9-1+b1.
 
 This seems to be not-so-correct package dependency in the debian/control
 case which breaks with binNMU.

It seems to be no binNMU-safe way for a maximum version dependency (=),
from arch: all to arch: any. [1] However, we can change librime-dev to
be arch: any, and solve this problem. (This is also required for an
migration to multiarch.)

[1] https://wiki.debian.org/binNMU
 
  Since librime-dev is architecture=all it needs a sourceful upload.
 
 Now that upstream has 1.1 out there, it is time to upload new upstream
 package anyway.  Hmmm... it seems Guo Yixua is working in GIT.
 
 Regards,
 
 Osamu

There's only one problem about the renaming, and hopefully we can upload
soon.

Regards,

Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739663: Processed: libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7

[GUO Yixuan]

Control: tag -1 + pending

Hi,

On Sat, Feb 22, 2014 at 11:13:01PM +0100, Andreas Beckmann wrote:
 On 2014-02-21 19:02, Gianfranco Costamagna wrote:
  I think because now boinc-dev is not a real package anymore, just a 
  transition virtual package.
 
 no it's not virtual, only transitional ...
 
  This probably breaks if I torture-test it :-) And it will definitely
  break in case you add a transitional boing-dev package.
 
  
  mmm this is something I don't understand,
 
 with boinc-dev being a transitional package things need to be done the
 correct way
 
  and moreover the problem is that I manually try to upgrade packages with 
  dpkg, and in this case I needed to add manually libboinc7 IIRC to the 
  list.
 
 Running
   dpkg -i pkg1.deb pkg2.deb ...
 does not respect dependency ordering. You need to use a local repository
 and apt-get install for sane upgrade path tests.
 
  So I don't know exactly how to test for this bug, this is why help is 
  really needed ;)
 
 Can you push the pending stuff (e.g. Replaces in addition to Breaks) to git?
 So I can build the package from git and push it into my piuparts engine.
 
 
 Andreas

I've just corrected our debian/control[.in] file, and had an successful
upgrade from wheezy to this current version.

The commit is at 
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=49f36c765fcde2a9cc9dd179fd9932a0c02af1b8;hp=ac94be23b771e086fcd15121a72f878325bd2bc5

Thank you for your kind help on this bug!

Cheers,

GUO Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730821: libsunpinyin3: fails to convert ue and iong syllables and crashes

[GUO Yixuan]

Control: forwarded -1 https://github.com/sunpinyin/sunpinyin/issues/42

On Fri, Feb 21, 2014 at 10:46:50PM -0500, Lingzhu Xiang wrote:
 I bisected the regression and opened a bug upstream
 https://github.com/sunpinyin/sunpinyin/issues/42.
 
 Lingzhu Xiang
 

Thank you!

GUO Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729148: Memory corruption vulnerability when using AES-GCM

[GUO Yixuan]

Hi,

On Sat, Nov 09, 2013 at 04:08:50PM +0100, Patrick Godschalk wrote:
 Package: openssh-server
 Version: 1:6.2p2-6~bpo7
 Severity: grave
 Tags: patch, security, fixed-upstream
 
 The recent security advisory from OpenSSH upstream dated 2013-11-07
 mentions that a memory corruption vulnerability exists in the
 post-authentication sshd process when an AES-GCM cipher
 (aes128-...@openssh.com or aes256-...@openssh.com) is selected during
 kex exchange.
 
 If exploited, this vulnerability might permit code execution with the
 privileges of the authenticated user and may therefore allow bypassing
 restricted shell/command configurations.
 
 This only applies to OpenSSH 6.2 and 6.3 built against OpenSSL
 supporting AES-GCM. It has been fixed in upstream, OpenSSH 6.4.
 

This seems to be the same as #729029?

Cheers,

GUO Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701380: boinc: ftbfs with eglibc-2.17

[GUO Yixuan]

Control: fixed -1 7.0.65+dfsg-1

Marked as fixed in the current version in sid.

Regards,

GUO Yixuan

於 2013年05月07日 23:48, Gianfranco Costamagna 提到:
 This bug have been fixed between 7.0.36 and 7.0.38.
 You can see both changelogs (on ubuntu raring, not the same configuration but 
 the same changelog)
 https://launchpadlibrarian.net/121599012/buildlog_ubuntu-raring-amd64.boinc_7.0.36%2Bdfsg-3_FAILEDTOBUILD.txt.gz
 https://launchpadlibrarian.net/121666774/buildlog_ubuntu-raring-amd64.boinc_7.0.36%2Bdfsg-4~raring1_BUILDING.txt.gz


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707375: boinc-app-seti: FTBFS: config.h:584:38: fatal error: project_specific_defines.h: No such file or directory

[GUO Yixuan]

Control: reassign src:boinc 7.0.65+dfsg-1
Control: affects -1 boinc-app-seti

Hi,

於 2013年05月09日 15:16, Lucas Nussbaum 提到:
 Source: boinc-app-seti
 Version: 6.97~svn1409-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20130509 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
...
 In file included from /usr/include/boinc/lib/str_replace.h:24:0,
  from main.cpp:73:
 /usr/include/boinc/config.h:584:38: fatal error: project_specific_defines.h: 
 No such file or directory
 compilation terminated.
 make[3]: *** [seti_boinc-main.o] Error 1
 

This is a known bug of boinc (libboinc-app-dev), which is fixed in the
next upload (7.0.65+dfsg-2).

Cheers,

GUO Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692119: {cpp, gfortran, gnat}-4.4-doc: copyright file missing after upgrade (policy 12.5)

[Guo Yixuan]

Control: tag -1 + pending

On Fri, Nov 02, 2012 at 12:39:53PM +0100, Andreas Beckmann wrote:
 Package: cpp-4.4-doc,gfortran-4.4-doc,gnat-4.4-doc
 Version: 4.4.7-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 
 Hi,
 
 a test with piuparts revealed that your package misses the copyright
 file after an upgrade from squeeze to sid, which is a violation of
 Policy 12.5:
 http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
 
 After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
 
 From the attached log (scroll to the bottom...):
 (from 'ls -lad /u/s/d/$PKG' and 'ls -la /u/s/d/$PKG/')
 
 0m43.8s ERROR: Command failed (status=1): ['chroot', 
 '/tmp/piupartss/tmpJFzIXk', 
 'tmp/scripts/pre_remove_50_find_missing_copyright']
   MISSING COPYRIGHT FILE: /usr/share/doc/cpp-4.4-doc/copyright
   drwxr-xr-x 2 root root 40 Oct 30 12:51 /usr/share/doc/cpp-4.4-doc
   total 0
   drwxr-xr-x  2 root root   40 Oct 30 12:51 .
   drwxr-xr-x 81 root root 1720 Oct 30 12:51 ..
 
 
 Additional info may be available here:
 http://wiki.debian.org/MissingCopyrightFile

Thanks for the tips, fixed in commit 7a4dd69.

[1] http://git.debian.org/?p=users/yixuan-guest/gcc-doc.git

GUO Yixuan


signature.asc
Description: Digital signature

Bug#691074: gcc-doc: Depends on docs for wrong gcc version

[Guo Yixuan]

Hi,

On 10/23/2012 09:35 AM, Samuel Bronson wrote:
 On Oct 21, 2012, at 12:34 AM, Guo Yixuan wrote:
 The packages in unstable are updated to 4.7 (or 4.6 on some archs)[1],
 
 I actually knew this; I can't think why I didn't say so in the report.
 
 and waiting for release team's unblock grant.
 
 This part I didn't know. Thanks!
 
 Thanks, also, for picking up where I got frustrated; I was delighted
 when I noticed the updates in aptitude.  (Though I was a bit puzzled
 when I saw that I was listed as maintainer; at first I thought I must be
 looking at the wrong version of the package or something -- I would have
 only expected credit in the changelog and such. ;-)

Thank you. :) Then I'm taking over the maintenance, and the next upload
of gcc-4.[67]-doc will list me as maintainer, and you in uploaders.[1] I
plan to remove you from uploaders in wheezy+1 (jessie), is this ok?

[1] http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git

 Sorry I've been hard to reach; I've been having trouble dealing with my
 email for the past year or so; gmail seems to eat all my RAM lately, and
 clients never seem to really grok gmail's IMAP.
 
 I tried to make it clear that I was happy for anyone to take this
 packaging over, but there wasn't any obvious central location in which
 to do that.

I think wnpp is the place. It's where you publish ITP, RFP and so on,
and you can simply retitle an ITP to an RFP to notify others.

Cheers,

Guo Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691074: gcc-doc: Depends on docs for wrong gcc version

[Guo Yixuan]

Control: block -1 by 689967

Hi Samuel,

On 10/21/2012 09:54 AM, Samuel Bronson wrote:
 Package: gcc-doc
 Version: 5:3
 Severity: serious
 
 Dear Maintainer,
   I've noticed that gcc-doc is still depending on the documentation for
 the aging GCC 4.4...

The packages in unstable are updated to 4.7 (or 4.6 on some archs)[1],
and waiting for release team's unblock grant.

[1] http://packages.debian.org/sid/gcc-doc
[2] http://packages.qa.debian.org/g/gcc-doc-defaults.html

Regards,

Guo Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688713: timidity-daemon: mishandles conffiles

[Guo Yixuan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/12/2012 02:36 AM, Sébastien Villemot wrote:
 Control: tags -1 + pending
 
 Dear Maintainers,
 
 Andreas Beckmann deb...@abeckmann.de writes:
 
 Package: timidity-daemon Version: 2.13.2-40 Severity: serious 
 User: debian...@lists.debian.org Usertags: piuparts
 
 during a test with piuparts I noticed your package mishandles 
 conffiles. This is violates the policy, see 
 http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files



 
I miserably failed to understand that the maintainer scripts were to do,
 the only thing I can say for sure is that the conffile 
 /etc/init.d/timidity is removed during the remove step of the 
 package (which is wrong, because configuration must be preserved 
 after remove, and needs to be clened up during purge only.
 
 And that will fail in the following scenario:
 
 install timidity-daemon remove (don't purge!) timidity-daemon 
 install timidity-daemon
 
 Now /etc/init.d/timidity is missing (as dpkg will not restore 
 deleted configuration files as that is usually a user choice the 
 should be preserved).
 
 I have uploaded to DELAYED/2 a NMU of timidity versioned 
 2.13.2-40.1 which fixes that bug. The debdiff is attached. Don't 
 hesitate to tell me if I should delay the upload longer.

Thank you for uploading a NMU.

 Guo: Thanks for your contribution. I did not directly upload your 
 patch for two reasons. First it was buggy since it was removing
 the call to invoke-rc.d timidity stop in prerm remove, and
 this call has to stay there.

OK, it indeed needs this. However, I found that dh_installinit already
provided this by default in prerm:

# Automatically added by dh_installinit
if [ -x /etc/init.d/timidity ]  [ $1 = remove ]; then
invoke-rc.d timidity stop || exit $?
fi
# End automatically added section

 Second it was making unnecessary changes related to 
 /etc/timidity/timidity.daemon, which is no longer shipped in the 
 package (it seems to predate squeeze); NMUs have to change the 
 minimal amount of code in order to fix the bug. But indeed, as 
 Andreas has noted, a lot of obsolete stuff could probably be 
 removed from the maintainer scripts.

I see that NMU prefer to be minimal. Maybe my patch will still be
useful in case of a maintainer upload.

Cheers,

Guo Yixuan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJQd3upAAoJEN1xpgAgL7gzZ0sP/A6qJlvwDZuiT6VSiTuZIqZO
m1eqRh3ZE1ZKP3oXElzHZqbr78YQ0inPVRl/rc5he2ev4bzXhD2oIwHTvF6JvGO2
H4rJCQ/UJBHdOSQbSD87Crm8zAdTxc+E7cM38/Ry7fj4EP1VZum9lnMOsR9adEL4
JG05mwEUQ/+F//ZKAVez+USQBvCskdAMXvobJvTJ63fnbcqvKUttni5SQcLgyqSE
uXxmvwB8GPdflTwBNQGgO3Qak9zW6EClVeRf72JybOU38IEV0prMHGv/7L3WmwQQ
UMbAu5YzUYdnbKBP7Cwe6j9J3xf7CYbdtxlk7+eNGICym5q4gtv2JAV3eQTtVDuo
4gsZzGT71Zn4qn46LsSlgTQHL3yux9kOVOnU3jka9kkRg8D4CNdvWC/Qt4x8YADD
3oFV0KGOaIQhYd5KbxIT4T7SAAh62S88/7wdcGLQJyVpJOjMCThhgXdaiiiUNYJ8
BLM5XjqSxDVpf0NUYz7QxDIwhnhiTQas8DFbKYxCHPSVA8vJ6e8s+6tlYZLBkXcN
lhIoUnUhHEWM4V4PcEhQl5OC+5FbiL8huNMlz6sM2VBzhgn5NfvpNrqNrtNszBta
S5UxPDpj77a2DlGuiUCM2MxoXHVYxKu0855WBYcOPsPfjixYmUnrmfKzeNxhz7CP
MDjc7xZHS2e30rnOrlcD
=p9pU
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649344: timidity: embedded fork of libmikmod needs to be dealt with

[Guo Yixuan]

severity 649344 important
thanks

Hi,

I'm lowering severity, for policy 4.13 is a should, and violations of
it are not considered release critical.

Regards,

Guo Yixuan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688713: Patch to fix conffile handling

[Guo Yixuan]

tag 688713 + patch
thanks

Hi,

I tried to fix this bug. In this patch, dpkg-maintscript-helper is used
instead of old rm_conffile(). Please see dpkg-maintscript-helper(1) for
its usage.

If you release the fix as 2.13.2-41, then put 2.13.2-41~ as parameter
for dpkg-maintscript-helper should be correct, I guess. You may need to
change the 2.13.2-41~ if it's not the case.

As in:
dpkg-maintscript-helper rm_conffile \
/etc/timidity/timidity.daemon 2.13.2-41~ timidity-daemon -- $@

Cheers,

Guo Yixuan
From 62b51523e6a4d802567358bc3c9758cf9b1e1a9c Mon Sep 17 00:00:00 2001
From: Guo Yixuan culu@gmail.com
Date: Wed, 26 Sep 2012 11:48:31 +0800
Subject: [PATCH] fix

---
 timidity-daemon.postinst |3 ++-
 timidity-daemon.postrm   |   10 ++
 timidity-daemon.preinst  |3 +++
 timidity-daemon.prerm|   42 --
 4 files changed, 15 insertions(+), 43 deletions(-)
 create mode 100644 timidity-daemon.postrm
 delete mode 100644 timidity-daemon.prerm

diff --git a/timidity-daemon.postinst b/timidity-daemon.postinst
index f95270d..166db43 100644
--- a/timidity-daemon.postinst
+++ b/timidity-daemon.postinst
@@ -50,7 +50,8 @@ fi
 ;;
 esac
 
-rm -f /etc/timidity/timidity.daemon
+dpkg-maintscript-helper rm_conffile \
+/etc/timidity/timidity.daemon 2.13.2-41~ timidity-daemon -- $@
 
 # make sure we really stop, because packaging system doesn't
 # understand what we're trying to do with migration to timidity-daemon
diff --git a/timidity-daemon.postrm b/timidity-daemon.postrm
new file mode 100644
index 000..22c3dec
--- /dev/null
+++ b/timidity-daemon.postrm
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+dpkg-maintscript-helper rm_conffile \
+/etc/timidity/timidity.daemon 2.13.2-41~ timidity-daemon -- $@
+
+#DEBHELPER#
+
+exit 0
+
diff --git a/timidity-daemon.preinst b/timidity-daemon.preinst
index afd27ac..ce8e04b 100644
--- a/timidity-daemon.preinst
+++ b/timidity-daemon.preinst
@@ -20,6 +20,9 @@ case $1 in
 ;;
 esac
 
+dpkg-maintscript-helper rm_conffile \
+/etc/timidity/timidity.daemon 2.13.2-41~ timidity-daemon -- $@
+
 # dh_installdeb will replace this with shell code automatically
 # generated by other debhelper scripts.
 
diff --git a/timidity-daemon.prerm b/timidity-daemon.prerm
deleted file mode 100644
index f0b1dd9..000
--- a/timidity-daemon.prerm
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-set -e
-
-rm_conffile() {
-local PKGNAME=$1
-local CONFFILE=$2
-
-[ -e $CONFFILE ] || return 0
-
-local md5sum=$(md5sum $CONFFILE | sed -e 's/ .*//')
-local old_md5sum=$(dpkg-query -W -f='${Conffiles}' $PKGNAME | \
-sed -n -e \' $CONFFILE ' { s/ obsolete$//; s/.* //; p })
-if [ $md5sum != $old_md5sum ]; then
-echo init.d conffile $CONFFILE has been modified by you.
-echo Saving as $CONFFILE.dpkg-bak ...
-mv -f $CONFFILE $CONFFILE.dpkg-bak
-else
-echo Removing init.d conffile $CONFFILE ...
-rm -f $CONFFILE
-fi
-}
-
-case $1 in
-remove)
-if [ -f /etc/init.d/timidity ]; then
-if which invoke-rc.d /dev/null 21; then
-  invoke-rc.d timidity stop
-else
-  /etc/init.d/timidity stop
-fi
-fi
-
-rm_conffile timidity-daemon /etc/init.d/timidity
-rm_conffile timidity-daemon /etc/timidity/timidity.daemon
-
-;;
-esac
-
-#DEBHELPER#
-
-exit 0
-
-- 
1.7.10.4

Bug#675839: boinc-app-seti: FTBFS[kfreebsd]: error: 'floor' was not declared in this scope

[Guo Yixuan]

tags 675839 + pending
thanks

Hi,

On 06/04/2012 12:14 AM, Christoph Egger wrote:
 Package: src:boinc-app-seti Version: 6.12~svn1305-2 Severity: serious
 Tags: sid wheezy User: debian-...@lists.debian.org Usertags: kfreebsd
 X-Debbugs-Cc: debian-...@lists.debian.org Justification: fails to
 build from source (but built successfully in the past)
 
 Hi!
 
 Your package failed to build on the kfreebsd-* buildds:
 
 vector/analyzeFuncs_sse.cpp: In function 'int
 sse1_ChirpData_ak(float (*)[2], float (*)[2], int, double, int,
 double)': vector/analyzeFuncs_sse.cpp:782:62: error: 'floor' was not
 declared in this scope vector/analyzeFuncs_sse.cpp: At global scope:
  vector/analyzeFuncs_sse.cpp:1299:91: warning: deprecated conversion 
 from string constant to 'char*' [-Wwrite-strings] 
 vector/analyzeFuncs_sse.cpp:2252:82: warning: deprecated conversion 
 from string constant to 'char*' [-Wwrite-strings] 
 vector/analyzeFuncs_sse.cpp:2265:1: warning: 'typedef' was ignored
 in this declaration [enabled by default] 
 vector/analyzeFuncs_sse.cpp:2556:82: warning: deprecated conversion 
 from string constant to 'char*' [-Wwrite-strings] make[3]: *** 
 [seti_boinc-analyzeFuncs_sse.o] Error 1

We added a patch[1], and think it will fix this error.

[1]
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc-app-seti.git;a=blob;f=debian/patches/101_freebsd_build.patch;h=e02e9a8a4bc14f33d33ab41e19fdbfa8bf10bce4;hb=8dc89b3126d80321134311930e3464845db00174

Cheers,

Guo Yixuan



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org