Bug#1013089: ddccontrol-db: Version number not matching with upstream

2022-06-17 Thread Barak A. Pearlmutter
Thanks. Good eye!
Turns out upstream had a typo in a git tag, which is what the
packaging tooling sees.
Hardly seems worth bumping an epoch when it will be solved by just
waiting a few weeks. We call this "laziness", right?



Bug#997823: Fix as merge request

2022-05-16 Thread Barak A. Pearlmutter
I've issued merge requests on salsa to the pulseaudio package that
addresses this issue. All it does is install the modules in
/usr/lib/pulse-MAJOR.MINOR/modules/. Using that small fix, paprefs is
not grayed out anymore.



Bug#997823: module path

2022-05-11 Thread Barak A. Pearlmutter
Just took over paprefs. Yes this is an issue.
You can fix it for now by adding a symbolic link, but yuck.

Open to suggestions.

See https://bugs.debian.org/1003163

(Maybe these bugs should be merged)



Bug#1003163: What's the Problem

2022-05-11 Thread Barak A. Pearlmutter
The root cause here seems to be that

pa_get_library_version()

in libpulse0 does not include the "+dfsg" suffix.

I'd say that either (A) it should, or (B) the pulse stuff should all
be installed in a directory without the suffix, or (C) there should be
a symbolic link from a non-suffix directory to the suffix one.

It's not clear to me why the "+dfsg" in the debian package version
should be something the innards of the package knows about, so I'd
vote for (B).

It's tempting to reassign this bug to libpulse0.

It's even more tempting to suggest that libpulse0 should have a
function that takes the name of a module and returns the path to that
module, so clients don't need to go through torturous logic to figure
out where the modules might be.

$ ls -d /usr/lib/*pulse*
/usr/lib/pulse-15.0+dfsg1

$ gdb /usr/bin/paprefs
(gdb) run
C-c
(gdb) print (char *)pa_get_library_version()
$1 = 0x774cad12 "15.0.0"



Bug#1010418: Proposed bugfix

2022-05-08 Thread Barak A. Pearlmutter
I don't understand this code in that patch:

+   while (true) {
+   unowned Posix.Passwd passwd =
Posix.getpwent();
+   if (passwd.pw_name ==
GLib.Environment.get_user_name()) {
+   found = true;
+   cmd += passwd.pw_shell;
+   break;
+   }
+   }

Will that loop forever if get_user_name returns something that doesn't
have an entry in /etc/passwd?



Bug#1008354: fossil: FTBFS: ./conftest__.c:3: undefined reference to `sqlite3_open'

2022-05-05 Thread Barak A. Pearlmutter
Yes.

I patched over the issue for now by just using the internal sqlite3
library, so I think it can wait until the next official release to
pick up the proper bug fix and go back to using the system sqlite3
library.



Bug#1009000: Prelim Packaging

2022-05-02 Thread Barak A. Pearlmutter
I've done a prelim (UNRELEASED) packaging of 1.2, see packaging repo fork
https://salsa.debian.org/bap/paprefs

I've enabled CI, so if you go to CI/CD>Pipelines and click on the
"build" job, you should be able to download a built binary amd64
package as one of the "Job artifacts" on the right.



Bug#1009324: GPU (CUDA) Support

2022-04-11 Thread Barak A. Pearlmutter
Package: libsvm-dev
Version: 3.24+ds-6
Severity: wishlist

Any chance of a GPU-enabled version? Appropriate mods to use CUDA are
in https://github.com/prehensilecode/mklabiti-libsvm-cuda although
that might be a bit dated, not sure it's tracked since libsvm 3.0. But
it would be really nice to enjoy the speedups at the bottom of that
README.md, we are running hundreds of jobs that each take a couple
CPU-days, and turning that into GPU-minutes would be amazing.



Bug#812227: Sort of solved

2022-04-10 Thread Barak A. Pearlmutter
You can right click in the left column and there's a menu with one
item: REFRESH.

I don't think it's well placed, a button next to CONNECT would be
better. But it does address this issue...



Bug#1009246: New Upstream Version

2022-04-09 Thread Barak A. Pearlmutter
Package: transmission-remote-gtk
Version: 1.4.1-5
Severity: wishlist

There's a new upstream version available.

I've taken the liberty of doing a prelim updated packaging; it uses
meson, and I patched it to use libayatana-appindicator3-dev, which is
license compatible and the successor to libappindicator.

My packaging is on branch "debian" repo
 https://salsa.debian.org/bap/transmission-remote-gtk.git
which is a clone of your packaging repo.

(Thanks for maintaining transmission-remote-gtk, it is super useful!)



Bug#1008207: Nice Script but Small

2022-03-29 Thread Barak A. Pearlmutter
That's a useful little shell script. But small. Maybe it would make
sense to get it included in /usr/share/doc/openssh-client/examples/?
Or make a package ssh-misc-utils that contains a bunch of scripts for
doing useful little tasks? Basically, to agglomerate it with some
other related things, so as to avoid fragmentation.



Bug#1006680: Stopgap

2022-03-12 Thread Barak A. Pearlmutter
As a stop-gap until this is fixed, you can run this script (as root, obviously).


fix-guake-desktop-link
Description: Binary data


Bug#1004678: git-lfs: allow offline operation

2022-02-20 Thread Barak A. Pearlmutter
I will file an issue upstream. But I don't expect them to care,
because github (the company) probably views this issue as a feature,
not a bug. This issue ties people to a single central repository and
makes migration nearly impossible, at least for non-wizards. Which is
basically their business model: come for the issue tracker and repo
sharing, stay because you have no choice, you can't leave, you can't
even commit without connecting.



Bug#1004678: git-lfs: allow offline operation

2022-01-31 Thread Barak A. Pearlmutter
Package: git-lfs
Version: 3.0.2-1
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

I have a repo whose only remote is on a gitlab instance. I'm using
git-lfs to manage large binary files in this repo. The remote goes down.
Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs,
freezes! Waits forever for the remote when trying to transfer the big
blobs.

This violates what I consider a central concept of git, namely that
operations are local unless you explicitly fetch or push. It means you
cannot work with lfs while offline, like on an aeroplane, or even (as
above) when the gitlab instance is offline for maintenance.

There is also a potential security issue. Users might reasonably assume
they can safely do "git add/commit/rebase" operations locally, with
intermediate steps exposing secret information that is later removed
before doing a push. Nope!

Anyway: I *wish* git-lfs allowed remote operation, like git-annex does.
It seems like it should be technically possible to wait until an
lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge
stub) is actually pushed before transferring the associated big binary
blob. Or at the very least, giving up and remembering to try again later
if there's a big binary blob transfer problem.

-- System Information:
Versions of packages git-lfs depends on:
ii  git1:2.34.1-1
ii  libc6  2.33-5



Bug#1004529: imagemagick-6.q16: convert foo.png foo.eps security violation leaves empty foo.eps

2022-01-29 Thread Barak A. Pearlmutter
Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal

When "convert foo.png foo.eps" gets a security error, it leaves an empty
foo.eps.

/usr/bin/convert should not generate incorrect output files.  If the
output cannot be correctly generated, the output file should be removed.

The current behaviour is a problem when convert is used in a Makefile,
where the first run of "make" generates an error but also an empty
output file, then a second run of "make" treats that empty output file
as correct and continues later stages of the build.

Example:

$ ls -l stroke-signs-1.eps
ls: cannot access 'stroke-signs-1.eps': No such file or directory

$ convert stroke-signs-1.png stroke-signs-1.eps
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `EPS' @ error/constitute.c/IsCoderAuthorized/421.

$ ls -l stroke-signs-1.eps
-rw-rw-r-- 1 barak barak 0 Jan 14 22:36 stroke-signs-1.eps



Bug#1004160: Newer Upstream Version

2022-01-22 Thread Barak A. Pearlmutter
UPDATE!

I've merged and pushed mods for the even-newer just-released upstream
version 3.0, which removes the need for running with privs entirely.



Bug#1004160: New Upstream Version

2022-01-21 Thread Barak A. Pearlmutter
Package: usbview
Version: 2.0-21-g6fe2f4f-2.1

Mark,

There's a new upstream version, 2.2, which addresses those security
CVEs and fixes some other problems, and upstreams a bunch of Debian
mods, and has some other improvements and such.

I've taken the liberty of packaging it, and doing some general
packaging script updating. See https://salsa.debian.org/debian/usbview
branch debian-bap, a repo I took the liberty of creating and
populating with the package's history.

Please feel free to snarf whatever changes I've made you like, or tell
me to sod off, or whatever. Or, I'm happy to co-maintain, or do an
NMU, if you'd like. Just let me know.

Cheers,

--Barak.



Bug#1003749: imagemagick-6.q16: convert foo.png foo.eps security violation leaves empty foo.eps

2022-01-14 Thread Barak A. Pearlmutter
Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal

/usr/bin/convert should not generate incorrect output files.  If the
output cannot be correctly generated, the output file should be removed.

The current behaviour is a problem when convert is used in a Makefile,
where the first run of "make" generates an error but also an empty
output file, then a second run of "make" treats that empty output file
as correct and continues later stages of the build.

Example:

$ ls -l stroke-signs-1.eps
ls: cannot access 'stroke-signs-1.eps': No such file or directory

$ convert stroke-signs-1.png stroke-signs-1.eps
convert-im6.q16: attempt to perform an operation not allowed by the
security policy `EPS' @ error/constitute.c/IsCoderAuthorized/421.

$ ls -l stroke-signs-1.eps
-rw-rw-r-- 1 barak barak 0 Jan 14 22:36 stroke-signs-1.eps



Bug#981464: systemctl --user start fetchmail.service

2021-12-08 Thread Barak A. Pearlmutter
Seems to work!



Bug#1001033: pdf-presenter-console: pdfpc terminates with 'std::bad_alloc'

2021-12-02 Thread Barak A. Pearlmutter
Thanks for the bug report.

I'm unable to replicate this with some other PDF file using version 4.5.0-3.

Could I trouble you to upgrade to the version in testing and see if it
still happens?
And if so, I need details: a particular PDF file it does this on, and
also info about the environment: Gnome with Wayland, or whatever.



Bug#981464: systemctl --user start fetchmail.service

2021-11-27 Thread Barak A. Pearlmutter
Great!

Just for a bit of eye candy, here's what it looks like in use:

$ systemctl --user status fetchmail.service
*●* fetchmail.service - Fetchmail Daemon
 Loaded: loaded (/home/barak/.config/systemd/user/fetchmail.service;
enabled; vendor preset: enabled)
 Active: *active (running)* since Fri 2021-11-19 10:06:05 GMT; 1 week 1
day ago
   Docs: man:fetchmail(1)
   Main PID: 33578 (fetchmail)
  Tasks: 1 (limit: 19040)
 Memory: 3.4M
CPU: 22.160s
 CGroup: /user.slice/user-1000.slice/user@1000.service
/app.slice/fetchmail.service
 └─33578 fetchmail --nodetach --daemon 300

Nov 25 21:54:12 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx
at outlook.office365.com.
Nov 25 21:54:12 tarsk fetchmail[33578]: reading message
barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (3529 header
octets) (2423 body octets) flu>
Nov 26 15:25:25 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx
at outlook.office365.com.
Nov 26 15:25:26 tarsk fetchmail[33578]: reading message
barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4387 header
octets) (61207 body octets) fl>
Nov 26 16:20:30 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx
at outlook.office365.com.
Nov 26 16:20:30 tarsk fetchmail[33578]: reading message
barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (8659 header
octets) (43658 body octets) fl>
Nov 26 17:45:37 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx
at outlook.office365.com.
Nov 26 17:45:37 tarsk fetchmail[33578]: reading message
barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4271 header
octets) (573358 body octets) f>
Nov 27 08:11:41 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx
at outlook.office365.com.
Nov 27 08:11:42 tarsk fetchmail[33578]: reading message
barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (7244 header
octets) (196879 body octets) f>


Bug#981464: systemctl --user start fetchmail.service

2021-11-24 Thread Barak A. Pearlmutter
Agreed: it would probably make sense for these systemd support
materials to go upstream. (Modulo approval, smoothing off rough edges,
etc.)

Let me know if there's anything I should do to help.



Bug#981464: systemctl --user start fetchmail.service

2021-11-23 Thread Barak A. Pearlmutter
I've written a unit so I can run fetchmail under systemd as a user service.
I'd suggest that the file /usr/lib/systemd/user/fetchmail.service (see
below) be included in the package.

It would also make sense to describe how to actually enable it, by
putting something like the following into
/usr/share/doc/fetchmail/README.systemd:



To run fetchmail as a systemd user service, for an individual user:

(1) Configuration

Set up your .fetchmailrc so that "fetchmail --nodetach" actually
fetches your mail correctly.

(2) Tell systemd to run it as a service

Allow daemons to keep running after you log out (optional):
$ sudo loginctl enable-linger $USERNAME

Make the service available:
$ systemctl --user enable fetchmail.service

Actually turn it on:
$ systemctl --user start fetchmail.service

Monitor it, to check if it's okay:
$ systemctl --user status fetchmail.service

Monitor it harder:
$ journalctl --user -xeu fetchmail.service

-

Caveat:

In the below fetchmail.service file, I'm not sure if the "ExecStop="
command is a good idea. If you just leave that line out, systemd will
kill the process using its own mechanisms, which are effective but
perhaps a bit brutal. Might be more robust to just leave it out.

It's currently set to wake up every 5min. Not sure how to make this
default nicely but still be easy to change. Perhaps some systemd
wizard can help?



$ cat /usr/lib/systemd/user/fetchmail.service
[Unit]
Description=Fetchmail Daemon
Documentation=man:fetchmail(1)

[Service]
ExecStart=fetchmail --nodetach --daemon 300
ExecStop=fetchmail --quit
Restart=always

[Install]
WantedBy=default.target



Bug#999944: terminus: depends on obsolete pcre3 library

2021-11-18 Thread Barak A. Pearlmutter
It looks to me like the pcre3 dependency in the terminus package is
entirely due to its use of valac and other build support. There
doesn't appear to be any direct use, except in a build dependency.

If I remove that build dependency, libpcre3-dev is still pulled into
the build environment, due to its being a transitive requirement.

So as a matter of policy, can I just remove the build dependency and
close this bug and relax, even though the actual executable still ends
up linked against libpcre3? Seeing as how that needs to be fixed in
some other package...



Bug#995802: ddccontrol: doesn't reload systemd service from postinst

2021-10-07 Thread Barak A. Pearlmutter
Lovely.

After a quick look through that discussion, it seems that the "right"
thing to do is install into whatever

$ pkg-config systemd --variable=systemdsystemunitdir

gives, and one day that will swizzle but there's no need to worry about it.
And in the meantime, no need to pollute pre/post scripts with reloads.

Barring objections from people more knowledgeable than me, that's what
I'll do to close this bug.



Bug#995802: ddccontrol: doesn't reload systemd service from postinst

2021-10-07 Thread Barak A. Pearlmutter
Thanks for the report, Paul.

Wow, that's annoying! I'd assumed debhelper had some dh_ thing in
its pipeline that automatically noticed .service files being installed
in the relevant places and emitted pre/post code to tickle systemd
appropriately, or that dpkg would trigger on the .service files the
same way it does on .so files, or something automatic like that.

Is a postinst / postrm "systemctl --system daemon-reload" really
appropriate? My read of the documentation is that this would reload
all the daemons, not just the ddccontrol one. But maybe it's more
gentle than I'm giving it credit for?



Bug#969418: Library Package from PPA

2021-09-10 Thread Barak A. Pearlmutter
Looks like this is not necessary?



Bug#993517: RM: mit-scheme [i386] -- ROM; i386 support removed upstream

2021-09-02 Thread Barak A. Pearlmutter
Package: ftp.debian.org
Severity: normal



Upstream no longer supports building for i386. Well, trying to build
on i386 runs out of memory, and upstream no longer releases i386
binaries, so I'm taking that to mean i386 support is kaput.



Bug#978839: confused and unable to reproduce

2021-08-26 Thread Barak A. Pearlmutter
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it, using autoconf 2.71. Could you check if the current
version still exhibits the problem?



Bug#978865: confused and unable to reproduce

2021-08-26 Thread Barak A. Pearlmutter
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it. Could you check if the version I just uploaded still
exhibits the problem?



Bug#992191: deborphan: deborphan --help unterminated last line

2021-08-15 Thread Barak A. Pearlmutter
Package: deborphan
Version: 1.7.33

The last line of "deborphan --help" is not terminated: no final EOL, aka
NL, aka 0x0A, aka C-j.

  $ deborphan --help | tail -1 ; echo '***UNTERMINATED LINE***'
  See also: deborphan(1), orphaner(8)***UNTERMINATED LINE***



Bug#927076: xournalpp packaging in Debian

2021-07-06 Thread Barak A. Pearlmutter
Okay, I used a git snapshot for the version and tarball, and all seems well.



Bug#927076: xournalpp packaging in Debian

2021-07-02 Thread Barak A. Pearlmutter
The reason I'm tracking is because I actually use the generated packages.
But I'm totally unfamiliar with the salsa continuous integration
stuff. Wouldn't mind learning though.

Happy to change workflow, maybe do development on a different branch?

Or, could make snapshot upstream releases 1.0.20+git.DATE.N.ID, or
1.1.0~git.DATE.N.ID, which are based on particular upstream commit IDs
and pushed into pristine-tar.



Bug#927076: xournalpp packaging in Debian

2021-07-02 Thread Barak A. Pearlmutter
Done. I reverted to 1.0.20 but left debian/watch untouched, so uscan
alerts about 1.0.20-hotfix being available.
If that's a problem I can edit the watch file, just let me know; I
kind of enjoy tweaking them, as it happens.

Guess now we wait for the actual 1.1.0 release.



Bug#927076: xournalpp packaging in Debian: how can we help?

2021-07-02 Thread Barak A. Pearlmutter
Sure, can change it to 1.0.20-hotfix-1 or can edit debian/watch to
skip the -hotfix tag and change it to 1.0.20-1. Or use 1.0.20-1 and
let uscan whine about 1.0.20-hotfix.

Given the changes all around, I don't think we want to actually push
into Debian until 1.1.0 is released anyway. So whether the changes are
representable or enormous or whatever doesn't really matter.

What do you think: -hotfix or not -hotfix?

Cheers,

--Barak.



Bug#927076: xournalpp packaging in Debian: how can we help?

2021-06-27 Thread Barak A. Pearlmutter
There is a pristine-tar branch on both salsa and my GitHub fork repo
barak/...


Bug#927076: xournalpp packaging in Debian: how can we help?

2021-06-27 Thread Barak A. Pearlmutter
Sure, always happy for help. Please do!

Would you like to take the package, or co-maintain, team-maintain,
whatever it's called nowadays?
I was using it for teaching, whereas you seem much more involved.



Bug#927076: xournalpp packaging in Debian: how can we help?

2021-06-27 Thread Barak A. Pearlmutter
Yeah, I think right now it's in good shape. I'm waiting for an
official upstream release, at which point I'll upload.
Since it's not in Debian right now, there's no reason to hold off
until after the Debian release. (If there were I'd upload to
Debian/experimental.)

I've been tracking the upstream repo, so I should be able to just hit
the button.

Cheers,

--Barak.



Bug#983483: Candidate Packaging

2021-06-06 Thread Barak A. Pearlmutter
I've updated the packaging for upstream version 2.4.0, and updated the
debian packaging scripts to the latest-and-greatest in the process.
This involved switching the python build system. The build-time
upstream test suite was failing, because it needs to be able to load
the modules in the package. Rather than deal with that so it can find
them at build time, I migrated the test suite into a DEP-8 test form,
which is a two-line debian/tests/control. This would in theory allow
this to migrate into testing despite the freeze.

I've placed this in a fork of the packaging repo,

https://salsa.debian.org/bap/ssh-audit.git

Please feel free to pick any or all of the changes.

Cheers,

--Barak.

PS I'm a DD, so if you'd like me to upload, either as a once-off or
after adding myself as a co-maintainer, I'd be happy to.



Bug#988339: unblock: djvulibre/3.5.28-2

2021-05-10 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package djvulibre

[ Reason ]

Address CVE-2021-3500 and some other potential security issues by
importing Fedora patches.

[ Impact ]

Programs using libdjvulibre to handle .djvu files will remain
vulnerable to crafted input.

[ Tests ]

n/a

[ Risks ]

All but one of these patches have been in Fedora for quite some time.
The last one is currently in Fedora, but recently. All the patches are
very simple: testing and bailing when various error conditions pop up,
like a memory allocation failure or page sizes that cause overflow.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock djvulibre/3.5.28-2



diff -Nru djvulibre-3.5.28/debian/changelog djvulibre-3.5.28/debian/changelog
--- djvulibre-3.5.28/debian/changelog   2020-11-23 13:10:15.0 +
+++ djvulibre-3.5.28/debian/changelog   2021-05-10 18:56:59.0 +0100
@@ -1,3 +1,26 @@
+djvulibre (3.5.28-2) unstable; urgency=high
+
+  * bump policy version
+  * Include Fedora 3.5.27 patches, foward ported, taken from djvulibre.spec in
+https://src.fedoraproject.org/rpms/djvulibre.git
+- Patch0: djvulibre-3.5.22-cdefs.patch(forward ported)
+- #Patch1: djvulibre-3.5.25.3-cflags.patch  (disabled in 
Fedora)
+- Patch2: djvulibre-3.5.27-buffer-overflow.patch(UPSTREAMED)
+- Patch3: djvulibre-3.5.27-infinite-loop.patch  (UPSTREAMED)
+- Patch4: djvulibre-3.5.27-stack-overflow.patch (UPSTREAMED)
+- Patch5: djvulibre-3.5.27-zero-bytes-check.patch   (UPSTREAMED)
+- Patch6: djvulibre-3.5.27-export-file.patch  (forward ported)
+- Patch7: djvulibre-3.5.27-null-dereference.patch   (UPSTREAMED)
+- Patch8: djvulibre-3.5.27-check-image-size.patch (forward ported)
+- Patch9: djvulibre-3.5.27-integer-overflow.patch (forward ported)
+- Patch10: djvulibre-3.5.27-check-input-pool.patch(forward ported)
+- Patch11: djvulibre-3.5.27-djvuport-stack-overflow.patch (forward ported)
+- Patch12: djvulibre-3.5.27-unsigned-short-overflow.patch (forward ported)
+These address a number of crashes and security issues, including
+CVE-2021-3500 (closes: #988215)
+
+ -- Barak A. Pearlmutter   Mon, 10 May 2021 18:56:59 +0100
+
 djvulibre (3.5.28-1) unstable; urgency=medium
 
   [ Leon Bottou ]
diff -Nru djvulibre-3.5.28/debian/control djvulibre-3.5.28/debian/control
--- djvulibre-3.5.28/debian/control 2020-11-23 13:10:15.0 +
+++ djvulibre-3.5.28/debian/control 2021-05-10 18:44:15.0 +0100
@@ -11,7 +11,7 @@
 Vcs-Git: https://salsa.debian.org/debian/djvulibre.git
 Vcs-Browser: https://salsa.debian.org/debian/djvulibre
 Homepage: http://djvu.sourceforge.net/
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 
 Package: libdjvulibre-dev
diff -Nru 
djvulibre-3.5.28/debian/patches/0001-djvulibre-fedora-Patch0-djvulibre-3.5.22-cdefs.patch.patch
 
djvulibre-3.5.28/debian/patches/0001-djvulibre-fedora-Patch0-djvulibre-3.5.22-cdefs.patch.patch
--- 
djvulibre-3.5.28/debian/patches/0001-djvulibre-fedora-Patch0-djvulibre-3.5.22-cdefs.patch.patch
 1970-01-01 01:00:00.0 +0100
+++ 
djvulibre-3.5.28/debian/patches/0001-djvulibre-fedora-Patch0-djvulibre-3.5.22-cdefs.patch.patch
 2021-05-10 18:46:09.0 +0100
@@ -0,0 +1,21 @@
+From: "Barak A. Pearlmutter" 
+Date: Mon, 10 May 2021 15:43:26 +0100
+Subject: djvulibre-fedora Patch0 djvulibre-3.5.22-cdefs.patch
+
+---
+ libdjvu/GSmartPointer.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/libdjvu/GSmartPointer.h b/libdjvu/GSmartPointer.h
+index 8a8bb8a..08540f7 100644
+--- a/libdjvu/GSmartPointer.h
 b/libdjvu/GSmartPointer.h
+@@ -62,6 +62,8 @@
+ # pragma interface
+ #endif
+ 
++#include 
++
+ /** @name GSmartPointer.h
+ 
+ Files #"GSmartPointer.h"# and #"GSmartPointer.cpp"# define a smart-pointer
diff -Nru 
djvulibre-3.5.28/debian/patches/0002-djvulibre-fedora-Patch6-djvulibre-3.5.27-export-file.patch
 
djvulibre-3.5.28/debian/patches/0002-djvulibre-fedora-Patch6-djvulibre-3.5.27-export-file.patch
--- 
djvulibre-3.5.28/debian/patches/0002-djvulibre-fedora-Patch6-djvulibre-3.5.27-export-file.patch
 1970-01-01 01:00:00.0 +0100
+++ 
djvulibre-3.5.28/debian/patches/0002-djvulibre-fedora-Patch6-djvulibre-3.5.27-export-file.patch
 2021-05-10 18:46:09.0 +0100
@@ -0,0 +1,24 @@
+From: "Barak A. Pearlmutter" 
+Date: Mon, 10 May 2021 15:47:32 +0100
+Subject: djvulibre-fedora Patch6 djvulibre-3.5.27-export-file.patch
+
+---
+ desktopfiles/Makefile.am | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/desktopfiles/Makefile.am b

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

2021-05-05 Thread Barak A. Pearlmutter
Yeah, I'm not afraid of the command line, but my 9yo daughter might
prefer the gui.

Anyway, I'll add a list of alternative programs to the documentation
in any case, maybe with a brief discussion of pros/cons. In fact, I'd
welcome putting the information here as pull requests against the
repo! In debian/NOTES.org or something like that.



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

2021-05-05 Thread Barak A. Pearlmutter
Thanks for the pointer. Will take a look.



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

2021-05-03 Thread Barak A. Pearlmutter
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 
X-Debbugs-Cc: debian-de...@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



Bug#987620: Bug

2021-04-29 Thread Barak A. Pearlmutter
>> I'd be happy to sponsor it.

> I would very much appreciate that

Okay then!

(CCing the WPNN bug, for posterity, and so others can see this is taken.)

Took a quick look, and did a major updating of the debian/ packaging scripts.

There were issues with passing flags through to the actual compiler,
so I did some Rube Goldberg tricks to bypass the top-level Makefile
and let debhelper do its tricks with qmake.
Ultimately, the "right thing" would be to mess about with the
"upstream" build scripts to make them more standard, like have the
qmake stuff do the installation, have only one qmake invocation, yada
yada.

Anyway, I forked your github repo and pushed my changes there. Please
check if it works with my scripts. If you're happy with everything, I
can just upload it. Or if you'd rather, I can be more hands-off and
sponsor someone else's uploads (e.g., yours) and let you do all the
packaging stuff w/ my feedback etc. However as a PI myself, I know
what I'd choose!

Minor stuff:

Not sure if it belongs in "science" because that's generally for
things like data analysis software, numeric methods, machine learning
libraries, etc.
But what the heck. That gives it an automatic team maintenance, which is nice.
And it can always be shifted.

There are some compiler warnings, like using an old sort function
instead of the new approved one. Someone should probably take a look
at them sometime.

I'm renamed the icon to just eln, since the longer one seems a bit
silly: what if (no offense) you're hit by a bus?

Cheers,

--Barak.



Bug#987556: unblock: stopmotion/0.8.5-3

2021-04-25 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package stopmotion

[ Reason ]

Change '%s' to %s in stopmotion.mime

[ Impact ]

Minor security issue.

[ Tests ]

n/a

[ Risks ]

Leaf package. Changing '%s' to %s is the only substantive change.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock stopmotion/0.8.5-3



$ git diff debian/0.8.5-2..debian/0.8.5-3
diff --git a/debian/changelog b/debian/changelog
index af0fe4a..ecfbbd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+stopmotion (0.8.5-3) unstable; urgency=medium
+
+  * bump policy, no changes required
+  * bump to debhelper 13
+  * Fix day-of-week for changelog entry 0.pre3.4-1
+  * Add pithy comment to debian/watch
+  * stop quoting %s in mimecap entry (closes: #987415)
+
+ -- Barak A. Pearlmutter   Fri, 23 Apr 2021 20:56:40 +0100
+
 stopmotion (0.8.5-2) unstable; urgency=medium
 
   * hack around integer size mismatch to std::min() on 32-bit systems
@@ -466,7 +476,7 @@ stopmotion (0.pre3.4-1) unstable; urgency=low
 
   * Fixed a bug when removing scenes
 
- -- Bjoern Erik Nilsen   Tue, 25 Apr 2005 17:12:36 +0200
+ -- Bjoern Erik Nilsen   Mon, 25 Apr 2005 17:12:36 +0200
 
 stopmotion (0.pre3.3-1) unstable; urgency=low
 
diff --git a/debian/stopmotion.mime b/debian/stopmotion.mime
index 483de5a..dcba5d0 100644
--- a/debian/stopmotion.mime
+++ b/debian/stopmotion.mime
@@ -1 +1 @@
-application/x-stopmotion;  /usr/bin/stopmotion  -caption "Animation Creator" 
'%s';   nametemplate='%s.sto'; test=test "$DISPLAY" != ""; priority=9
+application/x-stopmotion;  /usr/bin/stopmotion  -caption "Animation Creator" 
%s;   nametemplate=%s.sto; test=test "$DISPLAY" != ""; priority=9
diff --git a/debian/control b/debian/control
index 3cc21c7..2c4a90c 100644
--- a/debian/control
+++ b/debian/control
@@ -4,14 +4,14 @@ Priority: optional
 Maintainer: Barak A. Pearlmutter 
 Uploaders: Mahyuddin Susanto ,
   Bjoern Erik Nilsen 
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
pkg-config,
qtbase5-dev, qttools5-dev-tools,
qtmultimedia5-dev,
libtar-dev,
libvorbis-dev,
libxml2-dev
-Standards-Version: 4.4.1
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Homepage: http://linuxstopmotion.sourceforge.net
 Vcs-Git: https://salsa.debian.org/debian/stopmotion.git
diff --git a/debian/watch b/debian/watch
index 1b239b9..0b05a3b 100644
--- a/debian/watch
+++ b/debian/watch
@@ -2,3 +2,7 @@ version=4
 opts="mode=git, pgpmode=none" \
  https://git.code.sf.net/p/linuxstopmotion/code \
  refs/tags/v?([\d\.]+) debian uupdate
+
+## Would use
+##   refs/tags/v?@ANY_VERSION@
+## but that matches things like 0.8.6-RC1.



Bug#987373: mit-scheme: leaves alternatives after upgrade from buster: /usr/bin/scheme -> /etc/alternatives/scheme -> /usr/bin/mit-scheme-x86-64

2021-04-22 Thread Barak A. Pearlmutter
Thanks for the bug report.

That is odd: I thought I had the appropriate calls to
update-alternatives --install / --remove in mit-scheme.postinst/prerm.
Any idea what's going wrong? It looks like I'm doing the recommended
thing, in the bog-standard way. But I must be missing something...

Cheers,

--Barak.



Bug#987077: unblock: ensmallen/2.16.2-1

2021-04-17 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock (or manually allow transition of) package ensmallen

[ Reason ]

The previous version was 20+ days old.
The only delta here is adding autopkgtest support, which passes fine.
Which suggests that this might reasonably be treated as 20+ days old
with autopkgtest support.

[ Impact ]

The version currently in testing has subtle numeric bugs, which seem
more likely to manifest on unusual architectures. Since this is
numeric software, bugs can silently yield incorrect numeric results.

[ Tests ]

The autopkgtest test suite is rather comprehensive.

[ Risks ]

Although in -dev, this is a near-leaf package: only mlpack uses it,
and I don't think mlpack will make it into the release. So, no
particular risks.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock ensmallen/2.16.2-1



diff -Nru ensmallen-2.16.2/debian/changelog ensmallen-2.16.2/debian/changelog
--- ensmallen-2.16.2/debian/changelog   2021-03-25 21:55:13.0 +
+++ ensmallen-2.16.2/debian/changelog   2021-04-16 16:49:42.0 +0100
@@ -1,3 +1,9 @@
+ensmallen (2.16.2-2) unstable; urgency=medium
+
+  * add autopkgtest support
+
+ -- Barak A. Pearlmutter   Fri, 16 Apr 2021 16:49:42 +0100
+
 ensmallen (2.16.2-1) unstable; urgency=medium
 
   * New upstream version, WILL fix broken test (closes: #984868)
diff -Nru ensmallen-2.16.2/debian/patches/0001-include-path.patch 
ensmallen-2.16.2/debian/patches/0001-include-path.patch
--- ensmallen-2.16.2/debian/patches/0001-include-path.patch 1970-01-01 
01:00:00.0 +0100
+++ ensmallen-2.16.2/debian/patches/0001-include-path.patch 2021-04-16 
16:49:42.0 +0100
@@ -0,0 +1,24 @@
+From: "Barak A. Pearlmutter" 
+Date: Fri, 16 Apr 2021 15:54:22 +0100
+Subject: include path
+
+The C++ test files must #include  rather than
+"../include/ensmallen.hpp" in order to allow the installed files,
+rather than the repo-local files, to be tested.
+---
+ tests/de_test.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/de_test.cpp b/tests/de_test.cpp
+index a4bb246..c116c69 100644
+--- a/tests/de_test.cpp
 b/tests/de_test.cpp
+@@ -8,7 +8,7 @@
+  * http://www.opensource.org/licenses/BSD-3-Clause for more information.
+  */
+ 
+-#include "../include/ensmallen.hpp"
++#include 
+ #include "catch.hpp"
+ #include "test_function_tools.hpp"
+ 
diff -Nru ensmallen-2.16.2/debian/patches/series 
ensmallen-2.16.2/debian/patches/series
--- ensmallen-2.16.2/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ ensmallen-2.16.2/debian/patches/series  2021-04-16 16:49:42.0 
+0100
@@ -0,0 +1 @@
+0001-include-path.patch
diff -Nru ensmallen-2.16.2/debian/rules ensmallen-2.16.2/debian/rules
--- ensmallen-2.16.2/debian/rules   2021-03-04 10:05:57.0 +
+++ ensmallen-2.16.2/debian/rules   2021-04-16 11:35:59.0 +0100
@@ -7,9 +7,13 @@
 %:
dh $@
 
+# Number of times to run test suite.
+# (There was a heisenbug, and this was used to help track it down.)
+n_test = 1
+
 override_dh_auto_test:
ok=true; \
-   for i in $$(seq 3); do \
+   for i in $$(seq $(n_test)); do \
  echo "Test Run $$i"; \
  if env CTEST_OUTPUT_ON_FAILURE=1 dh_auto_test; \
  then \
diff -Nru ensmallen-2.16.2/debian/tests/control 
ensmallen-2.16.2/debian/tests/control
--- ensmallen-2.16.2/debian/tests/control   1970-01-01 01:00:00.0 
+0100
+++ ensmallen-2.16.2/debian/tests/control   2021-04-16 16:49:42.0 
+0100
@@ -0,0 +1,3 @@
+Tests: test-script
+Depends: @, g++ | clang | c++-compiler, libarmadillo-dev
+Restrictions: allow-stderr
diff -Nru ensmallen-2.16.2/debian/tests/test-script 
ensmallen-2.16.2/debian/tests/test-script
--- ensmallen-2.16.2/debian/tests/test-script   1970-01-01 01:00:00.0 
+0100
+++ ensmallen-2.16.2/debian/tests/test-script   2021-04-16 16:49:42.0 
+0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+set -x
+# Choose location for test executable
+e=$(mktemp --tmpdir=${AUTOPKGTEST_TMP} ensmallen-test-XX)
+# Build outside tests to reduce possibility of getting build rather
+# than installed ensmallen files via #include.
+c++ -O0 -o ${e} tests/*.cpp -lpthread -larmadillo
+# cd tests because the executable reads data/* files.
+cd tests && ${e} --durations yes



Bug#985721: unblock: fossil/1:2.15~rc1-1

2021-04-07 Thread Barak A. Pearlmutter
Holy mother of complexity! They don't make autopkgtest easy to
understand, do they? And no virtual driver for pbuilder/cowdancer,
just to put an extra nail in my wrist (if I may use a seasonal
metaphor.)

Anyway, I believe the upload I've just pushed has correct autopkgtest
support, explicitly testing the installed binary /usr/bin/fossil. If
this passes muster, please unblock! And if not, I'd very much
appreciate hints as to how I could improve it.

Cheers,

--Barak.



Bug#986169: unblock: docx2txt/1.4-5

2021-03-30 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package docx2txt

[ Reason ]

Address security issue: do not quote %s in mailcap entry.
See: https://bugs.debian.org/985594

[ Impact ]

Potential security issue with crafted filename.

[ Tests ]

n/a

[ Risks ]

- Code is trivial.
- Leaf package.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

It's a two-character change.

unblock docx2txt/1.4-5

diff -Nru docx2txt-1.4/debian/changelog docx2txt-1.4/debian/changelog
--- docx2txt-1.4/debian/changelog   2020-12-11 21:56:27.0 +
+++ docx2txt-1.4/debian/changelog   2021-03-20 17:13:44.0 +
@@ -1,3 +1,9 @@
+docx2txt (1.4-5) unstable; urgency=medium
+
+  * Address security issue: do not quote %s in mailcap entry (closes: #985594)
+
+ -- Barak A. Pearlmutter   Sat, 20 Mar 2021 17:13:44 +
+
 docx2txt (1.4-4) unstable; urgency=medium
 
   * debian/rules does not require root
diff -Nru docx2txt-1.4/debian/docx2txt.mime docx2txt-1.4/debian/docx2txt.mime
--- docx2txt-1.4/debian/docx2txt.mime   2020-12-11 21:55:16.0 +
+++ docx2txt-1.4/debian/docx2txt.mime   2021-03-20 17:12:47.0 +
@@ -1 +1 @@
-application/vnd.openxmlformats-officedocument.wordprocessingml.document; 
docx2txt '%s' - ; copiousoutput; description=Office Open XML Document
+application/vnd.openxmlformats-officedocument.wordprocessingml.document; 
docx2txt %s - ; copiousoutput; description=Office Open XML Document



Bug#985721: unblock: fossil/1:2.15~rc1-1

2021-03-27 Thread Barak A. Pearlmutter
> if the source has such an extensive test suite, doesn't that (at
least partially) qualify for autopkgtesting? Remember that packages that
have substantial testing with autopkgtest *of the installed binaries*
currently don't need to request unblocks if their not a key package.

I think so, yes. It currently tests the built executable during the
build. I'll see about getting autopkgtest set up for it; shouldn't be
too hard.



Bug#985721: unblock: fossil/1:2.15~rc1-1

2021-03-27 Thread Barak A. Pearlmutter
I was preparing one, but upstream released an official 2.15 release.
Which has an exhaustive test suite enabled in the build and passes (by
upstream standards; there are scary messages but they're expected) on
all architectures.

The delta is too big to sensibly check. But it's a proper release with
upstream blessing etc. If I were release manager I'd wait for people
to test it for a couple weeks, then (assuming all is okay) let it in.
Your call though.

Cheers,

--Barak.



Bug#985721: unblock: fossil/1:2.15~rc1-1

2021-03-22 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package fossil

[ Reason ]

Marked for autoremoval due to #985124.

The issue was fixed upstream. Given the nature of the package, I think
tracking their release candidate is better than cherry-picking the
change that appears directly related to this issue. They made a number
of other safety-related fixes to ensure robustness and security in the
face of old or compiled-with-wrong-options versions of SQLITE3. And
nothing that looks scary.

[ Impact ]

Will allow fossil to be in the release.

[ Tests ]

There is a comprehensive test suite, which can be run automatically.
It is disabled in debian/rules because the makefile says it needs to
be run in a fossil repo that will be discarded after the test because
the tests can corrupt it. Well, it used to say this: the comment is
gone, so maybe it's okay now. But in any case, the system passes all
tests right now.

[ Risks ]

This is a leaf package.

It ticks various boxes for security sensitivity, sort of the union of
the security sensitivity of git and a web server and a wiki. Upstream
is extremely responsive and careful. I think the best option is to
follow upstream's recommendation, which is to track their releases.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

I'm attaching the debdiff, but it's large. Due mainly to changes in
the enclosed sqlite3 (unused unless the debian version is too old or
otherwise unsuitable), and tweaks to static material in the integrated
wiki.

unblock fossil/1:2.15~rc2-1
<#part type="application/octet-stream" filename="~/tmp/ddiff2" 
disposition=attachment>
<#/part>



Bug#985628: unblock: docx2txt/1.4-5

2021-03-20 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package docx2txt

[ Reason ]

Fix mime security issue: '%s'

[ Impact ]

Potential vulnerability, or package unavailable if #985594 causes its removal.

[ Tests ]

none

[ Risks ]

change is trivial

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock docx2txt/1.4-5

$ debdiff
diff -Nru docx2txt-1.4/debian/changelog docx2txt-1.4/debian/changelog
--- docx2txt-1.4/debian/changelog   2020-12-11 21:56:27.0 +
+++ docx2txt-1.4/debian/changelog   2021-03-20 17:13:44.0 +
@@ -1,3 +1,9 @@
+docx2txt (1.4-5) unstable; urgency=medium
+
+  * Address security issue: do not quote %s in mailcap entry (closes: #985594)
+
+ -- Barak A. Pearlmutter   Sat, 20 Mar 2021 17:13:44 +
+
 docx2txt (1.4-4) unstable; urgency=medium
 
   * debian/rules does not require root
diff -Nru docx2txt-1.4/debian/docx2txt.mime docx2txt-1.4/debian/docx2txt.mime
--- docx2txt-1.4/debian/docx2txt.mime   2020-12-11 21:55:16.0 +
+++ docx2txt-1.4/debian/docx2txt.mime   2021-03-20 17:12:47.0 +
@@ -1 +1 @@
-application/vnd.openxmlformats-officedocument.wordprocessingml.document; 
docx2txt '%s' - ; copiousoutput; description=Office Open XML Document
+application/vnd.openxmlformats-officedocument.wordprocessingml.document; 
docx2txt %s - ; copiousoutput; description=Office Open XML Document



Bug#985124: Acknowledgement (fossil: fails to update schema for older repositories)

2021-03-17 Thread Barak A. Pearlmutter
Thanks for the report & digging out the relevant patch.

I uploaded the upstream 2.1.15~rc1 version, which includes this patch
and addresses a couple other issues as well.



Bug#982791: mit-scheme FTBFS on i386: out of memory

2021-02-14 Thread Barak A. Pearlmutter
Thanks for the report. I've been looking at the issue already.

Adding a new arch requires a bit of work, because there's a circular
build dependency so you have to build manually. And I don't have an
arm64 to hand, so I'll have to use a porter machine. Will get around
to it.

I doubt the i386 "out of memory" is from hitting the hard
architectural limit, I think the default limits are just too low on
i386. There are options that can be passed to increase the heap size,
but the build system and documentation are sufficiently convoluted to
make figuring out what they are and how to get them passed through
isn't easy.

If anyone who uses this in anger on an i386, or wants to use it on an
arm64, would like to lend a hand, all assistance would be welcome!

Meantime I'll probably just make it amd64-only for the next upload,
with a wishlist bug to get other supported architectures working.



Bug#981519: linuxlogo: Upstream Version 6.0 Available

2021-01-31 Thread Barak A. Pearlmutter
Package: linuxlogo
Version: 5.11-9+b1
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Thanks for maintaining linuxlogo; fun little package, and I think it's
super important to keep the fun in computing.

Anyway, upstream version 6.0 is available.

I took the liberty of creating

 https://salsa.debian.org/debian/linuxlogo

and pushing the last snapshot I could find of the now-defunct anonscm
linuxlogo repo there, plus a uscan/import of the upstream 6.0 release.

Then I forked it to

 https://salsa.debian.org/bap/linuxlogo

and pushed packaging updates for a draft 6.0-1.

Unless there are objections or activity or negative feedback (especially
about the above version, if anyone wants to take a look at it, which I'd
very much appreciate), I'll do an NMU of the above as 6.0-0.1 soon-ish,
since the freeze is looming and the current version gets the RAM wrong.

Or, of course, feel free to take as much or little of my updates as you
wish as a basis for an updated package.

Cheers,

--Barak.



Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed

2021-01-25 Thread Barak A. Pearlmutter
> In principle, it's possible to use URL instead of a local file in
> \movie, e.g.,
> .

That's an idea. Maybe as an option, guarded by latex \if tricks,
enabled by default.

> > Of course, they need pdfpc.sty in texlive-latex-extra.
>
> Actually, the demos currently do not need it.

Ah, right. Good point!



Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed

2021-01-25 Thread Barak A. Pearlmutter
Thanks for the report.

I think there are really two issues here.

(a) the demo/ source directory is not included in the package

(b) you're having trouble LaTeXing the demos

Issue (a) is absolutely not ideal. I'm considering including them in
/usr/share/doc/pdf-presenter-console/examples/ but fiddling around to
have the Makefile just invoke latexmk, and adding a latexmkrc, and not
including the video files instead having the Makefile download them.
Including the video files seems like overkill. Of course, they need
pdfpc.sty in texlive-latex-extra. Maybe the package should Suggest:
them? That seems like overkill. Maybe this stuff should be in a
separate -doc or -demo package? That seems a bit silly. I suppose
adding a check to the Makefile that issues a warning if those packages
are not installed might be the best compromise.

Which brings us to (b). Both the demos work fine for me (using plain
old "latexmk --pdf"). Under debian testing. Do you have
texlive-latex-extra installed? If so, please install latexmk and send
a full transcript of

$ cd demo
$ latexmk --pdf -gg pdfpc-demo.tex
$ cd pdfpc-video-example
$ latexmk --pdf -gg video-example.tex

and I'll see if I can diagnose the problem.



Bug#957317: gtkboard: diff for NMU version 0.11pre0+cvs.2003.11.02-10.1

2021-01-22 Thread Barak A. Pearlmutter
Thank you! I'll merge your fix and do a non-NMU when I get a chance.

For future ref, no need to delay or even NMU. I don't mind my packages
getting a little TLC.


Bug#980800: djview: No longer accepts a local DjVu document URL

2021-01-22 Thread Barak A. Pearlmutter
Thanks for your report.

I'm reducing the severity to "normal" because it meets the criteria
for that level.
But be assured that I understand it's important to *you* and your
workflow and applications, and I will try to get it fixed asap.

Cheers,

--Barak.



Bug#980790: gnome-software: emphasize portion of version actually changing

2021-01-22 Thread Barak A. Pearlmutter
Package: gnome-software
Version: 3.38.0-3
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Dear Maintainer,

In the window listing packages and their versions, there are lines like

   foo   1.2.3.4.5-3.4 -> 1.2.3.4.6-2

I'd suggest finding the common prefix of these two strings, and
emphasizing the part after that common prefix, by boldface & using a
bright color. Here is what I'm talking about, shown by underlining:

   foo   1.2.3.4.5-3.4 -> 1.2.3.4.6-2
 ====



Bug#976892: autoconf 2.70

2021-01-02 Thread Barak A. Pearlmutter
Other bugs, in other packages, pretty much.
I'm not spun up enough on autoconf to help.

autoconf 2.70 *is* in experimental, and autobuilders are building
packages with it and reporting bugs. Seems like a very reasonable path
to me.



Bug#976892: autoconf 2.70

2020-12-25 Thread Barak A. Pearlmutter
Getting autoconf 2.70 into Debian would be nice, and your willingness
to help is great. You might want to have a look at

https://bugs.debian.org/977331

which is the ITA bug for autoconf, and discusses both finding a new
maintainer (Matthias Klose  looks to be considering
taking it on, but I imagine he'd welcome assistance; such a critical
package as autoconf really should have a maintenance team) and what
getting 2.70 into usage would require. It seems the plan is to
generate a draft package 2.70 and then rebuild everything with it, to
see how much breaks and how, and use that information to help decide
on a concrete plan.

They seem pessimistic about getting it in as the default in bullseye,
which seems like a shame.

--Barak.



Bug#977546: duplicity: remove-all-but-n-full includes failed backups

2020-12-16 Thread Barak A. Pearlmutter
Package: duplicity
Version: 0.8.17-1+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter 

I ran out of storage on my remote, so I tried to reclaim some with

$ duplicity remove-all-but-n-full 1 --force "${transport}/${target}"

But afterwards there are just a few meg used in the target directory
instead of many hundreds of gig. It would appear that a full backup
failed due to space exhaustion on the remote, but that the failed full
backup is (inappropriately) included in remove-all-but-n-full's count.

This is just my best guess as to what's going on. But I am 100% sure
that "duplicity remove-all-but-n-full 1" sometimes does not leave an
intact full backup, instead it deletes nearly everything.

This has happened to me repeatedly, so I'm sure there's an actual
problem.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (490, 'testing'), (450, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages duplicity depends on:
ii  gnupg  2.2.20-1
ii  libc6  2.31-5
ii  librsync2  2.3.1-1
ii  python33.9.0-4
ii  python3-fasteners  0.14.1-2
ii  python3-future 0.18.2-4
ii  python3-lockfile   1:0.12.2-2.2

Versions of packages duplicity recommends:
pn  python3-oauthlib  
ii  python3-paramiko  2.7.2-1
ii  python3-pexpect   4.6.0-4
ii  python3-urllib3   1.25.11-1
ii  rsync 3.2.3-2

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
pn  python3-boto 
ii  python3-pip  20.1.1-2
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information



Bug#976540: clippoly: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

2020-12-15 Thread Barak A. Pearlmutter
The latest upload fails test on more architectures, making me suspect
that fancy new compiler tech may be involved. Chained floating point
operations keeping guard digits inappropriately or something like
that, perhaps.

In all bad cases, test0 passes, and both test1 and test2 fail, both with:

clippolytest: graphadd.cc:149: void recursive_intersection(const
hvec2_t&, const hvec2_t&, const hvec2_t&, const hvec2_t&, hvec2_t&):
Assertion `inp_ort(q,s1) <= 0' failed.

This is the same assertion that failed on a single platform (Longsoon)
years ago, reported in 762669, so I'm tempted to merge the reports.

Not sure what the next step should be. This may require attention from
someone who understands the bit-level float hackery being used, which
is pretty specialised stuff.



Bug#976540: ARM64 Float Point Woes

2020-12-15 Thread Barak A. Pearlmutter
This is a really strange error. Nothing relevant has changed in the
package proper.

At first I thought it might be a race condition on the three tests,
but I can't find any.

My suspicion at this point is that it's an error in the floating point
support on the ARM64 platform. On the one hand, that does seem ...
shocking? On the other hand, clippoly exercises the obscure properties
of IEEE FP, and sometimes that stuff is emulated, and there was a
similar issue before.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762669 which is
a test failure on mips64el, where James Cowgill commented:

> I think this must be a bug in the Loongson FPU (my guess since the
> assertion is related to floating point math). It builds successfully on
> all the non-loongson boards I've tried.

I've uploaded a new release with no actual code changes, let's see what happens.



Bug#960788: Intel SOF audio firmware packaging

2020-12-10 Thread Barak A. Pearlmutter
Pavucontrol is talking to pulseaudio, it doesn't talk to the alsa
device directly.
But the problem is at the alsa level, or at the interface where
pulseaudio talks to alsa.
Someone should probably report it to the pulseaudio folks.



Bug#960788: Intel SOF audio firmware packaging

2020-12-10 Thread Barak A. Pearlmutter
Not sure if this will work for you, but it does for me.
Basically, the device initializes into a muted state, so you need to
unmute it pretty forcibly.

Here are my notes showing various ways to accomplish this.
This is with my device numbering, yours might be different.
You can just run "alsamixer" with no arguments to see all the alsa
audio devices, and see if one is muted, and if so unmute it, and if
not mute/unmute it just to be sure.

---

Unmute device:

$ alsamixer -c 0

- switch to "Master" device
- press "m" to unmute it so that you see "00" instead of "MM" under
- up arrow key to increase the volume to 100%

Store setting across boot:

$ sudo alsactl store

Alt to unmute device:

$ amixer -Dhw:0 cset name='Master Playback Switch' on
$ amixer -Dhw:0 cset name='Master Playback Volume' 100%



Bug#960788: Intel SOF audio firmware packaging

2020-12-10 Thread Barak A. Pearlmutter
Oops! Thanks, fixed.
(I switched binary package names to match the packaging on salsa in
debian/control but neglected to make the consonant change in
debian/rules. I suppose debian/rules should grovel it out of
debian/control, according to the DRY principle. May do that, but
pushed trivial fix for now.)



Bug#960788: Intel SOF audio firmware packaging

2020-12-09 Thread Barak A. Pearlmutter
No need for anything so complex. This should work:

$ fakeroot debian/rules binary

Or sudo if you don't have fakeroot.



Bug#960788: Intel SOF audio firmware packaging

2020-12-09 Thread 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.



Bug#976136: size stats

2020-12-04 Thread Barak A. Pearlmutter
Sure! It was the minorest of wishes. More of a rueful comment on how
claims of small size don't tend to age well in computing. This one's
aged better than most, I suppose...



Bug#976136: size stats

2020-11-30 Thread Barak A. Pearlmutter
Package: yabasic
Version: 1:2.87.1-1
Severity: wishlist

$ apt show yabasic|egrep -i size
Installed-Size: 947 kB
Download-Size: 263 kB

$ apt show yabasic|egrep '[0-9]+ *KB'
 it is small (less than 200 KB) and free.

$ cat < /usr/bin/yabasic | wc -c
297192

$ cat < /usr/share/doc/yabasic/yabasic.htm | wc -c
548346

$ gzip -9 < /usr/share/doc/yabasic/yabasic.htm | wc -c
100934

$ xz < /usr/share/doc/yabasic/yabasic.htm | wc -c
77868



Bug#972813: xournal FTBFS: wrongly declared R³

2020-11-16 Thread Barak A. Pearlmutter
"Rules-Requires-Root?"
"No"
"You Worm. You Scum. You Lowly User. REJECTED!!! Upper Case Is
Reserved For Your Betters. Do You Think You Are My Equal?"
"no."
"What Was That? Did You Just Use Punctuation? Do You Deserve To Use
Punctuation?"
"nope"
"What!?!? You Need Discipline. A GNU Kind Of Discipline! Now Rewrite
This Package In Gnat Ada. Using Ed(1)."



Bug#972813: xournal FTBFS: wrongly declared R³

2020-11-16 Thread Barak A. Pearlmutter
"Rules-Requires-Root?"
"No"
"You Worm. You Scum. You Lowly User. REJECTED!!! Upper Case Is
Reserved For Your Betters. Do You Think You Are My Equal?"
"no."
"What Was That? Did You Just Use Punctuation? Do You Deserve To Use
Punctuation?"
"no"
"That's Better. Now I'm Sending You For A Session With The Multi-Arch
Hinter. I Expect You To Be On Your Best Behavior."

Seriously, requiring each word in the control key to be capitalized
but the subsequent value to be lower case does seem just a teenly
little bit counterintuitive.

Just saying.

--Barak.

"Be conservative in what you send, be liberal in what you accept."
---Postel's law



Bug#970227: Debugging vs Optimization

2020-11-04 Thread Barak A. Pearlmutter
Thanks for noticing that unfortunate interaction.

These should ideally be largely orthogonal, of course.
I'll check w/ upstream and see what the right thing is.
Maybe they can add a half-hearted-debugging option, which enables
debugging stuff that won't interfere with optimization or performance.

Cheers.

--Barak.



Bug#972429: djview4: djview4 as a server

2020-11-03 Thread Barak A. Pearlmutter
Sure. I could package it, but I'm not a browser expert, so if there is
one who could take primary responsibility that would make sense. If
they're not a debian developer I could sponsor the package in, etc.



Bug#845980: Poor Little Orphan Package

2020-10-28 Thread Barak A. Pearlmutter
Given the time span, I think Kyle Spiers' generous offer has probably
lapsed. (If not let me know and you can have it!) So in the interests
of efficiency, I'll just adopt it. Did a quick packaging of the latest
upstream, pushed to salsa, and will upload w/ self as maintainer in a
moment.

If someone else wants it, please feel free to co-maintain, or do 0-NMU
uploads without even asking, or whatever.

--Barak Pearlmutter.



Bug#972429: djview4: djview4 as a server

2020-10-25 Thread Barak A. Pearlmutter
That's great. If the extension is in Debian, than djview4 could
"Suggest:" it. Or maybe would could just put appropriate instructions
in /usr/share/doc/djview4/README.Debian, if you have wording for such
a paragraph I'm happy to slip it in.

Cheers,

--Barak.



Bug#956272: xournalpp

2020-10-24 Thread Barak A. Pearlmutter
Absolutely. I made a tentative packaging, at
https://salsa.debian.org/debian/xournalpp

Builds and works fine. I use it daily, for teaching remotely. Would
welcome testers.

The only reason I have not actually pushed it into Debian is that the
debian/copyright file is a bit of a mess. Some of the .svg files in
particular have embedded copyright strings with CC of various
flavours, and nobody's had the time or enthusiasm to dive in and check
all the copyrights and record them in debian/copyright, and if any
problematic .svg files are found to replace them with free
replacements from one of the collections of actually free artistic SVG
files.



Bug#972813: xournal FTBFS: wrongly declared R³

2020-10-24 Thread Barak A. Pearlmutter
ack



Bug#927076: any progress?

2020-10-20 Thread Barak A. Pearlmutter
Right, I made that salsa repo, it doesn't mean anything except having
a place to hang a hat.

The situation now is that the *only* sticking point is
debian/copyright, which is a mess. Note all the "god knows" entries.
And the providence of a bunch of the .svg files is unclear, with
internal copyright strings embedded in them giving various flavours of
CC. Some of which might need to be replaced if they're the wrong
flavours; fortunately there are collections of appropriate open source
.svg icons that could be used instead if it comes to that.

If someone were to help with getting the copyright info worked out, I
can slot it straight into Debian. But there were so many little moving
parts I just couldn't clear an entire day to try and figure it all
out. Someone more familiar with the code base and its history would
probably have a much easier time of it.

--Barak.

PS I'm using xournalpp in teaching this semester. Got a new Dell
Inspiron 15 7591 2in1 with a pressure sensitive pen enabled screen,
and it's great for remote teaching.



Bug#972429: djview4: djview4 as a server

2020-10-18 Thread Barak A. Pearlmutter
Good idea.

There's a way to get some URLs sent to external programs, like magnet:
links to transmission, or some files to evince. In Firefox it's
Settings > General > Applications. Should be able to key off mime
types I think, although I don't see djvu files there.



Bug#972097: Fwd: [conrads...@gmail.com: mlpack stuck in debian unstable]

2020-10-12 Thread Barak A. Pearlmutter
Package: mlpack
Version: 3.4.1-1

I'm forwarding this to the Debian bug tracking system, it will be
allocated a number which we should CC on further correspondence about
the issue. For posterity etc.

-- Forwarded message -
From: Ryan Curtin 
Date: Mon, 12 Oct 2020 at 16:19
Subject: Re: [conrads...@gmail.com: mlpack stuck in debian unstable]
To: Barak A. Pearlmutter 
Cc: 


On Mon, Oct 12, 2020 at 04:01:21PM +0100, Barak A. Pearlmutter wrote:
> The big issue is compilation issues on various architectures, rather
> than the Julia bindings.
> Have a look,
>
> - https://tracker.debian.org/pkg/mlpack
> - https://buildd.debian.org/status/package.php?p=mlpack
>
> Help welcome, absolutely!

Awesome, thanks for the links.  I can try 'debugging-from-afar' for some
of these.  Please do feel free to open bugs in the mlpack repository for
this, just like the ensmallen repository.  I actually had no idea there
were problems here.

Anyway, quick hits:

 - armel: maybe add `-latomic` to CMAKE_EXE_LINKER_FLAGS?  e.g. add this
   to the CMake configuration command:
   "-DCMAKE_EXE_LINKER_FLAGS='-latomic'"

 - mips64el: related to this bug?
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965247
   You could also disable LTO by adding -fno-lto to CMAKE_CXX_FLAGS
   or CMAKE_LINKER_FLAGS.  I'm not sure if that will fix it.

 - mipsel: "LLVM ERROR: out of memory"; is there anything we can do
   here?  `make -j1`, maybe remove '-pipe' from CMAKE_CXX_FLAGS (if
   it's set) and set --param ggc-min-heapsize=32768 --param
   ggc-min-expand=1?  That's what I do for underpowered arm7hl
   builders on Fedora.

 - alpha: ".got subsegment exceeds 64K".  I have no idea what could be
   wrong here.  Can we just disable alpha?  There's very little
   information I can find on this one, other than a suggestion
   somewhere that the linker table sizes need to be increased, plus
   what look like a bunch of debian packages where they disabled
   alpha because of this exact issue.

 - m68k: is the version of Doxygen here different?  A workaround could
   be to regex `WARN_AS_ERROR[ ]*= YES` to `WARN_AS_ERROR = NO` in
   `Doxyfile` before the build starts.

I'm not sure about the dependency installability problems, but in the
worst case, those are all related to Python, so you could for those
architectures just disable the Python bindings.

> Meantime I'll turn off the Julia bindings.

My experience with Debian-packaged Julia actually hasn't been great, but
perhaps it's improved over time.  I think once Julia is available in
stable, perhaps the situation will be better?

--
Ryan Curtin| "Get off my lawn!"
r...@ratml.org |   - Kowalski



Bug#962733: Packaged

2020-09-04 Thread Barak A. Pearlmutter
Okay, will do!



Bug#962733: Packaged

2020-09-04 Thread Barak A. Pearlmutter
I've packaged and been using v1.2, please see

https://salsa.debian.org/bap/lieer.git

which has a bunch of packaging updates, including a transition to the
new name of lieer, with an appropriate transition package of course.

I'd be happy to have the maintainer take whatever is deemed useful, or
to upload it, NMU, co-maintain --- whatever the maintainer desires.
Julian?

Cheers,

--Barak.



Bug#969418: Library Package from PPA

2020-09-02 Thread Barak A. Pearlmutter
Package: simplescreenreader
Version: 0.4.2-1

I've ported the injection-library-package stuff from the upstream
author's Ubuntu PPA, moving the support library in the process to what
I'd consider the standard location for such things. Pushed to

https://salsa.debian.org/bap/simplescreenrecorder.git

with associated pull request.

(If merged, uploading will require a binary upload due to the
newly-generated binary package.)

Could use testing to make sure the injection stuff works on both same
arch and on an amd64 system running a 32-bit game process.

--Barak.



Bug#734592: Listing Makefile Targets

2020-08-28 Thread Barak A. Pearlmutter
This seems a bit safer:

make -f debian/rules -rp | egrep -i '^[.a-z0-9_-]*:$'

although it does include "foo:" if there's an "include foo:" even if
there's no rule for "foo".



Bug#968905: marked as done (djview4: unable to save a document)

2020-08-24 Thread Barak A. Pearlmutter
Maybe it would be worth adding something to the man page. Like "if
used in the following way ... this program can make very high demands
on the server, which may trigger anti-DoS logic on some servers or
networks. This can be worked around by ..."

Patches welcome!



Bug#968905: djview4: unable to save a document

2020-08-24 Thread Barak A. Pearlmutter
Quick first reaction, so maybe I'm being clueless. But, my first
thought is to ask: is this really the right place for such a facility?

This seems like a bug in the server. But failing that, it seems like a
"limit transfer rate to HOST:PORT to 10Mb/s" or whatever belongs in a
network policy, like a firewall rule or wherever bandwidth limitations
go. Otherwise we end up cluttering up the logic of every
network-capable program to basically include a little baby network
bandwidth policy submodule. There are also ways of enforcing limits
(CPU limits, memory limits, etc) on programs. "help ulimit" under
bash. This isn't set up to limit network bandwidth, but maybe it
should be? Or some other sandbox/wrapper thing: it's not like there's
any shortage of such mechanisms in a modern bloated Linux kernel!
Bottom line: I'm thinking these kinds of policy restrictions seem like
they belong in layers outside client programs.



Bug#961772: fossil FTCBFS: attempts to run a host tool to check for sqlite3

2020-08-20 Thread Barak A. Pearlmutter
Oops, just saw this. Thanks for the patch.

It's really an upstream issue, so I'm going to forward it there. If
they don't want to merge this functionality, I'll maintain it in a
Debian patch.

Cheers,

--Barak.



Bug#968409: simplescreenrecorder: Upstream Release 0.4.2 Available

2020-08-14 Thread Barak A. Pearlmutter
Package: simplescreenrecorder
Version: 0.3.11-1+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Upstream version 0.4.2 has been released.  I've taken the liberty of
forking the maintenance repo on salsa

https://salsa.debian.org/bap/simplescreenrecorder

and pushed a trial packaging there, which seems to work.  I also filed
merge requests on salsa, because that's what kids do these days.

Cheers,

--Barak



Bug#968237: auctex-12

2020-08-11 Thread Barak A. Pearlmutter
Dear Itaï,

Thanks for trying to contribute to Debian.

> I am not a Debian developper, but am able to package (in fact I have packaged 
> auctex v12 for personal use).

If you have auctex-12 packaged, I would very much encourage you to
share your work, even if the debian maintainer doesn't seem very
active. The easiest way is probably to just fork

https://salsa.debian.org//salve/auctex.git

into your own salsa account and push your changes there. This makes a
bunch of things easier.

(I note that right now upstream is at 12.2, and the current version
not only has functionality issues but also fails to build. So the
package could use a little love. Maybe the maintainer would welcome a
co-maintainer?)

Cheers,

--Barak.



Bug#962779: djview4 color PDF export results in a blank page

2020-07-22 Thread Barak A. Pearlmutter
Thanks for all your help!

I'll go ahead and update the debian package to incorporate the fix to
this issue.
And maybe sometime in the glorious future we'll be able to link to an
external libtiff instead. If so, it will be thanks to your efforts.

Cheers,

--Barak.



Bug#964983: New Upstream Version

2020-07-13 Thread Barak A. Pearlmutter
Sometimes I wonder if Debian needs some serious process analysis and
restructuring. Should a new library version that happens to cross a major
version boundary really good though the same extra vetting queue that a new
browser goes through?

tldr: What have we wrought???


Bug#964983: New Upstream Version

2020-07-13 Thread Barak A. Pearlmutter
Package: libghc-github-dev
Version: 0.20-2
Severity: wishlist

There's a new upstream version available, and I cannot update the
github-backup package until libghc-github-dev (>= 0.23) is available.
So I hope to see the new version packaged.

Cheers,

--Barak.



Bug#964821: New Upstream Version

2020-07-13 Thread Barak A. Pearlmutter
There's a new upstream version available, and I cannot update the
github-backup package until libghc-github-dev (>= 0.23) is available.
So I hope to see the new version packaged.

Cheers,

--Barak.



Bug#662692: Time When?

2020-07-09 Thread Barak A. Pearlmutter
It should probably be an option. The saytime --boop option. "At the
tone, the time will be blah blah blah ... BOOP!"



Bug#662692: Time When?

2020-07-09 Thread Barak A. Pearlmutter
Surely the right thing is:

> At the beep, the time will be ... three forty seven and sixteen seconds ... 
> BEEP.



Bug#962533: mlpack FTBFS on mips64el: relocation truncated to fit

2020-06-28 Thread Barak A. Pearlmutter
How about switching to clang; would there be any objections to that?
If a mips porter could rip all the space save and --parallel=1 stuff
out of debian/rules and build with

fakeroot debian/rules CXX=clang++-9 CC=clang-9 build

and if it works I think just switching would make sense.



  1   2   3   4   5   6   7   8   >