Bug#902400: ITP: backward-cpp -- Beautiful stack trace pretty printer for C++
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: backward-cpp Version : 1.4(upcoming) Upstream Author : François-Xavier Bourlet bomb...@gmail.com * URL : https://github.com/bombela/backward-cpp * License : MIT Programming Lang: C++ Description : Beautiful stack trace pretty printer for C++ Backward spices the stack trace up when C++ programs run into fault. . It can also display code snippets with colored lines when the source files are accessible. . Backward is a header only library. signature.asc Description: PGP signature
Bug#902398: ITP: csv-mode-el -- Emacs major mode for editing comma/char separated values
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Control: block 495989 by -1 Package name: csv-mode-el Version : 1.7 Upstream Author : "Francis J. Wright" URL : https://elpa.gnu.org/packages/csv-mode.html License : GPL-3+ Programming Lang: elisp Description : Emacs major mode for editing comma/char separated values This package implements CSV mode, a major mode for editing records in a generalized CSV (character-separated values) format. It binds finds with prefix ".csv" to `csv-mode' in `auto-mode-alist'. . CSV mode supports operations such as the following: . * sort lexicographically and numerically on a specified field or column. * kill and yank fields or columns. C-c C-k can kill more than one field at once, but multiple killed fields can be yanked only as a fixed group equivalent to a single field. * align fields into columns * interchange rows and columns. For details, see the documentation for the individual commands. . CSV mode can recognize fields separated by any of several single characters, specified by the value of the customizable user option `csv-separators'. CSV data fields can be delimited by quote characters (and must if they contain separator characters). This implementation supports quoted fields, where the quote characters allowed are specified by the value of the customizable user option `csv-field-quotes'. By default, the only separator is a comma and the only field quote is a double quote. . CSV mode commands ignore blank lines and comment lines beginning with the value of the buffer local variable `csv-comment-start', which by default is #. The user interface is similar to that of the standard commands `sort-fields' and `sort-numeric-fields', but see the major mode documentation below. . The global minor mode `csv-field-index-mode' provides display of the current field index in the mode line, cf. `line-number-mode' and `column-number-mode'. It is on by default. -- Yes, that description should probably be cut down a bit more... I am packaging this software for the Debian Emacsen Team as a contribution to the effort of breaking up emacs-goodies-el into a series of elpafied packages. It will be team maintained, and I will require a sponsor for the initial upload. This bug blocks #495989 Regards, Nicholas
Bug#902391: ITP: keras-applications -- popular models and pre-trained weights for the Keras deep learning framework
Package: wnpp Severity: wishlist Owner: Stephen Sinclair * Package name: keras-applications Version : 1.0.2 Upstream Author : Francois Chollet * URL : http://keras.io/ * License : Expat Programming Lang: Python Description : popular models and pre-trained weights for the Keras deep learning framework Keras is a Python library for machine learning based on deep (multi- layered) artificial neural networks (DNN), which follows a minimalistic and modular design with a focus on fast experimentation. Features of DNNs like neural layers, cost functions, optimizers, initialization schemes, activation functions and regularization schemes are available in Keras a standalone modules which can be plugged together as wanted to create sequence models or more complex architectures. Keras supports convolutions neural networks (CNN, used for image recognition resp. classification) and recurrent neural networks (RNN, suitable for sequence analysis like in natural language processing). It runs as an abstraction layer on the top of Theano (math expression compiler) by default, which makes it possible to accelerate the computations by using (GP)GPU devices. Alternatively, Keras could run on Google's TensorFlow (not yet available in Debian). Keras Applications is the applications module of the Keras deep learning library. It provides model definitions and pre-trained weights for a number of popular archictures, such as VGG16, ResNet50, Xception, MobileNet, and more. This new package is to be a dependency of an updated keras package, following upstream's splitting of keras-applications to its own Python module.
Bug#902390: ITP: keras-preprocessing -- data preprocessing module for the Keras deep learning framework
Package: wnpp Severity: wishlist Owner: Stephen Sinclair * Package name: keras-preprocessing Version : 1.0.1 Upstream Author : Francois Chollet * URL : http://keras.io/ * License : Expat Programming Lang: Python Description : data preprocessing module for the Keras deep learning framework Keras is a Python library for machine learning based on deep (multi- layered) artificial neural networks (DNN), which follows a minimalistic and modular design with a focus on fast experimentation. Features of DNNs like neural layers, cost functions, optimizers, initialization schemes, activation functions and regularization schemes are available in Keras a standalone modules which can be plugged together as wanted to create sequence models or more complex architectures. Keras supports convolutions neural networks (CNN, used for image recognition resp. classification) and recurrent neural networks (RNN, suitable for sequence analysis like in natural language processing). It runs as an abstraction layer on the top of Theano (math expression compiler) by default, which makes it possible to accelerate the computations by using (GP)GPU devices. Alternatively, Keras could run on Google's TensorFlow (not yet available in Debian). Keras Preprocessing is the data preprocessing and data augmentation module of the Keras deep learning library. It provides utilities for working with image data, text data, and sequence data. This new package is to be a dependency for an updated keras package, following upstream's splitting of keras-preprocessing into its own Python module.
Re: Versioned dependencies and maintainer scripts
Thanks Simon for the clarification.
On 6/25/18 1:04 AM, Simon McVittie wrote:
> On Sun, 24 Jun 2018 at 17:05:54 -0600, Daniele Nicolodi wrote:
>> Packages that will use dh_installsystemduser will have maintainer
>> scripts that will depend on the next relese of init-system-helpers.
>> dh_installsystemduser will then inject a versioned dependency using the
>> ${misc:Depends} substitution in debian/control.
>>
>> Is that enough to ensure that postinst and postrm maintainer scripts are
>> run with the right version of init-system-helpers available? Should I
>> be using Pre-Depends instead?
>
> https://www.debian.org/doc/debian-policy/#summary-of-ways-maintainer-scripts-are-called
I read that, but I was not sure if my interpretation was right. Indeed,
my conclusions were different.
> For the postinst, you can rely on the updated init-system-helpers being
> at least unpacked (which should be enough, because i-s-h is Essential,
> so it's required to provide its core functionality while merely unpacked
> and not yet configured).
>
> The difference for Pre-Depends is that it would give you the ability to
> assume that i-s-h has been configured (fully installed) before your
> postinst runs. I don't think you need that here.
>
> In the postrm, you can't normally rely on having your package's
> dependencies still installed, but init-system-helpers is Essential so
> it should still be there, and we don't officially support downgrades so
> i-s-h should still be at least the required version.
Only tangentially related: does that mean that we can drop the checks
for the presence of deb-systemd-helper in the postrm maintainer scripts
injected by dh_installsystemd (for example [1]) and simplify them a bit?
> Most packages do the more involved parts of their removal in the prerm.
> Is that feasible here?
I'm not sure. I'm probably not aware of all the intricacies involved in
writing robust maintainer scripts, thus I modelled dh_installsystemduser
after what dh_installsystemd does. The maintainer scripts code blocks
injected by dh_installsystemd stop services in prerm and deactivate them
in postrm, but I don't know if there is a technical reason for that.
The code blocks injected by dh_installsystemduser do not start or stop
services, and I don't see a reason why disabling the services could not
be done in prerm. The relevant maintainr script code block is here [2].
Thanks.
Cheers,
Dan
[1]
https://salsa.debian.org/debian/debhelper/blob/master/autoscripts/postrm-systemd
[2]
https://salsa.debian.org/debian/debhelper/merge_requests/5/diffs?commit_id=163d0b663f75071e6710016960db8581012f4c9c#618769df15efa903bfb94d164eacef2166af740c
Bug#902288: Issue raised with gnome-desktop as well
To avoid duplication of work, I report my filing of the issue with
gnome-desktop:
https://gitlab.gnome.org/GNOME/gnome-desktop/issues/4
I have a feeling bubblewrapping (i.e. bwrap), strict as it is configured at the
moment, could potentially affect other packages generating thumbnails, e.g.:
$ apt-file search /usr/share/thumbnailers | column -t -s : | sort
atril-common /usr/share/thumbnailers/atril.thumbnailer
blender-data /usr/share/thumbnailers/blender.thumbnailer
dia-common /usr/share/thumbnailers/dia.thumbnailer
evince /usr/share/thumbnailers/evince.thumbnailer
exe-thumbnailer /usr/share/thumbnailers/exe-dll-msi.thumbnailer
ffmpegthumbnailer
/usr/share/thumbnailers/ffmpegthumbnailer.thumbnailer
geogebra-gnome /usr/share/thumbnailers/geogebra.thumbnailer
gnome-font-viewer
/usr/share/thumbnailers/gnome-font-viewer.thumbnailer
gnome-hwp-support/usr/share/thumbnailers/hwp-thumbnailer.thumbnailer
gnome-nds-thumbnailer
/usr/share/thumbnailers/gnome-nds-thumbnailer.thumbnailer
gwyddion-common /usr/share/thumbnailers/gwyddion.thumbnailer
heif-thumbnailer /usr/share/thumbnailers/heif.thumbnailer
libgdk-pixbuf2.0-bin
/usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer
libgsf-bin /usr/share/thumbnailers/gsf-office.thumbnailer
librsvg2-common /usr/share/thumbnailers/librsvg.thumbnailer
mate-control-center-common
/usr/share/thumbnailers/mate-font-viewer.thumbnailer
mypaint /usr/share/thumbnailers/mypaint-ora.thumbnailer
pentobi /usr/share/thumbnailers/pentobi.thumbnailer
tiled/usr/share/thumbnailers/tiled.thumbnailer
totem-common /usr/share/thumbnailers/totem.thumbnailer
Do package maintainers run tests for thumbnailers? For example, we expect
gnome-desktop to generate a thumbnail .png from the hash of the media resource
as "URI-like" (not a full URI escaping, I have noticed, just some characters):
(Python)
hashlib.md5("file://" + sys.argv[1].replace(" ", "%20")
.replace("|", "%7C")).hexdigest()
do we verify that such file is created under:
$XDG_CACHE_HOME/thumbnails/GNOME_DESKTOP_THUMBNAIL_SIZE_{NORMAL,LARGE}
This would allow answering this type of questions programmatically: have
changes in gnome-desktop broken the way in which the Blender thumbnailer works?
Bug#902343: ITP: fonts-osifont -- ISO 3098-compliant TrueType font for CAD projects
Package: wnpp Severity: wishlist Owner: Kurt Kremitzki * Package name: fonts-osifont Version : 20160516 Upstream Author : hikikomori82 * URL : https://github.com/hikikomori82/osifont * License : GPL3 or GPL2 or LGPL3, with fonts exception Description : ISO 3098-compliant TrueType font for CAD projects In some European countries, CAD projects must have a font which conforms to the ISO 3098 specification. Such a font has been available in commercial CADs but was not available for free CADs (including FreeCAD) until this project. The font is created with free tools like FontForge, Inkscape, and GIMP, and is available under 3 licenses: GPL3, GPL2, and LGPL3, all with the GPL font exception. This font is used in FreeCAD 0.17's TechDraw technical drawing workbench. I plan on packaging it under the Debian Fonts Task Force.
Bug#902338: ITP: golang-github-mitchellh-go-testing-interface -- library to expose *testing.T as an interface
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: golang-github-mitchellh-go-testing-interface Version: 0.0~git20171004.a61a995 Upstream Author: Mitchell Hashimoto License: Expat URL: https://github.com/mitchellh/go-testing-interface Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-mitchellh-go-testing-interface Description: library to expose *testing.T as an interface Go library that exports an interface that *testing.T implements as well as a runtime version you can use in its place. . The purpose of this library is so export test helpers as a public API without depending on the "testing" package, since one can't create a *testing.T struct manually. signature.asc Description: This is a digitally signed message part.
Re: Versioned dependencies and maintainer scripts
On Sun, 24 Jun 2018 at 17:05:54 -0600, Daniele Nicolodi wrote:
> Packages that will use dh_installsystemduser will have maintainer
> scripts that will depend on the next relese of init-system-helpers.
> dh_installsystemduser will then inject a versioned dependency using the
> ${misc:Depends} substitution in debian/control.
>
> Is that enough to ensure that postinst and postrm maintainer scripts are
> run with the right version of init-system-helpers available? Should I
> be using Pre-Depends instead?
https://www.debian.org/doc/debian-policy/#summary-of-ways-maintainer-scripts-are-called
For the postinst, you can rely on the updated init-system-helpers being
at least unpacked (which should be enough, because i-s-h is Essential,
so it's required to provide its core functionality while merely unpacked
and not yet configured).
The difference for Pre-Depends is that it would give you the ability to
assume that i-s-h has been configured (fully installed) before your
postinst runs. I don't think you need that here.
In the postrm, you can't normally rely on having your package's
dependencies still installed, but init-system-helpers is Essential so
it should still be there, and we don't officially support downgrades so
i-s-h should still be at least the required version.
Most packages do the more involved parts of their removal in the prerm.
Is that feasible here?
smcv
