Bug#958868: charcodes component in node-babel7 ftbfs in buster-backports

[Pirate Praveen]

Package: node-babel7
Version: 7.4.5-2
Severity: important

When building node-babel7 for fasttrack.debian.net (like 
buster-backports but some packages taken from unstable or experimental) 
build failed.


Probably adding node-babel 6 as build dependency will fix this. Or we 
may need to embed charcodes that works with babel 7.


Not sure if change introduced in 7.4.5-3 will fix this.

cd charcodes; \
for D in ./packages/*; do \
mkdir "$D/lib"; \
babeljs-7 "$D/src/index.js" -o "$D/lib/index.js" --env-name "cjs"; \
babeljs-7 "$D/src/index.js" -o "$D/lib/index.mjs" --env-name "esm"; \
done
{ Error: [BABEL] 
/<>/charcodes/packages/babel-plugin-transform-charcodes/src/index.js: 
Cannot find module 'babel-types' (While processing: 
"/<>/node_modules/@babel/preset-env/lib/index.js$21")
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:581:15)

  at Function.Module._load (internal/modules/cjs/loader.js:507:25)
  at Module.require (internal/modules/cjs/loader.js:637:17)
  at require (internal/modules/cjs/helpers.js:22:18)
  at Object. 
(/usr/lib/nodejs/regenerator-transform/lib/visit.js:7:19)

  at Module._compile (internal/modules/cjs/loader.js:689:30)
  at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

  at Module.load (internal/modules/cjs/loader.js:599:32)
  at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
  at Function.Module._load (internal/modules/cjs/loader.js:530:3) 
code: 'MODULE_NOT_FOUND' }
{ Error: [BABEL] 
/<>/charcodes/packages/babel-plugin-transform-charcodes/src/index.js: 
Cannot find module 'babel-types' (While processing: 
"/<>/node_modules/@babel/preset-env/lib/index.js$20")
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:581:15)

  at Function.Module._load (internal/modules/cjs/loader.js:507:25)
  at Module.require (internal/modules/cjs/loader.js:637:17)
  at require (internal/modules/cjs/helpers.js:22:18)
  at Object. 
(/usr/lib/nodejs/regenerator-transform/lib/visit.js:7:19)

  at Module._compile (internal/modules/cjs/loader.js:689:30)
  at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

  at Module.load (internal/modules/cjs/loader.js:599:32)
  at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
  at Function.Module._load (internal/modules/cjs/loader.js:530:3) 
code: 'MODULE_NOT_FOUND' }
{ Error: [BABEL] 
/<>/charcodes/packages/charcodes/src/index.js: Cannot find 
module 'babel-types' (While processing: 
"/<>/node_modules/@babel/preset-env/lib/index.js$21")
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:581:15)

  at Function.Module._load (internal/modules/cjs/loader.js:507:25)
  at Module.require (internal/modules/cjs/loader.js:637:17)
  at require (internal/modules/cjs/helpers.js:22:18)
  at Object. 
(/usr/lib/nodejs/regenerator-transform/lib/visit.js:7:19)

  at Module._compile (internal/modules/cjs/loader.js:689:30)
  at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

  at Module.load (internal/modules/cjs/loader.js:599:32)
  at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
  at Function.Module._load (internal/modules/cjs/loader.js:530:3) 
code: 'MODULE_NOT_FOUND' }
{ Error: [BABEL] 
/<>/charcodes/packages/charcodes/src/index.js: Cannot find 
module 'babel-types' (While processing: 
"/<>/node_modules/@babel/preset-env/lib/index.js$20")
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:581:15)

  at Function.Module._load (internal/modules/cjs/loader.js:507:25)
  at Module.require (internal/modules/cjs/loader.js:637:17)
  at require (internal/modules/cjs/helpers.js:22:18)
  at Object. 
(/usr/lib/nodejs/regenerator-transform/lib/visit.js:7:19)

  at Module._compile (internal/modules/cjs/loader.js:689:30)
  at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

  at Module.load (internal/modules/cjs/loader.js:599:32)
  at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
  at Function.Module._load (internal/modules/cjs/loader.js:530:3) 
code: 'MODULE_NOT_FOUND' }

Bug#958838: [Pkg-javascript-devel] Bug#958838: node-babel7 ftbfs in buster-backports

[Pirate Praveen]

Control: tags -1 pending

On Sun, Apr 26, 2020 at 12:20 am, Pirate Praveen 
 wrote:

Package: node-babel7
Version: 7.4.5-2
Severity: important

I'm trying to backport node-babel7 for fasttrack.debian.net and build 
failed with error (many of the build dependencies are in still in 
backports-new so it will be hard to reproduce the error), but it 
seems a simple fix to add the missing dependency to 
debian/build_modules.


/usr/bin/gulp build
[18:37:07] Local gulp not found in /<>
[18:37:07] Try running: npm install gulp
[18:37:07] Using globally installed gulp
internal/modules/cjs/loader.js:583
   throw err;
   ^

Error: Cannot find module 'fastparse'


Added module in salsa master branch.

Bug#958829: haproxyctl: upstream project stale: no changes since 2016, homepage broken, and no issue tracker

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2020-04-25 21:21:50)
> Hi Jonas,
> 
> On Sat, Apr 25, 2020 at 07:34:22PM +0200, Jonas Smedegaard wrote:
> > The haproxyctl project seems abandoned:
> > 
> > Last git commit was in November 2016,
> > the "home" at Github has its issue tracker disabled,
> > and it points to another homebase which is currently down.
> 
> Sounds not good indeed. Should the package be removed from unstable,
> and not be included in the next stable release?

I only just now stumbled upon that package and have never used it 
myself, so would be helpful if others than be chime in on what to do.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#958865: mplayer: theora playback broken: vf_get_image: Assertion `h == -1 || h >= vf->h' failed.

[Jonas Smedegaard]

Hi Stuart,

Quoting Stuart Longland (2020-04-26 03:36:14)
> I struck this issue trying to play a Ogg/Theora video originally on 
> Ubuntu 18.04 LTS and later reproduced the exact same conditions on 
> Debian 10.

> mplayer: libmpcodecs/vf.c:287: vf_get_image: Assertion `h == -1 || h >= 
> vf->h' failed.

> `test.ogv` can be downloaded from
> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1857407/+attachment/5314961/+files/test.ogv

MPlayer is no longer developed and largely replaced by mpv.

I can suggest to try use mpv instead. If you dislike the minimal builtin 
user interface, then try one of the frontends gnome-mpv or smplayer.

I can play the above video just fine with mpv, but your problem might be 
related to other parts of your system (graphics driver, X11 or Wayland 
setup, etc.).



Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#958773: [Pkg-javascript-devel] Bug#958773: psl.js: Package fail to build with node-rollup-plugin-babel 4.4.0

[Pirate Praveen]

On Sat, Apr 25, 2020 at 9:51 am, y...@debian.org wrote:

Package: psl.js
Severity: important

This package fails to build with node-rollup-plugin-babel 4.4.0
(available in experimental dist). Problem seems to be just a missing
dependency to one a node-babel (6) package.


I was able to build it using babel7. See salsa master. I don't think we 
really need to remove the Provides if we can get the failing modules to 
build with babel 7 instead. From this experience, I think updating 
minimum version of node-rollup-plugin-babel and changing build 
dependency to node-babel7 should be enough for most cases. Any extra 
options to rollup-plugin-babel can be removed.

Bug#958867: add an option to add-node-component to embed build only modules in debian/build_modules

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.9.32
Severity: wishlist

It'd be a nice addition to automate this.

Bug#644728: CONFIM RECEIPT

[Smith and Associates]

Dear Sir,

Did you get my previous email about you deceased relatives estate?

Paul Smith
Smith and Associates
Tampa Florida U.S.A

Bug#956729: asciidoc-base: add xsltproc to Depends

[Joseph H.]

Hi Andrius,

asciidoc-base is as a base package and meant to be minimal especially
meant to be used for manpage. The whole xsltproc thing has a lot of
dependencies that are not always suitable in build environments for
example.
I wouldn't recommend using a2x for generating manpages. This relies on
the whole xslt machinery.
You can just use the asciidoc command-line. Example:

asciidoc -d manpage ~/Downloads/doc_a2x.1.txt


Joseph

Bug#150137: CONFIM RECEIPT

[Smith and Associates]

Dear Sir,

Did you get my previous email about you deceased relatives estate?

Paul Smith
Smith and Associates
Tampa Florida U.S.A

Bug#956729: asciidoc-base: add xsltproc to Depends

[Joseph H.]

Nevermind. I'm tired. That was for xmlto and that command I gave
earlier was the wrong one.
Anyway, I'll add the dependency tomorrow but note that you will also
need to add --no-xmllint to avoid errors.

a2x -d manpage -f manpage --no-xmllint ~/Downloads/doc_a2x.1.txt

Joseph

On Sat, Apr 25, 2020 at 8:36 PM Joseph H.  wrote:
>
> Hi Andrius,
>
> asciidoc-base is as a base package and meant to be minimal especially
> meant to be used for manpage. The whole xsltproc thing has a lot of
> dependencies that are not always suitable in build environments for
> example.
> I wouldn't recommend using a2x for generating manpages. This relies on
> the whole xslt machinery.
> You can just use the asciidoc command-line. Example:
>
> asciidoc -d manpage ~/Downloads/doc_a2x.1.txt
>
>
> Joseph

Bug#958811: exec: "runc": executable file not found in $PATH

[Dmitry Smirnov]

On Sunday, 26 April 2020 12:38:25 PM AEST Shengjing Zhu wrote:
> Shouldn't we move /usr/sbin/runc to /usr/bin/runc, since runc now has
> rootless mode after setting kernel.unprivileged_userns_clone?

Yeah, perhaps with a compatibility symlink. Why not?

Thanks.

-- 
Best wishes,
 Dmitry Smirnov.

---

The cure for the evils of democracy is more democracy.
-- H. L. Mencken


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

Bug#958811: exec: "runc": executable file not found in $PATH

[Shengjing Zhu]

control: clone -1 -2
control: reassign -2 runc
control: retitle -2 install runc symlink in /usr/bin

On Sun, Apr 26, 2020 at 11:10 AM Dmitry Smirnov  wrote:
>
> On Sunday, 26 April 2020 12:38:25 PM AEST Shengjing Zhu wrote:
> > Shouldn't we move /usr/sbin/runc to /usr/bin/runc, since runc now has
> > rootless mode after setting kernel.unprivileged_userns_clone?
>
> Yeah, perhaps with a compatibility symlink. Why not?
>

I think we can just do it like opensuse. /usr/bin/runc -> /usr/sbin/runc

--
Shengjing Zhu

Bug#958811: exec: "runc": executable file not found in $PATH

[Shengjing Zhu]

On Sun, Apr 26, 2020 at 10:38 AM Shengjing Zhu  wrote:
>
> On Sun, Apr 26, 2020 at 6:15 AM Dmitry Smirnov  wrote:
> >
> > On Sunday, 26 April 2020 12:14:25 AM AEST Tomas Janousek wrote:
> > > Debian installs runc as /usr/sbin/runc, and regular users don't have
> > > /usr/sbin in $PATH, so "buildah run" without "--runtime /usr/sbin/runc"
> > > fails:
> > >
> > > $ buildah run debian-working-container -- sh
> > > error running container: error creating container for [/bin/sh]: :
> > > exec: "runc": executable file not found in $PATH ERRO exit status 1
> >
> > Interesting. Thanks. Perhaps we should hard-code path to "runc" in "util/
> > types.go".
> >
> > Documentation suggests to set path to runtime in the BUILDAH_RUNTIME
> > environment variable:
> >
> >   export BUILDAH_RUNTIME=/usr/bin/crun
> >
> >
> > With cgroups_v2 You should be able to use "crun" instead of "runc".
> > "crun" is the first alternative that is expected to work "out of the box".
> >
> >
> > > I'd expect this to work out of the box.
> >
> > I'm not sure it can be done because of requirement to set
> > "kernel.unprivileged_userns_clone=1".
> >
>
> Shouldn't we move /usr/sbin/runc to /usr/bin/runc, since runc now has
> rootless mode after setting kernel.unprivileged_userns_clone?
>

Just checked the path in other distributions,

fedora and archlinux install it in /usr/bin now.
https://apps.fedoraproject.org/packages/runc/contents/
https://www.archlinux.org/packages/community/x86_64/runc/

opensuse installs a symlink a /usr/bin.
https://build.opensuse.org/package/view_file/openSUSE:Factory/runc/runc.spec?expand=1



--
Shengjing Zhu

Bug#958811: exec: "runc": executable file not found in $PATH

[Shengjing Zhu]

On Sun, Apr 26, 2020 at 6:15 AM Dmitry Smirnov  wrote:
>
> On Sunday, 26 April 2020 12:14:25 AM AEST Tomas Janousek wrote:
> > Debian installs runc as /usr/sbin/runc, and regular users don't have
> > /usr/sbin in $PATH, so "buildah run" without "--runtime /usr/sbin/runc"
> > fails:
> >
> > $ buildah run debian-working-container -- sh
> > error running container: error creating container for [/bin/sh]: :
> > exec: "runc": executable file not found in $PATH ERRO exit status 1
>
> Interesting. Thanks. Perhaps we should hard-code path to "runc" in "util/
> types.go".
>
> Documentation suggests to set path to runtime in the BUILDAH_RUNTIME
> environment variable:
>
>   export BUILDAH_RUNTIME=/usr/bin/crun
>
>
> With cgroups_v2 You should be able to use "crun" instead of "runc".
> "crun" is the first alternative that is expected to work "out of the box".
>
>
> > I'd expect this to work out of the box.
>
> I'm not sure it can be done because of requirement to set
> "kernel.unprivileged_userns_clone=1".
>

Shouldn't we move /usr/sbin/runc to /usr/bin/runc, since runc now has
rootless mode after setting kernel.unprivileged_userns_clone?

-- 
Shengjing Zhu

Bug#920485: Bug#958865: Acknowledgement (mplayer: theora playback broken: vf_get_image: Assertion `h == -1 || h >= vf->h' failed.)

[Stuart Longland]

On 26/4/20 11:48 am, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 958865: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958865.

So further research, it appears these are duplicate issues.  958865 can
be closed in favour of 920485.

Bug#958865: mplayer: theora playback broken: vf_get_image: Assertion `h == -1 || h >= vf->h' failed.

[Stuart Longland]

Package: mplayer
Version: 2:1.3.0-8+b4
Severity: important

Hi,

I struck this issue trying to play a Ogg/Theora video originally on
Ubuntu 18.04 LTS and later reproduced the exact same conditions on
Debian 10.

Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1857407

What happens on Debian:
stuartl@vk4msl-nb:~$ mplayer /tmp/test.ogv 
MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /tmp/test.ogv.
libavformat version 58.20.100 (external)
Mismatching header version 58.12.100
libavformat file format detected.
Invalid return value 0 for stream protocol
Invalid return value 0 for stream protocol
[lavf] stream 0: video (theora), -vid 0
[lavf] stream 1: audio (vorbis), -aid 0, -alang eng
VIDEO:  [theo]  240x180  0bpp  29.970 fps0.0 kbps ( 0.0 kbyte/s)
libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.35.100 (external)
Mismatching header version 58.18.100
Selected video codec: [fftheora] vfm: ffmpeg (FFmpeg Theora)
==
Load subtitles in /tmp/
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 32000 Hz, 1 ch, floatle, 128.0 kbit/12.50% (ratio: 16000->128000)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==
AO: [pulse] 32000Hz 1ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vdpau] 240x180 => 240x180 Planar YV12 
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vdpau] 240x180 => 240x180 Planar YV12 
Dropping frame with size not matching configured size (240x180 vs 240x168 vs 
240x180)
Dropping frame with size not matching configured size (240x180 vs 240x168 vs 
240x180)
[VD_FFMPEG] DRI failure.
mplayer: libmpcodecs/vf.c:287: vf_get_image: Assertion `h == -1 || h >= vf->h' 
failed.


MPlayer interrupted by signal 6 in module: decode video
 [ This binary of MPlayer in Debian is currently compiled with
   '--enable-debug'; the debugging symbols are in the package
   'mplayer-dbgsym'.]

The package `mplayer-dbgsym` does not exist according to `apt`.

`test.ogv` can be downloaded from
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1857407/+attachment/5314961/+files/test.ogv

I tried installing the "unstable" release of `mplayer`, however its
dependencies on `libc6` prevented me from doing so safely.  I am not
sure when the Debian 11 release is expected, so I am sticking to version
10 for now.

The above bug is pretty easy to reproduce anyway, and can be reproduced
on both Debian and Ubuntu, which says to me its something common to both.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mplayer depends on:
ii  liba52-0.7.4   0.7.4-19
ii  libaa1 1.4p5-46
ii  libasound2 1.1.8-1
ii  libass91:0.14.0-2
ii  libaudio2  1.9.4-6
ii  libavcodec-extra58 [libavcodec58]  7:4.1.4-1~deb10u1
ii  libavformat58  7:4.1.4-1~deb10u1
ii  libavutil567:4.1.4-1~deb10u1
ii  libbluray2 1:1.1.0-1
ii  libbs2b0   3.1.0+dfsg-2.2
ii  libc6  2.28-10
ii  libcaca0   0.99.beta19-2.1
ii  libcdio-cdda2  10.2+2.0.0-1+b1
ii  libcdio-paranoia2  10.2+2.0.0-1+b1
ii  libcdio18  2.0.0-2
ii  libdca00.0.6-1
ii  libdirectfb-1.7-7  1.7.7-9
ii  libdv4 1.0.0-12
ii  libdvdnav4 6.0.0-1
ii  libdvdread46.0.1-1
ii  libenca0   1.19-1+b1
ii  libfaad2   2.8.8-3
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3+deb10u1
ii  libfribidi01.0.5-3.1+deb10u1
ii  libgif75.1.4-

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[FeRD]

On Sat, Apr 25, 2020 at 4:41 PM John Scott  wrote:

> On Fri, 24 Apr 2020 23:33:59 -0400 FeRD  wrote:
> > What version of libopenshot is that result from? The Clang namespacing
> was
> > fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included
> in
> > both libopenshot-0.2.4 and libopenshot-0.2.5.
> I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm
> not
> the maintainer; upgrading it is outside of my domain (esp. in light of the
> following).
>

Ah, gotcha. Yeah, libopenshot 0.2.2's *tests* not building with Clang is a
known issue,
which has been fixed since 0.2.4.


> Right, I know what'll pull it all together. It seems that the source for
> libopenshot includes embedded code copies of JUCE, and code copies are
> strongly discouraged in Debian, even if they don't make it into the
> binaries.


> That file is a Debian-specific README mostly addressed to developers that
> says
> to replace bundled copies of JUCE and use the code in package juce-modules-
> source instead. This approach seems to have not been taken.
>

Understood. Well, looking at things from that direction, fortunately the
bundled
code is all sequestered into a separate package, libopenshot-*audio*, which
libopenshot depends on.

Really there's nothing to libopenshot-audio OTHER than a customized build
of JUCE, to be honest. (Customized == pared down, mostly. We don't use any
of the GUI components. So it's "JUCE but only these six modules: core,
events,
data_structures, audio_basics, audio_devices, and audio_formats.")

If Debian maintains JUCE as a distro package, and it would be a compatible
alternative to our JUCE-based "libopenshot-audio", I don't see any reason we
can't add an option to libopenshot's CMake configuration that tells it to
just
use those libs, completely replacing libopenshot-audio — which would
become entirely superfluous in that scenario.

This is the perfect time to do it, too, as I've been gutting and reworking
large parts
of libopenshot's build system recently — sticking in a "USE_SYSTEM_JUCE"
option would be no trouble at all.

Is there an importable CMake configuration for the distro JUCE package, by
any chance, or should I put together a find module as well?


>
> I hope this makes clear the nature of the obstacles ahead.


It makes the *situation* much clearer, yes thanks — but so far I'm still
optimistic that this is pretty easily solvable, really. Then again, I
rarely see
obstacles until I barrel into them at 50 MPH, so I guess we'll see how
things
go. ¯\_(ツ)_/¯

Bug#779003: CONFIM RECEIPT

[Smith and Associates]

Dear Sir,

Did you get my previous email about you deceased relatives estate?

Paul Smith
Smith and Associates
Tampa Florida U.S.A

Bug#958859: Never mind

[Edmund Biow]

Sorry Maintainer (Eric?), PEBKAC, please delete this bug if possible.

The problem was messed up permissions, I'd had to move my approx cache
directory from my / root partition because it just keeps getting bigger
since it no longer seems to cull itself and approx-gc no longer works. It
is now close to 150 GB.  So I moved the approx cache to my data partition
instead, where it had room to grow.

$cache  /data/approx

But recently I had problem writing to some directory on my server's data
partition, so I did a recursive chown to my normal user to the partition to
fix the problem, but I'd forgot I'd done it a few days later when I tried
to update a machine on my little network.

But after letting it percolate in my head for a few hours I remembered what
I had done and that my approx cache was on that partition, so I did a
'chown -R 125.131 /data/approx' and all is good again. Some people are too
dumb to run Linux.

While I'm groveling and thanking you for all your do, is there any new way
to cull the cruft from my approx cache?  For example, right now I have 23
versions of google-chrome-stable in my
/server/approx/googlechrome/pool/main/g/google-chrome-stable/' directory.
Maybe a command to delete all the .deb files in the cache that are older
than a year old?

Stay safe & well.

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: Bug#919557: Bug#919557: Bug#922944: handling symbolic links in webextensions

[Ximin Luo]

Dmitry Smirnov:
> On Sunday, 26 April 2020 9:25:06 AM AEST Ximin Luo wrote:
>> The source code doesn't mention any particular reason, and one person on
>> the upstream bug report mentions it in such an off-the-cuff and
>> non-explanatory way I can't take it into account as a serious data point.
>> We shouldn't just let a mere mention of "security" scare us into not
>> touching stuff and using our own reasoning to fix bugs.
>>
>> And I *did* think about the possible security considerations, as I
>> explained in my previous email, and derived my suggested patch based on
>> these considerations. (FWIW, I have done and am doing various types of
>> security work professionally, and I'm confident about this type of
>> reasoning in general.)
> 
> Did you consider the possibility of users having a mix of packaged and non-
> packaged extensions? I think it is reasonable to contain/sandbox extensions 
> to prevent peeking to various file system locations through symlinks.
> 
> Once Firefox is patched to allow symlinks, the threat might be from malicious 
> symlinks in non-packaged extensions.
> 

Yes, I covered this already. My suggested patch (B) would only traverse 
symlinks when the extension being loaded (the symlink being resolved) is itself 
underneath /usr/share/webext, other extensions would still not be allowed to 
traverse symlinks.

Please do read through my first email in full.

X


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#958864: at: Please add command line of the job to the output mail

[Patrik Schindler]

Package: at
Version: 3.1.23-1
Severity: wishlist

When typing a simple command at the at prompt and the command fails, I probably
need to type it again. Would be nice to have it in the mail ready for
copy-paste.

This could also be a solution for bug #244533.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages at depends on:
ii  libc6   2.28-10
ii  libfl2  2.6.4-6.2
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 2.8-1+b1
ii  lsb-base10.2019051400

Versions of packages at recommends:
ii  postfix [mail-transport-agent]  3.4.8-0+10debu1

at suggests no packages.

-- Configuration Files:
/etc/at.deny [Errno 13] Permission denied: '/etc/at.deny'

-- no debconf information

Bug#958863: at: Please add new queue for running one job after the other

[Patrik Schindler]

Package: at
Version: 3.1.23-1
Severity: wishlist

Hello,

I'd love to see a new queue added to at but instead of depending on start time,
or load-avg (batch), submitted jobs just run one after the other.

Sometimes, jobs simply don't create "enough" load, so batch jobs can run in
parallel without any issue. Sometimes, it's desirable to let one job finish
before starting the next.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages at depends on:
ii  libc6   2.28-10
ii  libfl2  2.6.4-6.2
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 2.8-1+b1
ii  lsb-base10.2019051400

Versions of packages at recommends:
ii  postfix [mail-transport-agent]  3.4.8-0+10debu1

at suggests no packages.

-- no debconf information

Bug#958861: additional information

[Wendy J. Elmer]

I tried to build my own 5.5 kernel and I get the following error during
the nvidia dkms build.

make -f ./scripts/Makefile.modpost
  sed 's/ko$/o/' /var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/modules.order | scripts/mod/modpost -m  -i
./Module.symvers  -o /var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/Module.symvers-s -T - 
ERROR: "nvUvmInterfaceSessionCreate" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceChannelAllocate" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceGetGpuArch" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceRegisterUvmCallbacks" [/var/lib/dkms/nvidia-
legacy-340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceAddressSpaceDestroy" [/var/lib/dkms/nvidia-
legacy-340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceCopyEngineAllocate" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceCheckEccErrorSlowpath" [/var/lib/dkms/nvidia-
legacy-340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceSessionDestroy" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceGetAttachedUuids" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceGetUvmPrivRegion" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceDeRegisterUvmOps" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceServiceDeviceInterruptsRM" [/var/lib/dkms/nvidia-
legacy-340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceAddressSpaceCreateMirrored"
[/var/lib/dkms/nvidia-legacy-340xx/340.108/build/uvm/nvidia-uvm.ko]
undefined!
ERROR: "nvUvmInterfaceKillChannel" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceMemoryCpuMap" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceMemoryAllocSys" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceQueryCaps" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
ERROR: "nvUvmInterfaceChannelDestroy" [/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm/nvidia-uvm.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[1]: *** [Makefile:1620: modules] Error 2
make[1]: Leaving directory '/usr/local/src/linux-source-5.5'
make: *** [Makefile:218: nvidia-uvm.ko] Error 2
make: Leaving directory '/var/lib/dkms/nvidia-legacy-
340xx/340.108/build/uvm'

Bug#885198: graphviz: please migrate to guile-2.2

[Rob Browning]

It appears that this hasn't actually been resolved.  i.e. after grabbing
the current sid source (and an ldd on the current libgv-guile .so also
indicates it's still built against 2.0):

  $ rgrep guile | grep -F 2.0
  debian/control: guile-2.0-dev,
  debian/control: This package contains the guile (2.0) bindings.
  debian/changelog:  * Build using guile-2.0. Closes: #746012.
  debian/changelog:- Build using guile-2.0.
  debian/changelog:  * Build using guile-2.0.
  configure.ac:   [guile-2.0 >= 
"$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"],
  .pc/build_with_libann.patch/configure.ac:   [guile-2.0 >=
"$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"],
  .pc/versioned-plugin-config-file.diff/configure.ac: [guile-2.0 >=
"$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"],
  .pc/50_remove_changelog_in/configure.ac:[guile-2.0 >=
"$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"],
  .pc/ruby-config.diff/configure.ac:  [guile-2.0 >=
"$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"],

Oh, and if feasible, please consider migrating directly to guile-3.0
instead.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)

[Aaron M. Ucko]

reassign 956848 t-coffee 13.41.0.28bdc39+dfsg-1
retitle 956848 t-coffee: should use "example" blastpgp.pl
retitle 956850 ncbi-blast+: Please provide /usr/bin/legacy_blast.pl
thanks

Andreas Tille  writes:

> Thanks again.  Applied an pushed.  Please feel free to directly
> commit to Git.  I don't see any advantage to communicate via
> BTW. :-)

Thanks, but I'm not closely familiar with t-coffee, so I appreciate
having a second set of eyes on any patches I prepare for it.

At any rate, I'm assigning #956848 to t-coffee, which should address the
NCBI blastpgp vs. EBI blastpgp.pl conflation, and leaving #956850 alone
for now (apart from correcting a typo in its title).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#947550: RFH: salsa.debian.org/debian/dbab

[Tong Sun]

On Wed, Jan 1, 2020 at 11:52 PM Utkarsh Gupta wrote:
>
> > However, a second pair of eyes, i.e., any kind of reviews and
> > suggestions are appreciated.
>
> A couple of pointers from my end..

Thank you Utkarsh for all the inputs and recommendation. I'm in the
process of fixing each and every one of them. I think I understand all
of them, except:

> 1. As a general rule, always check your package by running "cme fix
> dpkg". Once you do that, please commit the result.
> Let me know if you don't understand the result.

Which package does this `cme` come from?

I checked

cme - Check or edit configuration data with Config::Model

and think it is not the one.

thx

Bug#956007: mercurial: Remove use of python-subversion

[James McCoy]

Control: severity -1 serious

On Sun, Apr 05, 2020 at 08:50:32PM -0400, James McCoy wrote:
> python-subversion can't be built with current src:swig, so I'm in the
> process of removing it.  Subversion's next upstream release will have
> support for Python 3, but since src:subversion currently FTBFS I'm
> removing the package early.

This has now happened, as of subversion 1.13.0-4.

> It appears that mercurial uses python-subversion in some of its
> testsuite (and therefore also autopkgtests), so those should probably be
> blacklisted until they're converted to work with the future
> python3-subversion.

Can this please be addressed?

I'm raising the severity of the bug as mercurial will now FTBFS.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#958862: ITP: goverlay -- Graphical UI to help manage Linux overlays

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 

  Package name: goverlay
  Version : 0.3.1
  Upstream Author : Benjamimg Gois 
  URL : https://github.com/benjamimgois/goverlay
  License : GPL v3
  Programming Lang: Pascal (project uses Lazarus)
  Description : Graphical UI to help manage Linux overlays

GOverlay is a program to manage overlays for games, currently it supports
MangoHud, an overlay to display informations about fps, gpu temp etc, and
vkBasalt, a vulkan post processing layer.
Since I currently plan to pack MangoHud for Debian (see #954844 on BTS), this
would be a nice addition to that. I'll probably will look packaging into
vkBasalt as well.

My packaging current packaging attempt is on Salsa:
https://salsa.debian.org/stephanlachnit/goverlay
GOverlay is written in Pascal with Lazarus, meaning it doesn't work natively
with dh. As one can see in my rules file, I basically used dh everywhere and
just changed the build target. I wasn't able to get it working with the default
dh-sequencer, but I think it should be possible to do that. Any feedback is
appreciated.

Cheers,
Stephan

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: Bug#919557: Bug#922944: handling symbolic links in webextensions

[Dmitry Smirnov]

On Sunday, 26 April 2020 9:25:06 AM AEST Ximin Luo wrote:
> The source code doesn't mention any particular reason, and one person on
> the upstream bug report mentions it in such an off-the-cuff and
> non-explanatory way I can't take it into account as a serious data point.
> We shouldn't just let a mere mention of "security" scare us into not
> touching stuff and using our own reasoning to fix bugs.
> 
> And I *did* think about the possible security considerations, as I
> explained in my previous email, and derived my suggested patch based on
> these considerations. (FWIW, I have done and am doing various types of
> security work professionally, and I'm confident about this type of
> reasoning in general.)

Did you consider the possibility of users having a mix of packaged and non-
packaged extensions? I think it is reasonable to contain/sandbox extensions 
to prevent peeking to various file system locations through symlinks.

Once Firefox is patched to allow symlinks, the threat might be from malicious 
symlinks in non-packaged extensions.


> This is static linking, and in Debian we generally avoid doing that. I am
> not saying you shouldn't do it for your package, but we also shouldn't shy
> away from fixing infrastructural situations that force us into it.

Yes, valid. I agree. :)

-- 
Regards,
 Dmitry Smirnov.

---

Censorship is always cause for celebration. It is always an opportunity
because it reveals fear of reform. It means that the power position is so
weak that you have got to care what people think.
-- Julian Assange


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

Bug#958861: linux-image-5.5.0-2-amd64: nvidia dkms module fails to build on kernel 5.5.0-2-amd64

[Brent]

Package: src:linux
Version: 5.5.17-1
Severity: normal

I installed linux-image-5.5.0-2-amd64 and as part of the install it tried to
build nvidia-legacy-340-108 dkms module.  There was an error in the nvidia
module build.

DKMS make.log for nvidia-legacy-340xx-340.108 for kernel 5.5.0-2-amd64 (x86_64)
Sat 25 Apr 2020 06:38:39 PM CDT
NVIDIA: calling KBUILD...
make NV_MODULE_SUFFIX= KBUILD_OUTPUT=/lib/modules/5.5.0-2-amd64/build
KERNEL_SOURCES=/lib/modules/5.5.0-2-amd64/source
KERNEL_OUTPUT=/lib/modules/5.5.0-2-amd64/build KBUILD_VERBOSE=1 -C
/lib/modules/5.5.0-2-amd64/source M=/var/lib/dkms/nvidia-
legacy-340xx/340.108/build ARCH=x86_64 modules
make[1]: Entering directory '/usr/src/linux-headers-5.5.0-2-common'
make -C /usr/src/linux-headers-5.5.0-2-amd64 -f /usr/src/linux-
headers-5.5.0-2-common/Makefile modules
make[2]: Entering directory '/usr/src/linux-headers-5.5.0-2-amd64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-5.5.0-2-common/scripts/Makefile.build
obj=/var/lib/dkms/nvidia-legacy-340xx/340.108/build \
single-build= \
need-builtin=1 need-modorder=1
CONFTEST=/bin/sh /var/lib/dkms/nvidia-legacy-340xx/340.108/build/conftest.sh "
gcc-9" " gcc-9" x86_64 /lib/modules/5.5.0-2-amd64/source
/lib/modules/5.5.0-2-amd64/build
echo \#define NV_COMPILER \"` gcc-9 -v 2>&1 | tail -n 1`\" >
/var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv_compiler.h
CONFTEST_CFLAGS=
KBUILD_CFLAGS=-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-
strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-
declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-
mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1
-mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
-mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -DCONFIG_AS_ADX=1 -Wno-sign-
compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-
packed-member -O2 --param=allow-store-data-races=0  -Wframe-larger-than=2048
-fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough
-Wno-unused-const-variable  -fno-var-tracking-assignments -g -pg -mrecord-
mcount -mfentry -DCC_USING_FENTRY  -flive-patching=inline-clone -Wdeclaration-
after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-
overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check
-fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -fmacro-prefix-map=/usr/src/linux-
headers-5.5.0-2-common/= -fcf-protection=none -Wno-packed-not-aligned
  cat /var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv-kernel-amd64.o_shipped
> /var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv-kernel-amd64.o
LINUXINCLUDE=-I/usr/src/linux-headers-5.5.0-2-common/arch/x86/include
-I./arch/x86/include/generated -I/usr/src/linux-headers-5.5.0-2-common/include
-I./include -I/usr/src/linux-headers-5.5.0-2-common/arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I/usr/src/linux-
headers-5.5.0-2-common/include/uapi -I./include/generated/uapi -include
/usr/src/linux-headers-5.5.0-2-common/include/linux/kconfig.h
LDFLAGS=
ARCH=x86_64
{   echo /var/lib/dkms/nvidia-legacy-340xx/340.108/build/nvidia.ko; :; } \
| awk '!x[$0]++' - > /var/lib/dkms/nvidia-
legacy-340xx/340.108/build/modules.order
for SANITY_CHECK in rivafb_sanity_check nvidiafb_sanity_check dom0_sanity_check
xen_sanity_check preempt_rt_sanity_check; do \
 echo " CONFTEST: $SANITY_CHECK"; \
 if ! /bin/sh /var/lib/dkms/nvidia-legacy-340xx/340.108/build/conftest.sh "
gcc-9" " gcc-9" x86_64 /lib/modules/5.5.0-2-amd64/source
/lib/modules/5.5.0-2-amd64/build $SANITY_CHECK full_output; then \
 exit 1; \
 fi; \
done
 CONFTEST: rivafb_sanity_check
 CONFTEST: compile_tests
if ! /bin/sh /var/lib/dkms/nvidia-legacy-340xx/340.108/build/conftest.sh "
gcc-9" " gcc-9" x86_64 /lib/modules/5.5.0-2-amd64/source
/lib/modules/5.5.0-2-amd64/build compile_tests remap_pfn_range vmap
set_pages_uc set_memory_uc set_memory_array_uc change_page_attr i2c_adapter
pci_get_class pm_message_t irq_handler_t pci_choose_state vm_insert_page
acpi_device_ops acpi_op_remove acpi_device_id acquire_console_sem console_loc

Bug#943135: numba: Python2 removal in sid/bullseye - reopen 943135

[peter green]

severity 943135 serious
tags 943135 +patch
thanks


This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:numba)Testsuite-Triggers->python-all-dev
(source:numba)Testsuite-Triggers->python-funcsigs
(source:numba)Testsuite-Triggers->python-numba
(source:numba)Testsuite-Triggers->python-singledispatch
(binary:numba-doc)Recommends->python-numba

Re-opening, so that they can be taken care of.

I attatch a debdiff cleaning up the remaining python2 stuff.

Bumping severity to serious because the python2 leftovers are causing a 
autopkgtest failure which the release team now consider rc.

I may or may not NMU this later.

diff -Nru numba-0.48.0/debian/changelog numba-0.48.0/debian/changelog
--- numba-0.48.0/debian/changelog   2020-02-13 11:09:45.0 +
+++ numba-0.48.0/debian/changelog   2020-04-25 18:22:26.0 +
@@ -1,3 +1,11 @@
+numba (0.48.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove autopkgtest for removed python-numba package.
+  * Remove reccomends on removed python-numba package.
+
+ -- Peter Michael Green   Sat, 25 Apr 2020 18:22:26 +
+
 numba (0.48.0-1) unstable; urgency=medium
 
   * New upstream version 0.48.0
diff -Nru numba-0.48.0/debian/control numba-0.48.0/debian/control
--- numba-0.48.0/debian/control 2020-02-13 11:04:02.0 +
+++ numba-0.48.0/debian/control 2020-04-25 18:21:48.0 +
@@ -51,7 +51,6 @@
  ${sphinxdoc:Depends},
  ${misc:Depends}
 Recommends:
- python-numba,
  python3-numba
 Description: native machine code compiler for Python (docs)
  Numba compiles native machine code instructions from Python programs at
diff -Nru numba-0.48.0/debian/tests/control numba-0.48.0/debian/tests/control
--- numba-0.48.0/debian/tests/control   2019-11-24 05:52:38.0 +
+++ numba-0.48.0/debian/tests/control   2020-04-25 18:21:26.0 +
@@ -1,5 +1,3 @@
-Tests: python-numba
-Depends: python-numba, python-all-dev, python-funcsigs, python-singledispatch
 
 Tests: python3-numba
 Depends: python3-numba, python3-all-dev
diff -Nru numba-0.48.0/debian/tests/python-numba 
numba-0.48.0/debian/tests/python-numba
--- numba-0.48.0/debian/tests/python-numba  2019-11-24 05:52:38.0 
+
+++ numba-0.48.0/debian/tests/python-numba  1970-01-01 00:00:00.0 
+
@@ -1,4 +0,0 @@
-#!/bin/sh
-set -e
-cd "$AUTOPKGTEST_TMP" # run on installed package
-for py in $(pyversions -i); do echo "[*] Testing with $py:"; $py -Wd -m 
numba.runtests -v -m 2>&1; done

Bug#885215: mcron: please migrate to guile-2.2 (NMU diff 1.0.8-1.1)

[Rob Browning]

---
 configure.ac  |   2 +-
 debian/changelog  |  14 ++
 debian/control|   4 +-
 debian/patches/migrate-to-guile-3.0   |  13 ++
 debian/patches/series |   1 +
 debian/rules  |   2 +-
 create mode 100644 debian/patches/migrate-to-guile-3.0

diff --git a/configure.ac b/configure.ac
index 764ea03..881d8d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,7 +48,7 @@ AC_PROG_AWK
 AC_PROG_EGREP
 AM_PROG_CC_C_O
 
-PKG_CHECK_MODULES(GUILE, guile-2.0)
+PKG_CHECK_MODULES(GUILE, guile-3.0)
 
 # Checks for programs.
   
diff --git a/debian/changelog b/debian/changelog
index 9b46497..1a40b55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+mcron (1.0.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  * configure.ac: migrate to guile-3.0.
+
+  * debian/control: migrate to guile-3.0. (Closes: 885215)
+
+  * debian/control: build-depend on texinfo for makeinfo.
+
+  * debian/rules: request autoreconf to fix gcc invocations.
+
+ -- Rob Browning   Sat, 25 Apr 2020 18:03:00 -0500
+
 mcron (1.0.8-1) unstable; urgency=low
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 255fb63..e376c18 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: mcron
 Section: utils
 Priority: optional
 Maintainer: Dale Mellor 
-Build-Depends: debhelper (>= 9), guile-2.0-dev, ed, help2man
+Build-Depends: debhelper (>= 10), guile-3.0-dev, ed, help2man, texinfo
 Standards-Version: 3.9.5
 Homepage: http://www.gnu.org/software/mcron
 
@@ -11,7 +11,7 @@ Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  dpkg (>= 1.15.4)|install-info,
- guile-2.0,
+ guile-3.0,
  sendmail|mail-transport-agent
 Description: Guile-based program for running jobs at regular times
  The GNU package mcron (Mellor's cron) can be a 100% compatible replacement for
diff --git a/debian/patches/migrate-to-guile-3.0 
b/debian/patches/migrate-to-guile-3.0
new file mode 100644
index 000..83f5ead
--- /dev/null
+++ b/debian/patches/migrate-to-guile-3.0
@@ -0,0 +1,13 @@
+Index: main/configure.ac
+===
+--- main.orig/configure.ac
 main/configure.ac
+@@ -48,7 +48,7 @@ AC_PROG_AWK
+ AC_PROG_EGREP
+ AM_PROG_CC_C_O
+ 
+-PKG_CHECK_MODULES(GUILE, guile-2.0)
++PKG_CHECK_MODULES(GUILE, guile-3.0)
+ 
+ # Checks for programs.
+   
diff --git a/debian/patches/series b/debian/patches/series
index eeb6f6b..5949e95 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 disable-maintainer-mode.patch
 make-clean.patch
+migrate-to-guile-3.0
diff --git a/debian/rules b/debian/rules
index f11d5f0..e319d13 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@
 #export DH_VERBOSE=1
 
 %:
-   dh  $@
+   dh $@ --with autoreconf
 
 override_dh_auto_configure:
dh_auto_configure -- --enable-no-vixie-clobber
-- 
2.26.1

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: Bug#922944: handling symbolic links in webextensions

[Ximin Luo]

Dmitry Smirnov:
> On Sunday, 26 April 2020 8:20:28 AM AEST Ximin Luo wrote:
>> As I mentioned on firefox bugzilla [1], I have figured out the exact place
>> in the firefox code responsible for this issue.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420286
> 
> Without looking into the proposed fix, I think there are few reasons not to 
> make any alterations:
> 
> As much as I like the idea of symlinking resources from webextensions, 
> incorporating those resources at build-time make packaged addons less 
> fragile. Frequently synlinked Javascript libraries change/break often enough 
> on "apt upgrade" and when it happens maintainer have to resort to bundling of 
> working versions anyway but not before users experience (and report) 
> breakage.
> 
> Diverging from upstream may not be desirable. I'm sure Firefox is difficult 
> enough to maintain without adding specific logic that have to be tested.
> 

The suggested patch is removing 3 lines, and changing 1 line. This is not hard 
to maintain. I see plenty of other patches in this firefox package already much 
larger than this, and I maintain larger patches in other similarly complex 
packages.

> IMHO symlinks sandboxing was done upstream for security reasons. We may not 
> fully understand implication of changing this behaviour.
> 

The source code doesn't mention any particular reason, and one person on the 
upstream bug report mentions it in such an off-the-cuff and non-explanatory way 
I can't take it into account as a serious data point. We shouldn't just let a 
mere mention of "security" scare us into not touching stuff and using our own 
reasoning to fix bugs.

And I *did* think about the possible security considerations, as I explained in 
my previous email, and derived my suggested patch based on these 
considerations. (FWIW, I have done and am doing various types of security work 
professionally, and I'm confident about this type of reasoning in general.)

> I've already discovered and documented working solution to incorporating 
> resources to webextension packages at build time. Updating packages is easy 
> enough and should be even possible with binNMUs to refresh their bundled 
> resources. That approach might be considered "good enough".
> 

This is static linking, and in Debian we generally avoid doing that. I am not 
saying you shouldn't do it for your package, but we also shouldn't shy away 
from fixing infrastructural situations that force us into it.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#958848: [Pkg-privacy-maintainers] Bug#958848: pytest (build-)depends on pypy-funcsigs which the maintainer would like to get rid of.

[Chris Lamb]

Hi Peter,

> vanguards on the other hand is an application which I assume relies on 
> pytest for it's testsuite.
> 
> So I guess the question is whether it is worth keeping this pile of 
> pypy modules around to support the testsuite of one application?

I believe the following patch to src:vanguards can be used to use the
Python 3.x testsuite instead:

--- a/debian/control
+++ b/debian/control
@@ -8,8 +8,9 @@ Build-Depends: debhelper (>= 11),
dh-python,
pypy,
pypy-setuptools,
+  python3-pytest ,
+  python3-stem ,
pypy-stem (>= 1.6.0-3.1),
-   pypy-pytest,
pypy-ipaddress
 Standards-Version: 4.1.5
 Vcs-Browser: https://salsa.debian.org/pkg-privacy-team/vanguards

--- a/debian/rules
+++ b/debian/rules
@@ -5,3 +5,6 @@
 
 override_dh_installsystemd:
dh_installsystemd --no-enable --no-start
+
+override_dh_auto_test:
+   dh_auto_test -- --system=custom --test-args='cd {build_dir}; python3 -m 
pytest $(CURDIR)/tests'

… but I'm not sure the "python3" in the dh_auto_test line is right.
"{interpreter}" there is replaced with pypy). This also assumes that
running PyPy at runtime will have identical behaviour as Python 3.x.

Enjoy...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#940992: firefoxdriver: does not work with firefox > 47 at all

[Stefan Tauner]

On Mon, 23 Sep 2019 12:56:48 +0200 Sascha Girrulat 
wrote:
> Hi,
> 
> the error below does not depend to firefox driver. The firefoxdriver ist
> a leftover for older firefox versions. The package documentation[3]
> describes how to enable the geckodriver and there is a bug[1] (#874207)
> filed for firefox too.
> 
> The packge firefoxdriver will be removed with the next update of
> python-selenium in a few days[2].
> 
> Regards
> Sascha
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874207
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939398
> [3] /usr/share/doc/python-selenium/README.Debian

Hi,

[3] is not installed by python3-selenium (nor an equivalent).
The respective NEWS.Debian.gz of python3-selenium refers to that
non-existent README.Debian though.

It basically suggests fetching the binary from
https://github.com/mozilla/geckodriver/releases and install it in a
directory in $PATH. I can confirm that this works on Debian Buster
(python3-selenium 3.14.1+dfsg1-1) with the latest geckodriver (v0.26.0
from 2019-10-12).

What's the purpose of this bug? If it shouldn't be closed, shouldn't it
depend on #874207?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#958860: ITP: golang-layeh-gopus -- gopus is a Go binding for the Opus audio codec

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle 

* Package name: golang-layeh-gopus
  Version : 0.0~git20161224.0ebf989-1
  Upstream Author : 
* URL : https://github.com/layeh/gopus
* License : Unlicense
  Programming Lang: Go
  Description : gopus is a Go binding for the Opus audio codec

 gopus gopus is a Go binding for the Opus (http://www.opus-codec.org/)
 audio codec.  Documentation• API Reference
 (https://godoc.org/layeh.com/gopus)Requirements• cgo• opus
 (http://www.opus-codec.org/) development library (only on platforms
 where the shared library is used)License Public domain Author Tim Cooper
 (tim.coo...@layeh.com)

Dependency of barnard (#958567)

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: Bug#922944: handling symbolic links in webextensions

[Dmitry Smirnov]

On Sunday, 26 April 2020 8:20:28 AM AEST Ximin Luo wrote:
> As I mentioned on firefox bugzilla [1], I have figured out the exact place
> in the firefox code responsible for this issue.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420286

Without looking into the proposed fix, I think there are few reasons not to 
make any alterations:

As much as I like the idea of symlinking resources from webextensions, 
incorporating those resources at build-time make packaged addons less 
fragile. Frequently synlinked Javascript libraries change/break often enough 
on "apt upgrade" and when it happens maintainer have to resort to bundling of 
working versions anyway but not before users experience (and report) 
breakage.

Diverging from upstream may not be desirable. I'm sure Firefox is difficult 
enough to maintain without adding specific logic that have to be tested.

IMHO symlinks sandboxing was done upstream for security reasons. We may not 
fully understand implication of changing this behaviour.

I've already discovered and documented working solution to incorporating 
resources to webextension packages at build time. Updating packages is easy 
enough and should be even possible with binNMUs to refresh their bundled 
resources. That approach might be considered "good enough".

-- 
All the best,
 Dmitry Smirnov.

---

The past is whatever the records and the memories agree upon.
-- George Orwell, 1984


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

Bug#958859: Additionally

[Edmund Biow]

I am using Debian stable, buster, by the way.

Bug#958764: [Python-modules-team] Bug#958764: closed by Scott Kitterman (re: python3-pip: debundled _vendor packaging approach breaks usage of pip in environments)

[Scott Kitterman]

I do have something that might address this, but I'm reluctant to promise 
anything until I test it.

Scott K

Bug#958859: approx update disabled because it can't be updated securely

[y]

Package: approx
Version: 5.10-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I was attempting to update as usual using approx

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

My approx repositories all returned errors.

   * What was the outcome of this action?

I had to update my machine directly without approx.

   * What outcome did you expect instead?

To update and upgrade normally using approx.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.3
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages approx depends on:
ii  adduser  3.118
ii  bzip21.0.6-9.2~deb10u1
ii  curl 7.64.0-4+deb10u1
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libpcre3 2:8.39-12
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  xz-utils 5.2.4-1

approx recommends no packages.

Versions of packages approx suggests:
pn  libconfig-model-approx-perl  

-- Configuration Files:
/etc/approx/approx.conf changed [not included]

-- debconf information:
  approx/port: 

Dear maintaner,

I failed to update normally from approx this morning, I don't know if it is 
some type of temporary glitch.  Here is a snippet from my 'apt update' command:

  404  Not Found [IP: 192.168.22.22 ]
Err:13 http://server:/security buster/updates Release 
  404  Not Found [IP: 192.168.22.22 ]
Err:14 http://server:/debian buster-updates Release
  404  Not Found [IP: 192.168.22.22 ]

At the end of the output I got a bit of this:

E: The repository 'http://server:/debian buster Release' does not have a 
Release file.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration 
details.
E: The repository 'http://server:/security buster/updates Release' does not 
have a Release file.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.

I'd enabled logging in my /etc/approx/approx.conf so here is a snippet of my 
daemon.log:

4/25/20 3:06 PM server  systemd[1]  Started caching proxy server for Debian 
archive files (192.168.22.22:39730).
4/25/20 3:06 PM server  approx[4760]Connection from :::192.168.22.22 
port 39730
4/25/20 3:06 PM server  approx[4760]Request: GET 
/debian/dists/buster/InRelease
4/25/20 3:06 PM server  approx[4760]  Host: server:
4/25/20 3:06 PM server  approx[4760]  Cache-Control: max-age=0
4/25/20 3:06 PM server  approx[4760]  Accept: text/*
4/25/20 3:06 PM server  approx[4760]  User-Agent: Debian APT-HTTP/1.3 
(1.8.2)
4/25/20 3:06 PM server  approx[4760]  last modified: Sat, 08 Feb 2020 
11:10:51 GMT
4/25/20 3:06 PM server  approx[4760]  last verified: Fri, 24 Apr 2020 
07:05:35 GMT
4/25/20 3:06 PM server  approx[4760]  => cache miss
4/25/20 3:06 PM server  approx[4760]open: Permission denied 
(debian/dists/buster/InRelease.hint)
4/25/20 3:06 PM server  approx[4760]
http://mirrors.kernel.org/debian//dists/buster/InRelease: download error
4/25/20 3:06 PM server  approx[4760]Connection from :::192.168.22.22 
port 39730
4/25/20 3:06 PM server  approx[4760]Request: GET 
/security/dists/buster/updates/InRelease
4/25/20 3:06 PM server  approx[4760]  Host: server:
4/25/20 3:06 PM server  approx[4760]  Cache-Control: max-age=0
4/25/20 3:06 PM server  approx[4760]  Accept: text/*
4/25/20 3:06 PM server  approx[4760]  User-Agent: Debian APT-HTTP/1.3 
(1.8.2)
4/25/20 3:06 PM server  approx[4760]  last modified: Tue, 21 Apr 2020 
13:44:35 GMT
4/25/20 3:06 PM server  approx[4760]  last verified: Fri, 24 Apr 2020 
07:05:35 GMT
4/25/20 3:06 PM server  approx[4760]  => cache miss
4/25/20 3:06 PM server  approx[4760]open: Permission denied 
(security/dists/buster/updates/InRelease.hint)
4/25/20 3:06 PM server  approx[4760]
http://security.debian.org/debian-security/dists/buster/updates/InRelease: 
download error

Hopefully it is a temporary artifact caused by some sort of syncing going on 
somewhere, has anyone else had a similar issue?

Fealty,

Bug#949129: modemmanager: vcs-git outdated

[Martin]

Control: tag -1 pending
Control: retitl -1 modemmanager: vcs-git outdated

modemmanager, libmbim, and libqmi are now at:

https://salsa.debian.org/debian/modemmanager
https://salsa.debian.org/debian/libmbim
https://salsa.debian.org/debian/libqmi

Bug#919557: Bug#922944: #922944: handling symbolic links in webextensions

[Ximin Luo]

CC bug 919557 & interested parties
CC firefox Debian maintainer

As I mentioned on firefox bugzilla [1], I have figured out the exact place in 
the firefox code responsible for this issue.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420286

Near the bottom of ExtensionProtocolHandler::NewStream in 
netwerk/protocol/res/ExtensionProtocolHandler.cpp we have: 

|   bool isResourceFromExtensionDir = false;
|   MOZ_TRY(extensionDir->Contains(requestedFile, &isResourceFromExtensionDir));
|   if (!isResourceFromExtensionDir) {
| bool isAllowed;
| MOZ_TRY_VAR(isAllowed, AllowExternalResource(extensionDir, 
requestedFile));
| if (!isAllowed) {
|   LogExternalResourceError(extensionDir, requestedFile);
|   return Err(NS_ERROR_FILE_ACCESS_DENIED);
| }
|   }

The sledgehammer fix (A) to this problem is to simply remove this piece of 
code. I did not look closely at the surrounding code, but it is possible this 
also applies for user-loaded extensions, in which case if we take this option, 
users could shoot themselves in the foot by loading a malicious extension that 
can then read from /home or something.

A more nuanced fix (B) would be:

In ExtensionProtocolHandler::AllowExternalResource, in the same file:

|   if (!mozilla::IsDevelopmentBuild()) {
| return false;
|   }
| 
|   // On Mac and Linux unpackaged dev builds, system extensions use
|   // symlinks to point to resources in the repo dir which we have to
|   // allow loading. Before we allow an unpacked extension to load a
|   // resource outside of the extension dir, we make sure the extension
|   // dir is within the app directory.
|   bool result;
|   MOZ_TRY_VAR(result, AppDirContains(aExtensionDir));
|   if (!result) {
| return false;
|   }

Drop the first "if (!mozilla::IsDevelopmentBuild())" (since it bypasses the 
rest of the function), and then in ExtensionProtocolHandler::AppDirContains:

| MOZ_TRY(NS_GetSpecialDirectory(NS_GRE_DIR, getter_AddRefs(mAppDir)));

We would simply replace this line with a hard-coded /usr/share/webext. On 
Debian NS_GRE_DIR is /usr/lib/firefox and AFAICT no extensions are installed 
here anyway, so there is no need to keep the existing check.

It would be good to know the firefox maintainer's opinion on this.

X

Dmitry Smirnov:
> On Wed, 21 Aug 2019 19:32:26 +0200 Bruno Kleinert  wrote:
>> I've got an ITP ticket open for keepassxc-browser [1] waiting to be
>> processed in the NEW packages queue. It's also affected by the reported
>> behavior, because I replaced code copies by symbolic links to files in
>> existing debian packages. My intention is to reduce the burden of the
>> security team by avoiding code copies.
>>
>> [...]
>>
>> I searched the web for a solution without success. Guidance for package
>> maintainers of web extensions with symbolic links is highly
>> appreciated.
> 
> I've stumbled upon the issue with symlinks with "form-history-control" 
> package. Under new Firefox rule, extensions should bundle everything they 
> need without using links to files outside of the extension directory. This 
> effectively makes webextentions an equivalent of statically linked binaries.
> 
> The way to handle such situation is to Build-Depend on required packages and 
> copy their resources into webextension directory. Every dependency that we 
> borrow resources from should be noted in "Built-Using" field.
> 
> This is how I have implemented this (not entirely satisfying) solution for 
> the "form-history-control" package:
> 
>   https://salsa.debian.org/webext-team/form-history-control/commit/98b0a3ab
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#958858: golang-github-docker-docker-dev: Please install library k8s.io/klog in golang-github-docker-docker-dev

[Dmitry Smirnov]

Control: tags -1 wontfix

On Sunday, 26 April 2020 7:56:17 AM AEST Reinhard Tartler wrote:
> I'm trying to update the packge golang-github-openshift-imagebuilder and
> the package build fails with this failure:

I think "golang-github-openshift-imagebuilder" should use its own vendored 
"k8s.io/klog".


> I saw that the library is available in the source package src:docker.io,
> and should be easy to get installed into golang-github-docker-docker-dev.

It is not up to Docker to provide 3rd party libraries.


> Please let me know if you have any concerns with this approach.

Docker is one of the worst in regards to versioning and vendoring.
I don't trust Docker the slightest to provide "k8s.io/klog".

My other concern is about additional maintenance burden to otherwise very 
difficult package.

Also "imagebuilder" might FTBFS when built against whatever is vendored by 
Docker.

-- 
Cheers,
 Dmitry Smirnov.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill


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

Bug#958811: exec: "runc": executable file not found in $PATH

[Dmitry Smirnov]

On Sunday, 26 April 2020 12:14:25 AM AEST Tomas Janousek wrote:
> Debian installs runc as /usr/sbin/runc, and regular users don't have
> /usr/sbin in $PATH, so "buildah run" without "--runtime /usr/sbin/runc"
> fails:
> 
> $ buildah run debian-working-container -- sh
> error running container: error creating container for [/bin/sh]: :
> exec: "runc": executable file not found in $PATH ERRO exit status 1

Interesting. Thanks. Perhaps we should hard-code path to "runc" in "util/
types.go". 

Documentation suggests to set path to runtime in the BUILDAH_RUNTIME 
environment variable:

  export BUILDAH_RUNTIME=/usr/bin/crun


With cgroups_v2 You should be able to use "crun" instead of "runc".
"crun" is the first alternative that is expected to work "out of the box".


> I'd expect this to work out of the box.

I'm not sure it can be done because of requirement to set 
"kernel.unprivileged_userns_clone=1".

-- 
All the best,
 Dmitry Smirnov.

---

It has become appallingly obvious that our technology has exceeded our 
humanity.
-- Albert Einstein


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

Bug#958559: debian-kernel-handbook: document how to verify authenticity of git sources

[Ben Hutchings]

On Thu, 2020-04-23 at 19:30 +0200, Christoph Anton Mitterer wrote:
[...]
> It would be nice if the handbook tells people how to verify their
> repos by proper git means, i.e. verify signautres on tags.

Yes, definitely.

> At least for (2), Linus signs the tags, and the Debian kernel source
> package contains Linus' and Greg's keys, so a user could at least
> quite simply verify everything up to and including the repective tag.
>
>
> For the (1) I guess you guys don't use signatures, though. :-/

All but 2 of the tags we've made since converting from Subversion to
git are signed.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Bug#958858: golang-github-docker-docker-dev: Please install library k8s.io/klog in golang-github-docker-docker-dev

[Reinhard Tartler]

Package: golang-github-docker-docker-dev
Severity: normal

I'm trying to update the packge golang-github-openshift-imagebuilder and the
package build fails with this failure:

   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 
github.com/openshift/imagebuilder 
github.com/openshift/imagebuilder/cmd/imagebuilder 
github.com/openshift/imagebuilder/dockerclient 
github.com/openshift/imagebuilder/dockerfile/command 
github.com/openshift/imagebuilder/dockerfile/parser 
github.com/openshift/imagebuilder/imageprogress 
github.com/openshift/imagebuilder/signal 
github.com/openshift/imagebuilder/strslice
src/github.com/openshift/imagebuilder/dockerclient/archive.go:19:2: cannot find 
package "k8s.io/klog" in any of:
/usr/lib/go-1.14/src/k8s.io/klog (from $GOROOT)

/src/golang-github-openshift-imagebuilder/obj-x86_64-linux-gnu/src/k8s.io/klog 
(from $GOPATH)

I saw that the library is available in the source package src:docker.io, and
should be easy to get installed into golang-github-docker-docker-dev.

Please let me know if you have any concerns with this approach.

Best,
-rt


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages golang-github-docker-docker-dev depends on:
pn  golang-dbus-dev 
pn  golang-github-appc-cni-dev  
pn  golang-github-azure-go-ansiterm-dev 
pn  golang-github-burntsushi-toml-dev   
pn  golang-github-containerd-continuity-dev 
pn  golang-github-containerd-fifo-dev   
pn  golang-github-containernetworking-plugins-dev   
pn  golang-github-deckarep-golang-set-dev   
pn  golang-github-docker-distribution-dev   
pn  golang-github-docker-docker-credential-helpers-dev  
pn  golang-github-docker-go-connections-dev 
pn  golang-github-docker-go-events-dev  
pn  golang-github-docker-go-metrics-dev 
pn  golang-github-docker-go-units-dev   
pn  golang-github-docker-libkv-dev  
pn  golang-github-fsnotify-fsnotify-dev 
pn  golang-github-gogo-protobuf-dev 
pn  golang-github-gorilla-mux-dev   
pn  golang-github-hashicorp-memberlist-dev  
pn  golang-github-hashicorp-serf-dev
pn  golang-github-ishidawataru-sctp-dev 
pn  golang-github-mattn-go-shellwords-dev   
pn  golang-github-morikuni-aec-dev  
pn  golang-github-opencontainers-go-digest-dev  
pn  golang-github-opencontainers-image-spec-dev 
pn  golang-github-opencontainers-runc-dev   
pn  golang-github-opencontainers-selinux-dev
pn  golang-github-opentracing-opentracing-go-dev
pn  golang-github-pkg-errors-dev
pn  golang-github-seccomp-libseccomp-golang-dev 
pn  golang-github-sirupsen-logrus-dev   
pn  golang-github-stretchr-testify-dev  
pn  golang-github-tchap-go-patricia-dev 
pn  golang-github-tonistiigi-fifo-dev   
pn  golang-github-vishvananda-netlink-dev   
pn  golang-github-vishvananda-netns-dev 
pn  golang-golang-x-net-dev 
pn  golang-golang-x-sys-dev 
pn  golang-google-grpc-dev  
pn  golang-gopkg-check.v1-dev   

golang-github-docker-docker-dev recommends no packages.

golang-github-docker-docker-dev suggests no packages.

Bug#958857: ITP: python-injector -- Python dependency injection framework

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-injector
  Version : 0.18.3
  Upstream Author : Alec Thomas, Google Inc.
* URL : https://github.com/alecthomas/injector
* License : BSD-3-clause
  Programming Lang: Python
  Description : Python dependency injection framework

 While dependency injection is easy to do in Python due to its support
 for keyword arguments, the ease with which objects can be mocked and its
 dynamic nature, a framework for assisting in this process can remove a
 lot of boiler-plate from larger applications.
 .
 That's where Injector can help. It automatically and transitively
 provides dependencies for you. As an added benefit, Injector encourages
 nicely compartmentalised code through the use of :ref:modules .
 .
 This package is directly needed as a dependency of the to-be-uploaded
 package gwe (GreenWithEnvy).

Bug#958852: texlive-base/extra breaks jupyter-sphinx-theme autopkgtest: Builder name pickle not registered or available through entry point

[Hilmar Preuße]

Am 25.04.2020 um 22:10 teilte Paul Gevers mit:

Hi Paul,

> With recent uploads of texlive-base and texlive-extra the autopkgtest of
> jupyter-sphinx-theme fails in testing when that autopkgtest is run with
> the binary packages of texlive-base and texlive-extra from unstable. It
> passes when run with only packages from testing. In tabular form:
> 
I'm not 100% sure if it is the fault of TL 2020. Please note that at the
same time sphinx 2.4.3 was uploaded. And you'll notice that the last
successful run was w/ sphinx 1.8.5, meanwhile it fails w/ sphinx 2.4.3.

Hence I suspect an incompatibility of jupyter-sphinx-theme & sphinx,
which is quite unrelated to TeX Live.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#958764: closed by Scott Kitterman (re: python3-pip: debundled _vendor packaging approach breaks usage of pip in environments)

[Paul Ivanov]

Thanks for looking into this, Scott!

> Maintaining symlink farms is inherently difficult and unreliable.  Debian 
> used 
> to use a similar approach to support multiple python2 versions and it never 
> worked well.  I would be reluctant to use such an approach.

Ok, makes sense.

> I checked with a pip upstream developer on IRC and his view is that what pipx 
> is doing is not supported by upstream:
>
> >  dstufft: If an program external to pip tries to use one of pip's
> > vendored libraries directsly (e.g. from pip._vendor.six import iteritems)
> > this won't work on Debian because we don't put the wheels in the pip
> > package tree (they are in /usr/share/python-wheels).  From your point of
> > view upstream, if another package is doing such a thing are they
> > unreasonably mucking about in pip internals and if it breaks it's their
> > problem or is it something reasonable that they should be able to rely on
> > and we should try to support?
> >  ScottK: upstrem does not support people importing pip internals
> > /vendored libs 
> >  we moved *everything* into a _ directory just to make this obvious

Pipx is not importing pip internals. Pipx is simply using pip.
The way pipx is doing this is by adding the site-packages of a
working pip installation in it's ~/.local/pipx/shared folder to
the sys.path of the environments that it manages in various
~/.local/pipx/venvs folders

Pipx is trying to save from having a copy of pip in each of its
venvs. This works if the pip on the path is the  wheel as
published on PyPI, or as the vendored code with the debundled
wheels in the  pip/_vendor directory, with the debundled wheels
in the pip/_vendor directory. But this does not work with the
logic patched in Debian's packaging that points the debundled
wheels to the sys.prefix + "/share/python-wheels" , because the
sys.prefix for each of the venvs is different and will not have
copies of the vendored code.

So the question to follow up with Donald and PyPA folks is
something like: "should pip be usable by adding the site packages
of a working installation to the sys.path of another
environment?" And similarly, "should a repackaged pip wheel work
standalone" - because the pip wheel in /usr/share/python-wheels
cannot be used the same way as a regular pip wheel, it is not
standalone, and it requires making the debundled wheels which are
assumed to be on the sys.prefix + share/python-wheels

> It may be that this pipx bug is only apparent on Debian and its derivatives 
> because we rely on the pip unbundle logic, but what pipx is doing is 
> unsupported upstream, so I don't think we can support it either.

Again, I believe it's the additional modification to the unbundle
logic, namely that the vendored wheels will be in sys.prefix +
share/python-wheels directory *instead* of the pip/_vendor
directory that is causing this behaviour.

> Sorry I didn't have a more positive answer.

I appreciate that, thank you for your time and efforts.

best,
pi

Bug#958845: false positive wildcard-matches-nothing-in-dep5-copyright

[Chris Lamb]

Hi Jörg,

> at simutrans I get lintian info:
> 
> wildcard-matches-nothing-in-dep5-copyright simutrans/font/m+10r.bdf (paragraph
> at line 60)

I can't 100% confirm, but this appears to be nondeterminstic on my
local machine. I have no good idea how that is possible, which adds to
my uncertainty, however.

I seem to recall a similar bug report but cannot appear to locate it
right now.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#947464: buster-pu: gnome-maps/3.30.3.1-1+deb10u1

[Phil Wyett]

On Sat, 2020-04-25 at 20:35 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2020-04-23 at 13:10 +0100, Phil Wyett wrote:
> > On Thu, 2020-04-23 at 12:47 +0100, Adam D. Barratt wrote:
> > > On Thu, 2020-04-23 at 06:11 +0100, Phil Wyett wrote:
> > > > On Wed, 2020-04-22 at 21:50 +0100, Adam D. Barratt wrote:
> > > > > +gnome-maps (3.30.3.1-1+deb10u1) buster; urgency=medium
> > > > > 
> > > > > That version number would be the first stable update to
> > > > > 3.30.3.1-
> > > > > 1. 
> > > > > As this is a new upstream version, 3.30.3.1-0+deb10u1 is a
> > > > > commonly
> > > > > used pattern.
> > > > > Did you see my comment regarding version numbers?
> > > 
> > > Regards,
> > > 
> > > Adam
> > > 
> > 
> > Yes, I saw the comment regarding version number pattern.
> > 
> 
> Please feel free to upload with the version number suggested earlier
> in
> the discussion.
> 
> Regards,
> 
> Adam
> 

Hi,

Sorry for the error and attaching to another of my packages.

Attaching debdiff to this, the correct bug for clarity.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B

diff -Nru gnome-maps-3.30.3/debian/changelog gnome-maps-3.30.3.1/debian/changelog
--- gnome-maps-3.30.3/debian/changelog	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/changelog	2019-12-27 09:52:18.0 +
@@ -1,3 +1,14 @@
+gnome-maps (3.30.3.1-0+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release
+- Make the shape layer renderer use the tile size specified in the dynamic 
+  service file, fixing an issue with misaligned shape layer (GeoJSON, GPX, 
+  KML) rendering with the new 512 pixel tile
+- Update Icelandic translation
+
+ -- Phil Wyett   Fri, 27 Dec 2019 09:52:18 +
+
 gnome-maps (3.30.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gnome-maps-3.30.3/debian/control gnome-maps-3.30.3.1/debian/control
--- gnome-maps-3.30.3/debian/control	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/control	2019-12-27 09:52:18.0 +
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Jeremy Bicha , Tim Lunn 
+Uploaders: Jeremy Bicha , Michael Biebl , Tim Lunn 
 Build-Depends: debhelper (>= 11),
geoclue-2.0 (>= 0.12.99),
gjs (>= 1.50.0),
diff -Nru gnome-maps-3.30.3/debian/gbp.conf gnome-maps-3.30.3.1/debian/gbp.conf
--- gnome-maps-3.30.3/debian/gbp.conf	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/gbp.conf	2019-12-27 09:52:18.0 +
@@ -1,14 +1,14 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/buster
+upstream-branch = upstream/3.30.3.1
 upstream-vcs-tag = v%(version)s
 
 [buildpackage]
 sign-tags = True
 
 [import-orig]
-postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
+#postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
 
 [pq]
 patch-numbers = False
diff -Nru gnome-maps-3.30.3/meson.build gnome-maps-3.30.3.1/meson.build
--- gnome-maps-3.30.3/meson.build	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/meson.build	2019-05-21 22:18:49.0 +0100
@@ -1,5 +1,5 @@
 project('gnome-maps', 'c',
-	version: '3.30.3',
+	version: '3.30.3.1',
 	license: 'GPL2+'
 )
 
diff -Nru gnome-maps-3.30.3/NEWS gnome-maps-3.30.3.1/NEWS
--- gnome-maps-3.30.3/NEWS	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/NEWS	2019-05-21 22:18:49.0 +0100
@@ -1,3 +1,18 @@
+3.30.3.1 - May 21, 2019
+=
+
+Changes since 3.30.3
+ - Make the shape layer renderer use the tile size specified in the dynamic
+   service file, fixing an issue with misaligned shape layer (GeoJSON, GPX, KML)
+   rendering with the new 512 pixel tiles
+
+Added/updated/fixed translations
+ - Icelandic
+
+All contributors to this release
+Marcus Lundblad 
+Sveinn í Felli 
+
 3.30.3 - Dec 10, 2018
 =
 
diff -Nru gnome-maps-3.30.3/po/is.po gnome-maps-3.30.3.1/po/is.po
--- gnome-maps-3.30.3/po/is.po	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/po/is.po	2019-05-21 22:18:49.0 +0100
@@ -1,13 +1,13 @@
 # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE package.
 #
-# Sveinn í Felli , 2015, 2017, 2018.
+# Sveinn í Felli , 2015, 2017, 2018, 2019.
 msgid ""
 msgstr ""
 "Project-Id-Version: \n"
 "Report-Msgid-Bugs-To: https://gitlab.gnome.org/GNOME/gnome-maps/issues\n";
-"POT-Creation-Date: 2018-06-25 00:22+\n"
-"PO-Revision-Date: 2018-08-17 13:36+\n"
+"POT-Creation-Date: 2018-09-15 21:17+\n"
+"PO-Revision-Date: 2019-02-21 08:42+\n"
 "Last-Translator: Sveinn í Felli \n"
 "Language-Team: Icelandic \n"
 "Language: is\n"
@@ -15,17 +15,17 @

Bug#953369: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used

[Vincent Lefevre]

Control: tags -1 patch

On 2020-03-09 13:29:52 +0100, Vincent Lefevre wrote:
> On 2020-03-09 00:08:45 +0800, 積丹尼 Dan Jacobson wrote:
> > Setting up python3-apt (1.9.9) ...
> > /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
> > (buffering=1) isn't supported in binary mode, the default buffer size will 
> > be used
> >   self.stdin = io.open(p2cwrite, 'wb', bufsize)
> 
> I also got lots of these warning messages.

The warning was added upstream in the following commit:

  
https://github.com/python/cpython/commit/a2670565d8f5c502388378aba1fe73023fd8c8d4

"bpo-32236: open() emits RuntimeWarning if buffering=1 for binary mode 
(GH-4842)"
fixing upstream bug 32236:
"open() shouldn't silently ignore buffering=1 in binary mode"

This is silly. Such warnings are for developers so that should appear
only in some "debug mode". Otherwise they annoy the end user and they
can break tools where the output is important (e.g. where errors can
be detected only by testing whether there is some output).

I've attached a patch that removes this warning. I've tested it
and I no longer see the warning.

Note that there is a warning with the same message (except
"RuntimeWarning:" I think) in /usr/lib/python3.8/_pyio.py,
but I don't know whether it is worth to remove this one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: python3.8-3.8.2/Modules/_io/_iomodule.c
===
--- python3.8-3.8.2.orig/Modules/_io/_iomodule.c
+++ python3.8-3.8.2/Modules/_io/_iomodule.c
@@ -364,15 +364,6 @@ _io_open_impl(PyObject *module, PyObject
 goto error;
 }
 
-if (binary && buffering == 1) {
-if (PyErr_WarnEx(PyExc_RuntimeWarning,
- "line buffering (buffering=1) isn't supported in "
- "binary mode, the default buffer size will be used",
- 1) < 0) {
-   goto error;
-}
-}
-
 /* Create the Raw file stream */
 {
 PyObject *RawIO_class = (PyObject *)&PyFileIO_Type;

Bug#958856: RFS: tsvtree/1.0-1 [ITP] -- Tool to display and compress TSV data in tree format

[Marcelo Zimbres]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "tsvtree"

 * Package name: tsvtree
   Version : 1.0.3-1
   Upstream Author : Marcelo Zimbres Silva 
 * URL : https://github.com/mzimbres/tsvtree
 * License : GPL-3
 * Vcs : https://github.com/mzimbres/tsvtree
   Section : devel

It builds those binary packages:

  tsvtree - Tool to display and compress TSV data in tree format

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/tsvtree

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tsvtree/tsvtree_1.0.3-1.dsc

Changes since the last upload:

   * Removes unneeded files
   * First steps with the debian pipeline
   * Adds content to the pipeline
   * New upstream version 1.0.3

Regards,

--
  Marcelo Zimbres Silva

Bug#957309: grok: diff for NMU version 1.20110708.1-4.5

[Sudip Mukherjee]

Control: tags 957309 + patch
Control: tags 957309 + pending

Dear maintainer,

I've prepared an NMU for grok (versioned as 1.20110708.1-4.5) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru grok-1.20110708.1/debian/changelog grok-1.20110708.1/debian/changelog
--- grok-1.20110708.1/debian/changelog  2020-01-13 22:12:23.0 +
+++ grok-1.20110708.1/debian/changelog  2020-04-25 20:57:15.0 +0100
@@ -1,3 +1,10 @@
+grok (1.20110708.1-4.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-10. (Closes: #957309)
+
+ -- Sudip Mukherjee   Sat, 25 Apr 2020 20:57:15 
+0100
+
 grok (1.20110708.1-4.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru grok-1.20110708.1/debian/patches/fix_gcc10.patch 
grok-1.20110708.1/debian/patches/fix_gcc10.patch
--- grok-1.20110708.1/debian/patches/fix_gcc10.patch1970-01-01 
01:00:00.0 +0100
+++ grok-1.20110708.1/debian/patches/fix_gcc10.patch2020-04-25 
20:55:43.0 +0100
@@ -0,0 +1,19 @@
+Description: Fix FTBFS with GCC-10
+ Fix multiple definitions of a variable by declaring it as  extern
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957309
+
+---
+
+--- grok-1.20110708.1.orig/conf.tab.c
 grok-1.20110708.1/conf.tab.c
+@@ -77,7 +77,7 @@
+ #include "grok_input.h"
+ #include "grok_matchconf.h"
+ 
+-int yylineno;
++extern int yylineno;
+ void yyerror (YYLTYPE *loc, struct config *conf, char const *s) {
+   fprintf (stderr, "Syntax error: %s\n", s);
+ }
diff -Nru grok-1.20110708.1/debian/patches/series 
grok-1.20110708.1/debian/patches/series
--- grok-1.20110708.1/debian/patches/series 2020-01-13 22:08:30.0 
+
+++ grok-1.20110708.1/debian/patches/series 2020-04-25 20:56:14.0 
+0100
@@ -6,3 +6,4 @@
 fix-gperf-version-detection.patch
 gperf-function-declaration.patch
 move_ldflags.patch
+fix_gcc10.patch

Bug#958855: RFS: grok/1.20110708.1-4.5 [NMU] -- powerful pattern-matching and reacting tool

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "grok"

 * Package name: grok
   Version : 1.20110708.1-4.5
   Upstream Author :
 * URL : http://code.google.com/p/semicomplete/wiki/Grok
 * License : BSD-3-Clause
 * Vcs : http://anonscm.debian.org/gitweb/?p=collab-maint/grok.git
   Section : misc

It builds those binary packages:

  grok - powerful pattern-matching and reacting tool
  libgrok1 - shared libraries for grok
  libgrok-dev - development files for grok
  grok-dbg - debugging symbols for grok

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/grok

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/grok/grok_1.20110708.1-4.5.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS with GCC-10. (Closes: #957309)


-- 
Regards
Sudip

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[John Scott]

On Fri, 24 Apr 2020 23:33:59 -0400 FeRD  wrote:
> Sorry, I realized I might have sent this reply to the wrong bug.
Yes, I sent my mail to both of the bugs (am doing now again, I guess). I am 
also making noise :)

> What version of libopenshot is that result from? The Clang namespacing was
> fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in
> both libopenshot-0.2.4 and libopenshot-0.2.5.
I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm not 
the maintainer; upgrading it is outside of my domain (esp. in light of the 
following).

> That's a merge commit and it touches a bunch of files, but basically all of
> our headers now qualify juce symbols with the juce:: namespace prefix,  and
> the test sources now #define DONT_SET_USING_JUCE_NAMESPACE
> which prevents JUCE from exporting its symbols into the global namespace.
> 
> AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing
> over ambiguous 'UnitTest' symbols. But all this should have been solved
> months ago.
> 
>> I'm uneasy about this and hope that a new release of OpenShot made with
>> the practices described in /usr/share/doc/juce-modules-source/README.Debian
>> will make an elegant solution.
> 
> Is there a copy of that file online somewhere? It's not part of the JUCE
> distribution as far as I can tell, and it's definitely not located at that
> path on my Fedora machine.

Right, I know what'll pull it all together. It seems that the source for 
libopenshot includes embedded code copies of JUCE, and code copies are 
strongly discouraged in Debian, even if they don't make it into the binaries.

That file is a Debian-specific README mostly addressed to developers that says 
to replace bundled copies of JUCE and use the code in package juce-modules-
source instead. This approach seems to have not been taken.

Coincidentally the embedded code copy discussion just came up on debian-devel, 
and if no maintainer objects I'll add this to the 'big list' of embedded code 
copies sometime soonish.

I hope this makes clear the nature of the obstacles ahead.JUCE for Debian
===

upstream's preferred form of usage of JUCE is to include a verbatim copy of all
used JUCE modules in your application.
This is made explicit in the 'Projucer', JUCE's own software project
management workbench, that will copy (or symlink, or include otherwise) the
modules' source code into your project.

# Projucer for Debian

Installing the following packages will give you the 'Projucer' as Debian
packages while keeping your embedded-module-code workflow:
 - juce-tools (contains the Projucer)
 - juce-modules-source (contains the source-code for the JUCE modules)

The 'Projucer' as shipped with Debian has the following modification regarding
the once shipped by upstream:

# Debian packages that depend on JUCE

This is a quick guideline for packaging upstream software that uses JUCE for
Debian.
For further implementation details check out the 'iem-plugin-suite' package.

- Build-Depend on 'juce-modules-source'
- Add 'Built-Using: juce-modules-source (= <>)' to debian/control
  (replace '<>' with the actual version of 'juce-modules-source', as
  obtained with

   dpkg-query --show --showformat='${source:Version}' juce-modules-source


  E.g. dh based packages might use something like the following in debian/rules:

   JUCE_VERSION := $(shell dpkg-query --show --showformat='$${source:Version}' juce-modules-source)
   override_dh_gencontrol:
dh_gencontrol -- -Vjuce:BuiltUsing="juce ( = $(JUCE_VERSION) )"

  Accompanied by the following in the binary package's section in debian/control:

   Built-Using: ${juce:BuiltUsing}

- If needed, dynamically link against the following libraries (as
  "juce-modules-source" does not include their sources (as opposed to upstream):
  - libjpeg
  - libpng
  - libflac
  - libvorbis libvorbisenc libvorbisfile
  - libogg
  - zlib
  E.g. using something like:

   make LDFLAGS="$(pkg-config --libs libpng libjpeg flac vorbis vorbisfile vorbisenc ogg zlib)"

  *Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
  (>=5.4.4~repack0-3) which will take care of adding these libraries (if
  required) to the LinuxMakefile build.

- When compiling for some embedded architectures (notably 'armel', 'mipsel' and
  the like), you might need to link against '-latomic'.
  The following snippet for d/rules can help inject the library on the required
  architectures:

# link with libatomic on architectures without built-in atomic
noatomicarch = $(shell dpkg-architecture -qDEB_HOST_ARCH | egrep -x "(armel|powerpc|powerpcspe|m68k|mips|mipsel|sh4|riscv64)")
ifeq ($(if $(noatomicarch),atomic), atomic)
LDFLAGS += -latomic
endif

  *Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
  (>=5.4.4~repack0-3) which will take care of adding the relevant flags to the
  LinuxMakefile build.

Bug#947102: buster-pu: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Adam D. Barratt]

On Sat, 2020-04-25 at 21:00 +0100, Phil Wyett wrote:
> On Sat, 2020-04-25 at 20:34 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2019-12-26 at 12:31 +, Phil Wyett wrote:
> > > Attached is a debdiff that resolves CVE in package 'filezilla' on
> > > > buster.
> > > > 
> > > > filezilla (3.39.0-2+deb10u1) buster-security; urgency=high
> > > > 
> > > >   * Team Upload
> > > >   * Added: 02_untrusted_search_path.patch - CVE-2019-5429.
> > > > (Closes:
> > > > #928282)
> > > > 

> Attached is debdiff with version changed as suggested/required.
> 

I think that was intended for #947464. In any case, that looks fine,
thanks.

Regards,

Adam

Bug#958854: ITP: golang-github-kennygrant-sanitize -- Package sanitize provides functions for sanitizing text in golang strings.

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle 

* Package name: golang-github-kennygrant-sanitize
  Version : 1.2.4-1
  Upstream Author : Kenny Grant
* URL : https://github.com/kennygrant/sanitize
* License : BSD-3-clause
  Programming Lang: Go
  Description : Package sanitize provides functions for sanitizing text in 
golang strings.

 sanitize GoDoc
 (https://godoc.org/github.com/kennygrant/sanitize) Go Report Card
 (https://goreportcard.com/report/github.com/kennygrant/sanitize) CircleCI
 (https://circleci.com/gh/kennygrant/sanitize) Package sanitize provides
 functions to sanitize html and paths with go (golang).
 .
 FUNCTIONS
 .
 go sanitize.Accents(s string) string
 .
 .
 Accents replaces a set of accented characters with ascii equivalents.
 .
 go sanitize.BaseName(s string) string
 .
 .
 BaseName makes a string safe to use in a file name, producing a sanitized
 basename replacing . or / with -. Unlike Name no attempt is made to
 normalise text as a path.
 .
 go sanitize.HTML(s string) string
 .
 .
 HTML strips html tags with a very simple parser, replace common entities,
 and escape < and > in the result. The result is intended to be used as
 plain text.
 .
 go sanitize.HTMLAllowing(s string, args...[]string) (string, error)
 .
 .
 HTMLAllowing parses html and allow certain tags and attributes from the
 lists optionally specified by args - args[0] is a list of allowed tags,
 args[1] is a list of allowed attributes. If either is missing default
 sets are used.
 .
 go sanitize.Name(s string) string
 .
 .
 Name makes a string safe to use in a file name by first finding the path
 basename, then replacing non-ascii characters.
 .
 go sanitize.Path(s string) string
 .
 .
 Path makes a string safe to use as an url path.  Changes Version 1.2
 .
 Adjusted HTML function to avoid linter warning Added more tests from
 https://githubengineering.com/githubs-post-csp-journey/ Chnaged name of
 license file Added badges and change log to readme
 .
 Version 1.1 Fixed type in comments.  Merge pull request from Povilas
 Balzaravicius Pawka
  - replace br tags with newline even when they contain a space
 .
 Version 1.0 First release

Dependency of barnard (#958567)

Bug#927433: stretch-pu: package gosa/2.7.4+reloaded2-13+deb9u2

[Mike Gabriel]

Hi Adam,

On  Sa 25 Apr 2020 21:25:47 CEST, Adam D. Barratt wrote:


Control: tags -1 + confirmed

Apologies for the delay.

On Sat, 2019-08-10 at 04:17 +0200, Mike Gabriel wrote:

Hi again,

On Fri, 19 Apr 2019 19:53:33 +0200 Mike Gabriel 
wrote:
 > now that we could avoid the full backport of gosa from buster to
stretch
 > (see #927306), the Debian Edu team would still like to introduce
various
 > fixes for gosa to the next Debian 9 point release.
 >
 > Some issues require a fix (RC / important), some are small fixes
here and there that caused people pain and have been resolved in
Debian buster's gosa.
 >

[...]

I was wondering what the state of this stretch-pu request is?

I attached a new .debdiff version for this potential upload, adding
the fix for CVE-2019-11187 (no-dsa issue).


Mostly, it's a lot of changes, so takes longer to look at, and
oldstable review tends to get less priority when there's a reasonable
number of stable changes to get through.

In any case, please go ahead.

Regards,

Adam


thanks so much.

Please take not of an additional CVE (no-dsa) fix via follow-up bug  
#958850 (+deb9u3) (not such a monster as this one).


Thanks+Greets
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgps7qYUCToRY.pgp
Description: Digitale PGP-Signatur

Bug#947102: buster-pu: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

On Sat, 2020-04-25 at 20:34 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2019-12-26 at 12:31 +, Phil Wyett wrote:
> > Attached is a debdiff that resolves CVE in package 'filezilla' on
> > > buster.
> > > 
> > > filezilla (3.39.0-2+deb10u1) buster-security; urgency=high
> > > 
> > >   * Team Upload
> > >   * Added: 02_untrusted_search_path.patch - CVE-2019-5429.
> > > (Closes:
> > > #928282)
> > > 
> > >  -- Phil Wyett   Wed, 18 Dec 2019
> > > 20:25:54
> > > 
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928282
> > > https://security-tracker.debian.org/tracker/CVE-2019-5429
> > > 
> > > Regards
> > > 
> > > Phil
> > > 
> > 
> > Hi,
> > 
> > Updated debdiff. Changed from Team to NMU.
> > 
> 
> Apologies for the delay. Please go ahead.
> 
> Regards,
> 
> Adam
> 

Hi,

Attached is debdiff with version changed as suggested/required.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B

diff -Nru gnome-maps-3.30.3/debian/changelog gnome-maps-3.30.3.1/debian/changelog
--- gnome-maps-3.30.3/debian/changelog	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/changelog	2019-12-27 09:52:18.0 +
@@ -1,3 +1,14 @@
+gnome-maps (3.30.3.1-0+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release
+- Make the shape layer renderer use the tile size specified in the dynamic 
+  service file, fixing an issue with misaligned shape layer (GeoJSON, GPX, 
+  KML) rendering with the new 512 pixel tile
+- Update Icelandic translation
+
+ -- Phil Wyett   Fri, 27 Dec 2019 09:52:18 +
+
 gnome-maps (3.30.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gnome-maps-3.30.3/debian/control gnome-maps-3.30.3.1/debian/control
--- gnome-maps-3.30.3/debian/control	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/control	2019-12-27 09:52:18.0 +
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Jeremy Bicha , Tim Lunn 
+Uploaders: Jeremy Bicha , Michael Biebl , Tim Lunn 
 Build-Depends: debhelper (>= 11),
geoclue-2.0 (>= 0.12.99),
gjs (>= 1.50.0),
diff -Nru gnome-maps-3.30.3/debian/gbp.conf gnome-maps-3.30.3.1/debian/gbp.conf
--- gnome-maps-3.30.3/debian/gbp.conf	2018-12-11 22:58:41.0 +
+++ gnome-maps-3.30.3.1/debian/gbp.conf	2019-12-27 09:52:18.0 +
@@ -1,14 +1,14 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/buster
+upstream-branch = upstream/3.30.3.1
 upstream-vcs-tag = v%(version)s
 
 [buildpackage]
 sign-tags = True
 
 [import-orig]
-postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
+#postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
 
 [pq]
 patch-numbers = False
diff -Nru gnome-maps-3.30.3/meson.build gnome-maps-3.30.3.1/meson.build
--- gnome-maps-3.30.3/meson.build	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/meson.build	2019-05-21 22:18:49.0 +0100
@@ -1,5 +1,5 @@
 project('gnome-maps', 'c',
-	version: '3.30.3',
+	version: '3.30.3.1',
 	license: 'GPL2+'
 )
 
diff -Nru gnome-maps-3.30.3/NEWS gnome-maps-3.30.3.1/NEWS
--- gnome-maps-3.30.3/NEWS	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/NEWS	2019-05-21 22:18:49.0 +0100
@@ -1,3 +1,18 @@
+3.30.3.1 - May 21, 2019
+=
+
+Changes since 3.30.3
+ - Make the shape layer renderer use the tile size specified in the dynamic
+   service file, fixing an issue with misaligned shape layer (GeoJSON, GPX, KML)
+   rendering with the new 512 pixel tiles
+
+Added/updated/fixed translations
+ - Icelandic
+
+All contributors to this release
+Marcus Lundblad 
+Sveinn í Felli 
+
 3.30.3 - Dec 10, 2018
 =
 
diff -Nru gnome-maps-3.30.3/po/is.po gnome-maps-3.30.3.1/po/is.po
--- gnome-maps-3.30.3/po/is.po	2018-12-10 20:50:29.0 +
+++ gnome-maps-3.30.3.1/po/is.po	2019-05-21 22:18:49.0 +0100
@@ -1,13 +1,13 @@
 # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE package.
 #
-# Sveinn í Felli , 2015, 2017, 2018.
+# Sveinn í Felli , 2015, 2017, 2018, 2019.
 msgid ""
 msgstr ""
 "Project-Id-Version: \n"
 "Report-Msgid-Bugs-To: https://gitlab.gnome.org/GNOME/gnome-maps/issues\n";
-"POT-Creation-Date: 2018-06-25 00:22+\n"
-"PO-Revision-Date: 2018-08-17 13:36+\n"
+"POT-Creation-Date: 2018-09-15 21:17+\n"
+"PO-Revision-Date: 2019-02-21 08:42+\n"
 "Last-Translator: Sveinn í Felli \n"
 "Language-Team: Icelandic \n"
 "Language: is\n"
@@ -15,17 +15,17 @@
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=n != 1;\n"
-"X-Generator: Lokalize 1

Bug#958853: anki: Upstream new version

[Alberto Fuentes]

Package: anki
Version: 2.1.15+dfsg-1
Severity: wishlist

Upstream version is 2.1.22. Almost 9 months of fixes :)

Cheers!



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anki depends on:
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-flot   0.8.3+dfsg-1
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libjs-mathjax   2.7.4+dfsg-1
ii  libqt5core5a5.12.5+dfsg-9
ii  python3 3.8.2-3
ii  python3-bs4 4.9.0-1
ii  python3-decorator   4.4.2-2
ii  python3-distro  1.4.0-1
ii  python3-distutils   3.8.2-2
ii  python3-jsonschema  3.0.2-4
ii  python3-markdown3.2.1-1
ii  python3-pyaudio 0.2.11-1.1+b1
ii  python3-pyqt5   5.14.2+dfsg-1+b1
ii  python3-pyqt5.qtwebchannel  5.14.2+dfsg-1+b1
ii  python3-pyqt5.qtwebengine   5.14.0-2+b1
ii  python3-requests2.23.0+dfsg-2
ii  python3-send2trash  1.5.0-2

Versions of packages anki recommends:
ii  python3-matplotlib  3.1.2-2

Versions of packages anki suggests:
pn  dvipng   
ii  lame 3.100-3
ii  mplayer  2:1.3.0-8+b6
ii  mpv  0.32.0-1

-- no debconf information

Bug#958852: texlive-base/extra breaks jupyter-sphinx-theme autopkgtest: Builder name pickle not registered or available through entry point

[Paul Gevers]

Source: texlive-base, jupyter-sphinx-theme, texlive-extra
Control: found -1 texlive-base/2020.20200417-1
Control: found -1 texlive-extra/2020.20200417-1
Control: found -1 jupyter-sphinx-theme/0.0.6+ds1-9
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With recent uploads of texlive-base and texlive-extra the autopkgtest of
jupyter-sphinx-theme fails in testing when that autopkgtest is run with
the binary packages of texlive-base and texlive-extra from unstable. It
passes when run with only packages from testing. In tabular form:

   passfail
texlive-base   from testing2020.20200417-1
texlive-extra  from testing2020.20200417-1
jupyter-sphinx-theme   from testing0.0.6+ds1-9
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of texlive-base and
texlive-extra to testing [1]. Due to the nature of this issue, I filed
this bug report against all three packages. Can you please investigate
the situation and reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
texlive-base/2020.20200417-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=texlive-base

https://ci.debian.net/data/autopkgtest/testing/amd64/j/jupyter-sphinx-theme/5144210/log.gz

* pickle *
make -C demo pickle BUILDDIR=build/build-pickle
make[1]: Entering directory
'/tmp/autopkgtest-lxc.c4x56q58/downtmp/autopkgtest_tmp/examples/demo'
sphinx-build -b pickle -d build/build-pickle/doctrees   source
build/build-pickle/pickle
Running Sphinx v2.4.3

Sphinx error:
Builder name pickle not registered or available through entry point
make[1]: *** [Makefile:64: pickle] Error 2
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.c4x56q58/downtmp/autopkgtest_tmp/examples/demo'
make: *** [Makefile:51: build-demo] Error 2
autopkgtest [19:21:54]: test perform-demo: ---]



signature.asc
Description: OpenPGP digital signature

Bug#958849: jed-extra: New version of my po_mode available

[Morten Bo Johansen]

Package: jed-extra
Version: 2.5.7-2
Severity: wishlist

Dear Maintainer,

I have made a new version of the po_mode for Jed. It may be
downloaded from http://mbjnet.dk/po_mode/po_mode.tar.gz

I should be grateful if you'd include it in the jed-extra
package at your earliest convenience.

Thanks,
Morten

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=da_DK.utf-8, LC_CTYPE=da_DK.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to da_DK.utf-8), LANGUAGE=da_DK.utf-8 (charmap=UTF-8) (ignored: LC_ALL set 
to da_DK.utf-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

jed-extra depends on no packages.

Versions of packages jed-extra recommends:
pn  jed | xjed  
ii  slsh2.3.2-4

Versions of packages jed-extra suggests:
ii  a2ps1:4.14-5
ii  chromium [www-browser]  81.0.4044.92-1
ii  dict1.12.1+dfsg-8+b1
ii  edbrowse [www-browser]  3.7.6-1+b1
ii  elinks [www-browser]0.13.1-1
ii  firefox [www-browser]   70.0-1
ii  install-info6.7.0.dfsg.2-5
ii  lynx [www-browser]  2.9.0dev.5-1
ii  slang-curl  0.2.1-6
ii  slang-expat 0.5.0-3+b1
ii  slang-gdbm  1.7.1-7+b1
ii  slang-sqlite0.4.0-4+b1
ii  slang-wildcard  0.5.0-3+b1
ii  w3m [www-browser]   0.5.3-37+b1

Bug#958851: initramfs-tools: autopkgtest needs update for new version of shellcheck: SC2086: Double quote to prevent globbing and word splitting.

[Paul Gevers]

Source: initramfs-tools
Version: 0.136
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, shellch...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:shellcheck

Dear maintainer(s),

With a recent upload of shellcheck the autopkgtest of initramfs-tools
fails in testing when that autopkgtest is run with the binary packages
of shellcheck from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
shellcheck from testing0.7.1-1
initramfs-toolsfrom testing0.136
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of shellcheck to
testing [1]. Of course, shellcheck shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
shellcheck was intended and your package needs to update to the new
situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from shellcheck should really
add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=shellcheck

https://ci.debian.net/data/autopkgtest/testing/amd64/i/initramfs-tools/5145819/log.gz

autopkgtest [21:50:34]: test shellcheck: [---

In /usr/share/initramfs-tools/init line 227:
sleep $ROOTDELAY
  ^^ SC2086: Double quote to prevent globbing and
word splitting.

Did you mean:
sleep "$ROOTDELAY"


In /usr/sbin/update-initramfs line 176:
run-parts --arg=${version} --arg=${initramfs} \
^^ SC2086: Double quote to
prevent globbing and word splitting.

Did you mean:
run-parts --arg="${version}" --arg=${initramfs} \


In /usr/share/initramfs-tools/scripts/functions line 393:
logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -V -t 
"$TYPE" "$DEV"
  ^^ SC2086:
Double quote to prevent globbing and word splitting.

Did you mean:
logsave -a -s $FSCK_LOGFILE fsck $spinner "$force" $fix -V -t 
"$TYPE"
"$DEV"


In /usr/share/initramfs-tools/scripts/functions line 398:
logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t 
"$TYPE" "$DEV"
  ^^ SC2086:
Double quote to prevent globbing and word splitting.

Did you mean:
logsave -a -s $FSCK_LOGFILE fsck $spinner "$force" $fix -T -t 
"$TYPE"
"$DEV"

For more information:
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent
globbing ...
autopkgtest [21:50:38]: test shellcheck: ---]



signature.asc
Description: OpenPGP digital signature

Bug#958850: stretch-pu: package gosa/2.7.4+reloaded2-13+deb9u3

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

this is a follow-up for #927433 (about +deb9u2).

+  * debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_
+encode+json_decode.patch:
++ Replace (un)serialize with json_encode/json_decode to mitigate PHP object
+  injection (CVE-2019-14466).

Since I last uploaded the stretch-pu of gosa, one more CVE issue got
known and already addressed in the Git branch.

I will follow-up with a +deb9u3 upload on the +deb9u2 upload. Luckily,
this one is not as massive as the +deb9u2 one.

Greets,
Mike


-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gosa-2.7.4+reloaded2/debian/changelog 
gosa-2.7.4+reloaded2/debian/changelog
--- gosa-2.7.4+reloaded2/debian/changelog   2019-04-19 19:03:52.0 
+0200
+++ gosa-2.7.4+reloaded2/debian/changelog   2020-04-25 21:51:15.0 
+0200
@@ -1,3 +1,12 @@
+gosa (2.7.4+reloaded2-13+deb9u3) stretch; urgency=medium
+
+  * debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_
+encode+json_decode.patch:
++ Replace (un)serialize with json_encode/json_decode to mitigate PHP object
+  injection (CVE-2019-14466).
+
+ -- Mike Gabriel   Sat, 25 Apr 2020 21:51:15 +0200
+
 gosa (2.7.4+reloaded2-13+deb9u2) stretch; urgency=medium
 
   [ Mike Gabriel ]
diff -Nru 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_encode+json_decode.patch
 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_encode+json_decode.patch
--- 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_encode+json_decode.patch
1970-01-01 01:00:00.0 +0100
+++ 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_encode+json_decode.patch
2020-04-25 21:50:26.0 +0200
@@ -0,0 +1,47 @@
+From e1504e9765db2adde8b4685b5c93fbba57df868b Mon Sep 17 00:00:00 2001
+From: Fabian Henneke 
+Date: Mon, 29 Jul 2019 15:54:29 +0200
+Subject: [PATCH] Replace (un)serialize with json_encode/json_decode
+
+---
+ gosa-core/html/index.php | 4 ++--
+ gosa-core/html/main.php  | 6 +++---
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/gosa-core/html/index.php
 b/gosa-core/html/index.php
+@@ -338,9 +338,9 @@
+ if(isset($_COOKIE['GOsa_Filter_Settings']) || 
isset($HTTP_COOKIE_VARS['GOsa_Filter_Settings'])) {
+ 
+ if(isset($_COOKIE['GOsa_Filter_Settings'])) {
+-$cookie_all = 
unserialize(base64_decode($_COOKIE['GOsa_Filter_Settings']));
++$cookie_all = 
json_decode(base64_decode($_COOKIE['GOsa_Filter_Settings']));
+ }else{
+-$cookie_all = 
unserialize(base64_decode($HTTP_COOKIE_VARS['GOsa_Filter_Settings']));
++$cookie_all = 
json_decode(base64_decode($HTTP_COOKIE_VARS['GOsa_Filter_Settings']));
+ }
+ if(isset($cookie_all[$ui->dn])) {
+ $cookie = $cookie_all[$ui->dn];
+--- a/gosa-core/html/main.php
 b/gosa-core/html/main.php
+@@ -480,9 +480,9 @@
+ $cookie = array();
+ 
+ if(isset($_COOKIE['GOsa_Filter_Settings'])){
+-  $cookie = unserialize(base64_decode($_COOKIE['GOsa_Filter_Settings']));
++  $cookie = json_decode(base64_decode($_COOKIE['GOsa_Filter_Settings']));
+ }elseif(isset($HTTP_COOKIE_VARS['GOsa_Filter_Settings'])){
+-  $cookie = 
unserialize(base64_decode($HTTP_COOKIE_VARS['GOsa_Filter_Settings']));
++  $cookie = 
json_decode(base64_decode($HTTP_COOKIE_VARS['GOsa_Filter_Settings']));
+ }
+ 
+ /* Save filters? */
+@@ -496,7 +496,7 @@
+   if(isset($_GET['plug'])){
+ $cookie[$ui->dn]['plug'] = $_GET['plug'];
+   }
+-  @setcookie("GOsa_Filter_Settings",base64_encode(serialize($cookie)),time() 
+ (60*60*24));
++  
@setcookie("GOsa_Filter_Settings",base64_encode(json_encode($cookie)),time() + 
(60*60*24));
+ }
+ 
+ /* Show page... */
diff -Nru 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-2_replace_unserialize_with_json_encode+json_decode.patch
 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-2_replace_unserialize_with_json_encode+json_decode.patch
--- 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-14466-2_replace_unserialize_with_json_encode+json_decode.patch
1970-01-01 01:00:00.0 +0100
+++ 
gosa-2.7.4+reloaded2/debian/patches/1047_CVE-2019-1

Bug#947142: buster-pu: package python-oslo.utils/3.36.4-2 CVE-2019-3866

[Adam D. Barratt]

Control: tags -1 + confirmed

Apologies for the delay.

On Sat, 2019-12-21 at 22:13 +0100, Thomas Goirand wrote:
> I'd like to update python-oslo.utils in Buster to address CVE-2019-
> 3866.
> It wasn't possible to apply directly the patch available here:
> 
> https://review.opendev.org/692972
> 
> and I found too dangerous to skip the commits right before it, which
> are related to this patch. So I just merged upstream branch
> stable/rocky into the Debian package. However, looking closer to all
> patches, either they are all related to the official patch, or are
> cosmetic from the Debian perspective (ie: .gitreview, or upstream CI
> related).
> 
> Please find, attached to this bug, the debdiff for the udpate.
> 

+python-oslo.utils (3.36.4+2019.11.15.git.c49a426b66-1+deb10u1) buster;
urgency=medium

I'd prefer -0+deb10u1 there, as there was (I presume) never a -1 upload
to Debian.

With that change, please go ahead.

Regards,

Adam

Bug#958846: ITP: python-rx -- Reactive Extensions for Python

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-rx
  Version : 3.1.0
  Upstream Author : Microsoft Open Technologies, Inc.
* URL : https://github.com/ReactiveX/RxPY
* License : Apache-2.0
  Programming Lang: Python
  Description : Reactive Extensions for Python

 This package contains a set of libraries for composing asynchronous and
 event-based programs using observable sequences and LINQ-style query
 operators in Python. Using Rx, developers represent asynchronous data
 streams with Observables, query asynchronous data streams using
 operators, and parameterize concurrency in data/event streams using
 Schedulers.
 .
 This package is packaged as a direct dependency of GWE (GreenWithEnvy)
 an NVidia card tweaking utility.

Bug#958848: pytest (build-)depends on pypy-funcsigs which the maintainer would like to get rid of.

[peter green]

Package: pytest
Version: 4.6.9-3
x-debbugs-cc: vangua...@packages.debian.org

As discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937769 the 
maintainer of the python-funcsigs source package (which builds the 
python-funcsigs, python3-funcsigs and pypy-funcsigs binary packages) would like 
to get rid of the python-funcsigs source package completely rather than simply 
removing cpython 2 support from it.

pypy-pytest depends on and the pytest source package build-depends on the 
pypy-funcsigs package. I am assuming that removing the dependency on this 
package would mean dropping the pypy-pytest binary package.

checking reverse dependencies with dak reveals.

# Broken Build-Depends:
python-atomicwrites: pypy-pytest
python-pluggy: pypy-pytest
python-py: pypy-pytest
setuptools-scm: pypy-pytest
vanguards: pypy-pytest
wcwidth: pypy-pytest

most of these seem to be python module packages that are maintained by the 
python modules team and build pypy modules to directly or indirectly support 
pypy-pytest.

vanguards on the other hand is an application which I assume relies on pytest 
for it's testsuite.

So I guess the question is whether it is worth keeping this pile of pypy 
modules around to support the testsuite of one application?

Bug#958847: ITP: golang-github-bmmcginty-go-openal -- OpenAL bindings for Go.

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle 

* Package name: golang-github-bmmcginty-go-openal
  Version : 0.0~git20190816.d96453c-1
  Upstream Author : Brandon McGinty-Carroll
* URL : https://github.com/bmmcginty/go-openal
* License : BSD-2-clause
  Programming Lang: Go
  Description : OpenAL bindings for Go.

 OpenAL bindings for Go.
 
 .
 I've forked this library from https://github.com/phf/go-openal 
 and have started changing it quite a bit from the original library.
 .
 I don't have any experience with the original OpenAl libraries, so
 I'm going to be rearranging this a bit to fit my needs.  
 .
 .
 To install simply install the openal and alc libs appropriately for
 your platform, or build them from scratch, then run
 .
 go get -u github.com/timshannon/go-openal/
 .
 .
 *Note, as of commit 0a4cd0b this library is no longer compatible with Go 1.3.3 
and older.*

Dependency of barnard (#958567)

Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Wed, 2020-04-08 at 16:11 +0200, Michael Biebl wrote:
> I'd like to make a stable/buster upload for systemd fixing CVE-2020-
> 1712
> https://security-tracker.debian.org/tracker/CVE-2020-1712
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950732
> 
> After talking to the security team (namely Salvatore), we decided to
> fix this issue via a stable upload.
> 
> The debdiff is a bit on the larger side, unfortunately.
> Salvatore made a smaller backport avoiding some of the refactorings
> that were done upstream
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/69
> 
> I decided to go with the backport provided by upstream that was done
> for the v241-stable branch mainly for two reasons:
> - It makes potential future cherry-picks easier
> - Doing our own backport has the potential to introduce Debian
> specific bugs
> 

I'd be OK with that, but this will need a KiBi-ack, so CCing and
tagging accordingly.

Regards,

Adam

Bug#947464: buster-pu: gnome-maps/3.30.3.1-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-04-23 at 13:10 +0100, Phil Wyett wrote:
> On Thu, 2020-04-23 at 12:47 +0100, Adam D. Barratt wrote:
> > On Thu, 2020-04-23 at 06:11 +0100, Phil Wyett wrote:
> > > On Wed, 2020-04-22 at 21:50 +0100, Adam D. Barratt wrote:
> > > > +gnome-maps (3.30.3.1-1+deb10u1) buster; urgency=medium
> > > > 
> > > > That version number would be the first stable update to
> > > > 3.30.3.1-
> > > > 1. 
> > > > As this is a new upstream version, 3.30.3.1-0+deb10u1 is a
> > > > commonly
> > > > used pattern.
> > > > Did you see my comment regarding version numbers?
> > 
> > Regards,
> > 
> > Adam
> > 
> 
> Yes, I saw the comment regarding version number pattern.
> 

Please feel free to upload with the version number suggested earlier in
the discussion.

Regards,

Adam

Bug#947102: buster-pu: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-12-26 at 12:31 +, Phil Wyett wrote:
> Attached is a debdiff that resolves CVE in package 'filezilla' on
> > buster.
> > 
> > filezilla (3.39.0-2+deb10u1) buster-security; urgency=high
> > 
> >   * Team Upload
> >   * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
> > #928282)
> > 
> >  -- Phil Wyett   Wed, 18 Dec 2019
> > 20:25:54
> > 
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928282
> > https://security-tracker.debian.org/tracker/CVE-2019-5429
> > 
> > Regards
> > 
> > Phil
> > 
> 
> Hi,
> 
> Updated debdiff. Changed from Team to NMU.
> 

Apologies for the delay. Please go ahead.

Regards,

Adam

Bug#930374: stretch-pu: package node-url-parse/1.0.5-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-06-11 at 18:32 +0200, Xavier Guimard wrote:
> node-url-parse does not parse correctly hostname which leads to
> multiple vulnerabilities such as SSRF, Open Redirect, Bypass
> Authentication Protocol,... (#906058, CVE-2018-3774)
> 
> I imported upstream patch in debian/patches/CVE-2018-3774.patch. This
> is the only changes enabled on installed files. Since this package
> didn't launch upstream test, I added also some build dependencies and
> installed some little required test dependencies in
> debian/tests/test_modules, and of course modify debian/rules.
> 
> If you prefer to have only the security change without test, I just
> can just this commit with a debian/changelog entry:
> https://salsa.debian.org/js-team/node-url-parse/commit/e4204c37
> 

Apologies for the long delay. Please go ahead.

Regards,

Adam

Bug#947758: buster-pu: package node-handlebars/3:4.1.0-1+deb10u1

[Paul Gevers]

Hi Xavier,

On Sat, 8 Feb 2020 08:23:25 +0100 Xavier  wrote:
> Le 07/02/2020 à 20:16, Adam D. Barratt a écrit :
> > On Sat, 2020-01-25 at 20:40 +, Adam D. Barratt wrote:
> > This apparently causes regressions in the autopkgtests of node-
> > markdown-it-html5-embed, which you also most recently uploaded - see 
> > https://ci.debian.net/user/britney/jobs?package=node-markdown-it-html5-embed&suite[]=stable&arch[]=amd64
> > 
> > Is this enough of an issue to not include the node-handlebars update?
> > 
> > Regards,
> > 
> > Adam
> 
> Hi,
> 
> then please defer node-handlebars update until I understand what happens.

Did you figure this out in the mean time? The next point release is
going to happen on 9 May 2020, so it would be good to know if the
package can be included.

Paul

Bug#931678: buster-pu: package qdirstat/1.5-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-08 at 11:23 +0200, Patrick Matthäi wrote:
> Control: tags -1 - moreinfo
> 
> Am 09.07.2019 um 10:41 schrieb Patrick Matthäi:
> > Control: tags -1 - moreinfo
> > 
> > Am 09.07.2019 um 10:30 schrieb Adam D. Barratt:
> > > Control: tags -1 + moreinfo
> > > 
> > > On 2019-07-09 09:22, Patrick Matthäi wrote:
> > > > upstream just fixed a bug in qdirstat, where user configured
> > > > MIME
> > > > categories
> > > > are not saved properly, as described here:
> > > > https://github.com/shundhammer/qdirstat/issues/109
> > > This doesn't appear to be fixed in unstable yet, which is (as
> > > ever) a
> > > prerequisite. Please let us know, and remove the moreinfo tag,
> > > once it
> > > is.
> > > 
> > > Regards,
> > > 
> > > Adam
> > Heh, you were too fast ;) I were just building other packages, just
> > uploaded the new upstream version right now:
> > qdirstat_1.5.90-1_amd64.changes
> Oh forgot to CC the bug.. ;)
> 

Apologies for the long delay. Please go ahead.

Regards,

Adam

Bug#927433: stretch-pu: package gosa/2.7.4+reloaded2-13+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

Apologies for the delay.

On Sat, 2019-08-10 at 04:17 +0200, Mike Gabriel wrote:
> Hi again,
> 
> On Fri, 19 Apr 2019 19:53:33 +0200 Mike Gabriel  > 
> wrote:
>  > now that we could avoid the full backport of gosa from buster to
> stretch
>  > (see #927306), the Debian Edu team would still like to introduce
> various
>  > fixes for gosa to the next Debian 9 point release.
>  >
>  > Some issues require a fix (RC / important), some are small fixes
> here and there that caused people pain and have been resolved in
> Debian buster's gosa.
>  >
[...]
> I was wondering what the state of this stretch-pu request is?
> 
> I attached a new .debdiff version for this potential upload, adding
> the fix for CVE-2019-11187 (no-dsa issue).

Mostly, it's a lot of changes, so takes longer to look at, and
oldstable review tends to get less priority when there's a reasonable
number of stable changes to get through.

In any case, please go ahead.

Regards,

Adam

Bug#958845: false positive wildcard-matches-nothing-in-dep5-copyright

[Jörg Frings-Fürst]

Package: lintian
Version: 2.66.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

at simutrans I get lintian info:

wildcard-matches-nothing-in-dep5-copyright simutrans/font/m+10r.bdf (paragraph
at line 60)

But this file exist:

$ ls -l simutrans/font/m*
- -rw-r--r-- 1 jff jff 1013593 Apr 25 17:51 simutrans/font/m+10r.bdf

CU
Jörg



- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.34-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-10
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.58-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl6kjv4ACgkQCfifPIyh
0l3JoA//a39IWohoCjkdFKtn31CKf7jFmLxRokOv6qpF5Bh8/qm7X6ag0/xUUuEO
beOn/s8VTgQ+RCD3w5w3GgSDe5WEMfS0iC4AwBTSHsEKN9cqLg7RmMUIZ6ok7Oh7
xfh/oXAd9h7auiFheQIeeE2EVaOO2y1EWhF3fywhzlmp8nTsM/nVRKEvH4VVT7bC
COzET4PV56EHA2LTnDl+dOxjKcfZ8RiPDqlwtSgLGkZrCzuMPWrVHr7wxmFvx0tR
yEhvLi+LZFf7Vt4l7JuFTP+C8xEqvQLswWmi+Moo8REDD6+kEj7tXYkFN8BdVYVa
TsN0vCMEI1OhNL4VKIJKTCuSi2i/758LatJjuZo9LiBkQbXR7VxwlY8npp+bwvnk
JyMnBvy1PPC+d0ABSZqjd/30Xiq8Rhh6+K0dCDweBge4paKuREOUXher9o6ZRlDw
KI38eAhodXxzLJnkh3FM/NeDx6pWg5zQBvy69T17l/rsTsfAa/Jp5Lan1WwIvF9F
BUm659XhjR17qc03S3CnPMeKzauoNWRjoQHMKS3lZfF9BWIq8eOR4dk2/RBTU8F5
R5SxP5OehNU8QoDtXM0dCE9fuori/Y69RuC6Xb97TjVKYN9Pahul8uStOQey8FN7
uncCzt7WlzwR3brQON44OHjMxLBpPiwPBJM6fhjKXdRGnhwV9dQ=
=Nlvy
-END PGP SIGNATURE-

Bug#958844: installation-reports: installation report - succesfull installation on iMac G5 (powerpc64)

[Martine Hrebec]

Package: installation-reports
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

Boot method: CD
Image version: 
https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-ppc64-NETINST-1.iso
Date: 2020-04-20 11:00

Machine: iMac G5 2.1 20", A1145, PowerMac12,1
Partitions: 
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   2075584   0   2075584   0% /dev
tmpfs  tmpfs   452224   14400437824   4% /run
/dev/sda7  ext4 165438336 6490612 150474216   5% /
tmpfs  tmpfs  2260864   20672   2240192   1% /dev/shm
tmpfs  tmpfs 5120  64  5056   2% /run/lock
tmpfs  tmpfs  2260864   0   2260864   0% /sys/fs/cgroup
/dev/sda2  hfs 1249906516118474   6% /boot/grub
tmpfs  tmpfs   452160 128452032   1% /run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:


Installation without problems, grub install works perfectly. Only grub 
partition is not visible on powermac Startup Manager (alt//option) on early 
strtup. 
I correct it with "blessing" file /System/Library/CoreServices/BootX on 
bootstrap (grub) partition. I blessed this file with MorphOS command 
HFSsetMacBooot and it works
I will test it later under debian - maybe this? 
hmount /dev/sda2 && hattrib -b untitled:System:Library:CoreServices
I will make a notice to debian-powerpc mailing list
-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20200315"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux imac 5.5.0-2-powerpc64 #1 SMP Debian 5.5.17-1 (2020-04-15) 
ppc64 GNU/Linux
lspci -knn: lspci: Unable to load libkmod resources: error -12
lspci -knn: :00:0b.0 PCI bridge [0604]: Apple Inc. CPC945 PCIe Bridge 
[106b:005b]
lspci -knn: :04:00.0 VGA compatible controller [0300]: Advanced Micro 
Devices, Inc. [AMD/ATI] RV380 [Radeon X600] [1002:3e50]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV380 [Radeon 
X600] [1002:3e50]
lspci -knn: 0001:00:00.0 Host bridge [0600]: Apple Inc. U4 HT Bridge [106b:0074]
lspci -knn: 0001:00:01.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0053]
lspci -knn: 0001:00:02.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0054]
lspci -knn: 0001:00:03.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0055]
lspci -knn: 0001:01:01.0 Network controller [0280]: Broadcom Inc. and 
subsidiaries BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller 
[14e4:4318] (rev 02)
lspci -knn: Subsystem: Apple Inc. Device [106b:4318]
lspci -knn: Kernel driver in use: b43-pci-bridge
lspci -knn: 0001:01:07.0 Unassigned class [ff00]: Apple Inc. Shasta Mac I/O 
[106b:004f]
lspci -knn: Kernel driver in use: macio
lspci -knn: 0001:01:0b.0 USB controller [0c03]: NEC Corporation OHCI USB 
Controller [1033:0035] (rev 43)
lspci -knn: Subsystem: NEC Corporation OHCI USB Controller [1033:0035]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:01:0b.1 USB controller [0c03]: NEC Corporation OHCI USB 
Controller [1033:0035] (rev 43)
lspci -knn: Subsystem: NEC Corporation OHCI USB Controller [1033:0035]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:01:0b.2 USB controller [0c03]: NEC Corporation uPD72010x USB 
2.0 Controller [1033:00e0] (rev 04)
lspci -knn: Subsystem: NEC Corporation uPD72010x USB 2.0 Controller 
[1033:00e0]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 0001:02:0c.0 IDE interface [0101]: Broadcom K2 SATA [1166:0240]
lspci -knn: Subsystem: Broadcom K2 SATA [1166:0240]
lspci -knn: Kernel driver in use: sata_svw
lspci -knn: 0001:0

Bug#958829: haproxyctl: upstream project stale: no changes since 2016, homepage broken, and no issue tracker

[Salvatore Bonaccorso]

Hi Jonas,

On Sat, Apr 25, 2020 at 07:34:22PM +0200, Jonas Smedegaard wrote:
> Package: haproxyctl
> Version: 1.4.3-1
> Severity: important
> Tags: security
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> The haproxyctl project seems abandoned:
> 
> Last git commit was in November 2016,
> the "home" at Github has its issue tracker disabled,
> and it points to another homebase which is currently down.

Sounds not good indeed. Should the package be removed from unstable,
and not be included in the next stable release?

Running a simulation of a dak rm on coccia at least does show that
there will be no problems with reverse dependencies:

| $ dak rm --suite=sid -n -R haproxyctl
| Will remove the following packages from sid:
| 
| haproxyctl |1.4.3-1 | source, all
| 
| Maintainer: Debian Ruby Extras Maintainers 

| 
| --- Reason ---
| 
| --
| 
| Checking reverse dependencies...
| No dependency problem found.

Regards,
Salvatore

Bug#954838: buster-pu: package wpa/2:2.7+git20190128+0c1e29f-6+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Tue, 2020-03-24 at 11:33 +0100, Andrej Shadura wrote:
> I’m proposing to upload a couple of upstream patches improving Wi-Fi
> connectivity in some cases especially on certain hardware.
> 
> For two of them, the relevant issues are #942164 and LP: #1867908.
> 

I'd be OK with that, but as wpa builds a debdiff this will need a KiBi-
ack. CCing and tagging accordingly.

Regards,

Adam

Bug#951761: buster-pu: package opam/2.0.3-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-02-21 at 11:56 +0100, Stéphane Glondu wrote:
> It has been brought to my attention that opam doesn't work in buster
> out of the box. This has been tracked in [1] (fixed in testing) and
> [2]. See in particular comments starting at [3].
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908203
> [2] https://github.com/ocaml/opam/issues/3827
> [3] https://github.com/ocaml/opam/issues/3827#issuecomment-586265289
> 
> Martin Lucina (@mato on GitHub) proposed some changes to improve the
> situation.
> 
> I've attached the proposed changes. I would like to apply them in a
> buster update.
> 

Please go ahead.

Regards,

Adam

Bug#958843: please don't depend on vim-nox

[John Scott]

Package: vim-editorconfig
Version: 0.3.3+dfsg-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I see in #851572 the dependency was added on vim-nox, but it appears to me
that this was done out of an abundance of caution. Caution is good, but I
mean to point out that the reporter wasn't having any difficulties:
> https://github.com/editorconfig/editorconfig-vim#installation states
> that vim needs to have enabled python support. This support is included
> in the "vim-nox" package so it might make sense to add a dependency to
> that package instead of the "vim" package.

That's not true: Python isn't necessary, and if it were all versions of Vim
except for vim-tiny have support for it. The README says
> If your Vim is not compiled with +python feature (...), please first
> download the EditorConfig core

> This plugin would NOT work if neither +python nor EditorConfig core is
> available.

(It didn't get mentioned in the README until a couple years after [1], but
Python 2 or Python 3 are sufficient.) Since vim-editorconfig does depend on
editorconfig, Python support in Vim isn't needed.

In fact editorconfig.txt says there is a third option by which you can get
away with neither, by invoking the Python interpreter outside Vim:
> Specify the mode of EditorConfig core. Generally it is OK to leave this option
> empty. There are 3 modes currently: "external_command", "python_builtin",
> "python_external".
> 
> python_builtin: Use the vim built-in python to run the python version
> EditorConfig Core.
> python_external:Use an external python interpreter to run the python
> version EditorConfig Core.
> external_command:   Run external EditorConfig Core.

However all of the search paths for an external Python interpreter still look
for Python 2, so I don't think that works without patching.

debian/copyright has
> Files-Excluded: plugin/editorconfig-core-py
but vim-editorconfig doesn't depend/recommend/suggest python3-editorconfig
in its place. Because vim-editorconfig isn't patched to search outside of
its runtime path in /usr/lib/python3/dist-packages/editorconfig I don't think
it would find them or run any Python code for that matter.

I don't think the release candidate upstream uses Python at all anymore, so
please take that invitation to drop the need for Python when it comes.

[1] 
https://github.com/editorconfig/editorconfig-vim/pull/52#issuecomment-406514109

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim-editorconfig depends on:
ii  editorconfig  0.12.1-1.1
ii  vim-nox   2:8.2.0439-1

Versions of packages vim-editorconfig recommends:
ii  vim-addon-manager  0.5.10

vim-editorconfig suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXqSMbgAKCRByvHFIwKst
p3hDAP9cYT0e5fADRboC8l+x0VHUJXEWzCxQHsFMoDEt8YFW/wEA5HisEhHgRWzC
YVTGGP/gD8xA7SLIJfP3EYU6YJx3IQQ=
=P4Q6
-END PGP SIGNATURE-

Bug#950854: buster-pu: package node-anymatch/2.0.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-02-07 at 14:20 +0100, Xavier Guimard wrote:
> too many dependencies are required in Buster to install anymatch.
> This
> little fix reduce them, build/test & autopkgtest are OK.
> 

Please go ahead.

Regards,

Adam

Bug#958192: stretch-pu: package xdg-utils/1.1.1-1+deb9u1

[Mattia Rizzolo]

On Sat, Apr 25, 2020 at 07:15:41PM +0100, Adam D. Barratt wrote:
> On Sun, 2020-04-19 at 17:16 +0300, Nicholas Guriev wrote:
> > Along with 1.1.3-1+deb10u1 for buster I propose an update for stretch
> > with the same fixes that applicable for 1.1.1 version.
> > 
> 
> Please go ahead.

Uploaded.

(Nicholas: I know you didn't ask me to, hope I didn't just in too soon)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#958842: fsplib: autopkgtest failure: Assertion `fsp_transaction(s,&p,&r)==0' failed.

[Paul Gevers]

Source: fsplib
Version: 0.14-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

With a recent upload of fsplib you added an autopkgtest, great. However,
it fails. I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=fsplib

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fsplib/4959489/log.gz

autopkgtest [11:37:00]: test build: [---
build: OK
fsptest: /tmp/autopkgtest-lxc.aeo3u5or/downtmp/build.m5e/src/test.c:35:
main: Assertion `fsp_transaction(s,&p,&r)==0' failed.
Aborted
autopkgtest [11:37:00]: test build: ---]



signature.asc
Description: OpenPGP digital signature

Bug#947172: buster-pu: package npm/5.8.0+ds6-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-12-22 at 14:14 +0100, Xavier Guimard wrote:
> npm is vulnerable to some CVEs (CVE-2019-16775, CVE-2019-16776,
> CVE-2019-16777). This patch groups patches from differents sub
> modules affected and add a new module (npm-normalize-package-bin
> package) used by these fixes.
> 

Sorry for the delay. Please go ahead.

Regards,

Adam

Bug#955807: transition: netcdf

[Sebastian Ramacher]

On 2020-04-25 17:23:03, Sebastiaan Couwenberg wrote:
> vtk7 (7.1.1+dfsg2-3) was just uploaded and it FTBFS as reported in #958817.
> 
> Since it's a key package the RC bug won't trigger autoremoval of it and
> its rdeps like lammps.
> 
> If #958817 is not fixed soon, rebuilds in testing-proposed-updates like
> for hdf5 may be required to enable migration of netcdf and the affected
> packages.

I don't think this will be necessary. libnetcdf15 and libnetcdf18 are
co-installable so netcdf should be smooth-updatable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#948333: buster-pu: package frr/6.0.2-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote:
> On 1/7/20 2:01 PM, Thomas Goirand wrote:
> > As per the issue described here:
> > https://github.com/FRRouting/frr/issues/3251
> > 
> > extended next hop capability does not work in Debian Buster.
> > As a consequence, we aren't able to advertize for an IP
> > address on our local loopback through the IPv6 link local,
> > which is how we would like to do BGP to the host.
> > 
> > Note that this issue is from version 5.0.1 up to version
> > 7.2 (which is in Sid), so I took the time to cherry-pick the
> > fix from upstream. I have attached the resulting debdiff, and
> > opened the bug against the frr package itself.
[...]
> FYI, frr bug number is:
> https://bugs.debian.org/cgi-bin/948332

Apologies for the delay in getting back to you.

The description above, and the metadata on the referenced bug report,
suggest that the issue still affects the package in unstable. Is that
correct?

Regards,

Adam

Bug#958841: erlang breaks elixir-lang autopkgtest: killed

[Paul Gevers]

Source: erlang, elixir-lang
Control: found -1 erlang/1:22.3.2+dfsg-1
Control: found -1 elixir-lang/1.9.1.dfsg-1.3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of erlang the autopkgtest of elixir-lang fails in
testing when that autopkgtest is run with the binary packages of erlang
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
erlang from testing1:22.3.2+dfsg-1
elixir-langfrom testing1.9.1.dfsg-1.3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of erlang to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=erlang

https://ci.debian.net/data/autopkgtest/testing/amd64/e/elixir-lang/5145669/log.gz

Finished in 119.8 seconds (9.2s on load, 110.6s on tests)
9 doctests, 618 tests, 0 failures

Randomized with seed 214091
Killed
autopkgtest [21:16:46]: test run-all: ---]



signature.asc
Description: OpenPGP digital signature

Bug#765104: Update hfsprogs to 572.1.1

[John Paul Adrian Glaubitz]

Rogério

On 4/25/20 1:57 AM, Rogério Brito wrote:
> On Jul 03 2019, John Paul Adrian Glaubitz wrote:
>> Are you still interested working on hfsprogs or do you want me to take the
>> package over? Updating to a newer version of hfsprogs is surely needed now
>> and if you are no longer interested in maintaining the package, it would
>> be best to orphan it and me or someone else pick it up for maintenance.
> 
> I don't know if you received my last message, but, if not, feel free to
> adopt this package.

I already filed a bug report for an ITA yesterday, see [1].

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958522

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#958840: kmer: autopkgtest regression: No module named 'localAlignerInterface'

[Paul Gevers]

Source: kmer
Version: 0~20150903+r2013-7
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of kmer the autopkgtest of kmer fails in testing
when that autopkgtest is run with the binary packages of kmer from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
kmer   from testing0~20150903+r2013-7
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=kmer

https://ci.debian.net/data/autopkgtest/testing/amd64/k/kmer/5152781/log.gz

autopkgtest [14:11:18]: test atac-unit-test: [---
Rewriting
'/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/GCF_000195855.1_ASM19585v1_genomic.fna'
to
'/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.fasta',
removing newlines.
Rewriting
'/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/GCF_000195955.2_ASM19595v2_genomic.fna'
to
'/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.fasta',
removing newlines.

/usr/bin/meryl -B -C -threads 2 -m 20 -s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.fasta
-o /tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.ms20


/usr/bin/meryl -v -M lessthanorequal 1 -s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.ms20
-o
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.ms20.le1



/usr/bin/meryl -B -C -threads 2 -m 20 -s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.fasta
-o
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.ms20


/usr/bin/meryl -v -M lessthanorequal 1 -s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.ms20
-o
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.ms20.le1


Finding the min count between Lepr.ms20.le1 and Tuber.ms20.le1.

/usr/bin/meryl -M min -s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.ms20.le1
-s
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.ms20.le1
-o
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/min.Lepr.ms20.le1.Tuber.ms20.le1


includeSize is proportional to 1048608.
excludeSize is proportional to 15724920.
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/min.Lepr.ms20.le1.Tuber.ms20.le1
has 33265 mers.
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.ms20
has 3268184 mers.
includeSize is exactly 33265 mers.
excludeSize is exactly 3234919 mers.

/usr/bin/../lib/atac/bin/seatac -verbose -mersize 20 -minlength   20
-maxgap  0 -numthreads  4 -table
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Lepr.fasta
-stream
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/meryldir/Tuber.fasta
-only
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber.include
-output
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber-segment-000.matches
-filtername  /usr/bin/../lib/atac/lib/filter-heavychains.so -filteropts
"-1 Lepr -2 Tuber -S 100 -J 10" >
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber-000.out
2>&1


/usr/bin/../lib/atac/bin/matchExtender
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber.header
 
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber-segment-000.matches
 > 
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended

WARNING:  TMPDIR not set, defaulting to
'/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results'.

python3 /usr/bin/../lib/atac/bin/AtacDriver.py
/tmp/autopkgtest-lxc.pom4prd4/downtmp/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended

Traceback (most recent call last):
  File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 26, in 
import localAlignerInterface
ModuleNotFoundError: No module named 'localAlignerInterface'
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.
autopkgtest [14:11:24]: test atac-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#947442: buster-pu: package pango1.0/1.42.4-8~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-12-26 at 21:43 +, Simon McVittie wrote:
> We've been asked to fix a crash bug (#898960) in buster. Would you
> be willing to consider a direct backport of 1.42.4-8 when it has had
> some more time in unstable? In addition to a simple crash fix, it
> has some improvements to the autopkgtest (which do not affect binary
> packages). Diff below.
> 
> Or I could drop the autopkgtest changes and do a 1.42.4-7~deb10u2 or
> something with just the crash fix, if preferred.

Sorry for the delay in replying. I'd be happy with the diff as
presented, thanks.

> Either way this will need a d-i ack - the graphical installer uses
> Pango, via GTK 2.
> 

CCing for that.

Regards,

Adam

Bug#958839: RFS: fuse-posixovl/1.2.20120215+gitf5bfe35-3 -- FUSE file system that provides POSIX functionality

[Seunghun Han]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fuse-posixovl"

 * Package name: fuse-posixovl
   Version : 1.2.20120215+gitf5bfe35-3
   Upstream Author : Jan Engelhardt ,

 * URL : https://sourceforge.net/projects/posixovl
 * License : GPL-2+
 * Vcs : https://sourceforge.net/p/posixovl/posixovl/ci/master/tree/
   Section : misc

It builds those binary packages:

  fuse-posixovl - FUSE file system that provides POSIX functionality

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fuse-posixovl

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fuse-posixovl/fuse-posixovl_1.2.20120215+gitf5bfe35-3.dsc

Changes since the last upload:

   * Fixed an unreproducible bug (Closes: #782215)
 - With Reiner Herrmann 's patch

Regards,

--
  Seunghun Han

Bug#948381: buster-pu: package owfs/3.2p3+dfsg1-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-01-08 at 01:37 +0100, Andreas Beckmann wrote:
> I'd like to drop the broken python3 packages from src:owfs. They are
> unusable since they contain python2-only code. (#943612)
> There are no rdepends.
> They were removed from unstable, too, waiting for proper python3
> support upstream.
> 

Sorry for the delay; please go ahead.

Regards,

Adam

Bug#958566: Wrong package name

[Gert van de Kraats]

I think it should be a bug to package firmware-b43-installer.

Bug#953763: buster-pu: package node-minimist/1.2.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-03-13 at 07:23 +0100, Xavier Guimard wrote:
> node-minimist is vulnerable to prototype pollution. I fixed this
> using
> whole 1.2.0-to-1.2.5 diff (very little) since only prototype related
> issues have been fixed.
> 

Please go ahead.

Regards,

Adam

Bug#958838: node-babel7 ftbfs in buster-backports

[Pirate Praveen]

Package: node-babel7
Version: 7.4.5-2
Severity: important

I'm trying to backport node-babel7 for fasttrack.debian.net and build 
failed with error (many of the build dependencies are in still in 
backports-new so it will be hard to reproduce the error), but it seems 
a simple fix to add the missing dependency to debian/build_modules.


/usr/bin/gulp build
[18:37:07] Local gulp not found in /<>
[18:37:07] Try running: npm install gulp
[18:37:07] Using globally installed gulp
internal/modules/cjs/loader.js:583
   throw err;
   ^

Error: Cannot find module 'fastparse'
   at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:581:15)

   at Function.Module._load (internal/modules/cjs/loader.js:507:25)
   at Module.require (internal/modules/cjs/loader.js:637:17)
   at require (internal/modules/cjs/helpers.js:22:18)
   at Object. 
(/<>/node_modules/html-loader/lib/attributesParser.js:5:14)

   at Module._compile (internal/modules/cjs/loader.js:689:30)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

   at Module.load (internal/modules/cjs/loader.js:599:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
   at Function.Module._load (internal/modules/cjs/loader.js:530:3)
make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: binary] Error 2

Bug#958835: installation-report: all ok

[Martin Hrebec]

Package: installation-reports
Version: 2.74
Severity: minor

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

Boot method: CD
Image version: 
https://cdimage.debian.org/ports/2020-04-19/debian-10.0-ppc64-NETINST.iso  
bulid date 2020-04-19 18:34
Date: 2020-04-20 20:30

Machine: Powermac G5 Quad, A1117/A1177, PowerMac11,2
Partitions: 
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   7720704   0   7720704   0% /dev
tmpfs  tmpfs  16418567936   1633920   1% /run
/dev/sda7  ext4  76372700 4490048  67960020   7% /
tmpfs  tmpfs  8209088   0   8209088   0% /dev/shm
tmpfs  tmpfs 5120  64  5056   2% /run/lock
tmpfs  tmpfs  8209088   0   8209088   0% /sys/fs/cgroup
/dev/sda2  hfs 1249906524118466   6% /boot/grub
tmpfs  tmpfs  1641792   0   1641792   0% /run/user/0

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:



installation on powermac64 with grub works fine, only grub partition is not 
visible in mac Startup Manager (alt/option during early boot)
Maybe is needed "to bless" /System/Library/CoreServices/BootX file? I will try 
and make notice to debian-powerpc mailing list 
-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20200315"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux powermac 5.5.0-2-powerpc64 #1 SMP Debian 5.5.17-1 (2020-04-15) 
ppc64 GNU/Linux
lspci -knn: lspci: Unable to load libkmod resources: error -12
lspci -knn: :00:0b.0 PCI bridge [0604]: Apple Inc. CPC945 PCIe Bridge 
[106b:005b]
lspci -knn: :0a:00.0 VGA compatible controller [0300]: Advanced Micro 
Devices, Inc. [AMD/ATI] R580+ [Radeon X1950 XTX] [1002:7240]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] R580+ [Radeon 
X1950 XTX] [1002:7240]
lspci -knn: 0001:00:00.0 Host bridge [0600]: Apple Inc. U4 HT Bridge [106b:0074]
lspci -knn: 0001:00:01.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X 
bridge [1166:0130] (rev a3)
lspci -knn: 0001:00:02.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X 
bridge [1166:0130] (rev a3)
lspci -knn: 0001:00:03.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev a3)
lspci -knn: 0001:00:04.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev a3)
lspci -knn: 0001:00:05.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev a3)
lspci -knn: 0001:00:06.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev a3)
lspci -knn: 0001:00:07.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0053]
lspci -knn: 0001:00:08.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0054]
lspci -knn: 0001:00:09.0 PCI bridge [0604]: Apple Inc. Shasta PCI Bridge 
[106b:0055]
lspci -knn: 0001:01:07.0 Unassigned class [ff00]: Apple Inc. Shasta Mac I/O 
[106b:004f]
lspci -knn: Kernel driver in use: macio
lspci -knn: 0001:01:0b.0 USB controller [0c03]: NEC Corporation OHCI USB 
Controller [1033:0035] (rev 43)
lspci -knn: Subsystem: NEC Corporation OHCI USB Controller [1033:0035]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:01:0b.1 USB controller [0c03]: NEC Corporation OHCI USB 
Controller [1033:0035] (rev 43)
lspci -knn: Subsystem: NEC Corporation OHCI USB Controller [1033:0035]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 0001:01:0b.2 USB controller [0c03]: NEC Corporation uPD72010x USB 
2.0 Controller [1033:00e0] (rev 04)
lspci -knn: Subsystem: NEC Corporation uPD72010x USB 2.0 Controller 
[1033:00e0]
lspci -knn: Kernel driver in use: ehci-p

Bug#958837: vulkan-loader breaks openxr-sdk-source autopkgtest: VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not declared

[Paul Gevers]

Source: vulkan-loader, openxr-sdk-source
Control: found -1 vulkan-loader/1.2.135.0-2
Control: found -1 openxr-sdk-source/1.0.8~dfsg1-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of vulkan-loader the autopkgtest of
openxr-sdk-source fails in testing when that autopkgtest is run with the
binary packages of vulkan-loader from unstable. It passes when run with
only packages from testing. In tabular form:

   passfail
vulkan-loader  from testing1.2.135.0-2
openxr-sdk-source  from testing1.0.8~dfsg1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of vulkan-loader to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=vulkan-loader

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openxr-sdk-source/5144212/log.gz

autopkgtest [19:21:52]: test build-hello-xr-vulkan-xlib:
[---
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:
In member function ‘VkBool32
{anonymous}::VulkanGraphicsPlugin::debugReport(VkDebugReportFlagsEXT,
VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t, const char*,
const char*)’:
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not
declared in this scope; did you mean
‘VK_DEBUG_REPORT_OBJECT_TYPE_END_RANGE_EXT’?
 1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
  |  ^~~~
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1638:5:
note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
 1638 | _(OBJECT_TABLE_NVX)  \
  | ^
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
note: in expansion of macro ‘LIST_OBJECT_TYPES’
 1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
  | ^
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NVX_EXT’
was not declared in this scope; did you mean
‘VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT’?
 1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
  |  ^~~~
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1639:5:
note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
 1639 | _(INDIRECT_COMMANDS_LAYOUT_NVX)
  | ^
/tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
note: in expansion of macro ‘LIST_OBJECT_TYPES’
 1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
  | ^
autopkgtest [19:22:04]: test build-hello-xr-vulkan-xlib:
---]



signature.asc
Description: OpenPGP digital signature

Bug#958830: php-apcu: upgrade to php-apcu 5.1.17->18 breaks nextcloud

[Ondřej Surý]

Control: close -1

NextCloud (server) isn’t even packaged for Debian, and it should be using the 
default PHP version in Debian which is currently PHP7.4. 
The PHP7.3 has been removed from unstable and it will be shortly removed from 
testing.

Ondrej
--
Ondřej Surý 

> On 25 Apr 2020, at 19:45, james.bottom...@hansenpartnership.com 
>  wrote:
> 
> Package: php-apcu
> Version: 5.1.18+4.0.11-1+b1
> Severity: grave
> Justification: renders package unusable
> 
> After the upgrade nextcloud just gives an internal server error
> 
> The problem seems to be that nextcloud is configured to use apcu as
> a memory cache and this version of apcu only has php7.4 files.  Nextcloud
> is currently stuck on php7.3 so the memory cache it's told to use
> doesn't exist.
> 
> I can fix this in my nextcloud config.php by commenting out the line
> 
> 'memcache.local' => '\\OC\\Memcache\\APCu',
> 
> But the problem certainly makes apcu unusable by nextcloud
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (500, 'testing'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 5.5.0-2-686 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages php-apcu depends on:
> ii  libc62.30-4
> ii  php-common   2:69
> ii  php7.4-cli [phpapi-20190902] 7.4.5-1
> ii  php7.4-phpdbg [phpapi-20190902]  7.4.5-1
> 
> Versions of packages php-apcu recommends:
> ii  php-apcu-bc  1.0.5-2+b1
> 
> Versions of packages php-apcu suggests:
> ii  php-gd  2:7.3+69
> ii  php7.2-gd [php-gd]  7.2.9-1
> ii  php7.3-gd [php-gd]  7.3.15-3
> 
> -- no debconf information
>