Bug#952571: ITP: golang-golang-x-mod -- Go module mechanics libraries
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-golang-x-mod Version : 0.2.0-1 Upstream Author : Go * URL : https://github.com/golang/mod (golang.org/x/mod) * License : BSD-3-clause Programming Lang: Go Description : Go module mechanics libraries This repository holds packages for writing tools that work directly with Go module mechanics. That is, it is for direct manipulation of Go modules themselves. . It is NOT about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages. . The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms. Reason for packaging: Required by newer versions of golang-golang-x-tools
Re: bootstrap.min.js in pydoctor
Am Dienstag, den 25.02.2020, 17:40 + schrieb Ian Jackson: > For -devel, context is that Anthony Fok just uploaded a new upstream > version of pydoctor (a tool for extracting API docs for python > modules) in order to fix a couple of upstream bugs. Anthony, thank > you very much for your work to help fix one of our (mutual) indirect > dependencies. > > Unfortunately the new pydoctor has some DFSG issues (#952546, CC'd). > > I am hoping that -devel can advise what the conventional approach is > to the package containing a sourceless copy of bootstrap.min.js. > > I'm guessing that the answer is to strip the sourceless file from the > package, and have the binary package contain a symlink into the file > tree of some other package which contains an appropriate bootstrap > file ? But is this right, and if so which package ? You don't have to strip it if the unminified version is added under debian/missing-sources/ with an appropriate entry in d/copyright. The final package however should not use it but instead rely on whatever package provides bootstrap.js or its minified version. Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: bootstrap.min.js in pydoctor
Quoting Daniel Leidert (2020-02-26 10:27:03) > Am Dienstag, den 25.02.2020, 17:40 + schrieb Ian Jackson: > > For -devel, context is that Anthony Fok just uploaded a new upstream > > version of pydoctor (a tool for extracting API docs for python > > modules) in order to fix a couple of upstream bugs. Anthony, thank > > you very much for your work to help fix one of our (mutual) indirect > > dependencies. > > > > Unfortunately the new pydoctor has some DFSG issues (#952546, CC'd). > > > > I am hoping that -devel can advise what the conventional approach is > > to the package containing a sourceless copy of bootstrap.min.js. > > > > I'm guessing that the answer is to strip the sourceless file from the > > package, and have the binary package contain a symlink into the file > > tree of some other package which contains an appropriate bootstrap > > file ? But is this right, and if so which package ? > > You don't have to strip it if the unminified version is added under > debian/missing-sources/ with an appropriate entry in d/copyright. > > The final package however should not use it but instead rely on whatever > package provides bootstrap.js or its minified version. but if you add the unminified version under debian/missing-sources then it has to be the exact right version that produces precisely the minified version you have. I so far found the trouble I have to go through to verify this, is *far* too much compared to putting a simple Files-Excluded into debian/copyright and a dversionmangle and repacksuffix into my debian/watch -- especially because I cannot use the shipped minified version in the end anyways. Thanks! cheers, josch signature.asc Description: signature
git-buildpackage to be autoremoved due to python2 transition
FYI. The widespread impact of this not so apparent because git-buildpackage is typically used ad-hoc by maintainers, rather than via (Build)-Depends. Relevant packages and bugs: 943107 git-buildpackage: Python2 removal in sid/bullseye 937132 nevow: Python2 removal in sid/bullseye 938622 tahoe-lafs: Python2 removal in sid/bullseye Bugs which you may notice which are now not so relevant any more because they have been fixed in sid (but not yet migrated): 950216 [git-buildpackage] missing xsltproc autopkg test dependency Fixed in sid; migration blocked by FTBFS due to pydoctor breakage (#949232). When pydoctor has migrated, reattempting build (eg by re-upload) should fix this. 949232/948831 [pydoctor] needs to depend on cachecontrol 952546 [pydoctor] d/copyright & DFSG issues 937421 [pydoctor] Python2 removal in sid/bullseye My personal interest in this is that dgit Depends on git-buildpackage so I am early in the firing line. However, unfortunately my python skills are very weak and I doubt my blundering efforts [1] to try to mitigate the situation would would be helpful. I can at least do the digging to see what is actually still wrong here. Thanks to Anthony Fok for fixing pydoctor but the py2 rot seems wider including in gbp itself. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: git-buildpackage to be autoremoved due to python2 transition
On Wed, Feb 26, 2020 at 11:28:03AM +, Ian Jackson wrote: > FYI. The widespread impact of this not so apparent because > git-buildpackage is typically used ad-hoc by maintainers, rather than > via (Build)-Depends. > > Relevant packages and bugs: > 943107 git-buildpackage: Python2 removal in sid/bullseye > 937132 nevow: Python2 removal in sid/bullseye > 938622 tahoe-lafs: Python2 removal in sid/bullseye > > Bugs which you may notice which are now not so relevant any more > because they have been fixed in sid (but not yet migrated): > 950216 [git-buildpackage] missing xsltproc autopkg test dependency > Fixed in sid; migration blocked by FTBFS due to pydoctor > breakage (#949232). When pydoctor has migrated, reattempting > build (eg by re-upload) should fix this. > 949232/948831 [pydoctor] needs to depend on cachecontrol > 952546 [pydoctor] d/copyright & DFSG issues > 937421 [pydoctor] Python2 removal in sid/bullseye Yes, and as far as I can see after pydoctor migrates the only problem with gbp will be python-rpm in debian/tests/control, which is probably unneeded. > the py2 rot seems wider including in gbp itself. Where exactly? -- WBR, wRAR signature.asc Description: PGP signature
Re: git-buildpackage to be autoremoved due to python2 transition
Andrey Rahmatullin writes ("Re: git-buildpackage to be autoremoved due to
python2 transition"):
> Yes, and as far as I can see after pydoctor migrates the only problem with
> gbp will be python-rpm in debian/tests/control, which is probably
> unneeded.
Oh.
> > the py2 rot seems wider including in gbp itself.
>
> Where exactly?
I looked again and I was looking at an old version. Sorry for the
noise. I still think we have problems with these
937132 nevow: Python2 removal in sid/bullseye
938622 tahoe-lafs: Python2 removal in sid/bullseye
which I think are brought in by pydoctor...
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: git-buildpackage to be autoremoved due to python2 transition
On Wed, Feb 26, 2020 at 12:14:08PM +, Ian Jackson wrote: > I looked again and I was looking at an old version. Sorry for the > noise. I still think we have problems with these > 937132 nevow: Python2 removal in sid/bullseye > 938622 tahoe-lafs: Python2 removal in sid/bullseye > which I think are brought in by pydoctor... As you can see with reverse-depends or dak, there is no packages depending on these two (after pydoctor was ported, I guess). -- WBR, wRAR signature.asc Description: PGP signature
Re: bootstrap.min.js in pydoctor
On Wed, Feb 26, 2020 at 3:31 AM Johannes Schauer wrote: > > Quoting Daniel Leidert (2020-02-26 10:27:03) > > Am Dienstag, den 25.02.2020, 17:40 + schrieb Ian Jackson: > > > For -devel, context is that Anthony Fok just uploaded a new upstream > > > version of pydoctor (a tool for extracting API docs for python > > > modules) in order to fix a couple of upstream bugs. Anthony, thank > > > you very much for your work to help fix one of our (mutual) indirect > > > dependencies. > > > > > > Unfortunately the new pydoctor has some DFSG issues (#952546, CC'd). > > > > > > I am hoping that -devel can advise what the conventional approach is > > > to the package containing a sourceless copy of bootstrap.min.js. > > > > > > I'm guessing that the answer is to strip the sourceless file from the > > > package, and have the binary package contain a symlink into the file > > > tree of some other package which contains an appropriate bootstrap > > > file ? But is this right, and if so which package ? > > > > You don't have to strip it if the unminified version is added under > > debian/missing-sources/ with an appropriate entry in d/copyright. > > > > The final package however should not use it but instead rely on whatever > > package provides bootstrap.js or its minified version. > > but if you add the unminified version under debian/missing-sources then it has > to be the exact right version that produces precisely the minified version you > have. I so far found the trouble I have to go through to verify this, is *far* > too much compared to putting a simple Files-Excluded into debian/copyright and > a dversionmangle and repacksuffix into my debian/watch -- especially because I > cannot use the shipped minified version in the end anyways. Indeed, which option is easier or more feasible depends on the scenario. In this particular case with pydoctor, I was quite lucky because its included bootstrap.min.css is exactly what Twitter distributed officially, so the exact unminified version was easily found: Files: debian/missing-sources/pydoctor/templates/bootstrap.css pydoctor/templates/bootstrap.min.css Copyright: 2011-2015 Twitter, Inc. Embedded copy of normalize.css v3.0.2: 2011-2014 Nicolas Gallagher License: Expat Comment: These files are copies of vanilla Bootstrap v3.3.4 CSS files, identical to those distributed on Bootstrap CDN: * https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.css * https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css The new pydoctor upload that fixes #952546 is now in sid: https://tracker.debian.org/news/1104779/accepted-pydoctor-19110git20200114c74016b-2-source-into-unstable/ Cheers, Anthony
Bug#952606: ITP: relint-el -- Emacs Lisp regexp mistake finder
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: relint-el Version : 1.13-1 Upstream Author : Mattias Engdegård * URL or Web page : https://elpa.gnu.org/packages/relint.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs Lisp regexp mistake finder Relint scans Emacs Lisp files for mistakes in regexps, including deprecated syntax and bad practice. It also checks the regexp-like arguments to skip-chars-forward, skip-chars-backward, skip-syntax-forward and skip-syntax-backward.
Bug#952640: ITP: armnn -- Arm NN is an inference engine for CPUs, GPUs and NPUs
Package: wnpp Severity: wishlist Owner: Wookey * Package name: armnn Version : 19.11 Upstream Author : ARM Ltd * URL : https://github.com/ARM-software/armnn * License : MIT Programming Lang: C++ Description : Arm NN is an inference engine for CPUs, GPUs and NPUs Arm NN is a set of tools that enables machine learning workloads on Arm hardware. It provides a bridge between existing neural network frameworks and whatever hardware is available: Cortex-A CPUs, Mali GPUs and Ethos NPUs. It utilizes the Arm Compute Library to target these programmable cores, as efficiently as possible. Arm NN does not provide support for Cortex-M CPUs. . The package is only available for arm64 and armhf architectures. This release supports Caffe, TensorFlow, TensorFlow Lite, and ONNX. Arm NN takes networks from these frameworks, translates them to the internal Arm NN format and then, through the Arm Compute Library, deploys them efficiently on Cortex-A CPUs, and, if present, Mali GPUs such as the Mali-G71 and Mali-G72. This package is part of the machine learning stack (on arm). arm-compute-library, armnn, tvm, onnx etc. It is developed under the Linaro Machine Intelligence Initiative (see mlplatform.org).
Re: f...@packages.debian.org Re: moving mg from salsa to github?
On 2/15/20 10:03 PM, Bernd Zeimetz wrote: So far I did not find a single upstream that was not able to understand a sentence like "Hi, my name is foo and I'm the Debian developer who is maintaining blubb in Debian". Thats correct. The maintainer for mg attached a new label 20200215 without hesitation, I created a tar file, imported it via gbp and pushed all to salsa. Thanx to all for your help Harri
Bug#952654: ITP: golang-github-google-renameio -- provides a way to atomically create or replace a file or symbolic link
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-google-renameio Version : 0.1.0-1 Upstream Author : Michael Stapelberg Copyright Owner : Google Inc. * URL : https://github.com/google/renameio * License : Apache-2.0 Programming Lang: Go Description : provides a way to atomically create or replace a file or symbolic link The renameio Go package provides a way to atomically create or replace a file or symbolic link. . Atomicity vs durability --- . renameio concerns itself only with atomicity, i.e. making sure applications never see unexpected file content (a half-written file, or a 0-byte file). . As a practical example, consider https://manpages.debian.org/: if there is a power outage while the site is updating, we are okay with losing the manpages which were being rendered at the time of the power outage. They will be added in a later run of the software. We are not okay with having a manpage replaced by a 0-byte file under any circumstances, though. Reason for packaging: * Required by honnef.co/go/tools, which in turn is required by golang-google-api v0.16.0 and above
pager and upgrades
I just upgraded a Buster system to today's unstable and got the below. I think this should be regarded as a bug, but what is it a bug in? dpkg? Configuration file '/etc/smartd.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** smartd.conf (Y/I/N/O/D/Z) [default=N] ? d sh: 1: pager: not found diff: standard output: Broken pipe dpkg: error processing package smartmontools (--configure): conffile difference visualizer subprocess returned error exit status 127 -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Re: pager and upgrades
Hi Russell, Russell Coker writes: > I just upgraded a Buster system to today's unstable and got the below. I > think this should be regarded as a bug, but what is it a bug in? dpkg? > > Configuration file '/etc/smartd.conf' > ==> Modified (by you or by a script) since installation. > ==> Package distributor has shipped an updated version. >What would you like to do about it ? Your options are: > Y or I : install the package maintainer's version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : start a shell to examine the situation > The default action is to keep your current version. > *** smartd.conf (Y/I/N/O/D/Z) [default=N] ? d > sh: 1: pager: not found > diff: standard output: Broken pipe > dpkg: error processing package smartmontools (--configure): > conffile difference visualizer subprocess returned error exit status 127 > /usr/bin/pager should be a link to /etc/alternatives/pager, which should then link to a pager. On a minimal installation this should point to /bin/more, from util-linux. If I had to speculate, maybe /e/a/p is a broken link to something, and maybe there's a bug in the package that provides that alternative pager? Anyways, if it's not an obvious bug then you'll almost certainly be asked to provide steps to reproduce. Best, Nicholas signature.asc Description: PGP signature
