Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb{9,10}u1

[Aaron M. Ucko]

clone 933828 -1
tags 933828 - buster
retitle 933828 ncbi-tools6/6.1.20170106+dfsg1-0+deb9u1
tags -1 - stretch
retitle -1 ncbi-tools6/6.1.20170106+dfsg1-0+deb10u1
thanks

"Aaron M. Ucko"  writes:

> Got it, thanks; cloning and tuning accordingly.

This time for real.  (Long week.)

> On a somewhat related note, should I cite the tracking bugs in my
> changelogs?

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

Bug#550381: tex4ht: Creates invalid html document

[Hilmar Preuße]

Control: forwarded 550381 https://puszcza.gnu.org.ua/bugs/?435

Am 09.10.2009 um 20:14 teilte Andrey mit:

> htlatex produces invalid html document if the source contains
> \AtBeginDocument directive. Minimal example and result html file
> attached.
> 
Forwarded to upstream for now.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb{9,10}u1

[Aaron M. Ucko]

bts clone 933828 -1
bts tags 933828 - buster
bts retitle 933828 ncbi-tools6/6.1.20170106+dfsg1-0+deb9u1
bts tags -1 - stretch
bts retitle -1 ncbi-tools6/6.1.20170106+dfsg1-0+deb10u1
thanks

"Adam D. Barratt"  writes:

> As a side note, having just spotted the subject header - if you're
> looking at updating the package in both stretch and buster then that
> needs two distinct tracking bugs, please. They're distinct uploads
> that go through different queues and may be released (or not) at
> different times.

Got it, thanks; cloning and tuning accordingly.  On a somewhat related
note, should I cite the tracking bugs in my changelogs?

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

Bug#931503: protobuf: FTBFS on x32 (now for a different reason)

[Laurence Parry]

Thanks for that. To be honest, what the test is doing seems odd to begin
with - looks like it's converting a double to protobuf native format, then
interpreting the result (which would be in python's '0x...' format?) as an
integer (varint?) as it doesn't know what type it should be. But again, my
understanding of that is very limited, I can just see it's breaking.

Best regards,
--
Laurence

Bug#934230: unattended-upgrades: Prevents regular usage of package tools

[Francisco M Neto]

Hi Balint,

On Fri, 2019-08-09 at 15:46 +0200, Bálint Réczey wrote:
> 
> So APT is being improved to report who is holding the lock:
> https://salsa.debian.org/apt-team/apt/merge_requests/68

That's VERY good to know. At least it seems I'm on the same track as the
APT maintainers.

> If you would like to keep the habit of upgrading packages in the
> morning manually then I suggest configuring unattended-upgrades to
> perform upgrades in the evening or on shutdown.
> Please note that you can also configure u-u to apply all updates not
> just security updates.

Is there any way to set it up so it checks is there's any user logged in
before running? That would be a nice workaround.

-- 
[]'s,

Francisco M Neto

GPG: 4096R/D692FBF0


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

Bug#934310: ITP: gnome-shell-xrdesktop -- gnome shell with with xrdesktop patches

[李健秋]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee (李健秋) 

* Package name: gnome-shell-xrdesktop
  Version : 0.12.1
  Upstream Author : Lubosz Sarnecki lubosz.sarne...@collabora.com
* URL : https://gitlab.freedesktop.org/xrdesktop/gnome-shell
* License : Expat
  Programming Lang: C
  Description : gnome shell with with xrdesktop patches

 This package contains gnome shell with with xrdesktop patches.

Bug#931503: protobuf: FTBFS on x32 (now for a different reason)

[GCS]

On Fri, Aug 9, 2019 at 6:36 AM Laurence Parry  wrote:
> Unfortunately the build now fails earlier on x32 (indeed it seems on
> most 32-bit platforms) during the Python 2.7 tests, so we can't see if
> the fix worked yet:
> https://buildd.debian.org/status/package.php?p=protobuf=experimental
 Seen that and was experimenting with possible fixes.

> I believe this is
> https://github.com/protocolbuffers/protobuf/issues/6205 though, and I
> left some thoughts there about what might have caused the test to
> fail.
 It's a more deep issue I believe. Changed the mentioned constant to
1024 (which is a small enough number for embedded systems even). But
it fails the same way, in the result 0 is shown. Easy cut through fix
is on the way.

Regards,
Laszlo/GCS

Bug#933960: qtbase-opensource-src: .tag files do not belong into doc packages

[Jiri Palecek]

On Mon, 05 Aug 2019 11:45:54 -0300
=?utf-8?q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= wrote:
> Source: qtbase-opensource-src
> Version: 5.11.3+dfsg1-2
> Severity: normal
>
> Jonathan Ridell just reported that some KDE packages (and then
Scarlett checked
> that Qt has the same issue) ship the .tags files within foo-doc packages.

Yes. I have reported that about half a year ago as 922707.

> It turns out that the .tags files are used for linking docs, thus
more of a

> development file.

Yes. And generated apidocs in debian-built packages are suboptimal
because of this.

> We need to consider if we have to move this files or not within Qt.
If we have

> then we might tackle the xml files for examples too (see #933597).

This change is already commited in the Salsa repository.

BTW the other culprits in this business are:


libkf5activities-doc
libkf5activitiesstats-doc
libkf5archive-doc
libkf5attica-doc
libkf5auth-doc
libkf5baloo-doc
libkf5bluezqt-doc
libkf5bookmarks-doc
libkf5codecs-doc
libkf5completion-doc
libkf5config-doc
libkf5configwidgets-doc
libkf5coreaddons-doc
libkf5crash-doc
libkf5dbusaddons-doc
libkf5declarative-doc
libkf5dnssd-doc
libkf5emoticons-doc
libkf5filemetadata-doc
libkf5globalaccel-doc
libkf5guiaddons-doc
libkf5holidays-doc
libkf5iconthemes-doc
libkf5idletime-doc
libkf5itemmodels-doc
libkf5itemviews-doc
libkf5i18n-doc
libkf5jobwidgets-doc
libkf5kcmutils-doc
libkf5kio-doc
libkf5kirigami2-doc
libkf5modemmanagerqt-doc
libkf5networkmanagerqt-doc
libkf5newstuff-doc
libkf5notifications-doc
libkf5notifyconfig-doc
libkf5package-doc
libkf5parts-doc
libkf5people-doc
libkf5plasma-doc
libkf5plotting-doc
libkf5prison-doc
libkf5pty-doc
libkf5runner-doc
libkf5service-doc
libkf5solid-doc
libkf5sonnet-doc
libkf5su-doc
libkf5syntaxhighlighting-doc
libkf5texteditor-doc
libkf5textwidgets-doc
libkf5threadweaver-doc
libkf5unitconversion-doc
libkf5wallet-doc
libkf5wayland-doc
libkf5widgetsaddons-doc
libkf5windowsystem-doc
libkf5xmlgui-doc
libkf5xmlrpcclient-doc
qtbase5-doc-html
qtconnectivity5-doc-html
qtdeclarative5-doc-html
qtgraphicaleffects5-doc-html
qtlocation5-doc-html
qtnetworkauth5-doc-html
qtquickcontrols2-5-doc-html
qtquickcontrols5-doc-html
qtsensors5-doc-html
qtserialbus5-doc-html
qtspeech5-doc-html
qtsvg5-doc-html
qttools5-doc-html
qtwebengine5-doc-html
qtwebchannel5-doc-html
qtwebkit5-doc-html
qtwebsockets5-doc-html
qtxmlpatterns5-doc-html
qt3d5-doc-html

Do we need a separate bug for every one of them?

Regards

    Jiri Palecek

Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb{9,10}u1

[Adam D. Barratt]

On 2019-08-09 14:23, u...@debian.org wrote:

"Aaron M. Ucko"  writes:


some data files turned out to contain non-free portions


Oops, looks like I'll need to update the autopkgtest in buster (and
unstable) to account for removing these files; I should be able to take
care of it over the weekend.

Sorry for not catching that earlier!


As a side note, having just spotted the subject header - if you're 
looking at updating the package in both stretch and buster then that 
needs two distinct tracking bugs, please. They're distinct uploads that 
go through different queues and may be released (or not) at different 
times.


Regards,

Adam

Bug#934230: unattended-upgrades: Prevents regular usage of package tools

[Bálint Réczey]

Hi Francis,

Francisco M Neto  ezt írta (időpont: 2019. aug.
9., P, 16:03):
>
> Hi Balint,
>
> On Fri, 2019-08-09 at 15:46 +0200, Bálint Réczey wrote:
> >
> > So APT is being improved to report who is holding the lock:
> > https://salsa.debian.org/apt-team/apt/merge_requests/68
>
> That's VERY good to know. At least it seems I'm on the same track as 
> the
> APT maintainers.
>
> > If you would like to keep the habit of upgrading packages in the
> > morning manually then I suggest configuring unattended-upgrades to
> > perform upgrades in the evening or on shutdown.
> > Please note that you can also configure u-u to apply all updates not
> > just security updates.
>
> Is there any way to set it up so it checks is there's any user logged 
> in
> before running? That would be a nice workaround.

You can add a drop-in with ExecStartPre= for
apt-daily-upgrade.service, that fails when a user is logged in, but
I'm not recommending that.

Cheers,
Balint

>
> --
> []'s,
>
> Francisco M Neto
>
> GPG: 4096R/D692FBF0

Bug#934284: journal sometimes with x-bit, sometimes without

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 09.08.19 um 08:15 schrieb Marc Haber:
> 
> I have not fully understood what happens here. I am monitoring my
> filesystems with aide, and sometimes get the following report:
> 
> ---
> Changed entries:
> ---
> 
> f   .... A.  : 
> /run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal
> 
> ---
> Detailed information about changes:
> ---
> 
> File: /run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal
>   ACL  : A: user::rw- | A: user::rw-
>  A: group::r--| A: group::r-x   #effective:r--
>  A: group:adm:r-- | A: group:adm:r-x
> #effective:r--
>  A: mask::r-- | A: mask::r--
>  A: other::---| A: other::---
> 
> This means that the system.journal has grown an x bit since the last
> aide run. This looks to me that the file gets created without the x bit,
> and then the x bit gets added at some later time.
> 
> Since the file is not executable, the X bit should not be set in the
> first place. If it's necessary for some magic, then it should be set
> from the beginning.
> 
> I am seeing this on more than just a few systems, also on buster and
> sid. I am reporting this from a stretch system just coincidentally, if
> you need information from a more modern system, please let me know.
> 
> Can you shed some light on this please?

I have never seen this behaviour myself on the multitude of systems I
run (laptop, servers, VM, containers) so I don't really have any idea.

What are the permissions /ACLs on

/run/log/journal/8f018d505adf4ecaad2720811a888b04/

Do you have any tmpfiles which references files in /run/log ?
Can you exclude that non-systemd components change the permissions?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#934246: munin-node doesn't start any more after upgrade to buster

[Paolo Benvenuto]

Il giorno gio 8 ago 2019 alle ore 23:27  ha scritto:

> > I had munin and munin-node working well on stretch, after upgrading to
> buster
> > munin-node service doesn't start any more.
>
> That sounds unpleasant.
>
> Did you already find a reason for this behaviour?
>

no


> What is the result of running "munin-node" directly (as root)?
>
> # munin-node
doesn't produce any error

after that:

$ ps ax|grep munin
12471 ?Ss 0:00 /usr/bin/perl -wT /usr/sbin/munin-node

and it seems that something more is executed every 5 minutes.


> Cheers,
> Lars
>

Bug#912303: ITA: libopenhmd -- API and drivers for immersive

[Bálint Réczey]

Emmanuel,

Could you please push the upstream tag?
I also suggest copying the Salsa CI config from Wireshark to catch
such missing pushes.

I can then sponsor the upload from there. Thanks for adopting the package.

Cheers,
Balint

Adam Borowski  ezt írta (időpont: 2019. aug. 6., K, 23:29):
>
> On Mon, Aug 05, 2019 at 10:03:02PM +0200, Bálint Réczey wrote:
> > Emmanuel Arias  ezt írta (időpont: 2019.
> > aug. 5., H, 21:43):
> > > Hi I am working on the new usptream version. You can see on salsa.
> > >
> > > I CC to Bálint to help to upload the package.
> > >
> > > Bálint do you prefer that send the package to mentors? or you can take 
> > > from salsa?
>
> > It is also an established practice to work with the same mentor who
> > sponsor all the uploads and help improving by giving feedback on the
> > packaging changes.
> > I see Adam sponsored the previous upload thus he would be a more
> > natural choice and I'm wondering if he would like to keep sponsoring
> > uploads.
>
> I'm still on the Debconf (sort of... but we're only now getting rid of
> Holger, and Stefano is still here), and the bars/etc have limited net
> access; I'm running out of working hardware too.
>
> So... it's yours.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
> ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
> ⠈⠳⣄

Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

[Arnaud Rebillout]

On 8/9/19 5:15 PM, Adam D. Barratt wrote:
> The module apparently has three reverse build-dependencies:
>
> amazon-ecr-credential-helper:
> golang-github-docker-docker-credential-helpers-dev
> docker-pycreds: golang-docker-credential-helpers
> docker.io: golang-github-docker-docker-credential-helpers-dev (>= 0.6.1~)
>
> Would this update imply any of those needing to be rebuilt? If so, is
> that the end of the tree, or do we end up down a rabbit hole of Go
> libraries?

That's a good question. FWIW I tried this command, I got a different
result from you:

$ dose-ceve -T deb \
  --deb-native-arch=amd64 \
  -r golang-github-docker-docker-credential-helpers-dev \
 
debsrc:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources
\
 
deb:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
\
  | grep-dctrl -n -s Package '' \
  | sort -u
golang-docker-dev
golang-github-docker-docker-credential-helpers-dev
golang-github-docker-docker-dev
golang-github-fsouza-go-dockerclient-dev
golang-github-samalba-dockerclient-dev

I suppose that for every package ending with -dev in this list, we
should also get the reverse build-depends? Then we're going down the
rabbit hole.

But I'm not sure that following the reverse build-depends is the right
way to do it. Maybe following the Built-Using field is better.

Let me CC the Go team (question is: how to figure out which package to
rebuild after uploading
golang-github-docker-docker-credential-helpers-dev to stable).

Thanks,

  Arnaud

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

[Beniamino Galvani]

On Fri, Aug 09, 2019 at 01:10:55PM +0200, Vincent Lefevre wrote:
> On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> > On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> ...
> > Could you capture DHCP packets with:
> > 
> >   tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68
> > 
> > when using dhclient and the failing internal client, and attach the
> > files?
> 
> dhcp-dhclient.pcap- using dhclient (success, though NAK came first)
> 
> dhcp-int-failure.pcap - using the internal client (failures until
> I stopped the capture; ACK never came first)
> 
> dhcp-int-success.pcap - using the internal client (success after
> several requests, once ACK came first)
> 

Hi,

in the traces I see that there are 3 servers and one of them
advertises a subnet different from other two.  This setup makes the
behavior non-deterministic because clients can get an address either
in the 10.0.1.0/24 or in the 140.77.12.0/23 network. Do you know if
the network configured in this way on purpose?

Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:

  12:29:03.690421 94:f1:28:19:08:00 > 98:90:96:bd:7f:f7, ethertype IPv4 
(0x0800), length 366: (tos 0x0, ttl 63, id 55318, offset 0, flags [DF], proto 
UDP (17), length 352)
140.77.1.11.67 > 140.77.13.17.68: BOOTP/DHCP, Reply, length 324, hops 1, 
xid 0xff001675, secs 2, Flags [none]
  Your-IP 140.77.13.17
  Server-IP 140.77.14.50
  Gateway-IP 140.77.12.1
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  file "/lpxelinux.0"[|bootp]

to which the internal client replies with a request. Note the
server-id set to 140.77.1.11:

  12:29:03.690539 98:90:96:bd:7f:f7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 340: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 326)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:bd:7f:f7, length 298, xid 0xff001675, secs 2, Flags [none]
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 98:90:96:bd:7f:f7
Parameter-Request Option 55, length 18: 
  Subnet-Mask, Default-Gateway, Hostname, Domain-Name
  Domain-Name-Server, Time-Zone, MTU, BR
  Classless-Static-Route, Static-Route, YD, YS
  NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
  Option 252, RP
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 140.77.1.11
Requested-IP Option 50, length 4: 140.77.13.17
Hostname Option 12, length 7: "cventin"

The DHCP server at 10.0.1.1 NAKs the request even if it had a
different server-id; I don't think this is correct:

  12:29:03.691585 5c:96:9d:6d:9d:48 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto 
UDP (17), length 328)
10.0.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 
0xff001675, secs 2, Flags [Broadcast]
  Server-IP 10.0.1.1
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: 10.0.1.1
MSG Option 56, length 31: "requested address not available"

Also, RFC 2131 says that the "If the client receives a DHCPNAK
message, the client restarts the configuration process", that is what
the internal client does, until the ACK comes before or until
timeout. dhclient apparently ignores the NAK, but I haven't found yet
in the code where this is done and based on what.

Beniamino


signature.asc
Description: PGP signature

Bug#934264: Please update (4.6.2?) and provide/switch to python3

[Yaroslav Halchenko]

On Fri, 09 Aug 2019, Andreas Tille wrote:
> > 4.5.0 still causes segfaults for me (while trying to build/test python-mne
> > package).  I could not get to upstream's download page for mayavi2 (server 
> > bogs
> > out), but conda seems to have 4.6.2 https://anaconda.org/anaconda/mayavi  
> > so I guess
> > it is out there.

> Its definitely out and the watch file reports a new version which even
> supports Python3.  I've updated the packaging Git[1] to latest packaging

THANKS for looking into it!

> standards (attention, since I know NeuroDebian prefers lower versions
> of debhelper - feel free to revert my switch to debhelper 12!) and

well, we could try to backport build (after lowering) but I am not sure
if we would love to take that monster mayavi2 under our backports wing
;)

> tried to convert the build system to Python3 but unfortunately the
> configure step fails with:

> ...

> Remark: Since it seems the package is not really maintained by the
> Uploader inside the PAPT team and entering the PAPT team might take a
> bit longer I'd consider it a sensible step to take over the package to
> Debian Science team to enable more people an easy access to the
> repository.  I'm not keen on "nursing" merge requests of grown up
> Python developers just because these are not part of PAPT team.

well -- I guess that should be cleared up with the PAPT team / original
uploaders (at least with Varun ?  any objections?)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#934230: unattended-upgrades: Prevents regular usage of package tools

[Bálint Réczey]

Control: notfound -1 unattended-upgrades

Hi Francesco,

 ezt írta (időpont: 2019. aug. 9., P, 3:01):
>
> Greetings!
>
> On 2019-08-08 17:47, Bálint Réczey wrote:
> > Control: tags -1 moreinfo
> >
> > Hi Francisco,
>
> <...>
>
> > Unattended-upgrades is expected to run only for a few seconds per day
> > and should not block installation of packages when it is not running.
> > Could you please check if it was stuck?
> > You can use pstree and check the logs in /var/log/unattended-upgrades/
> > .
> >
> > Thanks,
> > Balint
>
>
>I checked the log files for it. Two things:
>
> 1) Ironically, unattended-upgrades.log reports an error because it could
> not get the lock at /var/lib/dpkg/lock
>
> 2) unattended-upgrades-dpkg.lost shows nothing out of the ordinary,
> except it suddenly stops (most likely when I manually killed the
> process).
>
> These files do not contain logs for other times, though. However, it may
> be supposed to run only for a few seconds, but these logs span several
> minutes (which, come to think of it, make _some_ sense since the logs
> report several packages to be installed).
>
> Thinking back, and considering this installation as well as others (my
> computer at work and my desktop at home), the impression that I get is
> that it seems to check for updates right after I log in to the system,
> which is usually the moment I decide to do the same (check for upgrades
> or installing new packages).
>
> I have no idea if that is the expected behavior for it or not, but I
> have encountered dpkg locked more often than not, and that can become
> really annoying after some time.
>
> Perhaps, instead of simply complaining about an unobtainable lock, apt
> could give the user a message like "hang on, there are upgrades being
> installed, these are the packages that are being upgraded" - or
> something along those lines. That way at least I'd know to wait for a
> bit until the upgrade is complete.
>
> With hopes of making this whole issue a bit clearer, I'm gonna try and
> summarize:
>
> 1- I log in to the system
> 2a- The first thing I do is run apt update
> 2b- Alternatively, I search for something with apt search then try to
> install it with apt install
> 3- In either case, I get a message about the locks not being available
>
> I hope this is more illuminating (the log files I mentioned are
> attached).

So APT is being improved to report who is holding the lock:
https://salsa.debian.org/apt-team/apt/merge_requests/68

APT runs update every morning or after the system is started if it is
later than morning. Downloading all the metadata can easily take
longer than the package upgrades themselves.
If you try to do the same, you can expect colliding with the automated task.

If you would like to keep the habit of upgrading packages in the
morning manually then I suggest configuring unattended-upgrades to
perform upgrades in the evening or on shutdown.
Please note that you can also configure u-u to apply all updates not
just security updates.

Cheers,
Balint

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Reinhard Karcher]

A selfcompiled kernel from git (version 5.3-rc3) does not show that error.

Bug#934254: [Debian-med-packaging] Bug#934254: Time to provide python3-mne package

[Yaroslav Halchenko]

On Fri, 09 Aug 2019, Alexandre Gramfort wrote:

> thanks Yarik for looking into this.

> Unless there is a bug it's perfectly possible to run the mne-python tests
> withing mayavi. All tests that require mayavi are decorated to be skipped
> if mayavi is not installed. See:

> https://github.com/mne-tools/mne-python/blob/master/mne/viz/tests/test_3d.py#L334

ah, great -- then we coudld proceed!   I guess I have got too alarmed by

SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_coreg_gui.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_fiducials_gui.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_file_traits.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_kit2fiff_gui.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_marker_gui.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/_viewer.py')
SKIP [1] /usr/lib/python3/dist-packages/_pytest/doctest.py:361: unable to 
import module 
local('/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/viz/backends/_pyvista.py')

where it looked like imports of mayavi were the culprit.

Next errors which forbid trying to test were attempts  to get some absent data 
files


Here is the full protocol from trying to build/test in that debian-0.18.x
branch (available on salsa), which I guess should have been just skipped due to
MNE_SKIP_SAMPLE_DATASET_TESTS=true, correct?  could you please provide a patch?

(git)hopa:~exppsy/mne-python[debian-0.18.x]
$> quilt push -a   
Applying patch deb_skip_segfaultingtests
patching file mne/gui/tests/test_kit2fiff_gui.py

Applying patch deb_paths
patching file mne/report.py

Applying patch up_check_numpy
patching file mne/decoding/tests/test_receptive_field.py

Now at patch up_check_numpy
changes on filesystem:  
  
 mne/decoding/tests/test_receptive_field.py | 5 -
 mne/gui/tests/test_kit2fiff_gui.py | 1 +
 mne/report.py  | 8 ++--

$> fakeroot debian/rules binary
dh binary --with python3 --buildsystem pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/home/yoh/deb/gits/pkg-exppsy/mne-python'
mkdir -p build
dh_auto_build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
copying mne/report.py -> 
/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne
copying mne/decoding/tests/test_receptive_field.py -> 
/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/decoding/tests
copying mne/gui/tests/test_kit2fiff_gui.py -> 
/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/gui/tests
running egg_info
writing mne.egg-info/PKG-INFO
writing dependency_links to mne.egg-info/dependency_links.txt
writing requirements to mne.egg-info/requires.txt
writing top-level names to mne.egg-info/top_level.txt
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.css' under directory 'mne/html'
warning: no files found matching 'mne/datasets' under directory 'mne'
warning: no previously-included files matching '*' found under directory 
'examples/MNE-sample-data'
warning: no previously-included files matching '*' found under directory 
'examples/MNE-testing-data'
warning: no previously-included files matching '*' found under directory 
'examples/MNE-spm-face'
warning: no previously-included files matching '*' found under directory 
'examples/MNE-somato-data'
warning: no previously-included files matching '*.pyc' found under directory 
'mne'
warning: no previously-included files found matching '.github'
warning: no previously-included files found matching '.github/ISSUE_TEMPLATE'
writing manifest file 'mne.egg-info/SOURCES.txt'
creating 
/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/html
copying mne/html/bootstrap.min.js -> 
/home/yoh/deb/gits/pkg-exppsy/mne-python/.pybuild/cpython3_3.7_mne/build/mne/html
running 

Bug#923240: policykit-1: Please support alternative logind implementations

[Simon McVittie]

Control: tags -1 + moreinfo

On Mon, 25 Feb 2019 at 10:58:49 +, Mark Hindley wrote:
> For desktops to be installable on such systems, policykit-1 needs to depend on
> the newly approved virtual packages default-logind and logind. In the latest
> upload of src:systemd, libpam-systemd provides default-logind.

Sorry for the delay in getting back to you on this. Non-critical changes
to important components like policykit-1 did not seem like a good idea
during the buster release freeze.

Does polkit work correctly on systems that use elogind, without any
further source or binary changes? It is not enough that a logind-like
service is merely installed and monitoring sessions: to keep polkit's
core functionality working, it has to be able to query logind's state
via libsystemd.so.0 APIs.

For example, when polkitd calls sd_pid_get_session(), if the system is
using elogind, the API call needs to return whether pid is part of an
elogind session.

Please could you describe how this is meant to work on systems that use
elogind? Which packages are meant to be installed to make this work?

For comparison, here is how it works on systemd systems:

- libpam_systemd is invoked on login and logout
- libpam_systemd communicates with systemd-logind to update its knowledge
  of login sessions
- polkitd is linked to libsystemd.so.0, which is provided by libsystemd0
- libsystemd0 communicates with systemd-logind via D-Bus, or by reading
  files in /run/systemd that are considered private to the combination
  of systemd-logind and libsystemd0 (mainly /run/systemd/seats and
  /run/systemd/sessions, I think)

Which parts of that architecture get replaced when using elogind?

When a bug is reported in policykit-1 on a system that is using elogind,
does the reportbug-generated message template indicate that? Is there
someone among the elogind maintainers who can help with such bugs if
they appear to be integration issues between policykit-1 and elogind?

(If the reportbug-generated message template with your proposed patch
doesn't currently indicate systemd-logind vs. elogind, it should be
possible to fix that by putting appropriate runes in
debian/policykit-1.bug-control.)

> There is a separate issue about backend support for elogind. I will
> open a separate bug for that.

Does that separate bug exist, or has the question of backend support
become irrelevant due to changes in the design of how elogind fits into
Debian since you opened this bug?

On Fri, 09 Aug 2019 at 14:15:17 +0200, Svante Signell wrote:
> Please explain your decision on why desktops for other
> init systems are excluded (even in sid).

Please don't assume that the absence of action is a deliberate decision.
All of policykit-1's maintainers (both upstream and in Debian) mostly
work on other things and don't have a huge amount of time available for
policykit-1. This makes us reluctant to risk creating the possibility
of non-functional combinations of packages that will take more of our
time to debug.

smcv

Bug#896086: network-manager-gnome: Cannot configure IPsec/IKEv2 VPN with pre-shared key

[Harald Dunkel]

Hi Rupert,

I understand that this is highly frustrating. Apparently you
have found the hidden radio buttons for the "Password" entry?


Regards
Harri

Bug#774262: jadetex: Makes loads of duplicate access() calls

[Hilmar Preuße]

Control: retitle 774262 latex: Makes loads of duplicate access() calls
Control: reassign 774262 texlive-binaries

Am 30.03.2016 um 16:34 teilte Preuße, Hilmar mit:

Hi,

>> While building the installation-guide package, I noticed that jadetex
>> was taking a lot of system time. strace shows me this in a loop over and
>> over:
>>
> Problem still there, can be reproduces attached tex file, simply compile it 
> using
> jadetex. Some strace statistics:
> 
Well, errm. jadetex is just a macro package, hence it can't be the root
cause. So, the issue is also reproducible w/ normal LaTeX:

\documentclass{article}
\begin{document}
test\textbf{testbf}test\textbf{testbf}test
\end{document}

strace pdflatex a.tex 2>&1 |grep access|grep article.cls|sort|uniq -c

is attached. Of course it might also a problem in libkpathsea6

H.
-- 
sigfault
#206401 http://counter.li.org
hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/774262$ strace latex a.tex 
2>&1 |grep access|grep article.cls|sort|uniq -c
  2 access("./article.cls", R_OK)   = -1 ENOENT (No such file or 
directory)
  2 access("/home/hille/.texlive2019/texmf-var/tex/latex/article.cls", 
R_OK) = -1 ENOENT (No such file or directory)
  2 
access("/home/hille/.texlive2019/texmf-var/tex/latex/hyperref/article.cls", 
R_OK) = -1 ENOENT (No such file or directory)
  2 access("/usr/share/texlive/texmf-dist/tex/latex/base/article.cls", 
R_OK) = 0
hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/774262$ strace pdflatex a.tex 
2>&1 |grep access|grep article.cls|sort|uniq -c
  2 access("./article.cls", R_OK)   = -1 ENOENT (No such file or 
directory)
  2 access("/home/hille/.texlive2019/texmf-var/tex/latex/article.cls", 
R_OK) = -1 ENOENT (No such file or directory)
  2 
access("/home/hille/.texlive2019/texmf-var/tex/latex/hyperref/article.cls", 
R_OK) = -1 ENOENT (No such file or directory)
  2 access("/usr/share/texlive/texmf-dist/tex/latex/base/article.cls", 
R_OK) = 0


signature.asc
Description: OpenPGP digital signature

Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb{9,10}u1

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> some data files turned out to contain non-free portions

Oops, looks like I'll need to update the autopkgtest in buster (and
unstable) to account for removing these files; I should be able to take
care of it over the weekend.

Sorry for not catching that earlier!

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

Bug#934309: linux-image-5.2.0-1-amd64-unsigned: suggesting INTEL_IOMMU_DEFAULT_ON

[Ryutaroh Matsumoto]

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

Dear Maintainer,

Without hardware IOMMU, heavy IO traffic sometimes causes
"swiotlb buffer is full" from kernel/dma/swiotlb.c.
Then an error is returned to a device driver calling dma_map_sg()
or something similar. Some device drivers (e.g. ehci-pci.c) do
not handle failures from dma_map_*() functions, and failures
of assigning DMA memories often lead undesirable behaviors.
Enablement of hardware IOMMU reduces possiblity of "swiotlb buffer is full".

I'd like to request to consider INTEL_IOMMU_DEFAULT_ON.
AMD IOMMU seems to be enabled by default, btw.

Best regards,
Ryutaroh Matsumoto

-- Package-specific info:
** Version:
Linux version 5.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 5.2.6-1 (2019-08-05)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-1-amd64
root=UUID=12f1110c-5548-452b-ba7e-b995b8aa7f45 ro i915.fastboot=1
swiotlb=noforce iommu=force,merge,nopanic,nopt intel_iommu=on
cgoup_no_v1=all systemd.unified_cgroup_hierarchy=1
systemd.show_status=1

** Tainted: E (8192)
 * Unsigned module has been loaded.

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

** Model information
sys_vendor: Panasonic Corporation
product_name: CFSZ6-1L
product_version: 001
chassis_vendor: Panasonic Corporation
chassis_version: 001
bios_vendor: American Megatrends Inc.
bios_version: V1.11L10
board_vendor: Panasonic Corporation
board_name: CFSZ6-1L
board_version: 1

** Loaded modules:
ctr(E)
ccm(E)
cmac(E)
cpufreq_powersave(E)
cpufreq_userspace(E)
cpufreq_conservative(E)
bnep(E)
intel_rapl(E)
x86_pkg_temp_thermal(E)
intel_powerclamp(E)
coretemp(E)
kvm_intel(E)
kvm(E)
irqbypass(E)
crct10dif_pclmul(E)
crc32_pclmul(E)
ghash_clmulni_intel(E)
nls_ascii(E)
nls_cp437(E)
vfat(E)
fat(E)
arc4(E)
snd_hda_codec_hdmi(E)
snd_soc_skl(E)
snd_soc_skl_ipc(E)
snd_soc_sst_ipc(E)
cdc_mbim(E)
snd_hda_codec_realtek(E)
btusb(E)
snd_soc_sst_dsp(E)
btrtl(E)
btbcm(E)
snd_hda_codec_generic(E)
cdc_wdm(E)
btintel(E)
snd_hda_ext_core(E)
ledtrig_audio(E)
snd_soc_acpi_intel_match(E)
snd_soc_acpi(E)
snd_soc_core(E)
qcserial(E)
bluetooth(E)
usb_wwan(E)
cdc_ncm(E)
snd_compress(E)
efi_pstore(E)
aesni_intel(E)
usbnet(E)
mii(E)
snd_hda_intel(E)
usbserial(E)
aes_x86_64(E)
crypto_simd(E)
cryptd(E)
glue_helper(E)
intel_cstate(E)
uvcvideo(E)
iwlmvm(E)
snd_hda_codec(E)
videobuf2_vmalloc(E)
videobuf2_memops(E)
intel_uncore(E)
videobuf2_v4l2(E)
mac80211(E)
iTCO_wdt(E)
intel_rapl_perf(E)
videobuf2_common(E)
snd_hda_core(E)
serio_raw(E)
iTCO_vendor_support(E)
snd_hwdep(E)
videodev(E)
watchdog(E)
drbg(E)
iwlwifi(E)
media(E)
snd_pcm(E)
efivars(E)
pcspkr(E)
snd_timer(E)
ansi_cprng(E)
snd(E)
soundcore(E)
cfg80211(E)
tpm_crb(E)
ecdh_generic(E)
ecc(E)
rfkill(E)
sg(E)
mei_me(E)
processor_thermal_device(E)
mei(E)
intel_soc_dts_iosf(E)
intel_pch_thermal(E)
battery(E)
acpi_als(E)
kfifo_buf(E)
industrialio(E)
int3403_thermal(E)
int340x_thermal_zone(E)
tpm_tis(E)
tpm_tis_core(E)
panasonic_laptop(E)
int3406_thermal(E)
tpm(E)
sparse_keymap(E)
rng_core(E)
int3400_thermal(E)
acpi_pad(E)
acpi_thermal_rel(E)
ac(E)
pcc_cpufreq(E)
evdev(E)
joydev(E)
parport_pc(E)
ppdev(E)
lp(E)
parport(E)
efivarfs(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
crc32c_generic(E)
sr_mod(E)
cdrom(E)
sd_mod(E)
ahci(E)
libahci(E)
crc32c_intel(E)
i915(E)
psmouse(E)
sdhci_pci(E)
xhci_pci(E)
i2c_algo_bit(E)
cqhci(E)
xhci_hcd(E)
libata(E)
drm_kms_helper(E)
e1000e(E)
scsi_mod(E)
i2c_i801(E)
sdhci(E)
mmc_core(E)
usbcore(E)
drm(E)
usb_common(E)
fan(E)
video(E)
button(E)

** Network interface configuration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp0s31f6:  mtu 1500 qdisc
pfifo_fast state DOWN group default qlen 1000
link/ether a8:13:74:97:2f:94 brd ff:ff:ff:ff:ff:ff
3: wwp0s20f0u2i12:  mtu 1500 qdisc noop
state DOWN group default qlen 1000
link/ether ba:d9:fa:0c:cc:18 brd ff:ff:ff:ff:ff:ff
4: wlp2s0:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether 00:28:f8:4a:37:bf brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlp2s0
   valid_lft 13555sec preferred_lft 13555sec
inet6 2409:251:2c0:1500:fbf1:f1f9:2ab9:f9c7/64 scope global
dynamic noprefixroute
   valid_lft 13558sec preferred_lft 11758sec
inet6 fe80::9b0f:dffc:a216:933/64 scope link noprefixroute
   valid_lft forever preferred_lft forever

*** Device statistics:

Bug#934132: Processed: #934132: Raise severity to important

[Jonathan Wiltshire]

On Fri, Aug 09, 2019 at 01:13:58PM +0200, Svante Signell wrote:
> On Fri, 2019-08-09 at 12:06 +0100, Jonathan Wiltshire wrote:
> > On Fri, Aug 09, 2019 at 12:55:02PM +0200, Svante Signell wrote:
> > > On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote:
> > > > Control: severity -1 normal
> > > > 
> > > > On 2019-08-09 11:33, Debian Bug Tracking System wrote:
> > > > > Processing commands for cont...@bugs.debian.org:
> > > > > 
> > > > > > severity 934132 important
> > > > > Bug #934132 [release.debian.org] unblock: elogind/241.3-
> > > > > 1+debian1
> > > > > Severity set to 'important' from 'normal'
> > > > 
> > > > No. release.d.o bugs are normal at most unless the team decide 
> > > > otherwise. Please leave them like that.
> > > 
> > > Might be so. But explain why this package is still blocked, buster
> > > was
> > > released several weeks ago!
> > 
> > Because it's nothing to do with buster. We're working on bullseye
> > now.
> 
> So elogind has been excluded from the bullseye release? Maybe you can
> explain that decision.

For the time being, yes, and for the reasons outlined in the initial bug
report.

You seem very intent on believing that this is a permanent state. In fact
there are probably nearly two years in which the problems outlined in this
bug can be resolved. If they are, I see no reason why elogind couldn't be
in bullseye in the fullness of time.

Please take a little time to study the background before you make alarmist
conclusions like this.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Bernhard Übelacker]

Control: found -1 linux/5.2.6-1


Dear Maintainer,
the bugreport https://bugs.debian.org/934292
seems about the same issue.

The issue can be reproduced by just accessing the file below.


root@debian:~# strace -f powertop
execve("/usr/sbin/powertop", ["powertop"], 0x7fff5df92d08 /* 11 vars */) = 0
brk(NULL)   = 0x56055fbf3000
...
openat(AT_FDCWD, "/sys/kernel/debug/tracing/events/power/cpu_idle/id", 
O_RDONLY) = ?
+++ killed by SIGKILL +++
Getötet

root@debian:~# cat /sys/kernel/debug/tracing/events/power/cpu_idle/id
Getötet


Issue can not be seen in 5.0.2-1~exp1, appeared in 5.2.6-1.

Kind regards,
Bernhard

Bug#934254: [Debian-med-packaging] Bug#934254: Time to provide python3-mne package

[Alexandre Gramfort]

thanks Yarik for looking into this.

Unless there is a bug it's perfectly possible to run the mne-python tests
withing mayavi. All tests that require mayavi are decorated to be skipped
if mayavi is not installed. See:

https://github.com/mne-tools/mne-python/blob/master/mne/viz/tests/test_3d.py#L334

Alex

Bug#934274: (no subject)

[Marcin Kulisz]

Tarjei, Noah

I think I managed to activate those 2 new regions, please give it a go and
shout if something is not working.

Bug#934159: metview: FTBFS after new magics++

[Alastair McKinstry]

Hi

Thanks, I've been working on this in parallel and discovered the same 
fixes :/


I'm testing metview-5.6, will merge changes

regards

Alastair

On 07/08/2019 16:31, Gianfranco Costamagna wrote:

Source: metview
Version: 5.3.0-3
Severity: serious
tags: patch

Hello, magics++ changed interpretAsMatrix prototype, and now metview is FTBFS.

The new upstream release has already a fix, but I'm posting a minimal debdiff 
here.

Also, new metview changed the METVIEW_EXTRA_INCLUDES variable, so also a change 
in rules file is needed now.


diff -Nru metview-5.3.0/debian/changelog metview-5.3.0/debian/changelog
--- metview-5.3.0/debian/changelog  2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/changelog  2019-08-07 17:13:08.0 +0200
@@ -1,3 +1,10 @@
+metview (5.3.0-4) unstable; urgency=medium
+
+  * debian/rules: fixup includes directive for terralib
+  * Cherry-pick upstream build fix (Closes: #-1)
+
+ -- Gianfranco Costamagna   Wed, 07 Aug 2019 
17:13:08 +0200
+
  metview (5.3.0-3) unstable; urgency=medium

* Standards-Version: 4.4.0
diff -Nru metview-5.3.0/debian/patches/fix-build-new-magics.patch 
metview-5.3.0/debian/patches/fix-build-new-magics.patch
--- metview-5.3.0/debian/patches/fix-build-new-magics.patch 1970-01-01 
01:00:00.0 +0100
+++ metview-5.3.0/debian/patches/fix-build-new-magics.patch 2019-08-07 
17:13:07.0 +0200
@@ -0,0 +1,16 @@
+Description: Cherry-pick upstream fix for the metview build.
+
+Last-Update: 2019-08-07
+
+--- metview-5.3.0.orig/src/Reprojection/ReprojectService.cc
 metview-5.3.0/src/Reprojection/ReprojectService.cc
+@@ -57,7 +57,8 @@ ReprojectService::execute()
+
+
+ magics::Matrix *matrix = 0;
+-gribInterpreter.interpretAsMatrix(grib, );
++gribInterpreter.interpretAsMatrix(grib);
++matrix = grib.u();
+ if (!matrix)
+ {
+ MagLog::dev() << "ERROR: interpretAsMatrix failed on file " << gribIn_ << 
"\n";
diff -Nru metview-5.3.0/debian/patches/series 
metview-5.3.0/debian/patches/series
--- metview-5.3.0/debian/patches/series 2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/patches/series 2019-08-07 17:12:51.0 +0200
@@ -12,3 +12,4 @@
  syserrlist.patch
  qt5-transition.patch
  g++14.patch
+fix-build-new-magics.patch
diff -Nru metview-5.3.0/debian/rules metview-5.3.0/debian/rules
--- metview-5.3.0/debian/rules  2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/rules  2019-08-07 17:13:08.0 +0200
@@ -72,7 +72,7 @@
 -DMETVIEW_SITE=debian  \
 -DCMAKE_BUILD_TYPE=Release \
 -DMETVIEW_EXTRA_LIBRARIES='terralib -lemosR64 -leccodes 
-leckit' \
-   -DMETVIEW_EXTRA_INCLUDES='/usr/include/terralib/kernel' \
+   -DMETVIEW_EXTRA_INCLUDE_DIRS='/usr/include/terralib/kernel' \
 -DMAGICS_HAVE_METVIEW=True \


--
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, 
phone: 087-6847928
Green Party Councillor, Galway County Council

Bug#900742: apparently we shall move away from Wireless Extensions

[Guido Maria Serra]

apparently we shall move away from Wireless Extensions kernel API

https://wireless.wiki.kernel.org/en/developers/documentation/wireless-extensions
shall I try to patch wireless-tools? I doubt I have the skills-set to
do it, I can try though

this thing of the AP limitation is pretty annoying... wicd is heavily
impacted by it
 - https://bugs.launchpad.net/wicd/+bug/1801751

regards,
GMS

Bug#934307: rust-regex_1.2.1-1_s390x.changes REJECTED

[Aurelien Jarno]

Package: rust-regex
Version: 1.2.1-1
Severity: serious

On 2019-08-09 12:10, Debian FTP Masters wrote:
> 
> 
> librust-regex-dev_1.2.1-1_s390x.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/cargo/registry/regex-1.2.1/Cargo.lock (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#923240: #923240: Explain why no desktops are installable w/o systemd

[Svante Signell]

Hello,

Due to that the patch for polickit-1 in #923420 is not applied no
working desktop is possible w/o installing systemd (via libpam-systemd) 
as pid 1. This effectively excludes usage of other init systems for
desktop usage. Please explain your decision on why desktops for other
init systems are excluded (even in sid).

Thanks!

Bug#842921: RFP: libextutils-hascompiler-perl -- check for the presence of a compiler

[Clément Hermann]

Hi,

closing this, since it was packaged after all (#932485). Sorry, while
packaging it I failed to check if there was already an RFP.

Cheers,

nodens.

Bug#933982: bash: normalize video with ffmpeg corrupts variable bash in the while/done loop

[Antonio]

I understand the problem, it depends on ffmpeg that gets characters from
std input and interferes with input pipe managed by the while/done loop.

I reported the bug to his maintainer.

You can close this bug.

Thanks,
Antonio

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

[Florian Weimer]

* Roman Savochenko:

> Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have
> got the memory effectivity some better even than in Debian 7!

Is there a way to reproduce your results easily?  Upstream, we're
looking for workloads which are difficult to handle for glibc's malloc
and its default settings, so that we hopefully can improve things
eventually.

Thanks,
Florian

Bug#934292: powertop: running powertop introduces "kernel NULL pointer dereference"

[Bernhard Übelacker]

Dear Maintainer,
it seems this issue got reported now
also against package src:linux in:
https://bugs.debian.org/934304

Kind regards,
Bernhard

Bug#875018: [lfhex] Future Qt4 removal from Buster

[Tobias Klauser]

Hi,

On 2019-07-22 at 16:29:45 +0200, Boyuan Yang  wrote:
> X-Debbugs-CC: tklau...@distanz.ch
> 
> It's been almost 10 years since your last upload and I think it's quite clear
> that package lfhex has a dead upstream and it will not be ported away from the
> deprecated Qt4. With projected Qt4 removal in Debian, I think package lfhex
> has to be removed eventually, ideally within the Bullseye cycle.
> 
> Please let me know if you think it's okay to have it removed from Debian soon.
> If there's no response within 28 days, I will proceed to file the Removal
> request to Debian FTP Masters and have the package removed from Sid.

I haven't used lfhex myself in a long time and forgot that I was still
listed as this package's maintainer. From my point of view it's
perfectly okay to remove it from Debian. Please feel free to file the
removal request as you see fit.

Thanks a lot
Tobias

Bug#873816: bug is fixed in buster

[Marc SCHAEFER]

Hello,

that bug is fixed in buster BTW.

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

[Vincent Lefevre]

On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> > On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > > Bringing Vincent into the loop here.
> > > 
> > > Vincent, can you gather the information Beniamino is asking for?
> > > 
> > > Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > > > Would it be possible to capture a dump of DHCP packets for a success
> > > > and for a failure?
> > 
> > Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1)
> > and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always
  ^^^ ACK

Grrr... I meant "ACK". Sorry. Being a bit tired...

> > in the same order.
> > 
> > With the internal DHCP client, this seems to be a success only if an
> > ACK packet comes first. There is no such issue with the external one.

By an ACK packet, I meant, one of the 2 packets from 140.77.1.*.

> > Do you need more information?
> 
> Could you capture DHCP packets with:
> 
>   tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68
> 
> when using dhclient and the failing internal client, and attach the
> files?

dhcp-dhclient.pcap- using dhclient (success, though NAK came first)

dhcp-int-failure.pcap - using the internal client (failures until
I stopped the capture; ACK never came first)

dhcp-int-success.pcap - using the internal client (success after
several requests, once ACK came first)

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


dhcp-dhclient.pcap
Description: Binary data


dhcp-int-failure.pcap
Description: Binary data


dhcp-int-success.pcap
Description: Binary data

Bug#934132: Processed: #934132: Raise severity to important

[Svante Signell]

On Fri, 2019-08-09 at 12:06 +0100, Jonathan Wiltshire wrote:
> On Fri, Aug 09, 2019 at 12:55:02PM +0200, Svante Signell wrote:
> > On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote:
> > > Control: severity -1 normal
> > > 
> > > On 2019-08-09 11:33, Debian Bug Tracking System wrote:
> > > > Processing commands for cont...@bugs.debian.org:
> > > > 
> > > > > severity 934132 important
> > > > Bug #934132 [release.debian.org] unblock: elogind/241.3-
> > > > 1+debian1
> > > > Severity set to 'important' from 'normal'
> > > 
> > > No. release.d.o bugs are normal at most unless the team decide 
> > > otherwise. Please leave them like that.
> > 
> > Might be so. But explain why this package is still blocked, buster
> > was
> > released several weeks ago!
> 
> Because it's nothing to do with buster. We're working on bullseye
> now.

So elogind has been excluded from the bullseye release? Maybe you can
explain that decision.

Bug#934132: Processed: #934132: Raise severity to important

[Jonathan Wiltshire]

On Fri, Aug 09, 2019 at 12:55:02PM +0200, Svante Signell wrote:
> On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote:
> > Control: severity -1 normal
> > 
> > On 2019-08-09 11:33, Debian Bug Tracking System wrote:
> > > Processing commands for cont...@bugs.debian.org:
> > > 
> > > > severity 934132 important
> > > Bug #934132 [release.debian.org] unblock: elogind/241.3-1+debian1
> > > Severity set to 'important' from 'normal'
> > 
> > No. release.d.o bugs are normal at most unless the team decide 
> > otherwise. Please leave them like that.
> 
> Might be so. But explain why this package is still blocked, buster was
> released several weeks ago!

Because it's nothing to do with buster. We're working on bullseye now.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#934132: Processed: #934132: Raise severity to important

[Adam D. Barratt]

On 2019-08-09 11:55, Svante Signell wrote:

On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote:

Control: severity -1 normal

On 2019-08-09 11:33, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
> > severity 934132 important
> Bug #934132 [release.debian.org] unblock: elogind/241.3-1+debian1
> Severity set to 'important' from 'normal'

No. release.d.o bugs are normal at most unless the team decide
otherwise. Please leave them like that.


Might be so. But explain why this package is still blocked, buster was
released several weeks ago!


I didn't add the blocking hint, but it was added after the release, so 
I'm not sure what your point there is.


(Nor am I likely to remove someone else's hint, so attempting to 
persuade me of the merits either way is unlikely to be a good use of 
either of our time.)


Regards,

Adam

Bug#704005: Claim your fund

[CitiBank group]

Your attention is needed urgently. Please be informed that your pending charity 
funds is ready for release, but someone is trying to claim it on your behalf, 
he said he is your representative and you have instructed him to claim the 
charity funds. So get back to us immediately to clarify this claim. Note, this 
information is coming from the Head of Legal department & General Counsel 
CitiBank group. 

Regards.

Mr Michael Feldman
Head of Legal department & General Counsel
CitiBank group

Bug#873818: iproute2: Keeping the man page is confusing

[Luca Boccassi]

On Fri, 2019-08-09 at 12:25 +0200, Oliver Schode wrote:
> Package: iproute2
> Version: 5.2.0-1
> Followup-For: Bug #873818
> 
> Hi,
> 
> the package still ships a man page for ifstat, why is that? Briefly
> judging from the changelog I guess it's just been overlooked
> following a
> revert. It probably should be removed, or at least add a short hint
> to
> the readme confirming the removal.
> 
> Kind regards,
> Oliver

Hi,

Thank you for the heads-up, it probably just slipped past. I've pushed
a commit to stop shipping the manpage, it will be included in the next
upload.

-- 
Kind regards,
Luca Boccassi


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

Bug#932498: affects non root users

[Andrew Yearp]

It seems that message #19 is on the right track  it's only effecting non
root users.

I now have two  systems  with this stopping a service from starting but
when i run the command as

root it works ok.

This was the command used :  iptables -t raw -L

One system is a new build the other an upgrade both with the same
version of iptables  1.8.2-4 and the same issue iptables hangs with high
cpu usage.


Andrew




BU is a Disability Confident Employer and has signed up to the Mindful Employer 
charter. Information about the accessibility of University buildings can be 
found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may 
contain confidential information. If you have received this email in error, 
please notify the sender and delete this email, which must not be copied, 
distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not 
necessarily represent those of Bournemouth University or its subsidiary 
companies. Nor can any contract be formed on behalf of the University or its 
subsidiary companies via email.

Bug#934132: Processed: #934132: Raise severity to important

[Svante Signell]

On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote:
> Control: severity -1 normal
> 
> On 2019-08-09 11:33, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> > 
> > > severity 934132 important
> > Bug #934132 [release.debian.org] unblock: elogind/241.3-1+debian1
> > Severity set to 'important' from 'normal'
> 
> No. release.d.o bugs are normal at most unless the team decide 
> otherwise. Please leave them like that.

Might be so. But explain why this package is still blocked, buster was
released several weeks ago!

Bug#934306: fsearch-trunk: Please, add fsearch package to current repos

[jesusda]

Package: fsearch-trunk
Version: 0.1+362+9~ubuntu18.10.1
Severity: wishlist

Dear Maintainer,

Please, add fsearch package to current repos.

Fsearch is a nice and useful utility to search files. It is the perfect
companion to light desktop environments like XFCE, LXDE, and so on.

https://github.com/cboxdoerfer/fsearch

Thanks a lot!



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

Kernel: Linux 4.18.0-20.3-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fsearch-trunk depends on:
ii  libc6   2.28-5
ii  libgdk-pixbuf2.0-0  2.36.12-2
ii  libglib2.0-02.58.3-1
ii  libgtk-3-0  3.24.5-1
ii  libpcre32:8.39-4

fsearch-trunk recommends no packages.

fsearch-trunk suggests no packages.

-- no debconf information

Bug#926543: lintian: Deadlock in source-copyright check on source:khronos-opencl-man/1.0~svn33624-4

[Andrey Rahmatullin]

It's the same with lintian from sid (2.16.0) on xhtml2pdf 0.2.2-2 and 0.2.2-3.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#704440: Claim your fund

[CitiBank group]

Your attention is needed urgently. Please be informed that your pending charity 
funds is ready for release, but someone is trying to claim it on your behalf, 
he said he is your representative and you have instructed him to claim the 
charity funds. So get back to us immediately to clarify this claim. Note, this 
information is coming from the Head of Legal department & General Counsel 
CitiBank group. 

Regards.

Mr Michael Feldman
Head of Legal department & General Counsel
CitiBank group

Bug#917996: texlive-pstricks: gs gives undefined in --execute-- when using color.tex with pstricks on plain tex.

[Hilmar Preuße]

Am 02.01.2019 um 05:24 teilte P V Mathew mit:

> Inclusion of color.tex and calling \pscircle. plain tex compiled ok
> with
>   >tex test.tex 
> and created test.dvi 
> But running xdvi on generated test.dvi file results in gs error.
> If we remove the \input color line, every thing works ok.
> 

https://tex.stackexchange.com/questions/503508/ghostscript-gives-undefined-in-execute-when-using-color-tex-with-pstricks-on

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#934132: Processed: #934132: Raise severity to important

[Adam D. Barratt]

Control: severity -1 normal

On 2019-08-09 11:33, Debian Bug Tracking System wrote:

Processing commands for cont...@bugs.debian.org:


severity 934132 important

Bug #934132 [release.debian.org] unblock: elogind/241.3-1+debian1
Severity set to 'important' from 'normal'


No. release.d.o bugs are normal at most unless the team decide 
otherwise. Please leave them like that.


Regards,

Adam

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Reinhard Karcher]

As I rebooted the system after the abort, the abort is not seen in the log.
Attached is the relevant part of the log on the system, where the abort 
happened.

ReinhardAug 09 09:00:41 apollon kernel: BUG: kernel NULL pointer dereference, address: 

Aug 09 09:00:41 apollon kernel: #PF: supervisor instruction fetch in kernel mode
Aug 09 09:00:41 apollon kernel: #PF: error_code(0x0010) - not-present page
Aug 09 09:00:42 apollon kernel: Oops: 0010 [#1] SMP PTI
Aug 09 09:00:42 apollon kernel: CPU: 5 PID: 2187 Comm: powertop Not tainted 
5.2.0-2-amd64 #1 Debian 5.2.7-1
Aug 09 09:00:42 apollon kernel: Hardware name: FUJITSU LIFEBOOK N532/FJNBB21, 
BIOS 1.14 03/12/2013
Aug 09 09:00:42 apollon kernel: RIP: 0010:0x0
Aug 09 09:00:42 apollon kernel: Code: Bad RIP value.
Aug 09 09:00:42 apollon kernel: RSP: 0018:a9184277fcd8 EFLAGS: 00010246
Aug 09 09:00:42 apollon kernel: RAX:  RBX: 8eca2e72d700 
RCX: 0001
Aug 09 09:00:42 apollon kernel: RDX: 8eca6513d400 RSI: 8eca2e72d700 
RDI: 8eca66ae6060
Aug 09 09:00:42 apollon kernel: RBP: 8eca66ae6060 R08:  
R09: 
Aug 09 09:00:42 apollon kernel: R10: 8eca66a92540 R11:  
R12: 8eca2e72d710
Aug 09 09:00:42 apollon kernel: R13: b4b1cdd0 R14:  
R15: 8eca2e72d700
Aug 09 09:00:42 apollon kernel: FS:  7f5c80179fc0() 
GS:8eca6714() knlGS:
Aug 09 09:00:42 apollon kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Aug 09 09:00:42 apollon kernel: CR2: ffd6 CR3: 0001ee624001 
CR4: 001606e0
Aug 09 09:00:42 apollon kernel: Call Trace:
Aug 09 09:00:42 apollon kernel:  do_dentry_open+0x13a/0x370
Aug 09 09:00:42 apollon kernel:  path_openat+0x2c6/0x1480
Aug 09 09:00:42 apollon kernel:  ? terminate_walk+0xe6/0x100
Aug 09 09:00:42 apollon kernel:  ? path_lookupat.isra.48+0xa3/0x220
Aug 09 09:00:42 apollon kernel:  ? reuse_swap_page+0x105/0x320
Aug 09 09:00:42 apollon kernel:  do_filp_open+0x93/0x100
Aug 09 09:00:42 apollon kernel:  ? __check_object_size+0x15d/0x189
Aug 09 09:00:42 apollon kernel:  do_sys_open+0x184/0x220
Aug 09 09:00:42 apollon kernel:  do_syscall_64+0x53/0x130
Aug 09 09:00:42 apollon kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug 09 09:00:42 apollon kernel: RIP: 0033:0x7f5c802d51ae
Aug 09 09:00:42 apollon kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 
05 59 65 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 
0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
Aug 09 09:00:42 apollon kernel: RSP: 002b:7fffe747d0a0 EFLAGS: 0246 
ORIG_RAX: 0101
Aug 09 09:00:42 apollon kernel: RAX: ffda RBX: 5607fd9cb870 
RCX: 7f5c802d51ae
Aug 09 09:00:42 apollon kernel: RDX:  RSI: 7fffe747e450 
RDI: ff9c
Aug 09 09:00:42 apollon kernel: RBP: 0008 R08: 0008 
R09: 0001
Aug 09 09:00:42 apollon kernel: R10:  R11: 0246 
R12: 7f5c806e9805
Aug 09 09:00:42 apollon kernel: R13: 7f5c806e9805 R14: 0001 
R15: 5607fda3d000
Aug 09 09:00:42 apollon kernel: Modules linked in: msr cpufreq_userspace 
cpufreq_powersave cpufreq_conservative nft_counter nft_chain_nat xt_MASQUERADE 
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables 
nfnetlink bridge stp llc arc4 uvcvideo iwldvm intel_rapl mac80211 
videobuf2_vmalloc x86_pkg_temp_thermal videobuf2_memops videobuf2_v4l2 
intel_powerclamp videobuf2_common coretemp videodev kvm_intel 
snd_hda_codec_hdmi media snd_hda_codec_realtek kvm irqbypass 
snd_hda_codec_generic ledtrig_audio snd_hda_intel nouveau crct10dif_pclmul 
iwlwifi snd_hda_codec snd_hda_core crc32_pclmul ghash_clmulni_intel snd_hwdep 
ttm i915 snd_pcm aesni_intel aes_x86_64 crypto_simd cryptd drm_kms_helper 
cfg80211 snd_timer sg drm snd glue_helper iTCO_wdt iTCO_vendor_support rfkill 
watchdog i2c_algo_bit soundcore pcc_cpufreq intel_cstate intel_uncore 
intel_rapl_perf joydev serio_raw evdev wmi_bmof mxm_wmi fujitsu_laptop button 
battery sparse_keymap pcspkr ac nfsd auth_rpcgss nfs_acl lockd grace sunrpc tun
Aug 09 09:00:42 apollon kernel:  binfmt_misc ip_tables x_tables autofs4 ext4 
crc16 mbcache jbd2 btrfs zstd_decompress zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom 
sd_mod ahci xhci_pci libahci xhci_hcd libata ehci_pci ehci_hcd psmouse r8169 
usbcore scsi_mod realtek libphy crc32c_intel lpc_ich i2c_i801 mfd_core 
usb_common video wmi
Aug 09 09:00:42 apollon kernel: CR2: 
Aug 09 09:00:42 apollon kernel: ---[ end trace 427904d505b760d2 ]---
Aug 09 09:00:42 apollon kernel: RIP: 0010:0x0
Aug 09 09:00:42 apollon kernel: Code: Bad RIP value.
Aug 09 09:00:42 apollon kernel: RSP: 0018:a9184277fcd8 EFLAGS: 

Bug#934305: Drop Pylons support

[Andrey Rahmatullin]

Package: src:turbogears2
Version: 2.3.12+really2.3.7-1
Severity: important

While we are working on dropping Python 2, and there is already #880154 that
asks about providing Python 3 support, dropping Pylons is a separate task and
it will help with dropping a bunch of obsolete Python 2-only packages, so
please drop the Pylons support from this package.



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

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

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Reinhard Karcher]

Package: src:linux
Version: 5.2.7-1
Severity: normal

Dear Maintainer,

starting with version 5.2.0-2, powertop aborts, version 4.19.0-5 is OK




-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-19)) #1 SMP Debian 5.2.7-1 (2019-08-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=62878f00-afec-4500-affc-1e8ecd1c996e ro 
resume=/dev/disk/by-label/swap quiet nohz_full=1,2,3,4,5,6,7

** Not tainted

** Kernel log:
[   20.627518] AVX version of gcm_enc/dec engaged.
[   20.627518] AES CTR mode by8 optimization enabled
[   21.042236] media: Linux media interface: v0.10
[   21.067768] Console: switching to colour frame buffer device 240x67
[   21.072152] videodev: Linux video capture interface: v2.00
[   21.089373] snd_hda_intel :00:1b.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   21.091896] i915 :00:02.0: fb0: i915drmfb frame buffer device
[   21.092045] nouveau :01:00.0: NVIDIA GF108 (0c1400a1)
[   21.126179] nouveau :01:00.0: bios: version 70.08.a9.00.01
[   21.233964] nouveau :01:00.0: fb: 1024 MiB DDR3
[   21.251083] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   21.251084] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   21.251085] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   21.251086] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 
6205 AGN, REV=0xB0
[   21.263890] iwlwifi :03:00.0: reporting RF_KILL (radio disabled)
[   21.263910] iwlwifi :03:00.0: RF_KILL bit toggled to disable radio.
[   21.296811] vga_switcheroo: enabled
[   21.296902] [TTM] Zone  kernel: Available graphics memory: 4031184 KiB
[   21.296903] [TTM] Zone   dma32: Available graphics memory: 2097152 KiB
[   21.296904] [TTM] Initializing pool allocator
[   21.296907] [TTM] Initializing DMA pool allocator
[   21.296929] nouveau :01:00.0: DRM: VRAM: 1024 MiB
[   21.296930] nouveau :01:00.0: DRM: GART: 1048576 MiB
[   21.296933] nouveau :01:00.0: DRM: TMDS table version 2.0
[   21.296934] nouveau :01:00.0: DRM: DCB version 4.0
[   21.296935] nouveau :01:00.0: DRM: DCB outp 00: 02000300 
[   21.296937] nouveau :01:00.0: DRM: DCB conn 00: 
[   21.297651] nouveau :01:00.0: DRM: MM: using COPY0 for buffer copies
[   21.298157] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   21.298158] [drm] Driver supports precise vblank timestamp query.
[   21.326637] snd_hda_codec_realtek hdaudioC0D0: ALC269VC: SKU not ready 
0x909701f0
[   21.326958] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VC: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   21.326959] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   21.326960] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x15/0x0/0x0/0x0/0x0)
[   21.326961] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   21.326961] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0
[   21.326962] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   21.326963] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x18
[   21.326964] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   21.334017] nouveau :01:00.0: DRM: allocated 1024x768 fb: 0x6, bo 
292cc6e2
[   21.334071] nouveau :01:00.0: fb1: nouveaudrmfb frame buffer device
[   21.334182] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on 
minor 1
[   21.346638] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   21.388017] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[   21.388100] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[   21.388168] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input17
[   21.388252] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input18
[   21.400578] uvcvideo: Found UVC 1.00 device FJ Camera (04f2:b302)
[   21.438250] uvcvideo 1-1.1:1.0: Entity type for entity Extension 3 was not 
initialized!
[   21.438254] uvcvideo 1-1.1:1.0: Entity type for entity Processing 2 was not 
initialized!
[   21.438256] uvcvideo 1-1.1:1.0: Entity type for entity Camera 1 was not 
initialized!
[   21.438368] input: FJ Camera: FJ Camera as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input19
[   21.438478] usbcore: registered new interface driver uvcvideo
[   21.438480] USB Video Class driver (1.1.1)
[   22.369780] intel_rapl: Found RAPL domain package
[   22.369783] intel_rapl: Found RAPL domain core
[   22.369785] intel_rapl: Found RAPL domain uncore
[   22.369795] intel_rapl: RAPL package 0 domain package locked by BIOS
[   24.971080] Adding 16383996k swap on /dev/sda7.  Priority:-2 extents:1 
across:16383996k FS
[   26.379748] ACPI: \_SB_.PCI0.RP00.VGA_: failed to evaluate _DSM
[   27.546099] EXT4-fs (sda9): mounted filesystem with ordered 

Bug#934303: ITP: stratis-cli -- cli interface to stratisd storage management service

[Josua Mayer]

Package: wnpp
Severity: wishlist
Owner: Josua Mayer 

* Package name: stratis-cli
  Version : 1.0.4
  Upstream Author : RedHat, Inc. 
* URL : https://stratis-storage.github.io/
* License : Apache 2.0
  Programming Lang: Python 3
  Description : cli interface to stratisd storage management service

Stratis is a storage management solution built on device-mapper and XFS,
featuring both volume management and snapshot capability.


Being a rather new solution stratis is not yet commonly used.
Version 1.0 was released late 2018. Quoting their announcement, it
"is ready for more widespread testing and evaluation by potential users".

At this point the package will be useful for evaluation and testing of Stratis 
outside
of RedHat systems. My personal motivation is that I am running Debian on a NAS,
and want to explore Stratis on it.
It is my believe that ultimately Stratis will be a much more user-friendly 
alternative to
LVM - and interesting from a technology standpoint.

Obviously the CLI client alone is not useful, instead my goal is to package 
both the daemon,
and the management application. However the client utility is integral to 
testing of the
daemon package, so it should be done first imo.

What I am looking for in the community is co-maintainers /-developers and a 
packaging team
to join for access to build infrastructure, as well as some assistance with the 
packaging
if I come across roadblocks.

Bug#873818: iproute2: Keeping the man page is confusing

[Oliver Schode]

Package: iproute2
Version: 5.2.0-1
Followup-For: Bug #873818

Hi,

the package still ships a man page for ifstat, why is that? Briefly
judging from the changelog I guess it's just been overlooked following a
revert. It probably should be removed, or at least add a short hint to
the readme confirming the removal.

Kind regards,
Oliver

Bug#934273: python3-debian: please support parsing Source: package (version)

[David Bremner]

David Bremner  writes:
> def parse_source(string):
> matches=rex.match(string)
> if matches:
> return (matches.group(1),matches.group(2))
> else:
> return string

Probably return type polymorphism is a terrible idea in python. But I
guess you knew that. Maybe return (string,None) is the simplest
option. Or nicer, find the correct version from the binary package,
which I think is closer to your original idea.

Bug#934209: steam: libGL.so.1 requieres symlink

[Stephan Lachnit]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I removed the symlink and it works fine now. I also installed 
libgl1-nvidia-glx:i386 manually. I don't install recommended packages by 
default, so it wasn't installed before. I think this was the problem. Anyway, 
sorry for this issue, it can be closed now.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJdTUiVAAoJELNbSepdVj7+tg4P+wShSQmyHxLkR+VLm7zg
KdlMqGqs8Irw0QVuDyj9tlW+Pkguuhk2RFBJb6kNhsJjgyNOAZUMScN5mw5a
o56t85o9orz1aqa3lCo2+7m0/0cjxSbcsY7eKhwOOyPj5c5Cv2TIe0pZGgfy
CudIjvenz4yT9BPM/ETjowhC2BmyyHpaALxQOYgr2AXiH3FomSa48CVIFgzP
DpWRQPhxadqC5oA6+piopVwqjpbcTR3kPpOCLnM17THJ7k1B6jfZ1RfpGLqT
EA+EbCCM3v7/Fi0MCTv9jh7HmukveSdx+ltLyIc4uutnYMIVdWtdBff9xXxK
MGJPlNDdnx5w/a9LEhm0AppM1IyZgiF2HiKxt/xTMC8j3wthEV135r7IOfx0
UIoyP4MO33PVNiqS6d3EfRv73i/1p3gGvfXmPd/jv7pW5OuvgWUo359C9gWE
TovgsOMhSmOD0zEk60Ay+XoCbmNJFOT61jVLtiTdUyH/Q4EPhulKrQiBLSGQ
xv0eNYumuzEzVWV3xXEtPWTRAUqNKu1A57A3CsOpKJUiAgV/jz1AKp98botz
7DtJTCcO1Ir9DI2defH4Yz4zcM3FxVlKdoeyTLDsLxw+dMuwiAfdI0DrLTMz
GFpMUVi5jvMvGhkuE4pCX1AFl/aWhkp2s2SdT0PbXwYsFZsjAea7bq5l3zfU
adzF
=YUtC
-END PGP SIGNATURE-

Bug#934302: new upstream version with IPv6 support for charon-nm

[Harald Dunkel]

Package: strongswan
Version: 5.7.2-1

Upstream provides a new strongswan version 5.8.0, including
IPv6 support for charon-nm. See

https://wiki.strongswan.org/issues/1143

Would it be possible to include this version for Bullseye?


Thanx in advance
Harri

Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

[Adam D. Barratt]

On 2019-08-08 19:09, Moritz Mühlenhoff wrote:

On Thu, Aug 08, 2019 at 09:53:16AM +0100, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On 2019-08-08 08:47, Arnaud Rebillout wrote:

[...]

> The debdiff attached brings in an upstream patch to fix
> CVE-2019-1020014, hence closes #933801.

[...]

>* Fixes for security issues should be co-ordinated with the
>  Security Team, unless they have explicitly stated that they
>  will not issue an DSA for the bug (e.g. via a "no-dsa" marker
>  in the Security Tracker) [SECURITY-TRACKER]

[...]

I've CCed them now, let's see what they say.


It's harmless, stable-proposed-updates sounds good. I'll mark it as 
no-dsa

in the security tracker.


Thanks for the confirmation.

The module apparently has three reverse build-dependencies:

amazon-ecr-credential-helper: 
golang-github-docker-docker-credential-helpers-dev

docker-pycreds: golang-docker-credential-helpers
docker.io: golang-github-docker-docker-credential-helpers-dev (>= 
0.6.1~)


Would this update imply any of those needing to be rebuilt? If so, is 
that the end of the tree, or do we end up down a rabbit hole of Go 
libraries?


Regards,

Adam

Bug#933961: gitlab: Viewing diff of a commit results in error 500

[Claudius Steinhauser]

On 08.08.2019 19:22, Pirate Praveen wrote:
> I can provide packages for unstable too via the same repo. 

That would be great if it's not too much work for you. Thanks.

Regards,

Claudius

Bug#933811: fusiondirectory: Fusion directory install fails as imagick is not detected

[Mike Gabriel]

Control: severity -1 normal

Hi Judicael,

I cannot reproduce your issue here... So bug severity reduced to normal.

On  Fr 09 Aug 2019 11:57:44 CEST, Judicael Courant wrote:


Control: reopen -1

Hi,

Thanks for your answer, unfortunately, the issue looks deeper:


I will close this bug, because I think it's a user/admin issue. If you
still think that fusiondirectory is buggy, please reopen this bug by
putting "Control: reopen -1" into the first line of your reply to this
email.


No php7.0 package is left:

~# dpkg -l "*php7.0*"
Desired=Unknown/Install/Remove/Purge/Hold
|  
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  php7.0-common(no description available)
un  php7.0-curl  (no description available)


This very much sounds like your webserver is still running on an older
PHP version (e.g. PHP 7.0 from stretch).

Please note that with Apache2 in Debian when upgrading from stretch to
buster, you need to a2dismod php7.0 and a2enmod php7.3 (with apache2
restart afterwards).


I think I was already running PHP 7.3:

~# a2dismod php7.0
ERROR: Module php7.0 does not exist!
~# a2enmod php7.3
Considering dependency mpm_prefork for php7.3:
Considering conflict mpm_event for mpm_prefork:
Considering conflict mpm_worker for mpm_prefork:
Module mpm_prefork already enabled
Considering conflict php5 for php7.3:
Module php7.3 already enabled

Anyway, I restarted apache:

~# service apache2 restart

And in order to be sure, I added 'phpinfo();' in this file:


I wrote the following php code and put it in /var/www/html/atest.php :
--
A simple test
  
  

--


I get 'PHP Version 7.3.4-2' both when I execute it via the command line
and when I run it through apache.

With the command line, Imagick is detected:

/var/www/html# php atest.php|grep -i imagick
Imagick detectedphpinfo()
/etc/php/7.3/cli/conf.d/20-imagick.ini,
imagick
imagick module => enabled
imagick module version => 3.4.3
imagick classes => Imagick, ImagickDraw, ImagickPixel,  
ImagickPixelIterator, ImagickKernel
Imagick compiled with ImageMagick version => ImageMagick 6.9.10-23  
Q16 x86_64 20190101 https://imagemagick.org
Imagick using ImageMagick library version => ImageMagick 6.9.10-23  
Q16 aarch64 20190101 https://imagemagick.org

imagick.locale_fix => 0 => 0
imagick.progress_monitor => 0 => 0
imagick.skip_version_check => 1 => 1

With apache, Imagick is not detected: the only occurence of 'imagick' I
could find in the web page I got is 'Imagick not detected' :-(

Yours,

Judicael.

PS: Even if this problem renders fusiondirectory useless to me, maybe it
should be reassigned to package php7.3?


Please try all of this with a very fresh installation and see if  
things work then out of the box.


If not, we have an issue in one of the DEBs, if it works, you have an  
issue on that machine. Let's find out which of that is the case.


Thanks+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



pgp68tDlIFG4f.pgp
Description: Digitale PGP-Signatur

Bug#933811: fusiondirectory: Fusion directory install fails as imagick is not detected

[Judicael Courant]

Control: reopen -1

Hi,

Thanks for your answer, unfortunately, the issue looks deeper:

> I will close this bug, because I think it's a user/admin issue. If you  
> still think that fusiondirectory is buggy, please reopen this bug by  
> putting "Control: reopen -1" into the first line of your reply to this  
> email.

No php7.0 package is left:

~# dpkg -l "*php7.0*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  php7.0-common(no description available)
un  php7.0-curl  (no description available)

> This very much sounds like your webserver is still running on an older  
> PHP version (e.g. PHP 7.0 from stretch).
>
> Please note that with Apache2 in Debian when upgrading from stretch to  
> buster, you need to a2dismod php7.0 and a2enmod php7.3 (with apache2  
> restart afterwards).

I think I was already running PHP 7.3:

~# a2dismod php7.0
ERROR: Module php7.0 does not exist!
~# a2enmod php7.3
Considering dependency mpm_prefork for php7.3:
Considering conflict mpm_event for mpm_prefork:
Considering conflict mpm_worker for mpm_prefork:
Module mpm_prefork already enabled
Considering conflict php5 for php7.3:
Module php7.3 already enabled

Anyway, I restarted apache:

~# service apache2 restart

And in order to be sure, I added 'phpinfo();' in this file:

>> I wrote the following php code and put it in /var/www/html/atest.php :
>> --
>> A simple test
>>   
>>   >   $R = class_exists('Imagick', FALSE);
>>   if ($R) {
>>echo "Imagick detected";
>>   } else {
>>   echo "Imagick not detected";
>>   }
>> ?>
>> 
>> --

I get 'PHP Version 7.3.4-2' both when I execute it via the command line
and when I run it through apache.

With the command line, Imagick is detected:

/var/www/html# php atest.php|grep -i imagick
Imagick detectedphpinfo()
/etc/php/7.3/cli/conf.d/20-imagick.ini,
imagick
imagick module => enabled
imagick module version => 3.4.3
imagick classes => Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator, 
ImagickKernel
Imagick compiled with ImageMagick version => ImageMagick 6.9.10-23 Q16 x86_64 
20190101 https://imagemagick.org
Imagick using ImageMagick library version => ImageMagick 6.9.10-23 Q16 aarch64 
20190101 https://imagemagick.org
imagick.locale_fix => 0 => 0
imagick.progress_monitor => 0 => 0
imagick.skip_version_check => 1 => 1

With apache, Imagick is not detected: the only occurence of 'imagick' I
could find in the web page I got is 'Imagick not detected' :-(

Yours,

Judicael.

PS: Even if this problem renders fusiondirectory useless to me, maybe it
should be reassigned to package php7.3?

-- 
TEL : (+33) (0)4 72 50 48 13
GPG public key: 783D F28F DBEA 5600 C0CB A7C4 828A B452 479A 5941

Bug#934301: ack searches the output file creating a loop

[ali]

Package: ack
Version: 2.24-1
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

   * What led up to the situation?
 Searching a string in a folder with only a single file in it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I've run "ack Time > time.txt" in a folder that had only one file
 in it (8MB mysql-slow.log.1 to be exact).

   * What was the outcome of this action?
 time.txt file ended up being 14GB in size, filling the disk to 100%
 and crashing the database.

   * What outcome did you expect instead?
 A similar outcome with "ack Time mysql-slow.log.1 > time.txt" which
 results in an output 135KB file.

   * To recreate the problem the file that is being searched needs to be
 big enough, the string that is being searched needs to be scarce
 enough and the output filename should not contain the searched
 string. I can provide the file if needed.

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

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

Versions of packages ack depends on:
ii  libfile-next-perl  1.16-2
ii  perl   5.28.1-6

ack recommends no packages.

ack suggests no packages.

-- no debconf information

Bug#934300: buster-pu: package apt/1.8.3~deb10u1

[Julian Andres Klode]

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

(sorry, no fix for the allow-releaseinfo-change stuff yet!)

I just uploaded 1.8.3 to unstable which includes a fix for HTTPS
proxying - when using the CONNECT method, we were sending the proxy's
host name in the Host header, where we should have sent the destination
host name.

This breaks ACLs on proxies that filter on that field and might thus
prevent access to HTTPS repositories over such proxies.

A test case has been included that can be run with autopkgtest, and is
running on CI.

The 1.8.3 also includes a change to the apport hook to exclude squashfs
file systems in the output (to hide installed snaps) - this only affects
Ubuntu, though. I'd prefer to keep one 1.8.y branch rather than have a
1.8.2.z for buster, if possible, so I'd love if we could get it in like
this (the 1.8.y branch currently covers unstable, stable, and ubuntu
disco, but the ubuntu one will be gone in a few months, so it's likely
a one,two time thing).

The attached diff is the 1.8.3 uploaded to unstable. The stable upload
would have the version and upload target replaced in the changelog to
read "1.8.3~deb10u1) buster" instead of "1.8.3) unstable". I'd expect
buster to eventually take over 1.8.y properly and then we'd get 1.8.4
for buster instead of 1.8.4~deb10u1 for example.

-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (991, 'eoan'), (500, 'eoan'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru apt-1.8.2/apt-pkg/deb/dpkgpm.cc apt-1.8.3/apt-pkg/deb/dpkgpm.cc
--- apt-1.8.2/apt-pkg/deb/dpkgpm.cc	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/apt-pkg/deb/dpkgpm.cc	2019-08-09 11:16:15.0 +0200
@@ -2475,7 +2475,7 @@
{
 
   fprintf(report, "Df:\n");
-  FILE *log = popen("/bin/df -l","r");
+  FILE *log = popen("/bin/df -l -x squashfs","r");
   if(log != NULL)
   {
 	 char buf[1024];
diff -Nru apt-1.8.2/CMakeLists.txt apt-1.8.3/CMakeLists.txt
--- apt-1.8.2/CMakeLists.txt	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/CMakeLists.txt	2019-08-09 11:16:15.0 +0200
@@ -193,7 +193,7 @@
 # Configure some variables like package, version and architecture.
 set(PACKAGE ${PROJECT_NAME})
 set(PACKAGE_MAIL "APT Development Team ")
-set(PACKAGE_VERSION "1.8.2")
+set(PACKAGE_VERSION "1.8.3")
 
 if (NOT DEFINED DPKG_DATADIR)
   execute_process(COMMAND ${PERL_EXECUTABLE} -MDpkg -e "print $Dpkg::DATADIR;"
diff -Nru apt-1.8.2/debian/changelog apt-1.8.3/debian/changelog
--- apt-1.8.2/debian/changelog	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/debian/changelog	2019-08-09 11:16:15.0 +0200
@@ -1,3 +1,13 @@
+apt (1.8.3) unstable; urgency=medium
+
+  [ Simon Körner ]
+  * http: Fix Host header in proxied https connections (LP: #1838771)
+
+  [ Brian Murray ]
+  * Do not include squashfs file systems in df output. (LP: #1756595)
+
+ -- Julian Andres Klode   Fri, 09 Aug 2019 11:16:15 +0200
+
 apt (1.8.2) unstable; urgency=medium
 
   [ Alwin Henseler ]
diff -Nru apt-1.8.2/doc/apt-verbatim.ent apt-1.8.3/doc/apt-verbatim.ent
--- apt-1.8.2/doc/apt-verbatim.ent	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/doc/apt-verbatim.ent	2019-08-09 11:16:15.0 +0200
@@ -268,7 +268,7 @@
 ">
 
 
-
+
 
 
 
diff -Nru apt-1.8.2/doc/po/apt-doc.pot apt-1.8.3/doc/po/apt-doc.pot
--- apt-1.8.2/doc/po/apt-doc.pot	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/doc/po/apt-doc.pot	2019-08-09 11:16:15.0 +0200
@@ -5,9 +5,9 @@
 #, fuzzy
 msgid ""
 msgstr ""
-"Project-Id-Version: apt-doc 1.8.2\n"
+"Project-Id-Version: apt-doc 1.8.3\n"
 "Report-Msgid-Bugs-To: APT Development Team \n"
-"POT-Creation-Date: 2019-05-28 16:41+0200\n"
+"POT-Creation-Date: 2019-08-09 11:16+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
diff -Nru apt-1.8.2/methods/http.cc apt-1.8.3/methods/http.cc
--- apt-1.8.2/methods/http.cc	2019-05-28 16:40:29.0 +0200
+++ apt-1.8.3/methods/http.cc	2019-08-09 11:16:15.0 +0200
@@ -320,14 +320,14 @@
std::string ProperHost;
 
if (Host.find(':') != std::string::npos)
-  ProperHost = '[' + Proxy.Host + ']';
+  ProperHost = '[' + Host + ']';
else
-  ProperHost = Proxy.Host;
+  ProperHost = Host;
 
// Build the connect
Req << "CONNECT " << Host << ":" << std::to_string(Port) << " HTTP/1.1\r\n";
if (Proxy.Port != 0)
-  Req << "Host: " << ProperHost << ":" << 

Bug#933827: "dgit fetch" fails with "cannot remove directory for ..."

[Stéphane Glondu]

Le 09/08/2019 à 11:11, Ian Jackson a écrit :
> Thank you for investigating and providing a patch.  Very helpful.
> 
> Would you might please confirming your permission for me to distribute
> your change (and your name etc.), according to the Developer
> Certificate of Origin[1] ?  You can do this in a commit message by
> adding your Signed-off-by line (git commit -s), or with your approval
> I can put it in for you.

Yes, I confirm and you have my approval to put it for me.


Cheers,

-- 
Stéphane

Bug#934032: libjaxen-java: FTBFS in stretch (failing tests, IllegalArgumentException)

[Emmanuel Bourg]

Le 09/08/2019 à 11:06, Santiago Vila a écrit :

> Point releases exist to fix bugs like this one, so I don't see why I
> would have to stop reporting them.

If you do so, please amend the existing bugs instead of opening new ones
(in this case #909216 should have been unarchived and modified to change
the package version).

Emmanuel Bourg

Bug#917996: texlive-pstricks: gs gives undefined in --execute-- when using color.tex with pstricks on plain tex.

[Hilmar Preuße]

Am 02.01.2019 um 05:24 teilte P V Mathew mit:

Hi,

> Inclusion of color.tex and calling \pscircle. plain tex compiled ok
> with
>   >tex test.tex 
> and created test.dvi 
> But running xdvi on generated test.dvi file results in gs error.
> If we remove the \input color line, every thing works ok.
> 
Here is the difference between the Postscript files:

hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/917996$ diff
917996_1.ps 917996.ps



2881,2883c2881,2883
<  0.8 SLW 0. setgray   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round
< sub dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW 0. setgray  1.
< .setopacityalpha   0  setlinejoin 0  setlinecap stroke  grestore end
---
>  0.8 SLW gray 0   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round sub
> dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW gray 0  1.
.setopacityalpha
>   0  setlinejoin 0  setlinecap stroke  grestore end

So it is basically how the color is specified, in case the color package
is called, the command is "gray", meanwhile w/o it is "setgray". At the
first glance the last command is the correct one. So it seems to be a
bug in color.sty...but I'm not 100% confident as I don't speak Postscript.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#934299: RFS: socketapi/2.2.15-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: socketapi
Version: 2.2.15-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/sctplib/
  * License: GPL-3+
  * Section: net

SocketAPI is the socket API library for the SCTPLIB user-space SCTP
implementation.

"socketapi " builds these
binary packages:

  * libsctpsocket2 - Socket API library for sctplib
  * libsctpsocket-dev - Development package for Socket-API

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/socketapi.

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

dget -x 
https://mentors.debian.net/debian/pool/main/s/socketapi/socketapi_2.2.15-1.dsc

More information about "socketapi
" can be obtained from
https://www.uni-due.de/~be0001/sctplib/.

Most recent changelog entry:

-- 

Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula Research Laboratory A/S
 SimulaMet — Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#934298: RFS: tsctp/0.7.3-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: tsctp
Version: 0.7.3-1
Upstream Author: Michael Tüxen mailto:tue...@fh-muenster.de>>
  * URL: https://www.uni-due.de/~be0001/tsctp/
  * License: BSD-3-clause GPL-3+
  * Section: net

TSCTP is an SCTP test tool. Its purpose is to perform basic SCTP
functionality tests to check implementations interoperability and to
verify that the SCTP stack is working.

"tsctp " builds these binary
packages:

  * tsctp - SCTP Test Tool

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/tsctp.

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

dget -x https://mentors.debian.net/debian/pool/main/t/tsctp/tsctp_0.7.3-1.dsc

More information about "tsctp "
can be obtained from https://www.uni-due.de/~be0001/tsctp/.

-- 

Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula Research Laboratory A/S
 SimulaMet — Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#934297: RFS: bibtexconv/1.1.16-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: bibtexconv
Version: 1.1.16-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/bibtexconv/
  * License: GPL-3+
  * Section: tex

BibTeXConv is a BibTeX file converter which allows to export BibTeX
entries to other formats, including customly defined text output.
Furthermore, it provides the possibility to check URLs (including MD5,
size and MIME type computations) and to verify ISBN and ISSN numbers.

"bibtexconv " builds these
binary packages:

  * bibtexconv - BibTeX Converter
  * ietf2bibtex - Create BibTeX entry for IETF document (RFC or Internet
Draft)

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/bibtexconv.

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bibtexconv/bibtexconv_1.1.16-1.dsc

More information about "bibtexconv
" can be obtained from
https://www.uni-due.de/~be0001/bibtexconv/.

Most recent changelog entry:

bibtexconv (1.1.16-1ubuntu1) disco; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.4.0.1.

-- Thomas Dreibholz > Wed, 07 Aug 2019
17:40:55 +0200

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula Research Laboratory A/S
 SimulaMet — Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#934296: RM: fookebox -- RoQA; orphaned; uses obsolete libs

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

This package is the only package in the archive using the Pylons library which
is Py2-only and will be removed. It is orphaned and no upstream development
happened since 2015.

Bug#934295: nvidia-legacy-340xx-driver: Fails to build with kernel 5.2

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.107-4
Severity: normal

Dear Maintainer,

I installed kernel 5.2, which hit the repo yesterday, and its headers and I
noticed that dkms fails to build the nvidia driver with that kernel version.

Log on pastebin.com
https://pastebin.com/PexXxCKu



-- Package-specific info:
uname -a:
Linux mitsos 4.19.0-5-amd64 #1 SMP Debian 4.19.37-6 (2019-07-18) x86_64 
GNU/Linux

/proc/version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 24 21:54:01 
PDT 2018
GCC version:  gcc version 8.3.0 (Debian 8.3.0-6) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.349393] Console: colour VGA+ 80x25
[0.400307] pci :01:00.0: vgaarb: setting as boot VGA device
[0.400307] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.400307] pci :01:00.0: vgaarb: bridge control possible
[0.400307] vgaarb: loaded
[0.852134] Linux agpgart interface v0.103
[3.358457] nvidia: loading out-of-tree module taints kernel.
[3.358468] nvidia: module license 'NVIDIA' taints kernel.
[3.381648] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.397876] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.398274] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.398286] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 
24 21:54:01 PDT 2018
[3.797998] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[5.082763] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22
[5.083061] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input23
[5.083137] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24
[5.083212] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25
[7.172169] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Aug  9 12:00 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Aug  9 12:00 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Aug  9 12:00 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Aug  9 12:00 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Nov 21  2017 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Nov 21  2017 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Nov 21  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 21  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   54 Nov 21  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Nov 21  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   25 Nov 21  2017 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Nov 21  2017 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Nov 21  2017 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Nov 21  2017 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Nov 21  2017 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Nov 21  2017 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Nov 21  2017 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Jan 12  2019 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/legacy-340xx
lrwxrwxrwx 1 root root   57 Jan 12  

Bug#931449: imagemagick: CVE-2019-13305/CVE-2019-13306

[Hugo Lefeuvre]

Hi,

These issues are similar, both fixed by [0]. Upstream claims to have fixed
CVE-2019-13306 via [1] but this is wrong, [1] is reverted by [0].

I took some time to investigate this vulnerability. Unless I am mistaken,
this allows for arbitrary stack buffer overflow up to 10 bytes via pixel
luma values. My exploitation skills are limited, but this could be an
exploitable vulnerability.

I think this should be fixed, at least via point release?

regards,
Hugo

[0] 
https://github.com/ImageMagick/ImageMagick6/commit/5c7fbf9a14fb83c9685ad69d48899f490a37609d
[1] 
https://github.com/ImageMagick/ImageMagick6/commit/cb5ec7d98195aa74d5ed299b38eff2a68122f3fa

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#933827: "dgit fetch" fails with "cannot remove directory for ..."

[Ian Jackson]

Stéphane Glondu writes ("Bug#933827: "dgit fetch" fails with "cannot remove 
directory for ...""):
> Control: tags -1 + patch
> Le 09/08/2019 à 07:12, Stéphane Glondu a écrit :
> > Adding "close F;" to line 4023 of /usr/bin/dgit (before chomp) seems to
> > fix the bug.
> 
> Patch attached.

Thank you for investigating and providing a patch.  Very helpful.

Would you might please confirming your permission for me to distribute
your change (and your name etc.), according to the Developer
Certificate of Origin[1] ?  You can do this in a commit message by
adding your Signed-off-by line (git commit -s), or with your approval
I can put it in for you.

[1] https://browse.dgit.debian.org/dgit.git/tree/DEVELOPER-CERTIFICATE

If you have questions about the s-o-b process I'll be happy to answer
them; maybe private email would be best.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#934010: virtualbox: still true, different error

[Paolo Cavallini]

Package: virtualbox
Version: 6.0.10-dfsg-4
Followup-For: Bug #934010

Dear Maintainer,

the package FTB in my box, with a different error:

  CC [M]  /var/lib/dkms/virtualbox-guest/6.0.10/build/vboxvideo/vbox_ttm.o
/var/lib/dkms/virtualbox-guest/6.0.10/build/vboxvideo/vbox_ttm.c:31:10: fatal 
error: ttm/ttm_page_alloc.h: File o directory non esistente
 #include 
  ^~
compilation terminated.
make[4]: *** [/usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.build:284: 
/var/lib/dkms/virtualbox-guest/6.0.10/build/vboxvideo/vbox_ttm.o] Error 1
make[4]: *** Attesa per i processi non terminati
make[3]: *** [/usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.build:494: 
/var/lib/dkms/virtualbox-guest/6.0.10/build/vboxvideo] Error 2
make[2]: *** [/usr/src/linux-headers-5.2.0-2-common/Makefile:1610: 
_module_/var/lib/dkms/virtualbox-guest/6.0.10/build] Error 2
make[1]: *** [Makefile:179: sub-make] Error 2
make: *** [Makefile:8: all] Error 2
make: uscita dalla directory "/usr/src/linux-headers-5.2.0-2-amd64"

Thanks for any hint.

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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.2.0-1
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.65.1-1
ii  libdevmapper1.02.12:1.02.155-3
ii  libgcc1   1:9.1.0-10
ii  libgl11.1.0-1
ii  libgsoap-2.8.75   2.8.75-2
ii  libopus0  1.3-1
ii  libpng16-16   1.6.37-1
ii  libpython3.7  3.7.4-2
ii  libqt5core5a  5.11.3+dfsg1-2+b1
ii  libqt5gui55.11.3+dfsg1-2+b1
ii  libqt5opengl5 5.11.3+dfsg1-2+b1
ii  libqt5widgets55.11.3+dfsg1-2+b1
ii  libqt5x11extras5  5.11.3-2
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1c-1
ii  libstdc++69.1.0-10
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx6   1.8.1-2
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.2.0-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3.7 3.7.4-2
ii  virtualbox-dkms [virtualbox-modules]  6.0.10-dfsg-4
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages virtualbox recommends:
ii  libxcb11.13.1-2
ii  virtualbox-qt  6.0.10-dfsg-4

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.0.10-1

-- no debconf information

Bug#913481: confirm

[Alexander Dahl]

Hello Axel,

On Thu, Aug 08, 2019 at 10:17:44PM +0200, Axel Beckert wrote:
> I though never ran into this myself (and wasn't aware of that comment
> in mkswap). I also never came across a Raspbian using F2FS so far
> although the idea sounds quite obvious.

FTR, this is no configuration Raspbian comes with by default. You have
to backup the default content (ext4?), install the necessary
f2fs-tools, reformat the root partition with f2fs, update your
/etc/fstab and the fix all upcoming problems by yourself. ;-)

I liked the idea and wanted to play with it, especially because I saw
SD-cards die and F2FS promises to be gentle to the card and thus delay
that problem.

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Bug#934032: libjaxen-java: FTBFS in stretch (failing tests, IllegalArgumentException)

[Santiago Vila]

On Thu, Aug 08, 2019 at 09:43:53AM +0200, Emmanuel Bourg wrote:
> If a build issue appeared *after* the release, due to a regression
> caused by a point release, then yes I think the issue is worth reporting
> (but I wouldn't bother reporting minor test failures that can be easily
> skipped to rebuild from sources).

You keep saying "minor" but it actually makes the build to fail!

This is certainly not what we expect to happen in a supported release and
it's already written in Release Policy: Packages must build without
failure, it refers to dpkg-buildpackage exit status, which in this case
indicates failure, it does not refer to the build *without* the tests.

And no, it's not easy to skip, by default DEB_BUILD_OPTIONS does not
contain nocheck, so by the time the end user realizes that the package
fails to build, it's too late and we have already make them to lose
their time, because the process of building the package stopped
and the binary packages are not generated.

Point releases exist to fix bugs like this one, so I don't see why I
would have to stop reporting them.

In either case, I'm not sure where is the problem for you. I'm not
specifically asking you to do anything (I could not, we are all
volunteers), and there is no autoremoving of packages in stable or
oldstable. So you could ignore the bug if you dislike it so much.
I only ask that you respect that this is a serious bug in stretch,
which means keeping the door open for a fix, i.e. allowing somebody
else to fix if you are unwilling. That's all.

Thanks.

Bug#934294: installation-reports: [armv7l] buster installation on BananaPro

[Hermann Lauer]

Package: installation-reports
Severity: minor
Tags: d-i

Dear Maintainer,

overall installation went rather fine, thanks a lot for work on arm buster!

U-Boot SPL 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2

=> dhcp
=> setenv installer-path "/bapro/debian-installer/armhf/"
=> tftpboot ${fdt_addr_r} ${installer-path}dtbs/${fdtfile}
=> tftpboot ${kernel_addr_r} ${installer-path}vmlinuz
=> tftpboot ${ramdisk_addr_r} ${installer-path}initrd.gz
=> bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

Bootloader is not reinstalled, as booting directly from the classic u-Boot
environment to avoid ugly fat partitioning and a custom kernel ist needed:
The machine runs a HIFIBerry Amp+ 1.0 over i2s, so a selfcompiled 5.2.x kernel
with patches available at 
https://bitbucket.org/hlauer/kernel/src/default/patches/
is used after the initial installation.

Thanks,
 greetings
  Hermann

-- Package-specific info:

Boot method: network
Image version: 
http://ftp.nl.debian.org/debian/dists/buster/main/installer-armhf/current/images/netboot/netboot.tar.gz
 20190702
Date: 27.7.2019

Machine: BananaPro
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs460284   0460284   0% /dev
tmpfs  tmpfs   1025282916 99612   3% /run
/dev/md0   ext4   1891216 1528088249008  86% /
tmpfs  tmpfs   512628   0512628   0% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs   512628   0512628   0% /sys/fs/cgroup
/dev/sda2  ext4  74474472 2629664  68018628   4% /home
tmpfs  tmpfs   102524   0102524   0% /run/user/0


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[ ]
Overall install:[O]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux bapro 4.19.0-5-armmp #1 SMP Debian 4.19.37-5 (2019-06-19) 
armv7l GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: raid1  45056  1
lsmod: dm_mod122880  0
lsmod: md_mod143360  2 raid1
lsmod: jfs   184320  0
lsmod: btrfs1228800  0
lsmod: libcrc32c  16384  1 btrfs
lsmod: xor16384  1 btrfs
lsmod: zstd_decompress61440  1 btrfs
lsmod: zstd_compress 159744  1 btrfs
lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
lsmod: zlib_deflate   28672  1 btrfs
lsmod: raid6_pq   98304  1 btrfs
lsmod: vfat   24576  0
lsmod: fat73728  1 vfat
lsmod: ext4  614400  1
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2 

Bug#932470: O: adminer -- web-based database administration tool

[Alexandre Rossi]

> > Should I update myself the VCS repository? Or should we move it out of
> > your personnal area on salsa? Perhaps in the Debian group?
> 
> Good idea. Can you create a repo in the Debian group? If so, please
> just go ahead and do that and push the entire history (etc.) there and
> then let me know it is safe to remove mine.

I cannot find the Debian group in the project creation form on salsa so
I think I am not allowed to create new projects in the Debian group.

Alex

Bug#481238: host key fingerprints in .ssh/config

[brian m. carlson]

On 2008-05-26 at 10:12:49, Colin Watson wrote:
> On Wed, May 14, 2008 at 07:13:32PM +0100, martin f krafft wrote:
> > Just an idea without having given it much thought:
> > 
> > if there are host key fingerprints in DNS, why not add
> > a configuration option to ssh_config so that I could say:
> > 
> >   Host foo
> > HostKeyFingerprint 99:11:ed:30:03:41:ff:9f:f3:74:bd:7d:e1:8f:04:44
> > 
> > which would then cause even StrictHostKeyChecking to accept the host
> > key into .ssh/known_hosts if the fingerprint matched?
> 
> I'm not sure I understand. Why not just add the fingerprint to
> ~/.ssh/known_hosts directly? What does putting it in the configuration
> file gain you?

One way in which this would be helpful is not in the configuration file,
but in scripting. All the options in ".ssh/config" can also be used on
the command line. If you can write "ssh -o HostKeyFingerprint=foo", then
you can securely connect in a script without needing "-o
StrictHostKeyChecking=no".

This would be enormously valuable as a way to write secure command-line
scripts without having to embed a full public key. It would also match
the new OpenSSH feature to allow specifying a fingerprint at the prompt.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#934264: Please update (4.6.2?) and provide/switch to python3

[Andreas Tille]

Hi Yaroslav,

On Thu, Aug 08, 2019 at 04:58:03PM -0400, Yaroslav Halchenko wrote:
> Package: mayavi2
> Version: 4.5.0-1
> Severity: normal
> 
> 4.5.0 still causes segfaults for me (while trying to build/test python-mne
> package).  I could not get to upstream's download page for mayavi2 (server 
> bogs
> out), but conda seems to have 4.6.2 https://anaconda.org/anaconda/mayavi  so 
> I guess
> it is out there.

Its definitely out and the watch file reports a new version which even
supports Python3.  I've updated the packaging Git[1] to latest packaging
standards (attention, since I know NeuroDebian prefers lower versions
of debhelper - feel free to revert my switch to debhelper 12!) and
tried to convert the build system to Python3 but unfortunately the
configure step fails with:

...
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
--
Building TVTK classes... Traceback (most recent call last):
  File "setup.py", line 474, in 
  File "/usr/lib/python3/dist-packages/numpy/distutils/core.py", line 171, in 
setup
return old_setup(**new_attr)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 145, in 
setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "setup.py", line 268, in run
  File "setup.py", line 254, in build_tvtk_classes_zip
  File "tvtk/setup.py", line 99, in gen_tvtk_classes_zip
gen.generate_code()
  File "/build/mayavi2-4.7.1/tvtk/code_gen.py", line 131, in generate_code
self._write_wrapper_class(node, tvtk_name)
  File "/build/mayavi2-4.7.1/tvtk/code_gen.py", line 221, in 
_write_wrapper_class
self.wrap_gen.generate_code(node, out)
  File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 250, in generate_code
self._gen_methods(node, out)
  File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 371, in _gen_methods
self._gen_get_methods(klass, out)
  File "/build/mayavi2-4.7.1/tvtk/wrapper_gen.py", line 919, in _gen_get_methods
if len(sig) == 1 and sig[0][1] is None:
TypeError: object of type 'NoneType' has no len()
E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: pybuild --build -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:10: build] Error 255
dpkg-buildpackage: error: debian/rules build gave error exit status 2
I: copying local configuration
E: Failed autobuilding of package


I'd be happy if someone would take over from here since I'll be busy
with real life for the next 10 days.

Remark: Since it seems the package is not really maintained by the
Uploader inside the PAPT team and entering the PAPT team might take a
bit longer I'd consider it a sensible step to take over the package to
Debian Science team to enable more people an easy access to the
repository.  I'm not keen on "nursing" merge requests of grown up
Python developers just because these are not part of PAPT team.

Kind regards

  Andreas.


[1] https://salsa.debian.org/python-team/applications/mayavi2

-- 
http://fam-tille.de

Bug#934293: fuse3.postinst fails

[Roderich Schupp]

Package: fuse3
Version: 3.4.1-1
Severity: normal

root@nuc8:/home/roderich# apt install fuse3
...
Setting up fuse3 (3.4.1-1) ...
dpkg: error processing package fuse3 (--configure):
 installed fuse3 package post-installation script subprocess returned error
exit status 1
Errors were encountered while processing:
 fuse3
E: Sub-process /usr/bin/dpkg returned an error code (1)


The problem is line 34 of fuse3.postint, running it by hand gives

root@nuc8:/home/roderich# udevadm test --action -p  $(udevadm info -q path -n
/dev/fuse)
Invalid action '-p'


Cheers, Roderich




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

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

Versions of packages fuse3 depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libfuse3-3  3.4.1-1
ii  lsb-base10.2019051400
ii  mount   2.34-0.1
ii  sed 4.7-1

fuse3 recommends no packages.

fuse3 suggests no packages.

-- Configuration Files:
/etc/fuse.conf [Errno 2] No such file or directory: '/etc/fuse.conf'

-- no debconf information

Bug#934289: evince-common: Make evince compatible with mailcap.order

[Jakub Wilk]

* Judicael Courant , 2019-08-09, 10:07:

I would like 'see foo.pdf' to open evince (for all users).

I guess mailcap.order(5) is the right place to give evince priority 
over other pdf readers. Unfortunately that does not work: I added the 
line


evince:application/pdf


FWIW, you should be able to make it work by using the name of the deskop 
file:


org.gnome.Evince:application/pdf

Admittedly this is neither intuitive nor (AFAIK) documented anywhere. :-/

--
Jakub Wilk

Bug#933835: Info received (Bug#933835: libreoffice not start with fatal exception signal 11)

[Rene Engelhard]

Hi,

On Fri, Aug 09, 2019 at 07:51:55AM +0300, Timur Irikovich Davletshin wrote:
> I believe this bug should be reopened.

Not sure.

> Right version of atk library is not in the dependencies of this build.

OK, but that would be a bug in atk that they are not giving us correct
dependency information.. I could force a newer dependency, but... The
code is the same as in "official builds" so it has to be something with
atk itself.

But see below.

> Regular installation via apt-get 
> -t buster-backports install libreoffice leads to non working state.

Just did this on my buster.

LO starts after that.

atk from bster. Maybe the problem exhibits itself only if you enable some 
"special"
accessibility? (My only accessibility-related option I enabled is
"Big fonts" and "Visual warnings" in gnome-shells "panel".
 
> P.S. Official builds work fine btw...

Because they build with an old atk? (CentOS 7 TTBOMK)

Regards,

Rene

Bug#934291: Extend qa.debian.org/cgi-bin/vcswatch graphs to cover Salsa info

[Otto Kekäläinen]

Package: qa.debian.org
Severity: wishlist

The page https://qa.debian.org/cgi-bin/vcswatch currently lists stats
about what VCS packages are using.

Could you please extend this check to also include a graph on how many
packages have 'salsa.debian.org' in their VCS field?

This should be fairly trivial to implement, and it would be nice to
know how the situation evolves.

Hopefully more and more packages would migrate to Salsa.


I would also like to have stats on how many packages have a
debian/gitlab-ci.yml or debian/salsa-ci.yml but that is probably out
of the scope for vcswatch, as I assume it only scans the control files
of each package and not the debian/* contents otherwise.

Bug#934292: powertop: running powertop introduces "kernel NULL pointer dereference"

[Vincas Dargis]

Package: powertop
Version: 2.8-1+b2
Severity: normal

Dear Maintainer,

Just tried to run `powertop` (after Linux 5.2 upgrade, but not sure if it
worked for me before, ever used it):

```
$ sudo powertop
modprobe cpufreq_stats failedCannot load from file
/var/cache/powertop/saved_results.powertop
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with
battery only 
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask f
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask f
Nutraukta (killed)
```

Meanwhile, on kernel.log:
```
Aug  9 11:24:47 vinco kernel: [ 6493.332451] BUG: kernel NULL pointer 
dereference, address: 
Aug  9 11:24:47 vinco kernel: [ 6493.332455] #PF: supervisor instruction fetch 
in kernel mode
Aug  9 11:24:47 vinco kernel: [ 6493.332456] #PF: error_code(0x0010) - 
not-present page
Aug  9 11:24:47 vinco kernel: [ 6493.332458] PGD 0 P4D 0 
Aug  9 11:24:47 vinco kernel: [ 6493.332460] Oops: 0010 [#12] SMP PTI
Aug  9 11:24:47 vinco kernel: [ 6493.332463] CPU: 3 PID: 20189 Comm: powertop 
Tainted: G  DOE 5.2.0-2-amd64 #1 Debian 5.2.7-1
Aug  9 11:24:47 vinco kernel: [ 6493.332464] Hardware name: ASUSTeK COMPUTER 
INC. N551JM/N551JM, BIOS N551JM.205 02/13/2015
Aug  9 11:24:47 vinco kernel: [ 6493.332467] RIP: 0010:0x0
Aug  9 11:24:47 vinco kernel: [ 6493.332470] Code: Bad RIP value.
Aug  9 11:24:47 vinco kernel: [ 6493.332471] RSP: 0018:a3da897dbcd8 EFLAGS: 
00010246
Aug  9 11:24:47 vinco kernel: [ 6493.332473] RAX:  RBX: 
8917f2e5f800 RCX: 0001
Aug  9 11:24:47 vinco kernel: [ 6493.332474] RDX: 891b5bd60c00 RSI: 
8917f2e5f800 RDI: 891b5e773090
Aug  9 11:24:47 vinco kernel: [ 6493.332475] RBP: 891b5e773090 R08: 
 R09: 
Aug  9 11:24:47 vinco kernel: [ 6493.332476] R10: 891b5e725d80 R11: 
 R12: 8917f2e5f810
Aug  9 11:24:47 vinco kernel: [ 6493.332477] R13: 9c11cdd0 R14: 
 R15: 8917f2e5f800
Aug  9 11:24:47 vinco kernel: [ 6493.332479] FS:  7f619c6befc0() 
GS:891b5ecc() knlGS:
Aug  9 11:24:47 vinco kernel: [ 6493.332480] CS:  0010 DS:  ES:  CR0: 
80050033
Aug  9 11:24:47 vinco kernel: [ 6493.332482] CR2: ffd6 CR3: 
000341aba001 CR4: 001626e0
Aug  9 11:24:47 vinco kernel: [ 6493.332483] Call Trace:
Aug  9 11:24:47 vinco kernel: [ 6493.332488]  do_dentry_open+0x13a/0x370
Aug  9 11:24:47 vinco kernel: [ 6493.332493]  path_openat+0x2c6/0x1480
Aug  9 11:24:47 vinco kernel: [ 6493.332496]  ? 
mem_cgroup_commit_charge+0x80/0x4d0
Aug  9 11:24:47 vinco kernel: [ 6493.332499]  do_filp_open+0x93/0x100
Aug  9 11:24:47 vinco kernel: [ 6493.332502]  ? __check_object_size+0x15d/0x189
Aug  9 11:24:47 vinco kernel: [ 6493.332505]  do_sys_open+0x184/0x220
Aug  9 11:24:47 vinco kernel: [ 6493.332509]  do_syscall_64+0x53/0x130
Aug  9 11:24:47 vinco kernel: [ 6493.332513]  
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug  9 11:24:47 vinco kernel: [ 6493.332515] RIP: 0033:0x7f619c81a1ae
Aug  9 11:24:47 vinco kernel: [ 6493.332517] Code: 25 00 00 41 00 3d 00 00 41 
00 74 48 48 8d 05 59 65 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe 
bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 
33 0c 25
Aug  9 11:24:47 vinco kernel: [ 6493.332518] RSP: 002b:7ffdd911d5b0 EFLAGS: 
0246 ORIG_RAX: 0101
Aug  9 11:24:47 vinco kernel: [ 6493.332520] RAX: ffda RBX: 
561f01e77870 RCX: 7f619c81a1ae
Aug  9 11:24:47 vinco kernel: [ 6493.332521] RDX:  RSI: 
7ffdd911e960 RDI: ff9c
Aug  9 11:24:47 vinco kernel: [ 6493.332522] RBP: 0008 R08: 
0008 R09: 0001
Aug  9 11:24:47 vinco kernel: [ 6493.332523] R10:  R11: 
0246 R12: 7f619cc2e805
Aug  9 11:24:47 vinco kernel: [ 6493.332524] R13: 7f619cc2e805 R14: 
0001 R15: 561f01e82130
Aug  9 11:24:47 vinco kernel: [ 6493.332526] Modules linked in: msr rfcomm 
xt_recent ipt_REJECT nf_reject_ipv4 xt_multiport xt_conntrack xt_hashlimit 
xt_addrtype xt_mark nft_chain_nat xt_comment xt_CT xt_owner xt_tcpudp 
nft_compat nft_counter xt_NFLOG nf_log_ipv4 nf_log_common xt_LOG nf_nat_tftp 
nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc 
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat 
nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp 
nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack pci_stub 
vboxpci(OE) nf_defrag_ipv6 nf_defrag_ipv4 vboxnetadp(OE) vboxnetflt(OE) 
nf_tables xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp vboxdrv(OE) 
l2tp_ppp esp4 l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel ah4 pppox 
ppp_generic af_key slhc
xfrm_algo 

Bug#934026: python-django: CVE-2019-14232 CVE-2019-14233 CVE-2019-14234 CVE-2019-14235

[Chris Lamb]

Hi Salvatore,

> Although I'm late for the game ;-). You can use both
> 1:1.11.23-1~deb10u1 or 1:1.11.23-0+deb10u1. It is a matter of what you
> want the oxpress.
> 
> 1:1.11.23-1~deb10u1 ... is mainly are rebuild of 1:1.11.23-1 with
> maybe some additional changes. Examples for this one are e.g. the
> opnejdk packages.
> 
> 1:1.11.23-0+deb10u1 means ... I import 1:1.11.23 on top of the
> existing packaging but released for a lower suite than sid. This in
> the theoretiical case there would have been a 1:1.11.23-1 in the upper
> suite it is 1:1.11.23-0+deb10u1 < 1:1.11.23-1. If you want examples
> for this one for instance ghostscript, mariadb, ...

Thank you for the explicit explanation. I had intuited and inferred
this from the previous conversation so I went with 1:1.11.23-1~deb10u1
for my most-recent [rebuild] version of the debdiff.

(… although it's not a "re"-build of anything; 1.11.23 won't be in any
other suite… :p)


Regards,

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

Bug#934290: nvidia-kernel-dkms: Reinstallation fails with "E: Internal Error, No file name for nvidia-kernel-dkms:amd64"

[Vincas Dargis]

Package: nvidia-kernel-dkms
Version: 418.74-1
Severity: normal

Dear Maintainer,

After getting Linux 5.2, I've noticed that `optirun` stopped working:

```
rugp. 09 10:49:57 vinco bumblebeed[823]: modprobe: FATAL: Module nvidia-current 
not found in directory /lib/modules/5.2.0-2-amd64
rugp. 09 10:49:57 vinco bumblebeed[823]: libkmod: ERROR 
../libkmod/libkmod-module.c:979 command_do: Error running install command for 
nvidia
rugp. 09 10:49:57 vinco bumblebeed[823]: [ 4402.691834] [ERROR]Could not load 
GPU driver
```

So (naively?) I've tried to reinstall dkms package, but it failes:

```
sudo apt install --reinstall nvidia-kernel-dkms
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  irqbalance linux-headers-4.19.0-4-amd64 linux-headers-4.19.0-4-common
  linux-image-4.19.0-4-amd64
  Use 'sudo apt autoremove' to remove them.
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
  upgraded.
  1 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  E: Internal Error, No file name for nvidia-kernel-dkms:amd64
```

-- Package-specific info:
uname -a:
Linux vinco 5.2.0-2-amd64 #1 SMP Debian 5.2.7-1 (2019-08-07) x86_64 GNU/Linux

/proc/version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-19)) #1 SMP Debian 5.2.7-1 (2019-08-07)

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor Integrated 
Graphics Controller [1043:177d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 860M] 
[10de:1392] (rev a2)
Subsystem: ASUSTeK Computer Inc. GM107M [GeForce GTX 860M] [1043:177d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Aug  9 09:36 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Aug  9 09:36 /dev/dri/renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Aug  9 09:36 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug  9 09:36 pci-:00:02.0-render -> ../renderD128
video:x:44:vincas

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root25 Apr 16 22:15 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root49 Mar 16 19:30 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root51 Apr 16 22:15 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root48 Mar 16 19:30 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Mar 16 19:30 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root48 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root55 Mar 16 19:30 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root55 Mar 16 19:30 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root55 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root55 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root57 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 

Bug#932470: O: adminer -- web-based database administration tool

[Chris Lamb]

Hi Alexandre,

> > Uploaded; thanks. :)
[…]>
> Should I update myself the VCS repository? Or should we move it out of
> your personnal area on salsa? Perhaps in the Debian group?

Good idea. Can you create a repo in the Debian group? If so, please
just go ahead and do that and push the entire history (etc.) there and
then let me know it is safe to remove mine.

> Regarding future revisions, I'll keep pinging you for sponsorship via
> mentors.debian.net if that's ok.

Perfect. After a while I'm sure we can visit the question of DM upload
rights too... :)


Regards,

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

Bug#934289: evince-common: Make evince compatible with mailcap.order

[Judicael Courant]

Package: evince-common
Version: 3.30.2-3
Severity: normal

Dear Maintainer,

I would like 'see foo.pdf' to open evince (for all users).

I guess mailcap.order(5) is the right place to give evince priority over other
pdf readers. Unfortunately that does not work: I added the line

evince:application/pdf

to /etc/mailcap.order and ran update-mime (as root) and got the following
warning:

Warning: package evince listed in /etc/mailcap.order does not have mailcap 
entries.

(and see foo.pdf still opens another application).

Could you please add a file /usr/lib/mime/packages/evince to package
evince-common with the (current) output of 'grep evince /etc/mailcap' and run
update-mime in evince.postinst (or evince-common.postinst)?

Adding such a file manually solved the issue for me and was the solution
suggested to a similar question on askubuntu:

https://askubuntu.com/questions/1118437/promote-evince-in-etc-mailcap-order

Yours,

J. Courant.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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

-- no debconf information

Bug#934288: nvidia-detct: Failed to identify your Debian suite

[Vincas Dargis]

Package: nvidia-detect
Version: 430.34-1
Severity: normal

Dear Maintainer,

Running `nvidia-detect` on Sid produces this output:

```
$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX
860M] [10de:1392] (rev a2)

Checking card:  NVIDIA Corporation GM107M [GeForce GTX 860M] (rev a2)
Uh oh. Failed to identify your Debian suite.
```

This does not seem very.. usefull :) . If Sid is not supported, it could
state that explicitly.

-- Package-specific info:
uname -a:
Linux vinco 5.2.0-2-amd64 #1 SMP Debian 5.2.7-1 (2019-08-07) x86_64 GNU/Linux

/proc/version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-19)) #1 SMP Debian 5.2.7-1 (2019-08-07)

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor Integrated 
Graphics Controller [1043:177d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 860M] 
[10de:1392] (rev a2)
Subsystem: ASUSTeK Computer Inc. GM107M [GeForce GTX 860M] [1043:177d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Aug  9 09:36 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Aug  9 09:36 /dev/dri/renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Aug  9 09:36 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug  9 09:36 pci-:00:02.0-render -> ../renderD128
video:x:44:vincas

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root25 Apr 16 22:15 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root49 Mar 16 19:30 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root51 Apr 16 22:15 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root48 Mar 16 19:30 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Mar 16 19:30 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root48 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Apr 16 22:15 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root55 Mar 16 19:30 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root55 Mar 16 19:30 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root55 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root55 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root57 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root57 Apr 16 22:15 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root52 Mar 16 19:30 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root52 Mar 16 19:30 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root52 Apr 16 22:15 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root52 Apr 16 

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

[Beniamino Galvani]

On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > Bringing Vincent into the loop here.
> > 
> > Vincent, can you gather the information Beniamino is asking for?
> > 
> > Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > > Would it be possible to capture a dump of DHCP packets for a success
> > > and for a failure?
> 
> Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1)
> and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always
> in the same order.
> 
> With the internal DHCP client, this seems to be a success only if an
> ACK packet comes first. There is no such issue with the external one.
> 
> Do you need more information?

Could you capture DHCP packets with:

  tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68

when using dhclient and the failing internal client, and attach the
files? Or, if you prefer, attach the decoded text output:

  tcpdump -vvenni enp0s25 udp port 67 or port 68

Thanks,
Beniamino


signature.asc
Description: PGP signature

Bug#672361: bootlogd: escape sequences should be filtered out

[Vincent Lefevre]

On 2019-08-08 19:24:23 -0300, Jesse Smith wrote:
> I'm not sure we want to do that. Perhaps the ideal would be a small
> degree of filtering to remove the positional control characters (like
> '\r') while leaving the rest in to allow for colour to be displayed?

I think so. Filter \r out, which is proved to be wrong (a date
is added at the beginning of the line). Concerning the escape
sequences, either leave them as they are (just like for
/var/log/boot.log under systemd) or remove them entirely with
ansi2txt from the colorized-logs package.

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

Bug#934287: python3-winrm: Please consider providing optional Kerberos and CredSSP feature

[Ryo IGARASHI]

Package: python3-winrm
Version: 0.3.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

pywinrm can optionally use Kerberos or CredSSP authentication,
but the package does not provide a way to use them.

with pip, you can use Kerberos authentication using
$ pip install pywinrm[kerberos]

and CredSSP authentication using
$ pip install pywinrm[credssp]

Best regards,
- -- 
Ryo IGARASHI, Ph.D.
rigar...@gmail.com

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

Kernel: Linux 4.4.0-18362-Microsoft
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-winrm depends on:
ii  python33.7.3-1
ii  python3-requests   2.21.0-1
ii  python3-requests-ntlm  1.1.0-1
ii  python3-six1.12.0-1
ii  python3-xmltodict  0.11.0-2

Versions of packages python3-winrm recommends:
ii  python3-requests-kerberos  0.11.0-2

python3-winrm suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYKADEWIQSQVQWnJ6dEuIxNmESAtgFFC/hXNwUCXU0iihMccmlnYXJhc2hA
Z21haWwuY29tAAoJEIC2AUUL+Fc3PpUBAMPWmdR54tCmXxurSTH7t0Y2ReguYNZk
ETxG2HQhSSoFAPjlh2DCpn2xrVuElveF+b6/hWh0WEIOoxUnUU2NhF0E
=D80B
-END PGP SIGNATURE-

Bug#934286: (no subject)

[Matthew Gabeler-Lee]

Subject: linux-image-5.2.0-2-amd64: More led trigger modules
Package: src:linux
Version: 5.2.7-1
Severity: wishlist

It would be nice if some more LEDS options were enabled in Debian's
configuration, e.g.:

# CONFIG_LEDS_TRIGGER_ACTIVITY is not set
# CONFIG_LEDS_TRIGGER_NETDEV is not set
# CONFIG_LEDS_TRIGGER_PATTERN is not set

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'oldoldstable'), 
(500, 'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.1.0-trunk-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.2.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-5.2.0-2-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.2.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.02+dfsg1-20
pn  linux-doc-5.2   

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

-- no debconf information

Bug#932470: O: adminer -- web-based database administration tool

[Alexandre Rossi]

Hi,

> > > https://mentors.debian.net/package/adminer
> […]
> > Package updated to latest policy (nothing to do). Sorry for this.
> 
> Uploaded; thanks. :)

Thanks a lot.

Should I update myself the VCS repository? Or should we move it out of
your personnal area on salsa? Perhaps in the Debian group?

Regarding future revisions, I'll keep pinging you for sponsorship via
mentors.debian.org if that's ok. Feel free to get back to me if you'd
like a different workflow.

Cheers,

Alex

Bug#805711: Info received (light-locker: no login possible after suspend)

[Lin Zhihang]

Yes. I can still reproduce the problem, too.

By the way, I can type my password directly and press enter to unlock 
the session while the screen is black.


On Tue, 4 Jun 2019 03:12:57 +0200 (CEST) Matthew Crews 
 wrote:

 > This issue is still present in Buster. The workaround (switch to VT8
 > then back to VT7) also still works in Buster.
 >

Bug#926924: Bug still applies to 3.1+dfsg-8~deb10u1

[Michael Kesper]

Dear Michael,

On 08.08.19 16:55, Michael Tokarev wrote:
> Control: severity -1 minor
> Control: tag -1 + wontfix
> 
> 30.07.2019 13:19, Michael Kesper wrote:
>> $ kvm -drive if=none,cache=none,media=cdrom,id=drive_cd,readonly=on
>> qemu-system-x86_64: -drive 
>> if=none,cache=none,media=cdrom,id=drive_cd,readonly=on: Must specify either 
>> driver or file
> 
> It makes little sense to specify cache mode for a read-only CD-rom device.
> In order to trigger this using virt-manager, one has to explicitly specify
> cache mode (by default virt-manager does not specify one).

It is an issue triggered by cloudstack via libvirt.

> So I'm lowering this bug severity to minor.
> 
> Note that upstream did not "fix" this "issue" at all even for 4.1 version
> (4.1 emits the same error message), for upstream it is not an issue per
> se.
> 
> (And note that the hack applied by redhat is not "upstream change").

So, this needs to be resolved on the cloudstack / libvirt side, I guess.

Thanks for your attention!
Michael



signature.asc
Description: OpenPGP digital signature