Bug#951050: Please add a systemd timer for the maintainance task

[Laurent Bigonville]

Le 10/02/20 à 23:00, Eduard Bloch a écrit :

Hallo,
* Laurent Bigonville [Mon, Feb 10 2020, 01:25:28PM]:

Package: apt-cacher-ng
Version: 3.3.1-2
Severity: wishlist

Hi,

It would be nice if a systemd time could be added to replace the daily
cronjob for the maintenance task.

And why so?


In general, .timer/.service are natively run by systemd (no need of 
extra cron deamon), are also scheduled on people machines that are not 
running all the time (without requiring extra packages like anacron), 
one place to look at if you are using systemd instead of multiple places...


Getting rid of crond/anacron/at might also become a goal for some people 
in the future as they are dead/unmaintained upstream and/or in debian.





Would be nice as well if the task was not running as apt-cacher-ng user
(with a User= in the .service file).

And why exactly?


Long story, I'm writing a SELinux policy[0] for apt-cacher-ng, the fact 
that acngtool is running as root and the fact that the socket 
(/run/apt-cacher-ng/socket) is owned by apt-cacher-ng user/group and 
that root has no direct r/w permission on it, requires me to give a too 
broad permission (dac_override) to the domain. Not running it as root 
might solve this for me.


So if you can ensure that the cronjob (or at least the call to acngtool 
maint) is run as apt-cacher-ng user, I might also be happy. I tried with 
setpriv(1) to drop the call to the acng user, that works to remove the 
dac_override privilege but requires two other (less problematic) 
permissions.



You seem to have a mission. Please show a Debian wiki page or something
similar to motivate me. At the moment I see no benefits, all that sounds
like just enforcing a systemd specific solution without need.
To be clear, I was more talking about adding a .timer and make the 
existing cronjob exit if systemd is used.

The actual plan of mine was to get rid of the cron jobs whatsoever. Run
the required tasks not based on a dumb time plan but purely based on the
collected information.

That might be indeed be better, see above.

That also applies to the access logs, they would
be migrated to a database (systemd fans might also try to advocate here
but I still have not seen the benefits of its log storage).


Not too sure why using a database here would be better, access logs are 
already rotated by logrotate apparently which is still quite commonly 
used and they look already machine readable.


Not sure anybody is advocating to move apache accesslogs to journald

[0] https://github.com/SELinuxProject/refpolicy/pull/137/files

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Control: clone -1 -2
Control: reassign -2 apt-listchanges
Control: severity -2 important
Control: retitle -2 apt-listchanges doesn't show NEWS entries

On Sun, 19 May 2019 13:55:39 +0200 Michael Biebl  wrote:
> Am 19.05.19 um 13:43 schrieb Guido Günther:
> 
> > On Sat, May 18, 2019 at 01:20:05PM +0200, Michael Biebl wrote:
> 
> >> https://salsa.debian.org/systemd-team/systemd/commit/e3772a013721083a740ab9dedbf060cf5b3c3709
> >> but either I made a mistake or apt-listchanges is buggy, since on none
> >> of my systems this NEWS entry was shown.
> >>
> >> Any ideas?
> > 
> > I can at least confirm that I didn't see the new entry when upgrading
> > udev. The NEWS entry looks correct though and apt-listchanges seems to
> > think it showed it:
> > 
> > # apt-listchanges --profile=apt --dump-seen | grep systemd
> > libconfig-model-systemd-perl 0.239.1-1
> > systemd 241-4
> > 
> 
> I wonder if apt-listchanges gets confused, if a src package ships
> multiple (different) NEWS files in different binary packages.
> 
> I just made a dist-upgrade of a test VM from stretch to buster, and
> noticed that quite a few NEWS entries were missing / not shown.
> E.g. the 2.29.2-3 news entry for the "mount" package (built from
> src:util-linux) was missing as well. So seems to a general problem.
> 
> Looks like a rather important bug in apt-listchanges to me.


Cloning and re-assigning the bug, so this can be investigated on the
apt-listchanges side. Seems something worthwile to fix.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#951104: ITP: node-markdown-it -- FIX_ME write the Debian package description

[Sakshi Sangwan]

Package: markdown-it
Severity: wishlist
Owner: Sakshi Sangwan 

* Package name: node-markdown-it
  Version : 10.0.0
  Upstream Author : Vitaly Puzrin, Alex Kocharin
* URL : https://github.com/markdown-it/markdown-it#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Fast and easy to extend markdown parser

 Follows the CommonMark spec, adds syntax extensions and sugar (URL
 autolinking, typographer). Provides configurable syntax, can add new
 rules and even replace existing ones, and high speed
 .
 Node.js is an event-based server-side JavaScript engine.

This is a dependency of Gitlab.

Best,
Sakshi

Bug#860416: digikam: can't switch map source

[Steven Robbins]

On Monday, February 10, 2020 7:08:17 P.M. CST Christoph Anton Mitterer wrote:
> On Mon, 2020-02-10 at 12:56 +0100, Agustin Martin wrote:
> > Triaging some Debian bugs. Tried to reproduce this problem with
> > digikam
> > 4:6.4.0+dfsg-2 (currently in sid) but switching maps seems to work.
> > Is this
> > still a problem for you?
> 
> I've just tried with the same version and unfortunately it still
> doesn't work here.
> Whatever I choose it stays at OSM.

I can't reproduce the problem.Here's what I tried:

- run digikam 6.4.0-3 from sid
- under the map view, click the first icon on the left (small globe)
- a menu comes up showing "Marble Virtual Globe" selected in the first section
  and "Atlas Map" selected in the second section

- I select "Google Maps" instead
  - display changes to google maps
  - console output shows

digikam.geoiface: "setting backend googlemaps"
digikam.geoiface: located data: QUrl("file:///usr/share/digikam/geoiface/
backend-googlemaps.html")
digikam.geoiface: "ROADMAP"
... snipped ...

I can switch between 4 kinds of google maps: roadmap / satellite / hybrid / 
terrain.

Do you see the same set of options?
What shows up on the console when you try this?

-Steve


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

Bug#951093: libmypaint: please package v2.0.0-beta.0

[Jesper Lloyd]

Speaking as the current de facto mypaint/libmypaint maintainer, I
would advice against this, because MyPaint 2.0 will depend on
libmypaint 1.5.0 and not libmypaint-2.0. This is a fairly recent
development, though it's been discussed for a few weeks:
https://github.com/mypaint/libmypaint/releases/tag/v1.5.0-beta.0

v1.5.0 will be released shortly, and MyPaint 2.0 shortly after (today
or tomorrow).

Den tis 11 feb. 2020 kl 04:06 skrev Sandro Tosi :
>
> Source: libmypaint
> Severity: wishlist
>
> Hello,
> in order to be able to upgrade mypaint to the latest beta version (which
> supports python3), we need an up-to-date libmypaint:
>
> https://github.com/mypaint/mypaint/releases/tag/v2.0.0-beta.0
>
> could you please prepare such an upload (maybe in experimental to begin with?)
>
> Thanks,
> Sandro

Bug#951103: ITP: libedevplus -- Easy-to-use event device library in C++

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: libevdevPlus
  Version : v0.1.0
  Upstream Author : YukiWorkshop
* URL : https://github.com/YukiWorkshop/libevdevPlus
* License : MIT
  Programming Lang: C++
  Description : Easy-to-use event device library in C++

I am packaging this as it is required for ydotool

Cheers,

--
Alexandre Viau
av...@debian.org

Bug#951102: iptables-restore empty line not accepted any more (regression)

[halfdog]

Package: iptables
Version: 1.8.4-2
Severity: grave
Tags: security

After upgrading from "1.8.3-2", iptables-restore handles empty
lines differently and does not restore the rules. Thus old rulesets
stored with save and then annotated for better readability (to
avoid loads of "iptables -A" calls), do not load any more.

As firewall data is ignored, this might break network access
to machines or have unknown security impact on the current firewall
ruleset.

# iptables-restore --noflush < *nat
> 
> -A POSTROUTING -s 10.0.0.0/16 -o usb0 -j SNAT --to-source 192.168.0.1
> COMMIT
> *filter
> 
> -A INPUT -p tcp -m tcp --dport 22 -j DROP
> COMMIT
> EOF
iptables-restore: COMMIT expected at line 2


# iptables-restore --noflush < *nat
> -A POSTROUTING -s 10.0.0.0/16 -o usb0 -j SNAT --to-source 192.168.0.1
> COMMIT
> *filter
> 
> -A INPUT -p tcp -m tcp --dport 22 -j DROP
> COMMIT
> EOF
iptables-restore: COMMIT expected at line 5

Bug#839961: libjs-d3: please package new upstream release

[GCS]

On Wed, Jan 15, 2020 at 3:51 PM Balint Reczey
 wrote:
> I'd like to have a fresh d3 in next Ubuntu LTS and also in Bullseye,
> but I don't have enough free time now to salvage the package myself.
> :-(
 Just for the record, did a quick check for the current situation.
Most important JavaScript dependencies are packaged and seems new
enough (not always the latest upstream version but lagging behind).
The eslint[1] need to enter the normal archive as it's only in
experimental only. Then rollup-plugin-terser[2] should be packaged,
even if it doesn't look like a hard dependency.
D3.js can be packaged via the following packages.
1) d3-array, d3-color, d3-dsv, d3-ease, d3-path, d3-polygon, d3-queue,
d3-selection, d3-time, d3-timer, d3-voronoi
2) d3-collection, d3-contour, d3-fetch, d3-format, d3-interpolate,
d3-quadtree, d3-random, d3-shape, d3-time-format
3) d3-geo, d3-scale, d3-hierarchy, d3-scale, d3-scale-chromatic, d3-transition
4) d3 itself

Not needed ATM: d3-cam16, d3-delaunay, d3-force, d3-geo-polygon,
d3-geo-projection, d3-hcg, d3-hexbin, d3-hsv, d3-request, d3-require,
d3-sankey, d3-scripts, d3-selection-multi, d3-tile, d3-zoom

Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/eslint
[2] https://www.npmjs.com/package/rollup-plugin-terser

Bug#951101: cracklib2 FTBFS: debian/rules:6: /usr/share/python/python.mk: No such file or directory

[Helmut Grohne]

Source: cracklib2
Version: 2.9.6-3.1
Severity: serious
Tags: patch ftbfs

cracklib2 fails to build from source, because debian/rules includes a
non-existent python.mk file:

| debian/rules:6: /usr/share/python/python.mk: No such file or directory

The file should be /usr/share/python3/python.mk now and it should be
conditional to the nopython profile.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru cracklib2-2.9.6/debian/changelog 
cracklib2-2.9.6/debian/changelog
--- cracklib2-2.9.6/debian/changelog2019-11-19 16:14:51.0 +0100
+++ cracklib2-2.9.6/debian/changelog2020-02-11 07:09:52.0 +0100
@@ -1,3 +1,10 @@
+cracklib2 (2.9.6-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with missing python.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 11 Feb 2020 07:09:52 +0100
+
 cracklib2 (2.9.6-3.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff --minimal -Nru cracklib2-2.9.6/debian/rules cracklib2-2.9.6/debian/rules
--- cracklib2-2.9.6/debian/rules2019-11-19 16:14:51.0 +0100
+++ cracklib2-2.9.6/debian/rules2020-02-11 07:09:50.0 +0100
@@ -3,13 +3,13 @@
 DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
-include /usr/share/python/python.mk
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
 include /usr/share/dpkg/architecture.mk
 
 ifeq ($(filter stage1,$(DEB_STAGE))$(filter nopython,$(DEB_BUILD_PROFILES)),)
+include /usr/share/python3/python.mk
 PY3VERS := $(shell py3versions -vs)
 DH_WITH_PARAMETERS := python3
 else

Bug#951044: Revdeps which use the typelib FTBFS: dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency

[Nicolas Mora]

Le 20-02-10 à 06 h 02, Iain Lane a écrit :
> 
> Since this is breaking the build of reverse dependencies, I'm proposing
> to NMU a fix to DELAYED/5. The debdiff is attached. Feel free to fix it
> yourself sooner, though.
> 
Thanks for the patch, I apply it to the package now!

Bug#951099: ITP: libuInputPlus -- Easy-to-use uinput library in C++

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: libuInputPlus
  Version : v0.1.3
  Upstream Author : YukiWorkshop
* URL : https://github.com/YukiWorkshop/libuInputPlus
* License : MIT
  Programming Lang: C++
  Description : Easy-to-use uinput library in C++

I am packaging this as it is required for ydotool

Cheers,

--
Alexandre Viau
av...@debian.org

Bug#951098: ITP: ruby-rspec-puppet-facts -- Library containing facts from many Facter versions on many Operating Systems

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-rspec-puppet-facts
  Version : 1.10.0
  Upstream Author : Mickaël Canévet 
* URL : https://github.com/mcanevet/rspec-puppet-facts
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Library containing facts from many Facter versions on many 
Operating Systems

With this library, simplify your unit tests by looping on every supported
Operating System and populating facts (provided by facterdb). This simplifies
unit testing because you don't need to specify the facts yourself.

This library is very useful for writing tests when working on a puppet module.
It also makes it very fast to setup a CI environment for your modules.


This library is used by puppet-development-kit as a requirement in order to
provide an easier framework and workflow for puppet module development.


I intend to maintain this module within the ruby team and I will ask for
sponsorship within the team.

Bug#951097: ITP: ruby-spdx-licenses -- Library for looking up and identifying SPDX licences

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-spdx-licenses
  Version : 1.2.0
  Upstream Author : Dominic Cleal 
* URL : https://github.com/domcleal/spdx-licenses
* License : Expat
  Programming Lang: Ruby
  Description : Library for looking up and identifying SPDX licences

This library can lookup a list of SPDX licences on spdx.org, and provide them
as a list of information that can be handled by your code. You can also use
this to lookup whether a certain licence is an SPDX license or not, and thus
programatically identify certain licences in code or other structured
information.


This library is a dependency to metadata-json-lint, which in turn is needed
for packaging puppet-development-kit (pdk) which I'm working towards packaging.

I intend to maintain this within the ruby team, and will ask for a sponsor
within the team.

Bug#951096: RM: ukui-indicators -- ROM; no longer in use

[handsome_feng]

Package: ftp.debian.org
Severity: normal

Package: ftp.debian.org
Severity: normal

ukui-panel 2.0.0-1 provided the functionality of ukui-indicators, so the ukui-
indicators can be removed, and there should be no reverse-depends left since
ukui-panel "Provides: ukui-indicators", and after upgrade ukui-control-center
to 2.0.0-1 (which no longer depends on ukui-indicators, but blocked by
#948775), I will delete the entry in ukui-panel.

Thanks,
handsome_feng

Bug#950810: new upstream release(s)

[Daniel Echeverry]

Hi!

On Thu, Feb 06, 2020 at 02:59:46PM -0500, Antoine Beaupre wrote:
> Package: irssi-scripts
> Version: 20181120
> Severity: wishlist
> 
> irssi-scripts in Debian is fairly old. since 2018, a lot of things
> happened in that repository, and it seems a *lot* of scripts present
> on scripts.irssi.org are not present in the Debian package.
> 
> for example, I was particularly looking for the `go2.pl` script and
> while it's been on scripts.irssi.org since the beginning (or at least
> since the git import in 2014), it's not in the Debian package.
> 
> it seems the current debian package is based on the old
> scripts.irssi.org website, with only *some* of the scripts from the
> website present. but nowadays (since 2014) the upstream site is a
> static site generated from a git repository, which the debian package,
> in my opinion, should be based on.
> 
> would that make sense?
> 
> thanks!
> 

Yes, I agree with you, I will work in a new release.

Regards!


signature.asc
Description: PGP signature

Bug#951095: /usr/sbin/munin-run: munin-run: issue with `--property DropInPaths=...`

[Olivier Mehani]

Package: munin-node
Version: 2.0.56-1
Severity: normal
File: /usr/sbin/munin-run
Tags: upstream

Dear Maintainer,

This is a placeholder for the upstream bug, reported at 
https://github.com/munin-monitoring/munin/issues/1280.
The text of the issue follows below.

**Describe the bug**
Running on Debian Testing (bullseye-ish), recently upgraded to 2.0.56-1.

I have a drop-in systemd override to work around [the hardening 
bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939339) (maybe linked to 
#1273). This worked fine until 2.0.51-1 (and upgrading to .56 didn't fix it), 
setting `Protect-Home=read-only`.

Now, running plugins through `munin-run` fails with 
```
Warning: the execution of 'munin-run' via 'systemd-run' returned an 
error. This may either be caused by a problem with the plugin to be executed or 
a failure of the 'systemd-run' wrapper. Details of the latter can be found via 
'journalctl
```

**To Reproduce**
Steps to reproduce the behavior:
1. Install the drop-in 
`/etc/systemd/system/munin-node.service.d/protect-home.conf`
```
[Service]
# Work around [0]
# [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939339
ProtectHome=read-only
```
2. Use `munin-run` on any plugin
```
sudo -u munin  /usr/sbin/munin-run --debug uptime
```
3. `systemd-run` fails with message `Unknown assignment: 
DropInPaths=/etc/systemd/system/munin-node.service.d/protect-home.conf`
```
# Running 'munin-run' via 'systemd-run' with systemd properties based 
on 'munin-node.service'.
# Command invocation: systemd-run --collect --pipe --quiet --wait 
--property EnvironmentFile=/tmp/rBa_tVsxS5 --property UMask=0022 --property 
LimitCPU=infinity --property LimitFSIZE=infinity --property LimitDATA=infinity 
--property LimitSTACK=infinity --property LimitCORE=infinity --property 
LimitRSS=infinity --property LimitNOFILE=524288 --property LimitAS=infinity 
--property LimitNPROC=7566 --property LimitMEMLOCK=65536 --property 
LimitLOCKS=infinity --property LimitSIGPENDING=7566 --property 
LimitMSGQUEUE=819200 --property LimitNICE=0 --property LimitRTPRIO=0 --property 
LimitRTTIME=infinity --property SecureBits=0 --property 
'CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search 
cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap 
cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin 
cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_rawio 
cap_sys_chroot cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot 
cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config cap_mknod 
cap_lease cap_audit_write cap_audit_control cap_setfcap cap_mac_override 
cap_mac_admin cap_syslog cap_wake_alarm cap_block_suspend cap_audit_read' 
--property AmbientCapabilities= --property DynamicUser=no --property 
MountFlags= --property PrivateTmp=yes --property PrivateDevices=no --property 
ProtectKernelTunables=no --property ProtectKernelModules=no --property 
ProtectKernelLogs=no --property ProtectControlGroups=no --property 
PrivateNetwork=no --property PrivateUsers=no --property PrivateMounts=no 
--property ProtectHome=read-only --property ProtectSystem=full --property 
NoNewPrivileges=no --property LockPersonality=no --property 
MemoryDenyWriteExecute=no --property RestrictRealtime=no --property 
RestrictSUIDSGID=no --property RestrictNamespaces=no --property 
ProtectHostname=no --property 
DropInPaths=/etc/systemd/system/munin-node.service.d/protect-home.conf -- 
/usr/sbin/munin-run --ignore-systemd-properties --debug uptime
Unknown assignment: 
DropInPaths=/etc/systemd/system/munin-node.service.d/protect-home.conf
Warning: the execution of 'munin-run' via 'systemd-run' returned an 
error. This may either be caused by a problem with the plugin to be executed or 
a failure of the 'systemd-run' wrapper. Details of the latter can be found via 
'journalctl'.
```

**Expected behavior**
The plugin is run without issue. Perhaps the property `DropInPaths` 
should be excluded around 
https://github.com/munin-monitoring/munin/blob/debian/2.0.56-1/node/sbin/munin-run#L69
 ?

**Desktop (please complete the following information):**
 - OS+Distribution Version: Debian Testing (bullseye)
 - Munin Version 2.0.56-.1

**Additional context**
Drop-in systemd config to work around 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939339 installed at 
`/etc/systemd/system/munin-node.service.d/protect-home.conf`:
```
[Service]
# Work around [0]
# [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939339
ProtectHome=read-only
```


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

Bug#683671: dash: 'set -e'+'trap' malfunction is fixed in upstream git

[Robinson, Branden (Data61, Kensington NSW)]

tag 683671 - patch fixed-upstream
tag 779416 + patch fixed-upstream
thanks

Hi Vincent,

Er, it appears that I misunderstood the discussion in the bug history.

I had been fixing a bug where an INT signal handler improperly did not reraise 
INT against itself, and had Martin Cracauer's article on INT, QUIT and shell 
signal handlers[1] fresh in my brain.  When I addressed the bad signal handler 
issue I was startled that dash did not behave according to my expectations.

I prepared to file a bug against dash, and when scanning the existing bug list 
I found this one and, perhaps hastily, concluded that it was the same issue.

Re-reviewing the list of open bugs against dash, it looks like I should have 
stumbled across #779416 instead.

I apologize for my error.  Thanks for the clarification.

Cheers!

[1] https://www.cons.org/cracauer/sigint.html

--
G. Branden Robinson
Trustworthy Systems Group, CSIRO's Data61
"Every good idea will be discovered twice: once by a logician and once by a 
computer scientist." - Philip Wadler


From: Vincent Lefevre 
Sent: Tuesday, February 11, 2020 13:59
To: Robinson, Branden (Data61, Kensington NSW); 683671-qu...@bugs.debian.org
Cc: cont...@bugs.debian.org; 683...@bugs.debian.org; 
683671-submit...@bugs.debian.org; jcris...@debian.org
Subject: Re: Bug#683671: dash: 'set -e'+'trap' malfunction is fixed in upstream 
git

On 2020-02-11 02:36:32 +, Robinson, Branden (Data61, Kensington NSW) wrote:
> # hello, control, been a while...
> tag 683671 + patch fixed-upstream
> thanks
>
> Hi Andrej et al.,
>
> After independently encountering and then debugging this problem to the point 
> where I had a fix, I learned that Antonio Ospite had come up with an 
> identical one (modulus whitespace) over a year ago[1].  I've attached a copy.
>
> It really sucks that dash has had this bug for 12 years, given that:
> 1. It's Debian's default /bin/sh;
> 2. We're required by Policy to 'set -e' in our maintainer scripts[2]; and
> 3. Script authors generally don't write signal handlers for fun--they do it 
> because they need to clean up or roll back some activity, and this bug 
> utterly frustrates their efforts.
[...]

I don't see the relation with bug 683671.

--
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#951094: RFP: tides -- Taylor series Integrator for Differential EquationS

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: tides
  Version : 2.0
  Upstream Author : A. Abad, R. Barrio
* URL : https://sourceforge.net/projects/tidesodes/
* License : GPLv3
  Programming Lang: C, fortran
  Description : Taylor series Integrator for Differential EquationS

TIDES permits to integrate numerically ODE problems with double or multiple 
precision (using MPFR, and GMP libraries), that means that you can solve ODE 
problems up to any precision level in a reasonable computer time.
TIDES may solve directly sensitivity equations with respect to initial 
conditions or parameters up to any any order.
TIDES integrates by using the Taylor Series method with an optimized 
variable-stepsize and variable-order formulation, and extended formulas for 
variational equations.
The software has been done to be extremely easy to use: with MathTIDES we 
write, in a natural way, the ODE and their parameters, together with the 
parameters of the integration. Then, MathTIDES writes the C (Fortran) code, 
that, compiled and linked with libTIDES, integrates the ODE.
The derivatives and partial derivatives are obtained by using Automatic 
Differentiation (AD) techniques.
MathTIDES writes automatically the code to compute partial derivatives of the 
solution of the ODE with respect to any variable or parameter (using AD and 
avoiding the use of any variational equation or sensitivity with respect to the 
parameters).
TIDES may detect events of ODEs, i. e. points where a function of the solution 
of the ODE satisfies an event function, like it becomes zero or reaches an 
extremum.

Bug#951093: libmypaint: please package v2.0.0-beta.0

[Sandro Tosi]

Source: libmypaint
Severity: wishlist

Hello,
in order to be able to upgrade mypaint to the latest beta version (which
supports python3), we need an up-to-date libmypaint:

https://github.com/mypaint/mypaint/releases/tag/v2.0.0-beta.0

could you please prepare such an upload (maybe in experimental to begin with?)

Thanks,
Sandro

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

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

Bug#951092: RFP: topcom -- TOPCOM is a package for computing Triangulations Of Point Configurations and Oriented Matroids.

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: topcom
  Version : 0.17.8
  Upstream Author : Joerg Rambau 
* URL : http://www.rambau.wm.uni-bayreuth.de/TOPCOM/
* License : GPL
  Programming Lang: C++
  Description : TOPCOM is a package for computing Triangulations Of Point 
Configurations and Oriented Matroids.

It was very much inspired by the maple program PUNTOS, which was written by 
Jesus de Loera. TOPCOM is entirely written in C++, so there is a significant 
speed up compared to PUNTOS.

Bug#683671: dash: 'set -e'+'trap' malfunction is fixed in upstream git

[Vincent Lefevre]

On 2020-02-11 02:36:32 +, Robinson, Branden (Data61, Kensington NSW) wrote:
> # hello, control, been a while...
> tag 683671 + patch fixed-upstream
> thanks
> 
> Hi Andrej et al.,
> 
> After independently encountering and then debugging this problem to the point 
> where I had a fix, I learned that Antonio Ospite had come up with an 
> identical one (modulus whitespace) over a year ago[1].  I've attached a copy.
> 
> It really sucks that dash has had this bug for 12 years, given that:
> 1. It's Debian's default /bin/sh;
> 2. We're required by Policy to 'set -e' in our maintainer scripts[2]; and
> 3. Script authors generally don't write signal handlers for fun--they do it 
> because they need to clean up or roll back some activity, and this bug 
> utterly frustrates their efforts.
[...]

I don't see the relation with bug 683671.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#951082: dnsdist: libsystemd-dev should be added to dependancies

[John Shaft]

Hi Chris,

> All versions of dnsdist that have been shipped with Debian already
> build-depend on libsystemd-dev. I'm not sure what exactly you are
> looking

The library is indeed listed in the source package's Build-depends of
control file.

But as it is needed for building the package, it's also needed to run
properly dnsdist - if dnsdist needs to open file. Without it, it gave me
fatal errors while I was trying to configure it as a DoH server:

févr. 10 19:50:39 Shaft-OL systemd[1]: Starting DNS Loadbalancer...
févr. 10 19:50:39 Shaft-OL dnsdist[591353]: Configuration
'/etc/dnsdist/dnsdist.conf' OK!
févr. 10 19:50:39 Shaft-OL dnsdist[591353]: Configuration
'/etc/dnsdist/dnsdist.conf' OK!
févr. 10 19:50:39 Shaft-OL dnsdist[591354]:
139986757410048:error:0200100D:system library:fopen:Permission
denied:../crypto/bio/bss_file.c:288:fopen('/etc/dnsdist/foobar.key','r')
févr. 10 19:50:39 Shaft-OL dnsdist[591354]:
139986757410048:error:20074002:BIO routines:file_ctrl:system
lib:../crypto/bio/bss_file.c:290:
févr. 10 19:50:39 Shaft-OL dnsdist[591354]:
139986757410048:error:140B0002:SSL
routines:SSL_CTX_use_PrivateKey_file:system lib:../ssl/ssl_rsa.c:540:
févr. 10 19:50:39 Shaft-OL dnsdist[591354]: Fatal error: Error setting
up TLS context for DoH listener on '[2001:bd8:cafe:cafe::443]:443': An
error occurred while trying to load the TLS server private key file:
/etc/dnsdist/foobar.k->
févr. 10 19:50:39 Shaft-OL systemd[1]: dnsdist.service: Main process
exited, code=exited, status=1/FAILURE
févr. 10 19:50:39 Shaft-OL systemd[1]: dnsdist.service: Failed with
result 'exit-code'.
févr. 10 19:50:39 Shaft-OL systemd[1]: Failed to start DNS Loadbalancer.

Without the lib installed, it can work by disabling the
CapabilityBoundingSet in the service file (which is clearly unwanted)

Installing it solved the issue

Thinking about it, it might be a more general bug, not related to Debian
(I'm definitely not a pro but it looks like it may be linked to the
"notify" service type and the CapabilityBoundingSettings)

I hope this message is clearer :)

Regards,

Bug#683671: dash: 'set -e'+'trap' malfunction is fixed in upstream git

[Robinson, Branden (Data61, Kensington NSW)]

# hello, control, been a while...
tag 683671 + patch fixed-upstream
thanks

Hi Andrej et al.,

After independently encountering and then debugging this problem to the point 
where I had a fix, I learned that Antonio Ospite had come up with an identical 
one (modulus whitespace) over a year ago[1].  I've attached a copy.

It really sucks that dash has had this bug for 12 years, given that:
1. It's Debian's default /bin/sh;
2. We're required by Policy to 'set -e' in our maintainer scripts[2]; and
3. Script authors generally don't write signal handlers for fun--they do it 
because they need to clean up or roll back some activity, and this bug utterly 
frustrates their efforts.

Were I active in the project, I'd be raising hell like in the old days to get 
this bug's severity back up to 'serious', on the premise that it frustrates the 
robustness of maintainer scripts that we try to ensure with 'set -e' in the 
first place.

The fix is a transposition of one line; please consider applying it.

I notice there are other fixes in the git repo, also usually from Antonio 
Ospite, for various compiler warnings.  Those may be worthy of consideration in 
a near-term package release as well.

Cheers!

[1] 
https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=06204f0c9f539fcb8cb532166656e80b81bd689a
[2] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

--
G. Branden Robinson
Trustworthy Systems Group, CSIRO's Data61
"Every good idea will be discovered twice: once by a logician and once by a 
computer scientist." - Philip Wadler
commit 06204f0c9f539fcb8cb532166656e80b81bd689a
Author: Antonio Ospite 
Date:   Tue Oct 16 14:09:52 2018 +0200

eval: make traps work when "set -e" is enabled

When "set -e" is enabled traps are not always executed, in particular
the EXIT trap is not executed when the shell exits on an unhandled
error.

Consider the following test script:

  #!/bin/dash

  set -e

  trap 'ret=$?; echo "EXIT: $ret"' EXIT
  trap 'exit 2' HUP INT QUIT PIPE TERM

  read variable

By pressing Ctrl-C one would expect the EXIT trap to be called, as it is
the case with other shells (bash, zsh), but dash does not do it.

By calling dotrap() before jumping to the exit path when checkexit is
not zero, dash behaves like other shells.

Signed-off-by: Antonio Ospite 
Signed-off-by: Herbert Xu 

diff --git a/src/eval.c b/src/eval.c
index 546ee1b..dde9fa2 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -307,11 +307,11 @@ setstatus:
 		break;
 	}
 out:
+	dotrap();
+
 	if (checkexit & status)
 		goto exexit;
 
-	dotrap();
-
 	if (flags & EV_EXIT) {
 exexit:
 		exraise(EXEXIT);

Bug#951079: [Pkg-zfsonlinux-devel] Bug#951079: zfs-dkms: Uses only single core during compile

[Witold Baryluk]

Hi,
Aron

I used dkms 2.6.1-4 from buster.

Hmm. Yes, configure part is slow, and unfortunately serial
due how the autoconf works in general.

Maybe it was a configure indeed, not the actual compilation,
I didn't check full command lines in `top` to see what was
being actually compiled by `cc`.

I think you might be right then.

Regards,
Witold

On Tue, 11 Feb 2020 at 01:48, Aron Xu  wrote:
>
> Hi,
>
> I'm curious about which version of dkms package do you have? The build
> process itself is parallel by default since dkms/2.2.0.3-4.
>
> It would take a lot of time at configure stage because versions prior
> to zfs-linux/0.8.3-1 suffer from the non-parallel KABI check, and if
> you have plenty of cores on the system then it gives an impression
> that configure takes ages but the actual build finishes in seconds.
>
> Regards,
> Aron

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[YunQiang Su]

On Thu, 6 Feb 2020 15:07:49 +0800 YunQiang Su 
wrote:
> Steven Robbins  于2020年2月6日周四 下午3:05写道：
> >
> > On Thursday, February 6, 2020 12:51:23 A.M. CST YunQiang Su wrote:
> > > Steven Robbins  于2020年2月6日周四 下午1:23写道：
> > >
> > > > On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su <
wzss...@gmail.com> wrote:
> > > > > Package: src:gmp
> > > > > Version: 6.2.0+dfsg-3
> > > > >
> > > > > Since binutils/gcc meet some problem due to 2GB/3GB memory
limitation
> > > > > on 32bit system.
> > > >
> > > > Since GMP has built on all architectures, so I don't understand
what
> > > > problem you are trying to solve.   Please enlighten me?
> > >
> > > The 32bit system has 2GiB/3GiB virtual memory space limitation.
> > > When a big object file need to compile/link, the ld/gcc/cc1 may
need lots of
> > > memory, which may be more than 2GiB/3GiB.
> >
> > I understand that.  I know that some packages have trouble to
build.  But gmp
> > is not one of them -- it has already built on all
architectures.  So I don't
> > understand why gmp needs a patch.
> 
> Because gcc builddeps it.

Any consideration of this changes?

> 
> >
> > -Steve
> 
> 
> 
> -- 
> YunQiang Su
> 
> 


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

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[Cameron Davidson]

This has just started hapenning to my also.

The cause, I think, that evenutally a tmpfile cleanup will delete
/run/smokeping - maybe depends on age and/or  because it is not owned by
root.

One solution (I found for other systemd processes run as non-root) is to
add a config file:

/usr/lib/tmpfiles.d/smokeping.conf

Contents should be something like:

   d    /run/smokeping   0755   smokeping   smokeping   -   -

to have systemd recreate the dir when smokeping is started.


Regards,

Cameron.

Bug#951079: [Pkg-zfsonlinux-devel] Bug#951079: zfs-dkms: Uses only single core during compile

[Aron Xu]

Hi,

I'm curious about which version of dkms package do you have? The build
process itself is parallel by default since dkms/2.2.0.3-4.

It would take a lot of time at configure stage because versions prior
to zfs-linux/0.8.3-1 suffer from the non-parallel KABI check, and if
you have plenty of cores on the system then it gives an impression
that configure takes ages but the actual build finishes in seconds.

Regards,
Aron

Bug#942934: cvs-fast-export does not depend on Python 2

[Anthony Fok]

Hi Eric,

On Mon, Feb 10, 2020 at 9:18 AM Eric Raymond  wrote:
> The reason given for removing cvs-fast-export is, I believe, in error.
> I went to considerable effort to prepare it for Python 2 EOL
> and find it quite annoying that it was removed anyway.
>
> ...
> Thus, cvs-fast-export can use Python 2 if that is all the environment has 
> available,
> but it will cheerfully use Python 3.  It doesn't care which interpreter 
> "python" redirects to.

Thanks for the heads up, and I sincerely apologize for the removal of
cvs-fast-export from Debian "bullseye" (testing).
It is, thankfully, still in Debian "sid" (unstable) and "buster"
(stable, i.e. Debian 10).

The problems actually lies in me, actually, or rather, in my failure
to update the Debian packaging files in time, especially
debian/control and debian/rules, to use Python 3 instead.

> Please either reinstate cvs-fast-export or file a bug against it explaining 
> how it actually fails to be Python-version-agnostic.

I'll be fixing the packaging soon, and either upload 1.47-2 to use
Python 3, or upgrade to 1.50 and upload 1.50-1.  If all goes well,
cvs-fast-export should be back in Debian "bullseye" (testing) within
one week.

Best regards,
Anthony

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[Cameron Davidson]

Sorry, a followup to my incomplete previous post...

After upgrade from Debian 9 to 10...

/run on my system is now mounted on a tmpfs and is therefore recreated
empty at reboot. 

The old pidfile location /var/run is symlinked to /run.

The folder /run/smokeping needs to be recreated each reboot with
permissions to allow user smokeping to write to it.



Regards,

Cameron.

Bug#950890: xserver-xorg-core: X segfaults when displaying a big image with xzgv

[Frédéric Brière]

On Mon, Feb 10, 2020 at 10:30:44AM +0100, Michel Dänzer wrote:
> Can't see the backtrace,

It was attached as gdb.txt.  (Granted, I could've renamed it to
something a bit more obvious.)

> but the log excerpt above looks like the fixes
> from https://gitlab.freedesktop.org/xorg/xserver/merge_requests/135
> might help, so I added them to
> https://gitlab.freedesktop.org/xorg/xserver/merge_requests/391 and they
> will hopefully be in the upcoming 1.20.8 release.

Thanks!  I've applied !391 to 2:1.20.7-3 (except for the one patch that
was already included), and it does seem to solve the issue.  Now,
instead of crashing, the server merely freezes for 5-15 seconds before
it emits a warning and keeps going on.

Thank you once again!

Bug#950627: Regression: Unable to config with CMake

[Brian Clinkenbeard]

Since SDL2 now comes bundled with sdl2-config.cmake, it seems that using 
an external FindSDL2.cmake is no longer necessary in SDL2 projects using 
CMake. Here is the file I was talking about: 
https://github.com/yuzu-emu/yuzu/blob/master/externals/cmake-modules/FindSDL2.cmake

When I remove this file from the project and allow CMake find the 
libraries with SDL2 with sdl2-config.cmake, CMake runs successfully. So 
while I can't speak for the original reporter, this seems to be an issue 
with projects using a legacy way including SDL2 with CMake and not with 
the package.

On Mon, 10 Feb 2020 20:08:43 +0100 Felix Geyer  wrote:
 > On 10.02.20 02:24, Brian Clinkenbeard wrote:
 > > I believe I am also having this issue. "find_package(SDL2 REQUIRED)" in
 > > CMakeLists.txt yields the following error:
 > > -- Target architecture: x86_64
 > > 
 > > 
 > > CMake Error at
 > > /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
 > > (message):
 > >   Could NOT find SDL2 (missing: SDL2_INCLUDE_DIR)
 > > Call Stack (most recent call first):
 > > /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393
 > > (_FPHSA_FAILURE_MESSAGE)
 > >   externals/cmake-modules/FindSDL2.cmake:239
 > > (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
 > >   CMakeLists.txt:155 (find_package)
 >
 > Without access to the code (externals/cmake-modules/FindSDL2.cmake in 
this case)
 > I can't really help debug it.
 >
 > My guess is that the custom FindSDL2 module is doing something wrong
 > when it tries to find the SDL2 header files.
 > It doesn't seem to search in all system include paths.
 > The headers have been moved from /usr/include/SDL2 to 
/usr/include//SDL2.
 >
 > Cheers,
 > Felix
 >
 >

Bug#860416: digikam: can't switch map source

[Christoph Anton Mitterer]

On Mon, 2020-02-10 at 12:56 +0100, Agustin Martin wrote:
> Triaging some Debian bugs. Tried to reproduce this problem with
> digikam 
> 4:6.4.0+dfsg-2 (currently in sid) but switching maps seems to work.
> Is this
> still a problem for you?

I've just tried with the same version and unfortunately it still
doesn't work here.
Whatever I choose it stays at OSM.

Cheers,
Chris.

Bug#946150: please update build-deps on iptables

[peter green]

Severity 946150 serious
Thanks


The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream.

It also dropped the iptables-dev package, which miniupnpd build-depends on.

This means it is no longer possible to build miniupnpd in testing, so I am 
raising the severity to serious.

Bug#951090: keepalived, build-depends on removed package.

[peter green]

Package: keepalived
Version: 1:2.0.19-1
Severity: serious

keepalived build-depends on iptables-dev, which is no longer built by the 
iptables source package. It is still present in unstable as a cruft package, 
but is completely gone from testing.

Before it's removal iptables-dev was a transitional dummy package depending on 
a bunch of other dev packages, please determine which of those dev packages 
your package needs and adjust your build-dependencies accordingly.

P.S. The release team have decreed that non-buildd binaries cannot migrate to 
testing, please ensure that your next upload is source-only.

Bug#951089: iproute2, build-depends on removed package.

[peter green]

Package: iproute2
Version: 5.4.0-1
Severity: serious

iproute2 build-depends on iptables-dev, which is no longer built by the 
iptables source package. It is still present in unstable as a cruft package, 
but is completely gone from testing.

Before it's removal iptables-dev was a transitional dummy package depending on 
a bunch of other dev packages, please determine which of those dev packages 
your package needs and adjust your build-dependencies accordingly.

Bug#951088: collectd, build-depends on removed package.

[peter green]

Package: collectd
Version: 5.9.2.g-1
Severity: serious

collectd build-depends on iptables-dev, which is no longer built by the 
iptables source package. It is still present in unstable as a cruft package, 
but is completely gone from testing.

Before it's removal iptables-dev was a transitional dummy package depending on 
a bunch of other dev packages, please determine which of those dev packages 
your package needs and adjust your build-dependencies accordingly.

Bug#951087: openjk: FTBFS against libsdl2 2.0.10+dfsg1-2: fatal error: SDL.h: No such file or directory

[Andreas Beckmann]

Source: openjk
Version: 0~20191030.4881be7~dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

openjk FTBFS against libsdl2 2.0.10+dfsg1-2 which has moved the headers
to an arch-dependent location:

[ 53%] Building CXX object 
code/CMakeFiles/openjo_sp.x86_64.dir/client/cl_cgame.cpp.o
cd "/build/openjk-0~20191030.4881be7~dfsg/obj/code" && /usr/bin/c++  
-DARCH_STRING=\"x86_64\" -DFINAL_BUILD -DJK2_MODE -DSOURCE_DATE="\"Nov  2 
2019\"" -D_JK2EXE -I"/build/openjk-0~20191030.4881be7~dfsg/shared" -I"
/build/openjk-0~20191030.4881be7~dfsg/code" 
-I"/build/openjk-0~20191030.4881be7~dfsg/lib/gsl-lite/include" 
-I"/build/openjk-0~20191030.4881be7~dfsg/lib/minizip/include"  -g -O2 
-fdebug-prefix-map=/build/openjk-0~2
0191030.4881be7~dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wno-unused-parameter 
-Wno-missing-field-initializers -fno-strict-aliasing -Wno-strict-aliasing 
-Wno-unused-but-set-variable  
 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -msse2 -std=c++11 -Wall 
-Wno-invalid-offsetof -Wno-write-strings -Wno-comment -fsigned-char 
-mstackrealign -mfpmath=sse   -fvisibility=hidden -o CMakeFiles/openjo_sp.x86_6
4.dir/client/cl_cgame.cpp.o -c 
"/build/openjk-0~20191030.4881be7~dfsg/code/client/cl_cgame.cpp"
In file included from 
/build/openjk-0~20191030.4881be7~dfsg/code/client/cl_cgame.cpp:34:
/build/openjk-0~20191030.4881be7~dfsg/shared/sys/sys_loadlib.h:39:11: fatal 
error: SDL.h: No such file or directory
   39 | # include 
  |   ^~~
compilation terminated.


Andreas


openjk_0~20191030.4881be7~dfsg-1.log.gz
Description: application/gzip

Bug#951086: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 is missing

[Vincent Lefevre]

Package: libgcc1
Version: 1:10-20200204-1
Severity: important

After a recent upgrade, I get the following error:

zira:~> gcc-4.9 tst.c -o tst
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status

It tries to open libgcc_s.so, which was previously found at

  /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so

which is a symbolic link to

  /lib/x86_64-linux-gnu/libgcc_s.so.1

but this file have moved to /lib.

The usual paths are searched too, so that alternatively, I think that
a libgcc_s.so -> libgcc_s.so.1 symbolic link in /lib could solve the
issue, if acceptable.

gcc-4.9 is rather old, but still useful for testing, and there was
no announce of any change.

In the mean time, a workaround is to add a symlink

/usr/local/lib/libgcc_s.so -> /lib/libgcc_s.so.1

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

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

Versions of packages libgcc1 depends on:
ii  gcc-10-base  10-20200204-1
ii  libc62.29-10
ii  libgcc-s110-20200204-1

libgcc1 recommends no packages.

libgcc1 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#949450: [pkg-apparmor] Bug#949450: thunderbird: tb not usable with apparmor profile enabled.

[Christian Boltz]

Hello,

I'm not the maintainer of the thunderbird profile nor using Debian, but 
maybe I can give some helpful input nevertheless ;-)

(Updating the shipped profile has to be done by someone else.)

Am Freitag, 31. Januar 2020, 11:46:49 CET schrieb Dimitris:
> On 1/30/20 2:11 PM, Dimitris wrote:
...
> > [Thu Jan 30 2020] audit: type=1400 audit(1580374356.923:36):
> > apparmor="DENIED" operation="open"
> > profile="thunderbird//sanitized_helper"
> > name="/tmp/clearsigned.message.pycT1r" pid=23600 comm="apt-cache"
> > requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

That looks interesting[tm] - why would apt-cache want to access a 
tempfile that looks like (wild guess based on the filename) a signed 
message?

[...]
> > audit: type=1400 audit(1580377190.735:2836): apparmor="DENIED"
> > operation="file_inherit" profile="thunderbird//gpg"
> > name=2F6
> > D6C pid=13850 comm="gpg" requested_mask="a"
> > denied_mask="a" fsuid=1000 ouid=1000
> > 
> > (replaced chars in between with Xs, since i don't know what this
> > could be..?)

That's a hex-encoded filename - this encoding gets used in the log if a 
filename contains for example a space or special characters. 

You can decode it with
aa-decode 2F6D6C
(obviously use the original name, not the X'ed out one)

>From the X'ed out name, I can say that it starts with, surprise, "/" 
(2F) and ends with "l" (6C)

> new messages emerging making tb/enigmail unusable :
> 
> audit: type=1400 audit(1580465922.867:14): apparmor="DENIED"
> operation="capable" profile="thunderbird" pid=11974 comm="thunderbird"
> capability=21 capname="sys_admin"

That's interesting[tm]. Wild guess: maybe thunderbird uses some 
sandboxing that needs this capability to initialize?

> audit: type=1400 audit(1580465924.499:15): apparmor="DENIED"
> operation="open" profile="thunderbird" name="/etc/mate/defaults.list"
> pid=11974 comm="thunderbird" requested_mask="r" denied_mask="r"
> fsuid=1000 ouid=0

That translates to   /etc/mate/defaults.list r,   for the thunderbird 
profile - or an abstraction. (We don't have a mate abstraction yet, 
maybe it's time to start one? ;-)

> audit: type=1400 audit(1580465929.463:16): apparmor="DENIED"
> operation="file_lock" profile="thunderbird"
> name="/home/user/.cache/thunderbird/profile.default/OfflineCache/index
> .sqlite" pid=11974 comm="thunderbird" requested_mask="k"
> denied_mask="k" fsuid=1000 ouid=1000

k is for "file lock". The strictest-possible rule would be
/home/*/.cache/thunderbird/profile.default/OfflineCache/index k,

> audit: type=1400 audit(1580465955.367:18): apparmor="DENIED"
> operation="file_inherit" profile="thunderbird//gpg"
> name="/home/user/.icedove/profile.default/ImapMail/account1/INBOX.sbd/
> folder" pid=13491 comm="gpg" requested_mask="w" denied_mask="w"
> fsuid=1000 ouid=1000
> 
> audit: type=1400 audit(158045.275:19): apparmor="DENIED"
> operation="file_inherit" profile="thunderbird//gpg"
> name="/home/user/.icedove/profile.default/prefs-1.js" pid=20428
> comm="gpg" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

These two look like a case of thunderbird not closing files when 
executing gpg. You can probably ignore or deny that.

> audit: type=1400 audit(158045.279:20): apparmor="DENIED"
> operation="exec" profile="thunderbird//gpg" name="/usr/bin/gpg-agent"
> pid=20430 comm="gpg" requested_mask="x" denied_mask="x" fsuid=1000
> ouid=0

Ah, gpg wants to execute gpg-agent. That makes sense.

The easiest solution would be to add
/usr/bin/gpg-agent mrix,
to the gpg subprofile.

A more strict version would be
/usr/bin/gpg-agent mrPx -> thunderbird//gpg-agent,
to the gpg subprofile, and then to create a child profile called 
gpg-agent:
profile gpg-agent {
# TODO
}


As a sidenote - soneone in the #apparmor IRC channel (on OFTC) spent 
some work on creating a profile for thunderbird a few weeks ago. 
Unfortunately the pastebin links have expired, but if you are 
interested, I can try to get it uploaded somewhere again.


BTW: While you work on the profile, you might want to put it into 
complain mode. Without knowing the exact profile filename:
aa-complain /etc/apparmor.d/*thunderbird
This will allow everything (so Thunderbird will work) and log what would 
be denied. However, note that "allow everything" means that AppArmor 
won't prevent anything evil, so don't forget to switch the profile back 
to enforce mode (using aa-enforce instead of aa-complain) when you think 
it's complete.

If you prefer an interactive tool over reading the logfile, you can use 
aa-logprof   to update the profile.


Regards,

Christian Boltz
-- 
> > How about openSUSE Leap $(sha256sum $ISOIMAGEFILENAME) :-(
> Can I get a version with my name?? :D
Sure.  Just change your name to "openSUSE".  ;)
[>> Mathias Homann, > Karl Sinn and James Knott in opensuse-factory]


signature.asc
Description: This is a digitally signed 

Bug#951085: gcc-10: FTBFS due to missing parens in versioned break

[Andres Salomon]

Package: gcc-10
Version: 10-20200210-1
Severity: serious

gcc-10 is failing to build with the following error:


dpkg-gencontrol: error: error occurred while parsing Breaks field: 
cryptsetup-initramfs << 2:2.2.2-3~,
dh_gencontrol: error: dpkg-gencontrol -plibgcc-s1 -ldebian/changelog 
-Tdebian/libgcc-s1.substvars -Pdebian/.debhelper/libgcc-s1/dbgsym-root 
-v10-20200210-1 -Vlibgcc:Version=10-20200210-1 
-Vgcc:Version=10-20200210-1 -Vgcc:EpochVersion=1:10-20200210-1 
-Vgcc:SoftVersion=10 -Vgdc:Version=10-20200210-1 
-Vgm2:Version=10-20200210-1 -Vgnat:Version=10-20200210-1 
-Vgnat:SoftVersion=10 -Vbinutils:Version=2.34 "-Vdep:libgcc=libgcc-s1 
(>= \${gcc:Version})" "-Vdep:libgccdev=libgcc-10-dev (= 
\${gcc:Version})" -Vdep:libgccbiarch= -Vdep:libgccbiarchdev= 
"-Vdep:libc=libc6 (>= 2.11)" "-Vdep:libcdev=libc6-dev (>= 2.13-5)" 
-Vdep:libcbiarch= -Vdep:libcbiarchdev= -Vdep:libunwinddev= 
-Vdep:libcxxbiarchdev= -Vdep:libcxxbiarchdbg= -Vdep:libgnat= 
"-Vbase:Breaks=gnat (<< 7)" "-Vlibgcc:Breaks=cryptsetup-initramfs << 
2:2.2.2-3~, " "-Vdep:gold=binutils-gold (>= 2.34)" 
"-Vdep:libgomp=libgomp1 (>= \${gcc:Version})" "-Vdep:libitm=libitm1 (>= 
\${gcc:Version})" "-Vdep:libatomic=libatomic1 (>= \${gcc:Version})" 
"-Vdep:libasan=libasan6 (>= \${gcc:Version})" "-Vdep:liblsan=liblsan0 
(>= \${gcc:Version})" "-Vdep:libtsan=libtsan0 (>= \${gcc:Version})" 
"-Vdep:libubsan=libubsan1 (>= \${gcc:Version})" 
"-Vdep:libqmath=libquadmath0 (>= \${gcc:Version})" -Vdep:libx32z= 
"-Vdep:libcc1=libcc1-0 (>= \${gcc:Version})" 
"-Vmultiarch:breaks=gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 
(<< 4.5.3-2)" "-Vgolang:Conflicts=golang-go (<< 2:1.3.3-1ubuntu2)" 
-Vfortran:mod-version=gfortran-mod-15 -UPre-Depends -URecommends 
-USuggests -UEnhances -UProvides -UEssential -UConflicts 
-DPriority=optional -UHomepage -UImportant -UBuilt-Using 
-DAuto-Built-Package=debug-symbols -DPackage=libgcc-s1-dbgsym 
"-DDepends=libgcc-s1 (= \${binary:Version})" "-DDescription=debug 
symbols for libgcc-s1" 
-DBuild-Ids=b8c5e334209666a8039479266ddbf6322ef1d78b -DSection=debug 
"-DReplaces=libgcc-s1-dbg (<< 9.2.1-21)" "-DBreaks=libgcc-s1-dbg (<< 
9.2.1-21)" returned exit code 25


Full build log is at 
<https://buildd.debian.org/status/fetch.php?pkg=gcc-10=ppc64el=10-20200210-1=1581374256=0>


The issue appears to be in debian/rules.conf:

 LIBGCC_BREAKS += cryptsetup-initramfs << 2:2.2.2-3~,

That versioned break needs parenthesis:

 LIBGCC_BREAKS += cryptsetup-initramfs (<< 2:2.2.2-3~),

Thanks,
Andres

Bug#933636: CVE-2019-14934

[Francois Marier]

On 2020-02-07 at 10:14:24, Salvatore Bonaccorso wrote:
> > It looks OK to me. Tagging moreinfo until there's a final diff.
> 
> Friendly ping, any news? (It's too late now for the upcoming point
> release though).

It's still on my list, but not a very high priority. Definitely won't happen
until at least after the Ubuntu 20.04 Debian merge deadline.

Francois

-- 
https://fmarier.org/

Bug#951084: module-assistant: unpack sub-command not documented in module-assistant(8)

[Kevin Locke]

Package: module-assistant
Version: 0.11.10
Severity: minor
Tags: patch

Dear Maintainer,


Although the `unpack` sub-command is documented in the `--help` output,
it is not currently documented in the module-assistant(8) manual page,
which makes it harder to find for users consulting the man page.  I've
attached a patch which documents it.

Cheers,
Kevin


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

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

Versions of packages module-assistant depends on:
ii  bzip2  1.0.8-2
ii  libtext-wrapi18n-perl  0.06-9
ii  perl   5.30.0-9
ii  xz-utils   5.2.4-1+b1

Versions of packages module-assistant recommends:
ii  liblocale-gettext-perl  1.07-4

Versions of packages module-assistant suggests:
ii  build-essential  12.8
ii  whiptail 0.52.21-4

-- no debconf information
>From 677eb8a7e0ebbc03b880ef6b49f898afde9a3700 Mon Sep 17 00:00:00 2001
Message-Id: 
<677eb8a7e0ebbc03b880ef6b49f898afde9a3700.1581375953.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Mon, 10 Feb 2020 15:56:55 -0700
Subject: [PATCH] document unpack in module-assistant(8)

Although the `unpack` sub-command is documented in the `--help` output,
it is not currently documented in the module-assistant(8) manual page.
This commit adds some basic documentation similar to the other
sub-commands.

Signed-off-by: Kevin Locke 
---
 module-assistant.8.sgml | 8 
 1 file changed, 8 insertions(+)

diff --git a/module-assistant.8.sgml b/module-assistant.8.sgml
index 74205bf..d739c8e 100644
--- a/module-assistant.8.sgml
+++ b/module-assistant.8.sgml
@@ -44,6 +44,7 @@
list-installed
auto-unpacked
get
+   unpack
build
install
clean
@@ -189,6 +190,13 @@
  source, downloading source packages when needed.
  
 
+ unpack
+ 
+ 
+
  build
  
  

Bug#947980: firmware-atheros: Please package new "upstream" firmware version

[jnqnfe]

yes, please update this for me also.

I have QCA6174; I've been experiencing a problem whereby sometimes
webpage loading hangs, fixed by turning wifi off and on again.

Also, I'm seeing a LOT of this in dmesg:
[37875.481395] pcieport :00:1c.4: AER: Corrected error received:
:00:1c.4
[37875.481402] pcieport :00:1c.4: AER: PCIe Bus Error:
severity=Corrected, type=Data Link Layer, (Transmitter ID)
[37875.481405] pcieport :00:1c.4: AER:   device [8086:9d14] error
status/mask=1000/2000
[37875.481407] pcieport :00:1c.4: AER:[12] Timeout

I'm already using the latest UEFI (mentioned in [2] below).

I see that from the changelog of this package that QCA6174 seems to
have last been updated last May. It seems to have seen a few updates in
the linux firmware git ([1]) since then.

I see in the Arch Wiki ([2]) that the above issue is discussed and
there is a suggestion of manually installing the latest firmware from
the linked 'kvalo' github repo. I've not tried this yet (nor
alternatively that in the linux repo).

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?qt=grep=QCA6174
[2]: https://wiki.archlinux.org/index.php/Dell_XPS_13_(9360)#Wireless

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Thorsten Glaser]

On Mon, 10 Feb 2020, Bernhard Übelacker wrote:

> I made an attempt in [1], hopefully my english is not too bad...

Thanks, I’ll have a look at it later (caught the flu and
can only concentrate for short times at best atm).

> Maybe a core could be collected with one of the
> three core-dump-handler providing packages installed in [2]?

No systemd here, but I wasn’t aware that something like
corekeeper exists and will have a look.

> [1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
> [2] https://wiki.debian.org/HowToGetABacktrace#Core_dump

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949710: /usr/bin/plasmashell: segfaults sporadically but only when using app dropdown menu

[Thorsten Glaser]

Hi Bernhard,

you seem to be triaging a lot of segfault bugs recently ;-)

>Usually when a segfault happens in 'dmesg' output should
>appear two lines about this event. Maybe you could forward
>these to the report too.

We debugged this together, as it just happened when we were
discussing the bugreport again. Interestingly enough, there
is nothing related in dmesg (last entry a couple of minutes
after boot).

>If it is possible to install systemd-coredump a backtrace
>would be automatically added to the journal, which could
>be viewed by 'journalctl --no-pager'.

We installed systemd-coredump.

>[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

We installed all debug symbol packages (from the goodies)
and gdb-minimal (or does it need gdb full?) and will see
when it happens next.

Some more ideas:

• it only happens on a Tuxedo laptop, but not on a Mac mini
• while it happened, VMs (libvirt/virt-manager/SPICE-QXL)
  were in use

Display is: lspci…
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
… and lshw…
  *-display
   description: VGA compatible controller
   product: Intel Corporation
   vendor: Intel Corporation
   physical id: 2
   bus info: pci@:00:02.0
   version: 07
   width: 64 bits
   clock: 33MHz
   capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
   configuration: driver=i915 latency=0
   resources: irq:127 memory:db00-dbff memory:9000-9fff 
ioport:f000(size=64) memory:c-d

As for the X video subsystem in use, xserver-xorg-video-all is
installed and I don’t know how to find out the one in actual use,
but the following X modules are loaded:

[64.097] (II) LoadModule: "glx"
[64.106] (II) LoadModule: "modesetting"
[64.108] (II) LoadModule: "fbdev"
[64.109] (II) LoadModule: "vesa"
[64.129] (II) LoadModule: "fbdevhw"
[64.130] (II) LoadModule: "glamoregl"
[64.251] (II) LoadModule: "fb"
[64.593] (II) LoadModule: "libinput"

(This is just one more, fbdevhw, than my own laptop has.)
I think it’s using KMS and no extra X driver.

As to firmware, i915/kbl_dmc_ver1_04.bin (v1.4) is loaded,
as are intel/ibt-12-16.ddc, intel/ibt-12-16.sfi, and others
(iwlwifi, Blåtand, r8169) that are unrelated.


Not sure how much this helps…

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#951083: RM: python-django-gravatar2 -- ROM; Dead upstream, no reverse dependency, python2 package

[Pierre-Elliott Bécue]

Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

python-django-gravatar2 is dead upstream, not used by any other package,
and it's in python2.

It's too much of a burden for a single package.

We should probably kill it on sight.

Cheers!

Bug#951080: [Pkg-zfsonlinux-devel] Bug#951080: zfsutils-linux: Please disable shipped crontab zfs scrub script by default

[Richard Laager]

On 2/10/20 4:04 PM, Witold Baryluk wrote:
> The current package, significant deviats from the upstream, and is a
> rather arbitrary decision by the maintainer, not a user or zfs
> developers.

I wouldn't characterize this as a significant deviation from upstream.
But yeah, we should ship a scrub cron job upstream too.
> This decision also can negatively impact system performance with multiple
> pools being scrubbed at the same time, or just affect performance in
> general, i.e. on laptops when running on battery, or when pool is mounted
> from device on iSCSI share.
Which of these examples is your situation? There may be other issues or
changes to consider.

Can you share your zpool status output?

Scrubs are (supposed to be) throttled to reduce their impact. Are you
experiencing problems only after upgrading to 0.8.x? If so, the new
sequential scrub code may be a factor here. Overall, it is much more
efficient, but perhaps it is creating too much load for you.

It may be necessary to customize this script or the timings to your
particular needs. That doesn't make it a bad default.

The point of the script is to ensure that people's pools _are_ being
scrubbed. Otherwise, they may not find out about errors until it is too
late (i.e. they have data loss). ZFS scrubbing is analogous to mdadm's
check functionality, and the mdadm package ships a similar script on a
similar schedule. (The particular scrubbing time for ZFS was
specifically selected to be a different week than mdadm just in case the
user has both in use.)

-- 
Richard

Bug#940199: pluma: python2 and new upstream stable release 1.24.0

[Mike Gabriel]

Hi Andreas,

On  Mo 10 Feb 2020 23:38:19 CET, Andreas Henriksson wrote:


Control: tags -1 + patch

Hello,

I've prepared an update for the pluma package to the recently released
new upstream stable release 1.24.0.
The merge-request is available at:
https://salsa.debian.org/debian-mate-team/pluma/merge_requests/1
(Please note that this has only been compile tested.)

I've kind of lost patience waiting for a followup from pluma maintainers
on the python2 loader issue, so expect me to drop the python2 loader
from libpeas any second now!

Please speak up if you want me to NMU the fixed up pluma package!

Regards,
Andreas Henriksson


sorry for the long delay on our side. We have been waiting for the  
MATE 1.24 release series which just came out today.


Martin and I will be prepare all the uploads within the coming week  
and the above issue will then be resolved.


Sorry again for the long delay,
Mike
--

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

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



pgp3kzrsRJkg4.pgp
Description: Digitale PGP-Signatur

Bug#951082: dnsdist: libsystemd-dev should be added to dependancies

[Chris Hofstaedtler]

Hi John,

thank you for your bug report.

* John Shaft  [200210 23:15]:
> Package: dnsdist
> Version: 1.4.0~rc5-1
> Severity: normal
> 
> To run using systemd, libsystemd-dev is highly recommended in order to have 
> dnsdist be able to use
> systemd-notify
(...)
> Hence, libsystemd-dev should be set as a dependancy of dnsdist

All versions of dnsdist that have been shipped with Debian already
build-depend on libsystemd-dev. I'm not sure what exactly you are
looking for?

Chris

Bug#944297: htmltable.c:1761: pos_html_tbl: assertion delx >= 0, when using nested fixedsize table

[Witold Baryluk]

Package: graphviz
Version: 2.42.2-3
Followup-For: Bug #944297

FYI. Reported upstream https://gitlab.com/graphviz/graphviz/issues/1622
including further minimized test case.

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

[Daniel Kahn Gillmor]

On Mon 2020-02-03 14:42:03 -0700, Sean Whitton wrote:
> On Fri 31 Jan 2020 at 05:43PM -05, Daniel Kahn Gillmor wrote:
>
>> Thanks for the extensive review.  I've revised imap-dl, taking it into
>> account, and have attached the revised version here.  You can also find
>> it on my imap-dl-v2 branch on salsa.
>
> Please send a v3 patch, or rebase your branch,

I don't understand what sort of rebase you are asking for -- the
imap-dl-v2 branch on https://salsa.debian.org/dkg/mailscripts.git is
(and been) based directly atop the imap-dl-squashed branch, so it's
accessible with piecewise commits, with explanatory comments.

But i'll send a squashed v3 patch as well :)

Thanks for reviewing!

--dkg

Bug#780741: [Pkg-mozext-maintainers] Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye

[Daniel Kahn Gillmor]

On Sun 2019-11-03 22:50:59 +0100, Benjamin Drung wrote:
> I ported amo-changelog and xpi-repack to Python 3 in version 0.54, but I
> wasn't able to port all scripts, because there is no Python 3 version of
> redland-bindings (see Debian bug #780741).

Afaict, upstream redland-bindings claims to support python3:
http://librdf.org/bindings/RELEASE.html#rel1_0_17_1

see also http://bugs.librdf.org/mantis/view.php?id=549

but this is from many years ago, and afaict, there has been no
additional work upstream on redland bindings since then.

Worse, i've been unable to make any of this build against python3.  You
can see my (failed) attempts at preparing an NMU.  I've published them
to salsa on the WIP-python3 branch at
https://salsa.debian.org/debian/redland-bindings if anyone wants to try
to improve.

So at any rate, i don't see how to get a python3-librdf package easily
into debian to unblock the mozilla-devscripts transition to python3.
But i do note that python3-rdflib has been in debian for a
while. (that's a totally different RDF python module)

I haven't looked into it myself, but perhaps mozilla-devscripts could
drop the use of redland and use rdflib instead?

Sorry to not have more effective progress to suggest.  I'm probably not
going to have time to work more on this, but i wanted to note where i
got to, and where i got stuck if someone else wants to pick it up.

 --dkg


signature.asc
Description: PGP signature

Bug#940461: [PATCH v3] Add imap-dl, a simple imap downloader

[Daniel Kahn Gillmor]

getmail upstream appears to have no plans to convert to python3 in the
near future.

Some of us use only a minimal subset of features of getmail, and it
would be nice to have something simpler, with the main complexity
offloaded to the modern python3 stdlib.

This patch represents a squashed series of changes from both Jameson
Graef Rollins and Daniel Kahn Gillmor (dkg), though dkg is primarily
responsible for any remaining bugs.

Thanks to Sean Whitton for useful and significant feedback.

Signed-off-by: Jameson Graef Rollins 
Signed-off-by: Daniel Kahn Gillmor 
---
 Makefile   |   4 +-
 debian/control |   2 +
 debian/mailscripts.bash-completion |   1 +
 debian/mailscripts.install |   1 +
 debian/mailscripts.manpages|   1 +
 imap-dl| 278 +
 imap-dl.1.pod  |  88 +
 7 files changed, 374 insertions(+), 1 deletion(-)
 create mode 100755 imap-dl
 create mode 100644 imap-dl.1.pod

diff --git a/Makefile b/Makefile
index af30616..ec3d851 100644
--- a/Makefile
+++ b/Makefile
@@ -1,15 +1,17 @@
 MANPAGES=mdmv.1 mbox2maildir.1 \
notmuch-slurp-debbug.1 notmuch-extract-patch.1 maildir-import-patch.1 \
+   imap-dl.1 \
email-extract-openpgp-certs.1 \
email-print-mime-structure.1 \
notmuch-import-patch.1
-COMPLETIONS=completions/bash/email-print-mime-structure
+COMPLETIONS=completions/bash/email-print-mime-structure 
completions/bash/imap-dl
 
 all: $(MANPAGES) $(COMPLETIONS)
 
 check:
./tests/email-print-mime-structure.sh
mypy --strict ./email-print-mime-structure
+   mypy --strict ./imap-dl
 
 clean:
rm -f $(MANPAGES)
diff --git a/debian/control b/debian/control
index bc8268a..21afa45 100644
--- a/debian/control
+++ b/debian/control
@@ -77,3 +77,5 @@ Description: collection of scripts for manipulating e-mail on 
Debian
  email-print-mime-structure -- tree view of a message's MIME structure
  .
  email-extract-openpgp-certs -- extract OpenPGP certificates from a message
+ .
+ imap-dl -- download messages from an IMAP mailbox to a maildir
diff --git a/debian/mailscripts.bash-completion 
b/debian/mailscripts.bash-completion
index 435576f..657de01 100644
--- a/debian/mailscripts.bash-completion
+++ b/debian/mailscripts.bash-completion
@@ -1 +1,2 @@
 completions/bash/email-print-mime-structure
+completions/bash/imap-dl
diff --git a/debian/mailscripts.install b/debian/mailscripts.install
index 2c060df..3739c49 100644
--- a/debian/mailscripts.install
+++ b/debian/mailscripts.install
@@ -1,5 +1,6 @@
 email-extract-openpgp-certs /usr/bin
 email-print-mime-structure /usr/bin
+imap-dl /usr/bin
 maildir-import-patch /usr/bin
 mbox2maildir /usr/bin
 mdmv /usr/bin
diff --git a/debian/mailscripts.manpages b/debian/mailscripts.manpages
index 1de088f..a915617 100644
--- a/debian/mailscripts.manpages
+++ b/debian/mailscripts.manpages
@@ -1,5 +1,6 @@
 email-extract-openpgp-certs.1
 email-print-mime-structure.1
+imap-dl.1
 maildir-import-patch.1
 mbox2maildir.1
 mdmv.1
diff --git a/imap-dl b/imap-dl
new file mode 100755
index 000..30f2c2f
--- /dev/null
+++ b/imap-dl
@@ -0,0 +1,278 @@
+#!/usr/bin/python3
+# PYTHON_ARGCOMPLETE_OK
+# -*- coding: utf-8 -*-
+
+# Copyright (C) 2019 Daniel Kahn Gillmor
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or (at
+# your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+DESCRIPTION = '''A simple replacement for a minimalist use of getmail.
+
+In particular, if you use getmail to reach an IMAP server as though it
+were POP (retrieving from the server and optionally deleting), you can
+point this script to the getmail config and it should do the same
+thing.
+
+It tries to ensure that the configuration file is of the expected
+type, and will terminate raising an exception, and it should not lose
+messages.
+
+If there's any interest in supporting other similarly simple use cases
+for getmail, patches are welcome.
+
+If you've never used getmail, you can make the simplest possible
+config file like so:
+
+--
+[retriever]
+server = mail.example.net
+username = foo
+password = sekr1t!
+
+[destination]
+path = /home/foo/Maildir
+
+[options]
+delete = True
+--
+'''
+
+import re
+import sys
+import ssl
+import enum
+import time
+import imaplib
+import logging
+import mailbox
+import os.path
+import argparse
+import statistics
+import configparser
+
+from 

Bug#940199: pluma: python2 and new upstream stable release 1.24.0

[Andreas Henriksson]

Control: tags -1 + patch

Hello,

I've prepared an update for the pluma package to the recently released
new upstream stable release 1.24.0.
The merge-request is available at:
https://salsa.debian.org/debian-mate-team/pluma/merge_requests/1
(Please note that this has only been compile tested.)

I've kind of lost patience waiting for a followup from pluma maintainers
on the python2 loader issue, so expect me to drop the python2 loader
from libpeas any second now!

Please speak up if you want me to NMU the fixed up pluma package!

Regards,
Andreas Henriksson

Bug#875847: qttools5-dev-tools: .qhc files not reproducible

[Vagrant Cascadian]

On 2020-02-10, Vagrant Cascadian wrote:
> On 2017-09-15, Laurent Bigonville wrote:
>> It seems that qcollectiongenerator is generating files that are
>> containing the creation time of the qhc file (LastRegisterTime and
>> CreationTime), making them non-reproducible. See:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/setools.html
>>
>> To make the build reproducible, qcollectiongenerator should probably be
>> patched to support SOURCE_DATE_EPOCH to be able to pass the debian/changelog
>> date instead of the current date.
>
> This seems partially fixed in recent qttools-opensource-src,
> implementing SOURCE_DATE_EPOCH for LastRegisterTime and CreationTime,
> but it is still affected by timezone variations.

Haven't figured out how to force the timezone to UTC or something like
that...


> TimeStampTable appears to still ignore SOURCE_DATE_EPOCH.

I *think* TimeStampTable is coming from the file modification time here:

  
https://sources.debian.org/src/qttools-opensource-src/5.12.5-2/src/assistant/help/qhelpcollectionhandler.cpp/?hl=1647#L1647


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#951082: dnsdist: libsystemd-dev should be added to dependancies

[John Shaft]

Package: dnsdist
Version: 1.4.0~rc5-1
Severity: normal

Dear Maintainer,

To run using systemd, libsystemd-dev is highly recommended in order to have 
dnsdist be able to use
systemd-notify (see :
https://dnsdist.org/install.html#installing-from-source)

Should the package be missing, capabilities defined with CapabilityBoundingSet 
in dnsdist.service will prevent dnsdist from loading external file, eg. private 
key and certificate to run it as DoT/DoH server

Hence, libsystemd-dev should be set as a dependancy of dnsdist

Regards

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
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)
LSM: AppArmor: enabled

Versions of packages dnsdist depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libc62.29-10
ii  libcap2  1:2.27-1
ii  libcdb1  0.78+b1
ii  libedit2 3.1-20191231-1
ii  libfstrm00.6.0-1+b1
ii  libgcc1  1:9.2.1-25
ii  libgnutls30  3.6.11.1-2
ii  libh2o-evloop0.132.2.5+dfsg2-3
ii  liblmdb0 0.9.22-1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libprotobuf173.6.1.3-2+b1
ii  libre2-5 20200101+dfsg-1
ii  libsnmp355.8+dfsg-2
ii  libsodium23  1.0.18-1
ii  libssl1.11.1.1d-2
ii  libstdc++6   9.2.1-25
ii  libsystemd0  244.1-1

dnsdist recommends no packages.

dnsdist suggests no packages.

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

-- no debconf information

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Bernhard Übelacker]

Hello Thorsten,


Am 06.02.20 um 19:19 schrieb Thorsten Glaser:
> On Thu, 6 Feb 2020, Bernhard Übelacker wrote:
> 
>> Hello Thorsten,
>> getting the source of such an address is possible, even with ASLR,
>> if the library versions are known and dbgsyms are available,
>> like in attached file.
> 
> This is great. Do you mind writing this up and posting it somewhere
> so people can link and bookmark it? Perhaps even in a place aggregated
> on Planet Debian?

I made an attempt in [1], hopefully my english is not too bad...


>> It looks like a null pointer is given to strncasecmp_l.
>>
>> But you are right, this information might still not be very useful,
>> because the location is in libc - if it would be in cups-browsed it
>> would be more useful.
> 
> Yeah, at least a backtrace… sorry I can’t be more helpful.

Maybe a core could be collected with one of the
three core-dump-handler providing packages installed in [2]?

Kind regards,
Bernhard


[1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
[2] https://wiki.debian.org/HowToGetABacktrace#Core_dump

Bug#932989: Microchip AVR GCC v3.6.2

[George Chapman]

> But U only see binaries. Where is the source???
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
via
https://www.avrfreaks.net/forum/where-have-atmel-avr-gcc-sourcecode-gone#comment-2742731
though it's walled; will need a myMicrochip account to get a copy.

Bug#951081: git-gui: "missing close-bracket" error while doing branch->reset

[Robert Luberda]

Package: git-gui
Version: 1:2.25.0-1
Severity: normal

After selecting Branch->Reset... and then answering 'Yes' to the
question, a popup with the following error appears:


  missing close-bracket
  missing close-bracket
  while executing
  "set status_bar_operation ["
  invoked from within
  "if {[ask_popup $op_question] eq {yes}} {
set fd [git_read --stderr read-tree --reset -u -v HEAD]
fconfigure $fd -blocking 0 -translation binary
..."
  (procedure "merge::reset_hard" line 28)
  invoked from within
  "merge::reset_hard"
  invoked from within
  ".#mbar.#mbar#branch invoke active"
  ("uplevel" body line 1)
  invoked from within
  "uplevel #0 [list $w invoke active]"
  (procedure "tk::MenuInvoke" line 50)
  invoked from within
  "tk::MenuInvoke .#mbar.#mbar#branch 1"
  (command bound to event)


Regards,
robert

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


Versions of packages git-gui depends on:
ii  git  1:2.25.0-1
ii  tk   8.6.9+1+b1

Versions of packages git-gui recommends:
ii  gitk  1:2.25.0-1

Versions of packages git-gui suggests:
ii  aspell   0.60.8-1
pn  git-doc  
pn  meld 

-- no debconf information

Bug#951080: zfsutils-linux: Please disable shipped crontab zfs scrub script by default

[Witold Baryluk]

Package: zfsutils-linux
Version: 0.8.3-1
Severity: important

Dear Maintainer,

please disable shipped crontab zfs scrub script by default.

The current package, significant deviats from the upstream, and is a
rather arbitrary decision by the maintainer, not a user or zfs
developers.

This decision also can negatively impact system performance with multiple
pools being scrubbed at the same time, or just affect performance in
general, i.e. on laptops when running on battery, or when pool is mounted
from device on iSCSI share.

I strongly suggest commenting out the crontab entry in the
/etc/cron.d/zfsutils-linux for doing this.

There is nothing in ZFS requiring to run zfs scrub regularly, and it
should be left to the user what to do about it. It is no less safe than
any other file system on the planet (in fact even without scrub it is
very safe).

The current behaviour isn't clearly documented or communicated either
(i.e. in package description).



Regards,
Witold




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

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

Versions of packages zfsutils-linux depends on:
ii  libblkid12.34-0.1
ii  libc62.29-10
ii  libnvpair1linux  0.8.3-1
ii  libuuid1 2.34-0.1
ii  libuutil1linux   0.8.3-1
ii  libzfs2linux 0.8.3-1
ii  libzpool2linux   0.8.3-1
ii  python3  3.7.5-3

Versions of packages zfsutils-linux recommends:
ii  lsb-base11.1.0
ii  zfs-dkms [zfs-modules]  0.8.3-1
ii  zfs-zed 0.8.3-1

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'

-- no debconf information

Bug#951050: Please add a systemd timer for the maintainance task

[Eduard Bloch]

Hallo,
* Laurent Bigonville [Mon, Feb 10 2020, 01:25:28PM]:
> Package: apt-cacher-ng
> Version: 3.3.1-2
> Severity: wishlist
>
> Hi,
>
> It would be nice if a systemd time could be added to replace the daily
> cronjob for the maintenance task.

And why so?

> Would be nice as well if the task was not running as apt-cacher-ng user
> (with a User= in the .service file).

And why exactly?

You seem to have a mission. Please show a Debian wiki page or something
similar to motivate me. At the moment I see no benefits, all that sounds
like just enforcing a systemd specific solution without need.

The actual plan of mine was to get rid of the cron jobs whatsoever. Run
the required tasks not based on a dumb time plan but purely based on the
collected information. That also applies to the access logs, they would
be migrated to a database (systemd fans might also try to advocate here
but I still have not seen the benefits of its log storage).

Best regards,
Eduard.
--
* ij ist sich zumindest sicher, dass Linux nie den Durchbruch auf dem Desktop
mit dieser chaotischen Ansammlung halbgarer GUIs schaffen wird.

Bug#951076: abi-compliance-checker: Invalid use of Perl "next"

[Olly Betts]

On Tue, Feb 11, 2020 at 08:36:43AM +1300, Olly Betts wrote:
> I've noticed this message repeatedly appearing in the ci.debian.net logs:
> 
> Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 
> 10171.
> 
> That's the "next" in this function:
> 
> sub exec_helper(@)
> {
> my ($reader, $writer) = @_;
> do {
> chomp($line = <$reader>);
> next if (!$line);
> if ($line eq 'exit') {
> exit(0);
> }
> system($line);
> print $writer "$? $!\n";
> } while(1);
> }
> 
> This is a quirk of Perl - "next" doesn't work in a "do { ... } while"
> like "continue" in C/C++ does because it's really a "do { ... }" block
> with a while applied.
> 
> "perldoc perlsyn" suggests just doubling the braces on the loop, but in
> this case a clearer fix (untested) is probably to rewrite the loop in
> the form: "while(1) { ... }"
> 
> The actual current effect of "next" here seems to be to terminate the
> loop.  That seems problematic on the face of it, but in practice I
> think the only cases where it would trigger are an entirely empty line or
> "0" with no newline, both of which would mean the end of the input
> stream.

Oh, except that there's a chomp() first, so it seems we'll exit early
if we read a blank line or a line containing only "0".  I guess those
are unlikely as this seems to be reading commands to execute.

> But maybe the loop should terminate at the end of the input stream,
> since otherwise it seems this loop will never terminate if the stream
> ends without "exit" being received.  So perhaps the better fix is:
> 
> if (!$line || $line eq 'exit') {
> exit(0);
> }

So this won't work as-is.

The problematic code is from a patch we're applying:

https://sources.debian.org/src/abi-compliance-checker/2.3-0.2/debian/patches/oom-exec-helper.patch/

Cc-ing Steve Langasek as the author of that patch.

Cheers,
Olly

Bug#934977: [Pkg-emacsen-addons] Bug#934977: Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25

[Nicholas D Steeves]

user debian-emac...@lists.debian.org
usertags 934977 -elpafy

Sean Whitton  writes:

> Hello,
>
> On Sun 09 Feb 2020 at 03:30PM -07, Nicholas D Steeves wrote:
>
>> I've tagged this bug "elpafy" because conversion to dh-elpa is best
>> practises for team-maintained packages.  I also wonder if this will
>> indirectly solve #863467 ?
>
> Kiwamu specifically wanted to be sure this package worked with xemacs,
> which is why it doesn't use dh_elpa (I sponsored the upload).
>

Sorry, I didn't realise this, and have unset the elpafy tag.  Would you
please add a note somewhere in verilog-mode/debian/?  I'm guessing
Kiwamu knew people who exclusively used xemacs so it seems to be a "what
users want/need" kind of thing.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#839961: libjs-d3: please package new upstream release

[GCS]

Hi Paul, Balint,

On Wed, Jan 15, 2020 at 3:51 PM Balint Reczey
 wrote:
> On Wed, 23 Jan 2019 20:12:56 +0100 Paul Gevers  wrote:
> > On Thu, 06 Oct 2016 22:03:43 +0200 Paul Gevers  wrote:
> > > Upstream d3 is very active and currently runs at 4.2.6. Please consider
> > > updating the libjs-d3 package.
> >
> > Any progress on this? I'd love to have the new version in Buster. I
> > offer help if you need or want it.
 There's definitely need for help, please read on.

> I believe the state of this package is a perfect fit for salvaging:
> https://wiki.debian.org/PackageSalvaging
 It's a bit more complex situation while it's clear it's my bad that
no activity shown on this package.

> I'd like to have a fresh d3 in next Ubuntu LTS and also in Bullseye,
> but I don't have enough free time now to salvage the package myself.
> :-(
 Wanted to go into details, but let me be brief now. When I packaged
D3.js it was one source tree only with dependencies packaged. Then its
build system switched to rollup, not packaged back then. With time it
further evolved and became highly modularized, meaning multiple source
tarballs.
Currently it has 45 (forty-five) modules, depending on each other like
a tree structure. Random check showed at least one of these has
unpackaged other JavaScript dependency. In really short, just see the
top level D3.js dependency list[1] which shows 31 (thirty-one)
immediate D3 modules dependency. That means about 50+ (fifty+)
JavaScript packages need to be created, uploaded and accepted to the
archives.
Do you know anyone who can take such a huge task?
@Balint: What's the best way to talk with you in personally? A meeting
or a phone call would do; maybe a chat on some platform.

Regards,
Laszlo/GCS
[1] https://github.com/d3/d3/blob/master/package.json

Bug#951079: zfs-dkms: Uses only single core during compile

[Witold Baryluk]

Package: zfs-dkms
Version: 0.8.3-1
Severity: normal

This is actually for zfs-dkms 0.8.2-3~bpo10+1 from buster-backports, but
I am filling this bug on another computer running sid.

During zfs-dkms post-install, it build modules for all installed kernels,
I did notice it is very slow, and looking at the top, it looks to be
using just a single core during a build process.

Manually building zfs from source with make -j8 was significantly faster.

The machine I was doing this on has 8 cores (AMD FX-8320). On more modern
machines (like Ryzen 3950, or 2950X, difference could be more dramatic).

I have no idea if this is the issue with zfs-dkms or dkms in general, but
compiling using single process only isn't the best idea. Use all (or half
maybe?) available cores if possible, and limit the impact to the rest of
the system using schedtool or nice. The apt install / dpkg itself will
impact the CPU usage anyway, so it is totally expected for the CPU usage
to be high during this process. So I see no reason to not use all
available core and speed up the install / upgrade.


Cheers,
Witold






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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  dkms   2.8.1-5
ii  file   1:5.38-4
ii  libc6-dev [libc-dev]   2.29-10
ii  libpython3-stdlib  3.7.5-3
ii  lsb-release11.1.0
ii  perl   5.30.0-9
ii  python3-distutils  3.8.0-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.4.13-1
ii  zfs-zed 0.8.3-1
ii  zfsutils-linux  0.8.3-1

Versions of packages zfs-dkms suggests:
pn  debhelper  

-- debconf information excluded

Bug#949739: workaround failed

[gpe]

Hi,

Are you sure about the command:

update-alternatives --config ip{,6}tables

Here is the result for me:

# LANG=C update-alternatives --config ip{,6}tables
update-alternatives: error: unknown argument 'ip6tables'

BR

Bug#951078: simage: autopkgtest regression: output to stderr

[Paul Gevers]

Source: simage
Version: 1.8.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of simage the autopkgtest of simage fails in
testing when that autopkgtest is run with the binary packages of simage
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
simage from testing1.8.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems the
tool you're using has started to report to stderr. Either suppress that
or enable the allow-stderr restriction.

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/simage/4244117/log.gz

autopkgtest [18:53:44]: test check2: [---
build: OK
read image: a_in.png...done
image size: (300, 300), components: 3
save image 'a_out.png'...done
total 76
-rw-r--r-- 1 1000 1000 20110 Feb  9 18:53 a_in.png
-rw-r--r-- 1 1000 1000 22098 Feb  9 18:53 a_out.png
-rwxr-xr-x 1 1000 1000 21512 Feb  9 18:53 simage-convert
-rw-r--r-- 1 1000 1000  7432 Feb  9 18:53 simage-convert.c
run: OK
autopkgtest [18:53:44]: test check2: ---]
autopkgtest [18:53:44]: test check2:  - - - - - - - - - - results - - -
- - - - - - -
check2   FAIL stderr: read image: a_in.png...done
autopkgtest [18:53:44]: test check2:  - - - - - - - - - - stderr - - - -
- - - - - -
read image: a_in.png...done
image size: (300, 300), components: 3
save image 'a_out.png'...done



signature.asc
Description: OpenPGP digital signature

Bug#950884: thonny: Please package new upstream version 3.2.7 (for python3.8 compatiblity)

[Aivar Annamaa]

Thank you for the notice!

I plan to update the package, but I'm not sure I understand the problem 
-- Thonny's dependencies already allow any asttokens version newer than 
1.1.10. I'm pretty sure Thonny 3.2.1 (the current version in Debian) 
will handle newest asttokens just fine. I'm not sure about tests, 
though, they may be more picky than necessary ...


Anyway, I'll update the package and hopefully everything works out.

Best regards,
Aivar

On 07.02.2020 19:19, Boyuan Yang wrote:

Source: thonny
Version: 3.2.1-1
Severity: important
X-Debbugs-CC: naturesha...@debian.org aivar.anna...@gmail.com

Dear thonny maintainers,

When trying to solve https://bugs.debian.org/950072 in package python-
asttokens, I found that the compatibility of asttokens was fixed in a new
upstream release that made a backward-incompatible change. Fortunately the
thonny upstream has already made updates in a new upstream version considering
this. Please package the new thonny upstream version to ensure that the
python3.8 compatibility issue is kept and that no package is broken due to the
version bump.

Bug#951053: transition: libmysofa

[Paul Gevers]

Control: tags -1 confirmed

Hi IOhannes,

On 10-02-2020 14:15, IOhannes m zmoelnig wrote:
> The new upstream of libmysofa comes with a soname bump from libmysofa.so.0 to
> libmysofa.so.1
> consequently the binary package in Debian has to be renamed from libmysofa0 to
> libmysofa1.

[...]

> Thanks for scheduling a transition slot.

Please go ahead in unstable.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#951077: git-review: man page out of sync with implementation

[Guillem Jover]

Package: git-review
Version: 1.27.0-1
Severity: normal

Hi!

The man page is out of sync with the current implementation and is
missing at lots of command-line options, assuming that:

  $ git-review --help

is up-to-date. :)

Thanks,
Guillem

Bug#951033: [3dprinter-general] Bug#951033: cura: UI not usable in 4.4.1

[Mateusz Skowroński]

Hi.
Here is my monitor info:

f3nix@bigspider:~$ xdpyinfo | grep -B 2 resolution
screen #0:
  dimensions:7680x4320 pixels (1393x784 millimeters)
  resolution:140x140 dots per inch
f3nix@bigspider:~$

No scaling.

Fonts look good but the controls are misplaced.

I'm attaching the start log.

There are some warnings regarding widths, heights... I do not know if
it would be useful.

Cheers,
Mateusz

pon., 10 lut 2020 o 09:01 Gregor Riepl  napisał(a):
>
> > After upgrading to 4.4.1 the UI is not usable. See screenshot. The dialog is
> > all messed up.
> > Appimage version works as expected.
> >
> > Deleting the config folder is even worse. I can't get past the settings 
> > wizard.
>
> Thank you for the bug report.
> The issue is known and reproducible, but a solution isn't known yet.
>
> I suspect it's got something to do with Qt and HiDPI handling.
>
> What DPI setting do you use for font rendering?



-- 
AKA f3nix AKA metyl AKA skowri ;)
/usr/lib/python3/dist-packages/UM/PluginRegistry.py:4: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
[MainThread] UM.Resources.__initializeStoragePaths [417]: Initializing storage paths
[MainThread] UM.Resources.__initializeStoragePaths [427]: Config storage path is /home/f3nix/.config/cura/4.4
[MainThread] UM.Resources.__initializeStoragePaths [435]: Data storage path is /home/f3nix/.local/share/cura/4.4
[MainThread] UM.Resources.__initializeStoragePaths [447]: Cache storage path is /home/f3nix/.cache/cura/4.4
[MainThread] UM.PackageManager.__init__ [52]: Found bundled packages JSON file: /usr/share/cura/resources/bundled_packages/cura.json
[MainThread] UM.PackageManager.__init__ [52]: Found bundled packages JSON file: /usr/share/uranium/resources/bundled_packages/uranium.json
Attribute Qt::AA_UseDesktopOpenGL must be set before QCoreApplication is created.
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [105]: Trying OpenGL context 4.1...
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [115]: Yay, we got at least OpenGL 4.1 core: 4.1 Core profile
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [162]: OpenGL renderer type for this OpenGL version: GeForce GTX 1660 Ti/PCIe/SSE2
[MainThread] UM.Qt.QtApplication.initialize [142]: Detected most suitable OpenGL context version: 4.1 Core profile
[MainThread] UM.Qt.QtApplication.initialize [149]: Initializing job queue ...
[MainThread] UM.Qt.QtApplication.initialize [153]: Initializing version upgrade manager ...
[MainThread] UM.PackageManager._loadManagementData [139]: Loaded bundled packages data from /usr/share/cura/resources/bundled_packages/cura.json
[MainThread] UM.PackageManager._loadManagementData [139]: Loaded bundled packages data from /usr/share/uranium/resources/bundled_packages/uranium.json
[MainThread] UM.PackageManager._loadManagementData [156]: Loaded user packages management file from /home/f3nix/.local/share/cura/4.4/packages.json
[MainThread] UM.PackageManager._saveManagementData [224]: Package management file /home/f3nix/.local/share/cura/4.4/packages.json was saved
[MainThread] UM.PluginRegistry.initializeBeforePluginsAreLoaded [86]: Loading plugin configuration file '/home/f3nix/.config/cura/4.4/plugins.json'
2020-02-10 20:58:09,485 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin ConsoleLogger
2020-02-10 20:58:09,490 - INFO - [MainThread] CuraEngineBackend.CuraEngineBackend.__init__ [78]: Found CuraEngine at: /usr/bin/CuraEngine
2020-02-10 20:58:09,491 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin CuraEngineBackend
2020-02-10 20:58:09,493 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin SelectionTool
2020-02-10 20:58:09,496 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin TranslateTool
2020-02-10 20:58:09,499 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin CameraTool
2020-02-10 20:58:09,502 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin RotateTool
2020-02-10 20:58:09,506 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin ScaleTool
2020-02-10 20:58:09,508 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin MirrorTool
2020-02-10 20:58:09,510 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin LocalContainerProvider
2020-02-10 20:58:09,511 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin SimpleView
2020-02-10 20:58:09,512 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin FileLogger
2020-02-10 20:58:09,514 - INFO - [MainThread] UM.PluginRegistry.loadPlugin [406]: Loaded plugin OBJWriter
/usr/lib/python3.7/importlib/_bootstrap.py:219: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  return f(*args, **kwds)

Bug#951059: [debian-mysql] Bug#951059: mariadb-server-10.3: lc_messages=fr_FR leads to upgrade crash with apt

[Otto Kekäläinen]

Thanks for reporting.
At least the packaging in Debian has not changed. This is probably an
upstream bug.

Have you checked jira.mariadb.org for bugs related to "lc_messages = fr_FR" ?

What is the version you had before upgrading?

- Otto

Bug#951076: abi-compliance-checker: Invalid use of Perl "next"

[Olly Betts]

Package: abi-compliance-checker
Version: 2.3-0.2
Severity: normal

I've noticed this message repeatedly appearing in the ci.debian.net logs:

Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 10171.

That's the "next" in this function:

sub exec_helper(@)
{
my ($reader, $writer) = @_;
do {
chomp($line = <$reader>);
next if (!$line);
if ($line eq 'exit') {
exit(0);
}
system($line);
print $writer "$? $!\n";
} while(1);
}

This is a quirk of Perl - "next" doesn't work in a "do { ... } while"
like "continue" in C/C++ does because it's really a "do { ... }" block
with a while applied.

"perldoc perlsyn" suggests just doubling the braces on the loop, but in
this case a clearer fix (untested) is probably to rewrite the loop in
the form: "while(1) { ... }"

The actual current effect of "next" here seems to be to terminate the
loop.  That seems problematic on the face of it, but in practice I
think the only cases where it would trigger are an entirely empty line or
"0" with no newline, both of which would mean the end of the input
stream.

But maybe the loop should terminate at the end of the input stream,
since otherwise it seems this loop will never terminate if the stream
ends without "exit" being received.  So perhaps the better fix is:

if (!$line || $line eq 'exit) {
exit(0);
}

Cheers,
Olly

Bug#943173: Not in testing yet?

[Dmitry Shachnev]

Hi all,

On Mon, Feb 10, 2020 at 06:59:17PM +0100, Axel Beckert wrote:
> [...]
>
> Florian Bruhin wrote:
> > Out of curiosity, is there a way I could've found out myself?
> > https://qa.debian.org/excuses.php?package=pyqt5webengine doesn't
> > seem to say much about this situation.
>
> Probably not. :-(

Well, there is this page, but its contents can be tricky to decode:

https://release.debian.org/britney/update_output.txt

Here it says:

trying: pyqt5webengine
skipped: pyqt5webengine (5, 36, 101)
got: 20+0: a-2:a-0:a-0:a-0:i-17:m-0:m-0:p-0:s-1
* amd64: calibre

So calibre is the obstacle for pyqt5webengine to migrate. Then you go to
https://tracker.debian.org/pkg/calibre, which has more information why.

By the way, calibre built fine on all architectures now, but now it is blocked
on gcc-10.

This page has more information on how to parse that file:

https://release.debian.org/doc/britney/short-intro-to-migrations.html#debugging-failed-migration-attempts

> > I was a bit worried about the exact timeline when this happens, since 27th 
> > is
> > the feature freeze for Ubuntu 20.04, and I'd really like qutebrowser 
> > v1.10.0 be
> > in there (given that it fixes various issues and will be supported by Ubuntu
> > for five years).
>
> Ubuntu takes packages from Unstable (and Experimental, even without
> asking why they are in Experimental!), not from Testing.

For clarity, automated syncs are only from unstable, if some package was
copied from experimental then someone did it manually.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#950627: Regression: Unable to config with CMake

[Felix Geyer]

On 10.02.20 02:24, Brian Clinkenbeard wrote:

I believe I am also having this issue. "find_package(SDL2 REQUIRED)" in
CMakeLists.txt yields the following error:
-- Target architecture: x86_64


CMake Error at
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
(message):
    Could NOT find SDL2 (missing: SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393
(_FPHSA_FAILURE_MESSAGE)
    externals/cmake-modules/FindSDL2.cmake:239
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
    CMakeLists.txt:155 (find_package)


Without access to the code (externals/cmake-modules/FindSDL2.cmake in this case)
I can't really help debug it.

My guess is that the custom FindSDL2 module is doing something wrong
when it tries to find the SDL2 header files.
It doesn't seem to search in all system include paths.
The headers have been moved from /usr/include/SDL2 to /usr/include//SDL2.

Cheers,
Felix

Bug#865495: tor >= 0.2.7.4-rc-1 renders CAP_NET_BIND_SERVICE on server transport plugins ineffective

[David Fifield]

On Tue, Jan 14, 2020 at 08:56:50AM +, Peter Palfrader wrote:
> Great.  So if you want your service to be able to gain extra privileges,
> you set NoNewPrivileges to false in your local override file.

Thanks for the hint about an override file. That's better than editing
/lib/systemd/system/tor@* because it will survive upgrades of the tor
package.

For the benefit of anyone who finds this bug report, here is what I did
to use an override or "drop-in" file.
https://bugs.torproject.org/18356#comment:10

$ systemctl edit tor@.service tor@default.service
In the first editor that appears, enter the following text, then save
and quit:
[Service]
NoNewPrivileges=no
A second editor will appear. Enter the same text, then save and quit.
[Service]
NoNewPrivileges=no
If all goes well, you will have two new files under /etc:
/etc/systemd/system/tor@.service.d/override.conf
/etc/systemd/system/tor@default.service.d/override.conf
Restart tor. There is no need to run "systemctl daemon-reload".
$ service tor restart

Bug#933059: 933...@bugs.debian.org

[Javier Miqueleiz]

I have an identical setup here (root FS on top of LVM on top of LUKS on
top of MD) and can confirm the bug. I'm running Debian Buster 10.2.

One little comment.  The MD array requires manual activation (with mdadm
--run /dev/md0) in order for the system to boot. But I found that this
manual procedure is only needed, apparently, once (i.e., the first time
the array is seen in a degraded state). Subsequent boots will go fine,
even if the MD array continues to be degraded.

Thanks Magnus for reporting the bug and for the patch. It also works on
my system. ;) :)

I did some further tests on a virt-manager VM, plugging and unplugging
discs. In my tests, I found the patch has a little side effect when the
lacking disc is plugged in again. With no patch, I found that after
adding the disc again to the VM, the array with the rootfs is
automatically resynced (the one with /boot is not).


root@debian10-mdadm:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5]
[raid4] [raid10]
md1 : active raid1 sda3[1] sdb3[2]
  3877888 blocks super 1.2 [2/2] [UU]
    bitmap: 1/1 pages [4KB], 65536KB chunk

md0 : active raid1 sdb2[2]
  248832 blocks super 1.2 [2/1] [U_]
    bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: 

root@debian10-mdadm:~# mdadm --manage /dev/md0 --re-add /dev/sda2
mdadm: re-added /dev/sda2

(md1 is the array for the rootFS/LVM/LUKS. md0 is the array for /boot)


With the patch, the behavior is a bit different. No array is
automatically resynced: you have to do it, manually, with mdadm.


root@debian10-mdadm:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5]
[raid4] [raid10]
md1 : active raid1 sdb3[2]
  3877888 blocks super 1.2 [2/1] [U_]
    bitmap: 1/1 pages [4KB], 65536KB chunk

md0 : active raid1 sdb2[2]
  248832 blocks super 1.2 [2/1] [U_]
    bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: 

root@debian10-mdadm:~# mdadm --manage /dev/md0 --re-add /dev/sda2
mdadm: re-added /dev/sda2
root@debian10-mdadm:~# mdadm --manage /dev/md1 --re-add /dev/sda3
mdadm: re-added /dev/sda3

(md1 is the array for the rootFS/LVM/LUKS. md0 is the array for /boot)


I'm not completely sure if this side effect is relevant or not. A long
time ago (>10 years), Linux MD RAID always re-added, IIRC, missing discs
from the array (if they were previously members of it). This was the
expected behavior. Nowadays, I've seen, IIRC, that sometimes it happens
and sometimes not (depending on the distro, initramfs, mdadm version,
etc.). Don't know what is the expected behavior (if any) these days.

Regards,

Ethereal.

Bug#875847: qttools5-dev-tools: .qhc files not reproducible

[Vagrant Cascadian]

On 2017-09-15, Laurent Bigonville wrote:
> It seems that qcollectiongenerator is generating files that are
> containing the creation time of the qhc file (LastRegisterTime and
> CreationTime), making them non-reproducible. See:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/setools.html
>
> To make the build reproducible, qcollectiongenerator should probably be
> patched to support SOURCE_DATE_EPOCH to be able to pass the debian/changelog
> date instead of the current date.

This seems partially fixed in recent qttools-opensource-src,
implementing SOURCE_DATE_EPOCH for LastRegisterTime and CreationTime,
but it is still affected by timezone variations. TimeStampTable appears
to still ignore SOURCE_DATE_EPOCH.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#951060: libreoffice-writer: Please make the package modify the user config while settings if a setting is deprecated

[Rene Engelhard]

Hi,

On Mon, Feb 10, 2020 at 03:29:21PM +0100, Jean-Philippe MENGUAL wrote:
> So far, I checked the box "Save and Open dialogs" in Tools - Custimize- 
> general
> tab. Lo decided not maintaining this dialog and using GTK ones only.

Wrong.

> They removed the checkbox, but the setting stays existing il LO.

No, they didn't? I have it here.

Maybe you somehow forced the desktop/VCLPlug to gtk2 (which indeed got
removed upstream)?

If you did so in the dialog that is and was always bad. There's envvars
and desktop detection and even in buster one should have used gtk3 (yes,
I know xfce uses gtk2 in buster) :-)

> I propose Debian, as a distributor, to include in its setting of the package 
> the
> removal of the deprecated settings and status to ensure the end-user will have
> the GTK box, instead of a kind of transition between the old and new ones.

I propose people setting stuff sensibly ;)

Regards,

Rene

Bug#943173: Not in testing yet?

[Axel Beckert]

Hi Florian and Dmitry,

Dmitry Shachnev wrote:
> > I don't really understand why - can someone elaborate on what's going on?
> 
> That is because the Python 3 version of calibre failed to build on two
> architectures (arm64, mipsel), so calibre in testing still uses Python 2,
> so some packages which dropped Python 2 support (like pyqt5webengine)
> cannot migrate to testing.

Thanks for that explanation! I was wondering, too, and suspected
something like that, but didn't bother digging deeper.

Previously there was a "more excuses" link besides the "excuses" link
which IIRC displayed such tricky correlations, but I can't find that
anymore.

> I think on February 16th calibre will be auto-removed from testing, and
> after that all those packages will be able to migrate. In the worst case,
> they will be removed for a short time but then will migrate anyway (but now
> that we have some activity on this bug, I don't think that will be the case
> for pyqt5webengine).

Ack, I expect the same, i.e.: We don't have to worry. :-)

Florian Bruhin wrote:
> Out of curiosity, is there a way I could've found out myself?
> https://qa.debian.org/excuses.php?package=pyqt5webengine doesn't
> seem to say much about this situation.

Probably not. :-(

> I was a bit worried about the exact timeline when this happens, since 27th is
> the feature freeze for Ubuntu 20.04, and I'd really like qutebrowser v1.10.0 
> be
> in there (given that it fixes various issues and will be supported by Ubuntu
> for five years).

Ubuntu takes packages from Unstable (and Experimental, even without
asking why they are in Experimental!), not from Testing.

And qutebrowser 1.10.0-1 is in Ubuntu Focal for two days already, so
you don't have to worry anymore:

https://packages.ubuntu.com/focal/qutebrowser
https://launchpad.net/ubuntu/+source/qutebrowser

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#950993: orage: calendar window doesn't work anymore

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2020-02-10 at 11:21 +0100, B wrote:
> I'm sorry for the noise and your wasted time, but thanks for your help ;
> may be a warning about not re-using old xfce4 configuration files when
> upgrading would be of some help for others.

Well, that shouldn't be a problem, so if you manage to identify which setting
causes an issue, I think it'd help.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5BlwQACgkQ3rYcyPpX
RFtZrAf/XUhUy9Y211/5MAK5ND7oFNUdnto21ITC7Q6+ErdeALMEYd/Is0IYSk8+
iIZeE1WOHnWUEQ6kd4dnfJl9ngor79p/LvWFykiSMR1hxh97502UHWo5N0gHtSCt
mAqXw9zWsEMTKpQtMM8womW2CO1XU8qh6S9FCc1F5dqys7brz0NEbilvSw4hYMKe
loWxHWsv+S8vdR8KkWrUn2qCcPMVAWsyLJySTODAkjU4tnzgkz316yYmQzg+07F4
KjK9BIqyKJH9YKtT5TSsCNeAXIRT8+ZOdLx3KDZjXJ4efDlu9r5en1oQpZetqCNN
fLBvdrRkg+ylfvWwzTbozWfwN8k11Q==
=WlsD
-END PGP SIGNATURE-

Bug#951075: ipmctl 02.00.00.3673+ds-3 breaks on ACPI PMTT v0.1 BIOS

[Martin Pollard]

Package: ipmctl

Version: 02.00.00.3673+ds-3


When I run `ipmctl show -memoryresource' on my machine I get an error that did 
not happen on the +really01 packages:

One or more DIMMs have invalid PCD data. A platform reboot is recommended to 
restore valid PCD data, then try again.
This regression has been fixed upstream:
https://github.com/intel/ipmctl/issues/123


There is a corresponding Ubuntu bug report for this as well:

https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1860537



-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Bug#951074: Missing depend libcache-cache-perl

[Jörg Frings-Fürst]

Package: munin-plugins-core
Version: 2.0.56-1
Severity: important
Tags: newcomer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello, the plugin mysql_ needs libcache-cache-perl.

Without I get:

[quote]
# munin-run mysql_sort
Missing dependency Cache::Cache at /etc/munin/plugins/mysql_sort line 902
[/quote]

CU
Jörg



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

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

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.56-1
ii  perl  5.30.0-9

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-5

Versions of packages munin-plugins-core suggests:
pn  conntrack 
ii  default-mysql-client  1.0.5
pn  ethtool   
ii  hdparm9.58+ds-4
pn  libcache-cache-perl   
ii  libdbd-mysql-perl 4.050-3
ii  libdbd-pg-perl3.10.3-1
ii  libhttp-date-perl 6.05-1
pn  liblwp-useragent-determined-perl  
ii  libnet-dns-perl   1.21-1
ii  libnet-ip-perl1.26-2
ii  libnet-irc-perl   0.79-2
pn  libnet-ldap-perl  
pn  libnet-netmask-perl   
pn  libnet-telnet-perl
ii  libxml-parser-perl2.46-1+b1
ii  libxml-simple-perl2.25-1
ii  lm-sensors1:3.6.0-2
ii  logtail   1.3.20
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python3   3.7.5-3
ii  ruby  1:2.5.2
ii  smartmontools 7.1-1

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl5BkBcACgkQCfifPIyh
0l0t0RAAwyuVj9U3af2p+HhamkHFD9VRt9KS++erocCvi5Crw0mELFa+9Wohvpz2
v13yOSGUwyV7ZHA+G3CwRlc+Y4AQEVvmDqPnF3GWvMoLwAN7G4pN3eZpwU7ll6gZ
Gjq9H/MQwSrSNN84nwPCko8UMdUHqj5fEk2xoPpI6WO6JC2Z2aBG5vrofWDVR/3b
FFaaNEs4V3ZlhxPZdFNflLaQxRhmktxKxb5siFgyFbFk+DYXLNEEGAnqqugTfbaQ
Xh3bUMagVAfofW5CzxwNxp/NK27k+p1DnpuFSLJDpLjpAK9o6z7nb6cb6zzYq0wT
l1IchXQNniQ5PX5pQhw5Z554L0NDfBxxqh7ZYLwloQZ1FwSxmpBdiqUltlFKaoVR
Qjcr7TGV5o5uqutS3jXgdyfNzCSZNYUK2McGU23Vu+VDNXjEyX/2vUVoBCf4Y+M5
jaQlm9nuThPxe/XYbLsdgrtnKsxkLfmRBTkLWOYLRjE/vdyDgsIDQ7slu6f3kDhZ
OhDKqYwBYzvyQVasoERBm/9Tonf7SoESKXX44pxtcNtrnxHbpPJp3wuBhpl6SO5A
8tNOD2svHu2BMC5NagvCsP1ZHPuu0mG3fLPtmfuDlx6Z0b6YdlUu9mvE3B3KVyS2
DFWEdwRogsv57K8rV2Dl8vYWcRpLe7bSqU8u9lOZpwkRjd4DpP0=
=6hen
-END PGP SIGNATURE-

Bug#950038: Looks like a bug in httplib2 rather than on wsgi-intercept

[Håvard Flaget Aasen]

According to [1] and [2] this issue was fixed in package wsgi-intercept 
version 1.9.0

Though they write that the change was indeed in the httplib2 package.

I have not tested the new release of wsgi-intercept myself.


Håvard

[1] https://github.com/cdent/wsgi-intercept/issues/57
[2] https://github.com/cdent/wsgi-intercept/pull/58

Bug#950853: gffutils tests are timing out with Python 3.8

[Stefano Rivera]

Control: tag -1 + patch

Hi Matthias (2020.02.07_05:18:06_-0800)
> gffutils tests are timing out with Python 3.8, while they succeed when run 
> with
> 3.7.  Currently only seen in an Ubuntu focal environment, however the upstream
> sources don't mention 3.7 and 3.8 at all.

I spent some time debugging this last week, and I *think* the cause is
https://bugs.python.org/issue38501

This patch seems to avoid it: https://github.com/daler/gffutils/pull/155

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#820081: libreoffice-writer: can't open LibreOffice Writer

[Jan Jona Javoršek]

Hi! 


I can confirm the same bug with the now current 6.1.5-3+rpi1+deb10u5
(ruinning on a raspberry PI 4). 


Removing libreoffice-gtk3 made writer start without issues (but without
theme integration). Writer displays no issues with libreoffice-gtk2 (and
runs with the correct theme). If I reinstall libreoffice-gtk3, the issue
returns. 


I can attach strace and package info if necessary, but it looks related
to gtk3 theme integration. 

Thank you! 


-jan

Bug#951072: ITP: htscodecs -- Custom compression for CRAM and others

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: htscodecs -- Custom compression for CRAM and others
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: htscodecs
  Version : 0.5
  Upstream Author : , Genome Research Ltd.
* URL : https://github.com/jkbonfield/htscodecs/
* License : BSD-3-clause
  Programming Lang: C
  Description : Custom compression for CRAM and others
 This library implements the custom CRAM codecs used for "EXTERNAL" block
 types. These consist of two variants of the rANS codec (8-bit and 16-bit
 renormalisation, with run-length encoding and bit-packing also supported
 in the latter), a dynamic arithmetic coder, and custom codecs for name/ID
 compression and quality score compression derived from fqzcomp.
 .
 They come with small command line test tools to act as both compression
 exploration programs and as part of the test harness.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/htscodecs

Bug#951073: result close button disabled

[jnqnfe]

Package: gedit-plugin-find-in-files
Version: 3.34.0-3

I've been meaning to report this for a long time...

Initially the close button on the results is disabled. It only becomes
enabled upon certain actions like switching to another tab. Very
annoying.

Bug#942934: cvs-fast-export does not depend on Python 2

[Eric Raymond]

The reason given for removing cvs-fast-export is, I believe, in error.  I
went to considerable effort to prepare it for Python 2 EOL and find it
quite annoying that it was removed anyway.

The Python scripts in cvs-fast-export are written to run correctly under
either Python 2 or Python 3. The techniques used are described here:

http://www.catb.org/esr/faqs/practical-python-porting/

Thus, cvs-fast-export can use Python 2 if that is all the environment has
available, but it will cheerfully use Python 3.  It doesn't care which
interpreter "python"redirects to.

The removal is causing problems for one of my other packages, reposurgeon.
It has cvs-fast-export as a dependency.

Please either reinstate cvs-fast-export or file a bug against it explaining
how it actually fails to be Python-version-agnostic.

Bug#940708: [Pkg-javascript-devel] Component database

[Xavier]

Le 10/02/2020 à 15:13, Jonas Smedegaard a écrit :
> Hi Xavier,
> 
> Quoting Xavier (2020-02-10 15:06:00)
>> I wrote a little feature in lintian that will build a component 
>> database (https://salsa.debian.org/lintian/lintian/commit/36469e3), 
>> released in lintian 2.51.0.
>>
>> Next step, build node.js components database (name+version given by 
>> package.json). This will avoid having to use too long version (See 
>> https://bugs.debian.org/940708)
> 
> I don't follow how changes to lintian can help solve bug#940708 - but 
> instead of replying here, I recommend that you clarify by posting to 
> that bug.
> 
>  - Jonas

1. Because of component embedding (required by ftpmaster), we use uscan
   components in JS Team
2. Then to follow upstream changes, we can have a version that stores
   all important modules versions in it
3. Then for important packages like acorn and if DD wants to follow all
   upstream changes, version becomes crazy (this bug for example)
4. I proposed an MR to acorn to reduce version,  => not accepted [1]
5. I proposed an MR to devscripts to compact version => not accepted [2]
6. Then I had the idea of another way to follow upstream changes,
   that could have some other benefits:
   a. lintian will generate some classification tags
   b. we will be able to have an up-to-date DB of embedded component
   c. we will be able to build a new tracker that displays result
   d. Security Team will have a better view on our embedded components
  (${nodejs:Provides} shows only components installed in nodejs root
   directories - name + real-version)
   e. npm2deb will be able to show already-embedded-component when a
  contributor uses `npm2deb depends foo`

For now, I didn't find a better way to solve this bug (important IMO).

acorn-6 is needed for Node.js 12 migration. I think we have to find a
way to fix this issue to avoid the shame of having published such
version string.

Using lintian tags is my 3rd proposal here and probably the last.

As usual, sorry for my poor English.

[1]: https://salsa.debian.org/js-team/acorn/merge_requests/4
[2]: https://salsa.debian.org/debian/devscripts/merge_requests/156

Bug#951071: debian-edu-config: on roaming workstations prep local user's firefox profile and make sure debian-edu.default gets used/created

[Mike Gabriel]

Package: debian-edu-config
Version: 2.11.12

When playing with roaming workstations, I noticed that the  
pam_mklocaluser'ed new local user does not have a debian-edu.default  
Firefox profile, but a profile folder of random name created by Firefox.


To control Firefox's behaviour, we need to add a little  
/etc/mklocaluser.d/ script, such as:


```
#!/bin/sh

set -e

GROUP=$(id -g "$USER")
HOMEDIR="/home/$USER"

mkdir -p "$HOMEDIR/.mozilla/firefox/debian-edu.default"
if [ ! -e "$HOMEDIR/.mozilla/firefox/profiles.ini" ]; then
	cp "/usr/share/debian-edu-config/profiles.ini.ff"  
"$HOMEDIR/.mozilla/firefox/profiles.ini"

fi
if [ ! -e "$HOMEDIR/.mozilla/firefox/installs.ini" ]; then
	cp "/usr/share/debian-edu-config/installs.ini"  
"$HOMEDIR/.mozilla/firefox/installs.ini"

fi
chmod -R u+w,go-rwx "$HOMEDIR/.mozilla/"
chown -R $USER:$GROUP "$HOMEDIR/.mozilla/"

mkdir -p "$HOMEDIR/.thunderbird/debian-edu.default"
if [ ! -e "$HOMEDIR/.thunderbird/profiles.ini" ]; then
	cp "/usr/share/debian-edu-config/profiles.ini"  
"$HOMEDIR/.thunderbird/profiles.ini"

fi
chmod -R u+w,go-rwx "$HOMEDIR/.thunderbird/"
chown -R $USER:$GROUP "$HOMEDIR/.thunderbird/"
```

Greets,
Mike
--

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

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



pgpfWZbjq8VwD.pgp
Description: Digitale PGP-Signatur

Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

[Mike Gabriel]

Package: debian-edu-config
Version: 2.11.12
Severity: wishlist

Driving the fetch-ldap-cert logic another step forward. We should, on  
retrieval of Debian-Edu_rootCA.crt, move that file to  
/usr/local/share/ca-certificates/debian-edu/ and run  
update-ca-certificates afterwards.


This assures that Debian-Edu_rootCA is available in the system-wide CA  
bundle in /etc/ssl/certs/ca-certificates.crt.


This issue relates to #926388 (let Firefox trust  
/etc/ssl/certs/ca-certificates.crt)


Mike
--

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

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



pgpAraRbNrG1V.pgp
Description: Digitale PGP-Signatur

Bug#943173: Not in testing yet?

[Florian Bruhin]

Hey Dmitry,

On Thu, Feb 06, 2020 at 01:04:35PM +0300, Dmitry Shachnev wrote:
> Hi Florian!
> 
> On Thu, Feb 06, 2020 at 10:36:22AM +0100, Florian Bruhin wrote:
> > Hey,
> >
> > It looks like 5.14.0-2 with the fix isn't in testing yet? See
> > https://tracker.debian.org/pkg/pyqt5webengine
> > https://qa.debian.org/excuses.php?package=pyqt5webengine
> >
> > I don't really understand why - can someone elaborate on what's going on?
> 
> That is because the Python 3 version of calibre failed to build on two
> architectures (arm64, mipsel), so calibre in testing still uses Python 2,
> so some packages which dropped Python 2 support (like pyqt5webengine)
> cannot migrate to testing.

Thanks a lot for the explanation! Out of curiosity, is there a way I could've
found out myself? https://qa.debian.org/excuses.php?package=pyqt5webengine
doesn't seem to say much about this situation.

> I think on February 16th calibre will be auto-removed from testing, and
> after that all those packages will be able to migrate.

FWIW it looks like there has been some activity for calibre:
https://tracker.debian.org/news/1099652/accepted-calibre-4994dfsgreally4100py3-1-source-into-unstable/
https://tracker.debian.org/news/1099754/accepted-calibre-4994dfsgreally4100py3-2-source-into-unstable/

> In the worst case, they will be removed for a short time but then will
> migrate anyway (but now that we have some activity on this bug, I don't think
> that will be the case for pyqt5webengine).

I was a bit worried about the exact timeline when this happens, since 27th is
the feature freeze for Ubuntu 20.04, and I'd really like qutebrowser v1.10.0 be
in there (given that it fixes various issues and will be supported by Ubuntu
for five years).

But indeed, it looks like the autoremoval date shown now is March 7th:
https://tracker.debian.org/pkg/qutebrowser

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#951069: debian-edu-config: roaming workstations tjener-smb bookmark missing in GTK-3 applications

[Mike Gabriel]

Package: debian-edu-config
Version: 2.11.12

When installing a roaming workstation there should be a way to access  
a user's home directory the easy way.


For this etc/mklocaluser.d/20-debian-edu-config added some logic to  
provide GTK and KDE compatible bookmarks.


Unfortunately, this feature got added a while ago and noone until now  
realized that the GTK bookmark was only added for GTK-2 applications.


For GTK-3 applications, another bookmark to another location needs to  
be added to the user's home directory (~/.config/gtk-3.0/bookmarks).


Mike
--

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

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



pgphd4MG9fii0.pgp
Description: Digitale PGP-Signatur

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

> Maybe we should first get to the bottom of your issue before jumping to
> conclusions and producing incorrect/incomplete documentation.

Happily so.

Right now I don't really know how to test this better (as in to get
usable data that'll get us on), let alone how to test this well (as in
without logging in and out of a virtual machine 2x5 times to get one or
two cases of observable behavior).

Any ideas on what more data I could pull out?

chrysn


signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[Michael Biebl]

Am 10.02.20 um 16:29 schrieb chrysn:
> On Mon, Feb 10, 2020 at 03:04:49PM +0100, Ansgar wrote:
>> If I start an xterm via Alt-F2 in gnome, the xterm process runs in a
>> cgroup like gnome-launched-xterm-489694.scope.  gnome-terminal or an
>> xterm started in gnome-terminal run in the gnome-terminal-
>> server.service cgroup.  I expect openbox doesn't do this and processes
>> started by openbox run in the same cgroup as openbox itself.
>>
>> `systemd-cgls` is useful to see how processes are organized into
>> cgroups.
>>
>> The gnome-launched-*.scope has KillMode=control-group, so all processes
>> including background processes like tmux get killed when the unit gets
>> stopped (systemd --user show -p KillMode gnome-launched-scope).
> 
> That does not explain the on-and-off behavior, but helps in
> understanding why processes get killed in the first place.
> 
> Then, however, is KillUserProcesses completely obsolete? A user trying
> to debug a situation like mine will currently wind up in the discussion
> of #825394 and look into KillUserProcesses' documentation. Even if it's
> not completely obsolete, a warning that desktop environment spawned
> processes might also be subject to killing from their desktop
> environment's KillMode would be helpful.

Maybe we should first get to the bottom of your issue before jumping to
conclusions and producing incorrect/incomplete documentation.

Michael




signature.asc
Description: OpenPGP digital signature

Bug#951067: apache2: unable to disable TLSv1

[Olaf Zaplinski]

Package: apache2
Version: 2.4.38-3+deb10u3
Severity: important

Dear Maintainer,

it is not possible to get rid of TLS v1. This is no duplicate of #925061, I 
think.

What I tried:

removed /etc/letsencrypt/options-ssl-apache.conf, see #950735
edited /etc/apache2/mods-enabled/ssl.conf: "SSLProtocol -all +TLSv1.3 +TLSv1.2"
edited etc/apache2/conf-enabled/local.conf: "SSLProtocol -all +TLSv1.3 +TLSv1.2"

Result:
# apache2ctl -t -D DUMP_CONFIG|grep SSLProtocol
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLProtocol -all +TLSv1.3 +TLSv1.2
  SSLProtocol all -SSLv2 -SSLv3
Syntax OK

=> something is enabling TLSv1 again after all config files were parsed. So...

# find /etc/apache2/ | xargs grep SSLProtocol
grep: /etc/apache2/: Is a directory
grep: /etc/apache2/mods-enabled: Is a directory
/etc/apache2/mods-enabled/ssl.conf: SSLProtocol -all +TLSv1.3 +TLSv1.2
grep: /etc/apache2/sites-enabled: Is a directory
grep: /etc/apache2/conf-available: Is a directory
/etc/apache2/conf-available/local.conf:SSLProtocol -all +TLSv1.3 +TLSv1.2
grep: /etc/apache2/mods-available: Is a directory
/etc/apache2/mods-available/ssl.conf:   SSLProtocol -all +TLSv1.3 +TLSv1.2
grep: /etc/apache2/sites-available: Is a directory
grep: /etc/apache2/conf-enabled: Is a directory
/etc/apache2/conf-enabled/local.conf:SSLProtocol -all +TLSv1.3 +TLSv1.2

=> TLSv1 is re-enabled no matter what the config files say.



-- Package-specific info:

-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin2.4.38-3+deb10u3
ii  apache2-data   2.4.38-3+deb10u3
ii  apache2-utils  2.4.38-3+deb10u3
ii  dpkg   1.19.7
ii  lsb-base   10.2019051400
ii  mime-support   3.62
ii  perl   5.28.1-6
ii  procps 2:3.3.15-2

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.39

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.5-1+b1
ii  libaprutil1  1.6.1-4
ii  libaprutil1-dbd-sqlite3  1.6.1-4
ii  libaprutil1-ldap 1.6.1-4
ii  libbrotli1   1.0.7-2
ii  libc62.28-10
ii  libcurl4 7.64.0-4
ii  libjansson4  2.12-1
ii  libldap-2.4-22.4.47+dfsg-3+deb10u1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libnghttp2-141.36.0-2+deb10u1
ii  libpcre3 2:8.39-12
ii  libssl1.11.1.1d-0+deb10u2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2 is related to:
ii  apache2  2.4.38-3+deb10u3
ii  apache2-bin  2.4.38-3+deb10u3

-- Configuration Files:
/etc/apache2/conf-available/security.conf changed:
ServerTokens Prod
ServerSignature Off
TraceEnable Off

/etc/apache2/mods-available/ssl.conf changed:

# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512
##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##
#
#   Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide 

Bug#951068: xinetd: daytime service gives incorrect format

[Keith Blow]

Package: xinetd
Version: 1:2.3.15.3-1
Severity: normal

Dear Maintainer,

I am using the internal daytime service, the daytime conf file says:
# description: An internal xinetd service which gets the current system time
# then prints it out in a format like this: "Wed Nov 13 22:30:27 EST 2002".
but the actual format is like this:
10 FEB 2020 15:17:02 GMT

It would be good if it gave the format specified in the conf file.
I have a workaround which is to create my own service which just executes
/bin/date
as this gives the (for me) right format.

This is not all that new, it was the same on jessie.
The report below says that the daytime file has been changed but this is
untrue as I submitted this report immediately after doing a reinstall of
xinetd.


-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Architecture: armv6l

Kernel: Linux 4.19.97+
Kernel taint flags: TAINT_CRAP
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/dash
Init: systemd (via /run/systemd/system)

Versions of packages xinetd depends on:
ii  libc62.28-10+rpi1
ii  libselinux1  2.8-1+b1
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400+rpi1
ii  netbase  5.6

Versions of packages xinetd recommends:
ii  logrotate3.14.0-4
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  update-inetd 4.49

xinetd suggests no packages.

-- Configuration Files:
/etc/xinetd.d/daytime changed [not included]

-- no debconf information

-- 
Keith Blow

Bug#822825: lua-socket: segfault in timeout_markstart()

[Tobias Mädel]

I would like to draw some attention to this old Debian bug again.

The problem is still present on Debian buster and sid (lua-socket
3.0~rc1+git+ac3201d-4).
It can be reproduced by using lighttpd (webserver) and mod_magnet
(similar to lua cgi).

A very small script, which is just doing a plain HTTP request will SEGV
the server:

http = require("socket.http")

r, c = http.request {
url = "https://tbspace.de;,
}

lighty.content = { r }
return 200

This is the backtrace of the issue: (screenshotted on a Debian sid/amd64
from 2020-02-10)
https://screenshot.tbspace.de/gqzldcawbnk.png

Thanks,
Tobias

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

On Mon, Feb 10, 2020 at 03:04:49PM +0100, Ansgar wrote:
> If I start an xterm via Alt-F2 in gnome, the xterm process runs in a
> cgroup like gnome-launched-xterm-489694.scope.  gnome-terminal or an
> xterm started in gnome-terminal run in the gnome-terminal-
> server.service cgroup.  I expect openbox doesn't do this and processes
> started by openbox run in the same cgroup as openbox itself.
> 
> `systemd-cgls` is useful to see how processes are organized into
> cgroups.
> 
> The gnome-launched-*.scope has KillMode=control-group, so all processes
> including background processes like tmux get killed when the unit gets
> stopped (systemd --user show -p KillMode gnome-launched-scope).

That does not explain the on-and-off behavior, but helps in
understanding why processes get killed in the first place.

Then, however, is KillUserProcesses completely obsolete? A user trying
to debug a situation like mine will currently wind up in the discussion
of #825394 and look into KillUserProcesses' documentation. Even if it's
not completely obsolete, a warning that desktop environment spawned
processes might also be subject to killing from their desktop
environment's KillMode would be helpful.

Kind regards
chrysn


signature.asc
Description: PGP signature