Bug#900744: ITP: zimwriterfs -- creates ZIM files from a locally-stored directory containing "self-sufficient" HTML content
Package: wnpp Severity: wishlist Owner: Kunal Mehta * Package name: zimwriterfs Version : 1.1 Upstream Author : Emmanuel Engelhart * URL : https://github.com/openzim/zimwriterfs * License : GPL-3.0-or-later Programming Lang: C/C++ Description : creates ZIM files from a locally-stored directory zimwriterfs is a console tool to create ZIM files from a locally-stored directory containing "self-sufficient" HTML content (with pictures, javascript, and stylesheets). The result will contain all the files of the local directory compressed and merged in the ZIM file. Nothing more, nothing less. The generated file can be opened with a ZIM reader; Kiwix is one example, but there are others. The main purpose for this will be able to generate ZIM files using tools that are packaged in Debian.
HELP WANTED: security review / pam experts for su transition
Hello, as previously discussed it seems all stakeholders are pretty much in agreement that it would be better for debian to use the implementation of login tools from src:util-linux instead of from src:shadow. Investigations about implementation differences has been done and remaining work is basically to implement the switch. (Details in #833256) As a preparation step for larger login package switch (which I'm not comitting to at the moment!), I'd like to start with switching only 'su' and moving it from 'login' (binary package) to 'util-linux' (binary package). This should also pave the way for potentially making login non-essential in the future. WIP on util-linux side: https://salsa.debian.org/debian/util-linux/commit/a2449f1a1bf0f77a80aa1f71871fa32b4d14d6f5 I don't feel entirely comfortable doing this security-sensitive work entirely on my own without peer review. I'm thus looking for people willing to review the security critical aspects, preferably PAM experts. Are you willing to help? Please contact me. Regards, Andreas Henriksson
Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules
Hi, On 03/06/18 16:08, Nicolas Braud-Santoni wrote: > X-Debbugs-CC: debian-devel@lists.debian.org > > Hi Debianites ! > > On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote: >> [libu2f-udev's post-inst script should make udev reload rules.] >> Otherwise, the rules are not active until the next reboot (or until the user >> manually calls `udevadm control -R`). > > To fix this bug, I need to call `udevadm` from the postinstall script, > meaning that libu2f-udev needs to Pre-Depends on udev. Running a command from another package in postinst only requires a normal Depends - not a Pre-Depends. However, I don't think you need to run "udevadm control -R" at all. udev will monitor rules from /lib/udev/rules.d while its running and automatically reload them when changed. For the second half of this bug: > Consider investigating whether it is possible to apply the udev rules to > already-plugged-in devices (as setting tag uaccess should be idempotent). This can be done by running "udevadm trigger". By default every device on the system will be triggered which is a bit heavyweight, so you probably want to add some *match parameters to restrict this to the devices you're interested in (see the udevadm man page). James signature.asc Description: OpenPGP digital signature
Bug#900697: ITP: python-morph -- collection of routines to help identify and morph objects
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-morph Version : 0.1.3 Upstream Author : metagriffin * URL : http://github.com/metagriffin/morph * License : GPL-3+ Programming Lang: Python Description : collection of routines to help identify and morph objects Morph provides a bunch of functions to help identify object type: * isstr() * isseq() * isdict() . Morph’s pick and omit functions allow you to extract a set of keys (or properties) from a dict-like object. The morph.xform helper function can be used to recursively transform all the items in a list & dictionary tree Note: This is a new dependency for Rally.
Bug#899299: Bug #899299: libu2f-udev: Post-inst script should make udev reload rules
X-Debbugs-CC: debian-devel@lists.debian.org Hi Debianites ! On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote: > [libu2f-udev's post-inst script should make udev reload rules.] > Otherwise, the rules are not active until the next reboot (or until the user > manually calls `udevadm control -R`). To fix this bug, I need to call `udevadm` from the postinstall script, meaning that libu2f-udev needs to Pre-Depends on udev. Per policy (§3.5 Dependencies), I need to discuss this first on d-d@, so here we are :) Best, nicoo
Bug#900689: ITP: octave-vibes -- VIBes API to easily display results in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-vibes Version : 0.2.0 Upstream Author : Oliver Heimlich * URL : https://octave.sourceforge.io/vibes/ * License : GPL-3+ Programming Lang: C++, Octave Description : VIBes API to easily display results in Octave The VIBes API allows one to easily display results (boxes, pavings) from interval methods. VIBes consists in two parts: (1) the VIBes application that features viewing, annotating and exporting figures, and (2) the VIBes API that enables your program to communicate with the viewer in order to draw figures. This package integrates the VIBes API into Octave. The VIBes application is required for operation and must be installed separately. Data types from third-party interval arithmetic libraries for Octave are also supported. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-vibes.git
Re: New lintian warnings helping to detect FTBFS and license violation
On Sat, Jun 2, 2018 at 4:37 PM, Sean Whitton wrote: > Hello Bastien and others, > > On Sat, Jun 02 2018, Bastien ROUCARIÈS wrote: > >> It will first detect minified javascript/css embedded in html file >> (source only). It it possible to avoid this warning by creating a >> symlink >> to source or adding source under >> debian/missing-source/$nameoffile.fragment (better naming welcome). > > There is a already a convention for naming the files documented in the > Policy Manual. Please use that. In particular, it's d/missing-sources > not d/missing-source. > > Section 4.16: > https://www.debian.org/doc/debian-policy/#missing-sources-debian-missing-sources It was a typo on my side work as policy said > > -- > Sean Whitton
RE:Feedback request about the Alba Upstream to Debian packaging effort
Hello Ian > I didn't have a massive amount of time to review this in detail, but > it sounds cool. I looked at the slides in the pdf [5] above. > (Shame there isn't a technical report...) the technical part is in the gitlab-ci.yml file :). > I reviewed the version number proposal and it seems sound to me. It just comes to my mind that Maybe it does not fit well with my convention for exeprimental numbering whcih is blablab_x.y.z-t~exp1 so maybe the best way would be to use blalbla_x.y.z-t~~alba+1 > I have some observations: > You probably want to keep the delta between the upstream and the > debianised branch as small as possible. Yes you are right this should be kept as small as possible. > On build systems and debian/ruless: if (i) you can get as much of your > upstream build system looking as standard as possible (ii) you can get > as much of the rest supported by dh as possible, then your > debian/rules files could possibly be very small indeed. Yes > debian/changelog is a bit of a pain and you will have to write code to > generate it. [gbp-]dch can be helpful. gbp allows to generate this automatically, but this is true that the quality of the changelog is not necessary good. Most of the time because the commit are not that great either... > Ideally you would treat debian/control as an output file: generate it > entirely from upstream stuff, using some tool, and commit the result > as a committed-artefact to the debianised branch. I agreed with you that it would be great to have a way to generate a debian package from the upstream git repository and some minimalist metadata purely descriptive. > Your debianisation tool becomes part of the source code for your > packages. You need to publish it in your repository, track the > version used, etc. So it probably needs to be debianised. I think > you need to mention it in Built-Using or something similar. good point, but for now this is just the gitlab file. Do you think that the guix way can be modified in order to generate Debian packages instead of guix binaries ? I like a lot the idea to maintain only the metadata in a repository. Indeed in our case scientific software are most of the time not that standard and need lot's of tweak in order to be packages. > Finally, and VERY CONTROVERSIALLY: consider whether you want to bother > with source packages. You could just use git branches instead. > Source packages are a pain. Just use dgit ;) > Good luck and have fun! thanks Frederic
Bug#900685: ITP: octave-secs3d -- Drift-Diffusion simulator for 3d semiconductor devices in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-secs3d Version : 0.0.1 Upstream Author : Carlo de Falco * URL : https://octave.sourceforge.io/secs3d/ * License : GPL-2+ Programming Lang: Octave Description : Drift-Diffusion simulator for 3d semiconductor devices in Octave This package provides functions for Drift-Diffusion simulation of 3d semiconductor devices in Octave, a scientific computation software. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-secs3d.git
Bug#900684: ITP: octave-queueing -- Queueing Networks and Markov chains analysis for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-queueing Version : 1.2.5 Upstream Author : Moreno Marzolla * URL : https://octave.sourceforge.io/queueing/ * License : GPL-3+ Programming Lang: Octave Description : Queueing Networks and Markov chains analysis for Octave The queueing package provides functions for queueing networks and Markov chains analysis. This package can be used to compute steady-state performance measures for open, closed and mixed networks with single or multiple job classes. Mean Value Analysis (MVA), convolution, and various bounding techniques are implemented. Furthermore, several transient and steady-state performance measures for Markov chains can be computed, such as state occupancy probabilities, mean time to absorption, time-averaged sojourn times and so forth. Discrete- and continuous-time Markov chains are supported. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-queueing.git
Bug#900683: ITP: octave-optics -- optics functions for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-optics Version : 0.1.3 Upstream Author : Andreas Weber * URL : https://octave.sourceforge.io/optics/ * License : GPL-3+ Programming Lang: Octave Description : optics functions for Octave This package covers various aspects of optics in Octave, a scientific computation software. It contains functions for manipulating Jones, Mueller, and Stokes matrices and for computing Zernike polynomials. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-optics.git
Bug#900682: ITP: octave-ncarray -- access NetCDF files as a multi-dimensional array in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-ncarray Version : 1.0.4 Upstream Author : Alexander Barth * URL : https://octave.sourceforge.io/ncarray/ * License : GPL-2+ Programming Lang: Octave Description : access NetCDF files as a multi-dimensional array in Octave This package contains functions for accessing a single or a collection of NetCDF files as a multi-dimensional array in Octave, a scientific computation software. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-ncarray.git
