Bug#955800: marked as done (RFS: yiyantang/0.7.0-6 [QA][RC] -- Terminal-based Chinese automatic encoding converter)
Your message dated Sat, 04 Apr 2020 21:24:03 -0400 with message-id <86615172e149b32b15880715d46644306563fd35.ca...@debian.org> and subject line Re: Bug#955800: RFS: yiyantang/0.7.0-6 [QA][RC] -- Terminal-based Chinese automatic encoding converter has caused the Debian Bug report #955800, regarding RFS: yiyantang/0.7.0-6 [QA][RC] -- Terminal-based Chinese automatic encoding converter to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 955800: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955800 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "yiyantang" * Package name: yiyantang Version : 0.7.0-6 Upstream Author : hashao * URL : http://yiyantang.on.openave.net/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/yiyantang Section : text It builds those binary packages: yiyantang - Terminal-based Chinese automatic encoding converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yiyantang Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yiyantang/yiyantang_0.7.0-6.dsc Changes since the last upload: * QA upload. * Update Standards-Version to 4.5.0 * Fix FTBFS. (Closes: #954520) * Update compat level to 12. - Remove dependency on autotools_dev. - configure without using autoreconf. * Add version in d/watch. * Add Vcs link to salsa. -- Regards Sudip --- End Message --- --- Begin Message --- Uploaded. Thanks for taking care of this Chinese-related software. -- Best, Boyuan Yang 在 2020-04-05星期日的 00:34 +0100，Sudip Mukherjee写道： > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "yiyantang" > > * Package name: yiyantang >Version : 0.7.0-6 >Upstream Author : hashao > * URL : http://yiyantang.on.openave.net/ > * License : GPL-2 > * Vcs : https://salsa.debian.org/debian/yiyantang >Section : text > > It builds those binary packages: > > yiyantang - Terminal-based Chinese automatic encoding converter > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/yiyantang > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/y/yiyantang/yiyantang_0.7.0-6.dsc > > Changes since the last upload: > >* QA upload. >* Update Standards-Version to 4.5.0 >* Fix FTBFS. (Closes: #954520) >* Update compat level to 12. > - Remove dependency on autotools_dev. > - configure without using autoreconf. >* Add version in d/watch. >* Add Vcs link to salsa. > > signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#955800: RFS: yiyantang/0.7.0-6 [QA][RC] -- Terminal-based Chinese automatic encoding converter
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "yiyantang" * Package name: yiyantang Version : 0.7.0-6 Upstream Author : hashao * URL : http://yiyantang.on.openave.net/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/yiyantang Section : text It builds those binary packages: yiyantang - Terminal-based Chinese automatic encoding converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yiyantang Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yiyantang/yiyantang_0.7.0-6.dsc Changes since the last upload: * QA upload. * Update Standards-Version to 4.5.0 * Fix FTBFS. (Closes: #954520) * Update compat level to 12. - Remove dependency on autotools_dev. - configure without using autoreconf. * Add version in d/watch. * Add Vcs link to salsa. -- Regards Sudip
Re: Sponsor for DMX - The Context Machine
On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY wrote: > - By building the upstream source (main)? By packaging the upstream > binary (contrib)? Pre-built binaries are for non-free, not for contrib. Contrib is strictly DFSG-free. -- WBR, wRAR signature.asc Description: PGP signature
Bug#955791: RFS: libkqueue/2.3.1-1 -- cross-platform library for kernel event notification
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libkqueue" * Package name: libkqueue Version : 2.3.1-1 Upstream Author : Mark Heily * URL : https://github.com/mheily/libkqueue/wiki * License : BSD-2-clause * Vcs : https://github.com/mheily/debian-packages/tree/libkqueue Section : libs It builds those binary packages: libkqueue0 - cross-platform library for kernel event notification libkqueue-dev - Development files for libkqueue To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libkqueue Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libk/libkqueue/libkqueue_2.3.1-1.dsc Changes since the last upload: * New upstream release Regards, -- Mark Heily
Re: How to update upstream when upstream has no releases
On Sat, Apr 4, 2020 at 5:48 PM Tong Sun wrote: > > On Sat, Apr 4, 2020 at 1:53 PM Robin Gustafsson - ro...@rgson.se > wrote: > > > > Hi Tong Sun, > > > > > I was using `gbp import-orig --sign-tags --uscan` but it seems that > > > `--uscan` cannot be used with `gbp import-orig` under the case of no > > > upstream releases. > > > > I believe it'll work if the debian/watch file is set up such as to > > have uscan download the upstream's git repo. The "direct access to the > > git repository" sections in the uscan manual provides examples of what > > I'm referring to. > > Thanks to all who replied. > > This is my debian/watch file > (https://salsa.debian.org/go-team/packages/golang-github-tonistiigi-fsutil/-/blob/debian/sid/debian/watch) > > version=4 > opts="mode=git, pgpmode=none" \ > https://github.com/tonistiigi/fsutil.git \ > HEAD debian > > but when I ran it, I got the following error: > > gbp:error: Uscan failed: Filename pattern missing version delimiters > () without filenamemangle Sorry, I fix it -- I should have ran it within my docker but not outside it.
Re: How to update upstream when upstream has no releases
On Sat, Apr 4, 2020 at 1:53 PM Robin Gustafsson - ro...@rgson.se wrote: > > Hi Tong Sun, > > > I was using `gbp import-orig --sign-tags --uscan` but it seems that > > `--uscan` cannot be used with `gbp import-orig` under the case of no > > upstream releases. > > I believe it'll work if the debian/watch file is set up such as to > have uscan download the upstream's git repo. The "direct access to the > git repository" sections in the uscan manual provides examples of what > I'm referring to. Thanks to all who replied. This is my debian/watch file (https://salsa.debian.org/go-team/packages/golang-github-tonistiigi-fsutil/-/blob/debian/sid/debian/watch) version=4 opts="mode=git, pgpmode=none" \ https://github.com/tonistiigi/fsutil.git \ HEAD debian but when I ran it, I got the following error: gbp:error: Uscan failed: Filename pattern missing version delimiters () without filenamemangle I can't quite interpret what it is telling me, and I didn't find much on the Internet that fix it. Searching through https://people.debian.org/~osamu/uscan.html#direct-access-to-the-git-repository for KW "Filename", I didn't find much good explanation either.
Re: Sponsor for DMX - The Context Machine
Juergen Neumann writes: > Hi all! > > I would like to file an ITP for DMX - The Context Machine [1], formerly > known as DeepaMehta [2]. As this will be my first project for Debian I > am kindly looking for a sponsor. So far I barely managed to create a > first lintian compliant result [3]. I will be happy to improve. :-) > > Thank you very much in advance! > > Juergen > > [1] https://git.dmx.systems/dmx-platform/dmx-platform > [2] https://www.deepamehta.de/ > [3] https://github.com/dmx-systems/dmx-build-deb Hello Juergen, I'm still quite new to Debian packaging and certainly can't talk for the Debian project but I'll try to give you some advice nevertheless. I hope the following advice is correct Debian-wise; sorry if I'm making mistakes, please correct me in that case. I can see in the README of dmx-build-deb: dmx-build-deb builds Debian packages from DMX binary files and loads them into the public repository at DMX Systems. Debian packages normally build software from source, not binary. That is required for your package to be part of Debian proper (the "main" section). If that's impossible though, there is the "contrib" section where such packages can be uploaded. It is recommended to build from source whenever possible. Also, I guess a Debian package should not load anything to some other repository. Your debian/README.source is basically a template. You should either remove it or write something interesting there. README.source is the place where you document specifics of your package with regards to how it should be built. debian/control, debian/copyright are templates (@@PACKAGENAME@@, @@CONFLICTS@@, ...). It looks like it is instantiated through .gitlab-ci.yml. I guess it is OK in principle, but remember that you have to upload a Debian-compliant source package in any case. I'm not sure whether a Debian package can be named "dmx-latest"; I guess it should just be named "dmx". Debian takes copyright and license information very seriously; if there is any doubt on the license of some file, it might need to be removed from the set of packaged files through a +dfsg modification. Therefore it is highly advised that the license of each source file in the upstream source code be very clear. The safest if you can is to add to each nontrivial source file the copyright line of each contributor with the years of contributions, and indicate which license applies to this file (and in particular if it is AGPL3 strict or "AGPL3 or later"); this is the case for the GNU project. Many projects don't do that, which may make it more difficult to be uploaded to Debian (sometimes a little more, sometimes a whole lot more). The clearer the better, and as a bonus it saves a lot of time to the people who are in charge of verifying the license of the software: if you can do that then that's the best; if not, try to be as clear as possible and cross fingers. It is not mandatory, but it is possible to format debian/copyright with a machine-readable format [1] It would be nice to also produce a "-doc" package containing the documentation [2], so that people with internet connectivity issues can still read the documentation. Through .gitlab-ci.yml you auto-generate debian/changelog. I doubt an auto-generated changelog can be used if you want your package integrated in Debian: end users should be able to modify your package at will, and add what they want to the changelog. In debian/postinst it looks like a password is stored into /etc/dmx/config.properties, but I don't see any provision (such as umask 077) to make sure it is not world-readable before "chmod 750 /etc/dmx". For you to check... debian/rules contains comments from the template; you should probably clean them up. I don't know debconf, but at what point is the equality between dmx/initial_admin_password and dmx/initial_admin_password_again checked? Once you have built the source package and the binary package(s) locally, you should run "lintian -EviIL+pedantic" to see if you have any important things to fix. One of the first things you need to make clear is how you want to create your package(s): - By building the upstream source (main)? By packaging the upstream binary (contrib)? - How do you organize the packaging files and your workflow for creating packages: with origtargz(1), uupdate(1), git-dpm, git-buildpackage, something else...? [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ [2] https://dmx.readthedocs.io/en/latest/ Hope this helps! Best regards -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#955761: RFS: htmldoc/1.9.8-1 [QA] -- HTML processor that generates indexed HTML, PS, and PDF
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "htmldoc" * Package name: htmldoc Version : 1.9.8-1 Upstream Author : Michael R Sweet * URL : https://www.msweet.org/htmldoc/ * License : GPL-2 * Vcs : None Section : web It builds those binary packages: htmldoc - HTML processor that generates indexed HTML, PS, and PDF htmldoc-common - Common arch-independent files for htmldoc To access further information about this package, please visit the following URL: https://mentors.debian.net/package/htmldoc Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.8-1.dsc Changes since the last upload: * QA upload. * New upstream release * Remove 0007-CVE-2019-19630.patch, applied upstream * Update Standards-Version to 4.5.0 * Remove d/gbp.conf and salsa-ci-yml, not needed. * Update copyright year in d/copyright Regards, Håvard
Re: How to update upstream when upstream has no releases
On Sat, Apr 04, 2020 at 01:10:59PM -0400, Tong Sun wrote: > Hi, > > How to use `gbp import-orig` to update upstream when upstream has no releases? > > I was using `gbp import-orig --sign-tags --uscan` but it seems that > `--uscan` cannot be used with `gbp import-orig` under the case of no > upstream releases. > > I'm using the Dep14 Workflow so no pristine tar branch needed. > > Thanks Newer uscan can also work with git repos; at least this is what I do e.g with dhewm3... Maybe this helps: https://salsa.debian.org/games-team/dhewm3/-/blob/master/debian/watch -- tobi
Re: How to update upstream when upstream has no releases
Hi Tong Sun, > I was using `gbp import-orig --sign-tags --uscan` but it seems that > `--uscan` cannot be used with `gbp import-orig` under the case of no > upstream releases. I believe it'll work if the debian/watch file is set up such as to have uscan download the upstream's git repo. The "direct access to the git repository" sections in the uscan manual provides examples of what I'm referring to. Regards, Robin
How to update upstream when upstream has no releases
Hi, How to use `gbp import-orig` to update upstream when upstream has no releases? I was using `gbp import-orig --sign-tags --uscan` but it seems that `--uscan` cannot be used with `gbp import-orig` under the case of no upstream releases. I'm using the Dep14 Workflow so no pristine tar branch needed. Thanks
Bug#955756: RFS: streamlink/1.3.1+dfsg-2 -- CLI for extracting video streams from various websites to a video player
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "streamlink" with a FTBFS fix when building using sphinx 2.4 (which is currently in experimental but will migrate to unstable) (see #955060). * Package name: streamlink Version : 1.3.1+dfsg-2 Upstream Author : Streamlink Team * URL : https://streamlink.github.io/ * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1 Section : python It builds those binary packages: python3-streamlink - Python module for extracting video streams from various websites python3-streamlink-doc - CLI for extracting video streams from various websites (documentation) streamlink - CLI for extracting video streams from various websites to a video player To access further information about this package, please visit the following URL: https://mentors.debian.net/package/streamlink Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.3.1+dfsg-2.dsc Changes since the last upload to unstable: streamlink (1.3.1+dfsg-2) unstable; urgency=medium * d/rules: run dh_link at install time to satisfy dh_sphinxdoc sanity checks This fixes the build with sphinx 2.4 (Closes: #955060) * docs: fix warnings with sphinx 2.4 -- Alexis Murzeau Sat, 04 Apr 2020 18:10:52 +0200 Regards, -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#955753: RFS: ck/0.6.0-1.4 [NMU, RC] -- Concurrency Kit
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for "ck" * Package name: ck Version : 0.6.0-1.4 Upstream Author : Samy Al Bahra * URL : http://concurrencykit.org/ * License : BSD-2-clause * Vcs : https://anonscm.debian.org/cgit/collab-maint/ck.git Section : libs It builds those binary packages: libck0 - Concurrency Kit - shared libraries libck-dev - Concurrency Kit - development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ck Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ck/ck_0.6.0-1.4.dsc Changes since the last upload: * Non-maintainer upload. * Explicitly set the platform option when building for armhf rather than rely on the configure script's autodetection. I'm doing another nmu for ck, as the previous one (0.6.0-1.3) failed to build for armhf [1], preventing migration [2]. Build failure occurs because the configure script fails to autodetect the platform, for no apparent reason. That problem didn't exist in previous builds and also doesn't happen when building -1.3 in ubuntu [3] for any architecture, armhf included. The changes made in -1.3 didn't involve the configure script in any way. [1] https://buildd.debian.org/status/fetch.php?pkg=ck=armhf=0.6.0-1.3=1585323705=0 [2] https://qa.debian.org/excuses.php?package=ck [3] https://launchpad.net/ubuntu/+source/ck/0.6.0-1.3 Thank you! pgpFCfMrUEEEj.pgp Description: OpenPGP digital signature
Re: [RFC] python-cobra, python3-sbml5
On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote: > >From the logs, in the last message[2] it looks like an import-error for > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > provide) package. When I dug into looking at libsbml, I noticed that the > relevant file (libsbml.py) which throws error > is generated with swig-3.0 by the upstream [3] > > While the same file in the apt archive (observed after $apt source > python3-sbml5) seems to be generated with swig-4.0, and that's the current > swig version in Debian now. Sorry, I couldn't understand which two files are you comparing. One is from the python3-sbml5 binary package and is generated with swig 4, where is the second one, generated by swig 3? -- WBR, wRAR signature.asc Description: PGP signature
Re: Sponsor for DMX - The Context Machine
On Sat, Apr 04, 2020 at 02:46:26PM +0200, Juergen Neumann wrote: > Hi all! > > I would like to file an ITP for DMX - The Context Machine [1], formerly > known as DeepaMehta [2]. As this will be my first project for Debian I > am kindly looking for a sponsor. So far I barely managed to create a > first lintian compliant result [3]. I will be happy to improve. :-) Please note thet the usual workflow is: 1. File an ITP. 2. Do the work. 3. Publish the package. 4. Look for sponsors, usually starting with filing an RFS. See https://mentors.debian.net/intro-maintainers for more details on this workflow. Looks like your git repo doesn't contain a source package tree, only some teemplates for it, you'll need a proper source package, correctly buildable in a minimal sid chroot, to get it sponsored. You also need to run lintian on the source package, not just on the binary ones. -- WBR, wRAR signature.asc Description: PGP signature
[RFC] python-cobra, python3-sbml5
Hi, Currently python-cobra FTBFS reported here [1]. >From the logs, in the last message[2] it looks like an import-error for '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a provide) package. When I dug into looking at libsbml, I noticed that the relevant file (libsbml.py) which throws error is generated with swig-3.0 by the upstream [3] While the same file in the apt archive (observed after $apt source python3-sbml5) seems to be generated with swig-4.0, and that's the current swig version in Debian now. When I compared, the one generated with swig 4.0 looks pretty different from the one generated by swig 3.0. I "suspect" that the error is due to the swig version change to 4.0, and corresponding API changes. I would really appreciate if I could have more folks "confirm" that this is the case, and I'm not missing out on anything else. I'll then file a report upstream then, asking for corresponding code changes needed for swig 4.0. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 [3]: https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple Thanks and regards Nilesh
Sponsor for DMX - The Context Machine
Hi all! I would like to file an ITP for DMX - The Context Machine [1], formerly known as DeepaMehta [2]. As this will be my first project for Debian I am kindly looking for a sponsor. So far I barely managed to create a first lintian compliant result [3]. I will be happy to improve. :-) Thank you very much in advance! Juergen [1] https://git.dmx.systems/dmx-platform/dmx-platform [2] https://www.deepamehta.de/ [3] https://github.com/dmx-systems/dmx-build-deb -- GnuPG KeyID: CD914C6C Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C
