Re: Changed Github download URLs are affecting lots of existing watch files
On Fri, Mar 26, 2021 at 10:38:57PM +0100, Andreas Tille wrote: > This breaks at least all Debian Med packages refereing to Github and > probably way more. This means our toolset will fail to detect new > upstream versions. > > Any idea what to do (besides uploading all packages obtained from > Github right after the release)? > This was reported as #985633 A fixer for this issue was added to lintian-brush already (version 0.101, fixer debian-watch-file-uses-old-github-pattern). That said, I agree that needing to update and re-upload every package isn't a great way of solving this issue. However, until and unless there is some good way of storing updatable out-of-band package metadata for this purpose, it would be nice if there was a more compact way of specifying the latest-tag case for common hosting platforms (with well-specified APIs) without needing to resort to HTML scraping. Gordon
Re: Pre-Depends usage
On 14/11/2022 12:39, Guerkan Myczko wrote: Hi I would like to use Pre-Depends in the cadabra2 packge so it'll not break the jupyterhub notebook. It gets broken due to the package python3-notebook creating a symlink for the codemirror at /usr/lib/python3/dist-packages/notebook/static/components Now if cadabra2 which puts a part into that directory, while it's not yet symlinked the codeeditor part of notebook gets broken. With the jupyter-notebook uploader hat on, this sounds a bit worryingly fragile. The layout of the static directories (and whether they are symlinks or not) is really an implementation detail, rather than a public interface for extensions. Jupyter does provide a notebook extension mechanism (nbextension), which can be used to inject javascript into the notebook context (although I admittedly don't know how easy it would be to customise the code editor component with that, which is presumably what you're doing). Note that the way jupyter-notebook handles web content is significantly restructured in 6.5 (https://github.com/jupyter/notebook/pull/6474) and completely changed to use jupyterlab-derived javascript in 7.0 (https://github.com/jupyter/notebook/pull/6294), so drop-in modifications to the current layout will probably break. Notebook is likely to stay at 6.4 for bookworm, because any changes on the web side are a big pain for packaging, but moving to one of those versions during the next cycle is quite possible. Gordon
Bug#943892: ITP: python-backcall -- Specify callback function signatures for Python
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: python-backcall Version : 0.1.0 Upstream Author : Thomas Kluyver * URL : https://github.com/takluyver/backcall * License : BSD Programming Lang: Python Description : Specify callback function signatures for Python This is a small library for annotating callback functions in Python. This is a new dependency for upgrading IPython. It will be maintained under the DPMT aegis.
Re: Pimp your shell - Debian developer tips?
On Wed, May 27, 2020 at 10:06:29PM +0300, Otto Kekäläinen wrote:
> Hello!
>
> Do we have Debian devs here who have pimped their shell heavily with custom
> prompts, colors, command line fonts, shell window title hacks, perhaps
> using zsh etc? Have you written blogs about you experiences, can you share
> some good reads (with screenshots) of what you have done?
>
> I've read a bit on zsh and powerline and the like, but I am annoyed that
> all those blog posts are quite superficial and do not mention security,
> interoperability or performance aspects. Frankly any blog post that
> recommends cloning random repos or even worse, running wget | sh something
> gives me chills.
>
> Some above average posts are
> https://linuxhint.com/install_zsh_shell_ubuntu_1804/ and
> https://www.hildeberto.com/2018/02/oh-my-zsh.html
>
> I'd very much want to read about some more knowledgeable experiences.
>
>
> Tips?
>
Not so much _pimping your existing shell_, but I'd like to give a
shout-out for `xonsh` (which I maintain).
It's a python shell - think IPython, but with first-class support for
running commands and passing pipes and arguments back-and-forth to the
python environment.
```
for dctrl in pg`**/debian/control`:
head -n1 @(dctrl.parent / "changelog")
sv = $(grep-dctrl -n -s Standards-Version . @(dctrl)).strip()
if sv != "4.5.0":
print(f"old s-v {sv}")
```
It's still admittedly a bit rough round the edges sometimes, and being
python there is a memory and performance penalty compared to
bash/zsh/fish/whatever, but I find being able to do flow control and
string manipulation without shell arcana is very useful (and to answer
the original question, the prompt and footer is fully customisable
either with builtin placeholders or the output of arbitrary python
functions).
Gordon
[1]: https://xon.sh/
>
> Some might react that bells and whistles is useless and real unix beards
> only run plain bash, but I think that good text prompts have a potential to
> increase productivity. And anyway I don't want those MacOS users to claim
> that their shells would be in any way better than what I can have in Debian
> ;)
Is Vcs-Browser necessary? [was: Why Vcs-* fields are not at least recommended ?]
Related question: is it useful (in most cases) to recommend having Vcs-Browser where Vcs-* is also provided? As the parent noted, policy doesn't make any strong recommendation here, as to whether any Vcs-* field should be present or whether Vcs-Browser should be present also, however lintian does make it a recommendation: I: missing-vcs-browser-field In the most common case (git, salsa, https, default branch), the same URI will work perfectly well both for both browse and clone (either with or without the .git suffix). Most packages set the fields like (random example): Vcs-Git: https://salsa.debian.org/apt-team/apt.git Vcs-Browser: https://salsa.debian.org/apt-team/apt Allowing an explicit Vcs-Browser field for unusual cases seems reasonable, but perhaps we could make the implicit assumption that if 1) Vcs-* uses scheme https: 2) Vcs-Browser is not present then the Vcs-* URI can be assumed to be browsable, and save some unnecessary duplication in d/control. Gordon On Tue, Aug 18, 2020 at 11:10:04PM +0200, Alexis Murzeau wrote: > Hi, > > > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > Vcs-) > are not recommended (or maybe even strongly recommended) ? (I mean here that > I think > having Vcs-* fields should be recommended for active packages) > > > There is no lintian tag for missing Vcs-* fields (not even a low severity one, > but I don't know if it's because of lack of interest or because of the > policy). > > Maybe the fact that we still have the package' source tarballs for each > released version is enough, but this loose the VCS history and ongoing work in > case someone else wants to contribute too. > > I acknowledge that previously, packages might not have been developed using > a VCS as said in the policy. But I think now most packages have a VCS where > it is developed. > > > Also, I see some orphaned packages in the QA group now actively maintained > without VCS, which seems counterproductive if someone else wants to contribute > too. > In that case, this would be almost like a NMU I guess, but against an > "non official maintainer" with manual merges (or lost changes). > > Or maybe orphaned package with QA upload are not supposed to be always > collaboratively maintained ? (I'm new to these concepts, but to me the > response to this should be "no"). > > > What do you think about actively developed packages without Vcs-* fields ? > > > - > Note: I've checked if it was already discussed before on -devel or -policy > but did > not find anything relevant for this exact subject. > If there is still something somewhere, I would be happy to read it :) > > -- > Alexis Murzeau > PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F >
Bug#837953: ITP: dh-r -- Debhelper support for R packages
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: dh-r Version : 20160901 Upstream Author : Gordon Ball * URL : https://anonscm.debian.org/git/debian-science/packages/dh-r.git * License : MIT Programming Lang: Perl, R Description : Debhelper support for R packages This is a debhelper buildsystem for R packages, and a script to generate debian/ skeletons for new R packages. It will be maintained within the debian-science team.
Bug#840535: ITP: jquery-typeahead.js -- Type-ahead autocompletion plugin for jQuery
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: jquery-typeahead.js Version : 2.7.1 Upstream Author : Tom Bertrand * URL : https://github.com/running-coder/jquery-typeahead * License : MIT Programming Lang: Javascript Description : Type-ahead autocompletion plugin for jQuery The jQuery Typeahead plugin provides autocomplete preview on search inputs with builtin options and deep customization. This is a dependency for jupyter-notebook. I intend to maintain it within the pkg-javascript team.
Bug#842825: ITP: jupyter-console -- Jupyter terminal client
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: jupyter-console Version : 5.0.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_console * License : BSD Programming Lang: Python Description : Jupyter terminal client This is the console interface for the jupyter interactive computing environment (successor of IPython). Compared to the ipython terminal, it supports language kernels other than python. I will maintain this within the DPMT.
Bug#814736: ITP: irkernel -- R kernel for Jupyter/IPython
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: irkernel Version : 0.6 Upstream Author : Thomas Kluyver * URL : https://github.com/IRkernel/IRkernel * License : MIT Programming Lang: R Description : R kernel for Jupyter/IPython This is a native R kernel for the Jupyter (formerly IPython) interactive computing tool.
Bug#814737: ITP: r-cran-pbdzmq -- R bindings for ZeroMQ from the pbdR project
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: r-cran-pbdzmq Version : 0.2.1 Upstream Author : pbdR * URL : https://github.com/RBigData/pbdZMQ * License : GPL-3 Programming Lang: R Description : R bindings for ZeroMQ from the pbdR project R bindings for ZeroMQ from the Programming with Big Data in R (pbdR) project. This is a dependency of irkernel. Upstream bundles zeromq; this will be stripped and the system version used instead.
Bug#814739: ITP: r-cran-r6 -- R classes with reference semantics
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: r-cran-r6 Version : 2.1.2 Upstream Author : Winston Chang * URL : https://github.com/wch/R6 * License : MIT Programming Lang: R Description : R classes with reference semantics An alternative class system for R. This is a dependency of r-cran-pbdzmq and hence irkernel.
Bug#814740: ITP: r-cran-uuid -- R library for generating and handling UUIDs
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: r-cran-uuid Version : 0.1.2 Upstream Author : Simon Urbanek * URL : https://cran.r-project.org/web/packages/uuid/index.html * License : MIT Programming Lang: R Description : R library for generating and handling UUIDs R UUID library. Dependency for irkernel.
Bug#814741: ITP: irkernel-irdisplay -- Rich display library for IRkernel
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: irkernel-irdisplay Version : 0.3 Upstream Author : Thomas Kluyver * URL : https://github.com/IRkernel/IRdisplay * License : MIT Programming Lang: R Description : Rich display library for IRkernel Dependency of IRkernel.
Bug#814742: ITP: irkernel-repr -- Text display library for IRkernel
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: irkernel-repr Version : 0.4 Upstream Author : Philipp A * URL : https://github.com/IRkernel/repr * License : MIT Programming Lang: R Description : Text display library for IRkernel Dependency for IRkernel.
Bug#823251: ITP: node-zmq -- ZeroMQ bindings for NodeJS
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: node-zmq Version : 2.15.0 Upstream Author : Justin Tulloss * URL : https://github.com/JustinTulloss/zeromq.node * License : MIT Programming Lang: Javascript Description : ZeroMQ bindings for NodeJS Node.js module providing bindings to the ZeroMQ messaging and communications library. All major 0MQ patterns (push/pull, pub/sub and socket monitoring) are supported.
Bug#825112: ITP: xonsh -- Python-ish, BASHwards-looking shell
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: xonsh Version : 0.3.0 Upstream Author : Anthony Scopatz * URL : http://xon.sh/ * License : BSD Programming Lang: Python Description : Python-ish, BASHwards-looking shell Xonsh is a Python-ish, BASHwards-looking shell language and command prompt. The language is a superset of Python (>= 3.4) with additional shell primitives drawn from bash and IPython. It can be used as a shell and also provides a kernel for IPython/Jupyter frontends.
