Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

 * Package name: inkscape-ext-textext
   Version : 0.12.0~git36-gbbb55e6-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : AGPL
 * Vcs : https://github.com/textext/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images


The packaging [1,2] works (though I haven't tested it in pbuild yet, so there
might be some missing build dependencies).  I'm also confused why py3compile
isn't being added by dh_python3 to the postinst script, so at least one
significant thing needs to be fixed.

Also, this is using upstream's "develop" branch, git commit febf8f7. Earlier
versions don't work with Inkscape 1.0 (beta), which has fully transitioned
to Python 3. There's no reason to waste time packaging things for Python 2,
so I suppose this is targeted at experimental, at least until upstream and
Inkscape make another release.

[1] https://mentors.debian.net/package/inkscape-ext-textext
[2] 
https://mentors.debian.net/debian/pool/main/i/inkscape-ext-textext/inkscape-ext-textext_0.12.0~git32-gfebf8f7-1.dsc

Re: Init systems and docker

[Jose-Luis Rivas]

Hello Tomas!

On 10/12/19 13:00, Tomas Pospisek wrote:
> I have to say that I disagree with you and many others on this thread.
> Maybe Docker was *meant* for single application containers, I do not know.
> 
> However running a service ("a single application") often implies
> surrounding services. F.ex. you want logs to be saved? Maybe you need to
> run cron or at? Maybe you want to get notified about problems, stats,
> whatever via email?

In all the professional instances of containerization I have seen, these
are provided by external containers/services, so you don't have to
maintain several configuration in several places. Logs go to stdout and
from there you collect them into whatever service you have for this,
process them and use that processing to send notifications or make them
searchable.

> 
> Now you can start re-implementing all the existing "surrounding" service
> solutions on the outside of the container. Which is a *lot* of complex
> work in my experience. The quick fix to those "surrounding" problems is
> often enough to stand onto proven-to-work shoulders and to install the
> "surrounding services" *inside* the container:
> 
> apt-get install cron at rsyslogd etc. etc.
> 
> Now the next problem is how to start those. Easiest way is to hook the
> provided Debian init scripts into whatever mini-init system one chooses.
> And so forth.
> 
> So I imagine people that want to run stuff in containers are usually
> very glad if init scripts are available, work and can be re-used.
> 
> John Goerzen is maintaining Debian docker images (thanks!) that contain
> a useful set of the mentioned "surrounding" services, that are quite
> popular AFAIK.
> 
> Being you, I'd ask for patches. I think running stuff in
> Docker/Kubernetes is a good solution for a lot of problems. I think
> Debian should grow to accommodate those architectures. And I think
> Debian *will* accommodate them (see John's work and a lot of other nice
> efforts in that direction not least by Ubuntu), it just takes time to
> find the sweet spot solutions, to spread the knowledge and knowhow etc.
> A lot of container loads are Debian based, not the least a lot of
> Kubernetes' own people's
Debian already does for a part of container users. You don't need
patches, support is already there. The ones complaining right now
haven't read the right part in Docker's manual to get it running.

Cheers.

-- 

   __.https://wiki.debian.org/JoseLuisRivas
___'/___  rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43

Bug#942240: ITP: glktermw -- Curses-based interface library for interactive fiction programs

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: glktermw
  Version : 1.0.4
  Upstream Author : Andrew Plotkin 
* URL : https://www.eblong.com/zarf/glk/index.html
* License : Custom permissive (DFSG-free)
  Programming Lang: C
  Description : Curses-based interface library for interactive fiction 
programs

Glk is a device-independent interface specification intended primarily for
interactive fiction implementations.  This library provides an ncurses-based glk
interface and includes Unicode support.  It is used by packages such as glulxe.

Bug#942239: ITP: glulxe -- Interpreter for glulx interactive fiction

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: glulxe
  Version : 0.5.4
  Upstream Author : Andrew Plotkin 
* URL : https://eblong.com/zarf/glulx/
* License : MIT
  Programming Lang: C
  Description : Interpreter for glulx interactive fiction

glulxe is the authoritative interpreter for the Glulx interactive fiction
VM, which is a 32-bit update of the older Z-Machine standard.

This program can play games ending with .ulx, .gblorb, .glb, .blorb, and .blb.
glulxe can work with only a terminal; the optional graphics in some Glulx games
can be shown by using the package gargoyle-free instead.

Re: Init systems and docker

[Simon Richter]

Hi,

On 12.10.19 19:00, Tomas Pospisek wrote:

> However running a service ("a single application") often implies
> surrounding services. F.ex. you want logs to be saved? Maybe you need to
> run cron or at? Maybe you want to get notified about problems, stats,
> whatever via email?

That's the point of containerization though: a site-wide service
orchestrator keeps track of services and their dependencies. You likely
only need a single mailer instance for however many of your application
containers you run, and your application should only talk to some
abstract service provider through a well-defined interface, so the
actual implementation behind it can be scaled and updated independently.

Containers and systemd solve the same problem at different scales
(site-wide vs per-host).

Stacking two systems that implement the same feature on top of each
other usually gives you bad side effects. Linux knows that virtio disks
should have an arbitrarily long command queue and no scheduler, because
I/O schedulers do not stack. RAID controllers rely on harddisks to
report read errors immediately instead of retrying. TCP-over-TCP behaves
erratically.

The only place where I could see a potential use would be exporting dbus
services between containers, similar to DCOM in Windows, but everyone
seems to be happy with socket connections and per-application protocol
definitions.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#942228: ITP: folium -- visualize geographic data in a Leaflet map

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: folium
  Version : 0.10.0
  Upstream Author : Rob Story 
* URL : https://python-visualization.github.io/folium
* License : MIT/X
  Programming Lang: Python
  Description : visualize geographic data in a Leaflet map

 folium builds on the data wrangling strengths of the Python ecosystem
 and the mapping strengths of the Leaflet.js library. Manipulate your
 data in Python, then visualize it in a Leaflet map via folium.


As a teacher of computer science for undergraduate students, I am
using th library folium to let them discover activities realted to
geographic maps, openstreetmap.org, and so on.

I shall maintain this package as part of my full time job.

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

[Tomas Pospisek]

Hi Sam & Debianistas,

this is far TLDR for me. That is not meant as a critique, but as a
feedback so you have a data point from some random Debianer's available
CPU resources.

(in general I'm fine to declare best practices for whatever issue so
that people can orient themselves on where to head to, provided that
those "best practices" aren't "too far out")

Am 08.10.19 um 03:22 schrieb Sam Hartman:
> 
> [...]

Bug#942226: ITP: branca -- library with non-map-specific features for folium

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: branca
  Version : 0.3.1
  Upstream Author : Martin Journois 
* URL : https://github.com/python-visualization/branca/tree/v0.3.1
* License : MIT/X
  Programming Lang: Python
  Description : library with non-map-specific features for folium

 folium builds on the data wrangling strengths of the Python ecosystem
 and the mapping strengths of the Leaflet.js library. Manipulate your
 data in Python, then visualize it in a Leaflet map via folium.
 .
 branca provides the features which are not specific to maps.



As a teacher of computer science for undergraduate students, I am using folium
to teach maps management, openstreetmap.org, and so on.

I shall maintain this package as part of my current job.

Re: Init systems and docker

[Sven Bartscher]

Hi,

Am 12.10.19 um 19:00 schrieb Tomas Pospisek:
> However running a service ("a single application") often implies
> surrounding services. F.ex. you want logs to be saved? Maybe you need to
> run cron or at? Maybe you want to get notified about problems, stats,
> whatever via email?
> 
> Now you can start re-implementing all the existing "surrounding" service
> solutions on the outside of the container. Which is a *lot* of complex
> work in my experience. The quick fix to those "surrounding" problems is
> often enough to stand onto proven-to-work shoulders and to install the
> "surrounding services" *inside* the container:
> 
> apt-get install cron at rsyslogd etc. etc.

I don't see why you say, that you would have to *re-implement* the
surrounding solutions on the outside of the container. From my
experience, the most appropriate solution for having cron, at, and
rsyslogd run alongside you main service would be to put each of them
into their own container and link the containers together as needed.

This might sound more complicated than just installing everything you
need into one container, but container based service management (such as
kubernetes or docker swarm) are (at least in my experience) a lot easier
to manage and more effective, when you consistently separate each
service into its own container.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Re: Init systems and docker

[Tomas Pospisek]

Hi Debianistas!

Am 12.10.19 um 01:06 schrieb Ben Hutchings:
> On Fri, 2019-10-11 at 18:49 -0400, Scott Kitterman wrote:
>> I have had bugs filed against more than one package I maintain regarding 
>> issues 
>> with sysv init scripts when used in docker.
>>
>> I have been told by docker users (I'm not one) that systemd as provided on 
>> Debian can't be used in docker.  I have no idea if that's true or not.  I 
>> try 
>> really hard to know as little about init systems as possible and trust our 
>> maintainers who work on such things.
>>
>> If it is true, then to the extent we want Debian to be useful for docker 
>> does 
>> that mean we ought to maintain sysv init scripts?  If it's not true, can 
>> someone point me to documentation that explains using systemd on Debian in 
>> docker?
> [...]
> 
> As I understand it, Docker is meant for application containers, and
> application containers should have a trivial init process that directly
> launches a single application process.  No init script, or indeed any
> shell script, should be used at all.

I have to say that I disagree with you and many others on this thread.
Maybe Docker was *meant* for single application containers, I do not know.

However running a service ("a single application") often implies
surrounding services. F.ex. you want logs to be saved? Maybe you need to
run cron or at? Maybe you want to get notified about problems, stats,
whatever via email?

Now you can start re-implementing all the existing "surrounding" service
solutions on the outside of the container. Which is a *lot* of complex
work in my experience. The quick fix to those "surrounding" problems is
often enough to stand onto proven-to-work shoulders and to install the
"surrounding services" *inside* the container:

apt-get install cron at rsyslogd etc. etc.

Now the next problem is how to start those. Easiest way is to hook the
provided Debian init scripts into whatever mini-init system one chooses.
And so forth.

So I imagine people that want to run stuff in containers are usually
very glad if init scripts are available, work and can be re-used.

John Goerzen is maintaining Debian docker images (thanks!) that contain
a useful set of the mentioned "surrounding" services, that are quite
popular AFAIK.

Being you, I'd ask for patches. I think running stuff in
Docker/Kubernetes is a good solution for a lot of problems. I think
Debian should grow to accommodate those architectures. And I think
Debian *will* accommodate them (see John's work and a lot of other nice
efforts in that direction not least by Ubuntu), it just takes time to
find the sweet spot solutions, to spread the knowledge and knowhow etc.
A lot of container loads are Debian based, not the least a lot of
Kubernetes' own people's.

This is my view of course, which *might* be herethic to the narrower
Docker and Kubernetes orthodoxies.

Bug#863408: ITP: bibledit-cloud -- Bible editor server

[Teus Benschop]

Package: wnpp
Followup-For: Bug #863408
Owner: Teus Benschop 

I am intending to package the existing upstream tarball and create a proper 
Debian package from it.

It already exists in Ubuntu and works well there.

The plan is to base the Debian packaging on the existing Ubuntu packaging.

This is expected to speed all up.

Bug#942213: ITP: nomad-driver-singularity -- Nomad Singularity driver plugin

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org, debian-...@lists.debian.org
Control: affects -1 src:nomad src:singularity-container

   Package name: nomad-driver-singularity
Version: 1.0.0~alpha2
Upstream Author: Sylabs Inc.
License: MPL-2.0
URL: https://github.com/sylabs/nomad-driver-singularity
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/nomad-driver-singularity
Description: Nomad Singularity driver plugin
 Singularity driver for HashiCorp's Nomad.


signature.asc
Description: This is a digitally signed message part.

Bug#942212: ITP: nomad-driver-lxc -- Nomad LXC driver plugin

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:nomad

   Package name: nomad-driver-lxc
Version: 0.1.0
Upstream Author: HashiCorp
License: MPL-2.0
URL: https://github.com/hashicorp/nomad-driver-lxc
Vcs-Browser: https://salsa.debian.org/go-team/packages/nomad-driver-lxc
Description: Nomad LXC driver plugin
 LXC driver for HashiCorp's Nomad.


signature.asc
Description: This is a digitally signed message part.

Bug#942210: ITP: golang-github-apparentlymart-go-textseg -- Golang implementation of Unicode Text Segmentation

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 941334 by -1
Control: affects -1 src:nomad

   Package name: golang-github-apparentlymart-go-textseg
Version: 1.0.0
Upstream Author: Martin Atkins
License: Expat, Apache-2.0, Unicode-ToU
URL: https://github.com/apparentlymart/go-textseg
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-apparentlymart-go-textseg
Description: Golang implementation of Unicode Text Segmentation
 Golang library implementing Unicode Text Segmentation.


signature.asc
Description: This is a digitally signed message part.

Bug#942205: ITP: golang-github-agext-levenshtein -- Levenshtein distance and similarity metrics

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:nomad

   Package name: golang-github-agext-levenshtein
Version: 1.2.2
Upstream Author: Alex Bucataru
License: Apache-2.0
URL: https://github.com/agext/levenshtein
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-agext-levenshtein
Description: Levenshtein distance and similarity metrics
 Golang package for calculating the Levenshtein distance and similarity
 metrics between two strings.


signature.asc
Description: This is a digitally signed message part.

Re: Init systems and docker

[Simon McVittie]

On Fri, 11 Oct 2019 at 18:49:37 -0400, Scott Kitterman wrote:
> I have been told by docker users (I'm not one) that systemd as provided on 
> Debian can't be used in docker.  I have no idea if that's true or not.

It isn't, as noted elsewhere on this thread.

However, my understanding is that they are sort of correct, because
systemd can't be used *in a Docker container that isn't specially
configured*.

It used to be the case that systemd needed `docker run --privileged`,
which removes the security boundary between host and container (aka
"containers don't contain"). systemd has improved since then, and if given
some specific bind-mounts from the host system (which can be read-only)
it will adapt its behaviour to be more container-friendly - so it still
needs special configuration from outside the container, but the special
configuration is now simpler and "more contained".

> If it is true, then to the extent we want Debian to be useful for docker does 
> that mean we ought to maintain sysv init scripts?

I think it's necessary to distinguish between two aspects of init here:

* pid 1 (process reaper of last resort)
* service manager

In systemd-world, both of these are the systemd manager,
/lib/systemd/systemd.

In sysvinit-world, sysvinit itself is a process reaper with some
mostly-vestigial service management (configured in /etc/inittab), but 95%
of the service management is delegated to sysv-rc, OpenRC or some similar
framework (for services that start during boot), or to service(8) and
friends (for services that are restarted or otherwise controlled after
the system is booted).

With Debian's historical (non-systemd) defaults, a small minority of
services (mostly just getty) are managed by sysvinit itself, but if it
involves init.d or rc.d, then it's really sysv-rc's job, not sysvinit's;
and The Thread about systemd vs. sysvinit was in fact mostly about
systemd vs. sysv-rc. The fact that we call that configuration "sysvinit"
is not really very helpful, because it makes sysvinit's pid 1 seem more
important than it actually is.

If you will ever have more than one process in your container, you need
a pid 1 that reaps processes, but it doesn't have to be as big as systemd
or even sysvinit: tini will do fine. `docker run --init` provides a
miniature init process for this purpose.

Booting a full operating system in a Docker container is not what it is
designed for (perhaps you *can*, but that doesn't necessarily mean you
*should*). The way I tend think about it is that Docker is a heavyweight
chroot, rather than a lightweight virtual machine. Some other container
frameworks, like lxc/lxd, aim to behave more like a virtual machine,
and for those you do need a full service management framework like
systemd or sysv-rc.

smcv

Re: Init systems and docker

[Mathieu Parent (Debian)]

Hello,

Le sam. 12 oct. 2019 à 01:26, Jose-Luis Rivas  a écrit :
>
> Hello Scott,
>
> On 10/11/19 18:49, Scott Kitterman wrote:
[...]
> In short: they should not be using systemd inside the container and if
> they want to the issue is not on how Debian ships systemd but that they
> are not using the --privilege parameter for launching their container.

While I agree to not recommend using systemd inside docker, it is very useful
in CI. We use this at work to test our salt states (salt is like
puppet/ansible/chef/...).

For this, we use Gitlab CI running test-kitchen with ruby-kitchen-salt
and ruby-kitchen-docker (all in buster).
Another solution would either mean hacking gitlab-runner [1] or
spanning a lot of VMs.

[1]: https://gitlab.com/gitlab-org/gitlab-runner/issues/1585

Also systemd can be run inside Docker without --privileged but
requires careful configuration [2].

[2]: 
https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/

Regards

-- 
Mathieu Parent Parent