Bug#958444: protobuf: Please add protobuf-java-util to the protobuf-java package

[GCS]

On Wed, Apr 29, 2020 at 4:17 PM Olek Wojnar  wrote:
> On Thu, Apr 23, 2020 at 10:50 AM Olek Wojnar  wrote:
> Did you have an opportunity to make any progress over the weekend?
 Had enough things to do, but of course I've tried to update the
libtruth-java package and failed. :(
I think the Java build dependencies should be handled by someone who
is more proficient with Java. :-/

> Offer to help is still open and I'm happy to push a branch to your VCS with 
> what I've already done. Hope you're having a nice week!
 How big is your changes? You can send that to me as a patch.

Regards,
Laszlo/GCS

Bug#956017: gnome-maps: no results when searching for an address

[Phil Wyett]

On Wed, 2020-04-29 at 22:49 +0100, Phil Wyett wrote:
> On Mon, 6 Apr 2020 22:47:46 +0100 Simon McVittie 
> wrote:
> > On Mon, 06 Apr 2020 at 10:44:13 +0200, Keno Goertz wrote:
> > > when entering an address into the search box of GNOME Maps on
> > > Debian
> > > Stable, I get a loading animation for a few seconds and then "No
> results
> > > found".
> > 
> > On Mon, 06 Apr 2020 at 12:35:32 +0200, Keno Goertz wrote:
> > > Turns out geocode-glib uses https://nominatim.gnome.org, which is
> > > currently down (I don't know since when).
> > 
> > It sounds as though this is resolved for now.
> > 
> > For the future: this service is outside Debian's control, so when it
> > isn't working, there is little the Debian maintainers of gnome-maps
> can
> > do about that.
> > 
> > smcv
> > 
> > 
> 
> Hi all,
> 
> Now this bug has been resolved. Can we mark it as complete and closed?
> 
> Regards
> 
> Phil
> 


Hi,

Oops, did this one when tired and. Please ignore.

Regards

Phil

-- 

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#959157: fix for CVE-2020-1749 in linux-image-4.19.0-9 breaks wireguard

[Luca Filipozzi]

Package: wireguard
Version: 1.0.20200319-1~bpo10+1
Severity: grave

Hello wireguard package maintainer,

DSA 4667-1, a Linux security update released on 2020-04-28, includes a
fix for CVE-2020-1749 that changes ipv6_stub to use ip6_dst_lookup_flow
instead of ip6_dst_lookup.

In wireguard-linux-compat/src/compat/compat.h, the following must be
corrected such that ipv6_dst_lookup_flow is used for Debian linux kernel
4.19.0-9:

 99 #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) && LINUX_VERSION_CODE >= 
KERNEL_VERSION(3, 16, 83)
100 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup_flow(b, c, d)
101 #elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 5) && LINUX_VERSION_CODE 
>= KERNEL_VERSION(5, 4, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 18) 
&& !defined(ISRHEL82))
102 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, , c) + 
(void *)0 ?: dst
103 #endif

Otherwise, line 102 is used and the code fails to build from source.

Thanks,

Luca

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

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

Versions of packages wireguard depends on:
ii  wireguard-dkms   0.0.20200318-1~bpo10+1
ii  wireguard-tools  1.0.20200319-1~bpo10+1

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

[Buck]

Package: simple-cdd
Version: 0.6.5
Followup-For: Bug #958277



> The maintainer scripts for each individual package and their debconf
> templates are where to look.

I recommend putting this in the docs.


> I wouldn't expect the "hello" program to document the fundamentals of
> computer science, or the working of electricity, or atomic theory, or
> the origins of the universe... even though all of those are, ostensibly,
> all relevent.

I would, in the way that docs are supposed to do that.  I think you don't know 
a lot about documentation theory.  You do all of that by saying "This project 
requires a computer running Debian," and if people aren't sure they have that 
then they research Debian, and computers, and their dependencies, etc.  That's 
just the way all documenation is always written.  Anything else is just 
scribbles.

Anyway you effectively do that in yours, so it's not material here.  But it is 
similar to how the debian-installer doc should reference the HowTo, which 
should reference the README as the authoritative doc.  Otherwise we're all just 
clicking around desperate for anything that says "simple-cdd" on it.

>> Great idea!  Are you aware that the README does not mention
>> "debconf-get-selections" once?  So it would take someone who does this
>> every day to think of this excellent solution.  Thank you for sharing
>> this.  I recommend adding it to the README, maybe the HowTo..
>
> This could perhaps be briefly touched on in the simple-cdd README, and
> referencing relevent chapters of the debian-installer manual.

It probably belongs in the same section that the first item does about debconf 
templates.  In a section about how to create a useful preseed file.

> Yes, the README should be the authorative source for simple-cdd.

Okay great.  Then the HowTo and the debian-installer manual should reference 
that.

> If you load the preseeding after the question has already been asked,
> then at best, it doesn't magically travel through time an un-ask the
> question... at best, it does nothing, at worst, it might trigger bugs.

That makes sense but it does not relate to anything clear about how 
NAME.preseed works, how --preseed works, and how --auto-preseed works.  Please, 
I've asked this every way that is possible.  Please document this interplay.

> an't know for sure, but sounds like it *might* be a bug in the code.
>
> If you could re-try with "simple-cdd --locale=en_CH --keyboard=us" with
> an empty ./profiles directory and empty ./images directory (you can
> probably leave ./tmp, since it sounds like you don't have much
> bandwidth), that would be great.

I did this, moved profiles/ and deleted images/.  The new image was generated 
in seconds which makes me wonder if I was really doing what you want.

Anyway, the result is the same.  I am asked what installer to use, I choose 
regular "Install" and my first question is what language to use.

One difference is you wrote "simple-cdd --locale=en_CH --keyboard=us" but I 
used "build-simple-cdd --locale=en_CH --keyboard=us" and I think that was just 
a typo right?  Anyway I also did it your way and the result was the same.

So it's looking like a bug.  I will do more testing if you want, including a 
new images/ directory.

> it sounds like you don't have much
> bandwidth

I wouldn't say that.  But building these CDs every time I want to test a new 
config option is taking a toll, sure.

Bug#959064: ignition-transport FTBFS in testing.

[Benjamin Kaduk]

On Thu, Apr 30, 2020 at 03:40:30AM +0100, peter green wrote:
> On 29/04/2020 17:47, Jochen Sprickerhof wrote:
> >
> > What I found up to now:
> >
> > - pkg-config=0.29.2-1:
> >
> >   $ pkg-config --cflags-only-I libzmq
> >   -isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.2
> >
> > - Whereas pkg-config=0.29-6 (or pkgconfig):
> >
> >   $ pkg-config --cflags-only-I libzmq
> >   -I/usr/include/pgm-5.2
> >
> > So the recent update of pkg-config has a new behaviour, introduced in
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=97337
> >
> So to clarify the situation as I now understand it (it took me a couple of 
> readings of the mail for it to sink in)
> 
> The behavior of pkg-config has changed so that --cflags-only-I now lets 
> through "-isystem" as well as "-I"
> 
> This lets though a -isystem parameter with a space which was previously 
> suppressed (not because it had a space but because it was a -isystem 
> parameter rather than a -I parameter)

I did not actually know that -isystem would still work with*out* the space!

> And the space in said parameter breaks cmake.
> 
> > Changing -isystem /usr/include/mit-krb5 to -isystem/usr/include/mit-krb5 
> > works in the .pc file(s) works around this but man gcc indicates that a 
> > space after -isystem seems fine as well.
> >
> Investigating further it seems that the use of -isystem in krb5 and the space 
> after it are the results of a Debian patch (upstream uses -I with no space). 
> So it seemed to me that the expedient way to fix the build failure was just 
> to change the krb5 patch and that this would actually reduce the delta from 
> upstream. I went ahead and did that in Raspbian. A debdiff should appear soon 
> at https://debdiffs.rapsbian.org/main/k/krb5/

FWIW we have to have this krb5 patch in Debian because we divide our
headers into krb5-multidev (which can coexist with the other major krb5
implementation, heimdal), and libkrb5-dev that installs symlinks in the
global location.  Our pkg-config files have to work with the -multidev
variant, which has the headers in a non-default path, but we still need
them treated as system headers, hence this patch.

I think it would be appropriate to open a wishlist bug against krb5 so we
remember to change this the next time we do an upload.

-Ben

Bug#873550: Your suspension notification

[Support Inc]

 


Hello,


Your account has been suspended.
Update the information to 
correct the problem.






RESTART 
MEMBERSHIP






–Your friends at Netflix



















  

Bug#698981: Your suspension notification

[Support Inc]

 


Hello,


Your account has been suspended.
Update the information to 
correct the problem.






RESTART 
MEMBERSHIP






–Your friends at Netflix



















  

Bug#959156: transmission-daemon: Service file contains erroneous ExecStop directive

[Tobias Umbach]

Package: transmission-daemon
Version: 2.94-2
Severity: minor

Dear Maintainer,

the bundled service file for transmission-daemon includes the following
directive:

ExecStop=/bin/kill -s STOP $MAINPID

As I understand it, SIGSTOP only halts a process which can later be
resumed using SIGCONT, which means stopping a transmission-daemon
instance only leaves a stopped process for systemd to kill after the
configured ExecStop command has completed. Since the directive doesn't
really do what it was probably intended to do -- and since systemd's
default stopping behavior seems to agree with transmission-daemon just
fine -- I would suggest dropping the ExecStop directive.

Regards,
- Tobias Umbach

Bug#959155: shotwell: please provide a version of shotwell without webkit

[Rogério Brito]

Package: shotwell
Version: 0.30.8-1
Severity: wishlist

Hi.

It would be great to have a leaner version of shotwell without webkit (and,
more generally, without the "social" features of sharing photos on "social
websites").


Thanks in advance,

Rogério Brito.

-- Package-specific info:

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

Kernel: Linux 5.6.0-trunk-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8), 
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shotwell depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-cli 0.36.0-1
ii  libc6 2.30-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libexif12 0.6.21-6
ii  libgcr-base-3-1   3.36.0-2
ii  libgcr-ui-3-1 3.36.0-2
ii  libgdata220.17.12-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libgee-0.8-2  0.20.3-1
ii  libgexiv2-2   0.12.0-2
ii  libglib2.0-0  2.64.2-1
ii  libgphoto2-6  2.5.24-1
ii  libgphoto2-port12 2.5.24-1
ii  libgstreamer-plugins-base1.0-01.16.2-4
ii  libgstreamer1.0-0 1.16.2-2
ii  libgtk-3-03.24.18-1
ii  libgudev-1.0-0233-1
ii  libjson-glib-1.0-01.4.4-2
ii  libpango-1.0-01.44.7-4
ii  libpangocairo-1.0-0   1.44.7-4
ii  libraw19  0.19.5-1
ii  librsvg2-common   2.48.3-1
ii  libsoup2.4-1  2.70.0-1
ii  libsqlite3-0  3.31.1-5
ii  libwebkit2gtk-4.0-37  2.28.2-2
ii  libxml2   2.9.10+dfsg-5
ii  shotwell-common   0.30.8-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#959154: Dead link for Debian KDE Team "Working with symbols files"

[Nicholas D Steeves]

Package: debmake-doc
Version: 1.14-1
Severity: normal

Hi Osamu Aoki,

Today I noticed that this document has a dead link in:

  https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#symbols
  specifically
  https://pkg-kde.alioth.debian.org/symbolfiles.html

In #debian-qt-kde ScottK confirmed that this is the intended replacement:

  https://qt-kde-team.pages.debian.net/symbolfiles.html

Thanks,
Nicholas

Bug#959153: tpm-udev: udev is not in depends

[Alvin Chen]

Source: tpm-udev
Severity: important

I found tpm-udev uses udevadm in tpm-udev.postinst script, but udev is
not listed in it's depends. which may cause package setting breaks.

log:
-
Adding group `tss' (GID 108) ... Done.
Adding system user `tss' (UID 106) ...
Adding new user `tss' (UID 106) with group `tss' ...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
Not creating home directory `/var/lib/tpm'.
/var/lib/dpkg/info/tpm-udev.postinst: 26: udevadm: not found
--

Regards,
Alvin Chen

Bug#959064: ignition-transport FTBFS in testing.

[peter green]

On 29/04/2020 17:47, Jochen Sprickerhof wrote:


What I found up to now:

- pkg-config=0.29.2-1:

  $ pkg-config --cflags-only-I libzmq
  -isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.2

- Whereas pkg-config=0.29-6 (or pkgconfig):

  $ pkg-config --cflags-only-I libzmq
  -I/usr/include/pgm-5.2

So the recent update of pkg-config has a new behaviour, introduced in

https://bugs.freedesktop.org/show_bug.cgi?id=97337


So to clarify the situation as I now understand it (it took me a couple of 
readings of the mail for it to sink in)

The behavior of pkg-config has changed so that --cflags-only-I now lets through 
"-isystem" as well as "-I"

This lets though a -isystem parameter with a space which was previously 
suppressed (not because it had a space but because it was a -isystem parameter 
rather than a -I parameter)

And the space in said parameter breaks cmake.


Changing -isystem /usr/include/mit-krb5 to -isystem/usr/include/mit-krb5 works 
in the .pc file(s) works around this but man gcc indicates that a space after 
-isystem seems fine as well.


Investigating further it seems that the use of -isystem in krb5 and the space 
after it are the results of a Debian patch (upstream uses -I with no space). So 
it seemed to me that the expedient way to fix the build failure was just to 
change the krb5 patch and that this would actually reduce the delta from 
upstream. I went ahead and did that in Raspbian. A debdiff should appear soon 
at https://debdiffs.rapsbian.org/main/k/krb5/


I think cmake should handle -isystem¹ and as this is reproducible without ignition-transport, I'm reassigning this to cmake. 

This certainly seems like the long term solution.

Bug#924444: RFA: eject -- ejects CDs and operates CD-Changers under Linux

[atzlinux]

hello,Aloïs Micard!

      From [1],I know you want  maintain the ejects package.

How about it now?

I also have intereste to maintain this package.


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


-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature

Bug#958277: preseeding documentation

[Vagrant Cascadian]

On 2020-04-29, Vagrant Cascadian wrote:
> On 2020-04-29, Buck wrote:
> [non-interactive installer] should be possible, but often time all the 
> exact questions asked may
> be hard to track down.

 Can you point me to a doc that has a complete list?
>>>
>>>A *mostly* complete list could be found by downloading the approximately
>>>5+ packages in Debian and extracting the questions from the
>>>/var/lib/dpkg/info/*.templates files. Hopefully that illustrates the
>>>scope of what you're asking for?

The recently posted Misc Developer News just so happens to have a
segment on preseeding:

  https://lists.debian.org/debian-devel-announce/2020/04/msg00016.html

In which someone extracted all the debconf preseeding values:

  https://jack.einval.com/debian-preseed/

And also pointed to:

  https://wiki.debian.org/DebianInstaller/Preseed


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 29, 2020, at 09:04, Andreas Tille  wrote:
> 
> On Wed, Apr 29, 2020 at 07:14:30AM -0700, Matthew Fernandez wrote:
> 
>> For those on this thread who have access to mipsel hardware or can shell in 
>> to one of the mipsel build machines, I would suggest running an 
>> ASan-instrumented test there (`export CFLAGS="-g -fsanitize=address"; export 
>> CXXFLAGS="-g -fsanitize=address"`) and see what we learn.
> 
> I tried on real hardware.  Unfortunately I'm running into
> 
> 
> 
> configure:3720: $? = 0
> configure:3709: gcc -v >&5
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/9/lto-wrapper
> Target: mipsel-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-10' 
> --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
> --with-gcc-major-version-only --program-suffix=-9 
> --program-prefix=mipsel-linux-gnu- --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
> --enable-gnu-unique-object --disable-libitm --disable-libsanitizer 
> --disable-libquadmath --disable-libquadmath-support --enable-plugin 
> --enable-default-pie --with-system-zlib --with-target-system-zlib=auto 
> --enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 
> --with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all 
> --with-arch-64=mips64r2 --enable-checking=release --build=mipsel-linux-gnu 
> --host=mipsel-linux-gnu --target=mipsel-linux-gnu
> Thread model: posix
> gcc version 9.3.0 (Debian 9.3.0-10) 
> configure:3720: $? = 0
> configure:3709: gcc -V >&5
> gcc: error: unrecognized command line option '-V'
> gcc: fatal error: no input files
> compilation terminated.
> configure:3720: $? = 1
> configure:3709: gcc -qversion >&5
> gcc: error: unrecognized command line option '-qversion'; did you mean 
> '--version'?
> gcc: fatal error: no input files
> compilation terminated.
> configure:3720: $? = 1
> configure:3740: checking whether the C compiler works
> configure:3762: gcc -g -O2 -fdebug-prefix-map=/home/tille/clustalo=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address 
> -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now conftest.c  >&5
> /usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
> /usr/bin/ld: cannot find -lasan
> collect2: error: ld returned 1 exit status
> configure:3766: $? = 1
> configure:3804: result: no
> configure: failed program was:
> 
> 
> 
> I have no idea why libasan_preinit.o and libasan.a are not installed.
> The package libgcc-9-dev is installed for sure and on amd64 both files
> are included here.  It seems the sudo command on eller does not permit
> me executing `apt-file update` in a chroot so I have no idea where these
> files are on mipsel (if they exist at all).
> 
> Any more help from debian-mipsel is really appreciated.

Hm yes, “--disable-libsanitizer” is rather ominous. I guess the mipsel GCC 
package has been built without ASan support. Surprising that it fails so 
messily (the front end seems to think -fsanitize=address is an accepted command 
line option), but libasan does indeed seem not available on mipsel [0]. The 
other option I suggested was Valgrind, but if you can’t run apt-file you 
probably can’t install Valgrind either. If anyone spectating has ideas, please 
chime in.

  [0]: 
https://packages.debian.org/search?searchon=contents=libasan.so=exactfilename=sid=mipsel

Bug#959152: gimp-plugin-registry: liquid rescale fails to register/work

[Adam Borowski]

Package: gimp-plugin-registry
Version: 9.20180625+nmu1
Severity: normal

Hi!
The "liquid rescale" tool is no longer present.  Upon starting the Gimp from
a terminal, I get:

GIMP-Error: Plug-in "gimp-lqr-plugin"
(/usr/lib/gimp/2.0/plug-ins/gimp-lqr-plugin)
attempted to install procedure "plug-in-lqr" with invalid parameter name 
"output target".

GIMP-Error: Plug-in "gimp-lqr-plugin"
(/usr/lib/gimp/2.0/plug-ins/gimp-lqr-plugin)
attempted to register the menu item "/Layer/" for the procedure 
"plug-in-lqr".
It has however not installed that procedure.  This is not allowed.


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

Kernel: Linux 5.7.0-rc3-00056-g8e2ea3acb98e (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gimp-plugin-registry depends on:
ii  gimp2.10.18-1
ii  libc6   2.30-4
ii  libgcc-s1   10-20200418-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libgimp2.0  2.10.18-1
ii  libglib2.0-02.64.2-1
ii  libgtk2.0-0 2.24.32-4
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-4+b1
ii  liblqr-1-0  0.4.2-2.1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10-20200418-1
ii  libtiff-tools   4.1.0+git191117-2
ii  libtiff54.1.0+git191117-2
ii  python  2.7.17-2
ii  xdg-utils   1.1.3-2

Versions of packages gimp-plugin-registry recommends:
pn  gimp-gmic  

Versions of packages gimp-plugin-registry suggests:
pn  icc-profiles  

-- no debconf information

Bug#959151: kopano-server is built without KCOIDC support

[Martin Wolf]

Package: kopano-server
Version: 8.7.0-3

|Severity: important|

The Kopano server is built without KCOIDC support, thuswhen enabling e.g.

  kcoidc_issuer_identifier = https://meet.example.net

in /etc/kopano/server.cfg, this leads to the followingerrors in the
/var/log/kopano/server.log file:

  Thu Apr 30 01:39:41 2020: [error  ] Incoming OIDC token, but this
server was built without KCOIDC support.
  Thu Apr 30 01:39:41 2020: [warning] Authentication by plugin failed
for user "": Trying to authenticate failed:  not found in
LDAP; username = 

Is there any chance for enabling KCOIDC during build-time?

KCOIDC support is necessary for Kopano Meet, otherwise the integration
doesn't work (e.g. accessing contacts).

Linux admailserver 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26)
x86_64 GNU/Linux

Bug#959150: [Pkg-clamav-devel] Bug#959150: Add support for Prelude

[Scott Kitterman]

According to the prelude web site:

Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is aimed 
for evaluation, research and test purpose on very small environments. Please 
note that Prelude OSS performances are way lower than the Prelude SIEM edition.

What testing have you done to determine the performance implications of the 
proposed change?

Scott K

On April 29, 2020 11:15:43 PM UTC, Thomas Andrejak  
wrote:
>Package: clamav
>
>Version: 0.102.2
>
>Please enable Prelude support:
>
>* d/control: Add libprelude-dev Build-Depends
>
>* d/rule: Add --enable-prelude to the ./configure
>
>Thanks
>
>Regards
>
>Thomas

Bug#959150: Add support for Prelude

[Thomas Andrejak]

Package: clamav

Version: 0.102.2

Please enable Prelude support:

* d/control: Add libprelude-dev Build-Depends

* d/rule: Add --enable-prelude to the ./configure

Thanks

Regards

Thomas

Bug#959019: lintian: True or false positive for uses-dpkg-database-directly? Checking for a running dpkg by testing for locks on /var/lib/dpkg/lock

[Chris Lamb]

tags 959019 + moreinfo
thanks

Hi Axel,

> So my question (mostly to Guillem, X-Debbugs-CC'ed): Does this file
> really belong to the "internal interface", "the entire dpkg database,
> its layout and files"?

I think question can only be resolved by the dpkg maintainer(s) so I
will mark this bug as 'moreinfo' here as there is no immediate next
action from the Lintian maintainers point of view. Feel free to drop
the moment this is resolved, and thank for for filing this and getting
the relevant people involved here.


Regards,

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

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

[Andreas Beckmann]

Control: found -1 340.108-3
Control: close -1 340.108-4

On 30/04/2020 00.20, Wendy J. Elmer wrote:
> I had 340.108-3 installed.  After I upgraded nvidia-legacy to 340.108-4 
> then the nvidia module built.

Thanks for confirming my guess.


Andreas

Bug#959002: backports version

[Gert van de Kraats]

I used the following versions:

bullseye:
status installed broadcom-sta-dkms:all 6.30.223.271-14

buster-backports:
status installed broadcom-sta-dkms:all 6.30.223.271-14~bpo10+1

This also did not work with same errors.

At the buster-backports version I tried the command dpkg-reconfigure 
broadcom-sta-dkms , that gave same errors.


Also restarts did not help.

I have no idea this has some relation, but at April a new version of 
wireless-regdb is upgraded with lot of changes.


2020-04-18 23:30:05 upgrade wireless-regdb:all 2019.06.03-1 2019.06.03-3.

gert@debian:/lib/firmware$ ls -l regulatory*
lrwxrwxrwx 1 root root   31 Apr 29 23:32 regulatory.db -> 
/etc/alternatives/regulatory.db

-rw-r--r-- 1 root root 4248 Apr 12 20:28 regulatory.db-debian
lrwxrwxrwx 1 root root   35 Apr 29 23:32 regulatory.db.p7s -> 
/etc/alternatives/regulatory.db.p7s

-rw-r--r-- 1 root root 1225 Apr 12 20:28 regulatory.db.p7s-debian
-rw-r--r-- 1 root root 1182 Apr 12 20:28 regulatory.db.p7s-upstream
-rw-r--r-- 1 root root 4248 Apr 12 20:28 regulatory.db-upstream
gert@debian:/lib/firmware$ ls -l /etc/alternatives/regulatory*
lrwxrwxrwx 1 root root 34 Apr 29 23:32 /etc/alternatives/regulatory.db 
-> /lib/firmware/regulatory.db-debian
lrwxrwxrwx 1 root root 38 Apr 29 23:32 
/etc/alternatives/regulatory.db.p7s -> 
/lib/firmware/regulatory.db.p7s-debian

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

[Wendy J. Elmer]

I had 340.108-3 installed.  After I upgraded nvidia-legacy to 340.108-4 
then the nvidia module built.
I'm not sure why the log file was truncated.  I guess it doesn't matter
now.
Thanks.
Brent
On Tue, 2020-04-28 at 11:33 +0200, Andreas Beckmann wrote:
> On Sat, 25 Apr 2020 18:48:10 -0500 Brent  wrote:
> > I installed linux-image-5.5.0-2-amd64 and as part of the install it
> > tried tobuild nvidia-legacy-340-108 dkms module.  There was an
> > error in the nvidiamodule build.
> 
> Which version of the nvidia-legacy-340xx-kernel-dkms do you
> haveinstalled? 340.108-4 or something older?
> > DKMS make.log for nvidia-legacy-340xx-340.108 for kernel 5.5.0-2-
> > amd64 (x86_64)
> 
> That pasted logfile seems to have been truncated.
> 
> Andreas

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Response embedded below. Just a quick note first - it was a little hard
to read the response you wrote because the embedded responses were
directly adjacent to the quoted text, with no spacing between (my email
client does not automatically add spacing and shows both quote and text
in similar colours unfortunately); it'd be helpful to add some spacing
please next time. :)

On Thu, 2020-04-16 at 01:15 +0200, adrian15sgd wrote:
> El 8/4/20 a las 16:56, jnq...@gmail.com escribió:
> > To fix the issue of broken EFI booting when syslinux is not used
> > (and
> > thus binary_syslinux was not put in place /live/vmlinuz), I was
> > intending to solve by moving creation of short filename kernel
> > files
> > out of binary_syslinux into somewhere common.
> > 
> > The first problem with this though is that alone of course it is
> > not
> > enough because it does not cover the `/live/vmlinuz1` multi-flavour
> > case, so a change to binaru_grub-efi would also be needed in order
> > to
> > dynamically change the searched for file to /live/vmlinuz1 where
> > appropriate.
> 
> You should also know that current isolinux/syslinux supports booting 
> from long filenames. So we could ditch using short 8.3 names for the 
> kernels.

Ok, noted, though I don't know that I'll bother the team with
submitting that change for now at least.

> This problem about having to update binary_grub-efi for searching
> for 
> long names would arise anyways.

Except when switching to a solution not involving the kernel filename,
as is the case now with the `/.disk/info` based search now
merged.

> > However, I now understand from reading #924053 that although this
> > would
> > fix things in all/most cases, it's at risk of breaking for odd
> > situations like your HP laptop case. Using /.disc/info as the
> > searched
> > for file as proposed in #924053 is much a better solution.
> It collides with Ubuntu live usbs which also have /.disc/info but it 
> would be a quick and easy fix for the current situation where HP
> laptop 
> are involved.

Exactly.

> > My current intention is to take the patch of yours provided in
> > #924053
> > that makes this change, though with a tweaked commit message (I
> > think
> > the problem is EFI specific not Secure Boot specific), and submit
> > it in
> > an MR, along with the fix for grub-pc, and some additional loosely
> > related work, in one or more MRs.
> The Secure Boot code works from an EFI sort-of-ramdisk so it needs
> to 
> find its own root somehow. That's why it was Secure Boot specific.

Ok. I can't say that I currently follow. It's been a long time since I
last researched bootloader specifics, and I don't think there even was
Linux secure boot support back then. I was a little confused (1) by the
comments in the binary_grub-efi script as to which bits were
generically EFI and which bits secure boot, considering you saying the
bit concerning the root search is secure boot specific, and (2) from
the fact that the search bit seems involved in loading an image in an
EFI virtualbox VM, which I don't think emulates secure boot. But
anyway, I think you know more about this than I currently...

> > While the concept of correctly identifying discs (aka liveid type
> > stuff) is interesting and of some potential value, priority should
> > be
> > given to simply fixing the ability to create working images first
> > and
> > foremost.
> > 
> > I will have the patches mark this bug and #924053 as closed, and
> > leave
> > you to create a new wishlist bug to propose or re-start discussion
> > of
> > the unique-disc identification stuff as you wish.
> 
> I don't think your solution is optimal (because you are postponing
> the 
> actual fact that every live cd cannot detect itself).
> 
> Liveid let's you find the correct live cd.

As things stand with the currently released version of live-build, we
have the following problems:

 1. If using `--bootloaders grub-pc` you get an unbootable image.
 2. If using `--bootloaders grub-pc,grub-efi` you get an unbootable
image in both BIOS and EFI (I'm not certain grub-efi can be used on its
own, I've not tried, but presumably it would fail just the same).
 3. If using `--bootloaders syslinux,grub-efi` with multiple kernel
versions such that you end up with `vmlinuz1`, you get an unbootable
image for EFI.
 4. You've got the problem with the HP system.
 5. You've got the problem liveid focusses on of correctly loading the
right image in a situation where there are multiple (multiple
CDs/DVS/pendrives; a pendrive containing multiple images like with
rEFInd).

Solving them:
 - The first four are easily solvable with just two tiny tweaks (the `-
-prefix=boot` grub-pc fix and the `/.disk/info` based search fix, both
of which have now been merged.
 - Fixing the last requires a much bigger and more complex solution,
with lots of decisions to make on how to proceed, issues with whether
or not the team will like the proposed solution, etc.

The difficulties with getting a final 

Bug#956017: gnome-maps: no results when searching for an address

[Phil Wyett]

On Mon, 6 Apr 2020 22:47:46 +0100 Simon McVittie 
wrote:
> On Mon, 06 Apr 2020 at 10:44:13 +0200, Keno Goertz wrote:
> > when entering an address into the search box of GNOME Maps on Debian
> > Stable, I get a loading animation for a few seconds and then "No
results
> > found".
> 
> On Mon, 06 Apr 2020 at 12:35:32 +0200, Keno Goertz wrote:
> > Turns out geocode-glib uses https://nominatim.gnome.org, which is
> > currently down (I don't know since when).
> 
> It sounds as though this is resolved for now.
> 
> For the future: this service is outside Debian's control, so when it
> isn't working, there is little the Debian maintainers of gnome-maps
can
> do about that.
> 
> smcv
> 
> 

Hi all,

Now this bug has been resolved. Can we mark it as complete and closed?

Regards

Phil

-- 

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#959149: kea-dhcp4-server: unable to open '/var/lib/lib/kea/kea-leases4.csv'

[Bernd Zeimetz]

Package: kea-dhcp4-server
Version: 1.7.5-1
Severity: serious

Hi,

after the upgrade kea fails to start with

Apr 29 23:47:12 xxx kea-dhcp4[1606]: 2020-04-29 23:47:12.790 ERROR 
[kea-dhcp4.dhcp4/1606] DHCP4_CONFIG_LOAD_FAIL configuration error using file: 
/etc/kea/kea-dhcp4.conf, reason: Unable to open database: unable to open 
'/var/lib/lib/kea/kea-leases4.csv'

Please note the extra 'lib/' in the path to the database.

A symlink as workaround helped...


Thanks,

Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#909241: gnome-maps: Unable to drag map around.

[Phil Wyett]

Hi,

This bug is for a version of gnome-maps in testing and not a version
that is now in the following Debian release i.e. Buster.

With the above in mind, if the original reporter no longer has the
issue, we should close this bug report?

Regards

Phil

-- 

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#748810: gnome-maps: credits tab in about dialog should mention OSM and MapQuest

[Phil Wyett]

Hi,

Credit is now given on the About dialog within gnome-maps to
'OpenStreetMap' and to 'MapBox' with links to their sites.

This bug I think can be marked as complete and closed?

Regards

Phil

-- 

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#959148: postfix: README.Debian provides incomplete instructions for SMTP generic mapping

[Cody Brownstein]

Source: postfix
Version: 3.5.1-1
Severity: normal
Tags: patch

Dear Maintainer,

README.Debian provides incomplete instructions for SMTP generic mapping.

If the instructions as currently written are followed, the generic
mappings will not work. The instructions do not specify how to load the
lookup tables file ('/etc/postfix/generic_mapping' in the given
example).

I am attaching a patch that completes the instructions to specify how to
load the lookup tables file for SMTP generic mapping.

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From d1a321e66f1bedaace7ebab6c71e36e5076f8877 Mon Sep 17 00:00:00 2001
From: Cody Brownstein 
Date: Wed, 29 Apr 2020 14:24:48 -0700
Subject: [PATCH] Fix instructions wrt SMTP generic mapping

---
 debian/README.Debian | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/README.Debian b/debian/README.Debian
index 2a9f02e3..cf0b9429 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -204,6 +204,14 @@ delivery of the mail via SMTP. Create an arbitrarily named 
file (e.g.,
 
 with 'host.domain' taken from '/etc/mailname'.
 
+After creating the file, run the command:
+
+postmap /etc/postfix/generic_mapping
+
+and add the following line to main.cf:
+
+sender_generic_maps = hash:/etc/postfix/generic_mapping
+
 One advantage to using generic over canonical mapping is that the latter will
 be applied to local mail as well. If the system will be configured to send all
 mail, even mail addressed to local users, via the smarthost (e.g., via
-- 
2.26.2

Bug#954044: libcpan-perl-releases-perl: Please verify server identity via SSL

[gregor herrmann]

On Wed, 29 Apr 2020 08:46:44 +0200, Salvatore Bonaccorso wrote:

> > Will you please turn on the verify_SSL attribute in HTTP::Tiny?
> 
> Unless mistaken, HTTP::Tiny is only used in tools/ which are installed
> as examples on how one can potentially use CPAN::Perl::Releases. 
> 
> Still, this should be adressed, but we won't diverge here from
> upstream, so this should be reported upstream/forwarded and then once
> fixed upstream close the bug.

Also, as discussed in #954089, this should probably be changed in
(the two instances of) HTTP::Tiny and not in each and every single
consumer.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: David Bowie: Golden Years


signature.asc
Description: Digital Signature

Bug#959147: catch2: cmake integration files are missing

[Patrick McNamara]

Package: catch2
Version: 2.11.3-2
Severity: normal

While attempting to follow the steps to integrate Catch2 with cmake, errors 
were encountered in cmake with both include(Catch) and catch_discover_tests.  
To fix the problem, I downloaded the three *.cmake files from the contrib 
directory 
of the git repository and copied them into /usr/lib/cmake/Catch2 which fixed 
the problem. 

It looks like there are also some gdb related files in the contrib directory as 
well, 
but I don't need them so I didn't do anything with them.

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

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

-- no debconf information

Bug#936803: kmodpy: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:22:16AM +, Matthias Klose wrote:
> Package: src:kmodpy
> Version: 0.1.10-2.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

What's the status, given that this has been fixed upstream in 0.1.13,
or should it be removed from the archive given there are no remaining
reverse dependencies?

Cheers,
Moritz

Bug#936790: keysync: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Wed, Apr 29, 2020 at 10:41:34PM +0200, Hans-Christoph Steiner wrote:
> 
> 
> Moritz Mühlenhoff:
> > On Fri, Aug 30, 2019 at 07:22:02AM +, Matthias Klose wrote:
> >> Package: src:keysync
> >> Version: 0.2.2-2
> >> Severity: normal
> >> Tags: sid bullseye
> >> User: debian-pyt...@lists.debian.org
> >> Usertags: py2removal
> >>
> >> Python2 becomes end-of-live upstream, and Debian aims to remove
> >> Python2 from the distribution, as discussed in
> >> https://lists.debian.org/debian-python/2019/07/msg00080.html
> >>
> >> Your package either build-depends, depends on Python2, or uses Python2
> >> in the autopkg tests.  Please stop using Python2, and fix this issue
> >> by one of the following actions.
> > 
> > There's no update at https://dev.guardianproject.info/issues/2478.html
> > at all, let's remove keysync?
> 
> Works for me.

Ack, I've just filed an RM bug.

Cheers,
Moritz

Bug#959145: ITP: protonmail-bridge -- ProtonMail Bridge for e-mail clients.

[Patryk Cisek]

Package: wnpp
Owner: Patryk Cisek 
Severity: wishlist

* Package name: protonmail-bridge
  Version : 1.2.6
  Upstream Author : Proton Technologies AG (ProtonMail Bridge
developers) 
* URL : https://github.com/ProtonMail/proton-bridge
* License : GPL
  Programming Lang: Go
  Description : ProtonMail Bridge for e-mail clients.

IMAP/SMTP bridge to ProtonMail for paid clients.

ProtonMail stores emails on their servers encrypted with GnuPG key, that
is encrypted with a symmetric cipher, for which the password is your
ProtonMail account password. Those emails can be decrypted only when you
access your account through Web Mail interface (you log in and provide
the password then) and through this bridge (your email client can
download messages through IMAP from the bridge, and it's the bridge that
decrypts those emails).

Bug#959146: RM: keysync -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove keysync. It depends on Python 2 and is dead upstream.
Acked by the maintainer in #936790.

Cheers,
Moritz

Bug#959070: klibc-utils: fstype falsely claims to need an executable stack

[Ben Hutchings]

On Wed, 2020-04-29 at 20:41 +0200, Helge Deller wrote:
> On 29.04.20 15:36, Ben Hutchings wrote:
> > Control: tag -1 upstream fixed-upstream patch
> > 
> > On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote:
> > > Package: klibc-utils
> > > Version: 2.0.7-1
> > > Severity: normal
> > > 
> > > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2
> > > Segmentation fault
> > > root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype
> > > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2
> > > FSTYPE=btrfs
> > > FSSIZE=719360278528
> > > 
> > > The fstype program is listed as needing an executable stack, which will 
> > > cause
> > > it to crash when run on a system with a security policy preventing 
> > > executable
> > > stacke.  If you clear the execstack bit it appears to work correctly.
> > [...]
> > 
> > I've fixed this upstream but not made a new release yet:
> > 
> > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641
> 
> On hppa/parisc we still need executable stacks for the signal trampoline 
> return code. 
> Might your patch then maybe break fstype on hppa? 
> I didn't tested it...

Kees Cook mentioned that too:
https://lists.zytor.com/archives/klibc/2020-February/004273.html
but I couldn't find any sign of it in the current code.

Looking again, I see that I was confused: the *kernel* creates these
trampolines on the stack.  On some architecturers (m68k and parisc)
this is done unconditionally; on others (alpha, s390, and sparc 32-bit) 
it's done if sa_restorer is not set (and we don't set it for them).

Presumably m68k and parisc are actually fine at the moment, as gcc
won't disable execstack on its output.  However alpha, s390, and sparc
will be broken if gcc is configured assuming the C library will set
sa_restorer and it disables execstack.

I shall make the execstack flag setting arch-dependent.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.



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

Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library

[Aaron Boxer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libgrokj2k". Grok is one of only two
actively developed open source JPEG 2000 toolkits on the planet.

 * Package name: libgrokj2k
   Version : 7.1.0-1
   Upstream Author : boxe...@gmail.com
 * URL : https://github.com/GrokImageCompression/grok
 * License : AGPL-3 and BSD-2-clause
 * Vcs : https://github.com/GrokImageCompression/grok
   Section : libs

It builds those binary packages:

  libgrokj2k1 - JPEG 2000 image compression/decompression library
  libgrokj2k1-dev - development files for Grok, a JPEG 2000 image library
  grokj2k-tools - command-line tools for the Grok JPEG 2000 library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libg/libgrokj2k/libgrokj2k_7.1.0-1.dsc

Changes since the last upload:

   * Initial release. Closes: #954265

Thank You!

--
  Aaron Boxer

Bug#959144: mozjs68: Build-depends on cargo and rustc but doesn't actually use it

[John Paul Adrian Glaubitz]

Source: mozjs68
Version: 68.6.0-2
Severity: normal
Tags: upstream
User: debian-...@lists.debian.org
Usertags: alpha hppa ia64 m68k sh4

Hi!

mozjs68 build-depends on cargo and rustc, but it doesn't actually build any Rust
code. The configure script just checks for the version of cargo and rustc, then
builds C/C++ code only [1].

We should find a way to eliminate the Rust build dependencies at least for the
architectures which don't have Rust support yet, so that mozjs68 can be built
on these as well.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mozjs68=amd64=68.6.0-2=1585310160=0

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

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Apologies once again for the time it's taking to get back to you, so
much to do. I'll try to get focussed on responding to all of your
messages now/next...

The fix for this bug report has been merged now since your response.

The piece of code modified to add `--prefix=/boot/grub` lived within a
condition of `"${LB_FIRST_BOOTLOADER}" = "grub-pc"`, so does not apply
to the default situation of using syslinux at least...

Furthermore the code concerns generation of a 'grub_eltorito' file,
which is then later used in a xorriso only when grub-pc is selected for
use.

So it seems to me that this only affects grub-pc...

It's been quite some time since I last researched the details of ISOs
and bootloaders and such. So I cannot say with complete confidence that
you're mistaken in being concerned about this breaking secure boot.
Especially since testing is tricky since I don't think my VM emulates
it, so would be a pain to double check, considering how busy I am.

If you're still concerned, would you happen to please have a little
spare time to double check?

Thanks,
Lyndon.


On Thu, 2020-04-16 at 01:03 +0200, adrian15sgd wrote:
> I suspect this would break Secure Boot support but it's only a guess.
> 
> El 8/4/20 a las 2:23, jnq...@gmail.com escribió:
> > update: I've just tried adding --prefix=/boot/grub to the grub-
> > mkimage
> > command in binary_iso (which should really be done in binary_grub-
> > pc)
> > that generates the core_img file that becomes part of
> > grub_eltorito,
> > and success!
> > 
> > So now that I know how fundamentally to fix the problems, I'll
> > follow
> > up soon with patches.
> > 

Bug#936790: keysync: Python2 removal in sid/bullseye

[Hans-Christoph Steiner]

Moritz Mühlenhoff:
> On Fri, Aug 30, 2019 at 07:22:02AM +, Matthias Klose wrote:
>> Package: src:keysync
>> Version: 0.2.2-2
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>>
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
> 
> There's no update at https://dev.guardianproject.info/issues/2478.html
> at all, let's remove keysync?

Works for me.

.hc

Bug#956731: Acknowledgement (RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C)

[Christian Göttsche]

I uploaded a new version, which switches to debhelper compat level 13,
updates the copyright file and disables the auto-test step on ppc architectures.

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream version 0.14.0
   * d/{control,compat}: switch to debhelper compat level 13
   * d/control:
 - bump std-version to 4.5.0 (no further changes)
 - drop dependency fulfilled since jessie
   * d/patches: add patch to correct misspelling
   * d/rules:
 - drop unneeded dh option '--buildsystem=autoconf --with autoreconf'
 - break configure lines
 - add 'dh_missing --fail-missing'
 - disable auto-test for ppc architectures (Closes: #918572, #951667)
   * debian: cleanup unnecessary .dirs and .files items
   * d/tests: add simple autopkgtest
   * d/copyright: update


The unstable version 0.12.0-0.1 is currently prevented from migration
to testing due to #918572 [1].
Also #951667 [2] will be resolved with this new version.

Check 0.11.0 introduces the common check macros 'ck_assert_ptr_null'
and 'ck_assert_ptr_nonnull',
which are e.g. required for SELint [3] which I'd like to package perspectively.


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918572
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951667
[3]: https://github.com/TresysTechnology/selint

p.s.: due to timeout tests the build can take up to 15 minutes, see
https://salsa.debian.org/cgzones/check/-/jobs/705379

Bug#953334: RFP: projectm -- iterative music visualization library

[Jonathan Joseph Chiarella]

On Sat, 7 Mar 2020 19:45:27 -0500 Boyuan Yang  wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-CC: siret...@tauware.de m...@debian.org
> debian-multime...@lists.debian.org
> 
> Dear package projectm maintainers,
> 
> According to https://tracker.debian.org/pkg/projectm , this package
> was just removed
> from Sid due to dependency on Qt4. However, the upstream has already released
> new versions supporting Qt5.
> 
> Please consider reintroducing projectm using new upstream releases. Thanks!
> 
> -- 
> Regards,
> Boyuan Yang

It looks like no one was able to step up on ProjectM's end for packaging: 
.

I can file bug reports and stalk bug reports, but I cannot package or code, 
otherwise I'd help. I imagine if there were just one release at this point, 
built on Qt5, it could last a long time. It's not a program you'd have to worry 
about security-wise. It doesn't open files, just reads audio streams, not 
directly hooked to internet, does not manage passwords, etc. It looks as if it 
may support Wayland, too, or at least indirectly.

-- 
Jonathan Joseph Chiarella
jonathan.chiare...@gmail.com
PGP Fingerprint: 8B54 67AE 714B 8A5B D479 F578 6AAB 963C 0402 061A



signature.asc
Description: OpenPGP digital signature

Bug#959140: roundcube: Cross-Site Scripting (XSS) vulnerability via malicious HTML messages

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security

AFAICT no CVE was assigned for this yet.  1.2.x, 1.3.x and 1.4.x
branches are affected.  Upstream fix:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/87e4cd0cf2c550e77586860b94e5c75d2b7686d0
1.3.x 
https://github.com/roundcube/roundcubemail/commit/23c06159ae8c6f500336e3075820e648aa6f40a4
1.2.x 
https://github.com/roundcube/roundcubemail/commit/4312dc4efecb9553fcacfab0ab9d9ee6e88477e7

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959142: roundcube: CSRF attack can cause an authenticated user to be logged out

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security

AFAICT no CVE was assigned for this yet.  1.2.x, 1.3.x and 1.4.x
branches are affected.  Upstream fix:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/9bbda422ff0b782b81de59c86994f1a5fd93f8e6
1.3.x 
https://github.com/roundcube/roundcubemail/commit/1e7bec9cb868fa32b05acf6b0a557a6311350c56
1.2.x 
https://github.com/roundcube/roundcubemail/commit/cceeff2472c00acb2c6b96c9df7a289f1db77713

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959141: apngopt 1.2-2 stack buffer overflow

[David Petek]

Package: apngopt
Version: 1.2-2

apngopt crashes with stack buffer overflow when calling with command line
argument longer than 247 bytes.

Steps to replicate:
```
wget
http://deb.debian.org/debian/pool/main/a/apngopt/apngopt_1.2.orig.tar.gz
tar -xf apngopt_1.2.orig.tar.gz
cd apngopt-1.2.orig
make
./apngopt `python -c "print('a'*256)"`
```

Output:
```
APNG Optimizer 1.2

*** buffer overflow detected ***: ./apngopt terminated
[1]5965 abort  ./apngopt `python -c "print('a'*256)"`
```

Bug is caused by copying command line argument into a 256-byte buffer using
strcpy on line 2372:
```
2363  szIn = argv[1];
2364
2365  if (argc > 2)
2366  {
2367strncpy(szOut, argv[2], 255);
2368szOut[255] = '\0';
2369  }
2370  else
2371  {
2372strcpy(szOut, szIn);
2373if ((szExt = strrchr(szOut, '.')) != NULL) *szExt = 0;
2374strcat(szOut, ".opt.png");
2375  }
```

Suggested fix: use strncpy or verify szIn length before copying.

Proposed patch:
```
2372c2372
< strcpy(szOut, szIn);
---
> strncpy(szOut, szIn, 247);
```

Best regards,

-- 
David Petek

Bug#952316: [pkg-go] Bug#952316: gopacket: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 github.com/google/gopacket github.com/google/gopacket/afpacket github.co

[Sascha Steinbiss]

Hi.

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

This is easily fixed by updating to the latest upstream version (1.1.17).

@Hilko: OK with you? I have already prepared the update as need this for
stenographer to migrate. Gopacket as a dependency has been removed from
testing due to this RC bug.

Will do a team upload on the weekend if there are no objections.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#955429: possiblity of using a different download agent like wget in bad internet connections

[Cédric Boutillier]

Hi,

Here is a log attached.

The client has private IP 192.168.0.106
behind an ADSL "box" with public IP 82.65.29.121
The package with a missed download was actually this time
apt-cacher-ng:

E: Impossible de récupérer 
http://deb.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_3.5-1_amd64.deb
  Somme de contrôle de hachage incohérente
   Hashes of expected file:
- SHA256:5bf309906ebfb202e2d91abd6bb952f42e38326c6a12fdc9326936dbf0b974b9
- MD5Sum:7407fe84c3f123b76a5daebd9bb71925 [weak]
- Filesize:562512 [weak]
   Hashes of received file:
- SHA256:f7284dd1761a74cd592496c8c3451721b14894c03fed22b9fd499924a1ea7dfb
- MD5Sum:d1df236d3c207c51d32c26da401a10e5 [weak]
- Filesize:562512 [weak]
   Last modification reported: Mon, 20 Apr 2020 22:42:49 +

Thanks for investigating.

Cheers,

Cédric


apt-cacher.err.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#959139: numpy breaks scikit-learn arm64 autopkgtest: assert_uniform_grid(Y, try_name)

[Paul Gevers]

Source: numpy, scikit-learn
Control: found -1 numpy/1:1.18.3-1
Control: found -1 scikit-learn/0.22.2.post1+dfsg-5
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of numpy the autopkgtest of scikit-learn fails in
testing on arm64 when that autopkgtest is run with the binary packages
of numpy from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
numpy  from testing1:1.18.3-1
scikit-learn   from testing0.22.2.post1+dfsg-5
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/arm64/s/scikit-learn/5194679/log.gz

=== FAILURES
===
 test_uniform_grid[barnes_hut]
_

method = 'barnes_hut'

@pytest.mark.parametrize('method', ['barnes_hut', 'exact'])
def test_uniform_grid(method):
"""Make sure that TSNE can approximately recover a uniform 2D grid

Due to ties in distances between point in X_2d_grid, this test
is platform
dependent for ``method='barnes_hut'`` due to numerical imprecision.

Also, t-SNE is not assured to converge to the right solution
because bad
initialization can lead to convergence to bad local minimum (the
optimization problem is non-convex). To avoid breaking the test
too often,
we re-run t-SNE from the final point when the convergence is not
good
enough.
"""
seeds = [0, 1, 2]
n_iter = 500
for seed in seeds:
tsne = TSNE(n_components=2, init='random', random_state=seed,
perplexity=20, n_iter=n_iter, method=method)
Y = tsne.fit_transform(X_2d_grid)

try_name = "{}_{}".format(method, seed)
try:
>   assert_uniform_grid(Y, try_name)

/usr/lib/python3/dist-packages/sklearn/manifold/tests/test_t_sne.py:784:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

Y = array([[ 52.326397  , -15.92225   ],
   [ 46.679527  , -20.175953  ],
   [ 40.870537  , -24.181147  ],
   ...[-35.291374  ,  22.122814  ],
   [-42.2738,  18.793724  ],
   [-48.922283  ,  15.606232  ]], dtype=float32)
try_name = 'barnes_hut_1'

def assert_uniform_grid(Y, try_name=None):
# Ensure that the resulting embedding leads to approximately
# uniformly spaced points: the distance to the closest neighbors
# should be non-zero and approximately constant.
nn = NearestNeighbors(n_neighbors=1).fit(Y)
dist_to_nn = nn.kneighbors(return_distance=True)[0].ravel()
assert dist_to_nn.min() > 0.1

smallest_to_mean = dist_to_nn.min() / np.mean(dist_to_nn)
largest_to_mean = dist_to_nn.max() / np.mean(dist_to_nn)

assert smallest_to_mean > .5, try_name
>   assert largest_to_mean < 2, try_name
E   AssertionError: barnes_hut_1
E   assert 6.67359409617653 < 2

/usr/lib/python3/dist-packages/sklearn/manifold/tests/test_t_sne.py:807:
AssertionError

During handling of the above exception, another exception occurred:

method = 'barnes_hut'

@pytest.mark.parametrize('method', ['barnes_hut', 'exact'])
def test_uniform_grid(method):
"""Make sure that TSNE can approximately recover a uniform 2D grid

Due to ties in distances between point in X_2d_grid, this test
is platform
dependent for ``method='barnes_hut'`` due to numerical imprecision.

Also, t-SNE is not assured to converge to the right solution
because bad
initialization can lead to convergence to bad local minimum (the
optimization problem is non-convex). To avoid breaking the test
too often,
we re-run t-SNE from the final point when the convergence is not
good
enough.
"""
seeds = [0, 1, 2]
n_iter = 500
for seed in seeds:
tsne = TSNE(n_components=2, init='random', random_state=seed,
perplexity=20, n_iter=n_iter, method=method)
Y = tsne.fit_transform(X_2d_grid)

try_name = "{}_{}".format(method, seed)
try:
assert_uniform_grid(Y, try_name)
except AssertionError:
# If the test 

Bug#900503: Bug #900503 - xbacklight: Packagely solve the case of intel_backlight

[Jens Radloff]

I noticed twice the behaviour which I desribed in message #10 in Debian 10.3 
("Buster", the currently stable Debian release) on the same hardware (Acer 
Aspire E1-530 laptop), too.

I then applied the same steps as mentioned in message #10 .

This is the first time I rebooted my machine having applied these steps, and so 
far the screen's brightness is at 100%.

This is information about Graphics info (card(s), driver, display protocol (if 
available), display server, resolution:

xxx@punk:~$ inxi -G
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: 
kernel. 
Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1366x768~60Hz.
OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 18.3.6 
xxx@punk:~

Bug#959137: lasagne: (autopkgtest) needs update for new version of numpy: 'numpy.float64' object cannot be interpreted as an integer

[Paul Gevers]

Source: lasagne
Version: 0.1+git20181019.a61b76f-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numpy

Dear maintainer(s),

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

   passfail
numpy  from testing1:1.18.3-1
lasagnefrom testing0.1+git20181019.a61b76f-2
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lasagne/5197094/log.gz

=== FAILURES
===

TestTPSTransformLayer.test_transform_thin_plate_spline_variable_input _

start = -1, stop = 1, num = 4.0, endpoint = True, retstep = False, dtype
= None
axis = 0

@array_function_dispatch(_linspace_dispatcher)
def linspace(start, stop, num=50, endpoint=True, retstep=False,
dtype=None,
 axis=0):
"""
Return evenly spaced numbers over a specified interval.

Returns `num` evenly spaced samples, calculated over the
interval [`start`, `stop`].

The endpoint of the interval can optionally be excluded.

.. versionchanged:: 1.16.0
Non-scalar `start` and `stop` are now supported.

Parameters
--
start : array_like
The starting value of the sequence.
stop : array_like
The end value of the sequence, unless `endpoint` is set to
False.
In that case, the sequence consists of all but the last of
``num + 1``
evenly spaced samples, so that `stop` is excluded.  Note
that the step
size changes when `endpoint` is False.
num : int, optional
Number of samples to generate. Default is 50. Must be
non-negative.
endpoint : bool, optional
If True, `stop` is the last sample. Otherwise, it is not
included.
Default is True.
retstep : bool, optional
If True, return (`samples`, `step`), where `step` is the spacing
between samples.
dtype : dtype, optional
The type of the output array.  If `dtype` is not given,
infer the data
type from the other input arguments.

.. versionadded:: 1.9.0

axis : int, optional
The axis in the result to store the samples.  Relevant only
if start
or stop are array-like.  By default (0), the samples will be
along a
new axis inserted at the beginning. Use -1 to get an axis at
the end.

.. versionadded:: 1.16.0

Returns
---
samples : ndarray
There are `num` equally spaced samples in the closed interval
``[start, stop]`` or the half-open interval ``[start, stop)``
(depending on whether `endpoint` is True or False).
step : float, optional
Only returned if `retstep` is True

Size of spacing between samples.


See Also

arange : Similar to `linspace`, but uses a step size (instead of the
 number of samples).
geomspace : Similar to `linspace`, but with numbers spaced
evenly on a log
scale (a geometric progression).
logspace : Similar to `geomspace`, but with the end points
specified as
   logarithms.

Examples

>>> np.linspace(2.0, 3.0, num=5)
array([2.  , 2.25, 2.5 , 2.75, 3.  ])
>>> np.linspace(2.0, 3.0, num=5, endpoint=False)
array([2. ,  2.2,  2.4,  2.6,  2.8])
>>> np.linspace(2.0, 3.0, num=5, retstep=True)
(array([2.  ,  2.25,  2.5 ,  2.75,  3.  ]), 0.25)

Graphical illustration:

>>> import matplotlib.pyplot as plt
>>> 

Bug#959138: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators'

[Paul Gevers]

Source: numpy, nipy
Control: found -1 numpy/1:1.18.3-1
Control: found -1 nipy/0.4.2-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
numpy  from testing1:1.18.3-1
nipy   from testing0.4.2-3
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/nipy/5197095/log.gz

autopkgtest [22:13:27]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/nipy/__init__.py", line 12, in

from nipy.testing import Tester
  File "/usr/lib/python3/dist-packages/nipy/testing/__init__.py", line
44, in 
from . import decorators as dec
  File "/usr/lib/python3/dist-packages/nipy/testing/decorators.py", line
11, in 
from numpy.testing.decorators import *
ModuleNotFoundError: No module named 'numpy.testing.decorators'
autopkgtest [22:13:27]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#959136: numpy breaks dask autopkgtest: E assert 10 == 11

[Paul Gevers]

Source: numpy, dask
Control: found -1 numpy/1:1.18.3-1
Control: found -1 dask/2.11.0+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
numpy  from testing1:1.18.3-1
dask   from testing2.11.0+dfsg-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/5197674/log.gz

=== FAILURES
===
__ test_argwhere_str
___

def test_argwhere_str():
x = np.array(list("Hello world"))
d = da.from_array(x, chunks=(4,))

x_nz = np.argwhere(x)
d_nz = da.argwhere(d)

>   assert_eq(d_nz, x_nz)

/usr/lib/python3/dist-packages/dask/array/tests/test_routines.py:1144:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

a = array([[ 0],
   [ 1],
   [ 2],
   [ 3],
   [ 4],
   [ 5],
   [ 6],
   [ 7],
   [ 8],
   [ 9],
   [10]])
b = array([[ 0],
   [ 1],
   [ 2],
   [ 3],
   [ 4],
   [ 6],
   [ 7],
   [ 8],
   [ 9],
   [10]])
check_shape = True, check_graph = True, check_meta = True, kwargs = {}
a_original = dask.array
b_original = array([[ 0],
   [ 1],
   [ 2],
   [ 3],
   [ 4],
   [ 6],
   [ 7],
   [ 8],
   [ 9],
   [10]])
adt = dtype('int64'), a_meta = array([], shape=(0, 0), dtype=int64)
a_computed = array([[ 0],
   [ 1],
   [ 2],
   [ 3],
   [ 4],
   [ 5],
   [ 6],
   [ 7],
   [ 8],
   [ 9],
   [10]])
bdt = dtype('int64'), b_meta = None

def assert_eq(a, b, check_shape=True, check_graph=True,
check_meta=True, **kwargs):
a_original = a
b_original = b

a, adt, a_meta, a_computed = _get_dt_meta_computed(
a, check_shape=check_shape, check_graph=check_graph
)
b, bdt, b_meta, b_computed = _get_dt_meta_computed(
b, check_shape=check_shape, check_graph=check_graph
)

if str(adt) != str(bdt):
# Ignore check for matching length of flexible dtypes, since
Array._meta
# can't encode that information
if adt.type == bdt.type and not (adt.type == np.bytes_ or
adt.type == np.str_):
diff = difflib.ndiff(str(adt).splitlines(),
str(bdt).splitlines())
raise AssertionError(
"string repr are different" + os.linesep +
os.linesep.join(diff)
)

try:
>   assert a.shape == b.shape
E   AssertionError

/usr/lib/python3/dist-packages/dask/array/utils.py:246: AssertionError
 test_count_nonzero_str


def test_count_nonzero_str():
x = np.array(list("Hello world"))
d = da.from_array(x, chunks=(4,))

x_c = np.count_nonzero(x)
d_c = da.count_nonzero(d)

>   assert x_c == d_c.compute()
E   assert 10 == 11
E -10
E +11



signature.asc
Description: OpenPGP digital signature

Bug#956371: deal.ii: diff for NMU version 9.1.1-9.1

[Tobias Frost]

Control: tags 956371 + pending


Dear maintainer,

I've prepared an NMU for deal.ii (versioned as 9.1.1-9.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru deal.ii-9.1.1/debian/changelog deal.ii-9.1.1/debian/changelog
--- deal.ii-9.1.1/debian/changelog	2020-01-28 15:19:52.0 +0100
+++ deal.ii-9.1.1/debian/changelog	2020-04-29 19:35:59.0 +0200
@@ -1,3 +1,10 @@
+deal.ii (9.1.1-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch to fix "FTBFS with opencascade 7.4 (Closes: #956371)
+
+ -- Tobias Frost   Wed, 29 Apr 2020 19:35:59 +0200
+
 deal.ii (9.1.1-9) unstable; urgency=medium
 
   * fix TBB version check
diff -Nru deal.ii-9.1.1/debian/patches/ftbfs-opencascade74.patch deal.ii-9.1.1/debian/patches/ftbfs-opencascade74.patch
--- deal.ii-9.1.1/debian/patches/ftbfs-opencascade74.patch	1970-01-01 01:00:00.0 +0100
+++ deal.ii-9.1.1/debian/patches/ftbfs-opencascade74.patch	2020-04-10 11:23:34.0 +0200
@@ -0,0 +1,11 @@
+--- a/source/gmsh/utilities.cc
 b/source/gmsh/utilities.cc
+@@ -76,7 +76,7 @@
+ 
+ dealii::OpenCASCADE::write_IGES(boundary, iges_file_name);
+ 
+-ofstream geofile;
++std::ofstream geofile;
+ geofile.open(geo_file_name);
+ geofile << "Merge \"" << iges_file_name << "\";" << std::endl
+ << "Line Loop (2) = {1};" << std::endl
diff -Nru deal.ii-9.1.1/debian/patches/series deal.ii-9.1.1/debian/patches/series
--- deal.ii-9.1.1/debian/patches/series	2020-01-28 12:34:00.0 +0100
+++ deal.ii-9.1.1/debian/patches/series	2020-04-10 13:39:09.0 +0200
@@ -3,3 +3,4 @@
 doxygen_compatibility.patch
 link_libopen-pal.patch
 fix_tbb_version_check.patch
+ftbfs-opencascade74.patch

Bug#955469: initramfs-tools-core: Enable zstandard support

[Norbert Lange]

Am Mittwoch, 29. April 2020 schrieb Ben Hutchings :

> On Tue, 2020-04-28 at 04:43 +0100, Ben Hutchings wrote:
> > On Wed, 01 Apr 2020 09:05:22 +0200 Norbert Lange 
> wrote:
> > > Package: initramfs-tools-core
> > > Version: 0.136
> > > Severity: wishlist
> > > Tags: patch
> > >
> > > Hello,
> > >
> > > there are Kernelpatches for zstandard initramfs support
> > > available for several years, and will hopefully accepted
> > > upstream soon.
> >
> > If the kernel doesn't yet support it, I'm not sure what the point of
> > supporting it in initramfs-tools is.
> [...]
>
> I see that the kernel support for this has been submitted recently,
> though it's not clear which maintainer is being asked to apply the
> patches.


It's been submitted multiple times over the years, I don't know the lkml
workings, and apparently the author of these changes is missing some detail
too.

Could you kindky point to what's missing? Sending the pull request directly
(not cc) to a maintainer?

I use initramfs-tools (unmkinitramfs in particular) for zstd compressed
initrds since years. The point would be that Debian is a nice distro for
any kind of development, including homebrewn kernels for pet project.
And that zstd is hopefully getting enabled for initrd/kernel in the near
future. It's not like this is an entirely new format.

Norbert

Bug#947518: casparcg-server: FTBFS: xf86vmode library not found - required for GLFW

[Julian Waller]

I've just seen a few of the bugs on here, and am having a look at them upstream.

You are right in that GLFW and a few other dependencies are not needed
at all, so I shall be removing those soon in v2.3.0 . I hope to have
that merged before beta1 which is due sometime this week.

> I've tried to clean it up a bit, but it seems to me that many cmake stanzas 
> are quite bogus.

I am not surprised that this is the case. Linux support in casparcg is
not the highest priority, so it hasn't had that much attention. As
such the build scripts have been a bit hacked together by people who
don't really know cmake, and littered with remnants of things that
have been long removed.

Julian

Bug#959135: gdc -debuglib not supported

[Witold Baryluk]

Package: gdc
Version: 4:9.2.1-3.1
Severity: normal

According to man page for gdc(1):

   -debuglib
   Specify the debug library to use instead of libphobos when linking.  
This option
   has no effect unless the -g option was also given on the command 
line.  Options
   specifying the linkage of libphobos, such as -static-libphobos or
   -shared-libphobos, are ignored.





$ gdc -debuglib -Wall -ggdb -O2 search.d
d21: warning: unrecognized gcc debugging option: e
d21: warning: unrecognized gcc debugging option: b
d21: warning: unrecognized gcc debugging option: u
d21: warning: unrecognized gcc debugging option: g
d21: warning: unrecognized gcc debugging option: l
d21: warning: unrecognized gcc debugging option: i
d21: warning: unrecognized gcc debugging option: b
$

AFAIK Debian doesn't provide the debug library (phobos and druntime
compiled with debug options and extra debug assertions and unittest).
libgphobos76-dbgsym is not a 'debug library', these are debug symbols for
normal (optimized) phobos and druntime library.

Even then, the -debuglib should be regognized, or maybe removed from the
manpage for gdc(1) and gdc-9(1)? I can't find any info about -debuglib in
gdc --help=common or in gdc --help=d.

https://wiki.dlang.org/Using_GDC  lists that there is option -debuglib=

dmd-script supposedly also supports it 
https://github.com/D-Programming-GDC/gdmd/blob/master/dmd-script

I also looked at upstreadm GCC sources, and it should be supported:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/d/d-spec.cc;h=f4744763ab617e3adf762ca0a791a512597b0fa8;hb=HEAD#l172


But reading the source and reading between the lines of the manpage,
maybe it should be stated in the manpage as '-debuglib libname', similar
to '-defaultlib libname'?





Regards,
Witold




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

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

Versions of packages gdc depends on:
ii  gdc-9   9.3.0-11
ii  libgphobos-dev  9.2.1-3.1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#959133: release.debian.org: Transition for gsl

[Dirk Eddelbuettel]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

GNU GSL 2.6 was release last fall; the package is stable and does not move
too much upstream.  It has been in 'auto transition' for a while following my
initial upload to experimental.  Could we maybe nudge it towards transition?

Tentative ben file (copied from
  https://release.debian.org/transitions/html/auto-gsl.html
and edited)

-
title = "gsl";
is_affected = .depends ~ "libgsl25" | .depends ~ "libgsl23";
is_good = .depends ~ "libgsl25"l
is_bad = .depends ~"r-api-3.5"
-

Let me know if I can help otherwise.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#959134: astroml: (autopkgtest) needs update for new version of numpy: object of type cannot be safely interpreted as an integer

[Paul Gevers]

Source: astroml
Version: 0.4.post1-5
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numpy

Dear maintainer(s),

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

   passfail
numpy  from testing1:1.18.3-1
astromlfrom testing0.4.post1-5
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroml/5208422/log.gz

=== FAILURES
===
___ test_gaussian1d


start = -6, stop = 10, num = 1000.0, endpoint = True, retstep = False
dtype = None, axis = 0

@array_function_dispatch(_linspace_dispatcher)
def linspace(start, stop, num=50, endpoint=True, retstep=False,
dtype=None,
 axis=0):
"""
Return evenly spaced numbers over a specified interval.

Returns `num` evenly spaced samples, calculated over the
interval [`start`, `stop`].

The endpoint of the interval can optionally be excluded.

.. versionchanged:: 1.16.0
Non-scalar `start` and `stop` are now supported.

Parameters
--
start : array_like
The starting value of the sequence.
stop : array_like
The end value of the sequence, unless `endpoint` is set to
False.
In that case, the sequence consists of all but the last of
``num + 1``
evenly spaced samples, so that `stop` is excluded.  Note
that the step
size changes when `endpoint` is False.
num : int, optional
Number of samples to generate. Default is 50. Must be
non-negative.
endpoint : bool, optional
If True, `stop` is the last sample. Otherwise, it is not
included.
Default is True.
retstep : bool, optional
If True, return (`samples`, `step`), where `step` is the spacing
between samples.
dtype : dtype, optional
The type of the output array.  If `dtype` is not given,
infer the data
type from the other input arguments.

.. versionadded:: 1.9.0

axis : int, optional
The axis in the result to store the samples.  Relevant only
if start
or stop are array-like.  By default (0), the samples will be
along a
new axis inserted at the beginning. Use -1 to get an axis at
the end.

.. versionadded:: 1.16.0

Returns
---
samples : ndarray
There are `num` equally spaced samples in the closed interval
``[start, stop]`` or the half-open interval ``[start, stop)``
(depending on whether `endpoint` is True or False).
step : float, optional
Only returned if `retstep` is True

Size of spacing between samples.


See Also

arange : Similar to `linspace`, but uses a step size (instead of the
 number of samples).
geomspace : Similar to `linspace`, but with numbers spaced
evenly on a log
scale (a geometric progression).
logspace : Similar to `geomspace`, but with the end points
specified as
   logarithms.

Examples

>>> np.linspace(2.0, 3.0, num=5)
array([2.  , 2.25, 2.5 , 2.75, 3.  ])
>>> np.linspace(2.0, 3.0, num=5, endpoint=False)
array([2. ,  2.2,  2.4,  2.6,  2.8])
>>> np.linspace(2.0, 3.0, num=5, retstep=True)
(array([2.  ,  2.25,  2.5 ,  2.75,  3.  ]), 0.25)

Graphical illustration:

>>> import matplotlib.pyplot as plt
>>> N = 8
>>> y = 

Bug#959081: buster-pu: package libssh/0.8.7-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-04-29 at 10:45 +0200, Laurent Bigonville wrote:
> Please allow an upload to fix #956308 (CVE-2020-1730).

Please go ahead.

> That upload should also probably end up in the coming point release

That's the general idea of p-u, yeah. :-)

Regards,

Adam

Bug#959070: klibc-utils: fstype falsely claims to need an executable stack

[Thorsten Glaser]

Helge Deller dixit:

>On hppa/parisc we still need executable stacks for the signal
>trampoline return code. Might your patch then maybe break fstype on
>hppa? I didn't tested it...

I think it only changed the assembly parts of the library to
signal to the linker that there’s no need for an executable
stack on their account, but the signal handling code should¹
add one on hppa then.

① also not tested, maybe you should ☻

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#959132: libquickfix-dev: Please compile with the option --with-openssl

[Micah Anderson]

Package: libquickfix-dev
Version: 1.15.1+dfsg-3
Severity: wishlist

Hello!

It would be nice if you could toggle the configure flag --with-openssl.

It doesn't impact people who want to use it without ssl, but makes it possible
to make TLS connections.

thanks!

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

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

Bug#959070: klibc-utils: fstype falsely claims to need an executable stack

[Helge Deller]

On 29.04.20 15:36, Ben Hutchings wrote:
> Control: tag -1 upstream fixed-upstream patch
> 
> On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote:
>> Package: klibc-utils
>> Version: 2.0.7-1
>> Severity: normal
>>
>> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2
>> Segmentation fault
>> root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype
>> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2
>> FSTYPE=btrfs
>> FSSIZE=719360278528
>>
>> The fstype program is listed as needing an executable stack, which will cause
>> it to crash when run on a system with a security policy preventing executable
>> stacke.  If you clear the execstack bit it appears to work correctly.
> [...]
> 
> I've fixed this upstream but not made a new release yet:
> 
> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641

On hppa/parisc we still need executable stacks for the signal trampoline return 
code. 
Might your patch then maybe break fstype on hppa? 
I didn't tested it...

Helge



signature.asc
Description: OpenPGP digital signature

Bug#826095: python-pandas: please provide backport of pandas

[Rebecca N. Palmer]

A potential problem is that upgrading pandas breaks some of its reverse 
dependencies: whether this is a blocker for backports is being discussed 
at https://lists.debian.org/debian-backports/2020/04/threads.html#00062


Packages thought to break are
cnvkit influxdb-python snakemake statsmodels tqdm
with pandas 0.25, plus
dask python-biom-format seaborn
if later upgraded to 1.0.  However, this is based on transition testing 
in unstable (#931557 / #950430), so there may be more in buster.


It would probably also be necessary to backport some of pandas' (build) 
dependencies, and at least pytest would involve similar breakage.


The Neurodebian backports mentioned above stop at 0.23, which current 
stable already has.

Bug#929804: gnome-maps: crash when exporting map as the image

[Phil Wyett]

Hi all,

I have tried to reproduce this bug on Debian stable (buster) for a
number of months and failed to do so.

As the original reporter has migrated to another 'testing' version and
desktop. I think we should close this bug?

Regards

Phil

-- 

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Dirk Eddelbuettel]

All,

R 4.0.0 was released as scheduled on Friday, source packages have been in
experimental since Friday too.

There is one build failure on ppc64el but we now know what causes it so a bug
fix from upstream should be forthcoming shortly.  The bug can also be
circumvented by (on that platform only) configuring with --disable-long-double.

As such, we're ready, so I may I would like to nudge you towards considering
a start for this transition.  R is reasonably widely used language that is
very well supported in Debian, and it would be good to have this updated
upstream version be part of Debian testing and the next release.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#959064: ignition-transport FTBFS in testing.

[Jochen Sprickerhof]

Control: reassign -1 cmake 3.16.3-2
Control: subject -i cmake breaks on -isystem
Control: affects -1 ignition-transport

* peter green  [2020-04-28 23:15]:

Package: ignition-transport
Version: 8.0.0+dfsg-3
Severity: serious

It seems that ignition-transport fails to build in testing with the following 
error.


CMake Error in src/CMakeLists.txt:
  Imported target "ZeroMQ::ZeroMQ" includes non-existent path

"-isystem"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in src/CMakeLists.txt:
  Imported target "ZeroMQ::ZeroMQ" includes non-existent path

"-isystem"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.




I first ran into this on a raspbian bullseye autobuilder, but it's also 
happening on reproducible builds, so it doesn't seem to be raspbian specific.

This doesn't seem to be showing up in the reproducible builds logs for 
unstable, that could either mean that it's a testing-specific issue or it could 
be because the reproducible builds logs for unstable are older than those for 
testing.



I was able to reproduce this using:

$ sudo apt install libzmq3-dev cmake pkg-config

$ cat > foot.c << HERE
int main() { }
HERE

$ cat CMakeLists.txt << HERE
cmake_minimum_required(VERSION 3.16)
project(foo)

include(FindPkgConfig)
pkg_check_modules(ZeroMQ IMPORTED_TARGET libzmq)

add_executable(foo foo.c)
target_link_libraries(foo PkgConfig::ZeroMQ)
HERE

$ cmake .
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Checking for module 'libzmq'
--   Found libzmq, version 4.3.2
-- Configuring done
CMake Error in CMakeLists.txt:
  Imported target "PkgConfig::ZeroMQ" includes non-existent path

"-isystem"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in CMakeLists.txt:
  Imported target "PkgConfig::ZeroMQ" includes non-existent path

"-isystem"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

What I found up to now:

- pkg-config=0.29.2-1:

  $ pkg-config --cflags-only-I libzmq
  -isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.2

- Whereas pkg-config=0.29-6 (or pkgconfig):

  $ pkg-config --cflags-only-I libzmq
  -I/usr/include/pgm-5.2

So the recent update of pkg-config has a new behaviour, introduced in

https://bugs.freedesktop.org/show_bug.cgi?id=97337

Changing -isystem /usr/include/mit-krb5 to -isystem/usr/include/mit-krb5 
works in the .pc file(s) works around this but man gcc indicates that a 
space after -isystem seems fine as well.


I think cmake should handle -isystem¹ and as this is reproducible 
without ignition-transport, I'm reassigning this to cmake.


Cheers Jochen

¹: I guess the same problem arises for -I but I haven't checked 
that.


signature.asc
Description: PGP signature

Bug#910876: first version of a package

[Petter Reinholdtsen]

[Gürkan Myczko]
> And I'm not sure on the issue:
> https://github.com/swwa/audmes/issues/1
> (it might, or not might pass ftp-master, bets?)

Note, swwa now have write access to the upstream repo on 
https://sourceforge.net/projects/audmes/ >.  So do I, btw. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#958277: (no subject) (but why there is no subject is a mystery to us all)

[Vagrant Cascadian]

So, it seems we potentially have several different issues, and should
discuss them in separate bug reports:

* How to make the documentation clearer about --profiles
vs. --auto-profiles

* For some reason --locale and --keyboard didn't work for you.

* What references should there be between the simple-cdd README and the
  debian-handbook?

* More references in the simple-cdd README to relevent chapters in the
  debian-installer.

* others?

I've touched on them each below, but it would be best to break them up
into separate issues soon so they can be tracked individually.

On 2020-04-29, Buck wrote:
>> --profiles selects what profiles are included on the generated images,
>> essentially copying the files from ./profiles/ and/or
>> /usr/share/simple-cdd/profiles/ files onto the installer media for the
>> relevent profile, and determines which packages are available on the
>> install media.
>> 
>> --auto-profiles effectively preseeds which profiles to install when you
>> boot the installer, if you do not use --auto-profiles, it will ask you
>> which profiles you want to install when you boot the installer media
>> (e.g. USB, DVD, CD, etc.).
>
> Interesting.  I do not understand what it means "to install when you
> boot the installer" vs "include on the generated images" here.

> They both sound like exactly the same thing: profiles that exist on a
> built installer image.  Are you distinguishing between the image, and
> the installer?  What is the distinction?  The image is an installer
> image, no?  Because from your explanation we have:

> Using --profiles: preseeds which profiles to install when you boot the
> installer NOT using --auto-profiles: does NOT preseed which profiles
> to install when you boot the installer

Using --profiles does not select which profiles to install, it selects
which provides are *available* to be installed. Using --auto-profiles
preseeds which profiles to install.


> But there's an omission by contrapositive here.  The questions are
> what *does* each one do, and how do those things differ?  Because,
> notice that NOT using a giraffe also does NOT preseed which profiles
> to install.

Well... --profiles merely determines which simple-cdd profiles are
available and present on the generated installer media (CD, DVD, USB
stick, etc).

While --auto-profiles answers (a.k.a. preseeds) the question that
simple-cdd would otherwise ask at run-time (e.g. when you boot the
generated installer media).

If you use --profiles without --auto-profiles, it should ask you which
profiles you want installed while you are running the installer.


> I am not trying to be rude, just to point out the source
> of the confusion.  I think you know enough to infer something that I
> do not, and I am asking you to state that inference explicitly so I
> understand these two similar flags.

They are maybe similar in name, but not in function, but my ability to
explain further is exhausted. Hopefully the above finally makes sense to
you.

If you need more detail, how they work is in the code itself.


>> As explained in the simple-cdd README
>
> You keep coming back to this.  Should this be taken to mean that the
> README in /usr/share/simple-cdd/README is the authoritative text on
> simple-cdd?

Yes.


>> Presumably, you've encoutered a warning from simple-cdd, as it cannot
>> verify that it's a valid preseeding file (the password configuration is
>> tested with a different database that requires root access, and
>> simple-cdd should not be run as root).
>
> No, I received no simple-cdd warnings when running `$ build-simple-cdd 
> --profiles custom` where "custom" is the file you are commenting on.  No 
> warnings at all.

Maybe that issue is fixed, then. Or maybe something is broken. I'll have
to check myself at this point.


>>> # Individual additional packages to install
>>>  d-i pkgsel/include string build-essential git w3m secure-delete rsync nmap 
>>> screen tmux sudo pwgen net-tools dnstools
>
>> You need these packages to be available in one of your profiles, or it
>> will require network access... maybe that's ok for you...
>
> It is, but please explain what you mean by "available in one of your 
> profiles" unless you mean this section of the README:
>
> ```
> Create a profile named NAME:
>
>  $ mkdir profiles
>  $ for p in list-of-packages-you-want-installed ; do echo $p >> 
> profiles/NAME.packages ; done
> ```

Yes, exactly that.


> In that case, I understand what you're trying to say, although it took
> work to bridge the gap.  It sounds, then, that NAME.packages requires
> the network when the image is created, so it can have the packages
> ready for the installer.

Yes, that's largely the point of simple-cdd; It generates an installer
media with the packages you want available on the installer media, with
debconf preseeding for the installation process itself, as well as
preseeding for the packages that you might install. It's intended that
you could complete the install from the media 

Bug#959092: Short description inadequate to tell what package does

[Jonas Smedegaard]

Let's try again...

Quoting Andrej Shadura (2020-04-29 12:58:29)
> On Wed, 29 Apr 2020 at 12:51, Jonas Smedegaard  wrote:
> > This is my current draft of new description (replacing short 
> > description and adding a section to long description, both to 
> > clarify which "matrix" it is):
> 
> > > Description: python no-IO library for the matrix chat protocol - Python3 
> > > library
> > >  Nio is a multilayered Matrix client library.
> > >  The underlying base layer doesn't do any IO on its own.
> > >  On top of the base layer,
> > >  a no-IO HTTP client implementation exists,
> > >  as well as a full fledged batteries included asyncio layer
> > >  using aiohttp.
> > >  .
> > >  Matrix is an open standard and lightweight protocol
> > >  for real-time communication.
> >
> > Do you perhaps have suggestions for further improvements?
> 
> How about s/[mM]atrix/Matrix.org/ in the short description and in the
> first line of the long one?

[later rephrased to s/matrix/Matrix/ and s/python/Python/ ]

I understand now that by "How about..." you did not mean "Let me suggest 
to do this..." but instead "Are you aware that you seemingly 
accidentally did this..."

To clarify: I lowercased those two words deliberately, because I think 
they are more appropriate to write lowercased.

It seems you disagree with that.

I have no strong opinion, other than to only uppercase when really 
needed (not being "too fancy").

Therefore: Can you please describe in more detail *why* you consider it 
wrong of me to change those words to be all lowercase?


 - Jonas

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

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

signature.asc
Description: signature

Bug#959125: xdg-desktop-portal-gtk: does not provide implementations for org.freedesktop.impl.portal.{ScreenCast,RemoteDesktop}

[Simon McVittie]

Control: block -1 by 954022

On Wed, 29 Apr 2020 at 17:13:08 +0100, Pedro Ângelo wrote:
> looking upstream, there's an issue reported about xdg-desktop-portal-gtk not
> instantiating the ScreenCast and RemoteDesktop interfaces on Ubuntu

It needs a newer version of pipewire (see #954022).

> it seems to never return from the call to `createSession`

The error behaviour when not everything needed is available is also
not great (it should fail cleanly with an error rather than waiting
forever). I'm not sure whether that's an xdg-desktop-portal or
xdg-desktop-portal-gtk bug.

smcv

Bug#959131: adding symbolic link from debian/build_modules does not work for @babel/* and others with similar names

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.9.33
Severity: important

With #959015 fixed, I tried to add @babel/plugin-check-constants in 
node-fbjs debian/build_modules but it failed to create a correct 
symbolic link.


It should support namespaces with @directory structure or should read 
package.json to create the final directory structure.

Bug#959092: Short description inadequate to tell what package does

[Jonas Smedegaard]

Quoting Sam Hartman (2020-04-29 18:20:07)
> > "Jonas" == Jonas Smedegaard  writes:
> 
> 
> Jonas> How is "matrix chat protocol" inadequate to tell what package
> Jonas> does, which a change to capitalization of initial character
> Jonas> fixes?
> 
> I think this is more confrontational than I'd like to see in Debian.

That was certainly not my intention.  thanks for pointing out that you 
perceived it that way, that is helpful to me.


> It is very common in many development communities  when reviewing a
> change to discuss problems introduced by that change in the issue where
> that change is being reviewed.
> So, in how we commonly use the BTS, I think the following sequence is
> fine:
> 
> 1) Hi.  I'd like the description to be more clear.
> 
> 2) Here's a proposed description.  Is this description more clear.
> 
> 3) Yes, that description is more clear, but you introduced a problem in
> the new text.
> 
> That is, problems introduced by the change are reasonable to discuss
> *while reviewing the change*
> *even if they are not directly related to the gola of the cchange*.

I agree that above conversation style is sensible.

I did not experience this conversation as being like the above, however, 
but more like this:

3) Yes, that description is more clear, and let's also replace protocol 
name with hostname, with uppercased initial letter.  And also change 
this other contro file hint.

4) I disagree that hostname is more clear than protocol.

5) But it is wrong.

6) Not adopting your proposed suggestion is wrong? How is it wrong?

7) The text is wrong.  I think you made a mistake.

8) [Ohhh, this is about _reverting_ not about _adding_ change]
No, the changes in current draft was deliberat (not accidental).

9) But it really is wrong.

10) I now understand that we are talking about dialing back some changes 
I did (not adding new changes you propose), but it is still not clear to 
me *how* it is wrong.  I need you to explain _how_ it is wrong, not just 
insist _that_ it is wrong.

11) You are silly that you insist on discussing this.

12) [WTF?] What are we discussing here? I insist on understanding you 
instead of dismissing your odd initial suggestion, but it is hard. Give 
me something to work with, not just repeat your solution to a problem 
only you see.


> If the complaint was about a alleged capitalization error already in 
> the description, it might be reasonable to ask for another bug.
> But if as part of clarifying the description, you introduce a change 
> that someone believes is a capitalization error, I think that you are 
> being overly confrontational to push that off elsewhere.

Yes, *if* I did such error, then it was overly confrontational of me to 
push off discussion of it.

I was trying to figure out *if* I had made an error.

Or rather, later in the conversation I tried to do that.  Because the 
converation (with Andrew) started not with talking about me having made 
an error, but instead him suggesting an additional (arguably stylistic 
too fancy) change, and him pointing out another unrelated issue in the 
packaging.

I found the conversation confusing, which made me continue to include 
the option of "maybe it turns out that he is really talking about 
womething third which might be sensible in itself but only *inspired* by 
this bug not tightly related to it, which means I am much better helped 
at being clued in if _he_ gets to decide the topic of the conversation 
by filing it as a separate bugreport".


> Certainly my frustration is high enough that in the future I am much 
> less likely to try and suggest small problem or improvements than I 
> was before this conversation.

That is really awful.

I was really quite happy that you filed this bugreport (not something I 
wrote just to be polite).

I was also happy that Andrew chimed in and contributed to the 
conversation.  I was *frustrated* that I did not understand Andrew, but 
wanted to.  Wanted to understand, I mean - not drive you both away!


> I also happen to believe that Python and Matrix should be capitalized 
> in that text under our standard style for descriptions.

Ok.  I would love to discuss that further.  With you and with Andrew.

I was genuinely quite uncertain if that is the conversation Andrew 
wanted to have - I tried to figure out which conversation Andrew really 
wanted to have (other than "here is the fix, just accept it instead of 
being silly by discussing it").


> I might be wrong about that, but it seems kind of unreasonable to push 
> that off to a different discussion and to narrowly scope the questions 
> as you have done.

I did _not_ want to push _that_ conversation off.

I wanted to push anything _unrelated_ off.

I kept asking "how is it relevant" and I meant exactly that.

I see how it can be misread as me really between the lines saying "come 
on, admit that you have nothing sensible to say here - go file another 
bug that I will ignore for a few years" but that is 

Bug#959130: i3status: Drop CAP_NET_ADMIN and libcap2-bin rec

[Cédric Hannotier]

Package: i3status
Version: 2.13-2
Severity: normal

Dear Maintainer,

Since [1], capability CAP_NET_ADMIN is no more required to request
Ethernet speed (related to EOL of a specific kernel version).
However, it seems that there is an old postinstall file [2] that still
tries to add it. Could you update the packaging process?

Regards,
Cédric

[1] 
https://github.com/i3/i3status/commit/03c8908ec6429a67c3a8f480f1002788ff155bfb
[2] 
https://salsa.debian.org/i3-team/i3status/-/blob/02705f8792c5fded19e180f5733f86ca23f707e7/debian/i3status.postinst

Bug#926416: licensing Re: ITP: conda

[Rebecca N. Palmer]

Note that these are distinct:
- conda, the package manager itself; BSD-3 licensed
- Anaconda Individual Edition, a bundle of conda + some commonly-used 
packages; non-DFSG-free as it includes intel-mkl and cudnn 
(https://docs.anaconda.com/anaconda/eula/)
- Anaconda repository, the server conda uses by default 
(https://repo.anaconda.com/pkgs/); has a no-unauthorized-mirrors policy


conda does not have to use its default server, as packages can be 
created with conda-build (also BSD-3 licensed) and distributed with 
standard web servers: 
https://conda.io/projects/conda/en/latest/user-guide/tasks/create-custom-channels.html


Did you find an intel-mkl dependency in conda itself, or only in packages?

Bug#910876: first version of a package

[Gürkan Myczko]

On 29.04.2020 17:13, Petter Reinholdtsen wrote:

[Gürkan Myczko]

I had completely forgotten about that, but beimg part of the
multimedia team, I would go ahead and rename the RFP to ITP and go for
it, unless someone else wants to do so very hard.

I would refresh/update the pkg, and put it on salsa of mm team.


Very good. :)


If you disagree it is yours, go ahead.


No objections here.   Note, there have been upstream improvements since
you made your package. :)


Great, so the package is ready (as dsc dget'able):
http://phd-sid.ethz.ch/debian/audmes/audmes_0%2Bgit20200429-1.dsc

On Salsa in the right team:
https://salsa.debian.org/multimedia-team/audmes

And I'm not sure on the issue:
https://github.com/swwa/audmes/issues/1
(it might, or not might pass ftp-master, bets?)

Best,

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

[Ryan Pavlik]

I'm not sure who was in the wrong here, if OpenXR shouldn't have had
that NVX line in the source, or if the removal of that symbol form the
header was not expected. In any case, the error-inducing line
"_(INDIRECT_COMMANDS_LAYOUT_NVX)" can be patched out of
OpenXR-SDK-Source - the next upstream release has that change already
queued.

If this isn't a Vulkan bug, I can revise the OpenXR-SDK-Source
package, though it will need sponsorship as usual.

Ryan


On Sat, Apr 25, 2020 at 1:45 PM Paul Gevers  wrote:
>
> Source: vulkan-loader, openxr-sdk-source
> Control: found -1 vulkan-loader/1.2.135.0-2
> Control: found -1 openxr-sdk-source/1.0.8~dfsg1-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> Dear maintainer(s),
>
> With a recent upload of vulkan-loader the autopkgtest of
> openxr-sdk-source fails in testing when that autopkgtest is run with the
> binary packages of vulkan-loader from unstable. It passes when run with
> only packages from testing. In tabular form:
>
>passfail
> vulkan-loader  from testing1.2.135.0-2
> openxr-sdk-source  from testing1.0.8~dfsg1-2
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration of vulkan-loader to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=vulkan-loader
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/openxr-sdk-source/5144212/log.gz
>
> autopkgtest [19:21:52]: test build-hello-xr-vulkan-xlib:
> [---
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:
> In member function ‘VkBool32
> {anonymous}::VulkanGraphicsPlugin::debugReport(VkDebugReportFlagsEXT,
> VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t, const char*,
> const char*)’:
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
> error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not
> declared in this scope; did you mean
> ‘VK_DEBUG_REPORT_OBJECT_TYPE_END_RANGE_EXT’?
>  1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
>   |  ^~~~
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1638:5:
> note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
>  1638 | _(OBJECT_TABLE_NVX)  \
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
> note: in expansion of macro ‘LIST_OBJECT_TYPES’
>  1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
> error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NVX_EXT’
> was not declared in this scope; did you mean
> ‘VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT’?
>  1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
>   |  ^~~~
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1639:5:
> note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
>  1639 | _(INDIRECT_COMMANDS_LAYOUT_NVX)
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
> note: in expansion of macro ‘LIST_OBJECT_TYPES’
>  1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
>   | ^
> autopkgtest [19:22:04]: test build-hello-xr-vulkan-xlib:
> ---]
>

Bug#959129: python3-imdbpy: episode `'original air date'` should be a datetime object, not a string

[Sandro Tosi]

Package: python3-imdbpy
Version: 6.8-2
Severity: wishlist

Hello,
when checking episodes data via imdb, the value of 'original air date' is a
string, f.e.:

{'title': 'Louis T. Steinhil (No. 27)',
 'kind': 'episode',
 'episode of': ,
 'season': 7,
 'episode': 1,
 'rating': 8.701234567891,
 'votes': 749,
 'original air date': '4 Oct. 2019',  # <-
 'year': '2019',
 'plot': '\nAfter being abducted by Katarina Rostova, Reddington []'}

if would be extremely more helpful if that information was actually a datetime
object; sure it could be processed with dateutil.parser, but it seems something
the API should do.

Probably should be forwarded upstream.

Please also consider maintaining this package under the Debian Python Modules
Team.

Regards,
Sandro


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

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

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

Versions of packages python3-imdbpy recommends:
ii  python3-lxml  4.5.0-1.1

Versions of packages python3-imdbpy suggests:
ii  python3-sqlalchemy  1.3.11+ds1-1
pn  python3-sqlobject   

-- no debconf information

Bug#947400: closed by Debian FTP Masters (reply to Picca Frédéric-Emmanuel ) (Bug#947400: fixed in hkl 5.0.0.2615-1)

[Adrian Bunk]

Control: reopen -1

On Wed, Apr 29, 2020 at 05:09:05PM +, Debian Bug Tracking System wrote:
>...
>  hkl (5.0.0.2615-1) unstable; urgency=medium
>  .
>* New upstream version 5.0.0.2615
>* Bug fix: "hkl FTBFS on arm64: sirius segfaults", thanks to Adrian Bunk
>  (Closes: #947400).
>...

Still segfaults:

https://buildd.debian.org/status/fetch.php?pkg=hkl=arm64=5.0.0.2615-1=1588180991=0

cu
Adrian

Bug#959128: python3-imdbpy: please rename to python3-imdb

[Sandro Tosi]

Package: python3-imdbpy
Version: 6.8-2
Severity: important

Hello,
python3-imdbpy should be renamed to python3-imdb since `imdb` is the top-level
module that you `import`.

Regards,
Sandro

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

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

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

Versions of packages python3-imdbpy recommends:
ii  python3-lxml  4.5.0-1.1

Versions of packages python3-imdbpy suggests:
ii  python3-sqlalchemy  1.3.11+ds1-1
pn  python3-sqlobject   

-- no debconf information

Bug#956872: src:frr: fails to migrate to testing for too long: ftbfs on mipsel

[Ivo De Decker]

Hi,

On Thu, Apr 16, 2020 at 09:48:09AM +0200, Paul Gevers wrote:
> Subject: src:frr: fails to migrate to testing for too long: ftbfs on mipsel

> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.

Please note that frr will be manually removed from testing in the next few
days, because the version in testing is older than the version in
stable-proposed-updates (which will go into stable in the next point release).

Cheers,

Ivo

Bug#958104: system-config-printer-udev: ABRT: free(): invalid pointer

[Mattia Rizzolo]

Hello there!

On Tue, Apr 28, 2020 at 12:35:52AM +0200, Bernhard Übelacker wrote:
> Dear Maintainer,
> looking at the backtrace from message 13 and at the changes
> done by upstream, following commit sounds related:
> 
> https://github.com/OpenPrinting/system-config-printer/commit/b9289dfe105bdb502f183f0afe7a115ecae5f2af#diff-d3f2f90b6e176486d4b8dfe3222577f7

Indeed!

I opened a MR at
https://salsa.debian.org/gnome-team/system-config-printer/-/merge_requests/1
picking that and the previous, related, commit.

After trying, the thing doesn't crash anymore, though it does still
fail:
Apr 29 18:58:45 warren systemd[1]: Started Configure Plugged-In Printer.
Apr 29 18:58:45 warren udev-configure-printer[3076204]: add usb-001-008
Apr 29 18:58:45 warren udev-configure-printer[3076204]: device devpath is 
/devices/pci:00/:00:14.0/usb1/1-1
Apr 29 18:58:45 warren udev-configure-printer[3076204]: Device already handled
Apr 29 18:58:45 warren systemd[1]: configure-printer@usb-001-008.service: Main 
process exited, code=exited, status=1/FAILURE
Apr 29 18:58:45 warren systemd[1]: configure-printer@usb-001-008.service: 
Failed with result 'exit-code'.


I didn't debug further, and I know nothing about udev so maybe it just
needs some poking?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#956891: Same error in different machine

[Arturo Borrero Gonzalez]

Hi there,

I got the exact same error in a different laptop.
Using kernel 5.4.19-1 (5.4.0-4)

See attached file for the kernel log.
Apr 29 17:48:47 ranger kernel: [ 3252.715611] BUG: kernel NULL pointer 
dereference, address: 0040
Apr 29 17:48:47 ranger kernel: [ 3252.715616] #PF: supervisor read access in 
kernel mode
Apr 29 17:48:47 ranger kernel: [ 3252.715618] #PF: error_code(0x) - 
not-present page
Apr 29 17:48:47 ranger kernel: [ 3252.715619] PGD 0 P4D 0 
Apr 29 17:48:47 ranger kernel: [ 3252.715623] Oops:  [#1] SMP PTI
Apr 29 17:48:47 ranger kernel: [ 3252.715627] CPU: 1 PID: 1129 Comm: xfwm4 
Tainted: P   OE 5.4.0-4-amd64 #1 Debian 5.4.19-1
Apr 29 17:48:47 ranger kernel: [ 3252.715629] Hardware name: LENOVO 
81BF/LNVNB161216, BIOS 6JCN23WW 01/23/2018
Apr 29 17:48:47 ranger kernel: [ 3252.715680] RIP: 
0010:i915_active_acquire+0x9/0x70 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715682] Code: 00 00 00 48 c7 46 58 00 00 
00 00 c7 46 38 00 00 00 00 48 c7 c6 0a 70 62 c0 e9 33 c0 b9 e6 0f 1f 00 0f 1f 
44 00 00 41 54 55 53 <8b> 47 38 48 89 fb 85 c0 74 15 8d 50 01 f0 0f b1 53 38 75 
f2 45 31
Apr 29 17:48:47 ranger kernel: [ 3252.715684] RSP: 0018:a33681ea7a40 
EFLAGS: 00010286
Apr 29 17:48:47 ranger kernel: [ 3252.715686] RAX:  RBX: 
8f0a246cdf00 RCX: 
Apr 29 17:48:47 ranger kernel: [ 3252.715687] RDX: 8f0a1ab9df80 RSI: 
8f0a246cdf00 RDI: 0008
Apr 29 17:48:47 ranger kernel: [ 3252.715688] RBP: 8f0a1ab9df80 R08: 
8f09bcb9e708 R09: 8f09bcb9e708
Apr 29 17:48:47 ranger kernel: [ 3252.715689] R10: a000 R11: 
 R12: 0008
Apr 29 17:48:47 ranger kernel: [ 3252.715690] R13: 0004 R14: 
8f0a1ab9df80 R15: 401c
Apr 29 17:48:47 ranger kernel: [ 3252.715692] FS:  7f2dbf00() 
GS:8f0a33c4() knlGS:
Apr 29 17:48:47 ranger kernel: [ 3252.715693] CS:  0010 DS:  ES:  CR0: 
80050033
Apr 29 17:48:47 ranger kernel: [ 3252.715695] CR2: 0040 CR3: 
0004681e2002 CR4: 003606e0
Apr 29 17:48:47 ranger kernel: [ 3252.715696] Call Trace:
Apr 29 17:48:47 ranger kernel: [ 3252.715730]  i915_active_ref+0x21/0x210 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715734]  ? _cond_resched+0x15/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715766]  
i915_vma_move_to_active+0x6e/0xf0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715795]  
i915_gem_do_execbuffer+0xc62/0x1520 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715800]  ? _cond_resched+0x15/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715802]  ? mutex_lock+0xe/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715805]  ? 
unix_stream_read_generic+0x1f7/0x8f0
Apr 29 17:48:47 ranger kernel: [ 3252.715809]  ? __kmalloc_node+0x1f5/0x300
Apr 29 17:48:47 ranger kernel: [ 3252.715835]  
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715865]  ? 
i915_gem_madvise_ioctl+0x13a/0x290 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715891]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715906]  drm_ioctl_kernel+0xaa/0xf0 [drm]
Apr 29 17:48:47 ranger kernel: [ 3252.715918]  drm_ioctl+0x208/0x390 [drm]
Apr 29 17:48:47 ranger kernel: [ 3252.715945]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715948]  do_vfs_ioctl+0x40e/0x670
Apr 29 17:48:47 ranger kernel: [ 3252.715950]  ksys_ioctl+0x5e/0x90
Apr 29 17:48:47 ranger kernel: [ 3252.715952]  __x64_sys_ioctl+0x16/0x20
Apr 29 17:48:47 ranger kernel: [ 3252.715956]  do_syscall_64+0x52/0x160
Apr 29 17:48:47 ranger kernel: [ 3252.715959]  
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 29 17:48:47 ranger kernel: [ 3252.715961] RIP: 0033:0x7f2ef03bd427
Apr 29 17:48:47 ranger kernel: [ 3252.715964] Code: 00 00 90 48 8b 05 69 7a 0c 
00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 
b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 7a 0c 00 f7 d8 64 
89 01 48
Apr 29 17:48:47 ranger kernel: [ 3252.715965] RSP: 002b:7fffd63b65c8 
EFLAGS: 0246 ORIG_RAX: 0010
Apr 29 17:48:47 ranger kernel: [ 3252.715967] RAX: ffda RBX: 
7fffd63b6610 RCX: 7f2ef03bd427
Apr 29 17:48:47 ranger kernel: [ 3252.715968] RDX: 7fffd63b6610 RSI: 
40406469 RDI: 000a
Apr 29 17:48:47 ranger kernel: [ 3252.715969] RBP: 40406469 R08: 
55d72e5a8000 R09: 
Apr 29 17:48:47 ranger kernel: [ 3252.715970] R10:  R11: 
0246 R12: 55d72e8d1ba0
Apr 29 17:48:47 ranger kernel: [ 3252.715971] R13: 000a R14: 
 R15: 7f2eed182e08
Apr 29 17:48:47 ranger kernel: [ 3252.715973] Modules linked in: ctr ccm 
nvidia_modeset(POE) bnep bbswitch(OE) intel_rapl_msr intel_rapl_common 
snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp 
snd_soc_acpi_intel_match 

Bug#956014: new upstream LTS version

[Harald Dunkel]

Hi Pierre,

sorry, I haven't seen your EMail. I am on vacation till end of this week.

I have backported the new lxc package to buster and installed it on my
office PC, but I didn't had a chance to do more than just a very brief test.
Hopefully I can install it on some "real" lxc servers next week.


Thanx for the new package

Regards
Harri

Bug#949974: More details

[Enrico Zini]

On Mon, Jan 27, 2020 at 09:46:35PM +0100, Enrico Zini wrote:

> If there is still data to write, self._pending_write is not done when
> future_add_done_callback is called, and RequestHandler.flush() won't get
> stuck.

Keeping the write buffer nonempty is not sufficient: if it remains with
a few data, the problem is triggered anyway, as it will managed to get
written right away and set the _pending_write future to done() before
reaching the event loop, triggering the hang again.

Since this depends on whether there is enough pending data to write to
cause the buffer to block, it's hard to predict what is a reasonable
amount of data to leave in the pipeline as a workaround.

Meaning, I currently cannot find a way to await finish() in tornado 5.

It would be important for me to do so, as it's the only way I have to be
able to log an outcome of a request, figuring out for example if the
remote has closed the connection early.

 - - -

To answer Julien Puydt, this is fixed upstream in Tornado 6, which is
not in Debian yet.

I would call this by now a debian-specific bug, and I think it's useful
to document it here, rather than waste upstream's time with an issue
they have fixed in a version releases a year ago.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#959127: gobjc-10: @selector broken for selectors with repeated colons

[Yavor Doganov]

Package: gobjc-10
Version: 10-20200418-1
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Tags: fixed-upstream
Control: block 957078 by -1
Control: block 957295 by -1
Control: block 957682 by -1
Severity: normal

$ cat test.m
#include 

int
main (void)
{
  SEL sel = @selector (method::);

  return 0;
}
$ gcc-10 test.m -lobjc
test.m: In function ‘main’:
test.m:6:30: error: expected ‘)’ before ‘::’ token
6 |   SEL sel = @selector (method::);
  |   ~  ^~
  |  )
$ gcc-9 test.m -lobjc
$

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

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

Versions of packages gobjc-10 depends on:
ii  gcc-10  10-20200418-1
ii  gcc-10-base 10-20200418-1
ii  libc6   2.30-4
ii  libc6-dev   2.30-4
ii  libgmp102:6.2.0+dfsg-4
ii  libisl220.22.1-1
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.2-1
ii  libobjc-10-dev  10-20200418-1
ii  libzstd11.4.4+dfsg-3
ii  zlib1g  1:1.2.11.dfsg-2

gobjc-10 recommends no packages.

Versions of packages gobjc-10 suggests:
pn  gcc-10-doc 
pn  gobjc-10-multilib  

-- no debconf information

Bug#955469: initramfs-tools-core: Enable zstandard support

[Ben Hutchings]

On Tue, 2020-04-28 at 04:43 +0100, Ben Hutchings wrote:
> On Wed, 01 Apr 2020 09:05:22 +0200 Norbert Lange  wrote:
> > Package: initramfs-tools-core
> > Version: 0.136
> > Severity: wishlist
> > Tags: patch
> > 
> > Hello,
> > 
> > there are Kernelpatches for zstandard initramfs support
> > available for several years, and will hopefully accepted
> > upstream soon.
> 
> If the kernel doesn't yet support it, I'm not sure what the point of
> supporting it in initramfs-tools is.
[...]

I see that the kernel support for this has been submitted recently,
though it's not clear which maintainer is being asked to apply the
patches.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.




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

Bug#957295: New GCC bug

[Yavor Doganov]

On Fri, 17 Apr 2020 14:43:15 +0300,
Richard Frith-Macdonald wrote:
> I noticed this issue, and thought it might be useful to point out
> that this is clearly a new compiler bug.

Yes, many thanks for reporting it to the GCC developers (FTR,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637).

Bug#959037: lintian: FPOS? for executable-in-usr-lib

[Mattia Rizzolo]

On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> ACK. d-i won't be looking in /usr/libexec. Please leave things where
> they are...

Good, then @lintian-maint: please exclude udebs from this check :)
(as I think used to be in the past, since I don't think I saw this tag
years ago in this package, but I know it has been there for a while…)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#959076: yara: FTBFS on armhf due to test failures

[Hilko Bengen]

* Simon Quigley:

> Package: src:yara
> Version: 3.3.0+dfsg-2.1

The version seems wrong. Did you mean 3.11.0-2?

> In Ubuntu, after doing a no-change rebuild of your package, the armhf
> build fails with the following error (the full build log is attached):
>
> FAIL: test-rules
> 
>
> yr_rules_scan_mem: error
> FAIL test-rules (exit status: 1)

Unfortunately, the error message is somewhat lacking. I just added some
improvements to 3.11.0-3. Let's see what those shake out.

Cheers,
-Hilko

Bug#959126: lintian: description for package-uses-old-debhelper-compat-version needs update

[gregor herrmann]

Package: lintian
Version: 2.69.0
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since 
https://salsa.debian.org/lintian/lintian/-/commit/bc895a4b41571e8ae4d92ecb8f3ec9eb0f701958
lintian warns about a debhelper compat level < 13. Perfectly fine.
But it looks like the description needs an update as well, currently
we see:

P: libobject-pad-perl source: package-uses-old-debhelper-compat-version 12
[…]
N:The compatibility version can be set by specifying debhelper-compat (=
N:12) in your package's Build-Depends, by the legacy debian/compat file or
N:even by setting and exporting DH_COMPAT in debian/rules. If it is not
N:set in either place, debhelper defaults to the deprecated compatibility
N:version 1.

A simple s/12/13/ in the right file should be enough :)


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl6prVtfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbb/g//SPTQZGHpRjO1pv7PDgi4+MOhh0n5+yOrj0R9ku1VgNBnx2//iMlKJZ4S
fjLWB1eP6C16cfqbc69tzLTL12HuEFZgnLbN4so0Zs05+Siuj+3gLmDpv8EWW4Ul
1L1SXLe7ZZ1JSE4OCCBsUUZp+XZtxoiFwy/OIUX2eTeeoPX3Jo0dR//kbaGrsVsE
ewL2obAj3q5Q+dpanJpwpRWOWrJeVwMImwGsJ84h7XT7GmoLwncdOTdDJYwTnp49
l/hwXpwLcpc+Trrxsx3/op0wvV8nU3rnQyfy+Ty1nDvNqD2QtDRE3hJ24XYYaYQa
sAN1PRUA5V5EOAtF6v+nRXZKy9ZiDfIpx5PIH5197Di4tLhztRclNQEIXoOqMoUD
5TTLV5Gz+HUWxpkFdq5PFuA9PXhmekIj4zlKB9BpGi+z1FHO4vswLbZJCHe4dOho
P74TzyQPHmgxFlg9eTABe+IFzVBqEnqlVBvotkDpfX1tK3EjWm7/OMmRz8gGwK2W
4S2RxQHkHCEpXBqcOwYIevWsGacQwmZgwLvnxFq9ah+dMlTdR4CcPAthGHP3DBzZ
xLtoOmIjO4tleudrQOY+vmlkrDNCuEz2isDCqL8hjg1cShjHOo8HZBbqVwZEMJqd
0+M2CcFBVL6SK+gDqvECLLGL52Cchaa15UyfoeKXRNd2FuOenck=
=Qjb2
-END PGP SIGNATURE-

Bug#959118: blender fails to start - missing libosdGPU.so.3.4.0 library

[Sebastian Ramacher]

Control: reassign -1 libosdgpu3.4.0 3.4.3-1

On 2020-04-29 10:25:13 -0500, David Palacio wrote:
> Package: blender
> Version: 2.82.a+dfsg-1+b1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> After a recent system upgrade Blender fails to start. In the terminal output 
> the following error message can be read:
> 
> blender: error while loading shared libraries: libosdGPU.so.3.4.0: cannot 
> open shared object file: No such file or directory
> 
> I could manage to get Blender to start by downgrading libosdcpu3.4.0 and 
> libosdgpu3.4.0 to the latest 3.4.0 version.

libosdgpu bumped its SONAME, but the package name did not change. This
is a bug in libosdgpu. Reassigning accordingly.

> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages blender depends on:
> ii  blender-data  2.82.a+dfsg-1
> ii  fonts-dejavu  2.37-1
> ii  libavcodec58  7:4.2.2-1+b1
> ii  libavdevice58 7:4.2.2-1+b1
> ii  libavformat58 7:4.2.2-1+b1
> ii  libavutil56   7:4.2.2-1+b1
> ii  libboost-locale1.67.0 1.67.0-17+b1
> ii  libc6 2.30-4
> ii  libfftw3-double3  3.3.8-2
> ii  libfreetype6  2.10.1-2
> ii  libgcc-s1 10-20200418-1
> ii  libgl11.3.1-1
> ii  libglew2.12.1.0-4+b1
> ii  libgomp1  10-20200418-1
> ii  libilmbase24  2.3.0-6
> ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
> ii  libjemalloc2  5.2.1-1
> ii  libjpeg62-turbo   1:1.5.2-2+b1
> ii  libopenal11:1.19.1-1+b1
> ii  libopencolorio1v5 1.1.1~dfsg0-6+b1
> ii  libopenexr24  2.3.0-6
> ii  libopenimageio2.1 2.1.13.0~dfsg0-1
> ii  libopenjp2-7  2.3.1-1
> ii  libopenvdb7.0 7.0.0-3
> ii  libosdcpu3.4.03.4.3-1
> ii  libosdgpu3.4.03.4.3-1
> ii  libpcre3  2:8.39-12+b1
> ii  libpng16-16   1.6.37-2
> ii  libpython3.8  3.8.2-1+b1
> ii  libsdl1.2debian   1.2.15+dfsg2-5
> ii  libsndfile1   1.0.28-7
> ii  libspnav0 0.2.3-1+b2
> ii  libstdc++610-20200418-1
> ii  libswscale5   7:4.2.2-1+b1
> ii  libtbb2   2020.2-2
> ii  libtiff5  4.1.0+git191117-2
> ii  libx11-6  2:1.6.9-2
> ii  libxfixes31:5.0.3-2
> ii  libxi62:1.7.9-1
> ii  libxml2   2.9.10+dfsg-5
> ii  libxrender1   1:0.9.10-1
> ii  libxxf86vm1   1:1.1.4-1+b2
> ii  zlib1g1:1.2.11.dfsg-2
> 
> blender recommends no packages.
> 
> blender suggests no packages.
> 
> -- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959100: ITP: fractal -- Matrix.org messaging app for GNOME written in Rust

[Andrej Shadura]

Hi,

On Wed, 29 Apr 2020 at 17:49, Arnaud Ferraris  wrote:
> Le 29/04/2020 à 16:52, Andrej Shadura a écrit :
> > Hi Arnaud and Henry-Nicolas,
> >
> > Great! I haven’t noticed much happening over in the Rust repos or the
> > IRC channel, where are you co-ordinating? The dependency tree is quite
> > vast, so I suspect there will be enough work for all of us.
>
> We're discussing through a Matrix private chat for now, but we can move
> to something more public.
> We're also using a wiki[1] in salsa to keep track of the dependency tree
> and each crate's packaging status.
>
> [1] https://salsa.debian.org/a-wai/debcargo-conf/-/wikis/Home

It would be great if you used TODO.rst in debcargo-conf, which is the
place others co-ordinate packaging dependencies.

-- 
Cheers,
  Andrej

Bug#959125: xdg-desktop-portal-gtk: does not provide implementations for org.freedesktop.impl.portal.{ScreenCast,RemoteDesktop}

[Pedro Ângelo]

Package: xdg-desktop-portal-gtk
Version: 1.7.1-1+b1
Severity: important

Dear Maintainer,

while testing a self-compiled version of `obs-xdg-portal` plugin for Open
Broadcast Studio I noticed that the plugin failed to bring up the portal window
necessary to authorize the program to capture the screen.

I looked into this issue with dbus-monitor and got the following:

~~~

$ dbus-monitor path=/org/freedesktop/portal/desktop

method call time=1588071448.258833 sender=:1.531 ->
destination=org.freedesktop.portal.Desktop serial=2
path=/org/freedesktop/portal/desktop;
interface=org.freedesktop.portal.ScreenCast; member=CreateSession
   array [
  dict entry(
 string "handle_token"
 variant string "obs1"
  )
  dict entry(
 string "session_handle_token"
 variant string "obs1"
  )
   ]
method call time=1588071448.273349 sender=:1.473 -> destination=:1.146
serial=213 path=/org/freedesktop/portal/desktop;
interface=org.freedesktop.impl.portal.ScreenCast; member=CreateSession
   object path "/org/freedesktop/portal/desktop/request/1_531/obs1"
   object path "/org/freedesktop/portal/desktop/session/1_531/obs1"
   string ""
   array [
   ]

~~~

and it seems to never return from the call to `createSession`.

looking into the service log I get:

~~~

$ journalctl --user

Apr 27 20:15:26 rae xdg-desktop-por[20017]: A backend call failed:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface
“org.freedesktop.impl.portal.ScreenCast” on object at path
/org/freedesktop/portal/desktop
Apr 27 20:15:26 rae xdg-desktop-por[20017]: Failed to close session
implementation: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such
interface “org.freedesktop.impl.portal.Session” on object at path
/org/freedesktop/portal/desktop/session/1_476/obs1

~~~

looking upstream, there's an issue reported about xdg-desktop-portal-gtk not
instantiating the ScreenCast and RemoteDesktop interfaces on Ubuntu:

https://github.com/flatpak/xdg-desktop-portal-gtk/issues/296

I can reproduce the behaviour reported upstream:

~~~

$ xdg-desktop-portal-gtk --replace --verbose

XDP: providing org.freedesktop.impl.portal.FileChooser
XDP: providing org.freedesktop.impl.portal.AppChooser
XDP: providing org.freedesktop.impl.portal.Print
XDP: providing org.freedesktop.impl.portal.Screenshot
XDP: providing org.freedesktop.impl.portal.Notification
XDP: Using org.gnome.SessionManager for inhibit
XDP: Using org.gnome.Screensaver for screensaver state
XDP: Using org.gnome.SessionManager for session state
XDP: providing org.freedesktop.impl.portal.Inhibit
XDP: providing org.freedesktop.impl.portal.Access
XDP: providing org.freedesktop.impl.portal.Account
XDP: providing org.freedesktop.impl.portal.Email
XDP: providing org.freedesktop.impl.portal.Lockdown
XDP: providing org.freedesktop.impl.portal.Background
...
XDP: providing org.freedesktop.impl.portal.Settings
XDP: providing org.freedesktop.impl.portal.Wallpaper
XDP: org.freedesktop.impl.portal.desktop.gtk acquired

~~~

This happens both in version 1.6.1 from Testing and version 1.7.1 from
Experimental.

I can also reproduce the same broken behaviour for the
`org.freedesktop.impl.portal.RemoteDesktop` interface using upstream's testing
script:

https://gitlab.gnome.org/snippets/39

Please let me know if there's anything else I can do to help fix this, as this
renders any screen grabbing and screen casting application unusable in GNOME
Wayland.

Best regards,

P.



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

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

Versions of packages xdg-desktop-portal-gtk depends on:
ii  dbus-user-session  1.12.16-2
ii  dbus-x11   1.12.16-2
ii  libc6  2.30-4
ii  libcairo2  1.16.0-4
ii  libfontconfig1 2.13.1-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-4
ii  libglib2.0-0   2.64.2-1
ii  libgnome-desktop-3-19  3.36.1-3
ii  libgtk-3-0 3.24.18-1
ii  xdg-desktop-portal 1.7.1-1

xdg-desktop-portal-gtk recommends no packages.

Versions of packages xdg-desktop-portal-gtk suggests:
ii  accountsservice  0.6.55-1
ii  evince   3.36.0-2+b1

-- no debconf information

Bug#959092: Short description inadequate to tell what package does

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:


Jonas> How is "matrix chat protocol" inadequate to tell what package
Jonas> does, which a change to capitalization of initial character
Jonas> fixes?

I think this is more confrontational than I'd like to see in Debian.
It is very common in many development communities  when reviewing a
change to discuss problems introduced by that change in the issue where
that change is being reviewed.
So, in how we commonly use the BTS, I think the following sequence is
fine:

1) Hi.  I'd like the description to be more clear.

2) Here's a proposed description.  Is this description more clear.

3) Yes, that description is more clear, but you introduced a problem in
the new text.

That is, problems introduced by the change are reasonable to discuss
*while reviewing the change*
*even if they are not directly related to the gola of the cchange*.

If the complaint was about a alleged capitalization error already in the
description, it might be reasonable to ask for another bug.
But if as part of clarifying the description, you introduce  a change
that someone believes is a capitalization error, I think that you are
being overly confrontational to push that off elsewhere.
Certainly my frustration is high enough that in the future I am much
less likely to try and suggest small problem or improvements than I was
before this conversation.

I also happen to believe that Python and Matrix should be capitalized in
that text under our standard style for descriptions.
I might be wrong about that, but it seems kind of unreasonable to push
that off to a different discussion
and to narrowly scope the questions as you have done.

Bug#911218: DFSG-incompatible sound (or even sounds?)

[Julien Puydt]

Hi,

I did package it, and didn't notice any problem, but ftpmasters did
find a clearly non-redistributable file, and upstream wouldn't confirm
the status of the other sound files nor fix the panda one :

https://notabug.org/TenPlus1/mobs_animal/issues/15

So I'm a bit at loss here : should I package it without the sounds, or
not package it at all?

JP

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Hi Matthew,

On Wed, Apr 29, 2020 at 07:14:30AM -0700, Matthew Fernandez wrote:
> 
> To add another data point to this discussion, one other (fruitless) thing I 
> tried previously was cross-compiling Clustal Omega. From an amd64 host, it’s 
> possible to target mipsel using the GCC cross-compilers in the standard 
> Debian repositories. You can then run the resulting binary using Qemu’s user 
> mode. Using this technique, the f002 test runs to completion with no bus 
> error. This is not really surprising as AFAIK unaligned accesses that would 
> trigger a bus error on mipsel hardware would be silently allowed in this 
> configuration (Qemu doesn’t faithfully emulate this hardware behaviour and 
> amd64 allows unaligned access).
> 
> Unfortunately the repositories’ cross-compilers have been built without ASan 
> enabled and you can’t attach to an emulated mipsel process with a native 
> Valgrind. So debugging memory safety issues is not straightforward. To go 
> further with this approach, you would have to build a mipsel-targeting 
> cross-compiler with ASan enabled or cross-compile Valgrind to mipsel. For a 
> true masochist, it may be possible to attach to the process with GDB or rr 
> and reverse-step from the location Andreas has quoted, but I wouldn’t trust 
> the debugger not to crash in this configuration. Even then the issue may not 
> be reproducible because it may be dependent on transformations/optimizations 
> only performed by the particular version of the native mipsel compiler called 
> during packaging.

Thanks a lot for your effort.
 
> For those on this thread who have access to mipsel hardware or can shell in 
> to one of the mipsel build machines, I would suggest running an 
> ASan-instrumented test there (`export CFLAGS="-g -fsanitize=address"; export 
> CXXFLAGS="-g -fsanitize=address"`) and see what we learn.

I tried on real hardware.  Unfortunately I'm running into



configure:3720: $? = 0
configure:3709: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/9/lto-wrapper
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-10' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=mipsel-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-libitm --disable-libsanitizer 
--disable-libquadmath --disable-libquadmath-support --enable-plugin 
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto 
--enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 
--with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all 
--with-arch-64=mips64r2 --enable-checking=release --build=mipsel-linux-gnu 
--host=mipsel-linux-gnu --target=mipsel-linux-gnu
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-10) 
configure:3720: $? = 0
configure:3709: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3720: $? = 1
configure:3709: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean 
'--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3720: $? = 1
configure:3740: checking whether the C compiler works
configure:3762: gcc -g -O2 -fdebug-prefix-map=/home/tille/clustalo=. 
-fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now conftest.c  >&5
/usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
/usr/bin/ld: cannot find -lasan
collect2: error: ld returned 1 exit status
configure:3766: $? = 1
configure:3804: result: no
configure: failed program was:



I have no idea why libasan_preinit.o and libasan.a are not installed.
The package libgcc-9-dev is installed for sure and on amd64 both files
are included here.  It seems the sudo command on eller does not permit
me executing `apt-file update` in a chroot so I have no idea where these
files are on mipsel (if they exist at all).

Any more help from debian-mipsel is really appreciated.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#933713: libgpg-error-dev: make package fit for cross development

[Simon McVittie]

(For context, I'm following up on this because I'm involved in the Steam
Runtime, a Debian derivative that ships libgcrypt and puts a high value
on being able to combine x86_64 with i386.)

On Fri, 02 Aug 2019 at 13:51:09 +0200, W. Martin Borgert wrote:
> IMHO, this package could be Multi-Arch: same, and therefore
> support cross development easily, if /usr/bin/gpg-error-config
> were renamed to /usr/bin/-gpg-error-config, e.g.
> /usr/bin/arm-linux-gnueabi-gpg-error-config.

Finding gpg-error-config in PATH is part of the API, so I don't think
dropping it is going to be an option. If gpgrt.m4 and gpg-error.m4 used
AC_PATH_TOOL (like pkg.m4 does to find i686-linux-gnu-pkg-config in
preference to plain pkg-config), then we could install gpg-error-config
as (for example) i686-linux-gnu-gpg-error-config; but it doesn't, so
we can't.

I think step 1 for all of this is to expand the 'build' autopkgtest
so that it covers all the "APIs" that we need to keep working; and
then we can immediately eliminate any proposed solution that fails the
autopkgtest. I don't know this library well, but please see attached
for a quick attempt at this.

> This probably needs a symlink for the native platform or similar
> to not break existing build processes.

Adding that symlink in the most obvious way would make it not Multi-Arch:
same and we'd be back where we started.

On Tue, 28 Jan 2020 at 13:01:04 +0100, Francois Gouget wrote:
> So I think it is reasonable to stop shipping gpg-error-config, just like
> FreeType stopped shipping freetype-config to become multiarch-compatible.

If it's part of upstream's API, then I don't think that's necessarily
feasible.

On Mon, 17 Feb 2020 at 10:33:04 +0900, NIIBE Yutaka wrote:
> In future release of libgpg-error, gpg-error-config will be a symbolic
> link to gpgrt-config at installation (when detected POSIX compatible
> Borne shell, or we will ignore system with no POSIX compatible Borne
> shell).

Isn't the calling convention different? gpgrt-config requires a --libdir
argument or a PKG_CONFIG_LIBDIR or PKG_CONFIG_PATH; gpg-error-config
doesn't. Debian systems normally don't set PKG_CONFIG_LIBDIR or
PKG_CONFIG_PATH, even for cross-compilation: they run an appropriate
architecture-specific *-linux-gnu*-pkg-config, which sets up the right
search paths internally.

On Sat, 07 Mar 2020 at 16:17:36 +0100, Francois Gouget wrote:
> Now an alternative to removing gpg-error-config is to make it 
> compatible with multiarch.

I think this is likely to be a more viable route.

> -libdir=${prefix}/lib/x86_64-linux-gnu
> +libdir=${prefix}/lib/i386-linux-gnu
> ...
> -   output="$output -L${prefix}/lib/x86_64-linux-gnu -lgpg-error"
> +   output="$output -L${prefix}/lib/i386-linux-gnu -lgpg-error"
> 
> The -L option is not needed on Debian so it might as well be omitted.

Yes, that's a straightforward (Debian-specific) patch.

> -   host) echo "x86_64-pc-linux-gnu" ;;
> +   host) echo "i686-pc-linux-gnu" ;;
> ...
> -echo "x86_64-pc-linux-gnu"
> +echo "i686-pc-linux-gnu"
> 
> This one is the real problem. Maybe it can be derived from some other 
> source. Or maybe removing support for host would have less impact than 
> removing gpg-error-config entirely.

gpg-error-config --host (or --variable=host) seems to be used in
gpg-error.m4 to check that we've found the right gpg-error. If it
prints "none", or if the script exits with a nonzero status, then the check
ignores it. So maybe we could patch gpg-error-config to print "none" for
the host, or to exit 1 when asked for it?

Is --host or --variable=host considered to be a "private" interface between
gpg-error-config and gpg-error.m4, or is it part of the "public API"?
If it's "private" then that trick seems fine, but if it's "public" then
I think it's more likely to break things.

The other possibility that I can think of is that we patch gpg-error-config
to determine the host dynamically, by assuming that some suitable
environment variable is set to a suitable value for the cross-compilation
host, and asking it where to look. For example, we could try
multiarch=$(${CC:-cc} -print-multiarch), and if that succeeds/gives
non-empty output, look in /usr/lib/${multiarch}, or try running
gpgrt-config --libdir=/usr/lib/${multiarch} --variable=host, or something
like that.

An alternative route that is essentially equivalent to that one would
be to install upstream's gpg-error-config into the libdir, and have a
Debian-specific wrapper in /usr/bin that uses an appropriate mechanism
(like $(${CC:-cc} -print-multiarch) maybe) to find and exec the right
architecture-specific gpg-error-config.

smcv
>From c39009617f81c63da3968f8f66927359fa2ed0c5 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 24 Apr 2020 19:25:17 +0100
Subject: [PATCH] d/tests/build: Extend to cover more ways to find gpg-error

---
 debian/tests/build | 46 ++
 1 file changed, 46 

Bug#959124: RFA: casparcg-server -- layered real-time video compositor to multiple outputs

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

Anyone interested in taking over the maintenance of this piece of TV
broadcasting machinery?  I am overloaded and less involved in anything
needing the system.

The CasparCG ystem is used by several TV stations to generate their
broadcasts, but I do not know of any of them using the Debian package.

Description: layered real-time video compositor to multiple outputs
 Play out professional graphics, audio and video to multiple outputs as a
 layerbased real-time compositor.

https://tracker.debian.org/pkg/casparcg-server >

-- 
Happy hacking
Petter Reinholdtsen

Bug#959119: shorewall: Please change AUTOHELPERS to 'No'.

[Nick]

Package: shorewall
Version: 5.2.3.2-1
Severity: normal

Dear Maintainer,

shorewall.conf(5) says "When configuring your firewall on systems
running kernel 3.5 or later, it is recommended that you: 1. Set
AUTOHELPERS=No..."

but the installed conf sets it to Yes.

(I'm none too keen on AUTOMAKE=Yes either but maybe that's another
issue.)

Thanks

Bug#959117: Unable to mount with fuse3 (fusermount: unknown option 'nonempty')

[Stéphane Glondu]

Control: tags -1 + patch

Le 29/04/2020 à 16:57, Stéphane Glondu a écrit :
> On my system, mounting a filesystem with mount.s3ql fails with:
>> fusermount: unknown option 'nonempty'
>> ERROR: fuse_mount failed
> 
> This seems related to fuse3, where this option has been removed. As
> gnome-gvfs requires fuse3, I guess this make s3ql unusable on many
> systems, hence the severity.

-- 
Stéphane
commit 7b8259b00287031b0019d8cfe1fa66580c1086f0
Author: Stephane Glondu 
Date:   Wed Apr 29 17:23:13 2020 +0200

Fix mount with fuse3 (Closes: #959117)

diff --git a/src/s3ql/mount.py b/src/s3ql/mount.py
index dec0c11..43a3737 100644
--- a/src/s3ql/mount.py
+++ b/src/s3ql/mount.py
@@ -439,7 +439,7 @@ def get_fuse_opts(options):
   'subtype=s3ql', 'big_writes', 'max_write=131072',
   'no_remote_lock' ]
 
-if platform.system() == 'Darwin':
+if platform.system() == 'Darwin' or True:
 # FUSE4X and OSXFUSE claim to support nonempty, but
 # neither of them actually do.
 fuse_opts.remove('nonempty')