date:20210216

Package: bridge-utils
Version: 1.5-10
Severity: important
Tags: patch

Hi!

When we tried to fix bug #779348 what we did was broke the code.

The since version 1.5-10 reads...

unset BREADY
unset TRANSITIONED
COUNT=0

# Use 0.1 delay if available
sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10))

while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ]
do
WAIT AND OTHER STUFF
done

As BREADY is unset (bridge is not ready) it is empty and thus it won't enter
the while, so it won't wait for the bridge to be ready.

Whis results in a failure to set up the interface if we use IPv6 on it. 
Maybe this is what is happening on #980507:

# time ifup br0

Waiting for br0 to get ready (MAXWAIT is 22 seconds).

Waiting for br0 to get ready (MAXWAIT is 22 seconds).
Waiting for DAD... Timed out
ifup: failed to bring up br0

real0m8,045s

The time expent waiting was all done at the DAD, the waiting for br0 didn't
take any time as it didn't get to the while loop.

The configuration used for testing this was:

auto br0
iface br0 inet static
bridge_ports eth0 wlan0
bridge_stp on
bridge_fd 10
bridge_hw wlan0
address 192.168.X.X
netmask 255.255.255.0

iface br0 inet6 static
bridge_ports eth0 wlan0
address 2001:::::1
netmask 64

While, if we invert the logic of the -n of the while loop to a !  like it
was before, like this:

--- /lib/bridge-utils/ifupdown.sh~  2021-01-22 11:06:45.0 +0100
+++ /lib/bridge-utils/ifupdown.sh   2021-02-17 03:41:50.114247593 +0100
@@ -203,7 +203,7 @@
 # Use 0.1 delay if available
 sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10))
 
-while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ]
+while [ ! "$BREADY" -a $COUNT -lt $MAXWAIT ]
 do
   sleep 0.1 2>/dev/null || sleep 1
   COUNT=$(($COUNT+1))


We get it to work and the while loop takes what it needs to get the bridge
forwarding:

# time ifup br0

Waiting for br0 to get ready (MAXWAIT is 22 seconds).

Waiting for br0 to get ready (MAXWAIT is 6 seconds).
Waiting for DAD... Done

real0m16,723s
user0m0,891s
sys 0m1,261s

If people finds that it takes always MAXWAIT seconds it is because there is
no other bridge speaking STP on the net or our bridge will be the Root of
the topology.  If that is not the case, like in this example, where the
neighbour has a FD of 2, the timing will be shorter and if one wants to make
it shorter he can always play with bridge_fd I don't recommend to lower it
under 2 anyway.

So, the code was ok like it was before and we should try to get this fix in
Bullseye.

I have a better fix for this which also addresses bug #319832, I've posted
it there, it addresses the two "Waiting for br0..." messages, now it is only
shown once, and solves the ifdown errors that you get with current
implementation, but maybe that's too late for Bullseye.

Regards.

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

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

Versions of packages bridge-utils depends on:
ii  libc6  2.31-9

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

-- Configuration Files:
/etc/default/bridge-utils changed [not included]

-- no debconf information

Bug#319832: A patch to solve this.

Hi!

It's been a long time since this bug entered the system, and now I have a
patch for it, I have to say it is a little dirty (I'm just adding the bridge
back on the stances that had it removed before them) so that way they won't
fail when trying to remove it.

This will work if you do:
ln -s /lib/bridge-utils/ifupdown.sh /etc/network/if-down.d/bridge
and apply the attached patch.

I'd love to see comments on this, even though more than 15 years later...
well who knows.

Whis patch is a little big, so I don't know if it will make it to Bullseye
at this time of the freeze :-( so all the testing will be welcome and will
of course help get it on Bullseye.

Regards
-- 
Manty/BestiaTester -> http://manty.net
--- ifupdown.sh.orig2021-02-17 03:53:52.414027536 +0100
+++ ifupdown.sh 2021-02-17 03:51:29.029521766 +0100
@@ -67,7 +67,11 @@
   fi
 # Previous work (stop the interface)
 elif [ "$MODE" = "stop" ];  then
+  if [ "$PHASE" = "pre-down" ]; then
+[ ! -d /sys/class/net/$IFACE ] && brctl addbr $IFACE && ip address add 
"$IF_ADDRESS"/"$IF_NETMASK" dev $IFACE
+  elif [ "$PHASE" = "post-down" ]; then
   ip link set dev $IFACE down || exit 1
+  fi
 fi
 
 all_interfaces= &&
@@ -100,7 +104,7 @@
   fi
   brctl addif $IFACE $port && ip link set dev $port up
 # We detach each port of the bridge
-elif [ "$MODE" = "stop" ] && [ -d /sys/class/net/$IFACE/brif/$port ];  then
+elif [ "$MODE" = "stop" -a "$PHASE" = "post-down" ] && [ -d 
/sys/class/net/$IFACE/brif/$port ];  then
   ip link set dev $port down && brctl delif $IFACE $port && 
destroy_vlan_port
   if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]
   then
@@ -194,16 +198,15 @@
   # Wait for the bridge to be ready
   if [ "$MAXWAIT" != 0 ]
   then
-/bin/echo -e "\nWaiting for $IFACE to get ready (MAXWAIT is $MAXWAIT 
seconds)."
-
 unset BREADY
 unset TRANSITIONED
 COUNT=0
+MMAXWAIT=$MAXWAIT
 
 # Use 0.1 delay if available
-sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10))
+sleep 0.1 2>/dev/null && MMAXWAIT=$((MAXWAIT * 10))
 
-while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ]
+while [ ! "$BREADY" -a $COUNT -lt $MMAXWAIT ]
 do
   sleep 0.1 2>/dev/null || sleep 1
   COUNT=$(($COUNT+1))
@@ -219,12 +222,15 @@
   unset BREADY
 fi
   done
+  if [ -z "$BREADY" -a $COUNT = 1 ]
+  then
+/bin/echo -e "\nWaiting for $IFACE to get ready (MAXWAIT is $MAXWAIT 
seconds)."
+  fi
 done
-
   fi
 
 # Finally we destroy the interface
-elif [ "$MODE" = "stop" ];  then
+elif [ "$MODE" = "stop" -a "$PHASE" = "post-down" ];  then
 
   brctl delbr $IFACE

Bug#982942: lomiri-app-launch: FTBFS on hppa - Please fix symbols

2021-02-16 Thread John David Anglin

Package: lomiri-app-launch
Version: 0.0.90-7
Severity: normal

Dear Maintainer,

Build fails Here:

   dh_makeshlibs -a -a
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/liblomiri-app-launch0/DEBIAN/symbols doesn't 
match completely debian/liblomiri-app-launch0.symbols
--- debian/liblomiri-app-launch0.symbols (liblomiri-app-launch0_0.0.90-7_hppa)
+++ dpkg-gensymbols0O943H   2021-02-17 01:40:07.169856319 +
@@ -16,10 +16,10 @@
  
_ZN6lomiri10app_launch5AppID8discoverERKSt10shared_ptrINS0_8RegistryEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESE_NS1_15VersionWildcardE@Base
 0.0.90
  
_ZN6lomiri10app_launch5AppID8discoverERKSt10shared_ptrINS0_8RegistryEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESE_SE_@Base
 0.0.90
  
_ZN6lomiri10app_launch5AppIDC1ENS0_10TypeTaggerINS1_10PackageTagENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS2_INS1_10AppNameTagES9_EENS2_INS1_10VersionTagES9_EE@Base
 0.0.90
- (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC1ERKS1_@Base 0.0.90
+#MISSING: 0.0.90-7# (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC1ERKS1_@Base 
0.0.90
  _ZN6lomiri10app_launch5AppIDC1Ev@Base 0.0.90
  
_ZN6lomiri10app_launch5AppIDC2ENS0_10TypeTaggerINS1_10PackageTagENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS2_INS1_10AppNameTagES9_EENS2_INS1_10VersionTagES9_EE@Base
 0.0.90
- (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC2ERKS1_@Base 0.0.90
+#MISSING: 0.0.90-7# (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC2ERKS1_@Base 
0.0.90
  _ZN6lomiri10app_launch5AppIDC2Ev@Base 0.0.90
  _ZN6lomiri10app_launch5AppIDD1Ev@Base 0.0.90
  _ZN6lomiri10app_launch5AppIDD2Ev@Base 0.0.90
dh_makeshlibs: error: failing due to earlier errors

For full log, see:
https://buildd.debian.org/status/fetch.php?pkg=lomiri-app-launch&arch=hppa&ver=0.0.90-7&stamp=1613526023&raw=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.16+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#982941: gnome-terminal: terminal windows take quite long to close, even though process in the backgrund and exit

2021-02-16 Thread Christoph Anton Mitterer

Package: gnome-terminal
Version: 3.38.2-1
Severity: normal

Hey.

This bug exists since quite a while and I even remember that it already used to 
be there
much earlier but vanished again after some longer time.

What happens is the following:

When I open a gnome-terminal window and do something like:
$ eog & exit

I still see:
[1] 98788
exit

and there it takes 1-3 seconds until the window really closes.

Maybe this is now intended (so that one can see the final output), but since it 
might be some
bug and is (at least for me personally) rather annoying, I wanted to tell :-)


Cheers,
Chris.



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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  gnome-terminal-data   3.38.2-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-9
ii  libdconf1 0.38.0-2
ii  libglib2.0-0  2.66.7-1
ii  libgtk-3-03.24.24-1
ii  libpango-1.0-01.46.2-3
ii  libuuid1  2.36.1-7
ii  libvte-2.91-0 0.62.2-1
ii  libx11-6  2:1.7.0-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.46.2-1
pn  nautilus-extension-gnome-terminal  
ii  yelp   3.38.3-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#964934:

2021-02-16 Thread Eike von Seggern

Hi,

bug #955180 seems to be fixed in unstable accorging to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955180

Best,
Eike

Bug#981513: courier: please replace fam with gamin

2021-02-16 Thread Chris Hofstaedtler

Hello Markus,

* Chris Hofstaedtler  [210217 01:13]:
> Because someone pointed out that Gamin is also not exactly
> maintained, it would be great if upstream could directly implement
> inotify support. That's going to stay around, hopefully.

Given gamin is currently marked as being autoremoved, could you look
into replacing libfam-dev/libgamin-dev with inotify in courier?

Note: I'm pinging this bug again because I'm not sure if courier
would stay in testing if gamin is gone. The libfam-dev/libgamin-dev,
libfam0/libgamin mess is a big one and includes virtual packages...
the automated tools might not be smart enough to figure this out.

Cheers,
Chris

Bug#980507: Problems with your fix for Debian bridge-utils bug 779348

Hi!

I'm crossposting this to another bug because maybe the previous bug fix is
the one that is making the new bug fail.

Alexander, I hope you are still around so we can talk about this bug you had
sent.

I just came over to this bug but with the reverse feeling, after your patch
now the code doesn't wait at all.

You can go to https://bugs.debian.org/779348 in order to see what you had
sent, with your change the code goes...

unset BREADY
unset TRANSITIONED
COUNT=0

# Use 0.1 delay if available
sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10))

while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ]
do
WAIT AND OTHER STUFF
done

So, as we've unset BREADY, then BREADY is empty, so -n "$BREADY" will be
false and thus we wont go in the wait loop and thus it will exit without the
bridge being ready.

So... for me the code was Ok, now... what I'm asking myself is how have we
gone this far with this bug we introduced without anybody complaining.

I just came to it after setting STP and IPv6, then DAD failed and I went
looking for the bug.

So... I'm about to reverse this patch you sent me but... I'd like to know
what was wrong in the first place, that is, when you sent me the patch.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

Bug#982494: acpica-unix FTBFS armhf, mips64el possible patch

2021-02-16 Thread Chris Hofstaedtler

I've uploaded a possible patch to experimental, to avoid introducing
new build failures on other archs.

Diff below.


diff -Nru 
acpica-unix-20200925/debian/patches/0001-Add-in-basic-infrastructure-for-big-endian-support.patch
 
acpica-unix-20200925/debian/patches/0001-Add-in-basic-infrastructure-for-big-endian-support.patch
--- 
acpica-unix-20200925/debian/patches/0001-Add-in-basic-infrastructure-for-big-endian-support.patch
   2020-10-30 01:15:48.0 +
+++ 
acpica-unix-20200925/debian/patches/0001-Add-in-basic-infrastructure-for-big-endian-support.patch
   2021-02-16 23:24:40.0 +
@@ -30,7 +30,7 @@
  9 files changed, 242 insertions(+)
  create mode 100644 source/components/utilities/utendian.c
 
-Index: acpica-unix2-20200925/generate/unix/acpibin/Makefile
+Index: acpica-unix-20200925/generate/unix/acpibin/Makefile
 ===
 --- acpica-unix2-20200925.orig/generate/unix/acpibin/Makefile
 +++ acpica-unix2-20200925/generate/unix/acpibin/Makefile
@@ -106,7 +106,7 @@
 ===
 --- /dev/null
 +++ acpica-unix2-20200925/source/components/utilities/utendian.c
-@@ -0,0 +1,205 @@
+@@ -0,0 +1,225 @@
 
+/**
 + *
 + * Module Name: utendian -- byte swapping support for other-endianness
@@ -263,7 +263,27 @@
 +return Result;
 +}
 +#else
-+UINT64 AcpiUtReadUint64 (void *SrcPtr) { return *(UINT64 *)SrcPtr; }
++UINT64 AcpiUtReadUint64 (void *SrcPtr) {
++#if defined(ACPI_MISALIGNMENT_NOT_SUPPORTED)
++UINT64 Result = 0;
++UINT8  *Dst = (UINT8 *)&Result;
++UINT8  *Src = (UINT8 *)SrcPtr;
++
++Dst[7] = Src[7];
++Dst[6] = Src[6];
++Dst[5] = Src[5];
++Dst[4] = Src[4];
++Dst[3] = Src[3];
++Dst[2] = Src[2];
++Dst[1] = Src[1];
++Dst[0] = Src[0];
++
++return Result;
++
++#else
++return *(UINT64 *)SrcPtr;
++#endif
++}
 +#endif
 +
 
+/***
diff -Nru acpica-unix-20200925/debian/patches/fix_ftbfs_mips64el.patch 
acpica-unix-20200925/debian/patches/fix_ftbfs_mips64el.patch
--- acpica-unix-20200925/debian/patches/fix_ftbfs_mips64el.patch
1970-01-01 00:00:00.0 +
+++ acpica-unix-20200925/debian/patches/fix_ftbfs_mips64el.patch
2021-02-16 23:24:38.0 +
@@ -0,0 +1,13 @@
+Index: acpica-unix-20200925/source/include/platform/aclinux.h
+===
+--- acpica-unix-20200925.orig/source/include/platform/aclinux.h
 acpica-unix-20200925/source/include/platform/aclinux.h
+@@ -217,7 +217,7 @@
+ 
+ #if defined(__ia64__)|| (defined(__x86_64__) && !defined(__ILP32__)) ||\
+ defined(__aarch64__) || defined(__PPC64__) ||\
+-defined(__s390x__) ||\
++defined(__s390x__) || defined(__mips64) ||\
+ (defined(__riscv) && (defined(__LP64__) || defined(_LP64)))
+ #define ACPI_MACHINE_WIDTH  64
+ #define COMPILER_DEPENDENT_INT64long
diff -Nru acpica-unix-20200925/debian/patches/series 
acpica-unix-20200925/debian/patches/series
--- acpica-unix-20200925/debian/patches/series  2020-10-30 01:15:48.0 
+
+++ acpica-unix-20200925/debian/patches/series  2021-02-16 23:24:29.0 
+
@@ -61,3 +61,4 @@
 armv7-str-fixes.patch
 dbtest.patch
 ull-32bit.patch
+fix_ftbfs_mips64el.patch

Bug#982940: Desktop sharing via VNC causes gnome-remote-desktop to crash

2021-02-16 Thread Marco Trevisan

Package: libvncserver1
Version: 0.9.13+dfsg-1
Severity: important
Tags: upstream patch
Upstream-Bug: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/45

Dear Maintainer,

When connecting via gnome-remote-desktop using the VNC protocol, there's
a crash:

#0 0x7f39d7c08497 in rfbMakeRichCursorFromXCursor
(rfbScreen=,
cursor=cursor@entry=0x7f39d7c32020 ) at 
./libvncserver/cursor.c:497
#1 0x7f39d7c089b7 in rfbSendCursorShape (cl=cl@entry=0x55e0530c5ae0)
at ./libvncserver/cursor.c:54
#2 0x7f39d7bfa33d in rfbSendFramebufferUpdate
(cl=cl@entry=0x55e0530c5ae0, givenUpdateRegion=)
at ./libvncserver/rfbserver.c:3190
#3 0x7f39d7bf48a5 in rfbUpdateClient (cl=cl@entry=0x55e0530c5ae0) at 
./libvncserver/main.c:1252
#4 0x7f39d7bf4920 in rfbProcessEvents (screen=,
usec=, usec@entry=0)
at ./libvncserver/main.c:1216
#5 0x55e052add793 in grd_session_vnc_take_buffer
(session_vnc=, data=)
at ../src/grd-session-vnc.c:169
#6 0x55e052ae2bde in do_render (loop=,
async=, seq=, data=,
size=, user_data=) at 
../src/grd-vnc-pipewire-stream.c:248
#7 0x7f39d193e806 in ?? () from 
/usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
#8 0x7f39d193e712 in ?? () from 
/usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
#9 0x7f39d193f063 in ?? () from 
/usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
#10 0x55e052ade72a in pipewire_loop_source_dispatch
(source=, callback=,
user_data=) at ../src/grd-vnc-pipewire-stream.c:97
#11 0x7f39d7f8e6eb in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7f39d7f8e998 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f39d7f8ea63 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f39d7e3a46d in g_application_run () from 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#15 0x55e052aca90b in main (argc=, argv=) at ../src/grd-daemon.c:351


The patch for fixing this issue is available in salsa:

https://salsa.debian.org/debian-remote-team/libvncserver/-/merge_requests/6

Bug#951704: ImportError: /lib/x86_64-linux-gnu/libjemalloc.so.2

2021-02-16 Thread Faidon Liambotis

Hi Andreas,

On Wed, Feb 10, 2021 at 01:09:30PM +0100, Andreas Tille wrote:
> I tried to fix the test issues of drmaa.  Besides a missing Depends
> which was fixed in Git[1] this bug of jmalloc2 affects the import:
> [...]
> So for drmaa it is release critical to fix the issue.

I'm sorry to hear that -- that doesn't sound great indeed!

The issue here seems to be that we have to choose between those two
options:

* Crashes such as the one you experience, effectively happening when
  one tries to dlopen() a library that is linked with jemalloc
  (libdrmaa), from a binary that is not linked with jemalloc (Python).
  This is what we have now.

* Building jemalloc with --disable-initial-exec-tls, which would allow
  dynamically loading jemalloc, but which will result into two malloc
  implementations (glibc's and jemalloc's) to coexist in the same
  process. In this case, if -for whatever reason- a pointer leaks from
  one implementation to the other (though e.g. a realloc call, free
  etc.), we would see some really weird and confusing crashes or
  deadlocks.

None of the two are great options! I don't feel super comfortable to
make this choice in isolation, so as promised before, I reached out to
upstream via Gitter¹. Upstream's recommendation is to avoid shipping with
--disable-initial-exec-tls and continue building the way we are right
now. Furthermore, they recommend that shared libraries should not define
their own malloc independent of the process malloc, if they want to use
the symbol name malloc, and thus should not link with jemalloc (at least
in the way they currently do). Effectively, they consider this a bug in
libdrmaa and others like it.

>From a Debian packaging PoV, a) I trust their judgement in evaluating
this tricky trade-off b) I think it's too late in the bullseye cycle to
be considering such a high-risk change that could result in weird to
debug crashes or deadlocks. Let me know if you disagree!

I realize this probably not the news you were hoping for.  I welcome
your thoughts and further discussion here, so not marking this as
wontfix/resolved yet. Hope this helps!

Best,
Faidon

1: https://gitter.im/jemalloc/jemalloc?at=602a62a49ba13e72e42f0ba5

Bug#981949: offlineimap3: broken when handling passwd input

2021-02-16 Thread Sudip Mukherjee

Hi Santiago,

On Mon, Feb 8, 2021 at 3:27 PM Sudip Mukherjee
 wrote:
>
> On Mon, Feb 8, 2021 at 3:12 PM Santiago Ruano Rincón
>  wrote:
> >
> > El 06/02/21 a las 16:46, Sudip Mukherjee escribió:
> > > On Sat, Feb 6, 2021 at 4:11 PM Sudip Mukherjee
> > >  wrote:
> > > >
> > > > Hi Santiago,
> > > >
> > > > On Fri, Feb 05, 2021 at 11:27:46AM +0100, Santiago Ruano Rincón wrote:
> > > > > Package: offlineimap3
> > > > > Version: 0.0~git20210105.00d395b+dfsg-2
> > > > > Severity: important
> > > > >
> > > > > Dear offlineimap3 maintainer,
> > > > >



> > > From your trace it seems you are using Curses and I do see problems if
> > > I mention 'blinkenlights' while running offlineimap.
> > > Your offlineimaprc will help, but also can you please comment the "ui
> > > = " in your offlineimaprc and check if you still get both these
> > > issues.
> >
> > Indeed, I can input my password if I comment out ui = Blinkenlights.
> > offlineimaprc attached. Thanks!

Can you please try the attached patch and confirm if it fixes both
your issues with blinkenlights..


-- 
Regards
Sudip
From 07598cc8b632fc13c38687c9dadba7757b062503 Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee 
Date: Tue, 16 Feb 2021 23:27:06 +
Subject: [PATCH] Use str password with Curses

Signed-off-by: Sudip Mukherjee 
---
 offlineimap/imapserver.py | 1 -
 offlineimap/ui/Curses.py  | 4 
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/offlineimap/imapserver.py b/offlineimap/imapserver.py
index 3970541..0086ab4 100644
--- a/offlineimap/imapserver.py
+++ b/offlineimap/imapserver.py
@@ -216,7 +216,6 @@ class IMAPServer:
 
 retval = NULL.join((authz, authc, passwd))
 logsafe_retval = NULL.join((authz, authc, '(passwd hidden for log)'))
-self.ui.debug('imap', '__plainhandler: returning %s' % logsafe_retval)
 return retval
 
 def __xoauth2handler(self, response):
diff --git a/offlineimap/ui/Curses.py b/offlineimap/ui/Curses.py
index 03f4d26..dfad308 100644
--- a/offlineimap/ui/Curses.py
+++ b/offlineimap/ui/Curses.py
@@ -583,6 +583,10 @@ class Blinkenlights(UIBase, CursesUtil):
 finally:
 self.unlock()
 self.inputhandler.input_release()
+
+# We need a str password
+if isinstance(password, bytes):
+return password.decode(encoding='utf-8')
 return password
 
 def setupwindows(self, resize=False):
-- 
2.30.0

Bug#982696: [PATCH] drm-info: FTBFS: tables.c:247:2: error: duplicate case value

2021-02-16 Thread Evangelos Ribeiro Tzaras


Hi,

On 2/16/21 6:20 PM, Dennis Filder wrote:

The attached patch drm-info-fourcc_py.patch fixes the issue by
ensuring case labels are not printed twice.


Thanks for providing a patch! Applied in [0]


I also noticed that d/watch hardcodes "drm_info" with an underscore in
the filenamemangle expression which was probably not intended.
drm-info-watchfile.patch consists of what I found in the uscan
manpage.


Again thanks for the patch! Applied in [1]


Regards,
Dennis.



@Birger: Could you upload the updated package?

[0] 
https://salsa.debian.org/swaywm-team/drm-info/-/commit/cdeeb4ee2d850dfcb5939b69ff9e5a89ad5a183d
[1] 
https://salsa.debian.org/swaywm-team/drm-info/-/commit/799b20d6ebf388bc9e2a607efa117f52bc4d2b63


Cheers

Bug#982696: drm-info: FTBFS: tables.c:247:2: error: duplicate case value

2021-02-16 Thread Evangelos Ribeiro Tzaras


Hi,

On 2/13/21 6:03 PM, Lucas Nussbaum wrote:

Source: drm-info
Version: 2.2.0-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20210213 ftbfs-bullseye

Hi,

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



thanks for your report!


Relevant part (hopefully):

cc -Idrm_info.p -I. -I.. -I/usr/include/libdrm -I/usr/include/json-c 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-std=c11 -D_POSIX_C_SOURCE=200809L -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-MD -MQ drm_info.p/meson-generated_.._tables.c.o -MF 
drm_info.p/meson-generated_.._tables.c.o.d -o drm_info.p/meson-generated_.._tables.c.o -c 
tables.c
tables.c: In function ‘modifier_str’:
tables.c:247:2: error: duplicate case value
   247 |  case DRM_FORMAT_MOD_LINEAR:
   |  ^~~~
tables.c:245:2: note: previously used here
   245 |  case DRM_FORMAT_MOD_LINEAR:
   |  ^~~~
tables.c:251:2: error: duplicate case value
   251 |  case DRM_FORMAT_MOD_SAMSUNG_16_16_TILE:
   |  ^~~~
tables.c:241:2: note: previously used here
   241 |  case DRM_FORMAT_MOD_SAMSUNG_16_16_TILE:
   |  ^~~~
[4/6] cc -Idrm_info.p -I. -I.. -I/usr/include/libdrm -I/usr/include/json-c 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-std=c11 -D_POSIX_C_SOURCE=200809L -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-MD -MQ drm_info.p/json.c.o -MF drm_info.p/json.c.o.d -o drm_info.p/json.c.o -c ../json.c
[5/6] cc -Idrm_info.p -I. -I.. -I/usr/include/libdrm -I/usr/include/json-c 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-std=c11 -D_POSIX_C_SOURCE=200809L -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-MD -MQ drm_info.p/pretty.c.o -MF drm_info.p/pretty.c.o.d -o drm_info.p/pretty.c.o -c 
../pretty.c
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v 
returned exit code 1
make: *** [debian/rules:6: binary] Error 25




Applying the patches generously provided by Dennis Filder I can build in 
a up to date schroot.



The full build log is available from:
http://qa-logs.debian.net/2021/02/13/drm-info_2.2.0-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Cheers

Bug#982939: RFS: libatomprobe/0+20210207-1 [ITP] -- Development files for libatomprobe

2021-02-16 Thread D Haley

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libatomprobe":

 * Package name: libatomprobe
   Version : 0+20210207-1
   Upstream Author : my...@gmx.com
 * URL : http://apttools.sourceforge.io/index.html
 * License : GPL-3+, CC-BY-SA-3.0
 * Vcs : https://salsa.debian.org/science-team/libatomprobe
   Section : science

It builds those binary packages:

  libatomprobe-dev - Development files for libatomprobe
  libatomprobe0 - Library for processing Atom Probe Tomography (APT) data

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/liba/libatomprobe/libatomprobe_0+20210207-1.dsc

Changes for the initial release:

 libatomprobe (0+20210207-1) unstable; urgency=low
 .
   * Initial release (Closes: #982265)
   * Upstream revision 548:69015288bab7

Regards,

D. Haley

Bug#963176: Additional information.

2021-02-16 Thread Michael Gilbert

control: tag -1 -moreinfo
control: severity -1 minor
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=39439

On Mon, Jun 22, 2020 at 12:54 AM Gong S. wrote:
> 10538.908:000a:000b:exception c005 in PE entry point
> (proc=0x7b02d8c0,module=0x7b00,reason=PROCESS_ATTACH,res=0x32fb00)

This error probably indicates that your wine installation path is
mounted noexec.

https://forum.winehq.org/viewtopic.php?t=2112
https://forum.winehq.org/viewtopic.php?t=7209
https://forum.winehq.org/viewtopic.php?f=2&t=20562
https://forum.endeavouros.com/t/setting-noexec-nodev-nosuid-mount-parameters-for-home-partition/7618
https://github.com/dnschneid/crouton/issues/528

Best wishes,
Mike

Bug#962259: Creating Webhooks fails and returns error 500

2021-02-16 Thread Antoine Le Gonidec


On Tue, 16 Feb 2021 18:38:42 +0100 Maximilian Stein  wrote:
This is weird, it still fails for me. I tested on two independent 
instances both using gitlab 13.6.7-1~fto10+1 and ruby-attr-encrypted 
3.1.0-3~bpo10+1. I tested with a user with activated and with 
deactivated 2FA. In all cases, accessing "-/profile/two_factor_auth" 
failed with error 500.


From what I remember of your interventions in other bug reports, you tend to 
favour the packages versions from buster-backports?
Here I try to minimise the use of buster-backports in favour of regular buster 
versions as much as possible, so the differences between our instances might be 
on this front.

Registrations are open on my instance, that can be found at 
forge.my-email-domain
Feel free to open an account there for testing purposes, as I am not a user of 
2FA I might have missed something in my quick test.

If the bug end up happening only on your instances and not on mine, we might 
find what triggers it by comparing `dpkg -l | grep ^ii` output and being 
careful about differences in packages versions.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977542: golang-github-revel-revel: Depends on network in tests

2021-02-16 Thread Reinhard Tartler

Got it.

On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher 
wrote:

> Control: severity -1 serious
>
> [...]
> Tests are executed as part of the binary target:
>
> dh binary --no-act  | grep auto_test
>dh_auto_test
>
> So the "no required targets may attmept network access" rule applies.
> Raising the severity accordingly. Please disable the tests that access
> the network.
>

Thanks for getting back to me. I've just made a sourceful upload that
disables the problematic test.

-- 
regards,
Reinhard

Bug#982920: w3m-el: does not work with Emacs 27

2021-02-16 Thread Tatsuya Kinoshita

Control: severity -1 important
Control: tags -1 + unreproducible

On 2021-02-16 at 16:14 +0100, Francesco Potortì wrote:
> ii  emacs-lucid [emacs]  1:27.1+1-3-dbg

BTW, is it your own build package?  If so, could you please try the
official binary package?

I've found a similar issue in Emacs bug #34094.

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

It seems related to Emacs portable dumper.

> load-history-filename-element: Wrong type argument: stringp, (require . info)

I've grep'd w3m-el and emacs, and found that load-history-filename-element
is only used by eval-after-load in emacs.  Probably, eval-after-load
is unusable because load-history is broken in your emacs.

A workaround may be `(require 'ffap)`, because `(eval-after-load "ffap"`
is in w3m.el, though your emacs is still problematic.

Thanks,
-- 
Tatsuya Kinoshita

pgpB5GwkL_Z9s.pgp
Description: PGP signature

Bug#962788:

2021-02-16 Thread David Roundy

I'm running into this bug also, and would love to know how to work around
it.

David Roundy

Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)

2021-02-16 Thread Andreas Henriksson

On Tue, Feb 16, 2021 at 10:35:53PM +0100, Andreas Henriksson wrote:
> Control: notfound -1 20201218-3
> Control: found -1 20210208-1
> 
> On Tue, Feb 16, 2021 at 08:20:47AM +0100, maximilian attems wrote:
> [...]
> > right it was replaced by newer cypress version and there should be
> > a symlink of that guy from the older name:
> > 
> >  Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin
> > 
> > Could you please test latest 2021 upstream package with this symlink?
> 
> It seems the bug report was filed against the (working) testing version
> when (as said in subject) the problem is really in the 2021 unstable
> version. Adjusted bug metadata accordingly. (I've confirmed by checking
> the content of both versions myself.)
> 
> It seems the reason that brcm/brcmfmac43340-sdio.bin symlink is missing
> is this:
> 
> The symlink first gets installed in debian/build/install ... then
... the rest on my analysis was completly wrong.

Actually I think the problem is this commit:
https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/9c597cb850e77c2bff39378503849a92ff522353

Regards,
Andreas Henriksson

Bug#980881: courier unicode cone lib bugfix

2021-02-16 Thread Markus Wanner


Control: fixed -1 2.1.2-1
Control: found -1 2.1-3

Hi,

thanks for filing this bug report.  I'm hereby only marking it as not 
affecting bullseye, which already provides an upstream version with the 
fix included.


Regards

Markus

Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)

2021-02-16 Thread Andreas Henriksson

Control: notfound -1 20201218-3
Control: found -1 20210208-1

On Tue, Feb 16, 2021 at 08:20:47AM +0100, maximilian attems wrote:
[...]
> right it was replaced by newer cypress version and there should be
> a symlink of that guy from the older name:
> 
>  Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin
> 
> Could you please test latest 2021 upstream package with this symlink?

It seems the bug report was filed against the (working) testing version
when (as said in subject) the problem is really in the 2021 unstable
version. Adjusted bug metadata accordingly. (I've confirmed by checking
the content of both versions myself.)

It seems the reason that brcm/brcmfmac43340-sdio.bin symlink is missing
is this:

The symlink first gets installed in debian/build/install ... then
debian/rules.gen (generated by debian/bin/gencontrol.py)
does *not* install it into debian/firmware-brcm80211 .
The reason seems to be that the filename is not listed in
debian/firmware-brcm80211.metainfo.xml
(The cypress filename the symlink points to is however listed
and that gets installed as expected.)

HTH

Regards,
Andreas Henriksson

Bug#956015: anarchism, new upstream version 15.4

2021-02-16 Thread Holger Levsen

hi!

there's a "new" upstream version available, 15.4 (17-Mar-2020), does someone
of you maybe have the capacity to package it? I'd be more than happy to assist
and help out, but I cannot drive this... and the freeze is near :)

last and most importantly, I hope you are doing well in these... times!

🖤🏴⬛ to you and to be stored in this bug log forever! 💖 :) 


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Nach wieviel Einzelfällen wird ein Einzelfall zum Normalfall?
(Jan Böhmermann)


signature.asc
Description: PGP signature

Bug#982907: dh_installsystemd: use new needs-reload/needs-restart unit interface

2021-02-16 Thread Niels Thykier

Luca Boccassi:
> Source: debhelper
> Priority: wishlist
> Tags: bookworm
> X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org
> 
> Dear Maintainer(s),
> 
> systemd v248 will ship with a new dbus/systemctl interface to mark a
> unit as needing reload/restart, and a new dbus/systemctl to queue all
> reload/restart jobs in a single command.
> The RPM packaging/scripts are changing to use this instead of custom
> batching.
> 
> I'm opening this ticket to explore whether it would be
> possible/good/desirable to switch the debhelper tools to use this as
> well in the future.
> 
> It looks like this:
> 
> systemctl set-property foo.service Markers=needs-restart
> systemctl set-property bar.service Markers=needs-reload
> ...
> systemctl reload-or-restart --marked
> 
> (or equivalent DBUS calls)
> 
> References:
> 
> https://github.com/systemd/systemd/commit/ff68472a20c208121b69ea13586f3105a219bc14
> https://github.com/systemd/systemd/commit/c9615f73521986b3607b852c139036d58973043c
> https://github.com/systemd/systemd/pull/18481/commits
> 
> The advantage being, you can mark a unit inline, but then batch the
> actual jobs later/asynchronously.
> 
> Note that, given the interface has just been merged and is not yet
> released, there is scope for improvements if there are debhelper-
> specific concerns to address, given the feature first use is the RPM's
> side of things.
> 
> Thoughts?
> 

By the sound of it, this is something that might need to go into the
init system helpers that debhelper invokes in the maintscripts (possibly
with a trigger in the systemd side to do the batch reload/restart).

@Michael: What is your view?

~Niels

Bug#977542: golang-github-revel-revel: Depends on network in tests

2021-02-16 Thread Sebastian Ramacher

Control: severity -1 serious

On 2021-02-16 21:50:32 +0100, Paul Gevers wrote:
> Control: Hi,
> 
> On 15-02-2021 19:23, Paul Gevers wrote:
> > Hi Reinhard,
> > 
> > On 15-02-2021 15:08, Reinhard Tartler wrote:
> >> Control: severity -1 important
> > 
> > I agree with this. The Debian infra allows for use of the internet (if
> > not used to download programs, that's forbidden by ftp-master [1].)
> 
> I must come back on my statement. I was reading "autopkgtest" here,
> while that wasn't claimed at all, sorry.
> 
> During build policy applies:
> 4.9. Main building script: debian/rules
> 
> """
> For packages in the main archive, no required targets may attempt
> network access, except, via the loopback interface, to services on the
> build host that have been started by the build.
> """
> 
> However, tests are not listed in the required targets, so *at this
> moment* I don't know what to conclude exactly.

Tests are executed as part of the binary target:

dh binary --no-act  | grep auto_test
   dh_auto_test

So the "no required targets may attmept network access" rule applies.
Raising the severity accordingly. Please disable the tests that access
the network.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination

2021-02-16 Thread Utkarsh Gupta

Hi Axel,

On Tue, Feb 16, 2021 at 11:12 PM Axel Beckert  wrote:
> I'm running these patches (as in git) now for about 1.5 days on
> Stretch and Buster in production. I'd say if I don't find any
> regression until Wednesday evening (i.e. in 1 day), feel free to
> finalise the packages as needed (the're currently all sporting
> "UNRELEASED" in the debian/changelog) and release them.
>
> Please push your changes and tags into the git repo. It's in
> collab-maint^Wthe "debian" group, so you should have write access.

Sure thing, once you give a go-ahead, I'll edit the changelog entry
and shall push that to the salsa repository.

> If you want to prepare a Jessie ELTS update, feel free to use the
> existing jessie branch in git. (It has no commit besides those being
> part of the master branch. Not sure why I or someone else has created
> it already.)

There's no "jessie" branch on salsa, at least. So I created one with
the latest dsc (4.2.1-3+deb8u1) and added 2 commits on top of it. By
importing the dsc and creating a branch out of it, the commit history,
I am afraid, is lost. Do you want to restore all that? I'll be happy
to do that after checking out from master and then applying +deb8u1
changes and then pushing mine on top of it, but I don't see any value
to it, really. But with your maintainer hat on, if you want me to do
that, I'll do so! :)

The jessie branch atm looks like this:
https://salsa.debian.org/debian/screen/-/tree/jessie

Please let me know if you have any questions or suggestions or if you
hoped to see something else than this? :)

- u

Bug#982055: (no subject)

2021-02-16 Thread Philippe SWARTVAGHER

Hello,

I was waiting for an opportunity to start contributing to Debian with
packaging. This seems like a great opportunity ! So if you have no
objection, I would like to adopt this package.

If I understood correctly, I should wait the end of Bullseye freeze to
start uploading some changes to the package.

Regards,

Philippe SWARTVAGHER.

Bug#961862: marked as done (debrebuild: should assemble the source for binNMUs)

2021-02-16 Thread Willy nilly

close #961862

On Tue, Feb 16, 2021 at 5:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Tue, 16 Feb 2021 17:48:26 +
> with message-id 
> and subject line Bug#961862: fixed in devscripts 2.21.1
> has caused the Debian Bug report #961862,
> regarding debrebuild: should assemble the source for binNMUs
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 961862: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961862
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Holger Levsen 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sat, 30 May 2020 17:03:21 +0200
> Subject: debrebuild: should assemble the source for binNMUs
> package: devscripts
> Version: 2.20.3
> Severity: normal
> x-debbugs-cc: reproducible-bui...@alioth-lists.debian.net
>
> Dear Maintainer,
>
> TTBOMK currently there is no tool to assemble the source for a binNMU. The
> source for a binNMU has do be assembled like this:
>
> - take the normal source package and unpack it
> - extract the d/changelog stanza from the .buildinfo file in question and
>   concatenate that with d/changelog from the source package.
> - use dpkg-source to build the source package.
>
> It would be great if debrebuild would this if instructed to.
>
> "#961861 «debrebuild: should (optionally) download the source too»" is a
> blocker/requirement to fix this bug.
>
>
> --
> cheers,
> Holger
>
>
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>
> "... the premise [is] that privacy is about hiding a wrong. It's not.
>  Privacy is an inherent human right, and a requirement for maintaining
>  the human condition with dignity and respect." (Bruce Schneier)
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 961862-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 16 Feb 2021 17:48:26 +
> Subject: Bug#961862: fixed in devscripts 2.21.1
> Source: devscripts
> Source-Version: 2.21.1
> Done: Mattia Rizzolo 
>
> We believe that the bug you reported is fixed in the latest version of
> devscripts, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 961...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Mattia Rizzolo  (supplier of updated devscripts
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 16 Feb 2021 17:45:53 +0100
> Source: devscripts
> Architecture: source
> Version: 2.21.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Devscripts Maintainers 
> Changed-By: Mattia Rizzolo 
> Closes: 955049 955123 955307 958750 958912 961861 961862 977809
> Changes:
>  devscripts (2.21.1) unstable; urgency=medium
>  .
>[ Mattia Rizzolo ]
>* setup.py:
>  + Produce a __init__.py at build time, containing the Devscripts
> version.
>* uscan:
>  + Set the umask while running `svn export`, so as to produce a
>reproducible tarball with mode=svn.
>* tests:
>  + Undefine some variables that might affect the tests.
>  + Run again all tests on hurd, glibc 2.31-6 fixed sem_open().
>  + test_debrepro, test_uscan_ftp, test_uscan_svn: skip the tests on
>kfreebsd, as support for the required sem_open() is lacking.
>  + test_uscan_mangle: do not call helperWatch multiple times in a
> test, to
>prevent leftover background processes.
>  + test_debchange: skip Ubuntu tests when there is no known development
>release, like right after an Ubuntu release.  Closes: #958912
>* d/control:
>  + Remove Pierre-Elliott Bécue from Uploaders;
>thank you for all your past contributions!
>* d/lintian-overrides:
>  + Update to match the newer lintian output.
>* d/copyright:
>  + Fix some issues spotted by lintian.
>  .
>[ Xavier Guimard ]
>* salsa:
>  + Fix bash completion.
>* uscan:
>  + Dicrease checksum message from war

Bug#720096: marked as done (rsyslog ignores rotated log file)

2021-02-16 Thread Willy nilly

cloes #720096

On Tue, Feb 16, 2021 at 7:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Tue, 16 Feb 2021 19:50:06 +
> with message-id 
> and subject line Bug#720096: fixed in rsyslog 8.2102.0-1
> has caused the Debian Bug report #720096,
> regarding rsyslog ignores rotated log file
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 720096: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720096
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Harald Dunkel 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 18 Aug 2013 17:14:55 +0200
> Subject: rsyslog ignores rotated log file
> Package: rsyslog
> Version: 7.4.3-1
>
> Sometimes rsyslog ignores the rotated log files. Sample session:
>
> # ls -lrt /var/log
> :
> :
> drwxr-s--- 2 Debian-exim  adm 4096 Aug 18 06:25 exim4
> -rw-r- 1 mysqladm0 Aug 18 06:25 mysql.log
> drwxr-x--- 2 www-data www-data4096 Aug 18 06:25 lighttpd
> -rw-r- 1 root adm0 Aug 18 06:25 user.log
> -rw-r- 1 root adm0 Aug 18 06:25 messages
> drwxr-xr-x 2 zabbix   zabbix  4096 Aug 18 06:25 zabbix-agent
> -rw-r--r-- 1 root root   16814 Aug 18 06:36 trim.log
> -rw-rw-r-- 1 root utmp  292876 Aug 18 07:13 lastlog
> -rw-r- 1 root adm 3668 Aug 18 07:13 auth.log
> -rw-r- 1 root adm   87 Aug 18 07:13 debug
> -rw-r- 1 root adm   892977 Aug 18 07:13 messages.1
> -rw-r- 1 root adm  649 Aug 18 07:13 kern.log
> -rw-r- 1 root adm 2067 Aug 18 07:13 syslog
> -rw-r- 1 root adm  615 Aug 18 07:13 daemon.log
> -rw-r--r-- 1 root root   26275 Aug 18 07:13 Xorg.4.log
> -rw-rw-r-- 1 root utmp  615168 Aug 18 07:14 wtmp
>
> See how messages.1 is written, but messages is ignored? I haven't
> figured out how to reproduce this, yet.
>
>
> 6:25 was boot time. The PC was shut down clean before. logrotate is
> version 3.8.5-1. /var/log/messages is written using
>
> *.=info;*.=notice;*.=warn;\
> auth,authpriv.none;\
> cron,daemon.none;\
> mail,news.none  -/var/log/messages
>
>
> Regards
> Harri
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 720096-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 16 Feb 2021 19:50:06 +
> Subject: Bug#720096: fixed in rsyslog 8.2102.0-1
> Source: rsyslog
> Source-Version: 8.2102.0-1
> Done: Michael Biebl 
>
> We believe that the bug you reported is fixed in the latest version of
> rsyslog, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 720...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Michael Biebl  (supplier of updated rsyslog package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 16 Feb 2021 20:23:15 +0100
> Source: rsyslog
> Architecture: source
> Version: 8.2102.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Michael Biebl 
> Changed-By: Michael Biebl 
> Closes: 720096
> Changes:
>  rsyslog (8.2102.0-1) unstable; urgency=medium
>  .
>* New upstream version 8.2102.0
>* Bump Standards-Version to 4.5.1
>* Update Homepage URL to use https://
>* Set upstream metadata fields: Bug-Submit, Bug-Database, Repository,
>  Repository-Browse
>* Remove some left-over news bits
>* Merge logrotate rules.
>  We only want a single postrotate to avoid having a SIGHUP getting lost
>  due to race conditions, leading to files not being rotated properly.
>  (Closes: #720096)
> Checksums-Sha1:
>  afe3813741e86781646e9ccc5ca1760576a372aa 3077 rsyslog_8.2102.0-1.dsc
>  fdda78ed808e7a0dca03ead9227a0a5d913a050f 3123684
> rsyslog_8.2102.0.orig.tar.gz
>  867d5817144a9af03c82243bbb3301b8fda063f6 28708
> rsyslog_8.2102.0-1.debian.tar.xz
>  e84519c5309ceed67ff4e592e863eec86a838994 8129
> rsyslog_8.2102.0-1_source.buildinfo
> Checksums-Sha256:
>  9c05ee9c9f6807f1af37df68ef7b2e3dbff319eae

Bug#977542: golang-github-revel-revel: Depends on network in tests

Control: Hi,

On 15-02-2021 19:23, Paul Gevers wrote:
> Hi Reinhard,
> 
> On 15-02-2021 15:08, Reinhard Tartler wrote:
>> Control: severity -1 important
> 
> I agree with this. The Debian infra allows for use of the internet (if
> not used to download programs, that's forbidden by ftp-master [1].)

I must come back on my statement. I was reading "autopkgtest" here,
while that wasn't claimed at all, sorry.

During build policy applies:
4.9. Main building script: debian/rules

"""
For packages in the main archive, no required targets may attempt
network access, except, via the loopback interface, to services on the
build host that have been started by the build.
"""

However, tests are not listed in the required targets, so *at this
moment* I don't know what to conclude exactly.

Paul

OpenPGP_signature
Description: OpenPGP digital signature

Bug#982908: dh_strip: fails to identify static library

2021-02-16 Thread Niels Thykier

Control: forcemerge -1 875780

Mattia Rizzolo:
> Package: debhelper
> Version: 13.3.3
> 
> Hi,
> 
> If you see src:eclipse-titan/7.2.0-1, d/rules has an extra call to
> `strip` because dh_strip fails to identify those .a files as static
> libraries.
> Indeed, running `file` on them just reports, for example:
> mattia@warren ..der/result/sid/amd64/foo/usr/lib/titan % file 
> libttcn3-rt2-parallel.a 
> libttcn3-rt2-parallel.a: current ar archive
> 
> I wonder if debhelper could do more to identify them, or if this should
> be reassigned to src:file.
> 

Ack, known issue.  Merging.

Bug#980924: Acknowledgement (mutt: Please include updated German translation)

2021-02-16 Thread Antonio Radici

On Sat, Feb 13, 2021 at 09:47:34AM +0100, Helge Kreutzmann wrote:
> Hello Antonio,
> as announced the German mutt translation was heavily improved over the
> course of the last weeks[1]. Since the freeze is now approaching and due
> to "real life" for key people involved in the review, we did not
> manage to complete the review, however, the version is *much* improved
> already.
> 
> I provided this intermediate update to the upstream maintainers (cf. 
> mutt-po lists) and I would kindly ask to include it into your next
> upload targetting Bullseye.
> 
> On behalf of the German speaking mutt users I thank you for
> considering!
> 
> Please unzip the file and place it as "de.po" in the appropriate
> place. If you want, I can prepare the upload "ready to go" including
> requesting unblock to debian-release (I did an upload aeons ago
> already); however, as I'm only a DM, I cannot perform the upload
> itself.)
> 

Thanks fror the extra ping, I'll do it now

Bug#979963: Addressing the IPv6 thing

Hi!

While I'm still waiting for you "ip a" output to continue debugging this,
I'd like to to test the one line patch which I'm going to add on next
version, this should solve the hotplugged interfaces getting an IPv6 address
like you explained here and also on #980752 which I have now reassigned to
bridge-utils, I've sent the patch to that bug not to mix more stuff here,
but yo were saying...

> What I DO notice is that because the bridge is stupid enough to use the
> MAC address of a removable device to build the EUI64 address for fe80
> local link (despite bridge_hw specifying the MAC address of a fixed
> device), disconnecting that removable device collapses the bridge.

I'd like you to test with the patch to see if this is still like you
describe it and then send me the output of "ip a" explaining how it behaves
now.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#980752: Patch for testing

Hi!

I have now assigned this bug to bridge-utils and I've got this patch that
should solve it, can you test it on your machine and let me know if it fixes
the problem?

--- /lib/udev/bridge-network-interface~ 2021-02-16 20:59:36.397579972 +0100
+++ /lib/udev/bridge-network-interface  2021-02-16 20:59:45.777222821 +0100
@@ -30,6 +30,7 @@
create_vlan_port
if [ -d /sys/class/net/$port ]; then
ifup --allow auto $i
+   if [ -f 
/proc/sys/net/ipv6/conf/$port/disable_ipv6 ]; then echo 1 > 
/proc/sys/net/ipv6/conf/$port/disable_ipv6;fi
brctl addif $i $port && ip link set dev 
$port up &&
if [ "$(ifquery "$i"|sed -n 
-e's/^bridge[_-]hw: //p')" = "$port" ]; then
ip link set dev "$i" address 
"$(ip link show dev "$port" 2>/dev/null|sed -n "s|.*link/ether \([^ ]*\) 
brd.*|\1|p")"


Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#982938: upgrade Evince to 3.38.1

2021-02-16 Thread Frederic Parrenin


Package: Evince

Version: 3.38.0-3

Dear Maintainer,

Would it be possible to upgrade Evince to 3.38.1?
It contains several fixes, including one for presentation with a scaled 
display under X11.


https://mail.gnome.org/archives/ftp-release-list/2021-January/msg00090.html

Thanks!

Frédéric

Bug#980638: unattended-upgrades: FTBFS: AssertionError: False is not true : Can not find 'Removing unused kernel packages: linux-image-4.05.0-1021-kvm

control: tags -1 patch

Found upstream:

https://github.com/mvo5/unattended-upgrades/pull/282

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980680: tqdm: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

tags -1 patch

It's a hack, disabling the test:
https://salsa.debian.org/python-team/packages/tqdm/-/merge_requests/1

If nothing happens, I'll NMU in the near future.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982937: Please remove the gnome-shell dependency

2021-02-16 Thread David Mohammed

Package: gnome-remote-desktop
Version: 0.1.9-4

Please can you consider removing the runtime dependency on gnome-shell.

budgie-desktop uses mutter for its window manager.  It can therefore
make use of gnome-remote-desktop for screen-sharing.

I have rebuilt v0.1.9-4 locally without the gnome-shell dependency and
screen-sharing works fine (enabled via GNOME Settings).  Thus
gnome-shell is an unnecessary runtime dependency from a budgie
point-of-view.

thanks for considering

David

Bug#977542: golang-github-revel-revel: Depends on network in tests

Hi Reinhard,

On 16-02-2021 12:39, Reinhard Tartler wrote:
> Is this something appropriate to upload at this point or rather after
> bullseye release?

It's fine to do now, but I'm not attached to having it in bullseye.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#765098: Proposed example for NetworkManager

Hi!

I've installed a machine with NetworkManager, so I could do tests with this,
I have arrived to an example that does what I think you wanted.

The example would be this:

auto lo
iface lo inet loopback

iface enp2s0 inet manual

auto br0
iface br0 inet dhcp
bridge_ports all
bridge_fd 2
bridge_hw enp2s0

This way NetworkManager doesn't configure enp2s0 and ifupdown uses it on br0
without any interference.

What do you think?

Regards...
-- 
Manty/BestiaTester -> http://manty.net

Bug#982859: libcmis-dev: allowable-actions.hxx uses non-existing file boost/shared_ptr.hpp

2021-02-16 Thread Rene Engelhard

Hi,

Am 15.02.21 um 15:56 schrieb Vincent Lefevre:
> Now, I don't know whether this file is really needed, in which case
> I suppose that there is a missing dependency on libboost1.74-dev
> (currently).

Hmm, yes.

Looks like libcmis-dev needs a Depends: libboost-dev...


Regards,


Rene

Bug#982936: hsetroot: Wrong homepage + new version


Source: hsetroot
Version: 1.0.2-9
Severity: normal

I have see that the project homepage do not respond anymore:
https://thegraveyard.org/hsetroot.html

I think that the homepage is now:
https://github.com/himdel/hsetroot/

I think that here there is a new version: 1.0.5

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982935: [Pkg-mailman-hackers] Postorius & Hyperkitty -- broken Javascript (Bootstrap)?

2021-02-16 Thread Jonas Meurer

Package: postorius
Version: 1.3.4-1

Hey Matt,

thanks for reporting the issue. I'll transform this into a proper Debian
bugreport so that it doesn't get lost.

Am 10.02.21 um 18:57 schrieb Matthew Blissett:

I've installed mailman3-full from the current packages in bullseye.

The dropdown controls on the UI for Postorius (e.g. "Subscription
requests", "Mass operations" and the username button to log out etc) and
the similar controls on Hyperkitty (e.g. "Threads by month") do not
work. You can see the latter at
http://newlistszm.gbif.org/mailman3/hyperkitty/list/t...@newlistszm.gbif.org/

I found https://lists.gem5.org/archives/list/gem5-annou...@gem5.org/
which is running the same version, but presumably not using Debian
packages as the Javascript is slightly different.

Yeah, we replace some Javascript libraries from the Mailman3 Postorius
package that are already packaged in Debian to avoid code duplication.

Could this be a problem with the Debian packaging, or perhaps my
configuration -- which is very close to the defaults (i.e. Mailman and
Apache configuration generated by dpkg-reconfigure).

Mh, might well be a problem with the JS library replacement I mentioned
above. Would you mind doing the following on your Mailman3 system to see
whether it fixes the bug:

* Fetch `jquery-1.11.3.min.js` from [1] and replace the symlink
`/usr/share/python3-django-postorius/static/postorius/libs/jquery/jquery-1.11.3.min.js`
with it.
* Fetch `bootstrap.min.js` from [2] and replace the symlink
`/usr/share/python3-django-postorius/static/postorius/libs/bootstrap/js/bootstrap.min.js`
with it.
* Fetch `html5shiv.js` and `html5shiv.min.js` from [3] and [4] and
replace the symlinks at
`/usr/share/python3-django-postorius/static/postorius/libs/html5shiv/`
with them.

[1]
https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/jquery/jquery-1.11.3.min.js
[2]
https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/bootstrap/js/bootstrap.min.js
[3]
https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.js
[4]
https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.min.js

Afterwards, you might (or might not) have to recreate the django cache
(not sure), which can easily be done by reconfiguring `mailman3-web`:

$ sudo dpkg-reconfigure mailman3-web

That would be super helpful in order to find out whether our Debian
versions of the JS libraries are the reason for your issue.

Thanks a lot for helping to debug the problem :)

Kind regards
jonas

OpenPGP_signature
Description: OpenPGP digital signature

Bug#982931: consul FTBFS in some environments.

2021-02-16 Thread Peter Green


On 16/02/2021 18:29, Peter Green wrote:


Any ideas what the problem might be?



Update: in my test environment uninstalling git solved the failure
to generate, but looking at the logs on reproducible builds,
that doesn't seem to explain the failures over there

Bug#982934: hscolour: Wrong homepage


Source: hscolour
Version: 1.24.4-3
Severity: normal

I have see that the project homepage do not respond anymore:
https://archives.haskell.org/code.haskell.org/~malcolm/hscolour/

I think that the homepage is now:
https://hackage.haskell.org/package/hscolour
https://github.com/crackleware/hscolour

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982579: Solution for loading firmware

2021-02-16 Thread maximilian attems

> > 1. Copy file brcmfmac43430-sdio.AP6212.txt from upstream to 
> > lib/firmware/brcm
> 
> so indeed it is a bug that we don't ship this one from upstream,
> will fix this in next Debian upload.

this needs to go in the debian git, will do soonish. (:
 
> > 2. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m3.txt to the 
> > AP6212-file

I am confused by this, as you did *not* submit an error log that showed
a request for this file, is this to add support to another device,
please be specific.

> > 3. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m2-ultra.txt 
> > to the AP6212-file
> this should be reported upstream, so that everyone takes advantage of
> it, hence adding linux-firmware mailinglist on Cc, happy to cook up
> a patch next 24hs.

sent, to add that symlink upstream.


thank you!

-- 
maks


signature.asc
Description: PGP signature

Bug#982579: Solution for loading firmware

2021-02-16 Thread maximilian attems

please find patch to add banana ultra support below

>From b549a10838edc4f97d4a3b49b572fc613c7c703d Mon Sep 17 00:00:00 2001
From: maximilian attems 
Date: Tue, 16 Feb 2021 19:35:27 +0100
Subject: [PATCH] Add symlink for BananaPi M2 to brcmfmac43430-sdio config

Fixes ( Debian bug #982579 [1]):
 [   10.514530] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43430-sdio.bin
 [   10.514732] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt ( -2)

Refs:
[1] https://bugs.debian.org/982579

Reported-by: Bernhard 
Signed-off-by: maximilian attems 
---
 WHENCE | 1 +
 1 file changed, 1 insertion(+)

diff --git a/WHENCE b/WHENCE
index aa96404..11c0970 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2716,6 +2716,7 @@ File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt"
 File: "brcm/brcmfmac43430-sdio.AP6212.txt"
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> 
brcmfmac43430-sdio.AP6212.txt
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> 
brcmfmac43430-sdio.AP6212.txt
+Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> 
brcmfmac43430-sdio.AP6212.txt
 File: "brcm/brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt"
 File: "brcm/brcmfmac43430-sdio.MUR1DX.txt"
 File: "brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt"
-- 
2.30.0

Bug#982933: hawtdispatch: Wrong homepage


Source: hawtdispatch
Version: 1.22-2.1
Severity: normal

I have see that the project homepage do not respond anymore:
hawtdispatch.fusesource.org

I think that the homepage is now:
https://github.com/fusesource/hawtdispatch

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982932: hawtbuf: Wrong homepage