Bug#902159: FWIW: uploaded
For What It's Worth At https://tracker.debian.org/pkg/dvdisaster is visible there was an uplooad of dvdisaster on 2018-06-23.
Help for build-time test failure of libhmsbeagle (phylogeny algorithms using GPU) needed
Hi, I'm trying to update libhmsbeagle[1] to its latest upstream version. Unfortunately I'm running into a build time test where I have no idea how to deal with: ... make[4]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' - make matrixtest make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' g++ -DHAVE_CONFIG_H -I. -I../../libhmsbeagle -I../.. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/java-10-openjdk-amd64/include -I/usr/lib/jvm/java-10-openjdk-amd64/include/linux -O3 -std=c++11 -pthread -g -O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -c -o matrixtest.o matrixtest.cpp /bin/bash ../../libtool --tag=CXX --mode=link g++ -O3 -std=c++11 -pthread -g -O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o matrixtest matrixtest.o ../../libhmsbeagle/libhmsbeagle.la -ldl libtool: link: g++ -O3 -std=c++11 -pthread -g -O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/matrixtest matrixtest.o ../../libhmsbeagle/.libs/libhmsbeagle.so -ldl -pthread make[5]: Leaving directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' e make check-TESTS - make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' make[6]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' md FAIL: matrixtest - libhmsbeagle 3.0.2: examples/matrixtest/test-suite.log # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: matrixtest OpenCL error: CL_INVALID_VALUE from file , line 923. Using resource 1: Rsrc Name : pthread-Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz (OpenCL 1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-haswell) Impl : OpenCL-Single Impl Desc : none FAIL matrixtest (exit status: 255) Before I contact upstream I wonder whether I might have missed some GPU specific things that might help here. Kind regards Andreas. [1] https://salsa.debian.org/med-team/libhmsbeagle -- http://fam-tille.de
Bug#902160: closing 902160
close 902160 thanks
Bug#902159: closing 902159
close 902159 thanks
Bug#902170: RFS: brise/0.38.20180515-1 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-input-met...@lists.debian.org sunwea...@debian.org Dear Mike, debian-input-method members and mentors, As part of bug fixes and package rebuild in Input Method Team, I prepared a team upload for package "brise" and am currently looking for a sponsor for this package. Besides, I am looking for a DD to help create a git repo under Debian group on Salsa platform and grant me (hosiet-guest) the Master role so that I could push and maintain changes there. The whole RIME IME ecosystem will have to undergo an important version bump (1.2.x -> 1.3.x), which requires a joint upload of librime and brise (aka librime-data*). Mentors who intend to sponsor this package should upload those two packages ideally at the same time. recommends librime (>= 1.3) --> brise (>= 0.38) <-- build-depends on Levels of rebuild (and bugfix): Level 1: * libmarisa0 (done), libopencc2 (done) Level 2: * libbkc2 (done), libkkc-data (done), librime1 ^ separate RFS: #902169 Level 3: * brise (aka librime-data*) ^ we are here Level 4: * fcitx-kkc, ibus-kkc, fcitx-rime, ibus-rime, goldendict (out of team but under my control), ibus-libzhuyin * Package name: brise Version : 0.38.20180515-1 Upstream Author : GONG Chen * URL : https://github.com/rime/brise * License : GPL-3 Section : libs It builds those binary packages: librime-data - Rime Input Method Engine, the schema data librime-data-array30 - RIME schema data - array30 librime-data-bopomofo - RIME schema data - Bopomofo (a.k.a Zhu Yin) librime-data-cangjie5 - RIME schema data - Cangjie5 librime-data-combo-pinyin - RIME schema data - Combo Pinyin (a.k.a Gong Bao Pin Yin) librime-data-double-pinyin - RIME schema data - Double Pinyin (a.k.a Zi Ran Ma Shuang Pin) librime-data-emoji - RIME schema data - Emoji librime-data-ipa-xsampa - RIME schema data - X-SAMPA librime-data-jyutping - RIME schema data - jyutping (a.k.a Cantonese) librime-data-luna-pinyin - RIME schema data - Luna Pinyin librime-data-pinyin-simp - RIME schema data - Pinyin Simp (a.k.a Xiu Zheng Jian Hua Pin Yin) librime-data-quick5 - RIME schema data - quick5 librime-data-sampheng - RIME schema data - sampheng (a.k.a Zhong Gu San Pin) librime-data-scj6 - RIME schema data - scj6 (a.k.a Fast Cangjie IM 6) librime-data-soutzoe - RIME schema data - soutzoe librime-data-stenotype - RIME schema data - stenotype librime-data-stroke - RIME schema data - Stroke librime-data-terra-pinyin - RIME schema data - Terra Pinyin (a.k.a Earth Pinyin) librime-data-wubi - RIME schema data - Wubi librime-data-wugniu - RIME schema data - wugniu (a.k.a Shanghai Native Language) librime-data-zyenpheng - RIME schema data - zyenpheng (a.k.a Medieval Chinese) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/brise Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/brise/ brise_0.38.20180515-1.dsc Git packaging repository: (temporary, will be removed after upload) https://salsa.debian.org/hosiet-guest/brise.git Git packaging repository: (proposed, not exist yet) https://salsa.debian.org/debian/brise.git Changes since the last upload: brise (0.38.20180515-1) unstable; urgency=medium . * Team upload. * New upstream release after migration to plum and librime 1.3. - Fix broken config for opencc in luna_pinyin_tw. (Closes: #877714). * Fix FTBFS by limiting required librime version to 1.3+. (Closes: #893386). * Use debian-input-met...@lists.debian.org as maintainer address. (Closes: #899883). * debian: Apply "wrap-and-sort -abst". * d/control: Bump debhelper compat to v11. * d/control: Bump Standards-Version to 4.1.4. * d/control: Use Salsa repo for Vcs fields. * d/control: Set package section to "libs". * d/control: Drop transitional packages librime-data-stroke5, librime-data-stroke-simp, librime-data-triungkox3p. (Closes: #878230). * d/control: Adopt upstream preset list and add three more packages into Recommends list: bopomofo, stroke and terra-pinyin. * d/control: Let all split librime-data-* packages depend on librime-data since librime-data provides some essential common files. * d/copyright: Refresh and rewrite all copyright information. * d/watch: Refresh GitHub project URL. * d/rules: Use "dh_missing --fail-missing". * d/install: Refresh install file list for jyutping and luna-pinyin. * d/patches: Add a patch to fix bashism in plum/Makefile. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#902169: RFS: librime/1.3.1+dfsg1-1 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-input-met...@lists.debian.org sunwea...@debian.org Dear Mike, debian-input-method members and mentors, As part of bug fixes and package rebuild in Input Method Team, I prepared a team upload for package "librime" and am currently looking for a sponsor for this package. The whole RIME IME ecosystem will have to undergo an important version bump (1.2.x -> 1.3.x), which requires a joint upload of librime and brise (aka librime-data*). Mentors who intend to sponsor this package should upload those two packages ideally at the same time. recommends librime (>= 1.3) --> brise (>= 0.38) <-- build-depends on Levels of rebuild (and bugfix): Level 1: * libmarisa0 (done), libopencc2 (done) Level 2: * libbkc2 (done), libkkc-data (done), librime1 ^ we are here Level 3: * brise (aka librime-data*) Level 4: * fcitx-kkc, ibus-kkc, fcitx-rime, ibus-rime, goldendict (out of team but under my control), ibus-libzhuyin * Package name: librime Version : 1.3.1+dfsg1-1 Upstream Author : GONG Chen * URL : https://github.com/rime/librime * License : GPL-3 Section : libs It builds those binary packages: librime-bin - Rime Input Method Engine - utilities librime-dev - Rime Input Method Engine, the core library - development files librime1 - Rime Input Method Engine - core library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/librime Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libr/librime/ librime_1.3.1+dfsg1-1.dsc Git packaging repository: https://salsa.debian.org/debian/librime.git Changes since the last upload: librime (1.3.1+dfsg1-1) unstable; urgency=medium . * New upstream release. * Add myself into uploaders list. * Bump Standards-Version to 4.1.4 (no changes needed). * d/control: Migrate to Salsa platform for Vcs fields. * d/control: Restrict librime-data (brise) version to >= 0.38 to ensure users are using newer br`ise that is compatible with librime 1.3+. * d/patches: Refresh patches and backport several upstream patches. * d/shlibs: Add a shlibs file to ensure link against latest librime library. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#902166: RFS: wifi-qr/0.1.0-1 [ITP, NMU] Please Check and Help for like Android WiFi QR
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wifi-qr" * Package name: wifi-qr Version : 0.1.0-1 Upstream Author : kokoye2...@gmail.com * URL : https://ubuntu-mm.net * License : GPL3 Section : utils It builds those binary packages: wifi-qr- WiFi Share with QR and Connect with QR To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wifi-qr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1.0-1.dsc More information about hello can be obtained from github.com/kokoye2007/wifi-qr I fork idea from Xiaomi Phone Wifi Share and Password Share with QR and QR Scan with Connect. with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master
On 6/22/18 4:17 AM, Fabian Grünbichler wrote: > > as promised, and unfortunately delayed a bit longer than I wanted. > thanks for the initial push - some of the points are more for a > discussion with upstream regarding their inclusion of some variant of > this, some are for debian experimental. > > - compat 12 is IMHO too new for anything except experimental, it's still > subject to change. dh_missing was added in debhelper 10.3. I'll remove the use, and suffer the deprecation warning. > - given the different licences and thus parts of the archive, I am not > sure whether we can merge zfs-dkms and spl-dkms inside Debian It would be a real pity if we had to keep these packages separated. Everything is much easier to maintain and build in a single package. Moreover, actually separating the now-merged upstream packaging is going to be a challenge---and probably will introduce weird bugs. If, for some reason, this must be separated, I think we should consider automatically building these binaries on the user's machine, like say libdvd-pkg, before we consider splitting splitting the packaging: It would be unacceptable to allow a bug in a filesystem driver to be introduced to work around a licensing issue. I'll formulate the question carefully, and submit it to debian-legal. I will say that the CDDL specifically allows for inclusion in a "Larger Work", and similarly, GPL says that "mere aggregation" is insufficient to have the license apply to the rest of it. What *will* be important is making sure that each source file license is properly tracked in copyright---so as to ensure each distributed non-source file be subject to at most one of the two licenses. As for the section: I imagine it would stay in contrib---for the same reasons it was originally placed there. > - which distros do we want to support upstream? Debian Stretch+, Ubuntu > Xenial/Bionic/Cosmic? just the latest ones? I only have experience with Debian. The Ubuntu packaging looks very different---in particular, they look like they build the module with the kernel (https://wiki.ubuntu.com/ZFS). I don't see any reason to try to support that. > - compat 10 or 11? Stretch only has 10 without backports.. I say we target 10. > > debian/rules: > - chmod a-x files should be on separate lines, otherwise git blame is > stupid ;) > - same for copied/installed scripts that need to be listed explicitly > (DKMS) Changed. > - the dmks.mkconf call does not belong into dh_auto_install > (semantically). does it need to be there or can we move it to > dh_auto_configure or dh_auto_build ? why not keep it in > override_dh_dkms? It's in override_dh_dkms, and clean it up there too. > - same for the "make dist" call, which should probably be run before the > build to prevent mistakes in "make dist" from tainting DKMS sources > with build products? Cleaned up as suggested. Might as well, since you've noticed it. > - debian/git-version.sh could benefit from some comments/rationale ;) > - debian/git-version.sh does not handle actual release tags correctly > (the resulting package version is a native one) > - debian/git-version.sh should probably somehow handle adding a > pkgrelease suffix as well? maybe as optional, second parameter > (defaulting to 1), and in case it is ommitted but d/changelog contains > the same version with -1, bump it to -2? This sounds reasonable. I was only ever targeting this script at upstream git snapshots. My use case is a script that just checks out and builds the next git version, making it available for use. > - debian/update-git: it would be cool to pre-populate the changelog with > a shortlog since the previous version (if the previous version matches > either the git-describe or release tag versioning scheme, > alternatively we could just encode the git commit in the changelog > like "gbp dch --snapshot" does?) > git-shortlog should be able to do this relatively easily. I'll get around to these last two points eventually. > I'll do some test builds and check the resulting packages later on - > thanks for getting the ball rolling! > Thanks for looking at this! Antonio
Bug#902160: RFS: dvdisaster/0.79.6-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dvdisaster" * Package name: dvdisaster Version : 0.79.6-2 Upstream Author : Carsten Gnörlich * URL : http://dvdisaster.net/ * License : GPL-3+ Section : otherosfs It builds these binary packages: dvdisaster - data loss/scratch/aging protection for CD/DVD media dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media (documentatio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dvdisaster Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.6-2.dsc Changes since the last upload: dvdisaster (0.79.6-2) experimental; urgency=medium [ TANIGUCHI Takaki ] * Update Vcs-* to salsa.debian.org. [ Carlos Maddela ] * Build with DH compat level 11. * Indicate compliance with Debian Policy 4.1.4. * Add machine-readable upstream metadata. * Update debian/copyright. * Update location of PDF manual registered with doc-base (required as a result of DH compat level change). -- Carlos Maddela Sat, 23 Jun 2018 05:41:03 +1000 Regards, Carlos Maddela
Bug#902159: RFS: dvdisaster/0.79.5-6
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dvdisaster" * Package name: dvdisaster Version : 0.79.5-6 Upstream Author : Carsten Gnörlich * URL : http://dvdisaster.net/ * License : GPL-3+ Section : otherosfs It builds these binary packages: dvdisaster - data loss/scratch/aging protection for CD/DVD media dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media (documentatio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dvdisaster Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.5-6.dsc Changes since the last upload: dvdisaster (0.79.5-6) unstable; urgency=medium [ TANIGUCHI Takaki ] * change Vcs-* path [ Carlos Maddela ] * Build with DH compat level 11. * Indicate compliance with Debian Policy 4.1.4. * Add machine-readable upstream metadata. * Update debian/copyright. * Update location of PDF manual registered with doc-base (required as a result of DH compat level change). -- Carlos Maddela Sat, 23 Jun 2018 05:01:27 +1000 Regards, Carlos Maddela
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Fri, Jun 22, 2018 at 06:04:14PM +0100, Ben Hutchings wrote: > I needed to make some small changes to build them as modules. The next > upload using Linux 4.17 should include ashmem_linux and binder_linux > modules for amd64, arm64 and armhf. I looked at it, and it seemed like making the mainline version of ashmem build as a module would indeed take only small changes. I did not have the time to actually do it, and it sounds like Ben just has done so. The driver is in staging/ thus perhaps you could push the patch gregkh's way? This would help people who use vanilla kernels. Binder is already module-capable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Sat, Jun 23, 2018 at 1:04 AM Ben Hutchings wrote: > I needed to make some small changes to build them as modules. The next > upload using Linux 4.17 should include ashmem_linux and binder_linux > modules for amd64, arm64 and armhf. > Thanks for your time! -- Best regards, Shengjing Zhu
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Wed, 2018-06-20 at 16:04 +0800, Shengjing Zhu wrote: > Hi Ben, > > On Thu, Jun 14, 2018 at 10:46 AM Shengjing Zhu wrote: > > > > On Thu, Jun 14, 2018 at 01:09:39AM +0100, Ben Hutchings wrote: > > > I agree, I don't think it makes much sense to build these OOT if > > > they > > > can be built in-tree. > > > > Here goes the bug #901492 (linux: Please enable Android ashmem and > > binder module) > > Is there any update about this? > It's it acceptable to enable the in-tree version, as built-in module? > Or it would be better to continue this dkms package as they can't be > built as modules? I needed to make some small changes to build them as modules. The next upload using Linux 4.17 should include ashmem_linux and binder_linux modules for amd64, arm64 and armhf. Ben. > > > > > The in-tree version of ashmem *cannot* be built as a module, > > > though, > > > which we would probably want to change. > > -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
Re: Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master
On Wed, Jun 06, 2018 at 12:17:13AM -0400, Antonio Russo wrote: > I have packaging of zfsonlinux (for upstream git revisions) that > is in need of review [1]. It builds, and zfs-dkms builds as well. > I have only done very superficial testing (i.e., the zfs module > loads, you can create a pool). > > This was somewhat nontrivial because upstream recently merged spl, > the "Solaris Porting Layer", into zfsonlinux. In the short term, > this made packaging more challenging, but in the long term it will > make maintenance much easier. > > Highlights from this new packaging: > > 1. Upstream now ships explicit an statement of kernel version > compatibility [2]. I've integrated that into the debian packaging, > so the maintainer will no longer have to update that manually. > > 2. Tunable parameter to put architecture independent zfs scripts > in a Debian FHS compliant location [3]. Hopefully, future > additions of scripts will use this parameter and Debian will get > that compliance "for free". I expect this to be merged relatively > soon, further simplifying the packaging. > > 3. debian/update-git , which automatically builds a changelog > for an upstream git revision. Another tool to simplify an > ambitious user's desire to build a recent git version. > > I'd appreciate feedback. as promised, and unfortunately delayed a bit longer than I wanted. thanks for the initial push - some of the points are more for a discussion with upstream regarding their inclusion of some variant of this, some are for debian experimental. - compat 12 is IMHO too new for anything except experimental, it's still subject to change. - given the different licences and thus parts of the archive, I am not sure whether we can merge zfs-dkms and spl-dkms inside Debian - which distros do we want to support upstream? Debian Stretch+, Ubuntu Xenial/Bionic/Cosmic? just the latest ones? - compat 10 or 11? Stretch only has 10 without backports.. debian/rules: - chmod a-x files should be on separate lines, otherwise git blame is stupid ;) - same for copied/installed scripts that need to be listed explicitly (DKMS) - the dmks.mkconf call does not belong into dh_auto_install (semantically). does it need to be there or can we move it to dh_auto_configure or dh_auto_build ? why not keep it in override_dh_dkms? - same for the "make dist" call, which should probably be run before the build to prevent mistakes in "make dist" from tainting DKMS sources with build products? - debian/git-version.sh could benefit from some comments/rationale ;) - debian/git-version.sh does not handle actual release tags correctly (the resulting package version is a native one) - debian/git-version.sh should probably somehow handle adding a pkgrelease suffix as well? maybe as optional, second parameter (defaulting to 1), and in case it is ommitted but d/changelog contains the same version with -1, bump it to -2? - debian/update-git: it would be cool to pre-populate the changelog with a shortlog since the previous version (if the previous version matches either the git-describe or release tag versioning scheme, alternatively we could just encode the git commit in the changelog like "gbp dch --snapshot" does?) I'll do some test builds and check the resulting packages later on - thanks for getting the ball rolling!
