Re: Call for votes for "GR: Re-affirm support to the Debian Project Leader"

[Barak A. Pearlmutter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
a65763d3-b1e2-4530-8ff8-aa5915274eb4
[   ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[   ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
[ 1 ] Choice 3: Further discussion
- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFFK7zbLz4Gnv7CP7IRAsdcAJ0Z8fBkERLQ8jM4oNC2TEU/g5sZnQCgqWFu
PoSBxjszqT4jMDIvuWSG/MQ=
=ULhi
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: new tar behavior and --wildcards (proposed middle ground)

[Barak A. Pearlmutter]

Both sides in this discussion seem to have valid concerns:

 FOR making --wildcard the default

   - compatibility with upstream
   - compatibility with standards
   - compatibility with other distributions
   - whatever reasons POSIX had for this were probably sensible
   - upstream's judgement on this is likely to be correct

 AGAINST making --wildcard the default

   - very difficult to figure out what scrips are affected
   - mysterious breakage far into the future
   - requires grubbing around and inserting --wildcard in many places

As a compromise that addresses some of the issues I would suggest the
following: go with upstream, but add some convenience code, to whit:

(1) Hot-wire tar to check an environment variable TAR_WILDCARD_DEFAULT
and activate the --wildcard option if set.

(2) Hot-wire tar to print a warning message to stderr if it
(a) is defaulting to the --no-wildcard behaviour and,
(b) it notices a filename that, had tar instead been
in --wildcards mode, would have been expanded.
If stderr is not hooked up, the warning could reasonably be sent
using syslog() instead.  I wouldn't bother adding any mechanism
to shut these warnings off; if one really wants them shut off,
use either --wildcards or --no-wildcards.

Point (1) would allow people to easily check if some breakage is
caused by this change, or to use old scripts/sources without
contortions; and point (2) would serve to catch problems in scripts
that might otherwise elude us.  Point (2) would be especially helpful
given that we're coming up on a release, so it would be nice to find
and correct all affected scripts as rapidly as possible.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: new tar behavior and --wildcards (proposed middle ground)

[Barak A. Pearlmutter]

Oops, guess I should have checked if it was already done.  My bad.

(Given that the warning is working, why were people making such a
fuss?  Well, never mind.)
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Barak A. Pearlmutter]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> > >From DFSG FAQ Draft ( http://people.debian.org/~bap/dfsg-faq.html ):

> This document mostly represents the opinion of the "DFSG revisionists",
> so it's hardly a surprise that supports the "we decide what is non-free"
> school of tought (sic).

I'm the primary author of that document, so please excuse me when I
ask:  What the fsck are you talking about?

That DFSG FAQ document is an attempt, with contributions by many, to
explain the DFSG and Debian license policies, as practiced.  It was
written before the GFDL general resolution, and to the best of my
ability says nothing particularly controversial about the GFDL.  It is
in fact agnostic on the issue of the freedom of the GFDL sans cover
texts etc.

If you have any particular suggestions for improvement, or have found
what you feel to be factual errors or biases that should be corrected,
I'd appreciate it if you would bring them to my attention.  This might
be more productive than making sly whacky criticisms that I can't even
understand.  I don't even know what a "DFSG revisionist" is supposed
to be!  Are you one?  Am I?  Please help, I can't even tell which side
I'm on, or who the players are!
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#195481: closed by Holger Levsen <[EMAIL PROTECTED]> (upstream issue, not packaging related)

[Barak A. Pearlmutter]

What makes Debian a "distribution" rather than just a random
collection of miscellaneous software is integration.  This is an
integration wishlist.  It has to happen at the distribution level if
it is to happen anywhere.  I don't understand why you want to close
this issue---the logic seems to be just that it's hard to address, but
that doesn't seem like a very compelling reason.  And I don't see how
it can be filed against any (or many) particular packages---it is an
issue that requires policy and coordination between many packages, and
hence belongs on Package: general.

--Barak.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#195481: closed by Holger Levsen <[EMAIL PROTECTED]> (upstream issue, not packaging related)

[Barak A. Pearlmutter]

> As said, feel free to reopen.

Will do.

Debian has made analogous contributions in similar domains: see
package libpaper, or tempfile(1) in debianutils, or emacsen-common.
So it not just our mandate; we even have a history.

> And, as usual.., are you willing to work on this goal?

Willing?  Yes.  Able?  No, not realistically: too many other plates
spinning in the air.  But I'm happy to bounce things around with
people.

> ...  First, some general plan and then an implementation needs to be
> found, maybe within freedesktop.org, maybe not.  Then, packages
> would need to be changed to implement this plan.  And then ...

Exactly.  There are a number of high-level approaches that could be
taken, and it is unclear which would be most sensible.  (Library, like
papersize?  Executable, like tempfile?  Location network server and
protocol?)  But at root, we should recognize that this is not a very
hard problem; merely a tedious one.  Like many design decisions, it
would be good for a group to talk through some options in order to
come up with a minimal but extensible (eg, accept and/or broadcast
location via avahi) design appropriate to this particular problem.
That's what debian-devel is for, at its best.

Then the real hassle starts: rejiggering all the plumbing to hook
things into a shiny new system.

--Barak.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#195481: closed by Holger Levsen <[EMAIL PROTECTED]> (upstream issue, not packaging related)

[Barak A. Pearlmutter]

> (And if there is no progress again within the next two years or so,
> I'll likely close this again.)

Guess we have different ideas about what "wishlist" bugs are for.
My attitude is they're for wishes, like the sea is for fishes.
Sometimes someone picks one up, perhaps even a big wily old fat one.
Maybe takes it on as a summer-of-code project, or whatever.
It might swim around for many years, that's okay.  They form a pool of
ideas, and sometimes someone fishes around and finds one they want to
take to heart.

--Barak.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#567685: ITP: pdf-presenter-console -- PPC is a Keynote-like presentation viewer for PDF files

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

* Package name: pdf-presenter-console
  Version : 1.1
  Upstream Author : Jakob Westhoff 
* URL or Web page : http://westhoffswelt.de/projects/pdf_presenter_console.html
* License : GPL-3
  Description : PPC is a Keynote-like presentation viewer for PDF files

Small but serviceable.
--
Barak A. Pearlmutter 
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Tiny is Fine! [Was Re: Removing the manpage requirement for GUI programs?]

[Barak A. Pearlmutter]

Please don't let the PERFECT be the enemy of the GOOD.

It would be perfect if we had complete man pages for all programs.
But a one-line (not including NAME section header) man page like this:

graphdraw - directed graph editor derived from drawtool

is not just good; it is 100x better than no man page.  And, for an
interactive graphical program which does not usually take command line
arguments and which has built-in help, almost as useful as a perfect
20-page magnum opus man page.

Why?  Because this works:

   man -k midi -s 1

   man -k edit | egrep -i 'graph\b'

It doesn't do users any good to have a program available if they
cannot find it!  Built-in online documentation from a HELP menu does
not do that.  Instead, that role is filled by menufile(5) and man(1)
and whatis(1).  The menufile system is useless for finding, say,
xournal if I'm looking for a PDF annotation program.  But man pages,
even super-short ones, with a couple keywords in the 1st line, are
great for that.

So please: takes two minutes and make a one-line man page listing a
some relevant keywords for your nifty graphical application, even
though it has a 278-page built-in html manual.

        --Barak.
--
Barak A. Pearlmutter 
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1nunuk-0006wp...@golconda.cs.nuim.ie

Bug#516898: ITP: scheme9 -- Scheme 9 from Empty Space R4RS Scheme interpreter

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 


* Package name: scheme9
  Version : 2009.02.09
  Upstream Author : Nils M Holm 
* URL : http://t3x.org/s9fes/
* License : ideosyncratic near-MIT/X
  Programming Lang: C, Scheme
  Description : Scheme 9 from Empty Space R4RS Scheme interpreter

 Scheme 9 from Empty Space is an interpreter for a broad subset of
 R4RS Scheme, and runs in many popular environments, including
 Linux, *BSD, the unmentionable horror, and Plan 9.  The S9fES code
 strives to be simple and comprehensible.  It is particularly
 interesting to people who want to (a) try Scheme without having to
 jump through too many hoops (S9fES is very portable); or (b) study
 the implementation of Scheme (in a language other than Scheme).  A
 free online textbook describing the system is also available.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Subject=Re: Can a leaf package require SSE2 on i386?

[Barak A. Pearlmutter]

The package "ikarus", another programming language implementation,
also requires SSE2 support.
There is a check in the preinst script which aborts installation if
sse2 is unavailable.

case "$1" in
install|upgrade)
if egrep -q '^flags[[:space:]]*:.*\bsse2\b' /proc/cpuinfo; then
# echo CPU instruction set extension sse2 confirmed
true
else
echo "error: CPU flag sse2 not found, aborting installation"
exit 1
fi
;;

Cheers,

--Barak.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANa01B+3oeZjFtTm=-t+herqb29ag-4uvfu3j8henfxto1h...@mail.gmail.com

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Barak A. Pearlmutter]

People embarking on packaging a bit of software are also supposed to
contact the upstream author.  When one contacts the upstream author
and they respond quickly and say they'd love to have the software
packaged and they don't know of anyone else doing so, an ITP can seem
(depending on the particulars of the situation) a bit superfluous.

If people are going to do only one of (a) heads-up to upstream author,
and (b) file an ITP, I personally would rather see them do (a).  Of
course, doing both would typically be best.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1SIy6b-7u-Cf@port-kdr.hamilton.local

Re: Target path variables in debian/rules

[Barak A. Pearlmutter]

> Why not reverse the two commands:

> override_dh_installman:
>   /somepath/create-a-man-page > debian/packagename.1
>   dh_installman --

>  Let dh_installman install the generated manpage.

To my mind this violates modularity, in that *building* the man page
is happening during what is supposed to be just *installing* it.

I'd write either:

 override_dh_auto_build:
dh_auto_build
/somepath/create-a-man-page > debian/packagename.1

Or maybe just let "make" do its job and allow parallelism and be clear
about dependencies with

 override_dh_installman: debian/packagename.1
dh_installman

 debian/packagename.1:
/somepath/create-a-man-page > $@

assuming the man page creation does not require some built executable.

Cheers,

            --Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1ScYv3-0002tp-MV@port-kdr.hamilton.local

Re: Lets (eventually) find a good solution for /tmp

[Barak A. Pearlmutter]

Don is right.

I'd like to step up a level and think about the situation.

The real issue here is that having /tmp be just another directory in a
writable partition filesystem, like / or /home or whatever, means that
/tmp gets all the associated properties.  One such property (A) is
that files can be large and can bleed off to disk smoothly without
thrashing the system, both of which are problems with tmpfs.  On the
other hand, another property (B) is that a great deal of effort is
going into ensuring that files get written to disk in a timely
fashion, that data and metadata survives crashes, and that structures
on disk are consistent, up-to-date, and if necessary, quick to check.
We want /tmp to have (A), but it need not have (B).

So this is a technical question.  Can we implement a filesystem which
provides properties A, but which (C) has zero data surviving after a
crash or umount, and takes advantage of property C to make things
faster.  This seems like a much easier problem than the problems that
journaling filesystems and their ilk solve.  But even though it may be
an easy problem, to my knowledge, no one has implemented a solution.

IDEAS

One thought would be to make a fuse filesystem which keeps small files
in the fuse process itself (like tmpfs) and puts big files on a big
filesystem but *unlinks* the files so their only reference is via an
open handle held by the fuse process itself.  The files are thus
backed on disk as usual, and can be large, but when the fuse process
dies *bam* they're gone, and the usual recovery mechanisms scavenge
their space after a crash.

Another thought would be to hack tmpfs to keep only big files in some
backing filesystem, perhaps using handles to unlinked files as above,
thus having the advantages of tmpfs for small files while also
handling large files well.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1SeSpB-00060c-Cg@port-kdr.hamilton.local

Bug#685720: ITP: expand-region-el -- Increase selected region in Emacs by semantic units

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: expand-region-el
  Version : 0+git.1.d157d7f
  Upstream Author : Magnar Sveen 
* URL : https://github.com/magnars/expand-region.el
* License : GPL3
  Programming Lang: elisp
  Description : Increase selected region in Emacs by semantic units

 Expand region increases the selected region by semantic units.  Just
 keep pressing the 'C-=' key until it selects what you want.
 The notion of "semantic" is language-sensitive.
 .
 Example: editing
 .
 (setq alphabet-start "abc def")
 .
 With the cursor at the `c`, it starts by marking the entire word
 `abc`, then expand to the contents of the quotes `abc def`, then to
 the entire quote `"abc def"`, then to the contents of the sexp `setq
 alphabet-start "abc def"` and finally to the entire sexp.

(initial packaging in git://github.com/barak/expand-region.el)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1T4fBP-0007o9-5E@port-kdr.hamilton.local

Bug#726393: solution via obfuscation

[Barak A. Pearlmutter]

Perhaps this issue could be solved by manipulating source tarballs in
question to obfuscate the problematic snippets.  Eg,
 gpg  --encrypt --symmetric --passphrase WhiteList ICKY-FILE
This would be unpacked appropriately at build time.
If the same issue comes up for binaries, a similar mechanism could be
used there, with the post-installation scripts doing the de-obfuscation.

I won't say it's pretty ... but it would suppress these false positives.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob6nvn5k@cs.nuim.ie

Re: Candidates for removal from testing (2012-11-30)

[Barak A. Pearlmutter]

> > # #692623
> > remove fossil/1:1.22.1-1

> This is worrying because fossil is the vcs used by sqlite upstream.

> It looks like fixing this would involve Packaging "cson" too.  The
> alternative of dumping cson into the fossil source tree is probably
> not ideal.

> Barak, have you looked at this at all yet ?

Hi Ian,

CSON is not used in the Debian build: the relevant source files can be
replaced by empty files and the fossil package will build fine.  (They
cannot just be removed because make expects them.)

I thought this CSON issue was being ignored for wheezy, otherwise I
would have gone through the appropriate machinations to implement the
above.

--Barak.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1TePl1-0004Og-LD@port-kdr.hamilton.local

Re: Candidates for removal from testing (2012-11-30)

[Barak A. Pearlmutter]

Good idea.  Will add this info to the bug report.

Technically there are two bugs.  692623 is for the CSON "not evil" files
being derived files rather than truly original source, while 692624 is
for the "not evil" license itself.  The latter is already tagged
wheezy-ignore, while the former is causing the package to be queued for
removal.  Can I just merge them, since the fix (remove the problematic,
albeit in this case unused, code) is the same?

--Barak.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk1zypb7@cs.nuim.ie

Re: Candidates for removal from testing (2012-11-30)

[Barak A. Pearlmutter]

The "patch" for both of these bugs is to just replace
 src/cson_amalgamation.{c,h}
by empty files in a +dfsg recombobulated upstream tarball.
I'll go ahead and do the machinations.  Unless someone else does an NMU
first.  A 0-day NMU.  Which I totally wouldn't mind.  Hint Hint.

    --Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqx2zyi4@cs.nuim.ie

Bug#736420: ITP: zenlisp -- Interpreter for purely symbolic, pure, lexically scoped dialect of LISP

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: zenlisp
  Version : 2013.11.22
  Upstream Author : Nils M Holm
* URL : http://www.t3x.org
* License : Public Domain (essentially)
  Programming Lang: C
  Description : Interpreter for purely symbolic, pure, lexically
  scoped dialect of LISP

 Zenlisp is an interpreter for a purely symbolic, side effect-free,
 lexically scoped dialect of LISP.  It may be considered an
 implementation of pure LISP plus global definitions. Zenlisp is
 derived from ArrowLISP.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sise7p0z@cs.nuim.ie

Bug#740822: ITP: colpack -- Graph vertex coloring library

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: colpack
  Version : 1.0.9
  Upstream Author : Alex Pothen 
* URL : http://www.cscapes.org/coloringpage/
* License : LGPL-3+
  Programming Lang: C++
  Description : Specialized graph vertex coloring library

ColPack is a package comprising of implementation of algorithms for
specialized vertex coloring problems that arise in sparse derivative
computation.  It is written in an object-oriented fashion heavily
using the Standard Template Library (STL).  It is designed to be
simple, modular, extenable and efficient.  Its primary application
has been for use in automatic differentiation.

It is already packaged in Fedora.

The adolc library package can optionally use it, and my reason for
wanting to package colpack is to allow me to enable that option in the
debian adolc package.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140305110417.9259.10354.reportbug@port-kdr.hamilton.local

Bug#743710: ITP: mlpack -- Fast and scalable C++ machine learning library

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

Package name: mlpack
Version : 1.0.8
Upstream Author : Ryan Curtin 
URL or Web page : http://www.mlpack.org/
License : LGPL-3+
Description : Fast and scalable C++ machine learning library

MLPACK (Machine Learning PACK) is an intuitive, fast, and scalable C++
machine learning library, meant to be a machine learning analog to
LAPACK.  It aims to implement a wide array of machine learning methods
and function as a "swiss army knife" for machine learning researchers.

Upstream has been notified of this ITP, and is encouraging.

For a preliminary packaging, see
 git://anonscm.debian.org/debian-science/packages/mlpack.git

Most of the lintian issues are due to doxygen generating bogus man
pages.  Excepting those, I'd hope to either address or report the issues
to upstream for most of the others before uploading.

    --Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnwgylgi@dellarge.hamilton.ie

Bug#746266: ITP: latex-coffee-stains -- Add a coffee stain to your LaTeX documents

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

* Package name: latex-coffee-stains
  Version : 4
  Upstream Author : Hanno Rein
* URL or Web page : http://hanno-rein.de/archives/349
* License : "You can freely distribute this package as I do not believe 
in imaginary property."
  Description : Add a coffee stain to your LaTeX documents

This package provides an essential feature that has been missing from
LaTeX for far too long: coffee stains.  Much time can be saved by
printing them directly thus avoiding the laborious manual coffee
staining process.  There are four different stain types to choose from.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87sioxeaav@cs.nuim.ie

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

[Barak A. Pearlmutter]

It is traditional to use the ancient IBM text "This page intentionally
left blank"

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> We have two separate issues here:

> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp

> I think it makes sense to discuss/handle those separately.

Agreed.

I also don't see any issue with a/, at worst people will be annoyed
with it for some reason and can then change it back.

> Regarding b/: ...

> The tmpfiles rule tmp.conf as shipped by systemd upstream ...
> Files that are older then 10 days or 30 days are automatically cleaned up.

This seems like a rather dangerous thing to spring on people.

First of all, time can be pretty fluid on user machines.

Someone has a laptop, they do some work and generate big files in
/var/tmp/, maybe they're editing videos or processing medical images
or downloading and pre-processing large datasets for machine learning.
Now they close their laptop and go on vacation for six weeks. When
they come back they open it and ... shazam all the files they were
working on are deleted.

Another scenario. I download a big source tarball, firefox say. I want
to make a few small changes and compile a custom version. I keep it in
/var/tmp/ for obvious reasons. (The patches are stored elsewhere of
course.) Now I download a new patch and apply it and recompile. And
get an error, because *some* of the files in the unpacked tree were
too old and got auto-deleted.

Imagine suspending a computer in the middle of a big build, and when I
un-suspend it a few weeks later the build fails because some files are
now too old and get deleted. Is this really desirable?

To me, the purpose of /var/tmp/ when I have my "user" hat on is: a
place to put files I don't want backed up, particularly large ones,
and which if I run out of disk space is a place to look for stuff to
delete. it's not "a place to put files that the system might
capriciously delete just because."

I do understand the imperative to keep the filesystem clean and to do
routine maintenance and upkeep without user intervention. But changing
something that used to be "stable storage unless your disk crashes"
into "files placed here can mysteriously disappear" seems like a major
potentially-breaking change that can disrupt common work flows.

I can see popping up a warning: "disk space on the filesystem
containing /var/tmp is getting low and /var/tmp contains xxxGb of
files, hit OKAY to delete the xxxGb of oldest files there" or
something like that. But doing it silently is scary.

One compromise would be to enable the /var/tmp/ reaper by default only
on new installations. People can always turn it on if they want. Also,
when files are deleted, I think the user should get warnings all over
their desktop. I'd also suggest that the reaper by default never
delete files from /var/tmp if there is a lot of space available, or if
/var/tmp isn't consuming much space.

--Barak Pearlmutter

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> Then upon reading the release notes, on such a machine, one can simply do:
>
> touch /etc/tmpfiles.d/tmp.conf
>
> And they get no automated cleanups.

This also disables on-boot cleaning of /tmp/.

The root issue here is that deleting not-read-in-a-while
but-maybe-stat'ed-recently-by-make-that-doesn't-count files from
/var/tmp/ by default, particularly when the system didn't used to,
violates the principle of least surprise. It will cause problems for
end users. And disabling it *properly* requires serious sysadmin
knowledge and is easy to get wrong.

There's an old debugging story: Maclisp on a DEC-10 was glitchy some
days and not others. Someone marked the crashes on a calendar, and
they correlated with the phase of the moon! Turns out the program
printed the lunar phase ("crescent", "waning gibbous", etc) in its
header, just for fun, and when the string was long it wrote past the
end of a buffer, etc.

The story is still told fifty years later because it's so funny, it's
a total violation of levels. People debugging in a windowless basement
should not need to know the phase of the moon!

Users want their systems to run reliably and reproducibly. Getting
different behaviour depending on how long it's been since some of the
files you're using have been *accessed* adds oodles of extra state
people have to keep track of in their mental model of what some
program needs to run. Sure, it can be administratively disabled on one
particular system; but then you run the same program or perform the
same work-flow on another system, and it fails. Something fails
reliably after running for over 30 days ... unless you keep an eye on
it.

As someone who regularly deals with large datasets, and keeps them in
the "approved" don't-back-these-up location /var/tmp/, this just seems
crazy to me. When I tell a grad student to install Debian on their
laptop, do I really need to spend time explaining to them to be sure
to turn off the "delete your old files for no reason" option which is
enabled by default? When they're using someone else's cluster, should
I remind them to run a cron job "find /var/tmp/foo -exec touch ..." so
the 25 Tb of data we pushed onto scratch storage on that cluster
doesn't partly disappear? Our priority should be our users. Our users
are not well served by having their files deleted. They put them there
for a reason!

--Barak.

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> What I am looking for right now is packages or internal
> infrastructure that need
> an update to cope with these two changes before I upload them, so if
> you know of any please do let me know and I'll happily look into it
> and at least file a bug, if not a MR. Thanks.

Okay.

git and other version control systems should be modified to warn if
the work tree or git dir are in /var/tmp and therefore exposed to
unexpected deletion of files, and possibly modified to refuse to clone
there without an explicit --force-unstable-storage option.

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

If it clones into /tmp the *entire* tree will either be reaped (upon
reboot) or not.

But having just some files deleted from a git dir or git working dir
is much more dangerous, because various git commands can treat files
deleted from the working tree as deliberate changes to be committed,
and files deleted from the git dir can render it unusable.

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> tmpfiles.d snippets can be defined to cleanup on a timer _anything_,

It's a question of what the *default* behaviour should be.

For whatever reason, a lot of people who process large data use
/var/tmp/FOO/ as a place to store information that should not be
backed up, but also should not just disappear.

Maybe they should use ~/FOO/ but put a CACHEDIR.TAG file with the
right magic contents there. Or touch ~/FOO/.nobackup and use duplicity
--exclude-if-present .nobackup. Or ~/.cache/FOO/, although that's a
bit counterintuitive because it's "hidden" and not really meant for
this purpose.

There's a reason people don't want these files below ~/, which is that
some backup mechanisms, like btrfs snapshots or LVMs snapshots, may
snapshot files there regardless; and often /home/ is on more
stable/expensive storage (raid k for k≥1) while /var/tmp/ is on a
cheaper substrate.

Given the era of large data we're living in, this is a ubiquitous
problem. Since we don't give users a standard solution, they've rolled
their own. If we think that solution is wrong, we should (a) make an
actual official suggested location for this sort of material,
/var/scratch/ or /var/scratch/${USER}/ with a link there from
~/Scratch or something, and (b) transition them to it, ideally without
unexpectedly deleting their files and messing up their work in the
process.

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

Rhys, I think you're being unfair. We have a *technical* disagreement
here. But our hearts are all in the same place: Luca, myself, and all
the other DDs discussing this, all want what's best for our users, we
all want to build the best OS possible, and are all discussing the
issue in good faith.

There is an unavoidable tension, and we're hashing it out. Upstream
has fielded a default behaviour which requires adjustment of a variety
of other programs and workflows. Basically, anything that stores stuff
in /tmp or /var/tmp needs to be made might-be-deleted-aware. There are
mechanisms for dealing with this, but they're pretty complicated, and
differ wildly for different file lifetimes etc. Other distributions
have adopted that default, and rather than using exposed mechanisms
for avoiding unexpected deletion, are just telling people not to count
on files in /var/tmp/ surviving a reboot if the computer is shut down
more than a month, or whatever. What should Debian do? You can make
arguments both ways, and we are. Generally we follow upstream unless
there's a compelling reason not to. You can suggest various strategies
for making things reliable despite following upstream. You can discuss
why maybe upstream should not be followed in this case. This is
precisely the kind of discussion that leads to good decisions, with
everyone keeping an open mind and sharing information and ideas.

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> ...3) I would put a file in any auto-cleaned space named "1-AUTOCLEAN.txt" 
> that contains some verbage explaining that things in this directory will be 
> wiped based on rules set in (wherever).

You know, that's a pretty good idea!

Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the
default deletion policy, the policy in place if it's not the default,
and a pointer to info about altering it. "/tmp's contents are deleted
at boot while /var/tmp is preserved across rebooting." Maybe in
/var/tmp suggest /var/scratch/ or /var/cache/tmp or such as a place
sysadmins might want to set up for not-backed-up but not-auto-deleted
material.

If the contents aren't dynamic, maybe they could be links to files in
/usr/share/doc/systemd/.

Re: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

I guess sometimes when people discuss technical matters, good ideas pop up.

(Although I still think that its problematic interactions with lengthy
suspends makes the whole idea of auto-deletion based purely on
timestamps problematic. I can imagine more coherent mechanisms, which
doesn't count time the machine was suspended against the removal
clock, which check if any files are open, check if any process has its
current directory in a tree, which treats trees as a whole instead of
deleting leaves piecemeal only deleting the tree if all its contents
are ripe, etc. That would introduce considerable complexity though.
However, it is the sort of thing a good sysadmin would do before
manually removing stuff in /var/tmp/, so ...)

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

> I'd like to hear some arguments *in favour* of making this change.
> Alignment with systemd-upstream, reduced package maintenance burden
> are two that I can think of, but perhaps I've missed more. These two,
> IMHO, are significantly outweighed by the risks.

Let me see if I understand the arguments being made in favor.

1. Compatibility with upstream. This means all the upstream logic is
sort of imported by reference, so the below is mainly the upstream
logic, as I understand it.

2. Defend the system against buggy programs that leave debris in
/var/tmp/, and against debris left there when programs are terminated
prematurely. These are programs which use /var/tmp/ internally, but
not as part of their API, so the user would have no particular way of
knowing that they are leaving things there, would have no particular
reason to check for and delete such files, and might not be able to
easily recognize which files should be removed.

3. Defend the system against forgetful users, who create files in
/var/tmp/ but neglect to delete them when they're no longer needed.

Unfortunately 2 & 3 cannot be mechanically distinguished, so even if
you wanted to have separate policies for these two classes of files,
it's not really technically possible. So upstream is optimizing for
case (2), and suggests that /var/tmp/ be sort of reserved for programs
and scripts that are aware of this policy, and users not manually
create files there.

I hope that's an accurate characterization.

I looked at the upstream bug report
https://github.com/systemd/systemd/issues/32674 which suggests that
deletion of directory trees in /var/tmp/ be atomic, and trigger only
when everything in the tree meets criteria for deletion. I added a
comment suggesting that the policy be tweaked in two ways. (a) Use
system-up time rather than wall-clock time for measuring file age, to
address the "suspending or shutting down for over 30 days breaks
running data processing scripts that uses /var/tmp/ for intermediate
files" issue. I sort of have an invariant in my head, which is that
suspending the computer doesn't break things, and also the whole point
of /var/tmp/ is that files there are preserved across boots. And (b)
check if a file is open by some process, the same way fuser(1) does,
and if so, don't delete it. Could also preserve directories which are
the current directory of some process, if you want to be even more
user friendly.

The only response I got was "don't use temporary directories for
things that you cannot afford to lose and recreate", which I don't
really understand. It's like saying "you should have good backups, so
it's not a problem to just delete anything in /home older than two
days". Bottom line, it's not clear to me that upstream has really
thought this through with users in mind. I'd suggest that Debian may
wish to tweak the defaults on this stuff pretty hard to be more user
friendly.

Here are a couple cheap tweaks I'd suggest. My hope is that these
would avoid some of the worst case scenarios discussed while still
satisfying the goals 1/2/3 above, and being super easy to implement.

- lengthen the reap time for /var/tmp/ to eight weeks, since Europeans
often take six-week vacations.

- make a "tempdir" command, philosophically similar to tempfile in
debianutils, which creates a fresh directory in /var/tmp/ and drops
the user into a shell with that as the current directory, directory
flocked until that subshell terminates. Could give an optional
directory argument to lock so you can get back into a directory, and
maybe have options to run a program there before or instead of the
subshell.

- following a resume-from-suspend or boot, shut off the
delete-old-files-in-var-tmp mechanism for a while, maybe eight hours
or something like that. Maybe shorten the delay if it doesn't get to
run across multiple resume-or-boot cycles for a week or two.

- as discussed earlier, add /tmp/00-README and /var/tmp/00-README to
explain this old-file-deletion policy

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Barak A. Pearlmutter]

Unless somebody's already put it there, I'm going to move these
suggestions to a wishlist bug against systemd. Not sure if it should
be one bug or a few, one for each suggestion.

Currently discussion about reaping /var/tmp/ is in
https://bugs.debian.org/966621 and
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1870585 but
these are discussing "should we turn on /var/tmp/ reaping" rather than
"if we do turn it on, should we take measures to make it safer".

Re: Intel SOF audio firmware packaging

[Barak A. Pearlmutter]

My Dell Inspiron 7591 2n1 required the SOF audio firmware, so I did a
quick packaging for my own purposes, to be sure I had the latest. See

 https://github.com/barak/sof-bin
 branch: debian

Works for me, and of course my packaging scripts are free for use in
whole or in part etc (I hereby place them in the public domain.)

Cheers,

--Barak.

Re: Re: using uscan with Fossil SCM

[Barak A. Pearlmutter]

As the Fossil Debian package maintainer, I'd certainly be grateful for
notes on how to use Fossil for Debian packages. I have my own
idiosyncratic workflow for Fossil itself, but it's not general because
it relies on upstream's distribution of tarballs, and otherwise uses
the local fossil repo, and is not very automated. Would be happy to
put notes, scripts, snippets, etc, in
/usr/share/doc/fossil/README-Debian or some such.

A pipeline with "v=$(fossil tag list | egrep  | max) ;
fossil tarball $v foo.tar" where  defaults to version_.*
or some such but can come from debian/gbp.conf might be useful, for
use with a local fossil repo. If there's nothing local only remote,
hmmm

One thing I should mention is that Fossil upstream is very
cooperative. If the web pages a Fossil repo makes available by default
don't have the right hooks for uscan, if we could ask for something
very simple (maybe a page with a list of all tags each consisting of a
link to a tarball FOO-tag.tar.xz) that would I think be something they
would seriously consider.

--Barak.

Re: using uscan with Fossil SCM

[Barak A. Pearlmutter]

> Yes it would be fine. This page can also be a JSON page
> (opts="searchmode=plain")

Ah, then it wouldn't be Fossil-specific at all. Good idea.

Bug#988031: ITP: youtubedl-gui -- GUI on youtube-dl to download videos from a variety of sites

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: youtubedl-gui
  Version : 2.5
  Upstream Author : Jason Goulet-Lipman 
* URL : https://github.com/JaGoLi/ytdl-gui
* License : GPL-3+
  Programming Lang: C++
  Description : GUI on youtube-dl to download videos from a variety of sites

 Graphical interface to youtube-dl, the CLI for downloading videos
 from a variety of sites. Allows control of format, resolution, audio
 and video codecs, etc.

It's a small qt program with a cmake build system.
Prelim packaging at https://salsa.debian.org/debian/ytdl-gui

Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Barak A. Pearlmutter]

Seriously? Being able to type

dpkg -S $(which cat)

instead of

dpkg -S $(which cat|sed 's:^/usr::')

is the big user-level pain point?

People seem pretty worked up over this, but honestly I'm not
understanding why. We already have $PATH which (let's be honest) is an
ancient crappy workaround for the original Unix sin of not keeping all
the executables in one place. (And analogous wheel-reinventing goo for
/lib vs /usr/lib vs /usr/lib/x86_64-linux-gnu, etc.) Given that,
moving them around isn't supposed to be a big fuss. Oh, but there are
also shebang #!/bin/foo issues and other hard coding. The shebang is
already such a mess that people use #!/usr/bin/env foo, just to get
foo searched in $PATH. (85 of the 890 scripts in /usr/bin/* on the
machine I'm typing this on use a /usr/bin/env trampoline.) Nobody
would ever consider having /bin/foo and /usr/bin/foo be different
programs, that would be madness. The TC basically concluded that the
distinction between /bin and /usr/bin, etc, had totally broken down
and there's no advantage to keeping them distinct, plus initrd is the
new /bin. (Pretty much the same argument as in the design of plan9.)
I'm not seeing much argument against that, except for nostalgia.

It seems that dpkg is ground zero for problems that occur during the
transition itself, and for the problem of handling the transition
gracefully. I for one am enormously impressed with the quality of
dpkg: its amazing robustness, the way it's evolved to support hooks
and such and really been the cornerstone of the distribution. So I
think we should take the dpkg maintainer's concerns seriously. But
frankly I don't quite understand them.

--Barak Pearlmutter.

Re: Q: How to avoid blhc failure

[Barak A. Pearlmutter]

That file is specially compiled using a different set of flags. This
is done deliberately, and is not an issue. You can squelch the false
positive using an appropriate stanza in debian/rules, to issue a
command in the log that tells blhc to stand down. Like this:

execute_before_dh_auto_build:
@echo "blhc: ignore-line-regexp: .*/CMakeCXXCompilerABI.cpp.*"

Bug#949948: ITP: gnu-apl -- GNU APL

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: gnu-apl
  Version : 1.8
  Upstream Author : Jürgen Sauermann 
* URL : https://savannah.gnu.org/projects/apl
* License : GNU GPL
  Programming Lang: C++
  Description : GNU APL

 GNU APL is a free APL interpreter. It (almost) fully implements
 ISO/IEC Standard 13751: Programming Language APL, Extended

Build-Depends-If-Available

[Barak A. Pearlmutter]

I'm maintaining mlpack. It is able to generate julia bindings, so on
architectures in which julia is available I'd like to generate julia
bindings, and this requires julia to be installed at build time. I've
set up debian/rules to check if julia is installed, and set
configuration options appropriately. Similarly, it seems best to build
the package using clang if possible, but if clang isn't available it
can be built using GCC (assuming you build single threaded and roughly
six hundred mysterious GCC space-saving options are set).

I thought I could accomplish this with build dependencies like

Build-Depends: julia | hello, ..., clang | buthead

where hello and buthead are stupid little packages that are available
on all architectures but would not otherwise be installed. Ugly, sure,
but maybe it would get the job done. Nope! The build daemons just try
to install julia and clang and fail if either's not available. I've
also seen

Build-Depends: julia | dpkg, ..., clang | dpkg

but that also doesn't work.

I could check which architectures have julia, and which have clang,
and list them.

Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel
armhf i386 ...]

but that makes my skin crawl because it is highly non-future-proof and
violates all sorts of software engineering principles.

Anybody know if there's a good solution to this problem?

Re: Build-Depends-If-Available

[Barak A. Pearlmutter]

On Sun, 9 Aug 2020 at 17:05, Adrian Bunk  wrote:
> The pragmatic solution is to list the 3 architectures where julia
> currently builds.

Okay, thanks for the hints, Adrian. That's what I'll do for now.

> The software engineering solution would be a dependency package
> julia-or-nothing that depends depending on the architecture either
> on julia or nothing.

This is a recurring problem, and seems slated to grow in severity as
Debian tentacles inself into more heterogeneous environments and as
software systems become larger and more complicated with more options.
Machine learning systems in particular can be built against various
sorts of hardware support libraries which phase in and out of fashion
with shocking speed. So manually generating julia-if-available, and
(thanks to Simon McVittie for the examples) valgrind-if-available, and
libseccomp-if-available, etc, seems to scale poorly, and would be a
lot of work. I suppose we could generate them automatically, like -dbg
packages. Blech! They'd also pollute the archive.

So let me step back and try to look at the problem a bit more globally.

I understand what you're saying, and indeed trying to encode
"Build-Depends-If-Available: foo" as "Build-Depends: foo | something"
is a bad idea from the get-go. After all, foo can have three states on
an architecture: installable, unavailable, or
available-but-uninstallable-for-some-reason. And we want different
behaviour in the three cases: build with it, build without it, or
delay-building-until-installable. And we can't shoehorn those three
things into the binary logic of "foo | something".

On the other hand, the maintainer isn't really in the right position
to figure out what architectures foo is available or should be
installable on. The buildd's are the place where that information is
really manifest. (And we might even make a stripped-down build, or a
derived distribution without systemd, and want packages to adjust
appropriately to that build environment as much as possible.)

Making up a whole new control field, like Build-Depends-If-Available:,
seems like overkill. But we already have a certain level of
abstraction in architectures, e.g., we can say foo [linux] to get foo
on systems running the linux kernel. How about we add this kind of
thing as an abstract architecture. So one could write perhaps
"Build-Depends: julia [has-julia]" to get julia iff a julia package
exists. I think that would be pretty easy to implement (no
installability check or backtracking; just check if a package by that
name exists). It would also give more flexibility than a generic
"Build-Depends: julia [IF-IT-EXISTS]" in case there are support
packages necessary only if something else is available. Like
"Build-Depends: chicken [has-chicken], swig [has-chicken]" to pull in
swig if you're generating chicken bindings, which makes sense only if
chicken is on that architecture.

TLDR: suggest encoding as abstract architecture. Build-Depends:
valgrind [has-valgrind], julia [has-julia]

Re: Build-Depends-If-Available

[Barak A. Pearlmutter]

On Sun, 9 Aug 2020 at 19:01, Adrian Bunk  wrote:
> The number of tools parsing build dependencies or doing dependency
> resolution is larger than you might expect.

Yeah, I can only imagine. And they're not all in one great big git
repo either! That's one reason I thought pushing it into the
architecture field might make sense: code dealing with architectures
has at least some abstraction already, because architectures are a
moving target, and are also a bit complicated. In this case, you could
put a clause into "dpkg-architecture --equal" to make an architecture
of "has-foo" just check (using the right API) if "apt policy foo" has
a candidate, and catch a significant fraction of the cases.

Re the "chicken no longer exists, use chicken-bin" bit-rot issue,
lintian could raise a flag for a [has-foo] arch when foo doesn't exist
in the target distribution on any architecture. We already have that
issue for binary packages with "Recommends:" and "Suggests:".

Bug#905855: ITP: qlogo -- Language using turtle graphics famous for teaching kids

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: qlogo
  Version : 0.92
  Upstream Author : Jason Sikes 
* URL : https://qlogo.org/
* License : GPL2+
  Programming Lang: C++
  Description : Language using turtle graphics famous for teaching kids

 QLogo is an interpreter for the Logo language written in C++ using
 Qt and OpenGL. Specifically, it mimics (as reasonably as possible)
 the UCBLogo interpreter developed at U.C. Berkeley. In fact, the
 UCBLogo manual describes about 99.9% of the functionality. You can
 find the UCBLogo Manual here:
 http://people.eecs.berkeley.edu/~bh/usermanual

Justification:

Basically, the ucblogo system is moribund, this is a proper clone using
somewhat modern tooling.

Bug#819980: ITP: nuntius-linux -- Get notifications from your Android phone or tablet over Bluetooth.

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: nuntius-linux
  Version : 0.2.0
  Upstream Author : The Holy Lobster Team
* URL : https://github.com/holylobster
* License : GPL-2+
  Programming Lang: Vala, C
  Description : Get notifications from your Android phone or tablet over 
Bluetooth.

Delivers notifications from your Android phone or tablet to your computer over 
Bluetooth.
To use, you will need to install a companion tool on your phone or tablet and 
pair it via Bluetooth.

Similar to KDE Connect, packaged as kdeconnect, but uses Gnome
libraries and doesn't pull in 200Mb of KDE infrastructure.  Also much
less mature.

Re: Bug#819980: ITP: nuntius-linux -- Get notifications from your Android phone or tablet over Bluetooth.

[Barak A. Pearlmutter]

> Why "-linux" in the name if it doesn't seem to be Linux-specific?

Good question.

That's just the name of the source package, following upstream's repo name,
which is parallel to their nuntius-android source repo. The binary package
would be just nuntius.

Bug#823425: ITP: chez-scheme -- Implementation of the R6RS Scheme language

[Barak A . Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

* Package name: chez-scheme
  Version : 9.4
  Upstream Author : R. Kent Dybvig and others
* URL or Web page : https://github.com/cisco/ChezScheme
* License : Apache 2
  Description : Implementation of the R6RS Scheme language

Cisco has released Chez Scheme under a free license.
All hail our new routing overlords.