Bug#857917: RM: golang-gocheck -- RoQA; duplicated package exists; RC buggy
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org 在 2017-03-16四的 19:05 +0800，Boyuan Yang写道： > Package: ftp.debian.org > Severity: normal > "build-rdeps golang-gocheck" shows no no reverse dependencies for > unstable. Sorry but I forgot that golang-gocheck is a source package. "build- rdeps golang-gocheck-dev" shows 4 results: Reverse Build-depends in main: -- golang-github-masterzen-simplexml golang-github-masterzen-xmlpath golang-go-dbus golang-go-xdg The first two packages have switched to golang-check.v1-dev already. They are not affected. golang-go-xdg already has a pending RFS open (#854395) in order to fix the bug, but currently blocked due to Stretch freeze. I will file a bug against golang-go-dbus to block this RM request. -- Sincerely, Boyuan Yang
Bug#904793: RFS: libskk/1.0.4-2
Package: sponsorship-requests Severity: normal X-Debbugs-CC: debian-input-met...@lists.debian.org Dear mentors and debian-input-method team members, I am looking for a sponsor for team package "libskk". * Package name: libskk Version : 1.0.4-2 Upstream Author : Daiki Ueno * URL : https://github.com/ueno/libskk/ * License : GPL-3+ Section : libs It builds those binary packages: gir1.2-skk-1.0 - library to deal with Japanese kana-kanji conversion method - introspection libskk-common - library to deal with Japanese kana-kanji conversion method - common files libskk-dev - library to deal with Japanese kana-kanji conversion method - development libskk-utils - program that emulates Japanese SKK input method libskk0- library to deal with Japanese kana-kanji conversion method To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libskk Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libs/libskk/lib skk_1.0.4-2.dsc Git packaging repository: https://salsa.debian.org/input-method-team/libskk.git Changes since the last upload: libskk (1.0.4-2) unstable; urgency=medium . * debian/control: - Drop backported patches since they are not merge into master branch and were introduced accidentally. - Remove introduced build-dependency libxcbcommon-dev. - Remove Daiki Ueno from Uploaders list. (Closes: #903251) Thank you for your previous contributions! + Add myself as Uploader. + Use git repository under Salsa input-method-team group. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#904794: RFS: fcitx-anthy/0.2.3-2 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-input-met...@lists.debian.org Dear mentors and debian-input-method list members, I am looking for a mentor for team package "fcitx-anthy". * Package name: fcitx-anthy Version : 0.2.3-2 Upstream Author : Weng Xuetian * URL : https://gitlab.com/fcitx/fcitx-anthy * License : GPL-2+ Section : utils It builds those binary packages: fcitx-anthy - Fcitx wrapper for Anthy IM engine To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fcitx-anthy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fcitx-anthy/f citx-anthy_0.2.3-2.dsc Git packaging repository: https://salsa.debian.org/input-method-team/fcitx-anthy.git Changes since the last upload: fcitx-anthy (0.2.3-2) unstable; urgency=medium . * Team upload. * debian/control + Update maintainer address and use input-method team mailing list (Closes: #899498). + Update email address for YunQiang Su and use the @debian.org one. + Bump Standards-Version to 4.1.5 (no changes needed) + Update Vcs fields with git repo on Salsa platform + Bump debhelper compat to v11. + Update homepage field and use the project on GitLab.com. * debian/rules: Modernize file and explicitly use architecture.mk. * debian/copyright: Refresh information. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#842652: fcitx-qt5: Possible uneeded build dependency on qtbase5-private-dev
X-Debbugs-CC: perezme...@gmail.com a...@debian.org On Mon, 05 Dec 2016 15:37:29 -0300 Lisandro Damián Nicanor Pérez Meyer" wrote: > On domingo, 4 de diciembre de 2016 18:44:21 ART Aron Xu wrote: > > Unfortunately no, at least the use of IID in fcitx-qt5 is not yet in > > public headers... > > Would it be possible for you to identify the private methods used? > The package should automatically gain a dependency on qtbase-x-y-z, but it is > not there. % apt-cache showsrc fcitx-qt5 | grep frontend Binary: fcitx-frontend-qt5, libfcitx-qt5-1, libfcitx-qt5-dev, libfcitx-qt5- data, fcitx5-module-quickphrase-editor fcitx-frontend-qt5 deb libs optional arch=any % apt-cache show fcitx-frontend-qt5 | grep 'Version' Version: 1.2.2-2 % apt-cache show fcitx-frontend-qt5 | grep 'abi' Depends: fcitx-module-dbus, libc6 (>= 2.14), libgcc1 (>= 1:3.0), libqt5core5a (>= 5.10.0), libqt5dbus5 (>= 5.0.2), libqt5gui5 (>= 5.9.0~beta), libstdc++6 (>= 4.8), libxkbcommon0 (>= 0.5.0), qtbase-abi-5-10-0 It seems that fcitx-qt5 is correctly using Qt private headers. As a result, I am closing this bug. -- Thanks, Boyuan Yang
Bug#879908: RFS: xcb-imdkit/0~20171020-1 [ITP] -- XIM protocol implementation in XCB
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: pkg-ime-de...@lists.alioth.debian.org a...@debian.org Dear mentors and pkg-ime maintainers, I am looking forward for a sponsor for my package "xcb-imdkit" * Package name: xcb-imdkit Version : 0~20171020-1 Upstream Author : Weng Xuetian * URL : https://github.com/wengxt/xcb-imdkit * License : LGPL-2.1+ Section : libs It builds those binary packages: libxcb-imdkit-dev - XIM protocol implementation in XCB (development files) libxcb-imdkit0 - XIM protocol implementation in XCB To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xcb-imdkit Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xcb-imdkit/xc b-imdkit_0~20171020-1.dsc Git packaging repository: https://anonscm.debian.org/git/collab-maint/xcb-imdkit.git Changes since the last upload: xcb-imdkit (0~20171020-1) unstable; urgency=low . * Initial snapshot. Closes: #877678. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#914190: yaml-cpp: diff for NMU version 0.5.3-0.2
X-Debbugs-CC: j...@debian.org 在 2018-11-21三的 17:37 +0100，Julian Andres Klode写道： > Actually, I missed a bit in the diff. Hi Julian, By making the NMU, you actually started an uncoordinated transition [1]. Since you initiated it, do you have time registering this transition with the Release Team so that the rebuild could be finished in time? Thanks, Boyuan Yang [1] https://release.debian.org/transitions/html/auto-yaml-cpp.html
Bug#911904: Processed: block 911904 with 911915
Hi all, 在 2018-10-26五的 13:49 +0200，Michal Čihař写道： > Hi > > On Fri, 2018-10-26 at 10:51 +0200, Ondřej Surý wrote: > > LIBTIDY_LIBRARY=$(shell readlink -f > > /usr/lib/$(DEB_HOST_MULTIARCH)/libtidy.so) > > Well it all started from this file being absent from the package :-) > > > LIBTIDY_PACKAGE=$(shell dpkg-query --search $(LIBTIDY_LIBRARY) | cut > > -f 1 -d :) > > LIBTIDY_LIBRARY_FILE$(shell basename $(LIBTIDY_LIBRARY)) > > > > then > > > > sed -e “s/libtidy.so/$(LIBTIDY_LIBRARY_FILE)” lib.py > > > > echo libtidy:Depends=$(LIBTIDY_PACKAGE) > python-utidylib.substvars > > > > and replace > > > > libtidy5deb1 | libtidy5, > > I don't get what this would solve - there is nothing wrong with > alternate dependecies as long as they both provide libtidy.so. Anyway > same is in Build-Depends as well, where substvars are not really > helpful. So what will be the final solution? I'm wondering if we could solve the problem soon to complete the transition. BTW I see the advantage of automatically generating lib dependency; however, I also believe that listing alternate dependencies should be okay as well since it extends the compatibility range of binary package. Manual adjustment will be necessary in each transition but as long as the package maintainer is comfortable with that, it should be acceptable. -- Regards, Boyuan Yang
