Bug#989591: ITP: golang-github-masterminds-sprig -- Useful template functions for Go templates.

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-masterminds-sprig
  Version : 3.2.1-1
  Upstream Author : Masterminds 
* URL : https://github.com/Masterminds/sprig
* License : Expat
  Programming Lang: Go
  Description : Useful template functions for Go templates. 

 The Go language comes with a built-in template language
 (http://golang.org/pkg/text/template/), but not very many template
 functions. Sprig is a library that provides more than 100 commonly used
 template functions.
 
 It is inspired by the template functions found in Twig
 (http://twig.sensiolabs.org/documentation) and in various JavaScript
 libraries, such as underscore.js (http://underscorejs.org/).
 
 The API documentation is available at GoDoc.org 
 (http://godoc.org/github.com/Masterminds/sprig/).

Reasoning: This library is a build dependency of the caddywebserver:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890

Re: ARM architectures

[Jonathan Dowland]

On Sat, Jun 05, 2021 at 01:19:10PM -0400, Polyna-Maude Racicot-Summerside wrote:

If you'd have took time to explain the real reason behind why choosing a
RPi4 maybe a good idea versus simply saying they are better than other
choices. Then I would have considered much more knowledgeable your
opinions and fact based.


He did: Marc wrote in his first reply to you that the issue with Siji
Sunny's suggestions was their age. It wasn't an attack on Siji Sunny
themself, although you seem to have interpreted it that way. This is a
pattern I've seen in your interactions on debian-user@, too: a quickness
to interpret messages as being hostile. Please, assume good faith from
fellow participants in the Debian community.


--
👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Bug#989607: ITP: 2geom -- robust computational geometry framework

[Mattia Rizzolo]

Package: wnpp
Severity: wishlist
Owner: Mattia Rizzolo 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org
Control: block 989606 by -1

* Package name: 2geom
  Version : 1.1
  Upstream Author : Inkscape developers
* URL : https://gitlab.com/inkscape/lib2geom
* License : LGPLG-2.1 or MPL-1.1
  Programming Lang: C++
  Description : robust computational geometry framework

The library is descended from a set of geometric routines present in
Inkscape, a vector graphics editor based around the Scalable Vector
Graphics format, the most widespread vector graphics interchange format
on the Web and a W3C Recommendation. Due to this legacy, not all parts
of the API form a coherent whole (yet).
Rendering is outside the scope of this library, and it is assumed
something like libcairo or similar is employed for this.  2geom
concentrates on higher level algorithms and geometric computations.



This library was developed mainly to be used by Inkscape, but it's
released separately in the hope to be useful to others.

I plan to maintain it within the Debian Multimedia team (like I do for
inkscape), and welcome others to join me.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Seeking feedback on a meta package builder

[Helmut Grohne]

Hi Raphaël,

On Tue, Jun 08, 2021 at 12:05:44AM +0200, Raphael Hertzog wrote:
> The point is that if you have to look behind the abstraction to do some
> other related tasks like selecting the worker, then using the abstraction
> to actually execute the build doesn't bring you much, just supplementary
> issues if the assumptions that you make no longer match the assumptions
> implemented in the abstraction.

You do have a point here. My focus definitely was on making it easy for
the one issuing a build. debusine seems to assume both roles here.

I felt that worker selection (let alone worker addressing) would be so
inhomogeneous that covering it in a general abstraction does not seem
feasible to me. That's why I left it out.

With "look behind the abstraction", I think that you mean that debusine
would have to implement the mdbp api to perform worker selection. While
that would be possible indeed, I don't see this as required though.

> And it seems to me that aiming for "it works out of the box without having
> to configure mdbp (if you already have sbuild schroot or pbuilder
> tarball)" is a nice thing to aim for. So somehow it would be nice if your
> various mdbp-* implementations could report whether they are able to
> perform a given build.

This is mostly true. One of the ideas is that when you encounter an
application or service that uses mdbp, it should be easy to direct it at
your existing builder. Some backends will need configuration though, so
a magic autoconfiguration seems infeasible to me. For instance, the ssh
one will need a remote host and for mmdebstrap you most likely want to
specify a local mirror.

I do wonder though, in what kind of situation would you want to merely
know whether a backend can perform a build as opposed to just attempting
it and being able to tell backend issues from actual build failures
apart.

> It would not be enough for debusine yet (for debusine I need to be able to
> export data from the worker and then make that decision on the server and
> not on the build machine itself) but it would be nice step forward for the
> local use case where you want "mdbp" to figure out alone which backend to
> use based on what the user did setup earlier.

Yes, that makes sense. I note that the decision is meant to be made on
the build-issuing side for mdbp as well. If you use the ssh backend, the
relevant command might look like this:

mdbp-ssh someserver.somesite mdbp-mmdebstrap --mirror 
http://mirror.somesite/debian

A user would append their build object to the command line and run it.

This is not meant as a recommendation for debusine to use mdbp-ssh. We
already agreed that it is not a good match.  It is meant to illustrate
that coming up with an automatic backend choice is not obvious though.

> That said if you are willing to complexify your mdbp abstraction to
> cover this use case, then there might be room to actually use mdbp in

There is a trade-off involved here. The reason we're talking now is that
I do want to consider and enable other uses even if that adds
complexity.

> debusine. I would still be annoyed by having to interface with CLI calls
> to make basic requests like those and I would hope that we could define a
> Python API instead.

Let us compare this to gettext. gettext also is an interface, one that
exists in multiple languages though. There is a CLI interface, but for
many languages there are individual bindings. The same can be done here
without loosing the gist.

In fact I already had to do this. The CLI uses arguments, stdout and
files. The latter tend to work badly over ssh, so I already added an
alternative API called mdbp-streamapi that only uses file descriptors to
interface with. The mdbp-streamapi command just converts this
alternative representation back to the "normal" CLI.

Sure, we can add more APIs if needed. The one thing that I'd like to
keep though is for them being compatible or convertible. Being able to
plug them into one another with ease.

> This abstraction definitely makes sense to me. Before looking closely
> at your build_schema.json, but after having looked at your mail here,
> I wrote this as a try to go in your direction:
> https://freexian-team.pages.debian.net/debusine/devel/ontology.html#task-packagebuild

Great. Maybe that's the level where we can make best progress?

> Feel free to submit merge requests to update my document to more
> closely match yours (many entries are missing).

I've taken the liberty to rather open a discussion issue at
https://salsa.debian.org/freexian-team/debusine/-/issues/10. Hope this
works for you. Bringing debusine's PackageTask and mdbp's build_schema is
the thing I'm really after. If these match, converting between the
relevant APIs should become a simple matter.

> Yes, the "command line interface" does not really help for debusine,
> unless you extend it to cover the requirements I explained above. And even
> then I don't really like to have to run an external executable to be abl

Re: Seeking feedback on a meta package builder

[Holger Levsen]

On Tue, Jun 08, 2021 at 10:07:50PM +0200, Helmut Grohne wrote:
> > PS: I already hate the "mdbp" name after having it typed so many times.
> I'm not attached to either. Any suggestions?
 
even medebupa seems better to me.

(assuming mdbp is meta debian build package?)

or meta-debuild or something^wanything more pronouncable.

meta-debuild would imply that 'meta' is the main feature here...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#989629: ITP: elementary-code -- Essential code editor with tab support

[Francisco M Neto]

Package: wnpp
Severity: wishlist
Owner: Francisco M Neto 
X-Debbugs-Cc: debian-devel@lists.debian.org, fmn...@fmneto.com

* Package name: elementary-code
  Version : 3.4.1
  Upstream Author : elementary, Inc 
* URL : https://elementary.io
* License : GPL-3+, LGPL-3
  Programming Lang: Vala
  Description : Essential code editor with tab support

Elementary Code earlier called Scratch, is an IDE
designed with simplicity in mind. It offers essential functionalities
such as git support, multi-panel and miniview support and extensions
for integration with the Terminal and web visualization.

It is written from scratch, with support for plugins. Its purpose is
to be lightweight and extensible, with plenty of customization
options. It support syntax highlighting for a wide range of
programming languages.

It is a minimalist, extensible GTK-based IDE that is not dependent
on GNOME. It follows the Elementary Human Interface Guidelines.

As with other elementary OS-related packages, I'll need a sponsor
(at least for the time being).