Bug#959931: qa.debian.org: udd.debian.org/dmd no more able to display HTML report

[Xavier Guimard]

Package: qa.debian.org
Severity: normal

Hi,

udd.debian.org is no more able to display HTML report: it reports an
empty HTML page (test with
https://udd.debian.org/dmd/?email1=pkg-javascript-devel%40lists.alioth.debian.org).
However, JSON report seems to work.

Cheers,
Xavier

Bug#959930: libejml-java: package v0.39

[merkys]

Source: libejml-java
Severity: wishlist
Control: block -1 by 926714

Packaging libejml-java v0.39 requires gradle v6.3 at least.

Best,
Andrius

Bug#959929: janus FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: janus
Version: 0.9.4-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

janus fails to cross build from source, because the upstream Makefile.am
hard codes the build architecture pkg-config in one place. Please
consider using the host pkg-config correctly detected by configure
instead. I'm attaching a patch for your convenience.

Helmut
--- janus-0.9.4.orig/Makefile.am
+++ janus-0.9.4/Makefile.am
@@ -208,7 +208,7 @@
 	echo "$(build_date)" | awk 'BEGIN {} {print "const char *janus_build_git_time = \""$$0"\";"} END {} ' >> version.c
 	echo "$(JANUS_VERSION)" | awk 'BEGIN {} {print "int janus_version = "$$0";"} END {} ' >> version.c
 	echo "$(JANUS_VERSION_STRING)" | awk 'BEGIN {} {print "const char *janus_version_string = \""$$0"\";"} END {} ' >> version.c
-	pkg-config --modversion nice | awk 'BEGIN {} {print "const char *libnice_version_string = \""$$0"\";"} END {} ' >> version.c
+	echo "$(LIBNICE_VERSION_STRING)" | awk 'BEGIN {} {print "const char *libnice_version_string = \""$$0"\";"} END {} ' >> version.c
 
 $(dir_present):
 	`which git` rev-parse HEAD | awk 'BEGIN {print "#include \"version.h\""} {print "const char *janus_build_git_sha = \"" $$0"\";"} END {}' > version.c
--- janus-0.9.4.orig/configure.ac
+++ janus-0.9.4/configure.ac
@@ -340,6 +340,8 @@
   ])
 JANUS_MANUAL_LIBS="${JANUS_MANUAL_LIBS} -lm"
 AC_SUBST(JANUS_MANUAL_LIBS)
+LIBNICE_VERSION_STRING=`$PKG_CONFIG --modversion nice`
+AC_SUBST(LIBNICE_VERSION_STRING)
 
 AS_IF([test "x${boringssl_dir}" != "x"],
 	  [echo "Trying to use BoringSSL instead of OpenSSL...";

Bug#959928: backuppc-rsync FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: backuppc-rsync
Version: 3.1.2.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

backuppc-rsync fails to cross build from source, because it does not
pass --host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes backuppc-rsync cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru backuppc-rsync-3.1.2.1/debian/changelog 
backuppc-rsync-3.1.2.1/debian/changelog
--- backuppc-rsync-3.1.2.1/debian/changelog 2020-04-19 23:28:58.0 
+0200
+++ backuppc-rsync-3.1.2.1/debian/changelog 2020-05-07 07:25:24.0 
+0200
@@ -1,3 +1,10 @@
+backuppc-rsync (3.1.2.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 07 May 2020 07:25:24 +0200
+
 backuppc-rsync (3.1.2.1-2) unstable; urgency=medium
 
   * Upload nearly unmodified as source-only upload after the initial
diff --minimal -Nru backuppc-rsync-3.1.2.1/debian/rules 
backuppc-rsync-3.1.2.1/debian/rules
--- backuppc-rsync-3.1.2.1/debian/rules 2019-11-21 00:10:27.0 +0100
+++ backuppc-rsync-3.1.2.1/debian/rules 2020-05-07 07:25:06.0 +0200
@@ -15,7 +15,7 @@
dh $@
 
 override_dh_auto_configure:
-   ./configure --with-included-zlib=no --with-included-popt=no
+   dh_auto_configure -- --with-included-zlib=no --with-included-popt=no
 
 # We are installing to /usr/libexec, see debian/install
 # Do not duplicate into /usr/bin

Bug#959927: birdtray: Uninstallable on Debian Buster

[wirelessduck]

Package: birdtray
Version: 1.5-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Attempting to install birdtray.

The current version of thunderbird in buster has
Breaks: birdtray (<< 1.7.0+ds-1~) which is preventing
birdtray from installing.

Can birdtray please be updated to allow it to be installed on Debian
buster.



-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages birdtray depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libgl11.1.0-1
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u3
ii  libqt5gui55.11.3+dfsg1-1+deb10u3
ii  libqt5widgets55.11.3+dfsg1-1+deb10u3
ii  libqt5x11extras5  5.11.3-2
ii  libsqlite3-0  3.27.2-3
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  thunderbird   1:68.7.0-1~deb10u1

birdtray recommends no packages.

birdtray suggests no packages.

Bug#958229: Please document whether trailing commas are allowed

[Josh Triplett]

On Tue, May 05, 2020 at 06:21:41AM +0200, Guillem Jover wrote:
> On Mon, 2020-04-20 at 11:55:42 -0700, Josh Triplett wrote:
> > On Sun, 19 Apr 2020 23:12:28 +0200 Guillem Jover  wrote:
> > > On Sun, 2020-04-19 at 13:45:17 -0700, Josh Triplett wrote:
> > > > Package: dpkg-dev
> > > > Version: 1.19.7
> > > > Severity: normal
> > > > File: /usr/share/man/man5/deb-control.5.gz
> 
> > > I'm wondering what gave this false lead?
> > 
> > I looked for documentation on the file named debian/control, and I
> > remembered that dpkg uses the deb- abbreviation for many things, so I
> > guessed `man deb-control` and found a manpage.
> > 
> > Would you consider adding a note at the top of deb-control stating
> > something like "Debian source packages support additional features in
> > control files, which get eliminated when translating into the more
> > restrictive format for binary packages described here. For the control
> > format in source packages, see deb-src-control."
> 
> I've committed the following:
> 
>   
> 
> 
> And also polished and merged an old commit I had around:
> 
>   
> 
> 
> Hope, with these two that should have helped? If not I'm open to
> further clarification. :)

That helps greatly, thank you!

- Josh Triplett

Bug#901182: node-agent-base: v6.0.0 packaged

[merkys]

Hello,

I have successfully packaged node-agent-base v6.0.0. Would you mind if I
push my packaging and upload it? The new version of node-agent-base does
no longer seem to depend on node-es6-promisify.

Best,
Andrius

Bug#959926: lxc-templates: Unprivileged Debian container can also be created by mmdebstrap --mode=unshare

[Ryutaroh Matsumoto]

Package: lxc-templates
Version: 3.0.4-3
Severity: minor
Tags: patch

Dear Maintainer,

Dear Maintainer,

Running "lxc-create" by a non-root user gives:

$ lxc-create -t debian -n test-container -- -r buster 
This template can't be used for unprivileged containers.
You may want to try the "download" template instead.

This error message is a bit misleading, as we can also create unprivileged 
Debian containers
by mmdebstrap --mode=unshare.

A proposed patch is attached.

Best regards, Ryutaroh Matsumoto


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

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

Versions of packages lxc-templates depends on:
ii  lxc  1:4.0.2-1~1

Versions of packages lxc-templates recommends:
ii  bridge-utils 1.6-3
pn  busybox-static   
pn  cloud-image-utils | cloud-utils  
ii  debootstrap  1.0.123
ii  openssl  1.1.1g-1
ii  rsync3.1.3-8
pn  uuid-runtime 
ii  xz-utils 5.2.4-1+b1

lxc-templates suggests no packages.

-- no debconf information
--- /usr/share/lxc/templates/lxc-debian 2020-04-19 18:59:35.0 +0900
+++ lxc-debian  2020-05-07 12:57:03.148065038 +0900
@@ -26,6 +26,8 @@
 if [ "$arg" = "--mapped-uid" -o "$arg" = "--mapped-gid" ]; then
 echo "This template can't be used for unprivileged containers." 1>&2
 echo "You may want to try the \"download\" template instead." 1>&2
+echo "You can also use mmdebstrap --mode=unshare, and an example is 
found at" 1>&2
+echo 
"https://wiki.debian.org/LXC#Unprivileged_Debian_container_by_mmdebstrap_--mode.3Dunshare;
 1>&2
 exit 1
 fi
 done

Bug#953397: evil-el: please update to 1.14.0, testing2sid is currently failing

[David Krauser]

Hi Nicholas,

On Sunday, March 8, 2020 11:07 PM, Nicholas D Steeves wrote:
> While reviewing my dashboard today I noticed that evil-el's
> testing2sid (piuparts) is failing in a new way. This is not the
> font-related lint that I previously recommended ignoring.
>
> https://piuparts.debian.org/testing2sid/fail/elpa-evil_1.12.17-1.log

As we get closer to having 1.14.0 packaged and uploaded, I wanted to make sure 
the failures you were seeing have been addressed. I'm unable to access the link 
to the failure logs, however.

Digging around more, it appears that the testing2sid piuparts are now passing 
for 1.12.17:

https://piuparts.debian.org/testing2sid/pass/elpa-evil_1.12.17-1.log

I looked at the piuparts documentation that I could find, and I saw this on the 
piuparts FAQ:

> [Packages with passing tests are not retested automatically; however] failed 
> packages are eventually re-queued for test.

This leads me to believe that the initial failure was intermittent, and the 
test passed with a retry. Do you remember what the failure was specifically? 
That will help me track it down and ensure it is fixed with 1.14.0. I should 
have saved the failure log when you opened this bug - I just didn't realize 
they are ephemeral.

I will also try running piuparts locally and see if I can reproduce a failure.

Thanks again,

David

Bug#958059: mumble: push-to-talk not working with some media keys

[Chris Knadle]

forwarded 958059 https://github.com/mumble-voip/mumble/issues/4140
thanks

nfb:
> Package: mumble
> Version: 1.3.0~git20190125.440b173+dfsg-2
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> some multimedia keys are not working when bound to the push-to-talk
> shortcut, but some of them do work fine.
> 
> For example the ThinkVantage button on a Thinkpad x230 keyboard
> generates XF86Launch1 keysym. Output from xev:
> 
> KeyPress event, serial 34, synthetic NO, window 0x161,
> root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
> XLookupString gives 0 bytes: 
> XmbLookupString gives 0 bytes: 
> XFilterEvent returns: False
> 
> KeyRelease event, serial 34, synthetic NO, window 0x161,
> root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
> XLookupString gives 0 bytes: 
> XFilterEvent returns: False
> 
> The key is correctly detected and saved (as XF86Launch1) by the
> shortcut setting dialog in mumble, but when pushing it, the voice is
> not activated.
> Also, there should be no interference by the rest of the system, since
> this button, but also all other media keys i chose for testing, are
> not used by the window manager, nor by any running application.
> 
> The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
> instead, work as expected, as all other "standard" keys do, afaict.
> 
> I already reported on the #mumble irc channel and was told to file a
> bug because it probably is, but i decided to open it here so we can
> track it in Debian and also because i dont't know if the package in
> the stable repo is a bit outdated and the issue has been recently
> fixed somehow...
> 
> Let me know if you need more details.
> 
> Thanks for the support.

Thank you for opening a bug upstream about this; if upstream is able to fix the
bug then I'll be able to upload a new package with the fix for unstable and 
testing.

It is doubtful that this can be fixed for Debian stable though; the only bugs
that are possible to fix for stable are bugs that are serious, and any fixes for
serious bugs would have to be targeted for only the serious issues specifically.
 I don't think this bug passes that threshold.

Out of curiosity, have you tested to see if Mumble 1.3.0+dfsg-1 in Debian
unstable and testing exhibits the same bug?

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#959925: webext-browserpass: ship upstream browserpass-extension README in the package

[Paul Wise]

Package: webext-browserpass
Version: 3.4.1-3
Severity: wishlist

Please ship the browserpass-extension README in the package, it
contains information useful to users of the binary package. It also
contains extensive build/install instructions, which should probably be
removed from the copy of the README installed into the Debian package.
The browserpass-native README isn't useful to Debian users though. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#959924: gnome-shell: gnome screen lock and screen blank no longer works after 3.36.2-1 update

[terroreek]

Package: gnome-shell
Version: 3.36.2-1
Severity: normal

Dear Maintainer,

After the upgrades from gnome-shell 3.36.2-1 screen locking pressing super + l 
or from the menu to and screen locking
no longer works.  I have noticed Screen blanking, is also no longer working.  



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

Kernel: Linux 5.6.11-towo.1-siduction-amd64 (SMP w/48 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), 
LANGUAGE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  evolution-data-server3.36.2-1
ii  gir1.2-accountsservice-1.0   0.6.55-2
ii  gir1.2-atspi-2.0 2.36.0-2
ii  gir1.2-freedesktop   1.64.1-1
ii  gir1.2-gcr-3 3.36.0-2
ii  gir1.2-gdesktopenums-3.0 3.36.1-1
ii  gir1.2-gdm-1.0   3.34.1-3
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gnomebluetooth-1.03.34.1-1
ii  gir1.2-gnomedesktop-3.0  3.36.2-1
ii  gir1.2-gtk-3.0   3.24.18-1
ii  gir1.2-gweather-3.0  3.36.0-1
ii  gir1.2-ibus-1.0  1.5.22-4
ii  gir1.2-mutter-6  3.36.2-1
ii  gir1.2-nm-1.01.23.90-1
ii  gir1.2-nma-1.0   1.8.28-2
ii  gir1.2-pango-1.0 1.44.7-4
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.48.4-1
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.64.2-1
ii  gnome-backgrounds3.36.0-1
ii  gnome-settings-daemon3.36.1-1
ii  gnome-shell-common   3.36.2-1
ii  gsettings-desktop-schemas3.36.1-1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-7
ii  libcairo21.16.0-4
ii  libecal-2.0-13.36.2-1
ii  libedataserver-1.2-243.36.2-1
ii  libgcr-base-3-1  3.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libgirepository-1.0-11.64.1-1
ii  libgjs0g 1.64.2-1
ii  libgles2 1.3.1-1
ii  libglib2.0-0 2.64.2-1
ii  libglib2.0-bin   2.64.2-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.36.2-1
ii  libgraphene-1.0-01.10.0-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.18-1
ii  libical3 3.0.8-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-6-03.36.2-1
ii  libnm0   1.23.90-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsecret-1-00.20.3-1
ii  libsystemd0  245.5-2
ii  libwayland-server0   1.18.0-1
ii  libx11-6 2:1.6.9-2+b1
ii  libxfixes3   1:5.0.3-2
ii  mutter   3.36.2-1
ii  python3  3.8.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.8-4
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.34.1-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.36.2-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   3.36.2-1
ii  ibus  1.5.22-4
ii  iio-sensor-proxy  3.0-1
ii  switcheroo-control2.1-1
ii  unzip 6.0-25

Versions of packages gnome-shell suggests:
pn  gir1.2-telepathyglib-0.12   
pn  gir1.2-telepathylogger-0.2  

Versions of 

Bug#959923: dh-linktree: "replace" fails on files in linked directories

[Norbert Preining]

Package: dh-linktree
Version: 0.7
Severity: important

When dh-linktree replace is called with a file in a "directory" which is
a symlink, dh-linktree dies because dpkg-query fails:

dpkg-query: no path found matching pattern 
/usr/share/javascript/jquery/jquery.js
dh_linktree: error: dpkg --search -- /usr/share/javascript/jquery/jquery.js 
/usr/share/javascript/underscore/underscore.js subprocess returned exit status 1

We are supposed to use the /usr/share/javascript/jquery/jquery.js file
but cannot use it to replace copies.

Thanks

Norbert


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

Kernel: Linux 5.6.10 (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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-linktree depends on:
ii  debhelper 13
ii  libdpkg-perl  1.19.7
ii  perl  5.30.0-10

dh-linktree recommends no packages.

dh-linktree suggests no packages.

-- no debconf information

Bug#959922: xdg-autostart does not comply with freedesktop.org spec

[Daniel Richard G.]

Package: obsession
Version: 20140608-2

I have an XDG config hierarchy with the following directories:

/etc/xdg/autostart/
/etc/xdg/xdg-openbox/autostart/

The Xsession startup scripts correctly set

XDG_CONFIG_DIRS=/etc/xdg/xdg-openbox:/etc/xdg

I have placed a number of *.desktop files under xdg-openbox/autostart/
which effectively disable those under xdg/autostart/, by adding the
Hidden=true directive to files of the same name. The intent is for
Openbox sessions to not run any of the normal XDG autostart programs, in
order to keep the session lightweight.

As an example...

# /etc/xdg/autostart/xiccd.desktop
[Desktop Entry]
Name=xiccd
GenericName=X color management daemon
Comment=Applies color management profiles to your session
Exec=xiccd
Terminal=false
Type=Application
NotShowIn=GNOME;KDE;

# /etc/xdg/xdg-openbox/autostart/xiccd.desktop
[Desktop Entry]
Hidden=true

Unfortunately, xdg-autostart executes files in xdg/autostart/. In
~/.xsession-errors, I see this:

** Message: 23:00:46.576: xdg-autostart.vala:39: Processing 
/etc/xdg/autostart/xiccd.desktop file.
** Message: 23:00:46.584: xdg-autostart.vala:94: Launching: xiccd 
(xiccd.desktop)

This behavior disregards the following section of the "Desktop
Application Autostart Specification":

Hidden Key

When the .desktop file has the Hidden key set to true, the .desktop
file MUST be ignored. When multiple .desktop files with the same
name exists in multiple directories then only the Hidden key in the
most important .desktop file must be considered: If it is set to
true all .desktop files with the same name in the other directories
MUST be ignored as well.


(https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html)

Upstream appears to have abandoned the xdg-autostart implementation
used in Debian. I would suggest removing it from the obsession package,
and have openbox rely on its own openbox-xdg-autostart program, which
uses PyXDG and handles the startup process in a more conformant manner.

(The openbox package would then probably need to gain a dependency on
python3-xdg, as currently it has none.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#959920: systemctl,elogind: No more co-installable

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I currently don't see a satisfying solution for that, [...]

actually I just came up with an idea which would also solve #959828.
But unfortunately it requires cooperation from the systemd package
maintainers — which from my experience makes chances rather low that
this will be implemented.

Anyway, here's the idea:

If the systemd package would provide Provides for at least those
interface also offered by alternatives (e.g. systemd-systemctl,
systemd-logind), then elogind would just need to have to Conflict with
"systemd-logind" and systemd-systemctl would just need to Provide
"systemd-systemctl" or similar. And they would be co-installable
again, because they both provide replacements for different interfaces
of systemd.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#959920: systemctl,elogind: No more co-installable

[Axel Beckert]

Package: systemctl,elogind
Severity: important
Version: systemctl/1.4.4181-1 elogind/241.3-1+debian3

Hi,

since the upload of systemctl/1.4.4181-1, systemctl "Provides: systemd"
which IMO is generally a good thing.

But since elogin "Conflicts" with systemd, these both tools, which
provide systemd replacements are no more co-installable — which is a bad
thing.

I currently don't see a satisfying solution for that, but it would be
nice if both package maintainers could come up with a solution which
still makes sure, elogind and systemd are not installed in parallel, but
systemctl and elogind can be continued to be installed together.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Bug#753821: closed by atzlinux (bugreport is too old)

[atzlinux 肖盛文]

Control:  tags moreinfo


Package: eject
Version: 2.1.5+deb1+cvs20081104-15

This new version is not for Buster,but for bullseye.If you has chance,I
hope test this new eject version on testing(bullseye).


The orig bugreport had reported for many years ago,almost all of things
is changed.

It's no meaning to check if the bug is actually exist on very old
hardware,kernel,OS.

So,I close it.


If you find this old bug still exist in the new version,I suggestion run
reportbug again to report it.

Why?

When you run reportbug,the information abut hardware,kernel,OK,etc,.
will auto attached.

These information is very useful to debug the bug.

Also the new bugreport has the  standard format,easy to read,forward to
upstream ,save the time of opensource contributor.

This bug also will get more chance to been fixed.





在 2020/5/7 上午2:03, Steve McIntyre 写道:
> Control: reopen -1
>
> Ummm, no. You don't understand how this works it seems. Please do
> *not* just close bugs without checking if the bug is actually closed.
>
> I've just tested on a current Buster amd64 system and the bug is still
> there, just as described.
>
> On Thu, May 07, 2020 at 12:45:17AM +0800, atzlinux 肖盛文 wrote:
>> please use bugreport to report it again.
>>
>> The code isn't change,this it true.But others all
>> changed,hardware,kernel,OS,etc,.
>>
>> this bug close at first.




signature.asc
Description: OpenPGP digital signature

Bug#959919: ITP: sparta -- Network Infrastructure Penetration Testing Tool

[Pedro Loami Barbosa dos Santos]

Package: wnpp
Severity: wishlist
Owner: Pedro Loami Barbosa dos Santos 

* Package name: sparta
  Version : 1.0.4
  Upstream Author : Antonio Quina
* URL : https://github.com/SECFORCE/sparta
* License : GPL 3+
  Programming Lang: Python
  Description : Network Infrastructure Penetration Testing Tool

SPARTA is a python GUI application which simplifies network infrastructure 
penetration testing by aiding the penetration tester in the scanning and 
enumeration phase. It allows the tester to save time by having point-and-click 
access to his toolkit and by displaying all tool output in a convenient way. If 
little time is spent setting up commands and tools, more time can be spent 
focusing on analysing results. Despite the automation capabilities, the 
commands and tools used are fully customisable as each tester has his own 
methods, habits and preferences.

This is a package has some python dependencies like python-elixir & 
python-pyside.qtwebkit, but it also requires some other networktools to be able 
to perform all of its functionalities (nmap, hydra, cutycapt,ldap-utils, rwho, 
rsh-client, x11-apps, finger)
I intend to maintain this package with guidance of a DD who already agreed to 
mentor me on the process.

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Aaron M. Ucko]

Yves-Alexis Perez  writes:

> Hi Aaron, thanks for the bug report. Note that

Thanks for the quick response, and for considering this request.  FTR,
it looks like upower makes a stronger justification after all, at least
according to popcon, which puts its installation rate at around 48%,
vs. 16% for uuid-runtime and a fraction of a percent for the handful of
other packages with PrivateUsers=yes hits on codesearch.debian.net.
(The 100% installed libuuid1's recommendation evidently doesn't carry as
much weight as I'd anticipated -- I suppose installation ignores
recommendations, and upgrades tend to preserve the status quo for
existing recommendations.)

> kernel.unprivileged_userns_clone is already set to 0 by default so it's not
> really needed here.

Hence "explicitly", for the sake of anyone running a custom kernel that
accidentally wound up with a lax default.

> I'm not a fan of lifting the max_user_namespace restriction here since it's
> there as runtime hardening. I can understand the pain with PrivateUsers but I
> still don't think exposing root-designed kernel code to unprivileged users is
> a good idea.

Sure, and I don't advocate for lifting unprivileged_userns_clone, but
AFAICT allowing root to create user namespaces doesn't raise nearly so
many concerns, and can even help security insofar as it allows for
better isolation.

> hardening-runtime is not installed by default so admins installing it are
> supposed to understand what they do. They can also locally override the
> restriction if needed (for example set it to 1 or 2).

Fair enough, and I may go this route.  It's perhaps unfortunate that
there's no clean way to keep the default setting of this limit alongside
10-hardening.conf's other settings, but the default looks like massive
overkill anyway, so I suppose that's no great loss.

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

Bug#959914: Xarchiver failed to extract multi-part passworded 7z

[Ski-lleR]

Package: xarchiver
Version: 1:0.5.4.14-1
Severity: important

When i create a multi-part 7z with password, the opening of the archive just 
failed, where using command line 7z tool work fine.

An example :
$ 7z a -ptest -v10b "test.7z" smallfile.example

So i get my multi-part 7z. Now if i open it with xarchiver, that's what i get 
in output window :
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=fr_FR.UTF-8,Utf16=on,HugeFiles=on,64 bits

Scanning the drive for archives:
1 file, 10 bytes (1 KiB)

Listing archive: /mnt/TEMPORAIRE/test.7z.001

Enter password (will not be echoed):--
Path = /mnt/TEMPORAIRE/test.7z.001Type = Split
Physical Size = 10
Volumes = 23
Total Physical Size = 230

   Date  Time    Attr Size   Compressed  Name
--- -    
    .  230  230  test.7z
--- -    
   230  230  1 files
--
Path = test.7z
Open ERROR: Can not open the file as [7z] archive

--- -    
   230  230  1 files

Archives: 1
Volumes: 23
Total archives size: 230

Errors: 1

---

Now testing the archive with the commande line tool :
$ 7z t -ptest test.7z.001

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=fr_FR.UTF-8,Utf16=on,HugeFiles=on,64 bits

Scanning the drive for archives:
1 file, 10 bytes (1 KiB)

Testing archive: test.7z.001
--
Path = test.7z.001
Type = Split
Physical Size = 10
Volumes = 23
Total Physical Size = 230

Path = test.7z
Size = 230
--
Path = test.7z
Type = 7z
Physical Size = 230
Headers Size = 182
Method = LZMA2:12 7zAES
Solid = -
Blocks = 1

Everything is Ok

Size:   85
Compressed: 230

---

7z x work fine too.

I am using Debian GNU/Linux sid, kernel 5.6.0.1

publickey - ski_ller@protonmail.ch - 0xC8010ECA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#959918: gnome-session: Ask for password TRIPLE times after screen-lock

[Shahab Ouraie]

Package: gnome-session
Version: 3.30.1-2
Severity: important

Greeting first!
When I press SUPER+L and screen locks, then click on "log in as other user" ,
and click on "not listed?" it asks for username, I press cancel to log in back
with current user, when i enter the password, screen become black and flashes,
ask for password again and after you enter password for second time, desktop
will come up, but just for 1 sec. then locks again and you need to enter
password for 3rd, time so you can use system again!

and to mention that, no matter if you 1-lock the screen 2-click on "log in as
another user" 3-click on "not listed?" 4- cancel it and log in with current
user or ignore steps 3 and 4 ! meaning that just lock the screen and use "log
in as another user" then use current user (the user you was using when press
SUPER+L) to log in back again, it will happens!

much tnx for all of nice works!



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

Kernel: Linux 4.19.0-8-amd64 (SMP w/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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-session depends on:
pn  gnome-session-bin  
pn  gnome-session-common   
ii  gnome-settings-daemon  3.30.2-3
pn  gnome-shell

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base   10.0.2
ii  gnome-keyring  3.28.2-5

Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package

[Sandro Tosi]

> Any update on moving amule to use libwxgtk3.0-gtk3-dev?  amule is one of
> the last couple of packages keeping the gtk2 wx package in unstable (as
> cruft).  We keep getting bug reports about those cruft packages
> periodically.

Sadly no: upstream hasnt ported amule to WX GTK3 and it doesnt look
like it's gonna happen anytime soon (help with the port is of course
welcome, probably better to sync upstream if someone wants to lend a
hand) so feel free to ask FTP Masters to force the decruft

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#959917: systemd: unit file Alias= leads to dangling symlink

[Christoph Anton Mitterer]

Package: systemd
Version: 245.5-2
Severity: normal


Hey.

I've just noted the following behaviour.

/lib/systemd/system/smartmontools.service has:
[Install]
WantedBy=multi-user.target
Alias=smartd.service


Which leads to:
# tree /etc/systemd/system
/etc/systemd/system
├── multi-user.target.wants
│   ├── smartd.service -> /lib/systemd/system/smartd.service
│   ├── smartmontools.service -> /lib/systemd/system/smartmontools.service
│   └── ...
├── smartd.service -> /lib/systemd/system/smartmontools.service
...

With /etc/systemd/system/multi-user.target.wants/smartmontools.service being
a dangling symlink to the non-existant /lib/systemd/system/smartd.service .

/etc/systemd/system/smartd.service is however created with the correct
destination.


This stays if one disables/enables the unit, i.e. it's re-created with
the dangling symlink.



Cheers,
Chris.

Bug#959916: gnome: Lockscreen background turns to default after screen dim

[Shahab Ouraie]

Package: gnome-backgrounds
Version: 3.30.0-1
Severity: normal
File: gnome

Hello.
After turn computer on from a full shutdown, when lock-screen appears, if you
don't log in and wait until screen dims (in my case, after 4 mins.) and then
press any button to turn screen on and enter the login info, you'll see lock-
screen cover turns back to default blue pic with bubbles!

tnx in advance!



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

Kernel: Linux 4.19.0-8-amd64 (SMP w/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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#933160: O: cpufreqd -- fully configurable daemon for dynamic frequency and voltage scaling

[Seunghun Han]

On Fri, 26 Jul 2019 23:36:03 -0300 Tobias Frost  wrote:
> Package: wnpp
>
> The current maintainer of cpufreqd, Mattia Dongili ,
> is apparently not active anymore.  Therefore, I orphan this package now.
>

Dear Maintainer,

I would like to adopt this package.

Best regards,

Seunghun

Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package

[Scott Talbert]

On Tue, 1 Oct 2019, Olly Betts wrote:


Switching to the GTK 3 version may be as simple as:
1) Update your Build-Depends
   libwxgtk3.0-dev -> libwxgtk3.0-gtk3-dev
   libwxgtk-media3.0-dev -> libwxgtk-media3.0-gtk3-dev
2) Rebuild
3) Test


i tried this but it failed with this segfault:


[...]


Thread 1 "amule" received signal SIGSEGV, Segmentation fault.
0x771d8c1a in wxWindow::DoClientToScreen(int*, int*) const () from 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0


That sounds suspiciously similar to this bug, reported as happening when
using the GTK2 flavour of wxWidgets:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935698


Any update on moving amule to use libwxgtk3.0-gtk3-dev?  amule is one of 
the last couple of packages keeping the gtk2 wx package in unstable (as 
cruft).  We keep getting bug reports about those cruft packages 
periodically.


Thanks,
Scott

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Paul Wise]

On Tue, Apr 28, 2020 at 8:57 PM Kyle Edwards  wrote:

> It builds those binary packages:
>
>   dh-cmake - Debhelper programs for CMake projects

How is this different to the existing cmake support in debhelper?

$ dpkg -L debhelper libdebhelper-perl  | grep -i cmake
/usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Guilhem Moulin]

Control: notfixed -1 2016.11.2+ds-1+deb9u3

On Wed, 6 May 2020 at 10:36:42 +0200, Elimar Riesebieter wrote:
> please notice the attached note from saltstack! I assume this is not
> integrated into DSA 4676-1, isn't it?

Ooops yes, 2016.11.2+ds-1+deb9u3 appears to still be vulnerable to
CVE-2020-11652:

| If you have already applied the patch for Salt 2017.x or earlier, there
| is a follow-up patch to apply. You can download the patch and
| instructions below. **This applies to 2017.x, 2016.x, and 2015.x. This
| does NOT apply to 2018.x, 2019.x, or 3000.x.** 
| […]
|   - 2016.x 
| […] 
| The original patch for versions 2017.x and earlier secured against
| arbitrary commands running on Salt minions and eliminated the exposure
| (CVE-2020-11651). This additional patch is required to completely
| resolve arbitrary directory access to authenticated users
| (CVE-2020-11652).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959915: redundant freshclam profile since it's shipped in-package

[John Scott]

Package: apparmor-profiles-extra
Version: 1.27
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

An experimental freshclam profile is provided at 
 /usr/share/apparmor/extra-profiles/usr.bin.freshclam, but clamav-freshclam
provides its own more recent one in enforce mode at /etc/aa.d/ and has been
for a while.

Please remove this one.

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

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

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.13.4-1+b1

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXrNEiAAKCRByvHFIwKst
pz8jAP9hDm6l+bk4I4OKB2IyWlh0aL2ZPtH6E9fm+Pw269OCwAEAzzsqu3YuGsgw
wETgjZAg6N6AMdBsOcjxN4s5gmWHOws=
=SQtB
-END PGP SIGNATURE-

Bug#958436: cfengine3: New cfengine3 upstream LTS versions are available

[Michael Berg]

A strong argument for updating the Debian packages to cfengine 3.15 LTS
is that upstream will stop supporting and patching the 3.12 LTS branch
sometime in early 2021.
Upstream will support the latest 3.15 LTS branch until the end of 2022
or early 2023.
https://cfengine.com/product/supported-versions/

So cfengine in Debian unstable and testing should update to cfengine
3.15 so that bullseye, when it eventually becomes the new stable, isn't
stuck on an unsupported cfengine 3.12.

Bug#958901: qreator does not start properly

[Rainer Dorsch]

reopen 958901 =

Am Montag, 4. Mai 2020, 09:39:07 CEST schrieb Chow Loong Jin:
> On Sun, Apr 26, 2020 at 02:53:21PM +0200, Rainer Dorsch wrote:
> > Dear Maintainer,
> > 
> > I installed qreator on my system (with a KDE desktop).
> > 
> > I started qreator but did not see any response or window popping up:
> > [...]
> 
> Hi Rainer,
> 
> I suspect that qreator might be hanging at startup while trying resolve
> your current location to initialize the location QR Code generator
> widget.
> 
> Could you disable the location QR code type by removing
> /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py and then try
> launching it again?

Hi Chow,

I apologize for the late reply and thank you for your quick reply.

Not sure if I am allowed to use the control server, so can you please check if 
the issue got reopened?

I tried your suggestion, but no luck, I think there is no difference:

root@h370:~# mv /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py /usr/
share/qreator/qreator/qrcodes/QRCodeLocation.py.orig
root@h370:~# Abgemeldet
rd@h370:~$ qreator 
/usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported 
without specifying a version first. Use gi.require_version('Gtk', '3.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import GObject, Gtk # pylint: disable=E0611
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:18: PyGIWarning: 
GtkChamplain was imported without specifying a version first. Use 
gi.require_version('GtkChamplain', '0.12') before import to ensure that the 
right version gets loaded.
  from gi.repository import Gtk, GtkChamplain, Clutter, Champlain
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning: 
GtkClutter was imported without specifying a version first. Use 
gi.require_version('GtkClutter', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import GtkClutter
/usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM was 
imported without specifying a version first. Use gi.require_version('NM', 
'1.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GLib, GdkPixbuf, NM
No handlers could be found for logger "qreator_lib"
^C^C^C^C^C^C^Z
[1]+  Angehalten  qreator
rd@h370:~$ kill %1

[1]+  Angehalten  qreator
rd@h370:~$ 
[1]+  Beendet qreator
rd@h370:~$ su -
Passwort: 
root@h370:~# mv /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py.orig /
usr/share/qreator/qreator/qrcodes/QRCodeLocation.py
root@h370:~# Abgemeldet
rd@h370:~$ qreator 
/usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported 
without specifying a version first. Use gi.require_version('Gtk', '3.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import GObject, Gtk # pylint: disable=E0611
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:18: PyGIWarning: 
GtkChamplain was imported without specifying a version first. Use 
gi.require_version('GtkChamplain', '0.12') before import to ensure that the 
right version gets loaded.
  from gi.repository import Gtk, GtkChamplain, Clutter, Champlain
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning: 
GtkClutter was imported without specifying a version first. Use 
gi.require_version('GtkClutter', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import GtkClutter
/usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM was 
imported without specifying a version first. Use gi.require_version('NM', 
'1.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GLib, GdkPixbuf, NM
No handlers could be found for logger "qreator_lib"
^C^C^C^C^C^Z
[1]+  Angehalten  qreator
rd@h370:~$ kill %1

[1]+  Angehalten  qreator
rd@h370:~$ 


Also ^C does not kill the process, I have to do a ^Z and kill %1 to get rid of 
it.

I should probably reopen the issue.

Sorry again for the late response
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Yun,

On Wed, May 6, 2020 at 5:34 PM Andrej Shadura <
andrew.shad...@collabora.co.uk> wrote:

>
> This makes the code not acceptable in Debian.
>
> I’m also very much against of packaging an obsolete and buggy old
> version of the code when we already have the new one in Debian.
>

I am assuming that Andrej is speaking for the Debian Java team here in
which case I must respect his wishes on this. Would it be possible for us
to get a Hangout together with Andrej (and any other required Debian Java
team members) and whoever at Google is in a decision-making position about
which version of diffutils are being used? Maybe if we get everyone
together we can figure out a reasonable way forward that will work for
everyone.

At worst, we can implement a possible Bazel patch from Andrej just in
Debian. That would resolve this issue by allowing us to use the newer
library that is already in Debian but I prefer not deviating from upstream
if we don't have to... It seems like we should be able to come to a
consensus solution here if we can get the right people to have a
conversation.

-Olek

Bug#958059: mumble: push-to-talk not working with some media keys

[nfb]

Meanwhile, forwarded upstream [0].

[0] https://github.com/mumble-voip/mumble/issues/4140



-- 
free as in freedom, not free beer

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Yun,

On Wed, May 6, 2020 at 5:34 PM Andrej Shadura <
andrew.shad...@collabora.co.uk> wrote:

>
> This makes the code not acceptable in Debian.
>
> I’m also very much against of packaging an obsolete and buggy old
> version of the code when we already have the new one in Debian.
>

I am assuming that Andrej is speaking for the Debian Java team here in
which case I must respect his wishes on this. Would it be possible for us
to get a Hangout together with Andrej (and any other required Debian Java
team members) and whoever at Google is in a decision-making position about
which version of diffutils are being used? Maybe if we get everyone
together we can figure out a reasonable way forward that will work for
everyone.

At worst, we can implement a possible Bazel patch from Andrej just in
Debian. That would resolve this issue


> --
> Cheers,
>   Andrej
>

Bug#948706: greylistd: python3 version fails to start - conversion from python 2 very broken

[Benedikt Spranger]

Am Tue, 5 May 2020 16:36:15 +0200
Benedikt Spranger  wrote:

Hi,

during further investigation and testing a additional hiccup occur:

RuntimeError: dictionary changed size during iteration

The attached patch address that.

Regards
Bene Spranger


0001-Fix-key-expire-function.patch
Description: Binary data

Bug#933611: "solved"

[r]

i had the wrong font configured ...
now it runs just fine.

this bug is the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934497

still a segmentation fault it too bad...

Bug#959867: ifup kills dhclient on if-up.d script failure

[Guus Sliepen]

On Wed, May 06, 2020 at 12:25:57PM +0200, Sergio Gelato wrote:

> I've now run into this problem on several systems running buster. Whenever
> a script in /etc/network/if-up.d/ fails (see, e.g., #959864) the dhclient
> instance dies. This behaviour may actually predate buster, but is much more
> noticeable now that dhclient-script sets the interface's valid_lft to
> the actual, finite lifetime of the lease (cf. #834532). The result is that
> the system drops off the network when the initial DHCP lease expires.
> 
> I'm not sure how well specified the behaviour of ifup is on script failure;
> I couldn't find it documented. Maybe this needs to be clarified? That's also
> why I've filed a bug against postfix, whose if-up.d script really shouldn't
> be failing so casually.
> 
> Still, doing things halfway (killing dhclient but leaving the interface up)
> doesn't feel right. I'd rather deal with an immediate failure than with a
> delayed one.

I can certainly document the behaviour on script failure (as well as
documenting the order in which things are executed). Cleaning up after a
failure is currently not done. I can partially add that; the problem is
that there is no clearly defined order of what (post-)down commands/scripts 
should
be executed given a failure at a given stage of bringing the interface
up.

However, I can ensure that at least the interface's built-in methods
clean up properly after an error, so that a failing script after the
DHCP client is started will cause the client to be stopped orderly by
ifupdown itself, and the link brought down as well.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Wednesday, 6 May 2020 9:58:03 PM AEST Ansgar wrote:
> > Clearly there is a problem in "php7.4-fpm" which should not depend on
> > "systemd" in first place because it is perfectly functional without
> > "systemd- tmpfiles" and without "systemd" as far as I can tell.
> 
> It might or might not be; adding wrong dependency information to other
> packages to work around that isn't a solution.

I insist that "adding wrong dependency information to other packages"
is not a situation here, if you misled to think that from unfortunate 
changelog entry in "systemctl" package.


> Though depending on packages required by startup scripts (init scripts
> or systemd units) doesn't seem wrong for Debian packages, even when
> specific use cases might not require it (when you provide your own,
> different startup scripts).

On this instance it is wrong. Suppose you install "php7.4-fpm" to run it with 
"runit" or "supervisor". In such situation it might be perfectly reasonable 
to have "broken" systemd because you would be starting "php7.4-fpm" using a 
custom service management script.

However there will be serious problem if "runit" or "supervisor" conflicts 
with "systemd" -- that is exactly the situation with "systemctl" package that 
provides compatible interface with "systemd" to manage services with native 
.service files (with little or no modifications).


> There also exist solutions like `equivs` for these cases.

Which is absolutely not acceptable for "systemctl" package because "systemd" 
will not work with "bin/systemctl" binary from "systemctl" package. It would 
be far worse to break "systemd" by installing "systemctl" package along with 
it. Remember that "bin/systemctl" is _the_ interface to manage services under 
"systemd" and "systemctl".

We do not have a problem with "Provides: systemd" in "systemctl" package on 
systems where "systemd" is installed by default because admins knowingly 
install "systemctl" in order to replace "systemd".

We do not have a problem with "Provides: systemd" in "systemctl" package on 
systems where "systemctl" is installed from scratch to manage services 
without systemd hence avoiding installation of "systemd".

I can't see where we would have a problem at all so I'll downgrade severity 
once again.


> With php7.4-fpm 7.4.5-1 and systemctl 1.4.4181-1 installed in a current
> Debian unstable:
> 
> +---
> 
> | root@09f957efac98:/# /etc/init.d/php7.4-fpm start
> | /etc/init.d/php7.4-fpm: 99: systemd-tmpfiles: not found
> 
> +---
> 
> That's what the dependency is for and it's broken because of the
> `Provides`.

No, it is broken because of the bug in SysV init script which explicitly 
calls `systemd-tmpfiles` binary hence _requires_ systemd facility.

Arguably it is a bad idea to hard-depend on "systemd" for SysV services and 
this is precisely the systemd zealotry that makes maintenance of alternatives 
so hard, creates bad reputation to Debian and poisons debates with toxic 
arguments... :(

As I've said earlier, you would not install "runit", "supervisor" or 
"systemctl" to use foreign interfaces to manage services.

Your example would have been more valid with `systemctl start php7.4-fpm` 
which needs a manual workaround to create `/run/php`.

FYI I've reported this problem upstream:

  https://github.com/gdraheim/docker-systemctl-replacement/issues/98

However "systemctl" is not suppose to provide a 100% compatible 
implementation of systemd features and I hope we will not be arguing on what 
percentage of interface compatibility warrants "Provides".

-- 
Cheers,
 Dmitry Smirnov.

---

Some like to understand what they believe in. Others like to believe in
what they understand.
-- Stanisław Jerzy Lec


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

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 23:01, Yun Peng wrote:
>> It seemed there was some ambiguity on licensing from the links Andrej
>> posted. Do you know who (if anyone) is responsible for diffutils at
>> Google now? If Google holds copyright then it should be possible to get
>> clarification on that license.

> Although the code is hosted on Google Code Archive, I don't think Google
> owns this code because it's in our internal third_party directory. Also
> from the commit history
> ,
> I don't think any of the authors is Googler.
> This project looks like it is no longer under development, but on the
> Google Code Archive page
> , it states very
> clearly the license is Apache License 2.0.
If you read the original thread I linked, you’ll see the code is derived
from a different project and it was originally mixed ASL 1.1 and
LGPL-2.1 and was at some point relicensed by the j-d-u authors, which
they were not legally allowed to do.

This makes the code not acceptable in Debian.

I’m also very much against of packaging an obsolete and buggy old
version of the code when we already have the new one in Debian.

-- 
Cheers,
  Andrej

Bug#959913: autopkgtest: please clarify breaks-testbed

[Andreas Beckmann]

Source: autopkgtest
Version: 5.13.1
Severity: normal

Hi,

I have some problems understanding the breaks-testbed restriction:

  breaks-testbed
The test, when run, is liable to break the testbed system. This
includes causing data loss, causing services that the machine is
running to malfunction, or permanently disabling services; it does
not include causing services on the machine to temporarily fail.

AIUI the testbed system is a throwaway chroot/container/virtual machine/...
So how can breakage (e.g. rm /bin/ls) be persistent? Or is it possible
to run subsequent tests in the same testbed instance?
Or does that mean the test can affect the host system? (E.g. from a
chroot with root access killing all processes with even PIDs, including
processes on the host.)
BTW, what does "machine" denote in the quoted paragraph?

Or am I on the wrong track here?


Andreas

Bug#959912: ITP: droidlysis -- Property extractor for Android apps

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner 

* Package name: droidlysis
  Version : 3.1.0
  Upstream Author : Axelle Apvrille
* URL : https://github.com/cryptax/droidlysis
* License : MIT
  Programming Lang: Python
  Description : Property extractor for Android apps

https://salsa.debian.org/python-team/applications/droidlysis

 DroidLysis is a property extractor for Android apps. It automatically
 disassembles the Android application you provide and looks for
 various properties within the package or its disassembly.  DroidLysis
 can be used over Android packages (apk), Dalvik executables (dex),
 Zip files (zip), Rar files (rar) or directories of files.
 .
 DroidLysis outputs:
 .
  * A summary on the console
  * The unzipped, pre-processed sample in a subdirectory of your output
dir. The subdirectory is named using the sample's filename and
sha256 sum.
  * A database (by default, SQLite droidlysis.db) containing
properties it noticed.

Bug#959723: RM: matrix-synapse/0.99.2-6 -- ROM; security issues; obsolete version

[Moritz Mühlenhoff]

On Mon, May 04, 2020 at 11:04:21PM +0200, Andrej Shadura wrote:
> On Mon, May 04, 2020 at 06:33:26PM +0200, Julien Cristau wrote:
> > > I think in this case it’s okay because of this NEWS entry:
> > > 
> > > https://sources.debian.org/src/matrix-synapse/0.99.2-6/debian/NEWS/
> 
> > I'm not sure how that makes it any better?  NEWS is shown on upgrade at
> > best, so anyone installing this on buster won't see it.
> 
> True; I haven’t thought about people who never had synapse installed
> before. In any case, I think anyone installing this on buster does
> follow the news about Matrix and probably tried to figure out how to
> upgrade.

Notifying users about an EOL package is handled by debian-security-support,
simply file a bug against it and the next time it lands in stable, people
will be notified who have it installed.

I'm all in favour of removing it by 10.4 or 10.5, depending on whether
the timing still allows for 10.4.

Cheers,
Moritz

Bug#959910: dkms: improve dkms-autopkgtest

[Andreas Beckmann]

Package: dkms
Version: 2.8.1-5
Severity: normal

Hi,

attached you can find 2 patches that aim on improving dkms-autopkgtest.
It does not solve the issue of missing linux-headers-* - that should be
addressed via autodep8.

IMO tests using dkms-autopkgtest should primarily test whether the
modules can be built against (all variants) of the current kernel to
quickly notice regressions (aka build failures) caused by newer kernel
headers.

Parsing the autoinstall result from apt-get output and logs does not
really work if the failure occurs while autopkgtest installs test
dependencies because dkms-autopkgtest won't be run in that case.
Neither does it work for multiple linux-headers-* packages being
installed.

Therefore the first patch adds the ability to disable autoinstall by
creating the flag file /etc/dkms/no-autoinstall. Then the required
packages can be installed without risking failures and dkms-autopkgtest
can run the build and install steps separately, providing more verbose
errors on failure.
dkms-autopkgtest will loop over all available kernel headers (via
existence of /lib/modules/*/build) and try to build and install the
module for them, that should work even in a plain chroot. It will
continue testing more headers even if one failed to collect as much
information as possible.

This should be used from autodep8 generated test instances like

Test-Command: /usr/lib/dkms/dkms-autopkgtest
Restrictions: needs-root, allow-stderr, superficial
Depends: dkms,
 linux-headers-4kc-malta [mipsel],
 linux-headers-5kc-malta [mips64el mipsel],
 linux-headers-686 [i386],
 linux-headers-686-pae [i386],
 linux-headers-amd64 [amd64],
 linux-headers-arm64 [arm64],
 linux-headers-armmp [armhf],
 linux-headers-armmp-lpae [armhf],
 linux-headers-cloud-amd64 [amd64],
 linux-headers-cloud-arm64 [arm64],
 linux-headers-loongson-3 [mips64el mipsel],
 linux-headers-marvell [armel],
 linux-headers-octeon [mips64el mipsel],
 linux-headers-powerpc64le [ppc64el],
 linux-headers-rpi [armel],
 linux-headers-rt-686-pae [i386],
 linux-headers-rt-amd64 [amd64],
 linux-headers-rt-arm64 [arm64],
 linux-headers-rt-armmp [armhf],
 linux-headers-s390x [s390x],
Features: test-name=dkms-autopkgtest

Note there is no longer a
  Depends: @
to prevent the *-dkms package being installed together with
linux-headers-* before dkms-autopkgtest gets the change to
create the no-autoinstall flag file.
(I'll file a separate bug about this against autodep8.)

This seems to work well for Debian (tested on bbswitch-dkms), I don't
know about the impact on Ubuntu.


Andreas
>From cb233cf90bee2c8bc6bbeb808e0897d56b01 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 6 May 2020 15:28:10 +0200
Subject: [PATCH 1/3] use /etc/dkms/no-autoinstall as flag file to disable
 autoinstall

---
 debian/patches/no-autoinstall-flag-file.patch | 39 +++
 debian/patches/series |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/no-autoinstall-flag-file.patch

diff --git a/debian/patches/no-autoinstall-flag-file.patch 
b/debian/patches/no-autoinstall-flag-file.patch
new file mode 100644
index 000..7592764
--- /dev/null
+++ b/debian/patches/no-autoinstall-flag-file.patch
@@ -0,0 +1,39 @@
+Author: Andreas Beckmann 
+Description: use /etc/dkms/no-autoinstall as flag file to disable autoinstall
+ intended use: autopkgtests should not fail while installing *-dkms
+ or linux-headers-* without detailed error reporting
+ instead they can run the invidiual steps with verbose error reporting
+
+--- a/dkms_autoinstaller
 b/dkms_autoinstaller
+@@ -45,9 +45,13 @@ case "$1" in
+   else
+   kernel=`uname -r`
+   fi
+-  log_daemon_msg "$prog: running auto installation service for 
kernel $kernel"
+-  dkms autoinstall --kernelver $kernel
+-  log_end_msg $?
++  if [ -f /etc/dkms/no-autoinstall ]; then
++  log_daemon_msg "$prog: autoinstall for dkms modules has 
been disabled"
++  else
++  log_daemon_msg "$prog: running auto installation 
service for kernel $kernel"
++  dkms autoinstall --kernelver $kernel
++  log_end_msg $?
++  fi
+   ;;
+   stop|restart|force-reload|status|reload)
+   # There is no stop action, this and the 04 priority during stop 
is
+--- a/dkms_common.postinst
 b/dkms_common.postinst
+@@ -149,6 +149,11 @@ if [ -z "$NAME" ] || [ -z "$VERSION" ];
+ exit 1
+ fi
+ 
++if [ -f /etc/dkms/no-autoinstall ]; then
++echo "autoinstall for dkms modules has been disabled."
++exit 0
++fi
++
+ # read framework configuration options
+ if [ -r /etc/dkms/framework.conf ]; then
+ . /etc/dkms/framework.conf
diff --git a/debian/patches/series b/debian/patches/series
index 4091394..eb51d12 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 

Bug#959911: python3.7: No module named '_cffi_backend'

[Yaroslav Halchenko]

Package: python3-cryptography
Version: 2.8-4
Severity: important

I am not sure if it is more pertinent to python3-cffi or one of its packages.

I am still using python3.7 which is AFAIK still supported on sid.  But with it,
it fails to import (using it via keyrings module):

$> docker run -it --rm debian:sid
root@c911d74fa6cb:/# apt-get update -qqq; apt-get install -y python3.7 
python3-cryptography >/dev/null
debconf: delaying package configuration, since apt-utils is not 
installed
root@c911d74fa6cb:/# python3.7 -c 'import 
cryptography.hazmat.primitives.constant_time'
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/constant_time.py",
 line 11, in 
from cryptography.hazmat.bindings._constant_time import lib
ModuleNotFoundError: No module named '_cffi_backend'
root@c911d74fa6cb:/# ls -l 
/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/
total 824
-rw-r--r-- 1 root root246 Oct 17  2019 __init__.py
drwxr-xr-x 2 root root   4096 May  6 20:49 __pycache__
-rw-r--r-- 1 root root  14512 Apr  4 22:53 _constant_time.abi3.so
-rw-r--r-- 1 root root 795160 Apr  4 22:53 _openssl.abi3.so
-rw-r--r-- 1 root root  14488 Apr  4 22:53 _padding.abi3.so
drwxr-xr-x 3 root root   4096 May  6 20:48 openssl

it imports fine with python3.8 in sid.  I wonder if that is the .abi3 which is
not compatible with python 3.7?

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

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

Versions of packages python3-cryptography depends on:
ii  libc62.30-4
ii  libssl1.11.1.1g-1
ii  python3  3.8.2-3
ii  python3-cffi-backend [python3-cffi-backend-api-min]  1.14.0-2
pn  python3-cffi-backend-api-max 
ii  python3-six  1.14.0-3

python3-cryptography recommends no packages.

Versions of packages python3-cryptography suggests:
pn  python-cryptography-doc   
pn  python3-cryptography-vectors  

-- no debconf information

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Hi Yun,

On Wed, May 6, 2020 at 3:38 PM Yun Peng  wrote:

> Hi Olek,
>
> First to correct one thing I said previously. The libdiffutils-java
> package is indeed a fork of the one Bazel has been using instead of what I
> said a character based diff implementation. I confused it with a different
> project diff-match-patch .
>

Ah, thanks for the clarification.


> Theoretically we can port Bazel to use the newer j-d-u library. I tried to
> do that, but it turned out the old version (diffutils-1.3.0) is imported in
> Google's internal code base and is a dependency by many other projects,
> including the internal version of Bazel.
> So it's very hard to migrate Bazel to the forked version of j-d-u.
>

Well that's not good news... :( Do you know if there's a newer/maintained
version of the pre-fork diffutils somewhere?


> As for the old version, I don't see where the license issue comes from.
> The code is very simple and it should be under Apache 2 license. I still
> hope we can have it in Debian if that's possible.
>

It seemed there was some ambiguity on licensing from the links Andrej
posted. Do you know who (if anyone) is responsible for diffutils at Google
now? If Google holds copyright then it should be possible to get
clarification on that license.

-Olek

>

Bug#959909: debian-policy: complete implementation of ctte decision to forbid vendor-specific series files

[Sean Whitton]

Package: debian-policy
Version: 4.5.0.2
Tags: patch

Hello,

Quoting from #904302:

> The Committee therefore resolves that:
>
> 1. Any use of dpkg's vendor-specific patch series feature is a bug for
>packages in the Debian archive (including contrib and non-free).
>
>This should be implemented in Debian Policy by declaring that a
>package SHOULD NOT contain a non-default series file.
>
> 2. After Buster is released, use of the vendor-specific patch series
>feature is forbidden in the Debian archive.
>
>This should be implemented in Debian Policy by declaring that a
>package MUST NOT contain a non-default series file.

Here is a patch to finish implementing this; I am seeking seconds:

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1a4e871..58da61e 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -811,8 +811,8 @@ Vendor-specific patch series
 

 Packages in the Debian archive using the 3.0 (quilt) source package
-format should not contain a non-default series file.  That is, there
-should not exist a file ``debian/patches/foo.series`` for any ``foo``.
+format must not contain a non-default series file.  That is, there
+must not exist a file ``debian/patches/foo.series`` for any ``foo``.

 .. [#]
Rationale:
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 2a8cc99..cae05c7 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -39,6 +39,18 @@ The sections in this checklist match the values for the
 except in the two anomalous historical cases where normative
 requirements were changed in a minor patch release.

+Version 4.5.1
+-
+
+Unreleased.
+
+4.17
+Packages must not contain a non-default series file.  That is,
+dpkg's vendor-specific patch series feature must not be used for
+packages in the Debian archive.
+
+(previously a "should not")
+
 Version 4.5.0
 -

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#853915: reportbug: Retrieved base64 messages aren't decoded

[Nis Martensen]

> So either something does not work as expected there, or I'm simply
> looking at the wrong code and should be looking somewhere else.

If this is the correct code, then why is it behaving differently when
its is run to serve a soap request, as compared to running it directly,
 for the same email message?

This is at least happening for multipart/signed messages, and likely
also for other MIME messages. For testing I am using the initial report
mail from #853037. The BTS' SOAP interface delivers the message body as
the entire undecoded body of the primary email message, as if the BTS
did not understand multipart messages at all. See `reportbug -N 853037`
for how the email body is then displayed by reportbug.

However, when I run this same message through Debbugs::MIME's `parse`,
it correctly identifies the text/plain subpart and decodes and returns
it. I've tested this by downloading the message mbox:

wget -O msg
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853037;mbox=yes;msg=5

and then using the following perl script to call the `parse` function:

--- m.pl --
#! /usr/bin/perl

use strict;
use warnings;

use Data::Dumper;
use Debbugs::MIME qw(parse);

sub make_list {
 return map {(ref($_) eq 'ARRAY')?@{$_}:$_} @_;
}

local $/;
my $lines = <>;

my $message = parse $lines;
my ($header, $body) = map {join("\n", make_list($_))}
@{$message}{qw(header body)};

print Dumper({header => $header, body => $body,});
-

Command line:

perl -I debbugs/lib/ m.pl < msg

Here the result shows a nicely identified and extracted message text.

Looking now at the code starting here:
https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/lib/Debbugs/MIME.pm#L130
Somehow, when the code is run on the BTS server, the MIME::Parser seems
to fail and the `parse` function code is falling back to the legacy
pre-MIME code. Why?

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[Jonas Smedegaard]

Control: clone -1 -2
Control: retitle -2 pandoc: please upgrade to 2.4 or newer to support parsing 
man format
Control: severity -2 wishlist

Quoting Jonas Smedegaard (2020-05-06 21:14:24)
> Quoting James Youngman (2020-05-06 20:43:10)
> > It seems to me that that interpretation was rather optimistic (and 
> > easily falsifiable using the provided reproduction steps):
> > 
> > horizon:~$ rm -f  bbcbasic.html;  pandoc -f man  -s  -o bbcbasic.html
> >  /tmp/minimal_nroff2.1 ; echo exit status $?; ls -l bbcbasic.html
> > Unknown reader: man
> > exit status 1
> > /bin/ls: cannot access 'bbcbasic.html': No such file or directory

Quoting John MacFarlane (2020-05-06 21:50:11)
> As you can see from pandoc's changelog, the man reader was only 
> introduced in version 2.4.  You're using an older version, so...

Thanks again, John.


> > Please reconsider the severity change.

Hereby forking the bugreport to separately track upgrading the pandoc 
package to a version which supports parsing man format.

Please do elaborate if you meant differently with your request for 
severity change.

 - 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#959907: librust-derive-builder+env-logger-dev: cannot be installed

[Sebastian Ramacher]

Package: librust-derive-builder+env-logger-dev
Version: 0.9.0-2
Severity: grave
Justifiaction: renders package unusable

$ udo apt install librust-derive-builder+env-logger-dev 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-derive-builder+env-logger-dev : Depends: 
librust-env-logger-0.5+default-dev but it is not installable
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959906: linux-image-5.6.0-1-arm64: Please enable CONFIG_DRM_ANALOGIX_ANX6345 on arm64

[Harald Geyer]

Package: src:linux
Version: 5.6.7-1
Severity: wishlist

Dear maintainer,

the analogix ANX6345 RGB-to-eDP video bridge is used at least in
pinebook and Teres-I OSHW Laptop. Including the driver in debian
kernel packages would allow using the proper display enginge instead
of the simple-framebuffer setup by u-boot.

Enabling CONFIG_DRM_ANALOGIX_ANX6345 should do the tick.

TIA,
Harald

-- Package-specific info:
** Version:
Linux version 5.6.0-1-arm64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)

** Command line:
rootwait root=UUID=2f4b7ce4-b9c5-4544-a938-9f189be41719 debug=on console=tty0 
console=ttyS0,115200n8 no_console_suspend

** Tainted: WC (1536)
 * kernel issued warning
 * staging driver was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Device Tree model: Olimex A64 Teres-I

** Loaded modules:
psnap
llc
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
hid_generic
videodev
usbhid
mc
hid
evdev
r8723bs(C)
ghash_ce
axp20x_battery
des_generic
lima
libdes
axp20x_ac_power
axp20x_adc
gf128mul
sha2_ce
cfg80211
industrialio
sha256_arm64
gpu_sched
axp20x_pek
aes_ce_blk
sun50i_codec_analog
sha1_ce
crypto_simd
sun8i_adda_pr_regmap
snd_soc_simple_card
sun8i_thermal
sun8i_codec
sun4i_i2s
rfkill
cryptd
snd_soc_simple_amplifier
snd_soc_simple_card_utils
sunxi_wdt
watchdog
sun4i_drm
snd_soc_core
pwm_sun4i
sun4i_frontend
aes_ce_cipher
sun4i_tcon
snd_pcm_dmaengine
sun8i_mixer
snd_pcm
sun8i_tcon_top
drm_kms_helper
snd_timer
sun8i_ce
nvmem_sunxi_sid
sun6i_dma
snd
drm
gpio_keys
soundcore
pwm_bl
cpufreq_dt
leds_gpio
asix
usbnet
mii
libphy
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
axp20x_regulator
pinctrl_axp209
ohci_platform
ohci_hcd
ehci_platform
axp20x_rsb
axp20x
ehci_hcd
fixed
usbcore
i2c_mv64xxx
phy_sun4i_usb
usb_common
sunxi_mmc

** PCI devices:

** USB devices:
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 007: ID 15ba:003c Olimex Ltd. 
Bus 001 Device 005: ID 1908:2311 GEMBIRD 
Bus 001 Device 009: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.6.0-1-arm64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.6.0-1-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.132
ii  kmod27-2
ii  linux-base  4.5

Versions of packages linux-image-5.6.0-1-arm64 recommends:
pn  apparmor 
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.6.0-1-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.6   

Versions of packages linux-image-5.6.0-1-arm64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20180825+dfsg-1
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#939271: tornado 6 -> unstable

[Gordon Ball]

Unless there are objections, I'll upload python-tornado 6 to unstable in
a week or so, with breaks against

pcs (<< 0.10.5-1~)
mitmproxy (<< 5.0~)

Bug#882584: Found the salsa package

[yanu]

On Sun, 15 Mar 2020 12:26:28 + Mike Gabriel 
 wrote:
> On  So 15 Mär 2020 03:10:03 CET, Martin Quinson wrote:
> > On Sat, Mar 14, 2020 at 09:02:49PM +, Mike Gabriel wrote:
> >> On  Sa 14 Mär 2020 00:36:21 CET, Martin Quinson wrote:
> >>
> >> > https://salsa.debian.org/debian-edu-pkg-team/openboard/
> >> >
> >> > could we however modify this git repository to use git-buildpackage?
> >> > It makes things so much easier to maintain...
> >> >
> >> > Thanks for your work,
> >> > Mt
> >>
> >> Sorry, no. I see myself in a constant process of removing more and more
> >> files from the upstream Git tag/tarball, because files are non-DFSG for 
> >> this
> >> or that reason. I am not willing to pollute the salsa repo with these
> >> changes.
> >
> > Ok, you know that better than I do.
> >
> >> To get openboard on salsa built, these steps should work:
> >>
> >>   $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git
> >>   $ cd openboard
> >>   $ debian/rules get-orig-source
> >>   $ debuild -uc -us -S -Zxz -d
> >>   $ dpkg-source -x openboard_.dsc
> >>   $ cd openboard-
> >>   $ debuild -uc -us
> >
> > I just tried, and it fails on the last step because of missing
> > dependencies. Maybe we could add a .gitlab-ci attempting these steps
> > so that we see where we currently stand?
> >
> >> IIRC, the current version on the repo's master branch only works / builds
> >> well on Debian testing/unstable.
>
> I'll try to invest some time on OpenBoard during the next week to
> bring myself and then you up to speed. I have a long feedback mail (in
> German) from a teacher in Germany with several suggestions. I'll try
> to translate the gist of that and post it to you (and the
> debian-edu-pkg-team's mailing list).

I'm on debian/unstable (desktop and laptop) and confirms that openboard is 
working, not perfect, but good.

With the compile-steps from Mike, I could compile all the openboard-packages, 
after installing a lot of dependencies (I saved the list).
  openboard - Interactive White Board Application
  openboard-common - Interactive White Board Application (common files)
  openboard-dbgsym - debug symbols for openboard
  openboard-fonts-nonfree - Interactive White Board Application (non-free fonts)

As a electric teacher in corana-times, I'm using openboard everyday as my main 
tool to teach.
Once in a while there is a crash, but after a quick restart, nothing is lost.

I would like to use this also after they find a vaccin against corona.
Then I would like to use it more often to evaluate papers, instead of printing 
them (saving the trees).
Also bought a wacom tablet to draw sketches, graphics, ... The wacom pen-top is 
melting fast ;-)
So, it would be great to have this software in debian repositories.

My software-knowledge doesn't go further than some hobby-programming on arduino.
I'm willing to donate some developping-time ?

Keep up the good work !
--
Lieven aka yanu 

Bug#959905: ydotool: FTBFS: relocation R_X86_64_PC32 against symbol `_ZTISt13runtime_error@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC

[Sebastian Ramacher]

Source: ydotool
Version: 0.1.8-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

While rebuilding on buildd, ydotool failed to build:
https://buildd.debian.org/status/fetch.php?pkg=ydotool=amd64=0.1.8-2%2Bb1=1588761426=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[John MacFarlane]

As you can see from pandoc's changelog, the man reader was only
introduced in version 2.4.  You're using an older version, so...

Bug#959904: android-platform-system-tools-hidl: FTBFS no matching function for call to ‘find(std::vector >::const_iterator, std::vector

[Sebastian Ramacher]

Source: android-platform-system-tools-hidl
Version: 9.0.0+r45-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

ndroid-platform-system-tools-hild currently fails to build. See
https://buildd.debian.org/status/fetch.php?pkg=android-platform-system-tools-hidl=amd64=9.0.0%2Br45-1%2Bb1=1588760324=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959883: gnome-shell: randomly crashes: segfaults and restarts

[Simon McVittie]

On Wed, 06 May 2020 at 15:21:30 -0300, Antonio Terceiro wrote:
> The actual core dump is 19MB compresses, is it useful?

Not particularly, because I probably don't have precisely the same
versions of libraries that you do. I might need to ask you to install
-dbgsym packages and get a backtrace with `coredumpctl gdb` if we can't
work out what's going on any other way.

> Stack trace of thread 86099:
> #0  0x7f5b6079408d __strncmp_avx2 (libc.so.6 + 0x15a08d)
> #1  0x7f5b61481f9d g_str_has_prefix (libglib-2.0.so.0 + 
> 0x71f9d)
> #2  0x7f5b605df475 _st_theme_node_ensure_background 
> (libst-1.0.so + 0x39475)
> #3  0x7f5b605e31a5 st_theme_node_paint_equal 
> (libst-1.0.so + 0x3d1a5)
> #4  0x7f5b605edc73 n/a (libst-1.0.so + 0x47c73)
> #5  0x7f5b605edfc3 st_widget_style_changed (libst-1.0.so 
> + 0x47fc3)

This looks like it could be
. If so, there's
a fix in upstream git (not uploaded to Debian yet).

smcv

Bug#959903: ruby-doorkeeper: CVE-2020-10187

[Salvatore Bonaccorso]

Source: ruby-doorkeeper
Version: 5.0.2-2
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for ruby-doorkeeper.

CVE-2020-10187[0]:
| Doorkeeper version 5.0.0 and later contains an information disclosure
| vulnerability that allows an attacker to retrieve the client secret
| only intended for the OAuth application owner. After authorizing the
| application and allowing access, the attacker simply needs to request
| the list of their authorized applications in a JSON format (usually
| GET /oauth/authorized_applications.json). An application is vulnerable
| if the authorized applications controller is enabled.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10187
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10187
[1] 
https://github.com/doorkeeper-gem/doorkeeper/security/advisories/GHSA-j7vx-8mqj-cqp9
[2] 
https://github.com/doorkeeper-gem/doorkeeper/commit/25d038022c2fcad45af5b73f9d003cf38ff491f6

Please adjust the affected versions in the BTS as needed. It is said
that it only affects versions >= 5.0.0, but this needs to be checked
yet (and why).

Regards,
Salvatore

Bug#959902: klayout: Vcs-* fields point to non-existing salsa project

[Jakob Haufe]

Source: klayout
Version: 0.26.2-2
Severity: minor

As stated in the subject: The Vcs control fields point to a project on
salsa which does not exist.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: systemd (via /run/systemd/system)

-- no debconf information

Bug#959901: avr-libc: The include file iom328*.h is missing some register definitions

[Frank Miles]

Package: avr-libc
Version: 1:1.8.0+Atmel3.5.0-1
Severity: normal

Dear Maintainer,

Register definitions above 0xc6 are missing.  These currently exist
in the files available outside of the Debian distribution; see, for 
example:
  
https://github.com/ElektorLabs/Arduino/blob/master/source2/avr/cores/arduino/avr/iom328p.h

Thanks for your work!
  -Frank


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

Kernel: Linux 4.9.168-rt125 (SMP w/8 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)

Versions of packages avr-libc depends on:
ii  binutils-avr  2.26.20160125+Atmel3.5.3-1
ii  gcc-avr   1:4.9.2+Atmel3.5.3-1

avr-libc recommends no packages.

avr-libc suggests no packages.

-- no debconf information

Bug#887100: geeqie: Orientation controls do nothing

[Andreas Ronnquist]

fixed 887100 1:1.5.1-2
thanks

No reply for more than half a year, I assume that the upload fixed the
problem.

best
-- Andreas Rönnquist
gus...@debian.org

Bug#959900: CVE pending / OSSA-2020-004: EC2 and credential endpoints are not protected from a scoped context

[Thomas Goirand]

Source: keystone
Version: 2:14.0.1-2
Severity: grave
Tags: patch security

kay reported a vulnerability in Keystone's EC2 credentials API. Keystone
is the identity service used by OpenStack for authentication (authN)
 and high-level authorization (authZ). Any user authenticated within a
limited scope (trust/oauth/application credential) can create an EC2
credential with an escalated permission, such as obtaining "admin" while
the user is on a limited "viewer" role.

The details and patches are available here:
https://bugs.launchpad.net/keystone/+bug/1872735

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[Jonas Smedegaard]

Quoting James Youngman (2020-05-06 20:43:10)
> It seems to me that that interpretation was rather optimistic (and
> easily falsifiable using the provided reproduction steps):
> 
> horizon:~$ rm -f  bbcbasic.html;  pandoc -f man  -s  -o bbcbasic.html
>  /tmp/minimal_nroff2.1 ; echo exit status $?; ls -l bbcbasic.html
> Unknown reader: man
> exit status 1
> /bin/ls: cannot access 'bbcbasic.html': No such file or directory
> 
> Please reconsider the severity change.

You originally reported an issue of "$ in nroff table causes spurious 
TeX-related failure".

John pointed out (among other things) that (at least never releases) 
supports telling pandoc explicitly to parse as man page.

I have trouble understanding what you are saying above: Do you argue 
that when explicitly telling pandoc to use man, you get the issue that 
you originally reported?

Seems to me you have a different issue on being unable to parse as man.


 - 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#959899: ITP: theli -- A pipeline for astronomical image data reduction

[Kay Thriemer]

Package: wnpp
Owner: Kay Thriemer 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org



* Package name    : theli
  Version : 3.0.0
  Upstream Author : Mischa Schirmer 
* URL : https://github.com/schirmermischa/THELI
* License : GNU GPL
  Programming Lang: C++ / Qt5
  Description : A pipeline for astronomical image data reduction


THELI is a data processing pipeline for optical, near-infrared and
mid-infrared astronomical images. Version 3 is a complete rewrite in C++
/ Qt5 (compared to version 2 in Qt3), eliminating a large number of
dependencies and overcoming installation issues. Using a hybrid
memory/drive data model and full parallelization, v3 offers a vast gain
in processing speed. Depending on the hardware and data set, processing
speed may increase by factors 2 to 20. THELI v3 also fully scales with
the amount of available RAM and CPUs on your machine, and there is still
potential for further improvement.

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on salsa:

https://salsa.debian.org/debian-astro-team/theli.git

Best regards

Kay

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[James Youngman]

It seems to me that that interpretation was rather optimistic (and
easily falsifiable using the provided reproduction steps):

horizon:~$ rm -f  bbcbasic.html;  pandoc -f man  -s  -o bbcbasic.html
 /tmp/minimal_nroff2.1 ; echo exit status $?; ls -l bbcbasic.html
Unknown reader: man
exit status 1
/bin/ls: cannot access 'bbcbasic.html': No such file or directory

Please reconsider the severity change.

Bug#959883: gnome-shell: randomly crashes: segfaults and restarts

[Antonio Terceiro]

The crash just happened again after I left the machine unattended for a
while while looking at something else.

root@lemur:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Wed 2020-05-06 14:51:28 -03   84995  1000  1000  11 present   
/usr/libexec/gnome-shell-hotplug-sniffer
Wed 2020-05-06 14:52:45 -03   86431  1000  1000  11 present   
/usr/libexec/gnome-shell-hotplug-sniffer
Wed 2020-05-06 15:15:40 -03   86099  1000  1000  11 present   
/usr/bin/gnome-shell

The actual core dump is 19MB compresses, is it useful?

root@lemur:~# coredumpctl info 86099 > /tmp/core
root@lemur:~# cat /tmp/core
   PID: 86099 (gnome-shell)
   UID: 1000 (terceiro)
   GID: 1000 (terceiro)
Signal: 11 (SEGV)
 Timestamp: Wed 2020-05-06 15:15:38 -03 (3min 24s ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/gnome-shell-x11.service
  Unit: user@1000.service
 User Unit: gnome-shell-x11.service
 Slice: user-1000.slice
 Owner UID: 1000 (terceiro)
   Boot ID: 1fa16c032db74ac6a577e6728a595e6e
Machine ID: 5611d778ed3749cc9a5086df5bf160a5
  Hostname: lemur
   Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.1fa16c032db74ac6a577e6728a595e6e.86099.1588788938.lz4
   Message: Process 86099 (gnome-shell) of user 1000 dumped core.

Stack trace of thread 86099:
#0  0x7f5b6079408d __strncmp_avx2 (libc.so.6 + 0x15a08d)
#1  0x7f5b61481f9d g_str_has_prefix (libglib-2.0.so.0 + 
0x71f9d)
#2  0x7f5b605df475 _st_theme_node_ensure_background 
(libst-1.0.so + 0x39475)
#3  0x7f5b605e31a5 st_theme_node_paint_equal (libst-1.0.so 
+ 0x3d1a5)
#4  0x7f5b605edc73 n/a (libst-1.0.so + 0x47c73)
#5  0x7f5b605edfc3 st_widget_style_changed (libst-1.0.so + 
0x47fc3)
#6  0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#7  0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#8  0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#9  0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#10 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#11 0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#12 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#13 0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#14 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#15 0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#16 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#17 0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#18 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#19 0x7f5b605edf6c st_widget_style_changed (libst-1.0.so + 
0x47f6c)
#20 0x7f5b605ee0d5 n/a (libst-1.0.so + 0x480d5)
#21 0x7f5b6154b206 n/a (libgobject-2.0.so.0 + 0x14206)
#22 0x7f5b615698d4 g_signal_emit_valist 
(libgobject-2.0.so.0 + 0x328d4)
#23 0x7f5b61569edf g_signal_emit (libgobject-2.0.so.0 + 
0x32edf)
#24 0x7f5b605dbb11 n/a (libst-1.0.so + 0x35b11)
#25 0x7f5b6154b206 n/a (libgobject-2.0.so.0 + 0x14206)
#26 0x7f5b615698d4 g_signal_emit_valist 
(libgobject-2.0.so.0 + 0x328d4)
#27 0x7f5b61569edf g_signal_emit (libgobject-2.0.so.0 + 
0x32edf)
#28 0x7f5b5fb2accd n/a (libffi.so.7 + 0x6ccd)
#29 0x7f5b5fb2a25a n/a (libffi.so.7 + 0x625a)
#30 0x7f5b60b62f49 n/a (libgjs.so.0 + 0x37f49)
#31 0x7f5b60b64d07 n/a (libgjs.so.0 + 0x39d07)
#32 0x7f5b5e97a193 n/a (libmozjs-68.so.0 + 0x106193)
#33 0x7f5b5e96c4a4 n/a (libmozjs-68.so.0 + 0xf84a4)
#34 0x7f5b5e97948d n/a (libmozjs-68.so.0 + 0x10548d)
#35 0x7f5b5e979ef0 n/a (libmozjs-68.so.0 + 0x105ef0)
#36 0x7f5b5e97a4a9 n/a (libmozjs-68.so.0 + 0x1064a9)
#37 0x7f5b5eead44a n/a (libmozjs-68.so.0 + 0x63944a)
#38 0x7f5b5eead824 n/a (libmozjs-68.so.0 + 0x639824)
#39 0x2e4b5eeb0f64 n/a (n/a + 0x0)
#40 0x55dea8281308 n/a (n/a + 0x0)
#41 0x2e4b5eeb04df n/a (n/a + 0x0)
#42 0x7f5b5efd37d0 n/a (libmozjs-68.so.0 + 0x75f7d0)
#43 0x7f5b5e973ed3 n/a (libmozjs-68.so.0 + 0xffed3)
#44 0x7f5b5e97948d n/a (libmozjs-68.so.0 + 0x10548d)
#45 0x7f5b5e979ef0 n/a (libmozjs-68.so.0 + 0x105ef0)
 

Bug#959587: python-biopython: FTBFS: AssertionError: False is not true

[Andreas Tille]

Control: forwarded -1 https://github.com/biopython/biopython/issues/2863

Bug#959898: hp-setup does not support parallel port printers

[Michael Schütz]

Package:hplip
Version:3.18.12+dfsg0-2

Since I upgrade from stretch to buster, I can not use my old scanner
any more (HP PSC500 parallel port all-in-one device). I found, that
hp-setup as a part of hplip does not support parallel port any longer.
But in description of this package it is said. 

I tried to compile the package by myself, but ends in massive errors.
Is it possible to compile the package with parallel support?

Thanks,
Michael

-- 
Wer sich zu wichtig für kleine Arbeiten hält, ist meist zu klein für
wichtige Arbeiten.  Jacques Tati

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[Jonas Smedegaard]

Control: severity -1 minor
Control: retitle -1 pandoc: no warning fallback-parsing as markdown (expected 
fixed since v2.8)

Quoting John MacFarlane (2020-05-06 20:06:30)
> 
> Thank you for your report.  If you'd run a more recent version of
> pandoc, you'd have seen the additional warning:
> 
> [WARNING] Could not deduce format from file extension .man
>   Defaulting to markdown
> 
> which should explain things.
> 
> Add '-f man' to your command line and it should work fine. (At
> least it does with the most recent version.)

Thanks, James, for reporting this.

Thanks John, for providing valuable insight to correlating this with 
upstream code.

Seems the helpful warning was added at git commit 680d7b5 and included 
since upstream release 2.8.

Lowered this bugreport to minor and changed its subject, by the 
assumption that it works also in older versions when explicitly told 
which format to process, and the issue therefore is one of suboptimal 
feedback (in older releases, which we are kinda stuck with on Debian, 
due to the pain of Haskell needing to be upgraded all at once and the 
lack of volunteers helping with maintenance of Haskell packages).

 - 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#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Sudip Mukherjee]

Control: retitle 959834 RFP: diffutils-java -- Implementation of general 
operations with diff files

On Wed, May 06, 2020 at 07:34:21PM +0200, Andrej Shadura wrote:
> On 06/05/2020 19:31, Andrej Shadura wrote:
> > On 06/05/2020 19:25, Andrej Shadura wrote:
> >> I don’t think we need the original code since it’s much older and the
> >> fork has seen quite some development. They are backwards-compatible
> >> except that the Maven coordinates are different. Basically, we only need
> >> to patch Bazel to use it.
> > 
> > Correction: they’re not fully compatible, but API difference is not big
> > and porting is quite straight-forward.
> 
> Right, I now remember one more reason why I chose the fork but not the
> original. There was a licensing issue around the diff algo
> implementation in the original. I don’t remember the details, but the
> fork has completely reimplemented it, thus working it around.

Thanks Andrej.

Moving it back to RFP for now.

--
Regards
Sudip

Bug#959897: RFS: awf-gtk2/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK

[Fabrice Creuzot]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "awf-gtk2"

 * Package name: awf-gtk2
   Version : 2.0.0-3
   Upstream Author : Fabrice Creuzot 
 * URL : https://github.com/luigifab/awf-extended
 * License : GPL-3+
 * Vcs : https://github.com/luigifab/awf-extended
   Section : x11

A widget factory is a theme preview application for GTK. It displays the 
various widget types provided by GTK in a single window allowing to see 
the visual effect of the applied theme.


It builds those binary packages:

  awf-gtk2 - A widget factory is a theme preview application for GTK

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


  https://mentors.debian.net/package/awf-gtk2

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/awf-gtk2/awf-gtk2_2.0.0-3.dsc


Changes since the last upload:

   * Initial debian package release (Closes: #959434)

Regards,
Thank you

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[John MacFarlane]

Thank you for your report.  If you'd run a more recent version of
pandoc, you'd have seen the additional warning:

[WARNING] Could not deduce format from file extension .man
  Defaulting to markdown

which should explain things.

Add '-f man' to your command line and it should work fine. (At
least it does with the most recent version.)

Bug#753821: closed by atzlinux (bugreport is too old)

[Steve McIntyre]

Control: reopen -1

Ummm, no. You don't understand how this works it seems. Please do
*not* just close bugs without checking if the bug is actually closed.

I've just tested on a current Buster amd64 system and the bug is still
there, just as described.

On Thu, May 07, 2020 at 12:45:17AM +0800, atzlinux 肖盛文 wrote:
>please use bugreport to report it again.
>
>The code isn't change,this it true.But others all
>changed,hardware,kernel,OS,etc,.
>
>this bug close at first.
>
>
>在 2020/5/6 下午8:39, Steve McIntyre 写道:
>> Control: reopen -1
>>
>> Sorry, not good enough - you don't get to close a bug just because
>> it's "too old". The code hasn't changed and still has the same
>> problem; I've just looked in your latest upload.
>>
>> Steve
>>
>> On Sat, May 02, 2020 at 01:51:03AM +, Debian Bug Tracking System wrote:
>>> This is an automatic notification regarding your Bug report
>>> which was filed against the eject package:
>>>
>>> #753821: eject fails on CD/DVD drive and reports wrong error
>>>
>>> It has been closed by atzlinux .
>>>
>>> Their explanation is attached below along with your original report.
>>> If this explanation is unsatisfactory and you have not received a
>>> better one in a separate message then please contact atzlinux 
>>>  by
>>> replying to this email.
>>>
>>>
>>> -- 
>>> 753821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753821
>>> Debian Bug Tracking System
>>> Contact ow...@bugs.debian.org with problems
>>> From: atzlinux 
>>> To: 753821-d...@bugs.debian.org
>>> Date: Sat, 2 May 2020 09:43:33 +0800
>>> Subject: bugreport is too old
>>> Message-ID: <9500528e-db80-3276-ed3e-1fdfad2a3...@sina.com>
>>>
>>>
>>> -- 
>>> 肖盛文 Faris Xiao
>>> 微信：atzlinux
>>> ＱＱ：909868357
>>> 铜豌豆 Linux 
>>> 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
>>>
>>
>>
>>
>>> From: Steve McIntyre 
>>> To: Debian Bug Tracking System 
>>> Date: Sat, 05 Jul 2014 14:17:42 +0100
>>> Subject: eject fails on CD/DVD drive and reports wrong error
>>> Message-ID: <20140705131742.28987.94205.report...@sledge.mossbank.org.uk>
>>>
>>> Package: eject
>>> Version: 2.1.5+deb1+cvs20081104-13
>>> Severity: important
>>>
>>> I should have reported this ages ago, sorry. :-(
>>>
>>> I've got a system with several CD/DVD drives in it, and they all show
>>> the same behaviour. I think there's a kernel bug with CD locking at
>>> the root of the main problem here, and I'll report another bug there.
>>>
>>> For a while after I start my system, "eject /dev/srX" works just
>>> fine. However, after some non-determined period it stops working
>>> reliably. What I'm seeing is an annoying badly-reported error:
>>>
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>>
>>> After the fourth attempt here, the eject call works. I've tried
>>> hitting the eject button on the drive itself, but no joy. 
>>>
>>> As to reporting ENOTTY, that's just *wrong*.
>>>
>>> Running the same under strace, I can see a silliness here that is the cause:
>>>
>>> open("/dev/sr1", O_RDONLY|O_NONBLOCK)   = 3
>>> ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)
>>> ioctl(3, SG_GET_VERSION_NUM, 0x7fff2e8f387c) = 0
>>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], 
>>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, 
>>> status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, 
>>> resid=0, duration=0, info=0}) = 0
>>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], 
>>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, 
>>> status=02, masked_status=01, sb[18]=[70, 00, 02, 00, 00, 00, 00, 0a, 3a, 
>>> 00, bb, 00, 3a, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, 
>>> resid=0, duration=4, info=0x1}) = 0
>>> ioctl(3, FDEJECT, 0x7fff2e8f38b8)   = -1 ENOTTY (Inappropriate ioctl 
>>> for device)
>>> ioctl(3, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or 
>>> SNDCTL_MIDI_MPUMODE, 0x7fff2e8f3890) = -1 ENOTTY (Inappropriate ioctl for 
>>> device)
>>>
>>> For some daft reason, eject looks to be trying ioctl(CDROMEJECT),
>>> getting EIO as a failure mode, then falling back to ioctl(FDEJECT) on
>>> the CD drive. That last failure is the cause for the ENOTTY error, and
>>> that is reported incorrectly instead of the EIO that is the first (and
>>> correct) error.
>>>
>>> -- System Information:
>>> Debian Release: 7.5
>>>  APT prefers stable
>>>  APT policy: (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/bash
>>>
>>> Versions of packages eject depends on:
>>> ii  

Bug#959896: simgrid: Please add packages to get human-readable backtraces

[Samuel Thibault]

Source: simgrid
Version: 3.25+dfsg-2
Severity: normal

Hello,

On crashes we get 

Backtrace (displayed in actor maestro):
(backtrace not set -- did you install Boost.Stacktrace?)

It would be useful to add 

libunwind-dev libboost-stacktrace-dev

as build-depends to get the backtrace.

Samuel

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

Kernel: Linux 5.6.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
I develop for Linux for a living, I used to develop for DOS.
Going from DOS to Linux is like trading a glider for an F117.
(By entr...@world.std.com, Lawrence Foard)

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Hi Andrej,

On Wed, May 6, 2020 at 1:45 PM Andrej Shadura <
andrew.shad...@collabora.co.uk> wrote:

> On 06/05/2020 19:39, Andrej Shadura wrote:
>
> > Java-diff-utils is based on the LGPL-2.1 code which IIRC was a direct
> > port of GNU diff to Java, and the then-maintainer of j-d-u has slapped
> > ASL on that code:
>
> In other words, in my opinion the right approach would be to port Bazel
> to the current j-d-u project, submit the patch upstream and thus reduce
> the number of packages depending on the legacy j-d-u.
>
> Uploading unmaintained legacy code with questionable licensing is a big
> meh in my book.
>

Wow. Good points. I agree and thanks for bringing them up! I'm willing to
deal with a lot to get good code into Debian but licensing issues is
typically not one of them... :/ Better to know about such things sooner
than later...

Sudip: I appreciate your enthusiasm here but in light of this issue perhaps
it may be better if you looked at one of the other packages instead.

-Olek

Bug#959893: appstream-generator: Link against libglibd-2.0.so broken

[Markus Frosch]

Package: appstream-generator
Version: 0.8.1-1+b1
Severity: grave
Justification: renders package unusable

Hi maintainer,
the package possible needs rebuilding.

> appstream-generator: error while loading shared libraries: libglibd-2.0.so:
> cannot open shared object file: No such file or directory

libglibd-2.0 now has an explicit .0 suffix version:

> $ apt-file search libglibd-2.0.so
> libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.0
> libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.2.1.0
> libglibd-2.0-dev: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so

Adding a symlink helps, but not sure why this happened.

> ln -s libglibd-2.0.so.0 /usr/lib/x86_64-linux-gnu/libglibd-2.0.so

Regards
Markus

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

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

Versions of packages appstream-generator depends on:
ii  libappstream40.12.10-2
ii  libarchive13 3.4.0-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4
ii  libfreetype6 2.10.1-2
ii  libgcc-s110-20200418-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.2-1
ii  libjs-highlight.js   9.12.0+dfsg1-5
ii  libjs-jquery-flot0.8.3+dfsg-1
ii  liblmdb0 0.9.24-1
ii  libpango-1.0-0   1.44.7-4
ii  libphobos2-ldc-shared90  1:1.20.1-1
ii  librsvg2-2   2.48.3-1

Versions of packages appstream-generator recommends:
ii  ffmpeg   7:4.2.2-1+b1
ii  optipng  0.7.7-1+b1

appstream-generator suggests no packages.

-- no debconf information

Bug#959894: debianutils: [INTL:it] Updated Italian translation of po4a documentation

[Beatrice Torracca]

Package: debianutils
Version: 4.9.1
Severity: wishlist
Tags: patch l10n

Hi,

I updated my Italian translation of debianutils po4a documentation. Please 
include it in your next upload.

Thanks,

beatrice
# Italian translation of debianutils man pages
# Copyright (C) 2017 Free Software Foundation, Inc.
# This file is distributed under the same license as the debian-utils package.
# Beatrice Torracca , 2012, 2017.
msgid ""
msgstr ""
"Project-Id-Version: debianutils\n"
"POT-Creation-Date: 2018-05-15 07:57-0400\n"
"PO-Revision-Date: 2020-05-06 19:44+0200\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.3\n"

#. type: TH
#: ../add-shell.8:1
#, no-wrap
msgid "ADD-SHELL"
msgstr "ADD-SHELL"

#. type: TH
#: ../add-shell.8:1
#, no-wrap
msgid "12 May 2011"
msgstr "12 maggio 2011"

#. type: SH
#: ../add-shell.8:2 ../installkernel.8:2 ../ischroot.1:3 ../remove-shell.8:2
#: ../run-parts.8:9 ../savelog.8:3 ../tempfile.1:3 ../which.1:3
#, no-wrap
msgid "NAME"
msgstr "NOME"

#. type: Plain text
#: ../add-shell.8:4
msgid "add-shell - add shells to the list of valid login shells"
msgstr "add-shell - aggiunge shell all'elenco di quelle valide per il login"

#. type: SH
#: ../add-shell.8:4 ../installkernel.8:4 ../ischroot.1:5 ../remove-shell.8:4
#: ../run-parts.8:11 ../savelog.8:5 ../tempfile.1:5 ../which.1:5
#, no-wrap
msgid "SYNOPSIS"
msgstr "SINTASSI"

#. type: Plain text
#: ../add-shell.8:8
msgid "B I [I...]"
msgstr "B I [I...]"

#. type: SH
#: ../add-shell.8:8 ../installkernel.8:6 ../ischroot.1:8 ../remove-shell.8:8
#: ../run-parts.8:20 ../savelog.8:9 ../tempfile.1:9 ../which.1:7
#, no-wrap
msgid "DESCRIPTION"
msgstr "DESCRIZIONE"

#. type: Plain text
#: ../add-shell.8:13
msgid ""
"B copies I to I, adds the given "
"shells to this file if they are not already present, and copies this "
"temporary file back to I."
msgstr ""
"B copia I in I, aggiune le shell "
"specificate in quel file, se non sono già presenti, e ricopia il file "
"temporaneo in I."

#. type: Plain text
#: ../add-shell.8:15
msgid "The shells must be provided by their full pathnames."
msgstr ""
"Le shell devono essere specificate con i loro nomi di percorso completi."

#. type: SH
#: ../add-shell.8:15 ../remove-shell.8:13 ../savelog.8:159 ../tempfile.1:86
#, no-wrap
msgid "SEE ALSO"
msgstr "VEDERE ANCHE"

#. type: Plain text
#: ../add-shell.8:16 ../remove-shell.8:14
msgid "B(5)"
msgstr "B(5)"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "INSTALLKERNEL"
msgstr "INSTALLKERNEL"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "7 Jan 2001"
msgstr "7 gennaio 2001"

#. type: TH
#: ../installkernel.8:1
#, no-wrap
msgid "Debian Linux"
msgstr "Debian GNU/Linux"

#. type: Plain text
#: ../installkernel.8:4
msgid "installkernel - install a new kernel image"
msgstr "installkernel - installa una nuova immagine del kernel"

#. type: Plain text
#: ../installkernel.8:6
msgid "BI"
msgstr "BI"

#. type: Plain text
#: ../installkernel.8:13
msgid ""
"B installs a new kernel image onto the system from the Linux "
"source tree.  It is called by the Linux kernel makefiles when B is invoked there."
msgstr ""
"B installa una nuova immagine del kernel nel sistema "
"dall'albero dei sorgenti Linux. Viene invocato dai makefile del kernel Linux "
"quando viene lì eseguito B."

#. type: Plain text
#: ../installkernel.8:22
msgid ""
"The new kernel is installed into I<{directory}/vmlinuz-{version}>.  If a "
"symbolic link I<{directory}/vmlinuz> already exists, it is refreshed by "
"making a link from I<{directory}/vmlinuz> to the new kernel, and the "
"previously installed kernel is available as I<{directory}/vmlinuz.old>."
msgstr ""
"Il nuovo kernel viene installato in I<{directory}/vmlinuz-{versione}>. Se un "
"collegamento simbolico I<{directory}/vmlinuz> esiste già, viene aggiornato "
"creando un collegamento da I<{directory}/vmlinuz> al nuovo kernel, e il "
"kernel precedentemente installato è disponibile come I<{directory}/vmlinuz."
"old>."

#. type: SH
#: ../installkernel.8:22 ../ischroot.1:35 ../savelog.8:152 ../tempfile.1:69
#, no-wrap
msgid "BUGS"
msgstr "BUG"

#. type: Plain text
#: ../installkernel.8:25
msgid ""
"installkernel resides in /sbin only because the Linux kernel makefiles call "
"it from there.  It should really be in /usr/sbin.  It isn't needed to boot a "
"system."
msgstr ""
"installkernel viene posizionato in /sbin solo perché i makefile del kernel "
"Linux lo invocano da lì. Dovrebbe in realtà essere in /usr/sbin. Non è "
"necessario per avviare un sistema."

#. type: TH
#: ../ischroot.1:2
#, no-wrap
msgid "ISCHROOT"
msgstr "ISCHROOT"

#. type: TH
#: ../ischroot.1:2
#, no-wrap
msgid "30 May 2011"
msgstr "30 maggio 2011"

#. type: TH
#: ../ischroot.1:2 ../run-parts.8:8 ../savelog.8:2 ../tempfile.1:2 ../which.1:2
#, no-wrap
msgid "Debian"

Bug#959892: RFS: awf-gtk3/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK

[Fabrice Creuzot]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "awf-gtk3"

 * Package name: awf-gtk3
   Version : 2.0.0-3
   Upstream Author : Fabrice Creuzot 
 * URL : https://github.com/luigifab/awf-extended
 * License : GPL-3+
 * Vcs : https://github.com/luigifab/awf-extended
   Section : x11

A widget factory is a theme preview application for GTK. It displays the 
various widget types provided by GTK in a single window allowing to see 
the visual effect of the applied theme.


It builds those binary packages:

  awf-gtk3 - A widget factory is a theme preview application for GTK

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


  https://mentors.debian.net/package/awf-gtk3

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/awf-gtk3/awf-gtk3_2.0.0-3.dsc


Changes since the last upload:

   * Initial debian package release (Closes: #959436)

Regards,
Thank you

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Hi Andrej,

On Wed, 6 May 2020 19:25:35 +0200 Andrej Shadura <
andrew.shad...@collabora.co.uk> wrote:
>
> I don’t think we need the original code since it’s much older and the
> fork has seen quite some development. They are backwards-compatible
> except that the Maven coordinates are different. Basically, we only need
> to patch Bazel to use it.

Are you comfortable with making such a patch? If so, could you please
submit it upstream [1] and copy this bug? Sounds like you know what you're
talking about and if you think that would be an easier way to resolve this
issue then I'm 100% behind it!

-Olek

PS If you submit an upstream issue and patch, could you please tag @olekw
and @meteorcloudy? Thanks!

[1] https://github.com/bazelbuild/bazel/issues/new

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Tue, 05 May 2020 19:34:31 +0200 Johannes Schauer wrote:

> Hi,

Hello Johannes, glad to hear from you.

> 
> did you get any further with this problem?

Unfortunately, I failed to progress any further.

I have just retried (who knows, after many system upgrades?!?).
Bad luck! Once again, I am stuck at the following error:

  [...]
  I: removing tempdir ${HOME}/Downloads/TEST/mmdebstrap.9R3P2pDSAZ...
  libguestfs: error: /usr/bin/supermin exited with error status 1.
  To see full error messages you may need to enable debugging.
  Do:
export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
  and run the command again.  For further information, read:
http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
  You can also run 'libguestfs-test-tool' and post the *complete* output
  into a bug report or message to the libguestfs mailing list.

and I really do not know how to debug this.

That's unfortunate, since mmdebstrap looks very promising, but I seem
to be unable to make it work correctly...:-(


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpJETvONd9zb.pgp
Description: PGP signature

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:39, Andrej Shadura wrote:
>>> On 06/05/2020 19:25, Andrej Shadura wrote:
 I don’t think we need the original code since it’s much older and the
 fork has seen quite some development. They are backwards-compatible
 except that the Maven coordinates are different. Basically, we only need
 to patch Bazel to use it.

> Java-diff-utils is based on the LGPL-2.1 code which IIRC was a direct
> port of GNU diff to Java, and the then-maintainer of j-d-u has slapped
> ASL on that code:

In other words, in my opinion the right approach would be to port Bazel
to the current j-d-u project, submit the patch upstream and thus reduce
the number of packages depending on the legacy j-d-u.

Uploading unmaintained legacy code with questionable licensing is a big
meh in my book.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:34, Andrej Shadura wrote:
> On 06/05/2020 19:31, Andrej Shadura wrote:
>> On 06/05/2020 19:25, Andrej Shadura wrote:
>>> I don’t think we need the original code since it’s much older and the
>>> fork has seen quite some development. They are backwards-compatible
>>> except that the Maven coordinates are different. Basically, we only need
>>> to patch Bazel to use it.
>>
>> Correction: they’re not fully compatible, but API difference is not big
>> and porting is quite straight-forward.
> 
> Right, I now remember one more reason why I chose the fork but not the
> original. There was a licensing issue around the diff algo
> implementation in the original. I don’t remember the details, but the
> fork has completely reimplemented it, thus working it around.

Java-diff-utils is based on the LGPL-2.1 code which IIRC was a direct
port of GNU diff to Java, and the then-maintainer of j-d-u has slapped
ASL on that code:

https://bugs.debian.org/845471#52

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:31, Andrej Shadura wrote:
> On 06/05/2020 19:25, Andrej Shadura wrote:
>> I don’t think we need the original code since it’s much older and the
>> fork has seen quite some development. They are backwards-compatible
>> except that the Maven coordinates are different. Basically, we only need
>> to patch Bazel to use it.
> 
> Correction: they’re not fully compatible, but API difference is not big
> and porting is quite straight-forward.

Right, I now remember one more reason why I chose the fork but not the
original. There was a licensing issue around the diff algo
implementation in the original. I don’t remember the details, but the
fork has completely reimplemented it, thus working it around.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:25, Andrej Shadura wrote:
> I don’t think we need the original code since it’s much older and the
> fork has seen quite some development. They are backwards-compatible
> except that the Maven coordinates are different. Basically, we only need
> to patch Bazel to use it.

Correction: they’re not fully compatible, but API difference is not big
and porting is quite straight-forward.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On Wed, 6 May 2020 13:11:52 -0400 Olek Wojnar  wrote:
> On Wed, May 6, 2020 at 12:32 PM Sudip Mukherjee 
> wrote:
> 
> > On Wed, May 06, 2020 at 04:54:22PM +0100, Sudip Mukherjee wrote:
> >
> > > Taking the source from:
> > > https://code.google.com/archive/p/java-diff-utils/source/default/source
> > > the packaging was fairly simple and if noone has already done it I can
> > > finalize it and upload to mentors and change this to ITP at the same
> > time.
> >

> That would be great! It would be best to have someone from the Java Team
> review/sponsor but, if none of them are available, I am willing to do that.

> fwiw, I did a diff and its the same source in the linked jar and the
> > link I gave. Also, looking at java-diff-utils that Andrej mentioned, is
> > actually a fork from the google code.

> Thanks for doing that extra check and good to know! The fork (as well as
> the line vs character thing) would probably be good to mention in the
> package description so it's clear for everyone. I'd also consider adding
> the "google" at the front of the package name (or something else) to easily
> distinguish it from the one already in the repository and prevent confusion
> from users.

I don’t think we need the original code since it’s much older and the
fork has seen quite some development. They are backwards-compatible
except that the Maven coordinates are different. Basically, we only need
to patch Bazel to use it.

-- 
Cheers,
  Andrej

Bug#753821: closed by atzlinux (bugreport is too old)

[atzlinux 肖盛文]

Hi,Steve McIntyre:

There are some type errors in my last email,sorry!

I write again:

Please use reportbug to report it again.

The code isn't change,this is true.But others all
changed,hardware,kernel,OS,etc,.

So,this bug close at first.

在 2020/5/7 上午12:45, atzlinux 肖盛文 写道:
> please use bugreport to report it again.
>
> The code isn't change,this it true.But others all
> changed,hardware,kernel,OS,etc,.
>
> this bug close at first.
>
>
> 在 2020/5/6 下午8:39, Steve McIntyre 写道:
>> Control: reopen -1
>>
>> Sorry, not good enough - you don't get to close a bug just because
>> it's "too old". The code hasn't changed and still has the same
>> problem; I've just looked in your latest upload.
>>
>> Steve
>>
>> On Sat, May 02, 2020 at 01:51:03AM +, Debian Bug Tracking System wrote:
>>> This is an automatic notification regarding your Bug report
>>> which was filed against the eject package:
>>>
>>> #753821: eject fails on CD/DVD drive and reports wrong error
>>>
>>> It has been closed by atzlinux .
>>>
>>> Their explanation is attached below along with your original report.
>>> If this explanation is unsatisfactory and you have not received a
>>> better one in a separate message then please contact atzlinux 
>>>  by
>>> replying to this email.
>>>
>>>
>>> -- 
>>> 753821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753821
>>> Debian Bug Tracking System
>>> Contact ow...@bugs.debian.org with problems
>>> From: atzlinux 
>>> To: 753821-d...@bugs.debian.org
>>> Date: Sat, 2 May 2020 09:43:33 +0800
>>> Subject: bugreport is too old
>>> Message-ID: <9500528e-db80-3276-ed3e-1fdfad2a3...@sina.com>
>>>
>>>
>>> -- 
>>> 肖盛文 Faris Xiao
>>> 微信：atzlinux
>>> ＱＱ：909868357
>>> 铜豌豆 Linux 
>>> 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
>>>
>>
>>
>>> From: Steve McIntyre 
>>> To: Debian Bug Tracking System 
>>> Date: Sat, 05 Jul 2014 14:17:42 +0100
>>> Subject: eject fails on CD/DVD drive and reports wrong error
>>> Message-ID: <20140705131742.28987.94205.report...@sledge.mossbank.org.uk>
>>>
>>> Package: eject
>>> Version: 2.1.5+deb1+cvs20081104-13
>>> Severity: important
>>>
>>> I should have reported this ages ago, sorry. :-(
>>>
>>> I've got a system with several CD/DVD drives in it, and they all show
>>> the same behaviour. I think there's a kernel bug with CD locking at
>>> the root of the main problem here, and I'll report another bug there.
>>>
>>> For a while after I start my system, "eject /dev/srX" works just
>>> fine. However, after some non-determined period it stops working
>>> reliably. What I'm seeing is an annoying badly-reported error:
>>>
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>> eject: unable to eject, last error: Inappropriate ioctl for device
>>> sledge:/home/steve/iso# eject /dev/sr1
>>>
>>> After the fourth attempt here, the eject call works. I've tried
>>> hitting the eject button on the drive itself, but no joy. 
>>>
>>> As to reporting ENOTTY, that's just *wrong*.
>>>
>>> Running the same under strace, I can see a silliness here that is the cause:
>>>
>>> open("/dev/sr1", O_RDONLY|O_NONBLOCK)   = 3
>>> ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)
>>> ioctl(3, SG_GET_VERSION_NUM, 0x7fff2e8f387c) = 0
>>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], 
>>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, 
>>> status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, 
>>> resid=0, duration=0, info=0}) = 0
>>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], 
>>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, 
>>> status=02, masked_status=01, sb[18]=[70, 00, 02, 00, 00, 00, 00, 0a, 3a, 
>>> 00, bb, 00, 3a, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, 
>>> resid=0, duration=4, info=0x1}) = 0
>>> ioctl(3, FDEJECT, 0x7fff2e8f38b8)   = -1 ENOTTY (Inappropriate ioctl 
>>> for device)
>>> ioctl(3, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or 
>>> SNDCTL_MIDI_MPUMODE, 0x7fff2e8f3890) = -1 ENOTTY (Inappropriate ioctl for 
>>> device)
>>>
>>> For some daft reason, eject looks to be trying ioctl(CDROMEJECT),
>>> getting EIO as a failure mode, then falling back to ioctl(FDEJECT) on
>>> the CD drive. That last failure is the cause for the ENOTTY error, and
>>> that is reported incorrectly instead of the EIO that is the first (and
>>> correct) error.
>>>
>>> -- System Information:
>>> Debian Release: 7.5
>>>  APT prefers stable
>>>  APT policy: (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/bash
>>>
>>> Versions of packages eject depends on:
>>> ii  libc6   2.13-38+deb7u1

Bug#942746: closed by Mattia Rizzolo (Bug#942746: fixed in libsoxr 0.1.3-2)

[John Paul Adrian Glaubitz]

Control: reopen -1

Reopening this since the patch was dropped.

I'll try to come up with a better patch in the future.

Adrian

-- 
 .''`.  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#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Hi Sudip,

On Wed, May 6, 2020 at 12:32 PM Sudip Mukherjee 
wrote:

> On Wed, May 06, 2020 at 04:54:22PM +0100, Sudip Mukherjee wrote:
>
> > Taking the source from:
> > https://code.google.com/archive/p/java-diff-utils/source/default/source
> > the packaging was fairly simple and if noone has already done it I can
> > finalize it and upload to mentors and change this to ITP at the same
> time.
>

That would be great! It would be best to have someone from the Java Team
review/sponsor but, if none of them are available, I am willing to do that.

fwiw, I did a diff and its the same source in the linked jar and the
> link I gave. Also, looking at java-diff-utils that Andrej mentioned, is
> actually a fork from the google code.
>

Thanks for doing that extra check and good to know! The fork (as well as
the line vs character thing) would probably be good to mention in the
package description so it's clear for everyone. I'd also consider adding
the "google" at the front of the package name (or something else) to easily
distinguish it from the one already in the repository and prevent confusion
from users.

-Olek

Bug#959891: postgresql-client-12: pgbench is in the wrong package

[Ben Harris]

Package: postgresql-client-12
Version: 12.2-4
Severity: normal

Dear Maintainer,

The "pgbench" program doesn't seem to be in the postgresql-client-12
package, being instead in postgresql-12, the server package.  I think
this is probably a mistake: pgbench is listed as a "client application"
here:

https://www.postgresql.org/docs/12/reference-client.html

If I install postgresq-12, I can use pgbench against a remote database,
so it looks like it does indeed work correctly as a client.

I think this came about because pgbench used to be part of
postgresql-contrib-10, and it got merged into the wrong package when
postgresql-contrib-10 was abolished.

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

Kernel: Linux 5.6.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postgresql-client-12 depends on:
ii  libc6 2.30-4
ii  libedit2  3.1-20191231-1
ii  libpq512.2-4
ii  postgresql-client-common  214
ii  sensible-utils0.0.12+nmu1
ii  zlib1g1:1.2.11.dfsg-2

postgresql-client-12 recommends no packages.

Versions of packages postgresql-client-12 suggests:
ii  postgresql-12  12.2-4
pn  postgresql-doc-12  

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#959883: gnome-shell: randomly crashes: Object St.Bin (0x__________), has been already deallocated

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 06 May 2020 at 11:25:09 -0300, Antonio Terceiro wrote:
> fev 03 19:12:36 lemur gnome-shell[2647]: Object St.Bin (0x55c46a33e8b0), has 
> been already deallocated — impossible to set any property on it. This might 
> be caused by the object having been destroyed from C code using something 
> such as destroy(), dispose(), or remove() vfuncs.

Are you using any Shell extensions? If yes, does this persist when you
disable them?

Does the actual crash appear in your system log? Those messages might
point towards the root cause, but they're warnings rather than fatal
errors: the actual crash should also be logged. (It might be attributed
to the kernel rather than gnome-shell, depending on the type of crash,
and might require reading the system log as root rather than as an
ordinary user.)

If you have, or can install, systemd-coredump, that would be a useful
way to get a C backtrace.

smcv

Bug#753821: closed by atzlinux (bugreport is too old)

[atzlinux 肖盛文]

please use bugreport to report it again.

The code isn't change,this it true.But others all
changed,hardware,kernel,OS,etc,.

this bug close at first.


在 2020/5/6 下午8:39, Steve McIntyre 写道:
> Control: reopen -1
>
> Sorry, not good enough - you don't get to close a bug just because
> it's "too old". The code hasn't changed and still has the same
> problem; I've just looked in your latest upload.
>
> Steve
>
> On Sat, May 02, 2020 at 01:51:03AM +, Debian Bug Tracking System wrote:
>> This is an automatic notification regarding your Bug report
>> which was filed against the eject package:
>>
>> #753821: eject fails on CD/DVD drive and reports wrong error
>>
>> It has been closed by atzlinux .
>>
>> Their explanation is attached below along with your original report.
>> If this explanation is unsatisfactory and you have not received a
>> better one in a separate message then please contact atzlinux 
>>  by
>> replying to this email.
>>
>>
>> -- 
>> 753821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753821
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>> From: atzlinux 
>> To: 753821-d...@bugs.debian.org
>> Date: Sat, 2 May 2020 09:43:33 +0800
>> Subject: bugreport is too old
>> Message-ID: <9500528e-db80-3276-ed3e-1fdfad2a3...@sina.com>
>>
>>
>> -- 
>> 肖盛文 Faris Xiao
>> 微信：atzlinux
>> ＱＱ：909868357
>> 铜豌豆 Linux 
>> 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
>>
>
>
>
>> From: Steve McIntyre 
>> To: Debian Bug Tracking System 
>> Date: Sat, 05 Jul 2014 14:17:42 +0100
>> Subject: eject fails on CD/DVD drive and reports wrong error
>> Message-ID: <20140705131742.28987.94205.report...@sledge.mossbank.org.uk>
>>
>> Package: eject
>> Version: 2.1.5+deb1+cvs20081104-13
>> Severity: important
>>
>> I should have reported this ages ago, sorry. :-(
>>
>> I've got a system with several CD/DVD drives in it, and they all show
>> the same behaviour. I think there's a kernel bug with CD locking at
>> the root of the main problem here, and I'll report another bug there.
>>
>> For a while after I start my system, "eject /dev/srX" works just
>> fine. However, after some non-determined period it stops working
>> reliably. What I'm seeing is an annoying badly-reported error:
>>
>> sledge:/home/steve/iso# eject /dev/sr1
>> eject: unable to eject, last error: Inappropriate ioctl for device
>> sledge:/home/steve/iso# eject /dev/sr1
>> eject: unable to eject, last error: Inappropriate ioctl for device
>> sledge:/home/steve/iso# eject /dev/sr1
>> eject: unable to eject, last error: Inappropriate ioctl for device
>> sledge:/home/steve/iso# eject /dev/sr1
>>
>> After the fourth attempt here, the eject call works. I've tried
>> hitting the eject button on the drive itself, but no joy. 
>>
>> As to reporting ENOTTY, that's just *wrong*.
>>
>> Running the same under strace, I can see a silliness here that is the cause:
>>
>> open("/dev/sr1", O_RDONLY|O_NONBLOCK)   = 3
>> ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)
>> ioctl(3, SG_GET_VERSION_NUM, 0x7fff2e8f387c) = 0
>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], 
>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, status=00, 
>> masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, 
>> duration=0, info=0}) = 0
>> ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], 
>> mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=1, flags=0, status=02, 
>> masked_status=01, sb[18]=[70, 00, 02, 00, 00, 00, 00, 0a, 3a, 00, bb, 00, 
>> 3a, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, 
>> duration=4, info=0x1}) = 0
>> ioctl(3, FDEJECT, 0x7fff2e8f38b8)   = -1 ENOTTY (Inappropriate ioctl for 
>> device)
>> ioctl(3, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or 
>> SNDCTL_MIDI_MPUMODE, 0x7fff2e8f3890) = -1 ENOTTY (Inappropriate ioctl for 
>> device)
>>
>> For some daft reason, eject looks to be trying ioctl(CDROMEJECT),
>> getting EIO as a failure mode, then falling back to ioctl(FDEJECT) on
>> the CD drive. That last failure is the cause for the ENOTTY error, and
>> that is reported incorrectly instead of the EIO that is the first (and
>> correct) error.
>>
>> -- System Information:
>> Debian Release: 7.5
>>  APT prefers stable
>>  APT policy: (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>>
>> Versions of packages eject depends on:
>> ii  libc6   2.13-38+deb7u1
>> ii  libdevmapper1.02.1  2:1.02.74-8
>>
>> eject recommends no packages.
>>
>> Versions of packages eject suggests:
>> ii  cdtool  2.1.8-release-2
>> pn  setcd   
>>
>> -- no debconf information

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




signature.asc
Description: OpenPGP digital signature

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-05-06 at 10:43 -0400, Aaron M. Ucko wrote:
> Package: hardening-runtime
> Version: 2
> Severity: normal
> 
> systemd services specifying PrivateUsers=yes (upower for a while, now
> also uuidd from uuid-runtime) have been failing with
> 
>   Failed to set up user namespacing: No space left on device
> 
> which I eventually tracked down to this package's specification of
> 
>   user.max_user_namespaces = 0
> 
> in /usr/lib/sysctl.d/10-hardening.conf.  Could you please consider
> lifting this restriction, or at least blocking user namespaces only
> for unprivileged users via an explicit
> 
>   kernel.unprivileged_userns_clone = 0
> 
Hi Aaron, thanks for the bug report. Note that
kernel.unprivileged_userns_clone is already set to 0 by default so it's not
really needed here.

I'm not a fan of lifting the max_user_namespace restriction here since it's
there as runtime hardening. I can understand the pain with PrivateUsers but I
still don't think exposing root-designed kernel code to unprivileged users is
a good idea.

hardening-runtime is not installed by default so admins installing it are
supposed to understand what they do. They can also locally override the
restriction if needed (for example set it to 1 or 2).

In the end I leave the bug open for now but I'm not really inclined to change
it.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl6y51MACgkQ3rYcyPpX
RFuiUQgAvVnPtCPIGNEbDDUm31GkLmNmzbkBIokzIcVBFCnpyGcq0PhfYpFDSwvQ
A5QpbO1/OWbnXjJwW9tqebSm0e/lic2Jgbluk1I7Fv+kPJVCLrSvRmJ+d/FtEAC/
J4ciaWC2dGn/TUK2YSjcivuN89TvMCwPwOJEVS5ARMcgQHAOFV4M4xu8EENYYxY6
HHYPomZ0em6oivBrbTMj48TABB/o7j/0dGfLR3SEnTyWs/8abq31wM0FjurvoK7v
h7zpnpKoPo8f4mSsUO25RCCAuFD8tWgnwHLIe9GJR7qtvbFXXJHOtoClWCCasfgw
/4Hqqh3Z8AsApQJubSSKSgCAMv/gbA==
=PhJf
-END PGP SIGNATURE-

Bug#919315: geeqie: Orientation keys ('[' and ']') don't work in latest geeqie release

[Andreas Ronnquist]

fixed 919315 1:1.5.1-2
thanks

No reply for more than half a year, I assume that the upload fixed the
problem.

best
-- Andreas Rönnquist
gus...@debian.org

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Sudip Mukherjee]

On Wed, May 06, 2020 at 04:54:22PM +0100, Sudip Mukherjee wrote:
> On Wed, May 06, 2020 at 10:22:03AM -0400, Olek Wojnar wrote:
> > Oops, dropped bug email...
> > 
> > -- Forwarded message -
> > From: Olek Wojnar 
> > Date: Wed, May 6, 2020 at 10:21 AM
> > Subject: Re: RFP: diffutils-java -- Implementation of general operations
> > with diff files
> > To: Andrej Shadura 
> > 
> > 
> > Hi Andrej,
> > 
> > Thanks for bringing up this point!
> > 
> > Based on Yun Peng's comment, would it be better if we disambiguated this
> > package by calling it "google-diffutils-java" instead? Maybe mention the
> > line vs character thing as well in the description?
> 
> Taking the source from:
> https://code.google.com/archive/p/java-diff-utils/source/default/source
> the packaging was fairly simple and if noone has already done it I can
> finalize it and upload to mentors and change this to ITP at the same time.
> 
> Please let me know if I have mistaken and that link was not the source
> for this package.

fwiw, I did a diff and its the same source in the linked jar and the
link I gave. Also, looking at java-diff-utils that Andrej mentioned, is
actually a fork from the google code.

--
Regards
Sudip

Bug#959890: buster-pu: package confget/2.2.0-4+deb10u1

[Peter Pentchev]

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

Hi,

First of all, thanks for all your work on keeping Debian sane!

The Python implementation in the confget package had an upstream bug in
parsing values containing an equal sign, as explained in
https://bugs.debian.org/959887 and fixed in confget/2.3.4-1 in unstable
and testing.

Attached is a debdiff updating the buster package of confget with two
patches, one of them introducing a test for this and another one fixing
the bug in the Python implementation. Here's the changelog entry, just
in case:

confget (2.2.0-4+deb10u1) buster; urgency=medium

  * Fix the Python module's handling of values containing "=":
- add the test-ini-eq patch to add a test for such values
- add the python-value-eq patch to fix the problem
- Closes: #959887

 -- Peter Pentchev   Wed, 06 May 2020 19:12:09 +0300

Also available at https://gitlab.com/confget/confget/-/tree/debian/buster

Thanks in advance, and keep up the great work!

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
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
diff -Nru confget-2.2.0/debian/changelog confget-2.2.0/debian/changelog
--- confget-2.2.0/debian/changelog  2019-02-27 00:44:26.0 +0200
+++ confget-2.2.0/debian/changelog  2020-05-06 19:12:09.0 +0300
@@ -1,3 +1,12 @@
+confget (2.2.0-4+deb10u1) buster; urgency=medium
+
+  * Fix the Python module's handling of values containing "=":
+- add the test-ini-eq patch to add a test for such values
+- add the python-value-eq patch to fix the problem
+- Closes: #959887
+
+ -- Peter Pentchev   Wed, 06 May 2020 19:12:09 +0300
+
 confget (2.2.0-4) unstable; urgency=medium
 
   * Use the test-name autopkgtest feature.
diff -Nru confget-2.2.0/debian/patches/python-value-eq.patch 
confget-2.2.0/debian/patches/python-value-eq.patch
--- confget-2.2.0/debian/patches/python-value-eq.patch  1970-01-01 
02:00:00.0 +0200
+++ confget-2.2.0/debian/patches/python-value-eq.patch  2020-05-06 
19:10:56.0 +0300
@@ -0,0 +1,17 @@
+Description: python: fix processing of values containing "=".
+Bug-Debian: https://bugs.debian.org/959887
+Origin: upstream; 
https://gitlab.com/confget/confget/-/commit/41b3a97b3d14a2b2f4365cc3fb4e5ea2497fe58c
+Author: Peter Pentchev 
+Last-Update: 2020-05-06
+
+--- a/python/confget/backend/ini.py
 b/python/confget/backend/ini.py
+@@ -141,7 +141,7 @@
+ regex=re.compile(r'''
+ ^
+ \s*
+-(?P \S+ )
++(?P [^\s=]+ )
+ \s* = \s*
+ (?P .*? )
+ \s*
diff -Nru confget-2.2.0/debian/patches/series 
confget-2.2.0/debian/patches/series
--- confget-2.2.0/debian/patches/series 2019-02-27 00:44:26.0 +0200
+++ confget-2.2.0/debian/patches/series 2020-05-06 19:08:23.0 +0300
@@ -1,2 +1,4 @@
 python-no-executable.patch
 test-too-many-pypy.patch
+test-ini-eq.patch
+python-value-eq.patch
diff -Nru confget-2.2.0/debian/patches/test-ini-eq.patch 
confget-2.2.0/debian/patches/test-ini-eq.patch
--- confget-2.2.0/debian/patches/test-ini-eq.patch  1970-01-01 
02:00:00.0 +0200
+++ confget-2.2.0/debian/patches/test-ini-eq.patch  2020-05-06 
19:08:23.0 +0300
@@ -0,0 +1,78 @@
+Description: Add a test for INI files with values containing "=".
+Origin: upstream; 
https://gitlab.com/confget/confget/-/commit/48c7942c59ec67ea0d9e670d8ef18d12054356d3
+Author: Peter Pentchev 
+Last-Update: 2020-05-06
+
+--- a/t/01-get-values.t
 b/t/01-get-values.t
+@@ -27,13 +27,18 @@
+ [ -z "$CONFGET" ] && CONFGET='./confget'
+ [ -z "$TESTDIR" ] && TESTDIR='t'
+ 
+-echo '1..18'
++echo '1..19'
+ 
+ 
+ if [ ! -f "$TESTDIR/t1.ini" ]; then
+ echo "Bail out!  No test file $TESTDIR/t1.ini"
+ exit 255
+ fi
++
++if [ ! -f "$TESTDIR/t4.ini" ]; then
++echo "Bail out!  No test file $TESTDIR/t4.ini"
++exit 255
++fi
+ v=`$CONFGET '-f' "$TESTDIR/t1.ini" '-s' 'a' 'key1' `
+ res="$?"
+ if [ "$v" = 'value1' ]; then echo 'ok 1'; else echo "not ok 1 v is '$v'"; fi
+@@ -88,3 +93,6 @@
+ v=`env Q1='key4key5=%09%09%20val%27ue5' Q2='' 
QUERY_STRING='key1=value1=%3Dvalue2%26key3=%09%09%20val%27ue3' 
$CONFGET -t http_get '-s' 'Q2' 'key66' `
+ res="$?"
+ if [ "$v" = '' ]; then echo 'ok 18'; else echo "not ok 18 v is '$v'"; fi
++v=`$CONFGET '-f' "$TESTDIR/t4.ini" '-s' 'x' 'key8' `
++res="$?"
++if [ "$v" = 'key9=key10=key11' ]; then echo 'ok 19'; else echo "not ok 19 v 
is '$v'"; fi
+--- a/t/defs/tests/01-get-values.json
 

Bug#959874: locales: default date format for en_DK and other en_* should be improved

[Aurelien Jarno]

On 2020-05-06 17:47, Vincent Lefevre wrote:
> On 2020-05-06 16:12:58 +0200, Aurelien Jarno wrote:
> > On 2020-05-06 13:52, Vincent Lefevre wrote:
> > > Package: locales
> > > Version: 2.30-5
> > > Severity: wishlist
> > > 
> > > I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
> > > written with digits. But the default date format seems to be the
> > > same one as LC_TIME=C and should be improved. This has currently
> > > been done only for US:
> > 
> > Please note that the en_US change is controversial and likely going to
> > be reverted. See https://sourceware.org/bugzilla/show_bug.cgi?id=25923
> 
> I'm not sure whether this is the same thing as this one focuses
> on day/month ordering, but there's the place of the year (which
> was actually the main thing I was thinking about).

Nope, this one indeed complains about the day/month ordering, but given
all the date part is going to be revert, the place of the year will also
be reverted.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#959887: [confget/python] Misparses INI file values containing an equal sign

[Peter Pentchev]

On Wed, May 06, 2020 at 06:47:43PM +0300, Peter Pentchev wrote:
> Source: confget
> Version: 2.2.0-1
> Severity: important
> Tags: upstream patch
> 
> Control: notfound -1 2.3.4-1
> 
> Hi,
> 
> This bug report will serve mainly to justify a stable upload of confget
> that fixes the parsing of values containing "=" in INI files.
> The problem was fixed upstream in version 2.3.4 and so is not present in
> unstable and testing.
[snip]
> 
> The fix is trivially backported from the upstream source; I will provide
> it as a justification for a stable upload shortly.

The fix is available at
https://gitlab.com/confget/confget/-/tree/debian/buster

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#959888: node-webpack-merge: Build with babel version 7

[Pirate Praveen]

Package: node-webpack-merge
Version: 2.2.0-3
Severity: important
Control: tags -1 patch

Babel 6 will be replaced by Babel 7 (node-babel7) in bullseye. I have 
fixed this package to build with babel 7 in babel7 branch.


https://salsa.debian.org/js-team/node-webpack-merge/-/commit/cc5278be5984276da2fd620e7c2744f1acdf1b21

Bug#959889: python3-sphinx-gallery: AttributeError: 'URLError' object has no attribute 'url'

[Ole Streicher]

Package: sphinx-gallery
Version: 0.5.0
Severity: serious
Tags: affects -1 src:astropy

Dear maintainer,

when I try to use sphinx-gallery to build the new astropy package, I get
the following error from sphinx-gallery:

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx_gallery/docs_resolv.py",
line 260, in _handle_http_url_error
msg, e.url, extra, e.msg)
AttributeError: 'URLError' object has no attribute 'url'

The reason seems to be that urllib.error.URLError indeed has no such
attribute (anymore?) on Python 3.8

This seem fixed upstream and could probvably be solved by uploading a
new version.

Best regards

Ole

Bug#959887: [confget/python] Misparses INI file values containing an equal sign

[Peter Pentchev]

Source: confget
Version: 2.2.0-1
Severity: important
Tags: upstream patch

Control: notfound -1 2.3.4-1

Hi,

This bug report will serve mainly to justify a stable upload of confget
that fixes the parsing of values containing "=" in INI files.
The problem was fixed upstream in version 2.3.4 and so is not present in
unstable and testing.

The problem may be reproduced trivially:

# Create a test.ini file containing a weird key/value pair
(buster-amd64)root@straylight:/cftest# cat > test.ini
[whee]
key=value=another=third

# The C implementation finds a variable named "key" with the weird value
(buster-amd64)root@straylight:/cftest# confget -f test.ini -s whee key
value=another=third

# The Python implementation finds the "whee" section, but then finds
# a variable named "key=value=another" inside
(buster-amd64)root@straylight:/cftest# python3 -c 'import confget; ccfg = 
confget.Config([], filename="test.ini"); cbak = confget.BACKENDS["ini"](ccfg); 
print(repr(cbak.read_file()))'
{'': {}, 'whee': {'key=value=another': 'third'}}
(buster-amd64)root@straylight:/cftest#

The fix is trivially backported from the upstream source; I will provide
it as a justification for a stable upload shortly.

G'luck,
Peter

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
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

-- no debconf information


signature.asc
Description: PGP signature

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Sudip Mukherjee]

On Wed, May 06, 2020 at 10:22:03AM -0400, Olek Wojnar wrote:
> Oops, dropped bug email...
> 
> -- Forwarded message -
> From: Olek Wojnar 
> Date: Wed, May 6, 2020 at 10:21 AM
> Subject: Re: RFP: diffutils-java -- Implementation of general operations
> with diff files
> To: Andrej Shadura 
> 
> 
> Hi Andrej,
> 
> Thanks for bringing up this point!
> 
> Based on Yun Peng's comment, would it be better if we disambiguated this
> package by calling it "google-diffutils-java" instead? Maybe mention the
> line vs character thing as well in the description?

Taking the source from:
https://code.google.com/archive/p/java-diff-utils/source/default/source
the packaging was fairly simple and if noone has already done it I can
finalize it and upload to mentors and change this to ITP at the same time.

Please let me know if I have mistaken and that link was not the source
for this package.

--
Regards
Sudip