Bug#971350: ITP: golang-github-saracen-walker -- walker is a faster, parallel version, of filepath.Walk

2020-09-28 Thread Jai Flack
Package: wnpp
Severity: wishlist
Owner: Jai Flack 

* Package name: golang-github-saracen-walker
  Version : 0.1.1-1
  Upstream Author : Arran Walker
* URL : https://github.com/saracen/walker
* License : Expat
  Programming Lang: Go
  Description : walker is a faster, parallel version, of filepath.Walk

Reasoning:
 This is a dependency for recent releases of fzf (>= 0.21.0), a popular, fast,
 command-line fuzzy finder.

Description:
 This library and filepath.Walk both perform os.Lstat calls and provide a full
 os.FileInfo structure to the callback. BenchmarkFastwalkWalkLstat and
 BenchmarkGodirwalkWalkLstat include this stat call for better comparison with
 BenchmarkFilepathWalk and BenchmarkWalkerWalk.
 .
 This library and fastwalk both require the callback to be safe for concurrent
 use. BenchmarkFilepathWalkAppend, BenchmarkWalkerWalkAppend,
 BenchmarkFastwalkWalkAppend and BenchmarkGodirwalkWalkAppend append the paths
 found to a string slice. The callback, for the libraries that require it, use a
 mutex, for better comparison with the libraries that require no locking.
 .
 This library will not always be the best/fastest option. In general, if you're
 on Windows, or performing lstat calls, it does a pretty decent job. If you're
 not, I've found fastwalk to perform better on machines with fewer cores.



Bug#971349: nmu: colord,gimagereader,haskell-bindings-sane,hplip,libimage-sane-perl,libinsane,libkf5sane,libreoffice,pike8.0,pillow-sane,sane-airscan,sane-frontends,scanbd,simple-scan,wine,xsane

2020-09-28 Thread Jörg Frings-Fürst
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hello,

please rebuild the following packages to use the new lib after rename libsane to
libsane1.
 

nmu colord_1.4.4-2  . ANY . -m 'Rebuild against new libsane1.'
nmu gimagereader_3.3.1-1 . ANY . -m 'Rebuild against new libsane1.'
nmu hplip_3.20.5+dfsg0-3 . ANY . -m 'Rebuild against new libsane1.'
nmu haskell-bindings-sane_0.0.1-13 . ANY . -m 'Rebuild against new libsane1.'
nmu libimage-sane-perl_5-1 . ANY . -m 'Rebuild against new libsane1.'
nmu libinsane_1.0.7-1 . ANY . -m 'Rebuild against new libsane1.'
nmu libkf5sane_20.08.0-1 . ANY . -m 'Rebuild against new libsane1.'
nmu wine_5.0-4 . ANY . -m 'Rebuild against new libsane1.'
nmu pike8.0_8.0.702-1 . ANY . -m 'Rebuild against new libsane1.'
nmu pillow-sane_2.8.3-4 . ANY . -m 'Rebuild against new libsane1.'
nmu libreoffice_1:7.0.1-1 . ANY . -m 'Rebuild against new libsane1.'
nmu sane-frontends_1.0.14-16 . ANY . -m 'Rebuild against new libsane1.'
nmu scanbd_1.5.1-6 . ANY . -m 'Rebuild against new libsane1.'
nmu simple-scan_3.36.4-1 . ANY . -m 'Rebuild against new libsane1.'
nmu xsane_0.999-9 . ANY . -m 'Rebuild against new libsane1.'


CU
Jörg 

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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


Bug#965012: squid3 http://:0 problem

2020-09-28 Thread j.stribrsky

Hello Markus,




your patch fixed the problem, we are again able to see accessed URL in
antivirus logs!




   Thank you very much, have a nice day.

   Jarda Stribrsky




-- Původní e-mail --
Od: Markus Koschany 
Komu: j.stribr...@email.cz, SerNet Support Kevin Ivory 
Datum: 29. 9. 2020 0:02:12
Předmět: squid3 http://:0 problem
"Hello,

I believe I have found the underlying problem that caused the strange
http://:0 responses. Apparently the patch
CVE-2019-12523-bug965012.patch, which fixed the original icap error,
introduced this one then. The modified code in
src/adaptation/icap/ModXact.cc was responsible for that.

I have uploaded a new version for testing to

https://people.debian.org/~apo/lts/squid3/stretch/

It also contains new patches for four security vulnerabilities namely
CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and CVE-2020-24606.

If I hear no negative feedback I intend to upload this version to fix
your problem.

Regards,

Markus


"

Bug#971348: frescobaldi: Frescobaldi does not start

2020-09-28 Thread Frédéric Moinard
Package: frescobaldi
Version: 3.1.2+ds1-1
Severity: normal
X-Debbugs-Cc: f2c...@gmail.com

Dear Maintainer,

Starting Frescobladi :

~$ frescobaldi
Traceback (most recent call last):
  File "/usr/share/frescobaldi/frescobaldi_app/plugin.py", line 79, in instance
return _instances[cls][obj]
  File "/usr/lib/python3.8/weakref.py", line 383, in __getitem__
return self.data[ref(key)]
KeyError: 

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/frescobaldi", line 29, in 
main.main() # Parse command line, create windows etc
  File "/usr/share/frescobaldi/frescobaldi_app/main.py", line 210, in main
win = mainwindow.MainWindow()
  File "/usr/share/frescobaldi/frescobaldi_app/mainwindow.py", line 129, in
__init__
self.createMenus()
  File "/usr/share/frescobaldi/frescobaldi_app/mainwindow.py", line 1105, in
createMenus
menu.createMenus(self)
  File "/usr/share/frescobaldi/frescobaldi_app/menu.py", line 61, in
createMenus
m.addMenu(menu_file(mainwindow))
  File "/usr/share/frescobaldi/frescobaldi_app/menu.py", line 95, in menu_file
m.addMenu(snippet.menu.TemplateMenu(mainwindow))
  File "/usr/share/frescobaldi/frescobaldi_app/snippet/menu.py", line 146, in
__init__
self.addAction(self.tool().actionCollection.templates_manage)
  File "/usr/share/frescobaldi/frescobaldi_app/snippet/menu.py", line 58, in
tool
return panelmanager.manager(self.mainwindow()).snippettool
  File "/usr/share/frescobaldi/frescobaldi_app/panelmanager.py", line 38, in
manager
return PanelManager.instance(mainwindow)
  File "/usr/share/frescobaldi/frescobaldi_app/plugin.py", line 84, in instance
result.__init__(obj)
  File "/usr/share/frescobaldi/frescobaldi_app/panelmanager.py", line 70, in
__init__
self.loadPanel("musicview.MusicViewPanel", "viewers")
  File "/usr/share/frescobaldi/frescobaldi_app/panelmanager.py", line 107, in
loadPanel
__import__(module_name)
  File "/usr/share/frescobaldi/frescobaldi_app/musicview/__init__.py", line 52,
in 
import pagedview
  File "/usr/share/frescobaldi/frescobaldi_app/pagedview.py", line 36, in

import popplerqt5
ValueError: PyCapsule_GetPointer called with incorrect name


Thanks in advance,
Frédéric



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

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

Versions of packages frescobaldi depends on:
ii  python33.8.2-3
ii  python3-ly 0.9.6-1
ii  python3-poppler-qt50.75.0-1+b1
ii  python3-pygame 1.9.6+dfsg-3
ii  python3-pyqt5  5.15.1+dfsg-2
ii  python3-pyqt5.qtsvg5.15.1+dfsg-2
ii  python3-pyqt5.qtwebengine  5.15.1-1
ii  python3-pyqt5.qtwebkit 5.15.1+dfsg-2
ii  tango-icon-theme   0.8.90-8

Versions of packages frescobaldi recommends:
ii  lilypond  2.20.0-2

Versions of packages frescobaldi suggests:
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-fr [hyphen-hyphenation-patterns] 1:7.0.1-1
ii  lilypond-doc2.20.0-2

-- no debconf information


Bug#971001: Please support caching packages outside the chroot

2020-09-28 Thread Johannes Schauer
Hi,

Quoting Josh Triplett (2020-09-29 06:39:40)
> I think it would make sense to have as part of the documentation of hooks,
> which goes hand-in-hand with an outline of mmdebstrap's operation and where
> those hooks fit. For instance, I didn't know until this conversation that
> mmdebstrap used a different mechanism to handle Essential than non-Essential.

agreed.

> > Would it be useful in any scenario to keep those *.deb files?
> 
> For caching, yes, to avoid downloading them more than once.

If a user wants to avoid downloading packages multiple times, they can just use
apt-cacher.

> Would it be possible to use libapt for that, via one of its various bindings?

I did not find an interface offering that functionality.

> >   $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \
> >   > --setup-hook='mkdir -p ./cache.ess "$1"/var/cache/apt/archives' \
> >   > --setup-hook='sync-in ./cache.ess /var/cache/apt/archives' \
> >   > --extract-hook="sync-out /var/cache/apt/archives ./cache.ess" \
> >   > --essential-hook='mkdir -p ./cache.rest "$1"/var/cache/apt/archives' \
> >   > --essential-hook='sync-in ./cache.rest /var/cache/apt/archives' \
> >   > --customize-hook='sync-out /var/cache/apt/archives ./cache.rest' \
> >   > unstable debian-unstable
> 
> This is definitely at the level of complexity where it'd be *really
> nice* to just be able to pass `--cache-debs cachedir`, without depending
> deeply on the specific nuance of mmdebstrap's essential/non-essential
> handling (and potential future changes to that).

This is what the --hook-directory option is for. You put a directory somewhere,
place scripts in it according to each hook and their order and then run
mmdebstrap like with `--hook-dir cachedir` which is just as short as your
example. :)

> > You can upgrade ext2 to ext4 by using "tune2fs -O
> > extents,uninit_bg,dir_index,has_journal" but I see that this would be of no
> > use to you.
> 
> Right, that won't actually convert how existing files are handled. That
> would take an e2fsck run with specific options. And the initial
> filesystem would need more space than the final one, requiring an
> unecessarily large image.

Correct.

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#960046: transition: sane-backends

2020-09-28 Thread Jörg Frings-Fürst
Hello,

I close this bug after upload to unstable.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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


Bug#971347: transition: mumps

2020-09-28 Thread Drew Parsons
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I wanted to make a combo transition with superlu-dist 5.3.1 and hypre
2.20.  But the hypre upgrade requires superlu-dist 5.3 and
superlu-dist 5.3 FTBFS (see
https://github.com/xiaoyeli/superlu_dist/issues/60 )

So let's proceed with the MUMPS 5.3.3 transition on its own and get
the mumps upgrade into the archives

(it's been waiting in experimental, and I've been using it to test
builds of reverse dependencies). Autotracker at
https://release.debian.org/transitions/html/auto-mumps.html


Ben file:

title = "mumps";
is_affected = .depends ~ "libmumps-5.3.1" | .depends ~ "libmumps-5.3.3";
is_good = .depends ~ "libmumps-5.3.3";
is_bad = .depends ~ "libmumps-5.3.1";


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

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



Bug#971346: emacs: Unable to install from ELPA

2020-09-28 Thread Janusz S. Bień
Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: normal

I get

package-install-from-archive: 
https://elpa.gnu.org/packages/dired-git-info-0.3.1.el: Bad Request

The same problem with auctex:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43667

Regards

Janusz

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

Kernel: Linux 4.19.0-11-amd64 (SMP w/2 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2+deb10u1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien



Bug#971345: WebKitNetworkProcess: random crashes (SIGABRT)

2020-09-28 Thread Paul Wise
Package: libwebkit2gtk-4.0-37
Version: 2.30.1-1
Severity: normal
File: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
Usertags: crash

I got seven random WebKitNetworkProcess crashes (SIGABRT) at around the
same time. I have no idea how to reproduce these crashes. All of the
crashes have a short backtrace like the one below. If the short
backtrace below and the full backtraces attached aren't helpful, then
please close this bug report.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply 
all bt full' --core 
/var/crash/1000/153921-1000-1000-6-1601184512-chianamo--usr-lib-x86_64-linux-gnu-webkit2gtk-4.0-WebKitNetworkProcess.core
 /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
[New LWP 153921]
[New LWP 153928]
[New LWP 153930]
[New LWP 153931]
[New LWP 153932]
[New LWP 153933]
[New LWP 153929]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by 
`/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess 28 70'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f77ed156fc0 (LWP 153921))]
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f77f4189537 in __GI_abort () at abort.c:79
#2  0x7f77f4d5eff1 in 
WebKit::AuxiliaryProcess::didReceiveInvalidMessage(IPC::Connection&, 
IPC::MessageName) () at ../Source/WebKit/Shared/AuxiliaryProcess.cpp:249
#3  0x7f77f4d4cffc in 
IPC::Connection::dispatchMessage(std::unique_ptr >) () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1084
#4  0x7f77f4d4d5ef in IPC::Connection::dispatchOneIncomingMessage() () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1139
#5  0x7f77f3643db3 in WTF::Function::operator()() const () at 
../Source/WTF/wtf/Function.h:83
#6  WTF::RunLoop::performWork() () at ../Source/WTF/wtf/RunLoop.cpp:119
#7  0x7f77f3690a69 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#8  _FUN() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:82
#9  0x7f77f369137f in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 _FUN() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:56
#11 0x7f77f3d53a8f in g_main_dispatch (context=0x56535c200090) at 
../../../glib/gmain.c:3325
#12 g_main_context_dispatch (context=0x56535c200090) at 
../../../glib/gmain.c:4016
#13 0x7f77f3d53e38 in g_main_context_iterate (context=0x56535c200090, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4092
#14 0x7f77f3d5412b in g_main_loop_run (loop=0x56535c2005b0) at 
../../../glib/gmain.c:4290
#15 0x7f77f36914c8 in WTF::RunLoop::run() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#16 0x7f77f4d46940 in WebKit::AuxiliaryProcessMain(int, char**) () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:68
#17 0x7f77f418acca in __libc_start_main (main=0x56535af1c710 , 
argc=3, argv=0x7fff889be6e8, init=, fini=, 
rtld_fini=, stack_end=0x7fff889be6d8) at ../csu/libc-start.c:308
#18 0x56535af1c78a in _start ()

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libwebkit2gtk-4.0-37:amd64 depends on:
ii  bubblewrap  0.4.1-1
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-3
ii  libcairo2   1.16.0-4
ii  libegl1 1.3.2-1
ii  libenchant-2-2  2.2.8-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgcc-s1   10.2.0-9
ii  libgcrypt20 1.8.6-2
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libgl1  1.3.2-1
ii  libglib2.0-02.66.0-2
ii  libgstreamer-gl1.0-01.18.0-2
ii  libgstreamer-plugins-base1.0-0  1.18.0-2
ii  libgstreamer1.0-0   1.18.0-3
ii  libgtk-3-0  3.24.23-1
ii  libharfbuzz-icu02.6.7-1
ii  libharfbuzz0b   2.6.7-1
ii  libhyphen0  2.8.8-7
ii  libicu6767.1-4
ii  libjavascriptcoregtk-4.0-18 2.30.1-1
ii  libjpeg62-turbo 1:2.0.5-1.1
ii  libnotify4  0.7.9-1
ii  libopenjp2-72.3.1-1
ii  libpango-1.0-0  1

Bug#971001: Please support caching packages outside the chroot

2020-09-28 Thread Josh Triplett
On Sun, Sep 27, 2020 at 10:09:03AM +0200, Johannes Schauer wrote:
> Hi,
> 
> Quoting Josh Triplett (2020-09-27 08:07:26)
> > > Yes, one bit is missing. For the initial Essential:yes package set,
> > > mmdebstrap deletes the *.deb files itself after installing them. So you
> > > have to copy them out of the chroot before the deletion happens, so 
> > > between
> > > downloading and extracting. Like so:
> > > 
> > >  $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \
> > >  > --setup-hook='mkdir -p cache "$1"/var/cache/apt/archives' \
> > >  > --setup-hook='sync-in ./cache /var/cache/apt/archives' \
> > >  > --extract-hook="sync-out /var/cache/apt/archives ./cache" \
> > >  > --customize-hook='sync-out /var/cache/apt/archives ./cache' \
> > >  > unstable debian-unstable
> > 
> > Ah! That was indeed what I was missing, thank you.
> > 
> > Is it documented somewhere that mmdebstrap deletes those files after
> > installing them?
> 
> no, that is not documented. I'm also unsure where to write that down and for
> how many people this would be of interest.

I think it would make sense to have as part of the documentation of
hooks, which goes hand-in-hand with an outline of mmdebstrap's operation
and where those hooks fit. For instance, I didn't know until this
conversation that mmdebstrap used a different mechanism to handle
Essential than non-Essential.

> Would it be useful in any scenario to keep those *.deb files?

For caching, yes, to avoid downloading them more than once.

> > Also, does mmdebstrap *use* the cache for the initial Essential package set?
> 
> Short answer: yes.
> 
> But as I was making sure what the right answer to your question is, I
> discovered another problem with our current approach: mmdebstrap uses apt to
> download the right packages but apt does not provide a machine readable
> interface to figure out which packages it decided to fetch, so what mmdebstrap
> does, is to just use all packages in /var/cache/apt/archives/ as the result of
> the apt query for the Essential:yes packages.

Ah, ouch.

Would it be possible to use libapt for that, via one of its various
bindings?

> This is a problem if /var/cache/apt/archives/ also contains non-Essential
> packages because many packages cannot be installed in the initial bootstrap
> phase due to maintainer scripts. You can try out this effect by using the 
> above
> command and putting more packages into --include and then during the second
> run, mmdebstrap will fail. To make sure, that we don't run into this problem
> without noticing in the future, I added a check to mmdebstrap whether
> /var/cache/apt/archives/ is empty before acquiring any packages. To not have
> this error prevent use-cases like yours, you can add the --skip=download/empty
> option to your mmdebstrap invocation with the next mmdebstrap release.
> 
> So we need *two* caches: One for the Essential packages and one for the rest.
> I didn't test, but it would probably be something like this:
> 
>   $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \
>   > --setup-hook='mkdir -p ./cache.ess "$1"/var/cache/apt/archives' \
>   > --setup-hook='sync-in ./cache.ess /var/cache/apt/archives' \
>   > --extract-hook="sync-out /var/cache/apt/archives ./cache.ess" \
>   > --essential-hook='mkdir -p ./cache.rest "$1"/var/cache/apt/archives' \
>   > --essential-hook='sync-in ./cache.rest /var/cache/apt/archives' \
>   > --customize-hook='sync-out /var/cache/apt/archives ./cache.rest' \
>   > unstable debian-unstable

This is definitely at the level of complexity where it'd be *really
nice* to just be able to pass `--cache-debs cachedir`, without depending
deeply on the specific nuance of mmdebstrap's essential/non-essential
handling (and potential future changes to that).

> > > > > This will not work with all modes. I guess you are using root or 
> > > > > fakechroot
> > > > > mode?
> > > > 
> > > > Yes, I'm using root mode, as I need a directory of files I can feed to
> > > > `mkfs.ext4 -d`. In theory I might be able to use fakechroot mode and
> > > > run mkfs.ext4 underneath mmdebstrap; I may try that once I've gotten the
> > > > existing setup to do everything I need it to.
> > > 
> > > Maybe the ability of mmdebstrap to produce ext2 filesystems directly can 
> > > be
> > > useful for you. You will then not need root privileges.
> > 
> > I did see that, but it looks like that uses genext2fs, and I need to use
> > mkfs.ext4 so that I can generate an ext4 filesystem with specific
> > options (as well as write files out with extents). It also doesn't
> > support xattrs.
> 
> You can upgrade ext2 to ext4 by using "tune2fs -O
> extents,uninit_bg,dir_index,has_journal" but I see that this would be of no 
> use
> to you.

Right, that won't actually convert how existing files are handled. That
would take an e2fsck run with specific options. And the initial
filesystem would need more space than the final one, requiring an
unecessarily large image.



Bug#971343: Problem changing wallpaper causes system to freeze

2020-09-28 Thread Leandro Cunha
Package: gnome-control-center
Version: 1:3.36.4-1
Severity: critical
Tags: upstream

When changing the wallpaper to the one that changes throughout the day in both
sections xorg and wayland through the gnome control center the system freezes
using nouveau and it is necessary to force the system shutdown. As the problem
occurs in other distributions and I found out by doing tests I put the upstream
tag.
I haven't tested the current version 3.38 and I have no idea if it fixes this
problem. I haven't found any reports on this and I'm looking through the git
repository of gnome and bts.
I chose to put this severity because it causes the system to freeze
according to
what it says in the documentation, which iscauses non-system-related software
(or the whole system) to stop, or cause
serious data loss, or introduce a security breach in the systems where
you install
the package.
This report follows the documentation: https://www.debian.org/Bugs/Reporting

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF9maJUBEADs8Y/AQuM2cW0pKynIRkUj9qFvnn/HICLJ+MYjPk2/lzJGjepY
YzQjkrNOpB5FlnDy0kfAI/ZAFIirytsH1JYx+4XEwBwlofGzS9hl9655u19n2iqp
f4CPhXMkbjKQuQMSL+MC8Kn9rWibmcFri415yW0nhiqL//f+Z+9TRYXynKOLdGnE
B4zi8l5TVh104rnP+vTChMHnnhBRRx1DNG6vaP+pkV6agHcaTVxcvIThu05+ngwR
sPGBpdr/G3Rt9Ltf5O9uiksKa7aD6OX6no4xS+NO4O+Vr5487LYKEpiaEGNjh2/d
eAdkqtjmH9lht16sUzqGTgq+Wdqtt0TX5ba5jClWvFcPMU3EVHZ5NsXuD9GQ5Vbx
H+j+kNBSaaWZeILPM9DI3qUaQlHGZIL4SIQNBT533CMO9ceOyjG/MQAGvyvov7Li
SasyQ65C89ExZhu1R/Z9M4vcWJX3QXf83CYgxoSANaU2eN+Pl9/tzIM+D/xy1O6A
FuuaTQKi66kBJv9Ub3/BnEFzcYlbgAZXNly6Ft3T2LYLM9rYJ7cFVCZzSaEd9Hg8
PwiD5SGQN4iqi8AFbRA6IpCd2I35jU5BONyCwvzO4ifuXBZ8dkRYycJvEwS/Wfkx
zRUnJx8GWRi6cdd9z4esw2AbzVoIR/cejOaY+DuQ5S2q46ImD56hwELWMwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBJzBewgVKcdfbNX/b2JhzmlCOdYYBQJfZmiVAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEGJhzmlCOdYYLNcP/0YcO+abhoTXiU7r6yoeRGsI2x1q
NBtpJZlaeF7KqDS0gyewQPpOGGMuFxfSvjUJp1MDig/+PyWToTw2uJZGOsDy7aqk
Mas90k/UBeH50G7BMmmlOalYCCM/VMPpt0l4n6QxU6ONuQrieZCjIYPPcSBNPIKp
I9WbNDSxbE/nb6n7Z2yYNYXXtHTjiPp4bs6Waoi9y5jxc7aTeKh8eI/Nz19w/3sB
t3UOxFONVcZldwRiW6F6y32x938K7aBRH/9lB4vTLrejVXEkkAFfJdW+BO+PWKRS
Ydnx9+UxtzPH2h2yT68bR4lL9WcEsqSz26s7a27hz4bqHBoLz5BohM8xDtv1eTSp
XKCofNASSJ/lGyJ/yjB/hsSQgpt1X/GsyCd21NVKOGjFCW0DU6ZAcx2X0sBrIjDt
iV8lUoTum7tW5HEtw1UJ5WY0Iik8wv32gXRaitRP+be1Kvcee4/Cqp0nHRBlO05R
4PG91g6kNOfSKHxH8FcZQ37F6e+dCHuK8Cx8XBegPVShQOFqWBGq7hQ/Uc2teUww
B6xRoDIxJPQRTmh+zrHJhYd4r36TJxHQo9oEBJ086NiBW6QRJg7kfnR6p0/nekDs
Wpw/lnivGToSDCJrZaOlMhnhZ+jWooH+fEPdnmcJDIByoOwh4hD+S5r9dy+kMlUp
gfeT/anhKh/sW54muQINBF9maJUBEACzpPahcamBaALztTnXBnm9C+SNzIhgHvBN
MDou32oVt1O42pKl4fa1JHsCS8+4TGPRvYvNqfB/vceEKjKvb5KXIltXR9B+cc4z
SycM3srmwmSqGyiNG+oAfmGC0uKtci2vNOdM5J4lBJyn+aSbSLCIaS2hy1ATF4wt
S4mnDJQlkWabiL6Nu8gLYup+rly8EwgH7EDIlRHHsZQGxVEXBrcXwqik29/CFZsy
6bA/sQAI9nreLNoexLucIJZGPEw+Wpk1y8vkdvxSZ3dxbQSK+sY4tINR4vp7hqiv
NduCyYEoPUu3Vc1vqkxJncUqxjejXYdfS7rt2SqwqkXJeyQbNwlxtAgf3dNWwSCA
fWwsL4Tw4ABXE9dy1SlZ1bbLaD4R8lLjY3iLArzDjTda0Lvwxr0+MIpryZevJD3w
uikLWKgPqFzNov88jz+n0VSUbIO4Yqm0UnWM7maYx60r2boU9WebvvDoBOcEoNjl
2P/eCHGrExJQ51fVBxfMyHnFsY6r9vLTz1G2KjAjaTWE3DlKZmjib5p3xPJIPQcR
V/4Lw8ILgUkGALbnoBQ2NWbRp3As1El5ANSJPWD52PdCEJ7leHIHNjSERvbpvXPM
xV6/q5g2e3cSKMFmzyaFCMrsWAnMp5lfBb02u1LREnxBuzJtrtrBBbztMxt3G4r3
yApwqOzOywARAQABiQI2BBgBCgAgFiEEnMF7CBUpx19s1f9vYmHOaUI51hgFAl9m
aJUCGwwACgkQYmHOaUI51hh55w//VhNmT8enopY+FW5seVLUf8nqHP3OtDIt5/RP
hLnyqU+Vr/EXcYOuNleJr7DhbgWmVroQajow8kzEgJWbgUjuwDON4IjoAUHFqNRn
1qInbQ7hbL8ohL5z05RtCRjWfAE620bda7hWP8Y5EgqKXB5auT1RddJAKthRerrO
u7gnehNW1X2CbZHEHTQOFUlXBnhL6Q6NtnT6Fi+t4sIQaRuXtqIBP/Hh88RdwxJk
1eYd0KSgDe7RG3DgQ5da+GRdAyqhNrKrsRjA1Re7poSFevSXyr5hYVvqGhmarpNp
wfiTtKC0Wlubgyhzbz53ZFsRAMvOBc+kId+rb74Xs7SrJzr1+lXUuWte9ErIKaaD
S/QHzShup9FOBY/WIU1tYAcSL83UkD6NFCzx+R48AG4Hfo25jg7/emj1vseNrfYB
mPo/tnYteUXcXUs6wH0JSMmVVBJJtcURH+KgQI9aPtyNFvDlpxtpJFXCDZE7LYZt
gUA8owrx1f/XuuLrgM+sS7beS7Z81JcEjBmBDGTNDxYFvO6/Lof9TyVScz4zLdLl
MdvV4hIVReH1Cv9vDiQN9BbgMTWcT6RQM5QVArTMIICu5JmTYqVJi3nQOyuvJ2u/
UkqN1M3P724hldLD529LUcWOqeRCQTRRGZy4/l++xCj/KXbZJ4BI8MDkst8bpRBz
XXnYczk=
=ZmJB
-END PGP PUBLIC KEY BLOCK-


Bug#970983: sugar-themes: does not define @text_view_bg named colour

2020-09-28 Thread James Cameron
On Mon, Sep 28, 2020 at 09:18:56AM +0100, Simon McVittie wrote:
> On Mon, 28 Sep 2020 at 13:20:59 +1000, James Cameron wrote:
> > I've just tested Debian Testing (Bullseye), with src:sugar
> > 0.117-3, src:sugar-artwork:0.117-1, src:sugar-terminal-activity
> > version 47-1, src:vte2.91 version 0.62.0-1, and GTK 3.24.23-1 but
> > do not see any problem.
> > 
> > The terminal is correctly rendered in black on white or white on
> > black modes.
> 
> If sugar-terminal-activity hard-codes its background colour, you
> wouldn't see a problem.

Yes, sugar-terminal-activity hard-codes background colour of the Vte.

> The problem case is when vte is configured to inherit its colours
> from the theme. I don't know whether this is even possible with
> sugar-terminal-activity, but it is possible in gnome-terminal:
> https://gitlab.gnome.org/GNOME/vte/-/issues/284
> 
> Note that src:vte2.91 0.62.0-2 has a workaround, so you will need to
> hold src:vte2.91 at version 0.62.0-1 to reproduce this. Upstream
> asked me not to apply the workaround on the 0.63.x branch, so it is
> likely to go away after bullseye.

Yes, I checked that I used src:vte2.91 0.62.0-1 after seeing your
later changes on salsa git.  Thanks for warning, and sorry for not
mentioning.

> To reproduce this in GNOME (I used a test VM):
> - Run a gnome-terminal and gnome-tweaks
> - In gnome-terminal, right-click -> Preferences
> - profile -> Colors -> Text and Background -> Use colors from system
>   theme
> - In gnome-tweaks: Appearance -> Themes -> Applications ->
>   Sugar-100 or Sugar-72
> - Drag the two windows around to see the misrendering

Thanks.  It does reproduce.

> (I realise the Sugar themes are probably not *intended* to be used
> to theme non-Sugar GTK-based environments like GNOME and XFCE, but
> there is nothing that prevents it!)

Yes, an unexpected outcome.  Perhaps we should make the theme local to
Sugar and activities rather than make it available for other uses.

> The client-side-decoration window titlebar seems to have the same
> issue, so there are probably other named colours missing? Depending
> on the age of the theme, you might also need to add
> @theme_text_color and @unfocused_insensitive_color. See
> gtk/theme/Adwaita/_colors-public.scss in the gtk+3.0 source package
> for the full set.

Thanks.  I added these, which further fixed the Vte rendering, making
gnome-terminal useful again.  Window titlebar rendering was still
broken, even after I added _all_ remaining named colors from the full
set.  I don't know what is missing.

https://github.com/sugarlabs/sugar-artwork/pull/118

> > Please review
> > https://github.com/sugarlabs/sugar-artwork/pull/117
> 
> That looks suitable, although I haven't tested it.
> 
> smcv

-- 
James Cameron
http://quozl.netrek.org/



Bug#971342: mirror submission for mirror.lagoon.nc

2020-09-28 Thread Tech Lagoon
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.lagoon.nc
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Tech Lagoon 
Country: NC New Caledonia
Location: Nouméa
Sponsor: OFFRATEL LAGOON https://www.lagoon.nc/




Trace Url: http://mirror.lagoon.nc/debian/project/trace/
Trace Url: http://mirror.lagoon.nc/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.lagoon.nc/debian/project/trace/mirror.lagoon.nc



Bug#963201: flightgear: diff for building on s390x

2020-09-28 Thread Joel Ray Holveck
Control: tags 963201 + patch

Dear maintainer,

I'd love to see flightgear get back into bullseye!  I see that it's been 
blocked for a while because it doesn't build on the s390x.

The HID bitfield extraction code assumes a little-endian machine, but the s390x 
is big-endian.  Enclosed is a patch to fix that.  I've written it as an NMU, 
but don't plan to actually upload it.

I haven't looked for other places that make that assumption.  I also haven't 
tried to verify that the HID code actually works right on an s390x.  But at 
least it builds now.

Regards.

diff -Nru flightgear-2020.1.3+dfsg/debian/changelog flightgear-2020.1.3+dfsg/debian/changelog
--- flightgear-2020.1.3+dfsg/debian/changelog	2020-07-13 01:50:46.0 -0700
+++ flightgear-2020.1.3+dfsg/debian/changelog	2020-09-28 14:32:08.0 -0700
@@ -1,3 +1,10 @@
+flightgear (1:2020.1.3+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix HID extractBits for big-endian systems (Closes: #963201)
+
+ -- Joel Ray Holveck   Mon, 28 Sep 2020 14:32:08 -0700
+
 flightgear (1:2020.1.3+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2020.1.3+dfsg
diff -Nru flightgear-2020.1.3+dfsg/debian/patches/hid-bigendian.patch flightgear-2020.1.3+dfsg/debian/patches/hid-bigendian.patch
--- flightgear-2020.1.3+dfsg/debian/patches/hid-bigendian.patch	1969-12-31 16:00:00.0 -0800
+++ flightgear-2020.1.3+dfsg/debian/patches/hid-bigendian.patch	2020-09-28 14:32:08.0 -0700
@@ -0,0 +1,22 @@
+Index: flightgear-2020.1.3+dfsg/src/Input/FGHIDEventInput.cxx
+===
+--- flightgear-2020.1.3+dfsg.orig/src/Input/FGHIDEventInput.cxx
 flightgear-2020.1.3+dfsg/src/Input/FGHIDEventInput.cxx
+@@ -27,6 +27,8 @@
+ #include 
+ #include 
+ 
++#include 
++
+ #include 
+ #include 
+ 
+@@ -865,6 +867,8 @@ int extractBits(uint8_t* bytes, size_t l
+ uint32_t v = 0;
+ // this goes from byte alignment to word alignment safely
+ memcpy((void*) &v, bytes + wholeBytesToSkip, bytesToCopy);
++// the memcpy arranges v in little-endian order, so swap if needed
++v = le32toh(v);
+ 
+ // shift down so lowest bit is aligned
+ v = v >> offsetInByte;
diff -Nru flightgear-2020.1.3+dfsg/debian/patches/series flightgear-2020.1.3+dfsg/debian/patches/series
--- flightgear-2020.1.3+dfsg/debian/patches/series	2020-07-13 01:41:42.0 -0700
+++ flightgear-2020.1.3+dfsg/debian/patches/series	2020-09-28 14:32:08.0 -0700
@@ -6,3 +6,4 @@
 disable_some_failing_tests.patch
 disable-check-for-windows.h.patch
 0008-Disable-some-newly-failing-tests.patch
+hid-bigendian.patch


Bug#971340: ITP: python-typing-inspect -- API for runtime inspection of types in python

2020-09-28 Thread Louis-Philippe Véronneau
Package: wnpp
Severity: wishlist
Owner: po...@debian.org

* Package name : python-typing-inspect
  Version : 0.6.0
  Upstream Author : Ivan Levkivskyi 
* URL : https://github.com/ilevkivskyi/typing_inspect
* License : Expat
  Programming Lang: Python
  Description : marshmallow extension for enum fields

The typing_inspect module defines experimental API for runtime
inspection of types defined in the Python standard typing module.

This library is needed to package the dataclasses-json library. I
intend to maintain in the Debian Python Team.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Bug#971341: ITP: libxml-hash-xs-perl -- Simple and fast hash to XML and XML to hash conversion written in C

2020-09-28 Thread Ken Ibbotson
Package: wnpp
Owner: Ken Ibbotson 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libxml-hash-xs-perl
  Version : 0.55
  Upstream Author : Yuriy Ustushenko 
* URL : https://metacpan.org/release/XML-Hash-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Simple and fast hash to XML and XML to hash conversion
written in C

XML::Hash::XS implements simple hash to XML and XML to hash conversion
written in C.

During conversion uses minimum of memory, XML or hash is written directly
without building DOM.

Some features are optional and are available with appropriate libraries:

This description was automagically extracted from the module by
dh-make-perl.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

From: "Ken Ibbotson"
To: "Debian Bug Tracking System"
Subject: ITP: libxml-hash-xs-perl -- Simple and fast hash to XML and XML to
hash conversion written in C
Date: Tue, 29 Sep 2020 11:11:55 +0930
--
Ken Ibbotson
M: +61 418 861 775
E: k...@computer.org

*"Reality is merely an illusion, albeit a very persistent one."*
- Albert Einstein (1879-1955)


Bug#960831: about RFS: yiyantang

2020-09-28 Thread 肖盛文
Hi, Paul,Tobias,

    Thanks for your review.

I had uploaded the new package, please help to review again.

About the upstream:

I can't find any forks that could be new upstream on Internet.

About the "not using autoreconf":

If use autoreconf, the build will failed:

automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
autoreconf: automake failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1

The source code is old, it use configure.in.

在 2020/9/28 上午9:27, Paul Wise 写道:
> On Sun, Sep 27, 2020 at 3:18 PM Tobias Frost wrote:
>
>> If upstream is gone and won't come back you can delete the watch file.
> I suggest instead to keep the watch file, but add a comment mentioning
> the upstream situation.
>
>> Did you look if there are any forks that could be new upstream?
> It can also be a good idea to create a new upstream project or take
> over the existing one if it is still there but not active.
>
-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat):atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统:https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB




signature.asc
Description: OpenPGP digital signature


Bug#971339: ITP: python-marshmallow-enum -- marshmallow extension for enum fields

2020-09-28 Thread Louis-Philippe Véronneau
Package: wnpp
Severity: wishlist
Owner: po...@debian.org

* Package name : python-marshmallow-enum
  Version : 1.5.1
  Upstream Author : Alec Nikolas Reiter 
* URL : https://github.com/justanr/marshmallow_enum
* License : Expat
  Programming Lang: Python
  Description : marshmallow extension for enum fields

This library is needed to package the dataclasses-json library. I
intend to maintain in the Debian Python Team.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Bug#971338: ITP: dataclasses-json -- API for encoding and decoding dataclasses to and from JSON in python

2020-09-28 Thread Louis-Philippe Véronneau
Package: wnpp
Severity: wishlist
Owner: po...@debian.org

* Package name : dataclasses-json
Version : 0.5.2
Upstream Author : Charles Li 
* URL : https://github.com/lidatong/dataclasses-json
* License : Expat
Description :  A python library that provides a simple API for encoding
and decoding dataclasses to and from JSON.

This library is needed to package the new version of sublime-music. I
intend to maintain in the Debian Python Team.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

2020-09-28 Thread Ahzo
Control: reassign -1 gcc-10 10.2.0-9
Control: retitle -1 gcc-10: regression in 10.2.0-9 causes segmentation fault in 
vlc
Control: affects -1 vlc
Control: severity -1 serious

Hi,

the vlc crash is caused by a compiler regression introduced in gcc-10 version 
10.2.0-9, which was used to compile vlc 3.0.11.1-2.

With the buggy compiler, the function picture_Clone from src/misc/picture.c 
gets miscompiled, in particular the following loop:
https://salsa.debian.org/multimedia-team/vlc/-/blob/1d01d5e56132e9917c53c5a97f10d42426081512/src/misc/picture.c#L401-405
    for (int i = 0; i < picture->i_planes; i++) {
    res.p[i].p_pixels = picture->p[i].p_pixels;
    res.p[i].i_lines = picture->p[i].i_lines;
    res.p[i].i_pitch = picture->p[i].i_pitch;
    }

A correctly working gcc simply unrolls the loop:
$ objdump --disassemble=picture_Clone 
/usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 | head -n 62 | tail -n 30
   a8c04:   85 c9   test   %ecx,%ecx
   a8c06:   0f 8e 8c 00 00 00   jle    a8c98 
   a8c0c:   48 8b b7 b0 00 00 00mov    0xb0(%rdi),%rsi
   a8c13:   48 8b bf b8 00 00 00mov    0xb8(%rdi),%rdi
   a8c1a:   48 89 74 24 10  mov    %rsi,0x10(%rsp)
   a8c1f:   48 89 7c 24 18  mov    %rdi,0x18(%rsp)
   a8c24:   83 f9 01cmp    $0x1,%ecx
   a8c27:   74 6f   je a8c98 
   a8c29:   4c 8b 83 d0 00 00 00mov    0xd0(%rbx),%r8
   a8c30:   4c 8b 8b d8 00 00 00mov    0xd8(%rbx),%r9
   a8c37:   4c 89 44 24 20  mov    %r8,0x20(%rsp)
   a8c3c:   4c 89 4c 24 28  mov    %r9,0x28(%rsp)
   a8c41:   83 f9 02cmp    $0x2,%ecx
   a8c44:   74 52   je a8c98 
   a8c46:   4c 8b 93 f0 00 00 00mov    0xf0(%rbx),%r10
   a8c4d:   4c 8b 9b f8 00 00 00mov    0xf8(%rbx),%r11
   a8c54:   4c 89 54 24 30  mov    %r10,0x30(%rsp)
   a8c59:   4c 89 5c 24 38  mov    %r11,0x38(%rsp)
   a8c5e:   83 f9 03cmp    $0x3,%ecx
   a8c61:   74 35   je a8c98 
   a8c63:   4c 8b a3 10 01 00 00mov    0x110(%rbx),%r12
   a8c6a:   48 8b 83 18 01 00 00mov    0x118(%rbx),%rax
   a8c71:   4c 89 64 24 40  mov    %r12,0x40(%rsp)
   a8c76:   48 89 44 24 48  mov    %rax,0x48(%rsp)
   a8c7b:   83 f9 04cmp    $0x4,%ecx
   a8c7e:   74 18   je a8c98 
   a8c80:   48 8b 93 30 01 00 00mov    0x130(%rbx),%rdx
   a8c87:   48 8b 8b 38 01 00 00mov    0x138(%rbx),%rcx
   a8c8e:   48 89 54 24 50  mov    %rdx,0x50(%rsp)
   a8c93:   48 89 4c 24 58  mov    %rcx,0x58(%rsp)


The buggy gcc does something strange instead:
$ objdump --disassemble=picture_Clone 
/usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 | head -n 80 | tail -n 48
   a8c04:   85 f6   test   %esi,%esi
   a8c06:   0f 8e ca 00 00 00   jle    a8cd6 
   a8c0c:   8d 46 fflea    -0x1(%rsi),%eax
   a8c0f:   83 f8 01cmp    $0x1,%eax
   a8c12:   0f 86 18 01 00 00   jbe    a8d30 
   a8c18:   48 8b bf b8 00 00 00mov    0xb8(%rdi),%rdi
   a8c1f:   48 8b 8b b0 00 00 00mov    0xb0(%rbx),%rcx
   a8c26:   41 89 c1mov    %eax,%r9d
   a8c29:   4c 8b 83 d8 00 00 00mov    0xd8(%rbx),%r8
   a8c30:   41 d1 e9shr    %r9d
   a8c33:   48 89 4c 24 10  mov    %rcx,0x10(%rsp)
   a8c38:   48 89 7c 24 20  mov    %rdi,0x20(%rsp)
   a8c3d:   48 89 7c 24 18  mov    %rdi,0x18(%rsp)
   a8c42:   4c 89 44 24 28  mov    %r8,0x28(%rsp)
   a8c47:   41 83 f9 01 cmp    $0x1,%r9d
   a8c4b:   74 30   je a8c7d 
   a8c4d:   4c 8b 93 c8 00 00 00mov    0xc8(%rbx),%r10
   a8c54:   4c 8b 9b c0 00 00 00mov    0xc0(%rbx),%r11
   a8c5b:   4c 8b a3 18 01 00 00mov    0x118(%rbx),%r12
   a8c62:   48 8b 93 f8 00 00 00mov    0xf8(%rbx),%rdx
   a8c69:   4c 89 5c 24 30  mov    %r11,0x30(%rsp)
   a8c6e:   4c 89 54 24 40  mov    %r10,0x40(%rsp)
   a8c73:   48 89 54 24 38  mov    %rdx,0x38(%rsp)
   a8c78:   4c 89 64 24 48  mov    %r12,0x48(%rsp)
   a8c7d:   83 e0 feand    $0xfffe,%eax
   a8c80:   4c 63 c0movslq %eax,%r8
   a8c83:   83 c0 01add    $0x1,%eax
   a8c86:   49 8d 48 01 lea    0x1(%r8),%rcx
   a8c8a:   49 c1 e0 05 shl    $0x5,%r8
   a8c8e:   4a 8b bc 03 b0 00 00mov    0xb0(%rbx,%r8,1),%rdi
   a8c95:   00
   a8c96:   4e 8b 8c 03 b8 00 00mov    0xb8(%rbx,%r8,1),%r9
   a8c9d:   00
   a8c9e:   48 c1 e1 04 shl    $0x4,%rcx
   a8ca2:   48 89 3c 0c mov    %rdi,(%rsp,%rcx,1)
   a8ca6:   4c 89 4c 0c 08  mov    %r9,0

Bug#971023: Version field (5.6.12) and colons

2020-09-28 Thread Sean Whitton
Hello,

On Sat 26 Sep 2020 at 02:48pm +02, Christian Kastner wrote:

> with regards to colons in version numbers, 5.6.12 states on the "epoch"
> fragment:
>
> "If it is omitted then the upstream_version may not contain any colons."
>
>
> However, this seems superfluous, as it states on the "upstream_version"
> fragment:
>
> "The upstream_version may contain only alphanumerics and the characters
> . + - ~ (full stop, plus, hyphen, tilde)"

Technically superfluous but I think helpful to the reader, so I suggest
we just keep it.

-- 
Sean Whitton



Bug#971337: RFS: dh-sysuser/1.3.5 [ITA] -- debhelper addon to handle creation of system users

2020-09-28 Thread Lorenzo Puliti
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser":

 * Package name: dh-sysuser
   Version : 1.3.5
   Upstream Author : [fill in name and email of upstream]
 * URL : https://salsa.debian.org/debian/dh-sysuser
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/dh-sysuser
   Section : admin

It builds those binary packages:


  sysuser-helper - dh-sysuser implementation detail
  dh-sysuser - debhelper addon to handle creation of system users

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

  https://mentors.debian.net/package/dh-sysuser/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.5.dsc

updated git:

  
https://salsa.debian.org/Lorenzo.ru.g-guest/dh-sysuser/-/commits/1.3.5-release/

Changes since the last upload:

 dh-sysuser (1.3.5) unstable; urgency=medium
 .
   [ Lorenzo Puliti ]
   * Do not pollute namespace in maintscript
   * Do not impose unneeded dependency on sysuser-helper
   * Bump Standards-Versions to 4.5.0:
   - Add Rules-Requires-Root: no
   * Update copyright file
   * Adopt the package
   * Release to unstable
 .
   [ Chris Lamb ]
   * Tidy the grammar (etc.) of the dh_sysuser(1) manpage.

Regards,
--
  Lorenzo Puliti



Bug#971336: ITP: gr-satellites -- telemetry decoders for satellites using the Amateur radio bands

2020-09-28 Thread A. Maitland Bottoms


Package: wnpp
Severity: wishlist
Owner: "A. Maitland Bottoms" 

* Package name: gr-satellites
  Version : v3.4.0
  Upstream Author : Daniel Estévez
* URL : https://github.com/daniestevez/gr-satellites
* License : (GPL v3)
  Programming Lang: (C++, Python)
  Description : Telemetry decoders for satellites using the Amateur
radio bands

gr-satellites is a GNU Radio out-of-tree module encompassing a
collection of telemetry decoders that supports many different Amateur
satellites. This open-source project started in 2015 with the goal of
providing telemetry decoders for all the satellites that transmit on
the Amateur radio bands.

It supports most popular protocols, such as AX.25, the GOMspace NanoCom
U482C and AX100 modems, an important part of the CCSDS stack, the AO-40
protocol used in the FUNcube satellites, and several ad-hoc protocols
used in other satellites.

This out-of-tree module can be used to decode frames transmitted from
most Amateur satellites in orbit, performing demodulation, forward
error correction, etc. Decoded frames can be saved to a file or
displayed in hex format. For some satellites the telemetry format
definition is included in gr-satellites, so the decoded telemetry
frames can be printed out as human-readable values such as bus voltages
and currents. Additionally, some satellites transmit files such as JPEG
images. gr-satellites can be used to reassemble these files and even
display the images in real-time as they are being received.

gr-satellites can be used as a set of building blocks to implement
decoders for other satellites or other groundstation solutions. Some of
the low level blocks in gr-satellites are also useful for other kinds
RF communications protocols.

Preliminary package is already prepared - plan is to do packaging under
the Debian Hamradio Maintainers Team and Salsa.
https://wiki.debian.org/DebianHams/
https://salsa.debian.org/debian-hamradio-team

While this has been (and will continue to be) a frequently updated
project, there are some satellite signals supported that would be
useful to decode during the lifespan of a stable Debian release.

-Maitland (AA4HS)



Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

2020-09-28 Thread Felipe Sateler
On Mon, Sep 28, 2020 at 4:03 PM Michael Biebl  wrote:

> Package: systemd
> Version: 246.6-1
> Severity: important
>
> Upstream changed the paths in systemd.pc from prefix to rootprefix in
> v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir:
>
> https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b
>
> This breaks packages which use pkg-config to determine those paths and
> where .install files reference /usr/. An example is mandos.
>
> I think we should revert this change. I don't see a compelling reason to
> move those files from /usr to /lib given that we require /usr to be
> pre-mounted by initramfs, if it's separate.
> Moving files from /usr to /lib files kinda backwards nowadays.
>
> I intend to apply a patch like the attached one in Debian.
> That said, I hope I can convince Lennart to revert this change upstream
> as well.
>

Looks good to me.


>
> Thoughts, Comments?
>

I wonder if systemd can be fully installed into `/usr` now that we require
premounting. Maybe we should start changing lintian and other tools to
install into /usr instead of /lib for the tools that currently used
rootprefix (I believe systemd searches in /usr anyway).

This is likely to be a multi-release effort, but if we never start, we will
never end.

-- 

Saludos,
Felipe Sateler


Bug#971255:

2020-09-28 Thread Daniel Black
Providing a different sysvinit service name different from the systemd
service name is a violation of the packaging guidelines
https://wiki.debian.org/Teams/pkg-systemd/Packaging?action=show#systemd_unit_files_naming_and_installation

Wasn't this covered already in
https://github.com/MariaDB/server/pull/1494  /
https://jira.mariadb.org/browse/MDEV-15526 ?



Bug#969973: lintian: Please emit dh-exec-useless-usage only when none of the lines needs dh-exec

2020-09-28 Thread Zack Weinberg
Package: lintian
Version: 2.96.0
Followup-For: Bug #969973

I just tripped over this as well.  In my case I am specifically using
dh-exec only for filter-build-profiles, but lintian complains anyway:

#! /usr/bin/dh-exec --with-scripts=filter-build-profiles

usr/lib/${DEB_HOST_MULTIARCH}/libthingy.so.1
 usr/share/java/thingy.jar



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

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

Versions of packages lintian depends on:
ii  binutils2.35.1-1
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
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-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

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

-- no debconf information



Bug#971291: salutatoi: Switch to python3-pycryptodome

2020-09-28 Thread Thomas Preud'homme
Upstream seems to have moved to the module cryptography: 
https://repos.goffi.org/sat/rev/330a5f1d9eea. Unfortunately that commit 
is not part of the 0.7 release. I wonder if we could persuade upstream 
from cutting a minor release for us to package.


Best regards,

Thomas

On 2020-09-28 22:29, Sebastian Ramacher wrote:

Source: salutatoi
Version: 0.8.0~hg3247.f981c0e99220-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

salutatoi currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers




Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes

2020-09-28 Thread Diego Escalante Urrelo
Source: broadcom-sta
Version: cfg80211 functionality updates, cleanups, fixes
Severity: normal
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Hi,

I've been working on a few improvements to this driver, trying
(hopelessly) to fix the disconnect issues on my particular card + router
combination. Although my original goal has failed miserably, I was able
to figure out a couple of other fixes for common issues with this card.

I have pushed a branch to salsa, which includes the following fixes:
 * Make power management commands actually work (the driver ignores
 turning PM off)
 * Correctly read the value of TX power (the notorious "200dBm" bug)
 * Correctly refuse MAC address changing (fixes network-manager
 disconnects because of "random / custom mac address"
 * Cleanup a few compiler warnings, and cfg80211 API usage

The branch is here:
 https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/diegoe_debian

While working on the above I also figured that I might as well try to
create a proof of concept "new upstream" without all the cruft from the
10 years of kernel versions conditionals:
 https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/frankenwl

My "frankenwl" branch is functionally the same as the above
"diegoe_debian" branch, but it certainly makes it less convoluted to try
and find problems in the code going forward. That said, I wasn't sure
what would be the best way to proceed, or if it was a smart thing to do
anyway. I guess this package is on "life support" on most distros, so I
doubt there would be a objections on creating a shared new upstream (but
I'm not familiar with the packaging of this driver in Debian, or other
distros).

I also tried, naively, to contact cypress/broadcom to inquiry about a
newer firmware blob dump, or just a new code dump. Of course, no
response. I think it's worth highlighting that the kernel bcmf80211
driver is very similar to the broadcom-sta code, which lead me to
believe that it can work with the cards supported only by broadcom-sta,
we just need the firmware blob and plug the loose ends. Anyway, this is
probably never going to happen, unless someone figures out how to
extract the (say, in my case) BCM4360 software-side firmware blob from
the linux or mac or windows driver.

Anyway, I wanted to share this work here so it's considered for
inclusion for the upcoming Debian stable. At the very least this solves
a few nitpicks (power settings, tx set/get) that degrade the user
experience and a serious issue (mac address failures) that usually gets
new users stuck and confused (random NM disconnections).

I'm also aware that cards supported by this driver are "old" but most
computers trapped in the broadcom-sta driver are perfectly functional
today and will be for a few more years. In my particular case I'm
running a macbookpro11,1 (2013) which works flawlessly except for the
wifi! (Hah!) -- And I understand most other macbookpro models from
around 2013 share this or similar Broadcom cards that use this driver.
All those machines should be perfectly functional with Debian right now,
and for a few more years.

Hope to hear your feedback, I'm glad to cleanup this branch as you see
fit to get it merged into the package.

Diego

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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
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:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#965012: RFT: squid3 3.5.23-5+deb9u5, please test

2020-09-28 Thread Markus Koschany
[adding Andreas and Kevin to CC who helped with testing past squid3 updates]

Hello,

I have uploaded a new version of squid3 for Stretch to people.debian.org.

https://people.debian.org/~apo/lts/squid3/stretch/

It contains fixes for CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and
CVE-2020-24606. Let me know if you find any regressions from
the current released version 3.5.23-5+deb9u4.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Bug#971334: opendkim should use /run instead of /var/run

2020-09-28 Thread Gabriel Filion
Package: opendkim
Version: 2.11.0~alpha-12
Severity: normal

Hello,

When installing opendkim on debian buster, I get the following warning:

Setting up opendkim (2.11.0~alpha-12) ...
Created symlink /etc/systemd/system/multi-user.target.wants/opendkim.service -> 
/lib/systemd/system/opendkim.service.
[opendkim.conf:1] Line references path below legacy directory /var/run/, 
updating /var/run/opendkim → /run/opendkim; please update the tmpfiles.d/ 
drop-in file accordingly.

indeed, opendkim is still using /var/run instead of the new path /run

I might have missed some occurrences of this, but it's at least present in the
systemd unit, /etc/default/opendkim and in /etc/opendkim.conf


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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages opendkim depends on:
ii  adduser  3.118
ii  dns-root-data2019052802
ii  init-system-helpers  1.58
ii  libbsd0  0.10.0-1
ii  libc62.31-3
ii  libdb5.3 5.3.28+dfsg1-0.6
ii  libldap-2.4-22.4.53+dfsg-1
pn  liblua5.1-0  
pn  libmemcached11   
pn  libmilter1.0.1   
pn  libopendbx1  
pn  libopendkim11
pn  librbl1  
ii  libssl1.11.1.1g-1
ii  libunbound8  1.11.0-1
pn  libvbr2  
ii  lsb-base 11.1.0

Versions of packages opendkim recommends:
pn  opendkim-tools  

opendkim suggests no packages.


Bug#965012: squid3 http://:0 problem

2020-09-28 Thread Markus Koschany
Hello,

I believe I have found the underlying problem that caused the strange
http://:0 responses. Apparently the patch
CVE-2019-12523-bug965012.patch, which fixed the original icap error,
introduced this one then. The modified code in
src/adaptation/icap/ModXact.cc was responsible for that.

I have uploaded a new version for testing to

https://people.debian.org/~apo/lts/squid3/stretch/

It also contains new patches for four security vulnerabilities namely
CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and CVE-2020-24606.

If I hear no negative feedback I intend to upload this version to fix
your problem.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Bug#971331: libextractor: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: libextractor
Version: 1:1.10-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

libextractor currently Build-Depends or Depends on libavresample-dev.
The ffmpeg developers consider libavresample as obsolete and replaced
the library with libswresample. Please switch libextractor to use
libswresample.

Note that this switch will require changes if libextractor doesn't
already have support for libsvresample.

Cheers 



Bug#971329: qtav: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: qtav
Version: 1.13.0+ds-2
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

qtav currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch qtav to use libswresample.

Note that this switch will require changes if qtav doesn't already
have support for libsvresample.

Cheers 



Bug#971332: alsa-plugins: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: alsa-plugins
Version: 1.2.2-2
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

alsa-plugins currently Build-Depends or Depends on libavresample-dev.
The ffmpeg developers consider libavresample as obsolete and replaced
the library with libswresample. Please switch alsa-plugins to use
libswresample.

Note that this switch will require changes if alsa-plugins doesn't
already have support for libsvresample.

Cheers 



Bug#971330: opencv: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: opencv
Version: 4.2.0+dfsg-6
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

opencv currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch opencv to use
libswresample.

Note that this switch will require changes if opencv doesn't already
have support for libsvresample.

Cheers 



Bug#971333: avifile: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: avifile
Version: 1:0.7.48~20090503.ds-20.1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

avifile currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch avifile to use
libswresample.

Note that this switch will require changes if avifile doesn't already
have support for libsvresample.

Cheers 



Bug#971328: nageru: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: nageru
Version: 2.0.1-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

nageru currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch nageru to use
libswresample.

Note that this switch will require changes if nageru doesn't already
have support for libsvresample.

Cheers 



Bug#971326: mgba: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: mgba
Version: 0.8.3+dfsg-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

mgba currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch mgba to use libswresample.

Note that this switch will require changes if mgba doesn't already
have support for libsvresample.

Cheers 



Bug#971325: renpy: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: renpy
Version: 7.3.5+dfsg-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

renpy currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch renpy to use libswresample.

Note that this switch will require changes if renpy doesn't already
have support for libsvresample.

Cheers 



Bug#971323: vdr-plugin-softhddevice: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: vdr-plugin-softhddevice
Version: 0.6.0+git20160108-3
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

vdr-plugin-softhddevice currently Build-Depends or Depends on
libavresample-dev. The ffmpeg developers consider libavresample as
obsolete and replaced the library with libswresample. Please switch
vdr-plugin-softhddevice to use libswresample.

Note that this switch will require changes if vdr-plugin-softhddevice
doesn't already have support for libsvresample.

Cheers 



Bug#971322: performous: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: performous
Version: 1.1+git20181118-4
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

performous currently Build-Depends or Depends on libavresample-dev.
The ffmpeg developers consider libavresample as obsolete and replaced
the library with libswresample. Please switch performous to use
libswresample.

Note that this switch will require changes if performous doesn't
already have support for libsvresample.

Cheers 



Bug#971327: libopenshot: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: libopenshot
Version: 0.2.5+dfsg1-4
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

libopenshot currently Build-Depends or Depends on libavresample-dev.
The ffmpeg developers consider libavresample as obsolete and replaced
the library with libswresample. Please switch libopenshot to use
libswresample.

Note that this switch will require changes if libopenshot doesn't
already have support for libsvresample.

Cheers 



Bug#971319: aubio: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: aubio
Version: 0.4.9-4
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

aubio currently Build-Depends or Depends on libavresample-dev. The
ffmpeg developers consider libavresample as obsolete and replaced the
library with libswresample. Please switch aubio to use libswresample.

Note that this switch will require changes if aubio doesn't already
have support for libsvresample.

Cheers 



Bug#971324: zoneminder: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: zoneminder
Version: 1.34.21-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

zoneminder currently Build-Depends or Depends on libavresample-dev.
The ffmpeg developers consider libavresample as obsolete and replaced
the library with libswresample. Please switch zoneminder to use
libswresample.

Note that this switch will require changes if zoneminder doesn't
already have support for libsvresample.

Cheers 



Bug#971321: sdl-kitchensink: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: sdl-kitchensink
Version: 1.0.9-1
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

sdl-kitchensink currently Build-Depends or Depends on
libavresample-dev. The ffmpeg developers consider libavresample as
obsolete and replaced the library with libswresample. Please switch
sdl-kitchensink to use libswresample.

Note that this switch will require changes if sdl-kitchensink doesn't
already have support for libsvresample.

Cheers 



Bug#971320: openscenegraph: uses deprecated libavresample

2020-09-28 Thread Sebastian Ramacher
Source: openscenegraph
Version: 3.6.5+dfsg1-5
Severity: important
Tags: sid bullseye
Usertags: libavresample-removal
Control: block 971318 by -1

Dear maintainer,

openscenegraph currently Build-Depends or Depends on
libavresample-dev. The ffmpeg developers consider libavresample as
obsolete and replaced the library with libswresample. Please switch
openscenegraph to use libswresample.

Note that this switch will require changes if openscenegraph doesn't
already have support for libsvresample.

Cheers 



Bug#971318: libavresample-dev: should be removed

2020-09-28 Thread Sebastian Ramacher
Package: libavresample-dev
Version: 7:4.3.1-4
Severity: important
Tags: sid bullseye

libavresample is deprecated in favor of libswresample, so let's remove
it when possible. The purpose of this bug is to track the progress.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#971317: gplaycli: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: gplaycli
Version: 3.29+dfsg-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

gplaycli currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971314: flask-restful: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: flask-restful
Version: 0.3.8-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

flask-restful currently Build-Depends or Depends on python3-crypto
from PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971311: dfvfs: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: dfvfs
Version: 20190128-2.1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

dfvfs currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971312: keyrings.alt: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: keyrings.alt
Version: 3.4.0-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

keyrings.alt currently Build-Depends or Depends on python3-crypto
from PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971292: samba: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: samba
Version: 2:4.12.5+dfsg-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

samba currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971316: onionbalance: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: onionbalance
Version: 0.2.0-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

onionbalance currently Build-Depends or Depends on python3-crypto
from PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971313: comitup: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: comitup
Version: 1.10-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

comitup currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971315: libcloud: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: libcloud
Version: 3.0.0-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

libcloud currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971298: python-ironic-lib: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-ironic-lib
Version: 4.2.1-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-ironic-lib currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971303: python-file-encryptor: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-file-encryptor
Version: 0.2.9-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-file-encryptor currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971302: python-asyncssh: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-asyncssh
Version: 2.2.1-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-asyncssh currently Build-Depends or Depends on python3-crypto
from PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971304: pwman3: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: pwman3
Version: 0.11.1-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

pwman3 currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971308: plaso: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: plaso
Version: 20190131-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

plaso currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971301: python-manilaclient: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-manilaclient
Version: 2.1.0-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-manilaclient currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971299: onionshare: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: onionshare
Version: 2.2-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

onionshare currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971310: keystone: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: keystone
Version: 2:17.0.0-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

keystone currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971295: salt: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: salt
Version: 3001+dfsg1-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

salt currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971297: python-oauth2client: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-oauth2client
Version: 4.1.2-6
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-oauth2client currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971296: rekall: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: rekall
Version: 1.7.2~rc1+git20190104+dfsg-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

rekall currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971305: patator: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: patator
Version: 0.9-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

patator currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971291: salutatoi: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: salutatoi
Version: 0.8.0~hg3247.f981c0e99220-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

salutatoi currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971307: python-openstackclient: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-openstackclient
Version: 5.2.1-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-openstackclient currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971306: python-potr: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-potr
Version: 1.0.2-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-potr currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971300: python-bottle-cork: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-bottle-cork
Version: 0.12.0-4
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-bottle-cork currently Build-Depends or Depends on
python3-crypto from PyCrypto. This project is no longer maintained
and PyCryptodome (https://www.pycryptodome.org/en/latest/) provides a
drop in replacement. Please switch to python3-pycryptodome. I'd like
to remove python-crypto before the release of bullseye.

Cheers 



Bug#971309: ansible: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: ansible
Version: 2.9.13+dfsg-1
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

ansible currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971294: wokkel: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: wokkel
Version: 18.0.0-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

wokkel currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971293: sshpubkeys: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: sshpubkeys
Version: 3.1.0-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

sshpubkeys currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971289: beaker: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: beaker
Version: 1.10.0-3
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

beaker currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#971290: python-pysaml2: Switch to python3-pycryptodome

2020-09-28 Thread Sebastian Ramacher
Source: python-pysaml2
Version: 4.5.0-8
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

python-pysaml2 currently Build-Depends or Depends on python3-crypto
from PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers 



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-28 Thread Aurelien Jarno
On 2020-09-28 15:12, Otto Kekäläinen wrote:
> After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> fails with these:
> 
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> 
> The odd thing is that an identical build on Ubuntu Groovy passes OK:
> https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz

Ubuntu has patched their version of cmake to link with -latomic on
riscv64. While patching cmake is a really good idea, the fix is wrong,
the correct think to do is to link with -pthread instead of -lpthread,
and do that for all architectures.

This is the strategy followed for mariadb-10.5 in the attached patch. I
have tested it and it builds fine on Debian.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- mariadb-10.5-10.5.5/debian/patches/riscv64-link-pthread.patch
+++ mariadb-10.5-10.5.5/debian/patches/riscv64-link-pthread.patch
@@ -0,0 +1,10 @@
+--- mariadb-10.5-10.5.5.orig/configure.cmake
 mariadb-10.5-10.5.5/configure.cmake
+@@ -135,6 +135,7 @@ IF(UNIX)
+   IF(NOT LIBRT)
+ MY_SEARCH_LIBS(clock_gettime rt LIBRT)
+   ENDIF()
++  set(THREADS_PREFER_PTHREAD_FLAG ON)
+   FIND_PACKAGE(Threads)
+ 
+   SET(CMAKE_REQUIRED_LIBRARIES 
diff -Nru mariadb-10.5-10.5.5/debian/patches/series mariadb-10.5-10.5.5/debian/patches/series
--- mariadb-10.5-10.5.5/debian/patches/series
+++ mariadb-10.5-10.5.5/debian/patches/series
@@ -13,3 +13,4 @@
 prevent-executable-stack-due-to-objects-compiled-fro.patch
 env-perl-usr-bin-perl.patch
 fix-spelling.patch
+riscv64-link-pthread.patch


Bug#971288: ITP: todo.txt-cli -- a CLI text-based task manager

2020-09-28 Thread David Steele
Package: wnpp
Severity: wishlist
Owner: 'David Steele' 
thanks

* Package name    : todo.txt-cli
  Version : 2.12.0
  Upstream Author : The todo.txt Team 
* URL : https://github.com/todotxt/todo.txt-cli
* License : GPL-3
  Description : A CLI, text-file-based tasking manager


This is the first of a suite of cross-platform tools that can manage
tasks based on a common, simple text file format.


I intend for this package to provide the virtual package (and
executable) "todo", facilitating alternatives support for other
todo.txt-compatible utilities (e.g. topydo).


There is an existing package ("devtodo", popcon 74, maintained by the
Debian QA Group) which provides an executable "todo" on the default
search path. The listed homepage flags the software as unmaintained, and
the last non-QA upload was in 2016. There will be an explicit
"Conflicts" clause for that package.




signature.asc
Description: OpenPGP digital signature


Bug#971286: Version: None in /usr/lib/python3/dist-packages/param-None.egg-info/PKG-INFO

2020-09-28 Thread Tomas Janousek
Package: python3-param
Version: 1.9.3-1
Severity: normal
X-Debbugs-Cc: 

This is obviously wrong, and it also prevents python3-param from being 
reused in --system-site-packages virtualenvs.

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

Kernel: Linux 5.8.0-trunk-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-param depends on:
ii  python3  3.8.2-3

python3-param recommends no packages.

python3-param suggests no packages.

-- no debconf information

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/



Bug#971287: Version: None in /usr/lib/python3/dist-packages/colorcet-None.egg-info

2020-09-28 Thread Tomas Janousek
Package: python3-colorcet
Version: 2.0.2-2+b1
Severity: normal
X-Debbugs-Cc: 

This is obviously wrong, and it also prevents python3-colorcet from being
reused in --system-site-packages virtualenvs.

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

Kernel: Linux 5.8.0-trunk-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-colorcet depends on:
ii  python33.8.2-3
ii  python3-param  1.9.3-1
ii  python3-pyct   0.4.7a3-1

python3-colorcet recommends no packages.

python3-colorcet suggests no packages.

-- no debconf information

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/



Bug#920365: [debian-mysql] Bug#920365: Bug#920365: mariadb_config: improve cross compilation support

2020-09-28 Thread Helmut Grohne
Hi Otto,

On Mon, Sep 28, 2020 at 10:24:16PM +0300, Otto Kekäläinen wrote:
> > While looking into it anyway, I was wondering why you are running cmake
> > directly instead of running it through dh_auto_configure. Can you shed
> > light on that question? Using dh_auto_configure would automatically pass
> > -DCMAKE_SYSTEM_NAME=..., which is required for cross compiling mariadb.
> 
> The cmake line has been manually defined in the debian/rules files
> since the beginning of time and mysql-5.0 packaging or something.
> There are so many customizations – I don't know if we can dismantle
> it.

Yeah, but that seems like "historical cruft" to me. I'm attaching a
patch that makes it use dh_auto_configure. Unfortunately, when I build
it with that patch, I get test suite failures about "debug_sync" being
unknown. I'm not sure whether that is caused by my build environment or
the change. Can you make that work?

For amd64, the generated cmake invocation becomes:

install -d builddir
cd builddir && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
"-DCOMPILATION_COMMENT=Debian unstable " -DMYSQL_SERVER_SUFFIX=-1.1 
-DSYSTEM_TYPE=debian-linux-gnu -DBUILD_CONFIG=mysql_release -DWITH_SSL=bundled 
-DPLUGIN_TOKUDB=NO -DPLUGIN_CASSANDRA=NO -DPLUGIN_AWS_KEY_MANAGEMENT=NO 
-DPLUGIN_COLUMNSTORE=NO -DWITH_INNODB_SNAPPY=ON -DDEB=Debian ..

The stuff that comes before -DCOMPILATION_COMMENT=... is inserted by
debhelper.

Helmut
diff --minimal -Nru mariadb-10.5-10.5.5/debian/changelog 
mariadb-10.5-10.5.5/debian/changelog
--- mariadb-10.5-10.5.5/debian/changelog2020-09-25 18:56:59.0 
+0200
+++ mariadb-10.5-10.5.5/debian/changelog2020-09-28 22:22:58.0 
+0200
@@ -1,3 +1,10 @@
+mariadb-10.5 (1:10.5.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh_auto_configure.
+
+ -- Helmut Grohne   Mon, 28 Sep 2020 22:22:58 +0200
+
 mariadb-10.5 (1:10.5.5-1) unstable; urgency=medium
 
   * New upstream version 10.5.5 (Closes: #968895)
diff --minimal -Nru mariadb-10.5-10.5.5/debian/rules 
mariadb-10.5-10.5.5/debian/rules
--- mariadb-10.5-10.5.5/debian/rules2020-09-17 22:17:28.0 +0200
+++ mariadb-10.5-10.5.5/debian/rules2020-09-28 22:22:57.0 +0200
@@ -22,9 +22,6 @@
 RELEASE := $(shell lsb_release -r -s) # Use changelog based DEB_DISTRIBUTION 
instead?
 TMP:=$(CURDIR)/debian/tmp
 
-CC := $(DEB_HOST_GNU_TYPE)-gcc
-CXX := $(DEB_HOST_GNU_TYPE)-g++
-
 # According to Debian Policy version 4.2.0 builds should be as verbose as
 # possible unless 'terse' is specifically passed.
 ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
@@ -94,18 +91,14 @@
# Remove -DWITH_SSL=bundle if you want to use system OpenSSL, otherwise
# the server will use YaSSL and Connector/C will use GnuTLS.
# Don't build ColumnStore, not mature enough for Debian yet.
-   mkdir -p $(BUILDDIR) && cd $(BUILDDIR) && \
-   sh -c  
'PATH=$${MYSQL_BUILD_PATH:-"/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin"} \
-   CC=${CC} \
-   CXX=${CXX} \
-   NO_UPDATE_BUILD_VERSION=1 \
-   cmake -DCMAKE_INSTALL_PREFIX=/usr \
+   
PATH=$${MYSQL_BUILD_PATH:-"/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin"} \
+   NO_UPDATE_BUILD_VERSION=1 \
+   dh_auto_configure --builddirectory=$(BUILDDIR) -- \
$(CMAKEFLAGS) \
$(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,-DIMPORT_EXECUTABLES=$(CURDIR)/builddir-native/import_executables.cmake)
 \
-DCOMPILATION_COMMENT="$(DEB_VENDOR) $(RELEASE)" \
-DMYSQL_SERVER_SUFFIX="-$(DEB_VERSION_REVISION)" \
-DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
-   -DCMAKE_SYSTEM_PROCESSOR=$(DEB_HOST_ARCH) \
-DBUILD_CONFIG=mysql_release \
-DWITH_SSL=bundled \
-DPLUGIN_TOKUDB=NO \
@@ -113,7 +106,7 @@
-DPLUGIN_AWS_KEY_MANAGEMENT=NO \
-DPLUGIN_COLUMNSTORE=NO \
-DWITH_INNODB_SNAPPY=ON \
-   -DDEB=$(DEB_VENDOR) ..'
+   -DDEB=$(DEB_VENDOR)
 
 # This is needed, otherwise 'make test' will run before binaries have been 
built
 override_dh_auto_build:


Bug#970927: 'mono' returns 'Unhandled Exception'

2020-09-28 Thread GMiller
Installing 'libmono-system-windows-forms4.0-cil' with it's depends solved the 
immediate problem. Perhaps I should have installed the -devel package to run my 
mono application.

Looking closer I also see Ubuntu is behind Debian in the stable mono release.

Garie Miller

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#970789: mmdebstrap: failed to execute qemu-xxx-static with --mode=proot

2020-09-28 Thread Johannes Schauer
Hi,

On Wed, 23 Sep 2020 21:27:04 +0900 Kentaro Hayashi  wrote:
> It was caused by missing -static suffix in mmdebstrap.
> 
>   % cat missing-static.patch
>   diff -uNr mmdebstrap-0.7.1.org/mmdebstrap mmdebstrap-0.7.1/mmdebstrap
>   --- mmdebstrap-0.7.1.org/mmdebstrap 2020-09-18 20:43:42.0 +0900
>   +++ mmdebstrap-0.7.1/mmdebstrap 2020-09-23 21:05:29.536185248 +0900
>   @@ -2214,7 +2214,7 @@
># --qemu
>if (defined $options->{qemu}) {
>  if ($options->{mode} eq 'proot') {
>   -push @chrootcmd, "--qemu=qemu-$options->{qemu}";
>   +push @chrootcmd, "--qemu=qemu-$options->{qemu}-static";
>  } elsif ($options->{mode} eq 'fakechroot') {
>  # Make sure that the fakeroot and fakechroot shared
>  # libraries exist for the right architecture
> 


did you try installing the package qemu-user?

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#971285: rsync FTCBFS: build vs host confusion

2020-09-28 Thread Helmut Grohne
Source: rsync
Version: 3.2.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rsync fails to cross build from source, because the configure script
confuses "build" and "host" when it decides whether to check for simd
instructions. It attempts to enable simd whenever one builds on amd64,
but it should attempt to enable simd whenever one builds for amd64.
Please consider applying the attached patch to fix that.

Helmut
--- rsync-3.2.3.orig/configure.ac
+++ rsync-3.2.3/configure.ac
@@ -211,7 +211,7 @@
 
 if test x"$enable_simd" != x"no"; then
 # For x86-64 SIMD, g++ >=5 or clang++ >=7 is required
-if test x"$build_cpu" = x"x86_64"; then
+if test x"$host_cpu" = x"x86_64"; then
 	AC_LANG(C++)
 	AC_RUN_IFELSE([AC_LANG_PROGRAM([[#include 
 #include 


Bug#965456: closed

2020-09-28 Thread Kevin M. Rosenberg
close



Bug#971005: [debian-mysql] Bug#971005: mariadb-10.5: unregistered vendor copy of readline

2020-09-28 Thread Helmut Grohne
Control: severity -1 wishlist
Control: retitle -1 make it harder to accidentally use the bundled readline

Hi Otto,

On Mon, Sep 28, 2020 at 11:02:03AM +0300, Otto Kekäläinen wrote:
> There is indeed in the sources extra/readline/.
> 
> Looking at upstream commit logs it has been there at least since 2014
> (and traces of the same are in Oracle mysql sources too). This is not
> something new that has been introduced in 10.5, but rather very old
> legacy.
> 
> The cmake/readline.cmake file should ensure the system libedit is
> always used in Debian.

I stand corrected! I only managed to get into this situation by failing
to provide all relevant build-depends. My fault. It really does build
using the system libedit by default as can be seen from the buildd logs.

The only thing that you might want to consider changing is making it
harder to accidentally use the bundled readline.

> I will experiment by removing the whole extra/readline/ from the
> Debian sources and then file an issue about it upstream.

I think the situation is fine from an upstream pov. It really does
prefer libedit when libedit is available.

I've attemped adding a "rm -Rf extra/readline" to override_dh_auto_clean
and that seems to just work. When you build a source package after
performing a binary package build you get a pile of warnings abouts
deleted files being ignored as a difference, but I'm used to that from
other packages already. Does that work for you?

Given the above, I see basically two options for moving forward:
 a) Close the bug with no action (as indeed the embedded copy is
unused).
 b) Delete it during clean.

I'm happy with either choice.

Helmut



Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback

2020-09-28 Thread Asher Gordon
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=209421

Hi Moritz,

Moritz Mühlenhoff  writes:

> Yeah, I'm also bitten by this for my day-to-day workflows, but
> unfortunately this was removed upstream, this is not a Debian-specific
> patch, so this needs to be fixed upstream, before it becomes available
> in Debian again.

OK, I forwarded this upstream here:
https://bugzilla.kernel.org/show_bug.cgi?id=209421

Thanks,
Asher

-- 
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature


Bug#971123: kxd: FTBFS: dh_auto_test: error: make -j4 test returned exit code 2

2020-09-28 Thread Alberto Bertogli

On Sun, Sep 27, 2020 at 08:45:30PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.14-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is due to a change in x509 certificate handling in Go 1.15. It has 
been fixed in upstream release 0.15.


In this repo you can find an updated Debian package for kxd 1.15; I 
don't have access to upload it to salsa directly, and it would need a DD 
to do a review and upload in any case:


https://blitiri.com.ar/git/r/debian:kxd/

Thanks,
Alberto



Bug#971203: dpkg-source cause gap-atlasrep to FTBFS for no reason

2020-09-28 Thread Bill Allombert
On Mon, Sep 28, 2020 at 05:19:33AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2020-09-27 at 22:53:13 +0200, Bill Allombert wrote:
> > On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> > > During a rebuild of all packages in sid, your package failed to build
> > > on amd64.
> > > 
> > > > dpkg-source: error: pathname 
> > > > '/<>/debian/gaproot/pkg/AtlasRep' points outside source 
> > > > root (to '/<>')
> 
> > $ apt-get source gap-atlasrep
> > Fetched 1351 kB in 2s (722 kB/s)
> > dpkg-source: info: extracting gap-atlasrep in gap-atlasrep-2.1.0
> > dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
> > dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: applying doc-makefile
> > dpkg-source: info: applying default-dir
> > dpkg-source: error: pathname
> > 'gap-atlasrep-2.1.0/debian/gaproot/pkg/AtlasRep' points outside source
> > root (to '/tmp/gap-atlasrep-2.1.0')
> > E: Unpack command 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc'
> > failed.
> > 
> > There is no rationale to reject such a symlink which does not point
> > _outside_ the source root, but _to_ the source root.
> > This leads to a spurious FTBFS.
> 
> Right, this is due to a regex not matching when the basedir is the
> same as the canonicalized symlink target. I've fixed this, but need to
> adapt the new test case.
> 
> > Also I am concerned that developers might need to unpack old packages
> > with symlinks in them. There should be a way to do it, if only to fix
> > the packaging.
> 
> I guess it might make sense indeed to disable this when running under
> --no-check.

Another issue is that dpkg-source -b still allows to build such packages
in the first place. So I am not completly sure about why you need to
check symlinks.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#971284: ITP: python-echo: Callback Properties in Python

2020-09-28 Thread Josue Ortega
Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

* Package name: python-echo
  Version : 0.5
  Upstream Author : Thomas Robitaille 
* URL : https://github.com/glue-viz/echo
* License : MIT
  Programming Lang: Python
  Description : Echo is a small library for attaching callback functions to
  property state changes.


signature.asc
Description: PGP signature


Bug#920365: [debian-mysql] Bug#920365: Bug#920365: mariadb_config: improve cross compilation support

2020-09-28 Thread Otto Kekäläinen
> I've started looking into it. I noticed a few embedded code copies. I've
> filed #971005 about readline. Bundling an ssl library seems like a very
> bad idea to me. The outcome of these will have significant impact on how
> cross compilation can be implemented.

I've filed issues upstream that they should build against the system
gnutls and system wolfssl. I believe the server now builds against the
system gnutls but there are still bundled codes in the sources.

> While looking into it anyway, I was wondering why you are running cmake
> directly instead of running it through dh_auto_configure. Can you shed
> light on that question? Using dh_auto_configure would automatically pass
> -DCMAKE_SYSTEM_NAME=..., which is required for cross compiling mariadb.

The cmake line has been manually defined in the debian/rules files
since the beginning of time and mysql-5.0 packaging or something.
There are so many customizations – I don't know if we can dismantle
it.



Bug#969321: transition: GNOME 3.38, libmutter-7-0

2020-09-28 Thread Simon McVittie
On Fri, 25 Sep 2020 at 09:34:32 +0200, Emilio Pozuelo Monfort wrote:
> Let's go ahead with the mutter/shell transition.

This seems to be progressing OK, after a bit of a fight with mozjs78
to get it passing tests on mipsen.

mutter transition is green:
https://release.debian.org/transitions/html/auto-mutter.html
* I think you can ignore the mutter row
* you can ignore the gnome-remote-desktop row, it has some weird
  dependencies to make sure it has a pipewire-enabled mutter without
  caring whether it's 3.36 or 3.38 (I'll probably simplify them after
  this transition is over)
* you can ignore gnome-shell-xrdesktop, it's RC-buggy and not in testing

The other important part of this transition is
https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
* please add a hint to remove gnome-shell-extension-easyscreencast from
  testing (acked by maintainer in #971040)
* otherwise everything looks fine

Some third-party extensions will almost certainly be broken by the new
Shell without actually having their dependencies broken. The only one
I know about is gnome-shell-extension-hard-disk-led, which should maybe
be hinted out of testing too.

We also need to close #970883 to let gjs through, which I'll do at some
point before gnome-shell's migration timer runs out (or feel free to close
it at whatever time seems most appropriate if I don't get round to it).

smcv



Bug#887007: [debian-mysql] Bug#887007: Bug#887007: my.cnf handling collides with MySQL

2020-09-28 Thread Otto Kekäläinen
> On Mon, Sep 28, 2020 at 08:57:11PM +0300, Otto Kekäläinen wrote:
> > I also see that mysql-8.0 added quite a few conflicts on mariadb-*. In
> > mysql-5.7 only the server conflicted with the mariadb equivalent.
>
> [...]
>
> > So having any kind of co-installability for even the clients does not
> > seem possible right now.
>
> Then how does this bug arise?

If somebody wanted to run MariaDB Server (which depends on MariaDB
Client) and then also have MySQL Client, it would not work due to the
Conflicst defined in mysql-8.0 control file:

# apt install mysql-client-core-8.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  bzip2 cracklib-runtime file galera-4 krb5-locales libbrotli1
libcgi-fast-perl libcgi-pm-perl libclone-perl libcrack2 libcurl4
libdbd-mariadb-perl libdbi-perl libencode-locale-perl libexpat1
libfcgi-perl
  libgflags2.2 libgssapi-krb5-2 libhtml-parser-perl
libhtml-tagset-perl libhtml-template-perl libhttp-date-perl
libhttp-message-perl libicu67 libio-html-perl libjudydebian1
libk5crypto3 libkeyutils1 libkrb5-3
  libkrb5support0 libldap-2.4-2 libldap-common libltdl7
liblwp-mediatypes-perl libmagic-mgc libmagic1 libncurses6
libnghttp2-14 libodbc1 libpcre2-posix2 libpopt0 libprocps8 libpsl5
libpython3-stdlib
  libpython3.8-minimal libpython3.8-stdlib libreadline5 librtmp1
libsasl2-2 libsasl2-modules libsasl2-modules-db libsnappy1v5
libsqlite3-0 libssh2-1 libterm-readkey-perl libtimedate-perl
liburi-perl libwrap0
  libxml2 libxxhash0 lsof mime-support odbcinst odbcinst1debian2
procps psmisc publicsuffix python3 python3-minimal python3-mysqldb
python3.8 python3.8-minimal rocksdb-tools rsync socat unixodbc
wamerican
  xz-utils
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libedit2 mariadb-common
The following packages will be REMOVED:
  mariadb-backup mariadb-client mariadb-client-10.5
mariadb-client-core-10.5 mariadb-plugin-connect
mariadb-plugin-cracklib-password-check mariadb-plugin-gssapi-client
mariadb-plugin-gssapi-server
  mariadb-plugin-mroonga mariadb-plugin-oqgraph mariadb-plugin-rocksdb
mariadb-plugin-s3 mariadb-plugin-spider mariadb-server
mariadb-server-10.5 mariadb-test
The following NEW packages will be installed:
  libedit2 mysql-client-core-8.0



Bug#971283: quodlibet doesn't remember browser-settings any more

2020-09-28 Thread Klaumi Klingsporn
Package: quodlibet
Version: 4.3.0-1
Severity: normal

Dear Maintainer,

for a few months now, I think since version 4.3.0 quodlibet doesn't remember my 
browser settings
any more. I use to have the browser-layout set to 'widescreen', which means 
that the columns for
artist, genre and label are located beside the songlist and not above it. Now I 
can set this
option and the layout changes as wanted but the next time I start quodlibet the 
layout is set back
again.

It's a little bit annoying and should be fixed!

Thanks for maintaining the program!

Klaumi


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

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

Versions of packages quodlibet depends on:
ii  exfalso  4.3.0-1
ii  gir1.2-gst-plugins-base-1.0  1.18.0-2
ii  gir1.2-gstreamer-1.0 1.18.0-3
ii  gir1.2-keybinder-3.0 0.3.2-1+b1
ii  gstreamer1.0-alsa1.18.0-2
ii  gstreamer1.0-plugins-base1.18.0-2
ii  gstreamer1.0-plugins-good1.18.0-1
ii  gstreamer1.0-plugins-ugly1.18.0-1
ii  gstreamer1.0-pulseaudio  1.18.0-1
ii  python3  3.8.2-3

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.03.24.11-2
ii  gir1.2-webkit2-4.0  2.30.1-1
ii  lxqt-notificationd [notification-daemon]0.14.1-1+b1
ii  mate-notification-daemon [notification-daemon]  1.24.1-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.17.5-4
ii  python3-dbus1.2.16-3
ii  python3-pyinotify   0.9.6-1.3
ii  xfce4-notifyd [notification-daemon] 0.6.1-1

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.18.0-2+b1

-- no debconf information



Bug#971281: RFS: golang-github-axgle-mahonia/0.0~git20180208.3358181-1 [ITP] -- Character-set conversion library implemented in Go.

2020-09-28 Thread Arun Kumar Pariyar
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "golang-github-axgle-mahonia":

 * Package name: golang-github-axgle-mahonia
   Version : 0.0~git20180208.3358181-1
   Upstream Author : axgle 
 * URL : https://github.com/axgle/mahonia
 * License : BSD-3-clause
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-axgle-mahonia
   Section : devel

It builds those binary packages:

  mahonia - Character-set conversion library implemented in Go. (program)
  golang-github-axgle-mahonia-dev - Character-set conversion library 
implemented in Go. (library)

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

  https://mentors.debian.net/package/golang-github-axgle-mahonia/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-axgle-mahonia/golang-github-axgle-mahonia_0.0~git20180208.3358181-1.dsc

Changes for the initial release:

 golang-github-axgle-mahonia (0.0~git20180208.3358181-1) unstable; 
urgency=medium
 .
   * Initial release (Closes: #971049)

Regards,
--
  Arun Kumar Pariyar



Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

2020-09-28 Thread Michael Biebl
Package: systemd
Version: 246.6-1
Severity: important

Upstream changed the paths in systemd.pc from prefix to rootprefix in
v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir:
https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b

This breaks packages which use pkg-config to determine those paths and
where .install files reference /usr/. An example is mandos.

I think we should revert this change. I don't see a compelling reason to
move those files from /usr to /lib given that we require /usr to be
pre-mounted by initramfs, if it's separate.
Moving files from /usr to /lib files kinda backwards nowadays.

I intend to apply a patch like the attached one in Debian.
That said, I hope I can convince Lennart to revert this change upstream
as well.

Thoughts, Comments?

Michael
diff --git a/src/core/systemd.pc.in b/src/core/systemd.pc.in
index 3af9f99830..699a9748f2 100644
--- a/src/core/systemd.pc.in
+++ b/src/core/systemd.pc.in
@@ -65,16 +65,16 @@ systemdshutdowndir=${systemd_shutdown_dir}
 tmpfiles_dir=/usr/lib/tmpfiles.d
 tmpfilesdir=${tmpfiles_dir}
 
-sysusers_dir=${rootprefix}/lib/sysusers.d
+sysusers_dir=${prefix}/lib/sysusers.d
 sysusersdir=${sysusers_dir}
 
-sysctl_dir=${rootprefix}/lib/sysctl.d
+sysctl_dir=${prefix}/lib/sysctl.d
 sysctldir=${sysctl_dir}
 
-binfmt_dir=${rootprefix}/lib/binfmt.d
+binfmt_dir=${prefix}/lib/binfmt.d
 binfmtdir=${binfmt_dir}
 
-modules_load_dir=${rootprefix}/lib/modules-load.d
+modules_load_dir=${prefix}/lib/modules-load.d
 modulesloaddir=${modules_load_dir}
 
 catalog_dir=/usr/lib/systemd/catalog
diff --git a/src/libsystemd/sd-path/sd-path.c b/src/libsystemd/sd-path/sd-path.c
index 26d2341c2b..414e249884 100644
--- a/src/libsystemd/sd-path/sd-path.c
+++ b/src/libsystemd/sd-path/sd-path.c
@@ -369,19 +369,19 @@ static int get_path(uint64_t type, char **buffer, const 
char **ret) {
 return 0;
 
 case SD_PATH_SYSUSERS:
-*ret = ROOTPREFIX_NOSLASH "/lib/sysusers.d";
+*ret = "/usr/lib/sysusers.d";
 return 0;
 
 case SD_PATH_SYSCTL:
-*ret = ROOTPREFIX_NOSLASH "/lib/sysctl.d";
+*ret = "/usr/lib/sysctl.d";
 return 0;
 
 case SD_PATH_BINFMT:
-*ret = ROOTPREFIX_NOSLASH "/lib/binfmt.d";
+*ret = "/usr/lib/binfmt.d";
 return 0;
 
 case SD_PATH_MODULES_LOAD:
-*ret = ROOTPREFIX_NOSLASH "/lib/modules-load.d";
+*ret = "/usr/lib/modules-load.d";
 return 0;
 
 case SD_PATH_CATALOG:


Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5

2020-09-28 Thread Paul Gevers
Hi Otto,

Thanks for contacting me.

On 28-09-2020 10:22, Otto Kekäläinen wrote:
> The command3 seems to be failing on unexpected output from MariaDB (if
> I read the output correctly).

Yes.

> -creating database testdbname: success.
> -verifying database testdbname exists: success.
> +sanity check failed for dbc_dbadmin.
> 
> -dropping database testdbname: success.
> -verifying database testdbname was dropped: success.
> +sanity check failed for dbc_dbadmin.
> 
> -checking privileges on database testdbname for testdbuser@localhost:
> user creation needed.
> -granting access to database testdbname for testdbuser@localhost: success.
> -verifying access for testdbuser@localhost: success.
> +sanity check failed for dbc_dbadmin.
> 
> -checking privileges on database testdbname for testdbuser@localhost: ok.
> +sanity check failed for dbc_dbadmin.
> 
> -revoking access to database testdbname from testdbuser@localhost: success.
> +sanity check failed for dbc_dbadmin.
> 
> 
> Maybe the test should be updated to expect new strings..?

What, ignore a "sanity check"? That must be there on purpose. Let me
check what's going on.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#971280: quodlibet segfauts trying to play some files in archive

2020-09-28 Thread Klaumi Klingsporn
Package: quodlibet
Version: 4.3.0-1
Severity: normal

Dear Maintainer,

when I try to play some files in my archive quodlibet segfauts (core dumped).
I can play the files with other players and I'm sure I've played them with
quodlibet maybe a year ago.

In a terminal I get:
"(io.github.quodlibet.QuodLibet:23043): WARNING **: 20:27:58.426: Binding 
'XF86AudioRandomPlay' failed!
E: 4.596: errorreport.main.errorhook: 
faulthandling.py:138:raise_and_clear_error:
 quodlibet.errorreport.faulthandling.FaultHandlerCrash: Fatal Python error: 
Segmentation fault
E: 9.698: formats._misc.MusicFile: __init__.py:402:__init__:
 quodlibet.formats._misc.AudioFileError: can't sync to MPEG frame terminate 
called after throwing an instance of 'std::runtime_error'
  what():  Unable to read configuration
Abgebrochen (Speicherabzug geschrieben)"

When I restart the progam I get an error-log-message inside quodlibet:
"{'event_id': 'e949e3acce534947a23c7c09d3625e9d',
'exception': {'values': [{'module': 'quodlibet.errorreport.faulthandling',
  'stacktrace': {'frames': [{'abs_path': 
'/usr/lib/python3/dist-packages/quodlibet/errorreport/faulthandling.py',
 'context_line': ''
 'raise '
 'FaultHandlerCrash(text)',
 'filename': 'quodlibet/errorreport/faulthandling.py',
 'function': 'raise_and_clear_error',
 'lineno': 138,
 'module': 'quodlibet.errorreport.faulthandling',
 'post_context': ['',
 '',
 'def '
 'crash():',
 ''
 '"""Makes '
 'the '
 'process '
 'segfault. '
 'For '
 'testing '
 'purposes"""',
 ''],
 'pre_context': [''
 '_fileobj.truncate()',
 ''
 'except '
 'IOError:',
 ''
 'print_exc()',
 ''
 'else:',
 ''
 'if '
 'text:'],
 'vars': {'text': "'Fatal "
 'Python '
 'error: '
 'Segmentation '
 "fault'"}}]},
  'type': 'FaultHandlerCrash',
  'value': 'Fatal '
 'Python '
 'error: '
 'Segmentation '
 'fault'}]},
'extra': {'sys.argv': ("'/usr/bin/quodlibet'",)},
'fingerprint': ['{{ default }}', ''],
'level': 40,
'message': 'FaultHandlerCrash: Fatal '
   'Python error: '
   'Segmentation fault',
'modules': {'python': '3.8.6'},
'platform': 'python',
'project': '142415',
'release': '4.3.0',
'repos': {},
'sdk': {'name': 'raven-python',
  'version': '6.5.0'},
'server_name': 'default',
'tags': {'build_info': 'NONE',
  'build_type': 'default',
  'gtk_backend': 'X11',
  'gtk_version': '3.24.23',
  'mutagen_version': '1.45.1',
  'platform': 'Linux-5.8.0-2-amd64-x86_64-with-glibc2.29',
  'pycairo_version': '1.16.2',
  'pygobject_version': '3.38.0',
  'python_version': '3.8.6'},
'time_spent': None,
'timestamp': datetime.datetime(2020, 9, 28, 18, 24, 0, 57141)}"

Would be nice if it worked again ;-)

Klaumi


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

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

Versions of packages quodlibet depends on:
ii  exfalso  4.3.0-1
ii  gir1.2-gst-plugins-base-1.0  1.18.0-2
ii  gir1.2-gstreamer-1.0 1.18.0-3
ii  gir1.2-keybinder-3.0 0.3.2-1+b1
ii  gstreamer1.0-alsa1.18.0-2
ii  gstreamer1.0-plugins-base1.18.0-2
ii  gstreamer1.0-plugins-good1.18.0-1
ii  gstreamer1.0-plugins-ugly1.18.0-1
ii  gstreamer1.0-pulseaudio  1.18.0-1
ii  python3  3.8.2-3

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.03.24.11-2
ii  gir1.2-webkit2-4.0  2.30.1-1
ii  lxqt-notificationd [notification-daemon]0.14.1-1+b1
ii  mate-notification-daemon [notification-daemon]  1.24.1-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.17.5-4
ii  python3-dbus1.2.16-3
ii  python3-pyinotify   0.9.6-1.3
ii  xfce4-notifyd [notification-daemon] 0.6.1-1

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.18.0-2+b1

-- no debconf information



Bug#887007: [debian-mysql] Bug#887007: Bug#887007: my.cnf handling collides with MySQL

2020-09-28 Thread Robie Basak
I think the original idea was:

Keep the client configuration common to both MySQL and MariaDB as much
as possible. This is because we do want the clients to be coinstallable
and also because users often don't have control of the client in use
since it goes through a client library they didn't choose to build.

So in this world, client configuration would be shipped by mysql-common
only.

I may be remembering this wrong, and there might have been a
misunderstanding at the time, so I welcome any corrections to this.

Then it'd only be the _server packages_ that register against
update-alternatives. Only one of the servers can be active at once,
which is reasonable. And then there would be no collision, since we
already ensure that only one server is active at once.

(If we want to allow coinstallable servers then we also need to complete
the cooperative handling of /var/lib/mysql that we agreed, as well as
disentangle the service files and binaries and default listening ports
in addition to /etc/mysql).

On Mon, Sep 28, 2020 at 08:57:11PM +0300, Otto Kekäläinen wrote:
> I also see that mysql-8.0 added quite a few conflicts on mariadb-*. In
> mysql-5.7 only the server conflicted with the mariadb equivalent.

[...]

> So having any kind of co-installability for even the clients does not
> seem possible right now.

Then how does this bug arise?


signature.asc
Description: PGP signature


Bug#971279: ITP: sphinx-markdown-tables -- Sphinx extension for rendering markdown tables

2020-09-28 Thread Peter Wienemann
Package: wnpp
Severity: wishlist
Owner: Peter Wienemann 

  Package name: sphinx-markdown-tables
  Version : 0.0.15
  Upstream Author : Ryan Fox
  URL : https://github.com/ryanfox/sphinx-markdown-tables
  License : GPL-3.0
  Programming Lang: Python
  Description : Sphinx extension for rendering markdown tables

While Sphinx supports markdown thanks to the recommonmark extension,
the latter does not cover tables. The sphinx-markdown-tables extension
remedies this shortcoming.

This package will be team-maintained by the Debian Python Team.



  1   2   >