Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

[Matthias Brennwald]

Package: general
Severity: normal

I have an external screen connected to my notebook computer (Dell XPS 13).
After waking the notebook from sleep mode, the windows that have been opened
before activating sleep mode are blurry. Newly opened windows are not affected.
The issue happens with windows from all programs, not just a specific program.
Moving or resizing the windows does not change the blurry appearance. I have
reproduced the issue on a different notebook computer (HP hardware) with a
different external screen.

(Debian Testing with Gnome 3.34)



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

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

Bug#947949: openssl: CVE-2019-1551

[Salvatore Bonaccorso]

Hi Sebastian,

On Thu, Jan 02, 2020 at 06:10:06PM +, Sebastian Andrzej Siewior wrote:
> On January 2, 2020 3:50:46 PM UTC, Salvatore Bonaccorso  
> wrote:
> >If you fix the vulnerability please also make sure to include the
> >CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> There is no upstream release which includes this fix (except for the
> 1.0.2 series). Should we quickly address this or is it okay to wait
> for the next upstream release? I  could do this if this is preferred
> given that this is fixed in Stretch.

I think it's perfectly fine to wait for this until there is the next
upstream release of openssl. I just filled the bug for have it
tracked, but I think it's rather minor, and has not an elevated
urgency to be now adressed via a DSA and cherry-pick the fix only.

Regards,
Salvatore

Bug#947949: openssl: CVE-2019-1551

[Sebastian Andrzej Siewior]

On January 2, 2020 3:50:46 PM UTC, Salvatore Bonaccorso  
wrote:
>If you fix the vulnerability please also make sure to include the
>CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

There is no upstream release which includes this fix (except for the 1.0.2 
series). Should we quickly address this or is it okay to wait for the next 
upstream release? I  could do this if this is preferred given that this is 
fixed in Stretch.

>Regards,
>Salvatore


-- 
Sebastian

Bug#873019: Located the bug in shellinabox/service.c

[Leonardo Marino-Ramirez]

Dear maintainer,

Please remove these outdated ssh options from service.c:

-oRhostsRSAAuthentication=no
-oRSAAuthentication=no

Thanks, Leonardo


On Wed, 23 Aug 2017 16:56:00 -0400 =?UTF-8?Q?Leonardo_Mari=C3=B1o-Ram=C3=ADrez?=
  wrote:
> The bug is located in shellinabox/service.c
>
> Removing the flags:
>
> -oRhostsRSAAuthentication=no
> -oRhostsRSAAuthentication=no
>
> and recompiling solves this issue.
>
>

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

On Thu, 2 Jan 2020 12:41:14 -0600
"Karl O. Pinc"  wrote:

>  (I'd also move the paragraph
> starting "Direct upgrades from Debian releases older than 10 (buster)
> are not supported." to the top.)

Oops.  I take that back.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

On Thu, 2 Jan 2020 17:28:07 +
Justin B Rye  wrote:

> Karl O. Pinc wrote:
> >>> +files; old
> >>> versions
> >>> +of configuration files, versions supplied by the package
> >>> +maintainers, etc.  Removing leftover files from previous
> >>> upgrades,
> >>> +before performing another upgrade, can avoid confusion.

>  Given that you're
> proposing this text as pre-upgrade advice, but that it's also true for
> any other time, we might as well just say
> 
>   Removing files left over from previous upgrades
> can avoid confusion.

Agreed.  Shorter is better.

> >> It might fit best in 4.7. "Preparing for the next release".  
> > 
> > I like to leave the leftover files laying around for a while after
> > upgrade just in case they shed light on some problem that I don't
> > notice until later.  So I clean them up (or not, usually) before
> > doing the next upgrade because I forget they exist.  
> 
> It seems to me that users ought to do this within a few days of a
> dist-upgrade while they remember the circumstances, not months or
> years later.  But it's quite possible that it only seems that way to
> me because of the habits I've got into thanks to my nagging cronjobs
> (and associated system configuration backups).

Users should certainly deal with making sure their configuration files
are working immediately after an upgrade.  I'm sure I'm catering to
my retentive streak in keeping them around for some time.  The
good part about forgetting to deal with them is that when you come
back years later to clean up you can be pretty confident that you
don't need them any more and can delete them without having to
think.  :-)  Especially because by that point in the upgrade
you should already have a backup.

---
On an unrelated note (FYI):  The bulk of what's between
the title of section 4.2. Checking APT configuration status
and 4.2.1 involves cleanup around ensuring that the system
is "pure Debian stable", as does a lot of the whole section.
I think the section title could be improved but a) I don't
know where to discuss this, and b) I don't have a suggestion
ready.  ("Remove complicating factors" is too mysterious, yes?)

A better title might inspire breaking up  what's between 4.2 and
4.2.1 into separate sections.  (I'd also move the paragraph
starting "Direct upgrades from Debian releases older than 10 (buster)
are not supported." to the top.)

Apologies for being offtopic.
---

> > That makes the complete list: *.dpkg-new *.dpkg-old *.dpkg-save,
> > *.dpkg-bak, *.pam-old, *.ucf-old, *.ucf-dist, *.merge-error  
> 
> The ucf manpage also says that .ucf-new can occur as a symptom of an
> interrupted run (like .dpkg-new); and in theory there's .dpkg-inst, so
> maybe the search should use globs like "*.dpkg-*" and "*.ucf-*"
> instead of trying to itemise them all.

Agreed.  Especially because we're not putting a command in that
just deletes them.  The user has to decide what to do.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947954: ITP: vmatch -- large scale sequence analysis software

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: vmatch
  Version : 2.3.0
  Upstream Author : Stefan Kurtz
* URL : http://vmatch.de
* License : ISC
  Programming Lang: C
  Description : large scale sequence analysis software

Vmatch is an index-based, versatile software tool for efficiently solving
large scale sequence matching tasks. Vmatch subsumes the software tool
REPuter, but is much more general, with a very flexible user interface,
and improved space and time requirements.

It has recently been freed after being closed-source for a long time.
I am packaging this under the Debian Med umbrella, partly as a
dependency of the GenomeThreader gene prediction tool.

Bug#943600: [Pkg-pascal-devel] Bug#943600: Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation

[Graham Inggs]

As of now, lazarus 2.0.6+dfsg-3 has failed its autopkgtests 2 out of
11 times on amd64 [1], and 3 out of 11 times on arm64 [2].

I am hesitant to re-open this bug as RC, as it potentially removes all
packages built with lazarus for no good reason.


[1] https://ci.debian.net/packages/l/lazarus/testing/amd64/
[2] https://ci.debian.net/packages/l/lazarus/testing/arm64/

Bug#946327: khotkeys FTBFS

[John Scott]

Control: forwarded -1 
https://salsa.debian.org/qt-kde-team/kde/khotkeys/merge_requests/2
Control: tags -1 patch

This is fixed in KHotKeys 5.15.1. Alternatively, I've submitted a merge request
to enable a potential new upload of 5.14.5 with the patch.


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

Bug#947953: python3-x2go: Makes pyhoca-gui fail to start.

[Yannick Roehlly]

Package: python3-x2go
Version: 0.6.1.3-1
Severity: normal
Tags: upstream

Hi,

pyhoca-gui fails to start with this error:

%<---
Traceback (most recent call last):
  File "/usr/bin/pyhoca-gui", line 50, in 
app.main(args=args, logger=logger, liblogger=liblogger)
  File "/usr/lib/python3/dist-packages/pyhoca/wxgui/launcher.py", line 404, in 
main
thisPyHocaGUI = PyHocaGUI(args, logger, liblogger, appname=self.PROG_NAME, 
version=self.VERSION)
  File "/usr/lib/python3/dist-packages/pyhoca/wxgui/frontend.py", line 239, in 
__init__
x2go.X2GoClient.__init__(self, **_x2goclient_kwargs)
  File "/usr/lib/python3/dist-packages/x2go/client.py", line 309, in __init__
self.pulseaudio_installdir = os.path.normpath(pulseaudio_installdir)
  File "/usr/lib/python3.7/posixpath.py", line 340, in normpath
path = os.fspath(path)
TypeError: expected str, bytes or os.PathLike object, not tuple
%<---

The error lies at line 308 in /usr/lib/python3/dist-packages/x2go/client.py:

%<---
if pulseaudio_installdir == None:
pulseaudio_installdir = os.path.join(os.getcwd(), 'pulseaudio'),
self.pulseaudio_installdir = os.path.normpath(pulseaudio_installdir)
%<---

Removing the trailing comma makes the package work as intended.

Happy new year.

Yannick

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

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

Versions of packages python3-x2go depends on:
ii  nxproxy 2:3.5.99.22-1
ii  python3 3.7.5-3
ii  python3-future  0.16.0-1
ii  python3-gevent  1.4.0-1+b1
ii  python3-paramiko2.6.0-1
ii  python3-requests2.22.0-2
ii  python3-simplejson  3.16.0-2+b1
ii  python3-xlib0.23-2

Versions of packages python3-x2go recommends:
ii  cups-bsd [lpr]2.3.1-1
ii  pulseaudio13.0-3
ii  sshfs 3.6.0+repack-1
pn  x2gokdriveclient  

Versions of packages python3-x2go suggests:
pn  mteleplayer-clientside  
pn  telekinesis-client  

-- no debconf information

Bug#947952: dpkg-repack compatibility: (optionally?) remove deleted files from /var/lib/dpkg/pkgname.list

[Andras Korn]

Package: localepurge
Version: 0.7.3.8
Severity: wishlist

Hi,

dpkg-repack fails when localepurge is in use (see #947951).

If dpkg-repack doesn't get fixed, a possible workaround would be to have
localepurge remove entries from /var/lib/dpkg/pkgname.list as it deletes the
files.

I'm not sure how that would work with --path-exclude.

Thanks!

András

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

Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  locales2.29-6
ii  perl   5.30.0-9
ii  procps 2:3.3.12-3+devuan2.1
ii  ucf3.0038+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit  
ii  debfoster  2.7-2.1+b1
ii  deborphan  1.7.32

-- debconf information excluded

-- 
   Always address your elders with respect; they could leave you a fortune.

Bug#947951: Fails if packages pruned by localepurge

[Andras Korn]

Package: dpkg-repack
Version: 1.46
Severity: normal

Hi,

the localepurge package can be used to automatically remove unneeded locale
files (and thereby conserve disk space as well as inodes).

dpkg-repack used to just print warnings for non-existent files, but
currently it fails on such packages and only prints a vague warning, e.g.:

dpkg-repack: warning: problems found processing kde-style-breeze, the package 
may be broken

In fact, no actual .deb is generated at all; the dpkg build directory is
missing DEBIAN/control.

Please do one or more of the following:

1. turn this error into a warning again (in line 248, replace 'error("cannot 
find file '$fn'")' with 'warning("cannot find file '$fn'")').

2. make sure the actual error message is printed, in addition to the vague 
warning; also, make it clear that no .deb was generated and that dpkg-repack 
exits unsuccessfully.

3. make this behaviour depend on a command line option; e.g. 
--ignore-missing-files, or --ignore-missing-locale, or --fail-on-missing-files 
or whatever.

I would argue that if files are missing, the generated .deb should just not
contain them. After all, dpkg-repack's description says "dpkg-repack creates
a .deb file out of a package that has already been installed. If any changes
have been made to the package while it was unpacked (i.e. files in /etc were
modified), the new package will inherit the changes.

This utility can make it easy to copy packages from one computer to another,
or to recreate packages that are installed on your system, but no longer
available elsewhere, or to store the current state of a package before you
upgrade it."

Removing files represents "changes made to the package" that dpkg-repack
should preserve.

Whether the .list file should include the missing files or not is an
interesting question, but irrelevant for my use case (backup before
upgrade); I think it would be better to include them if possible, because
then if you install the generated .deb, it's still obvious that those files
are missing from it.

Best regards,

András

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

Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages dpkg-repack depends on:
ii  libdpkg-perl  1.19.7
ii  perl  5.30.0-9

dpkg-repack recommends no packages.

Versions of packages dpkg-repack suggests:
ii  fakeroot  1.24-1

-- no debconf information

-- 
 The important thing is that we are moving forward - never mind the direction.

Bug#947950: autoconf BD on texlive-generic-recommended which isn't build anymore and isn't in bullseye

[Paul Gevers]

Source: autoconf
Version: 2.69-11
Severity: serious
Tags: ftbfs sid bullseye

Somewhere around August 2019, the texlive-base package has stopped
building the transitional package texlive-generic-recommended. This is
an issue for your package as it build-depends on it. Please update the
building of your package to use texlive-plain-generic instead.

Unfortunately the migration software doesn't detected this kind of
situation yet, so your package also FTBFS in bullseye since 2019-08-31.

I intent to prepare an NMU and upload it to DELAYED/15 or so, please let
me know if you will handle this yourself.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#947038: buster-pu: package libburn/1.5.0-1

[Steve McIntyre]

On Mon, Dec 30, 2019 at 05:32:13PM +, Adam Barratt wrote:
>Control: tags -1 + confirmed
>
>On Thu, 2019-12-19 at 19:35 +, Steve McIntyre wrote:
>> We'd like to add a stable update for libburn to fix an important bug
>> in cdrskin. 1.5.0-1 (currently in Buster) currently can't burn
>> multi-track audio CDs correctly and instead just spoils/wastes
>> media. This was reported by Thomas upstream and I've verified this
>> behaviour myself. See #946679, where he's given much more detail
>> about the problem.
>
>Please go ahead.

Thanks, just uploaded. One trivial tweak in the changelog - I added a
Closes: for #946679.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Bug#921502: Bug #921502 in latexdiff marked as pending

[Paul Gevers]

Control: tags -1 serious
Control: retitle -1 latexdiff BD/Recommends texlive-generic-recommended

Hi Peter, all,

On Thu, 07 Feb 2019 13:55:49 + Peter Pentchev <> wrote:
> Bug #921502 in latexdiff reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/perl-team/modules/packages/latexdiff/commit/3cd40f7549c9093079f04348ba9aedf226872bf6
> 
> 
> Recommend texlive-plain-generic instead of texlive-generic-recommended.
> 
> Closes:   #921502
> Reported by:  Julian Gilbey 
> 

Can you please upload this fix? The Build-Depends change is actually
fixing an RC issue that latexdiff can't be rebuild in testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

[thuejk]

A RX580? I have an old Radeon HD 7750; I had expected you to have a similar
graphics card to me, but apparently not.

I think it would be useful if you added the information about your GPU and
driver to the upstream bug report at
https://bugs.chromium.org/p/chromium/issues/detail?id=1036725

Regards, Thue

Den tor. 2. jan. 2020 kl. 18.16 skrev Christopher Obbard :

> On Thu, 2 Jan 2020 at 16:30,  wrote:
> >
> > Yes, it is the same.
> >
> > Since this seems likely to only occur on some graphics hardware: What is
> your graphics card?
>
> I run sid with a daily full-upgrade
> funnily this same thing used to happen about 6 months ago on my
> HD5850, so I got a RX580 which cured it until some time this week.
> I am using the driver provided by xserver-xorg-video-amdgpu
>
> Thanks
> Chris
>
> >
> > Regards, Thue
> >
> > Den tor. 2. jan. 2020 kl. 15.28 skrev Christopher Obbard <
> obba...@gmail.com>:
> >>
> >> Hi,
> >>
> >> For me some videos (incl. your link) now have their colours changed to
> >> a funny yellow/red tinge.
> >> Is this similar to you?
> >>
> >> Cheers!
> >>
> >> On Sun, 22 Dec 2019 22:59:03 +0100 Thue  wrote:
> >> > Package: chromium
> >> > Version: 79.0.3945.79-1
> >> > Severity: normal
> >> >
> >> > Dear Maintainer,
> >> > The hardware video support seems to have broken in a recent update.
> E.g. https://www.twitch.tv/videos/290265920 .
> >> >
> >> > Turning off "Use hardware acceleration when available" in the
> settings fixes it.
> >> >
> >> > Upstream bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1036725
> >> >
> >> > Regards, Thue
> >> >
> >> >
> >> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >> >
> >> >* What led up to the situation?
> >> >* What exactly did you do (or not do) that was effective (or
> >> >  ineffective)?
> >> >* What was the outcome of this action?
> >> >* What outcome did you expect instead?
> >> >
> >> > *** End of the template - remove these template lines ***
> >> >
> >> >
> >> > -- System Information:
> >> > Debian Release: bullseye/sid
> >> >   APT prefers unstable
> >> >   APT policy: (500, 'unstable')
> >> > Architecture: amd64 (x86_64)
> >> > Foreign Architectures: i386
> >> >
> >> > Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
> >> > Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> >> > Shell: /bin/sh linked to /bin/dash
> >> > Init: systemd (via /run/systemd/system)
> >> > LSM: AppArmor: enabled
> >> >
> >> > Versions of packages chromium depends on:
> >> > ii  chromium-common  79.0.3945.79-1
> >> > ii  libasound2   1.1.9-1
> >> > ii  libatk-bridge2.0-0   2.34.1-2
> >> > ii  libatk1.0-0  2.34.1-1
> >> > ii  libatomic1   9.2.1-21
> >> > ii  libatspi2.0-02.34.0-3
> >> > ii  libavcodec58 7:4.2.1-2
> >> > ii  libavformat587:4.2.1-2
> >> > ii  libavutil56  7:4.2.1-2
> >> > ii  libc62.29-6
> >> > ii  libcairo-gobject21.16.0-4
> >> > ii  libcairo21.16.0-4
> >> > ii  libcups2 2.3.0-7
> >> > ii  libdbus-1-3  1.12.16-2
> >> > ii  libdrm2  2.4.100-4
> >> > ii  libevent-2.1-7   2.1.11-stable-1
> >> > ii  libexpat12.2.9-1
> >> > ii  libflac8 1.3.3-1
> >> > ii  libfontconfig1   2.13.1-2+b1
> >> > ii  libfreetype6 2.10.1-2
> >> > ii  libgcc1  1:9.2.1-21
>

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Justin B Rye]

Karl O. Pinc wrote:
>>> +files; old versions
>>> +of configuration files, versions supplied by the package
>>> +maintainers, etc.  Removing leftover files from previous upgrades,
>>> +before performing another upgrade, can avoid confusion.  
>> 
>> The commas in this sentence seem subtly wrong.
> 
> I think the commas are right, as a parenthetical-ish without
> parenthesis, but the sentence structure is strange.  But
> I want the forgettable stuff in the middle and the important
> stuff on the ends of the sentence where the reader pays attention.

The trouble is, it isn't purely parenthetical; it's talking about
removing the leftover files under particular circumstances, so it's
rather like a defining relative clause (which doesn't take commas).
The competing misinterpretation is that you can avoid confusion by
removing these files and subsequently performing another upgrade
(that you otherwise wouldn't have performed).  Given that you're
proposing this text as pre-upgrade advice, but that it's also true for
any other time, we might as well just say

  Removing files left over from previous upgrades
can avoid confusion.

>> It might fit best in 4.7. "Preparing for the next release".
> 
> I like to leave the leftover files laying around for a while after
> upgrade just in case they shed light on some problem that I don't
> notice until later.  So I clean them up (or not, usually) before
> doing the next upgrade because I forget they exist.

It seems to me that users ought to do this within a few days of a
dist-upgrade while they remember the circumstances, not months or
years later.  But it's quite possible that it only seems that way to
me because of the habits I've got into thanks to my nagging cronjobs
(and associated system configuration backups).
 
[...]
> That makes the complete list: *.dpkg-new *.dpkg-old *.dpkg-save,
> *.dpkg-bak, *.pam-old, *.ucf-old, *.ucf-dist, *.merge-error

The ucf manpage also says that .ucf-new can occur as a symptom of an
interrupted run (like .dpkg-new); and in theory there's .dpkg-inst, so
maybe the search should use globs like "*.dpkg-*" and "*.ucf-*"
instead of trying to itemise them all.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

[Christopher Obbard]

On Thu, 2 Jan 2020 at 16:30,  wrote:
>
> Yes, it is the same.
>
> Since this seems likely to only occur on some graphics hardware: What is your 
> graphics card?

I run sid with a daily full-upgrade
funnily this same thing used to happen about 6 months ago on my
HD5850, so I got a RX580 which cured it until some time this week.
I am using the driver provided by xserver-xorg-video-amdgpu

Thanks
Chris

>
> Regards, Thue
>
> Den tor. 2. jan. 2020 kl. 15.28 skrev Christopher Obbard :
>>
>> Hi,
>>
>> For me some videos (incl. your link) now have their colours changed to
>> a funny yellow/red tinge.
>> Is this similar to you?
>>
>> Cheers!
>>
>> On Sun, 22 Dec 2019 22:59:03 +0100 Thue  wrote:
>> > Package: chromium
>> > Version: 79.0.3945.79-1
>> > Severity: normal
>> >
>> > Dear Maintainer,
>> > The hardware video support seems to have broken in a recent update. E.g. 
>> > https://www.twitch.tv/videos/290265920 .
>> >
>> > Turning off "Use hardware acceleration when available" in the settings 
>> > fixes it.
>> >
>> > Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1036725
>> >
>> > Regards, Thue
>> >
>> >
>> > *** Reporter, please consider answering these questions, where appropriate 
>> > ***
>> >
>> >* What led up to the situation?
>> >* What exactly did you do (or not do) that was effective (or
>> >  ineffective)?
>> >* What was the outcome of this action?
>> >* What outcome did you expect instead?
>> >
>> > *** End of the template - remove these template lines ***
>> >
>> >
>> > -- System Information:
>> > Debian Release: bullseye/sid
>> >   APT prefers unstable
>> >   APT policy: (500, 'unstable')
>> > Architecture: amd64 (x86_64)
>> > Foreign Architectures: i386
>> >
>> > Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
>> > Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE= 
>> > (charmap=UTF-8)
>> > Shell: /bin/sh linked to /bin/dash
>> > Init: systemd (via /run/systemd/system)
>> > LSM: AppArmor: enabled
>> >
>> > Versions of packages chromium depends on:
>> > ii  chromium-common  79.0.3945.79-1
>> > ii  libasound2   1.1.9-1
>> > ii  libatk-bridge2.0-0   2.34.1-2
>> > ii  libatk1.0-0  2.34.1-1
>> > ii  libatomic1   9.2.1-21
>> > ii  libatspi2.0-02.34.0-3
>> > ii  libavcodec58 7:4.2.1-2
>> > ii  libavformat587:4.2.1-2
>> > ii  libavutil56  7:4.2.1-2
>> > ii  libc62.29-6
>> > ii  libcairo-gobject21.16.0-4
>> > ii  libcairo21.16.0-4
>> > ii  libcups2 2.3.0-7
>> > ii  libdbus-1-3  1.12.16-2
>> > ii  libdrm2  2.4.100-4
>> > ii  libevent-2.1-7   2.1.11-stable-1
>> > ii  libexpat12.2.9-1
>> > ii  libflac8 1.3.3-1
>> > ii  libfontconfig1   2.13.1-2+b1
>> > ii  libfreetype6 2.10.1-2
>> > ii  libgcc1  1:9.2.1-21

Bug#947943: libsoup2.4: Please make the libnss-myhostname build-dep linux-any

[Samuel Thibault]

Simon McVittie, le jeu. 02 janv. 2020 17:00:17 +, a ecrit:
> On Thu, 02 Jan 2020 at 15:41:45 +0100, Samuel Thibault wrote:
> > libnss-myhostname comes from the systemd package, which is only built
> > on linux-any, so could you make the libnss-myhostname dependency
> > [linux-any] like the attached patch does?
> 
> Do the tests still pass on non-Linux without it?

I have to admit I haven't tried.

> Alternatively, the developers of non-Linux-kernel ports of
> Debian could fork and reintroduce the standalone package
>  which was
> later subsumed into systemd - it was designed for GNU/Linux, but
> 
> suggests that it actually worked (or at least compiled) on any glibc-based
> system. (This would likely require becoming its new upstream maintainer.)

It's very small and seems to indeed use glibc's getifaddrs support to
work on non-Linux. I guess that can be a better way indeed.

Samuel

Bug#947943: libsoup2.4: Please make the libnss-myhostname build-dep linux-any

[Simon McVittie]

On Thu, 02 Jan 2020 at 15:41:45 +0100, Samuel Thibault wrote:
> libnss-myhostname comes from the systemd package, which is only built
> on linux-any, so could you make the libnss-myhostname dependency
> [linux-any] like the attached patch does?

Do the tests still pass on non-Linux without it?

This dependency was added because:

The HSTS tests are failing because of not being able to resolve
subdomains of localhost. If the libnss-myhostname package is installed
while the tests are run, then the name resolution should work correctly.

See also https://gitlab.gnome.org/GNOME/libsoup/issues/159

So those tests will probably need to be skipped (ideally with
g_test_skip()) if names like 'some.arbitrary-name.localhost' do not
resolve to 127.x.x.x and/or ::1. The HSTS tests need to be able to
connect to a subdomain of a known domain name to be able to test some
of the desired HSTS behaviours.

Alternatively, the developers of non-Linux-kernel ports of
Debian could fork and reintroduce the standalone package
 which was
later subsumed into systemd - it was designed for GNU/Linux, but

suggests that it actually worked (or at least compiled) on any glibc-based
system. (This would likely require becoming its new upstream maintainer.)

smcv

Bug#947931: RM: ghostwriter [armel mips64el ppc64el s390x] -- RoQA; ANAIS

[Juhani Numminen]

Sebastien CHAVAUX kirjoitti 2.1.2020 klo 16.11:
> Hello,
> 
> I don't mind that you made the request. From what I understood is that the 
> dependence is not on all architectures and that therefore Ghostwriter can no 
> longer be on the architectures concerned.
> 

Correct. This removal request is only necessary because Ghostwriter no longer
supports some of the architectures where it was previously available.

> So for the Ghostwriter package, what will happen?
> 

The version listing at https://qa.debian.org/madison.php?package=ghostwriter
currently has the following information for sid:

 ghostwriter | 1.7.4-2| sid  | source, armel, mips64el, ppc64el, s390x
 ghostwriter | 1.8.0-2| sid  | source, armhf
 ghostwriter | 1.8.0-2+b1 | sid  | amd64, arm64, i386, mipsel

Once the FTP Masters remove the 1.7.4-2 binary packages, ghostwriter 1.8.0-2
and 1.8.0-2+b1 will migrate to testing (source:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#out-of-date).

Then your package maintenance will continue as usual.

> Best regards.

Bug#947867: [Pkg-javascript-devel] Bug#947867: RM: src:libjs-i18next -- ROM; Duplicate of node-i18next

[Nicolas Mora]

I agree but we should merge both packages content then, the package 
libjs-i18next provides UMD format.

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

[thuejk]

Yes, it is the same.

Since this seems likely to only occur on some graphics hardware: What is
your graphics card?

Regards, Thue

Den tor. 2. jan. 2020 kl. 15.28 skrev Christopher Obbard :

> Hi,
>
> For me some videos (incl. your link) now have their colours changed to
> a funny yellow/red tinge.
> Is this similar to you?
>
> Cheers!
>
> On Sun, 22 Dec 2019 22:59:03 +0100 Thue  wrote:
> > Package: chromium
> > Version: 79.0.3945.79-1
> > Severity: normal
> >
> > Dear Maintainer,
> > The hardware video support seems to have broken in a recent update. E.g.
> https://www.twitch.tv/videos/290265920 .
> >
> > Turning off "Use hardware acceleration when available" in the settings
> fixes it.
> >
> > Upstream bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1036725
> >
> > Regards, Thue
> >
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
> >
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages chromium depends on:
> > ii  chromium-common  79.0.3945.79-1
> > ii  libasound2   1.1.9-1
> > ii  libatk-bridge2.0-0   2.34.1-2
> > ii  libatk1.0-0  2.34.1-1
> > ii  libatomic1   9.2.1-21
> > ii  libatspi2.0-02.34.0-3
> > ii  libavcodec58 7:4.2.1-2
> > ii  libavformat587:4.2.1-2
> > ii  libavutil56  7:4.2.1-2
> > ii  libc62.29-6
> > ii  libcairo-gobject21.16.0-4
> > ii  libcairo21.16.0-4
> > ii  libcups2 2.3.0-7
> > ii  libdbus-1-3  1.12.16-2
> > ii  libdrm2  2.4.100-4
> > ii  libevent-2.1-7   2.1.11-stable-1
> > ii  libexpat12.2.9-1
> > ii  libflac8 1.3.3-1
> > ii  libfontconfig1   2.13.1-2+b1
> > ii  libfreetype6 2.10.1-2
> > ii  libgcc1  1:9.2.1-21
>

Bug#945490: gs always fails with "Permission denied"

[Barak A. Pearlmutter]

Great, thanks. I'll package that forthwith.

Cheers,

--Barak.

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Felipe Sateler]

Control: tags -1 moreinfo

On Wed, Jan 1, 2020 at 8:39 PM Joshua  wrote:

> Package: pulseaudio
> Version: 12.2-4+deb10u1
> Severity: normal
>
> After installing systemd, the following problem appeared in pulseaudio:
>

Please attach the entire client.conf (/etc/pulse and ~/.config/pulse).


>
> The first login after boot launches a non-working pulseaudio. Killing and
> restarting pulseaudio results in
> a working pulseaudio. It's not a wait for device to initialize problem. It
> doesn't matter how long I stare
> at the login screen before logging in.
>

Does `journalctl --user-unit pulseaudio.service` have anything to say?


>
> The normal debug steps are useless as the problem won't recur when
> pulseaudio is not restarted.
>

You can set the debug flags on daemon.conf to force it to verbose mode.

-- 

Saludos,
Felipe Sateler

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[John Scott]

On Thu, 2 Jan 2020 15:46:53 + Julian Gilbey  wrote:
> > I'm using Anki w/ Plasma on Bullseye, and Ctrl+Enter works as expected on
> > both X11 and Wayland. So this does seem Buster-specific.
> Thanks John, that's really helpful to know.  Are you using KDE?
Plasma is the name of KDE's desktop environment. I believe that's what the 
submitter meant. It would take a very powerful computer to run the entire KDE 
software suite at once 
And by the way, I don't think it's been said explicitly that this only affects 
KDE Plasma yet. Rahul didn't specify if he tried another desktop environment 
and I'm not running Buster to try.

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

Bug#947907: Same here

[Felicia P]

Also experiencing this same bug.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux bullseye/sid
Release:    unstable
Codename:   sid


ii  ure  6.4.0~rc1-4    amd64   LibreOffice UNO runtime environment



0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#947949: openssl: CVE-2019-1551

[Salvatore Bonaccorso]

Source: openssl
Version: 1.1.1d-2
Severity: important
Tags: security upstream fixed-upstream

Hi,

Filling for tracking the issue for src:openssl.

CVE-2019-1551[0]:
| There is an overflow bug in the x64_64 Montgomery squaring procedure
| used in exponentiation with 512-bit moduli. No EC algorithms are
| affected. Analysis suggests that attacks against 2-prime RSA1024,
| 3-prime RSA1536, and DSA1024 as a result of this defect would be very
| difficult to perform and are not believed likely. Attacks against
| DH512 are considered just feasible. However, for an attack the target
| would have to re-use the DH512 private key, which is not recommended
| anyway. Also applications directly using the low level API BN_mod_exp
| may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e-
| dev (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u-dev (Affected
| 1.0.2-1.0.2t).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-1551
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1551
[1] https://www.openssl.org/news/secadv/20191206.txt

Regards,
Salvatore

Bug#947263: python3-iniparse: missing Breaks+Replaces: python-iniparse

[Emmanuel Arias]

Hi,

I attach a patch to fix the Breaks missed.

Please consider applied it
thanks!


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com
From 64ac2053b609627c08f49cb4e0609e40c5e534ae Mon Sep 17 00:00:00 2001
From: Emmanuel Arias 
Date: Thu, 2 Jan 2020 12:45:59 -0300
Subject: [PATCH] d/control: add Breaks (<< 0.4-2.3) missed (Closes: #947263)

---
 debian/changelog | 7 +++
 debian/control   | 1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index dfdd027..80996e4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-iniparse (0.4-4) UNRELEASED; urgency=medium
+
+  * Team upload
+  * d/control: add Breaks (<< 0.4-2.3) missed (Closes: #947263)
+
+ -- Emmanuel Arias   Thu, 02 Jan 2020 12:46:59 -0300
+
 python-iniparse (0.4-3) unstable; urgency=medium
 
   * Maintain under DPMT.
diff --git a/debian/control b/debian/control
index b4d6560..1dfa28c 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Rules-Requires-Root: no
 Package: python3-iniparse
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, python3-six
+Breaks: python-iniparse (<< 0.4-2.3)
 Replaces: python-iniparse (<< 0.4-2.3)
 Description: access and modify configuration data in INI files (Python 3)
  iniparse is a INI parser for Python which is:
-- 
2.20.1

Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes

[Alberto Molina Coballes]

Hi,

ebtables 2.0.11-3 has been uploaded to unstable including a Depends on
netbase (>= 6.0). The same Depends on has been included in iptables
[1] that closes this bug, but it's not yet released.

Thanks Michael for reporting this bug and Marco for your willingness
to solve it including /etc/ethertypes in netbase.

Regards,

Alberto

[1] 
https://salsa.debian.org/pkg-netfilter-team/pkg-iptables/commit/d7ad2173f0cd7d26d2ecf0b49d3708203973faf2

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

On Wed, 1 Jan 2020 22:56:13 -0600
"Karl O. Pinc"  wrote:

> On Thu, 2 Jan 2020 01:45:16 +
> Justin B Rye  wrote:
> 
> > (Personally I have a cronjob that nags me if it sees any *.dpkg-new,
> > *.dpkg-old, *.dpkg-save, *.pam-old or *ucf-old files lying about.)  
> 
> I noticed with the Buster upgrade that there are some packages
> that want to do a "three way merge", which, when it fails,
> uses some other long suffix for the files it leaves laying
> around.  But I forget the name.

Finally found them: *.ucf-dist *.merge-error *.ucf-old

> Using locate I also notice a few *.dpkg-bak files.

That makes the complete list: *.dpkg-new *.dpkg-old *.dpkg-save,
*.dpkg-bak, *.pam-old, *.ucf-old, *.ucf-dist, *.merge-error

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947948: boinc: dpkg-buildpackage fails building packages

[Luigi Brambilla]

Source: boinc
Version: 7.14.2
Severity: important

Dear Maintainer,

   dpkg-buildpackage exits with error while building BOINC packages suite:
 the same error occurs within various version and systems:   - ubuntu 
19.10 (boinc 7.16.3)
   - debian 10.2 (boinc 7.14.2)
   - debian 10.2 (boinc 7.16.3 experimental)

 Please note: version 7.9.3 (ubuntu 18.04) can be successfully built

 These are the last lines or report boinc_7.14.2+dfsg-3_amd64.build
>> dh_install: Cannot find (any matches for) "lib/systemd/system" (tried in ., 
>> debian/tmp)

>> dh_install: boinc-client missing files: lib/systemd/system
>> dh_install: missing files, aborting
>> make[1]: *** [debian/rules:407: override_dh_install] Error 25
>> make[1]: Leaving directory '/home/luigi/src/boinc/boinc-7.14.2+dfsg'
>> make: *** [debian/rules:200: binary] Error 2
>> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
>> exit status 2     

this prevents from porting the boinc-server-maker package to the stable OS 
version.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
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


Luigi Brambilla

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[Julian Gilbey]

On Thu, Jan 02, 2020 at 10:22:48AM -0500, John Scott wrote:
> On Thu, 02 Jan 2020 19:25:39 +0530 ra...@amaram.name wrote:
> > It might be worth checking out in bullseye if the problem exists as well.
> I'm using Anki w/ Plasma on Bullseye, and Ctrl+Enter works as expected on 
> both 
> X11 and Wayland. So this does seem Buster-specific.

Thanks John, that's really helpful to know.  Are you using KDE?

Best wishes,

   Julian

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[Julian Gilbey]

On Thu, Jan 02, 2020 at 07:25:39PM +0530, ra...@amaram.name wrote:
> The anki version that comes with Debian buster also has this issue. It might 
> be
> worth checking out in bullseye if the problem exists as well. If it does and 
> we
> find some fix for it, then that could probably be backported to buster as part
> of updates.

Dear Rahul,

I am not surpised by this; as I said, my guess is that it's most
likely not an issue with anki itself but with the version of one of
the many libraries that is bundled with the official version of anki.

Best wishes,

   Julian

Bug#947946: ros-ros-comm: CVE-2019-13465

[Salvatore Bonaccorso]

Source: ros-ros-comm
Version: 1.14.3+ds1-10
Severity: important
Tags: security upstream
Forwarded: https://github.com/ros/ros_comm/issues/1752
Control: found -1 1.14.3+ds1-5

Hi,

The following vulnerability was published for ros-ros-comm.

CVE-2019-13465[0]:
| An issue was discovered in the ROS communications-related packages
| (aka ros_comm or ros-melodic-ros-comm) through 1.14.3. ROS_ASSERT_MSG
| only works when ROS_ASSERT_ENABLED is defined. This leads to a problem
| in the remove() function in clients/roscpp/src/libros/spinner.cpp.
| When ROS_ASSERT_ENABLED is not defined, the iterator loop will run out
| of the scope of the array, and cause denial of service for other
| components (that depend on the communication-related functions of this
| package).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13465
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13465
[1] https://github.com/ros/ros_comm/issues/1752
[2] https://github.com/ros/ros_comm/pull/1763

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#947947: ros-ros-comm: CVE-2019-13445

[Salvatore Bonaccorso]

Source: ros-ros-comm
Version: 1.14.3+ds1-10
Severity: important
Tags: security upstream
Forwarded: https://github.com/ros/ros_comm/issues/1738
Control: found -1  1.14.3+ds1-5

Hi,

The following vulnerability was published for ros-ros-comm.

CVE-2019-13445[0]:
| An issue was discovered in the ROS communications-related packages
| (aka ros_comm or ros-melodic-ros-comm) through 1.14.3. parseOptions()
| in tools/rosbag/src/record.cpp has an integer overflow when a crafted
| split option can be entered on the command line.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13445
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13445
[1] https://github.com/ros/ros_comm/issues/1738
[2] https://github.com/ros/ros_comm/pull/1741

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

> Does this upstream commit being added to the patches in +deb10u2 fix
> your issue?
> https://github.com/LibVNC/libvncserver/commit/7e63df224aa45a8b541cd63a870594454aba7526.patch

Not really.

With just ~debu10, 1 out of 10 times, the client window would stay open,
but I wasn't able to transmit any input… just no reaction whatsoever to
kb/mouse.

With 7e63df224aa45a8b541cd63a870594454aba7526 applied, this happens 9
out of 10 times.

A completely working connection couldn't be established at all.



signature.asc
Description: OpenPGP digital signature

Bug#945490: gs always fails with "Permission denied"

[Wolfgang Glunz]

should be solved with pstoedit 3.75 which I just uploaded to sourceforge.

Wolfgang

Bug#947785: x2gothinclient: x2go login window should show a blank username field

[Mike Gabriel]

Hi Wolfgang,

On  Do 02 Jan 2020 16:13:35 CET, Wolfgang Schweer wrote:


Hi Mike,

On Thu, Jan 02, 2020 at 01:44:27PM +, Mike Gabriel wrote:

For display-manager mode, --close-disconnect makes sense.

For minidesktop, the user is recommended to log out of the MATE
desktop session. This can be enforced by some auto logout (or killer?)
feature in MATE.


Yes, we all wish that people would follow recommendations...


Hehehe...


If --close-disconnect is added to X2Go Client in minidesktop mode,
what exactly happens when ending an X2Go session? Does X2Go Client
disappear entirely? The wanted behavious is that the X2Go Client
application stays on the desktop and is available for another X2Go
session login without having to relaunch the X2Go Client application.


With '--close-disconnect' added, the X2Go client is closed after the
user logged out from the server, but the X2Go Client icon stays on the
desktop.


Ok. The icon is IMHO sufficient.


If the next user clicks this icon, the X2Go Client appears in no time
with a clean login window.


Good. Then I will add --close-disconnect for minidesktop, too.


However, I agree that the user name should be removed from the login
mask. Maybe we need to amend this in X2Go Client upstream and discuss
that feature (maybe a new cmdline option) there.


Yes, good idea.


Not on my top prio list... I'll bring it up when looking into X2Go  
Client code next time.


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



pgpdfCsdw63yC.pgp
Description: Digitale PGP-Signatur

Bug#947945: shiro: CVE-2019-12422

[Salvatore Bonaccorso]

Source: shiro
Version: 1.3.2-4
Severity: important
Tags: security upstream
Control: found -1 1.3.2-1 

Hi,

The following vulnerability was published for shiro.

CVE-2019-12422[0]:
| Apache Shiro before 1.4.2, when using the default "remember me"
| configuration, cookies could be susceptible to a padding attack.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-12422
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12422
[1] https://www.openwall.com/lists/oss-security/2019/11/18/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#947683: x2gothinclient-minidesktop: diversion removal misses '--rename'

[Mike Gabriel]

Hi Andreas,

On  Do 02 Jan 2020 16:25:20 CET, Andreas Beckmann wrote:


On 02/01/2020 15.24, Mike Gabriel wrote:

My question about this bug report now is: do you see your bug report
fixed after I have added the --rename option to dpkg-divert? Or is the
bug more about policy and you are asking me to find another solution for
what I am doing with the diversion?


The --rename should be enough. My expectation is "uninstalling (purging)
the package should restore the former state". And if your "fiddling with
/usr" does not interfere with upgrades (diversions should work fine
here), I don't see any policy violations ;-).



Fair enough. Thanks for the feedback.

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



pgp251IN8luuu.pgp
Description: Digitale PGP-Signatur

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[John Scott]

On Thu, 02 Jan 2020 19:25:39 +0530 ra...@amaram.name wrote:
> It might be worth checking out in bullseye if the problem exists as well.
I'm using Anki w/ Plasma on Bullseye, and Ctrl+Enter works as expected on both 
X11 and Wayland. So this does seem Buster-specific.


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

Bug#947683: x2gothinclient-minidesktop: diversion removal misses '--rename'

[Andreas Beckmann]

On 02/01/2020 15.24, Mike Gabriel wrote:
> My question about this bug report now is: do you see your bug report
> fixed after I have added the --rename option to dpkg-divert? Or is the
> bug more about policy and you are asking me to find another solution for
> what I am doing with the diversion?

The --rename should be enough. My expectation is "uninstalling (purging)
the package should restore the former state". And if your "fiddling with
/usr" does not interfere with upgrades (diversions should work fine
here), I don't see any policy violations ;-).


Andreas

Bug#947785: x2gothinclient: x2go login window should show a blank username field

[Wolfgang Schweer]

Hi Mike,

On Thu, Jan 02, 2020 at 01:44:27PM +, Mike Gabriel wrote:
> For display-manager mode, --close-disconnect makes sense.
> 
> For minidesktop, the user is recommended to log out of the MATE 
> desktop session. This can be enforced by some auto logout (or killer?) 
> feature in MATE.

Yes, we all wish that people would follow recommendations...
 
> If --close-disconnect is added to X2Go Client in minidesktop mode, 
> what exactly happens when ending an X2Go session? Does X2Go Client 
> disappear entirely? The wanted behavious is that the X2Go Client 
> application stays on the desktop and is available for another X2Go 
> session login without having to relaunch the X2Go Client application.

With '--close-disconnect' added, the X2Go client is closed after the 
user logged out from the server, but the X2Go Client icon stays on the 
desktop.

If the next user clicks this icon, the X2Go Client appears in no time 
with a clean login window.
 
> However, I agree that the user name should be removed from the login 
> mask. Maybe we need to amend this in X2Go Client upstream and discuss 
> that feature (maybe a new cmdline option) there.

Yes, good idea.

Wolfgang


signature.asc
Description: PGP signature

Bug#947944: xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-

[Salvatore Bonaccorso]

Source: xen
Version: 4.11.1+92-g6c33308a8d-2
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

There are several CVEs open for xen up to unstable, compiling a list
from the information from the security-tracker it looks those below.

Any progress in getting those fixed at least for unstable already?

CVE-2018-12207[0]:
| Improper invalidation for page table updates by a virtual guest
| operating system for multiple Intel(R) Processors may allow an
| authenticated user to potentially enable denial of service of the host
| system via local access.


CVE-2019-11135[1]:
| TSX Asynchronous Abort condition on some CPUs utilizing speculative
| execution may allow an authenticated user to potentially enable
| information disclosure via a side channel with local access.


CVE-2019-18420[2]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to cause a denial of service via a VCPUOP_initialise hypercall.
| hypercall_create_continuation() is a variadic function which uses a
| printf-like format string to interpret its parameters. Error handling
| for a bad format character was done using BUG(), which crashes Xen.
| One path, via the VCPUOP_initialise hypercall, has a bad format
| character. The BUG() can be hit if VCPUOP_initialise executes for a
| sufficiently long period of time for a continuation to be created.
| Malicious guests may cause a hypervisor crash, resulting in a Denial
| of Service (DoS). Xen versions 4.6 and newer are vulnerable. Xen
| versions 4.5 and earlier are not vulnerable. Only x86 PV guests can
| exploit the vulnerability. HVM and PVH guests, and guests on ARM
| systems, cannot exploit the vulnerability.


CVE-2019-18421[3]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to gain host OS privileges by leveraging race conditions in
| pagetable promotion and demotion operations. There are issues with
| restartable PV type change operations. To avoid using shadow
| pagetables for PV guests, Xen exposes the actual hardware pagetables
| to the guest. In order to prevent the guest from modifying these page
| tables directly, Xen keeps track of how pages are used using a type
| system; pages must be "promoted" before being used as a pagetable, and
| "demoted" before being used for any other type. Xen also allows for
| "recursive" promotions: i.e., an operating system promoting a page to
| an L4 pagetable may end up causing pages to be promoted to L3s, which
| may in turn cause pages to be promoted to L2s, and so on. These
| operations may take an arbitrarily large amount of time, and so must
| be re-startable. Unfortunately, making recursive pagetable promotion
| and demotion operations restartable is incredibly complicated, and the
| code contains several races which, if triggered, can cause Xen to drop
| or retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables. A malicious PV guest administrator may be
| able to escalate their privilege to that of the host. All x86 systems
| with untrusted PV guests are vulnerable. HVM and PVH guests cannot
| exercise this vulnerability.


CVE-2019-18422[4]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service or gain privileges by leveraging
| the erroneous enabling of interrupts. Interrupts are unconditionally
| unmasked in exception handlers. When an exception occurs on an ARM
| system which is handled without changing processor level, some
| interrupts are unconditionally enabled during exception entry. So
| exceptions which occur when interrupts are masked will effectively
| unmask the interrupts. A malicious guest might contrive to arrange for
| critical Xen code to run with interrupts erroneously enabled. This
| could lead to data corruption, denial of service, or possibly even
| privilege escalation. However a precise attack technique has not been
| identified.


CVE-2019-18423[5]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service via a XENMEM_add_to_physmap
| hypercall. p2m-max_mapped_gfn is used by the functions
| p2m_resolve_translation_fault() and p2m_get_entry() to sanity check
| guest physical frame. The rest of the code in the two functions will
| assume that there is a valid root table and check that with BUG_ON().
| The function p2m_get_root_pointer() will ignore the unused top bits of
| a guest physical frame. This means that the function p2m_set_entry()
| will alias the frame. However, p2m-max_mapped_gfn will be updated
| using the original frame. It would be possible to set
| p2m-max_mapped_gfn high enough to cover a frame that would lead
| p2m_get_root_pointer() to return NULL in p2m_get_entry() and
| p2m_resolve_translation_fault(). Additionally, the sanity check on
| p2m-max_mapped_gfn is off-by-one allowing "highest mapped + 1" to
| be considered valid. However, p2m_get_root_pointer() will return 

Bug#930774: any idea when guile-2.2 will be fixed ?

[shirish शिरीष]

at bottom :-

On 02/01/2020, Rob Browning  wrote:
> shirish शिरीष  writes:
>
>> Just saw this, any idea when this FTFBS will be fixed. Somebody even
>> shared a patch, maybe that fixes the issue.
>
> I'll plan to investigate this weekend.  (I've been unfortunately
> preoccupied with python 3 related messes for a while.)
>

Ah, thank you fixing any python 3 messes as well. Well aware of the
transition happening. Haven't hit any major road-blocks yet, so all is
good :)

> Thanks
> --
> Rob Browning
> rlb @defaultvalue.org and @debian.org
> GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
> GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#947357: Bug #947357: votebar template fails at parsing some translated files

[Alban Vidal]

Hi Laura,

On Thu, 26 Dec 2019 22:31:36 +0100 Laura Arjona Reina
 wrote:

> * Fixing the Perl code in /english/template/debian/votebar.wml so it
> parses the title and status line wherever they are

I've created a MR on the Salsa webwml repository [1].

Build tried locally and it's work fine with the 'define-tag' on other
location on the file.

Bests regards,
Alban

[1] https://salsa.debian.org/webmaster-team/webwml/merge_requests/335

Bug#947943: libsoup2.4: Please make the libnss-myhostname build-dep linux-any

[Samuel Thibault]

Source: libsoup2.4
Version: 2.68.2-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

libnss-myhostname comes from the systemd package, which is only built
on linux-any, so could you make the libnss-myhostname dependency
[linux-any] like the attached patch does?

Thanks,
Samuel

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

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

-- 
Samuel
 on se croirait en cool : Some browsers close comments on the first ">" 
character, so to hide script content from such browsers, you can transpose 
operands for relational and shift operators (e.g., use "y < x" rather than "x > 
y") or use scripting language-dependent escapes for ">".
 -+- #ens-mim -+-
--- debian/control.original 2020-01-02 15:40:28.858523741 +0100
+++ debian/control  2020-01-02 15:41:12.858657536 +0100
@@ -28,7 +28,7 @@
php-xmlrpc ,
python3,
curl ,
-   libnss-myhostname ,
+   libnss-myhostname [linux-any] ,
valac
 Build-Depends-Indep: libglib2.0-doc
 Standards-Version: 4.4.1

Bug#947754: doorkeeper update

[Er_Maqui]

Hi @praveen,

Apparently, there's some work already done for updating gem:
Update doorkeeper to 4.4 version:
https://gitlab.com/gitlab-org/gitlab/merge_requests/20953
Update doorkeeper to 5 version:
https://gitlab.com/gitlab-org/gitlab/merge_requests/21173

Maybe the problem are deleting the "monkey patch"? As I've seen on the MRs,
it is deleted on version 5 but not on 4.4. Also, apparently, 4.4 are a
backport for fixing some CVE...

Regards,

https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia

Bug#947683: x2gothinclient-minidesktop: diversion removal misses '--rename'

[Mike Gabriel]

Hi Andreas,

On  So 29 Dez 2019 03:59:07 CET, Andreas Beckmann wrote:


Package: x2gothinclient-minidesktop
Version: 1.5.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies files from
another package in /usr. This is so wrong, I'm not even bothered to look
up the part of policy this violates ;-P


From the attached log (scroll to the bottom...):


4m16.9s INFO: Warning: Package purging left files on system:
  /etc/systemd/system/display-manager.service ->  
/lib/systemd/system/lightdm.service not owned

  /etc/systemd/user/ owned by: systemd
  /usr/lib/x2go/ owned by: x2gothinclient-common
  /usr/lib/x2go/x2goclient   not owned
  /usr/share/applications/x2goclient.desktop.disabled-by-x2gotce  
not owned

  /usr/share/doc/perl-base/  owned by: perl-base
  /usr/share/fonts/opentype/ owned by: fonts-cantarell
  /usr/share/fonts/opentype/cantarell/   owned by: fonts-cantarell
  /var/lib/systemd/deb-systemd-user-helper-masked/   not owned

4m16.9s ERROR: FAIL: After purging files have disappeared:
  /usr/bin/x2goclientowned by: x2gothinclient-minidesktop, x2goclient
  /usr/lib/x86_64-linux-gnu/gio/ owned by:  
glib-networking:amd64, gvfs:amd64, dconf-gsettings-backend:amd64
  /usr/lib/x86_64-linux-gnu/gio/modules/ owned by:  
glib-networking:amd64, gvfs:amd64, dconf-gsettings-backend:amd64

  /usr/share/applications/x2goclient.desktop owned by: x2goclient

4m17.0s ERROR: FAIL: Installation and purging test.

The diversions are created with --rename, so the files are moved aside,
but diversion removal lacks --rename, and the files are not restored.


cheers,

Andreas


Thanks for reporting this!

As x2gothinclient is a meta wrapper for x2goclient (and closely tied  
to it) and used on machines in a thin client environment, I went down  
the "fiddle with files in /usr of another package" path.


My question about this bug report now is: do you see your bug report  
fixed after I have added the --rename option to dpkg-divert? Or is the  
bug more about policy and you are asking me to find another solution  
for what I am doing with the diversion?


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



pgpc1Bu9jwtP3.pgp
Description: Digitale PGP-Signatur

Bug#945920: Random Chromium crashes

[Christopher Obbard]

Hi,
This is also occurring on two machines for me. The crashes are random
but will happen after about 10 minutes of use, quite annoying...

Thanks!
Chris

On Tue, 31 Dec 2019 18:27:13 +0100 (CET) Thorsten Bonow
 wrote:
> On Mon, 30 Dec 2019 13:50:36 -0800 Eloston 
> wrote:
>
> [...]
>
> > $ ./debian/rules get-orig-source
>
> Hi,
>
> this fails for me:
>
> [...]
> test ! -e debian || rm -rf debian
> cp -r ../debian ./
> cp: cannot stat '../debian': No such file or directory
> make: *** [debian/rules:212: get-orig-source] Error 1
> ./debian/rules get-orig-source  441.08s user 24.95s system 92% cpu
> 8:25.08 total
>
> Files and directories:
> $ ll
> total 12K
> drwxr-sr-x 50 toto staff 4.0K Dec 31 14:40 chromium-79.0.3945.79
> -rw-r--r--  1 toto staff 2.9K Dec 31 14:30
> chromium-build-deps_79.0.3945.79-1_all.deb
> -rw-r--r--  1 toto staff 3.6K Dec 31 12:28 enable-tracing.patch
> $ pwd
> /usr/local/src/chromium/chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371
>
>
> Regards,
> Toto
>
> --
> Sent from my GNU Emacs running on GNU/Linux
>
>

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Mike Gabriel]

Hi Daniel,

thanks for this regression report.

On  Mo 30 Dez 2019 14:01:04 CET, Daniel Reichelt wrote:


Hi all,

the new use-after-free patches introduced in 0.9.11+dfsg-1.3~deb10u2
hurt connections to servers provided by x11vnc.

Previously, a server initiated by

x11vnc -nopw -auth guess -display :0 -forever

was perfectly fine to connect to using tightvncviewer. Now, with
~deb10u2, the remote windows of tightvncviewer comes up for a fraction
of a second and then immediately closes with the message "Unknown
encoding". Nothing changed on the involved systems besides
libvncserver1/libvncclient1.

Reverting only the use-after-free patches, re-building libvncserver1 and
starting x11vnc using that package, tightvncviewer can connect again.

Also, this issue does NOT appear when libvncserver1/testing
(0.9.12+dfsg-5) is installed.


Cheers
Daniel


Does this upstream commit being added to the patches in +deb10u2 fix  
your issue?

https://github.com/LibVNC/libvncserver/commit/7e63df224aa45a8b541cd63a870594454aba7526.patch

Could you test this?

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



pgpa4ADAhofL7.pgp
Description: Digitale PGP-Signatur

Bug#947942: bash-completion: "umount" completion incompatible with mawk, breaks on spaces

[Philipp Marek]

Package: bash-completion
Version: 1:2.8-6
Severity: normal

With only the default "mawk" installed, auto-completion gives errors:

$ umount /
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined


With "gawk" installed (which gets used as more important alternative
automatically), this works as expected.

When using a debian live USB stick (which has spaces in the label),
autocompletion is broken though:

$ umount /media/
gives
$ umount /media/user/d-live nf 10.2.0 lx amd64
umount: /media/user/d-live: kein Einhängepunkt angegeben.
umount: nf: kein Einhängepunkt angegeben.
umount: 10.2.0: kein Einhängepunkt angegeben.
umount: lx: kein Einhängepunkt angegeben.
umount: amd64: kein Einhängepunkt angegeben.

I need to manually put quotes around that:

$ umount "/media/user/d-live nf 10.2.0 lx amd64"



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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

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

-- no debconf information

--

Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

[Scott Talbert]

On Thu, 2 Jan 2020, Bernd Zeimetz wrote:


upstream's comment to the current winpdb:

I started porting winpdb-reborn to Python 3 / Phoenix but the amount of
effort exceeds my availability. So: WINPDB ON PYTHON 3 IS BUGGY AND NOT
WORKING.

Did you test winpdb with the patches applied here? Does everything work
as expected?

I did not upload a new version as I wanted to keep it out of testing for
that reason, sorry for not stating that in the bug report.


I'm assuming you're talking about my changes in salsa to port to 
winpdb-reborn and move to Python 3 (and not my closing of this bug, which 
is pretty much unrelated).


Yes, it does seem to work as best as I can tell, but I'm not really 
familiar with winpdb.  I'm just really trying to help the Python 3 porting 
effort.  It seems like the other choice would be to remove winpdb from 
Debian, as Python 2 is going away.


Regards,
Scott

Bug#947931: RM: ghostwriter [armel mips64el ppc64el s390x] -- RoQA; ANAIS

[Sebastien CHAVAUX]

Hello,

I don't mind that you made the request. From what I understood is that 
the dependence is not on all architectures and that therefore 
Ghostwriter can no longer be on the architectures concerned.


So for the Ghostwriter package, what will happen?

Best regards.

Le 02/01/2020 à 11:02, Juhani Numminen a écrit :

Package: ftp.debian.org
X-Debbugs-Cc: Sebastien CHAVAUX 

Hi,

The binary package ghostwriter can't be built on these architectures
due to missing build-dependency qtwebengine5-dev.

With this removal, ghostwriter 1.8.0-2 should be able to migrate from
unstable to testing.

Sebastien, I hope you don't mind that I have filed this one for you.
The tracker https://tracker.debian.org/pkg/ghostwriter indicates your
package can't go to testing: it's a regression that the binaries for
some of the architectures do not exist in the new version. It can be
fixed by requesting a removal per https://wiki.debian.org/ftpmaster_Removals.


--
Juhani

Bug#947706: www.debian.org: Updating Debian portages web page

[Aurelien Jarno]

On 2019-12-31 07:56, Adrian Bunk wrote:
> On Sun, Dec 29, 2019 at 12:26:08PM +0100, Alban Vidal wrote:
> > Package: www.debian.org
> >...
> > -
> > 
> > Bellow the list of officials portages:
> > - amd64
> > - arm64
> > - armel
> > - armhf
> > - i386
> > - mipsel
> > - mips64el
> > - ppc64el
> > - s390x
> >...
> > [1] https://www.debian.org/ports/
> >...
> 
> Removing mips from the list of official ports is wrong.
> 
> As of Debian 10 mips is an official release architecture that will
> continue to be supported in this release.
> 
> For our users the most relevant information is what is supported in the 
> current stable release, not whatever changes might happen in future 
> releases.
> 
> Release architectures for Debian 11 are not yet decided, further changes 
> might happen and in theory it is even possible that someone starts 
> working on keeping mips as release architecture.
> 
> It has happened before that a port was discontinued but later restarted
> by other people.
> 
> > -
> > 
> > Bellow the list of unofficials portages:
> > - alpha
> > - arm
> > - AVR32
> > - hppa
> > - hurd-i386
> > - ia64
> > - kfreebsd-amd64
> > - kfreebsd-i386
> > - m32r
> > - m68k
> > - mips
> > - netbsd-i386
> > - netbsd-alpha
> > - or1k
> > - powerpc
> > - powerpcspe
> > - riscv64
> > - s390
> > - sparc
> > - sparc64
> > - sh4
> > - x32
> >...
> > [1] https://www.debian.org/ports/
> >...
> 
> This list does not contain all ports that autobuild unstable as of 
> today, and the status of several ports is incorrect.
> The current non-release architectures are the "Hosted Architectures"
> listed at https://www.ports.debian.org/
> 
> "discontinued" and "dead" seem to be different words for the same.
> 
> "in progress" is poor wording for ports that are not aiming at 
> (again) becoming release architectures, the most common term
> I am aware of would be "non-release architecture".
> 
> ftpmas...@ports-master.debian.org (added to Cc) is the correct contact 
> for discussing the status of ports that are not part of Debian 10.

The status of each port should be discussed directly with the
corresponding porters. On the debian-ports side, we basically host the
ports provided they are more or less maintained, useful to at least
some people and that there are no legal issue. We do not have other
criteria like the release team.

Aurelien, with his debian-ports hat.

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


signature.asc
Description: PGP signature

Bug#947941: alpine: New Upstream

[Matthew Gabeler-Lee]

Package: alpine
Version: 2.21+dfsg1-1.1
Severity: normal

It seems upstream has moved again, now to https://repo.or.cz/alpine.git

There is active development there from Eduadro, including two tagged
releases since what's in Debian currently (though from the numbering and the
contents of the pine.hlp file in the repo, these may be intended as
rc/pre-releases).

>From a cursory examination of the log, I see several commits that look like
they would fix open bugs in Debian.

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

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

Versions of packages alpine depends on:
ii  libc6 2.29-3
ii  libgssapi-krb5-2  1.17-3
ii  libkrb5-3 1.17-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u1
ii  libpam0g  1.3.1-5
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  mlock 8:2007f~dfsg-6

Versions of packages alpine recommends:
ii  alpine-doc  2.21+dfsg1-1.1

Versions of packages alpine suggests:
ii  aspell 0.60.7~20110707-6
ii  exim4  4.92-8+deb10u3
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u3

-- no debconf information

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[rahul]

The anki version that comes with Debian buster also has this issue. It might be 
worth checking out in bullseye if the problem exists as well. If it does and we 
find some fix for it, then that could probably be backported to buster as part 
of updates.

Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)

[Karel Zak]

On Thu, Oct 24, 2019 at 12:38:51AM +, Thorsten Glaser wrote:
> you were involved in changing script(1) to use signalfd, which
> is apparently Linux-specific but util-linux also is used, at
> least in Debian, on other kernels, such as the FreeBSD and Hurd
> ones (FSVO “kernel”, for the latter).

I have added this request to our TODO file. We'll see.

The problem is that with signalfd it's more reliable than when
classic signals interrupt any syscall, but I have no problem to
support any #ifdefs for non-signalfd systems.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com

Bug#946958: sa-compile failing on Graylisting.pm

[Shannon Dealy]

On Wed, 18 Dec 2019, Noah Meyerhans wrote:

[snip]

The problem is likely related to the fixes for CVE-2018-11805, which
involved malicious rulesets invoking arbitrary commands as the uid
running spamassassin/spamd.  In the case of sa-exim, the line triggering
the taint failure is performing an "eval" operation of configuration
data read directly from a .cf file, so changing spamasassin's behavior
is probably not ideal.

I've tested a backport of sa-exim 4.2.1-16 from stretch to jessie, and
have observed that the problem does not occur in this scenario.  So an
update of sa-exim in jessie might be the least disruptive path to a fix
here.  In the mean time, you might consider locally building it.


Hi Noah,

I tried backporting sa-exim 4.2.1-16 to jessie. While it installs and fixes 
the installation problem with sa-compile, for some reason it broke grey 
listing on my system. Basically, every email that gets grey listed will 
continually get temporary rejection until the other server gives up. It 
appears that no email once it is greylisted will ever get through.


I'm not sure if this is specific to my setup due to a quirk of my 
configuration settings and a minor incompatibility between the stretch 
and jessie versions of sa-exim or something more serious. Log files did not 
reveal anything obvious nor did a quick review of the differences between the 
sources of the two versions.


For now I have just disabled greylisting on my server, unfortunately I don't 
have time right now for a more in-depth analysis as I would have to re-learn 
how all of this works.


FWIW.

Shannon C. Dealy   |   DeaTech Research Inc.
de...@deatech.com  | Biotechnology Development Services
Telephone USA: +1 541-929-4089 |  USA and the Netherlands
Netherlands:   +31 85 208 5570 |  www.deatech.com

Bug#947940: RM: python-duckduckgo2 -- ROM; dead upstream

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal

For a package that depends on a web API, having a dead upstream is not a
great sign that it will continue to work going forward. Let's remove it
from the next release.

Bug#947785: x2gothinclient: x2go login window should show a blank username field

[Mike Gabriel]

Control: tags -1 + moreinfo

Hi Wolfgang,

On  Mo 30 Dez 2019 19:35:32 CET, Wolfgang Schweer wrote:


Package: x2gothinclient
Version: 1.5.0.1-1
Severity: important

Hi Mike, hi all,

while testing Debian Edu X2Go integration for thin clients I noticed
that the username field isn't blank after logging out. The username of
the last user is shown instead. This is supposed to be unwanted.

This change lets the x2go client start again with a clean login screen:

diff --git  
a/management/share/etc/x2gothinclient-displaymanager_start  
b/management/share/etc/x2gothinclient-displaymanager_start

index bb9fd5e..241b317 100755
--- a/management/share/etc/x2gothinclient-displaymanager_start
+++ b/management/share/etc/x2gothinclient-displaymanager_start
@@ -32,6 +32,7 @@
 --background=/etc/x2go/x2gothinclient-background.svg \
 --no-session-edit \
 --session=X2Go.Example \
+--close-disconnect \
 --add-to-known-hosts &

 #/usr/bin/x2goclient --no-menu \
diff --git a/management/share/etc/x2gothinclient-minidesktop_start  
b/management/share/etc/x2gothinclient-minidesktop_start

index 9ee118d..d1bde7b 100755
--- a/management/share/etc/x2gothinclient-minidesktop_start
+++ b/management/share/etc/x2gothinclient-minidesktop_start
@@ -32,6 +32,7 @@
  --read-exports-from=~/export \
  --no-session-edit \
  --session=X2Go.Example \
+ --close-disconnect \
  --add-to-known-hosts

 #/usr/libx/x2go/x2goclient --no-menu \

Please check.

Wolfgang


For display-manager mode, --close-disconnect makes sense.

For minidesktop, the user is recommended to log out of the MATE  
desktop session. This can be enforced by some auto logout (or killer?)  
feature in MATE.


If --close-disconnect is added to X2Go Client in minidesktop mode,  
what exactly happens when ending an X2Go session? Does X2Go Client  
disappear entirely? The wanted behavious is that the X2Go Client  
application stays on the desktop and is available for another X2Go  
session login without having to relaunch the X2Go Client application.


However, I agree that the user name should be removed from the login  
mask. Maybe we need to amend this in X2Go Client upstream and discuss  
that feature (maybe a new cmdline option) there.


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



pgpLfahAGSe7g.pgp
Description: Digitale PGP-Signatur

Bug#947912: hwloc: lstopo default scale is too small with graphical window on HiDPI screens

[Vincent Lefevre]

On 2020-01-02 13:28:59 +0100, Samuel Thibault wrote:
> Samuel Thibault, le jeu. 02 janv. 2020 01:55:15 +0100, a ecrit:
> > Vincent Lefevre, le jeu. 02 janv. 2020 01:48:43 +0100, a ecrit:
> > > It is possible to change the font size with --fontsize, but this
> > > does not work well as the space between the elements is not large
> > > enough.
> > 
> > You can use --gridsize to fix that part.
> > 
> > But yes, ideally lstopo would automatically use the dpi of the display,
> > to scale the font & grid sizes.
> 
> Actually there was already support for this, but it only took the dpi
> value from the Xserver, which is most often hardwired to 96 :/

Indeed, that's the case with the nouveau driver. :( The dpi value
was fine with the non-free Nvidia driver (but this driver has other
issues).

> I have added code to get the dpi value from Xft when available, that
> will be in hwloc 2.2.

Aligning the default font size with the Xft.dpi value may even be
better as this would honor the user preferences for the font size.

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

Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Control: tags -1 + fixed

I made a user instruction on how to use lxc on a Debian host booted with
systemd.unified_cgroup_hierarchy=1 at
https://wiki.debian.org/LXC/CGroupV2
I believe that this issue is now resolved, but I refrain from closing this,
while I add "fixed" tag. Ryutaroh Matsumoto

Bug#940570: gtk-layer-shell status

[Mike Gabriel]

Hi Birger,

On  Do 02 Jan 2020 13:56:25 CET, Birger Schacht wrote:


Hi,

On 1/2/20 7:49 AM, Mike Gabriel wrote:

Hi Birger,

thanks for your interest in joining in with packaging gtk-layer-shell.

On  Di 31 Dez 2019 22:07:00 CET, Birger Schacht wrote:

[...]



Maybe we can work together on this package or you can use the stuff I
already implemented (I haven't found a packaging repo in the mate team
for gtk-layer-shell so I figured you might not have started yet).


Yes, let's bundle resources. If you are not a DD yourself, I'll be happy
to move your Git repo over to salsa/debian/gtk-layer-shell and we
continue the packaging there. I haven't started anything, so far,
regarding putting together a DEB package. (Sometimes, it is just good to
wait... ;-) ).


Oke, feel free to move the repo any time. I'm neither DD nor DM, so you
would have to give me permissions to push to the repo if its in the
debian namespace.


I have moved the package over to the debian/ namespace on salsa. You  
should have full access to the repo there now.



If you are not a DD, are you interested in a packaging review? Or shall
I just go over your packaging and add my 2¢ here and there and then upload?


I'm happy about reviews! I have already some experience with packaging
and have more or less regular sponsors for some of my packages, but its
nice to have packages reviewed by new people, because different people
have different approaches to packaging ;)


As you are neither a DD nor DM, let me fine-tune the question:

Do you plan to become a DM or DD in the (near) future? If so, I'll  
surely review your packages.


If not (which makes not much sense with already quite a few pkgs in  
Debian), I'll simply add my change proposals on top (or via an MR) to  
save some time.




Maintainer-wise, I'd say we put a package tracker email address into the
Maintainer:-field and add the package to more than one team on
tracker.debian.org. So all teams get informed on updates. Uploader-wise,
we should put all persons' names into the field that are interested in
its maintenance.


Oke, I'll do that. I'm using the 'bare debian' git packaging approach,


/me loves bare debian/ repos... ;-)


which is not very common, but I'm happy to switch to something else (I
read the PkgMate/GitPackaging page, but it still lists alioth, so I'm
not sure how authoritative it is...).


no switching needed... :-D


I'll can then ping you when I think the package is ready for review.


Yes, please do.

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



pgphRUIrEtsXU.pgp
Description: Digitale PGP-Signatur

Bug#947939: etcd FTBFS in testing/unstable

[peter green]

Source: etcd
Version: 3.2.26+dfsg-4
Severity: serious

Etcd FTBFS in testing/unstable, I first noticed this on a raspbian autobuilder, 
but it's also happening on the
reproducible builds service for all architectures, so it's not raspbian specific

The only think I see in the log that looks like an error is


src/github.com/coreos/etcd/etcdserver/api/etcdhttp/base.go:57:26: undefined: 
prometheus.Handler


But I am far from sure if this is the real issue or not, I am not an expert in 
reading golang build logs.

Bug#947357: Bug #947357: votebar template fails at parsing some translated files

[Alban Vidal]

Hi Laura,

On Thu, 26 Dec 2019 22:31:36 +0100 Laura Arjona Reina
 wrote:

> I have noticed that the files not added in the Spanish index were the
> ones with the translation-check header in the first line. I have moved
> the translation-check header line below, so the first line is the
> pagetitle and the second line the status, and then the file is parsed
> correctly by the votebar template and thus, added to the index.
>
> So, I see 2 ways of solving the issue:
>
> * Fixing the Perl code in /english/template/debian/votebar.wml so it
> parses the title and status line wherever they are
>
> * Finding a list of the translated files not having the pagetitle and
> status lines as the first two lines in the file, and fixing them as I
> did with the Spanish ones, and adding a note to translators in future
> voting files so they move the translation-check header below (note that
> copypage.pl places this line at the top of the file).

All of files named 'vote_*.wml' now correctly start with:
line1: ^
line2: ^

Done by commit e7846f57 [1], thanks Jean-Pierre Giraud.
Votebar seem good on any languages.

Now I'll see to try to fix the Perl script (but I'm not Perl expert).

Best regards,
Alban

[1]
https://salsa.debian.org/webmaster-team/webwml/commit/e7846f578d3c3e61ec164111fa0569e6e8ca0d68




signature.asc
Description: OpenPGP digital signature

Bug#947938: RFP: kali-undercover -- Windows 10 like theme for Gnome

[iandeb]

Package: wnpp

Severity: wishlist

kali-undercover is a theme for Gnome to make it look like Windows 10.

Kali news: https://www.kali.org/news/kali-linux-2019-4-release/

Source: https://gitlab.com/kalilinux/packages/kali-undercover

Already packaged .deb files: 
https://archive.kali.org/kali/pool/main/k/kali-undercover/

Bug#940570: gtk-layer-shell status

[Birger Schacht]

Hi,

On 1/2/20 7:49 AM, Mike Gabriel wrote:
> Hi Birger,
> 
> thanks for your interest in joining in with packaging gtk-layer-shell.
> 
> On  Di 31 Dez 2019 22:07:00 CET, Birger Schacht wrote:
[...]
> 
>> Maybe we can work together on this package or you can use the stuff I
>> already implemented (I haven't found a packaging repo in the mate team
>> for gtk-layer-shell so I figured you might not have started yet).
> 
> Yes, let's bundle resources. If you are not a DD yourself, I'll be happy
> to move your Git repo over to salsa/debian/gtk-layer-shell and we
> continue the packaging there. I haven't started anything, so far,
> regarding putting together a DEB package. (Sometimes, it is just good to
> wait... ;-) ).

Oke, feel free to move the repo any time. I'm neither DD nor DM, so you
would have to give me permissions to push to the repo if its in the
debian namespace.

> If you are not a DD, are you interested in a packaging review? Or shall
> I just go over your packaging and add my 2¢ here and there and then upload?

I'm happy about reviews! I have already some experience with packaging
and have more or less regular sponsors for some of my packages, but its
nice to have packages reviewed by new people, because different people
have different approaches to packaging ;)

> 
> Maintainer-wise, I'd say we put a package tracker email address into the
> Maintainer:-field and add the package to more than one team on
> tracker.debian.org. So all teams get informed on updates. Uploader-wise,
> we should put all persons' names into the field that are interested in
> its maintenance.

Oke, I'll do that. I'm using the 'bare debian' git packaging approach,
which is not very common, but I'm happy to switch to something else (I
read the PkgMate/GitPackaging page, but it still lists alioth, so I'm
not sure how authoritative it is...).
I'll can then ping you when I think the package is ready for review.

cheers,
Birger

Bug#947937: celluloid crashes when clicking on hamburger menu or progress bar

[Roderich Schupp]

Package: celluloid
Version: 0.17-1
Severity: important
Tags: upstream

Known bug when celluloid is using libmpv1 >= 0.29.1, e.g.
https://github.com/celluloid-player/celluloid/issues/468 or
https://github.com/celluloid-player/celluloid/issues/471

Workaround in
https://github.com/celluloid-
player/celluloid/commit/6fca3f16616f4f46c1647fe4610e57c8c9ae74ff
(or upgrade to v0.18)



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

Kernel: Linux 5.4.6 (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)

Versions of packages celluloid depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-2
ii  libc62.29-7
ii  libcairo21.16.0-4
ii  libepoxy01.5.4-1
ii  libglib2.0-0 2.63.3-1
ii  libgtk-3-0   3.24.13-1
ii  libmpv1  0.30.0-1
ii  libpango-1.0-0   1.44.7-1
ii  libpangocairo-1.0-0  1.44.7-1

Versions of packages celluloid recommends:
ii  youtube-dl  2019.09.28-1

celluloid suggests no packages.

-- no debconf information

Bug#947263: python3-iniparse: missing Breaks+Replaces: python-iniparse

[Andreas Beckmann]

Followup-For: Bug #947263
Control: found -1 0.4-3

Hi,

python3-iniparse now has
  Replaces: python-iniparse (<< 0.4-2.3)
but the corresponding Breaks is still missing.
This allows partial upgrade paths where python-iniparse is kept
installed (but crippled, because it lost some files). If
python3-iniparse gets removed afterwards, python-iniparse is still
installed and able to satisfy dependencies, but broken.


Andreas

Bug#947936: chrony: Does (still) not start properly on boot on buster

[Santiago Vila]

Package: chrony
Version: 3.4-4
Severity: important

Dear maintainer:

Apparently, installing chrony does not ensure at all that it will work.

Google has moved from ntp in Debian 9 to chrony in Debian 10 for their
default Debian GCE images, and I discovered this on a lot of GCE
instances having a clock several minutes off.

The problem I found is very similar to the one described here:

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

I believe the best summary of the problem was made by Michael Biebl
here:

https://github.com/systemd/systemd/issues/7104#issuecomment-471329392

Quoting Michael:
> As it stands, the current practice of having systemd-timesyncd.service
> enabled by default (in Debian) and alternative implementations like
> chrony or ntpd declare Conflicts=systemd-timesyncd.service in their
> service file does not work reliably.


AFAIK, this has been fixed on the systemd side in version 241-3 by
dropping the "Conflicts" systemd had on chrony or ntpd.

Unfortunately, AFAIK, conflicts are bi-directional, so apparently the
problem will persist in buster as far as chrony still has conflicts
in the systemd unit file.

I've noticed this problem happens randomly (it happens in some
instances, it does not happens in some others), so I don't have a
"recipe" as such to reproduce it.

However, I have a particular instance at GCE showing this behaviour
which I could try to clone to give you ssh access if required (please
contact me privately for details).

The behaviour is the following:

Both systemd-timesyncd and chrony are enabled (which is the default
on GCE instances). Just after a reboot, "systemctl status chrony" shows this:

● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead)
   Docs: man:chronyd(8)
   man:chronyc(1)
   man:chrony.conf(5)

and I see this in the boot log:

systemd[1]: Condition check resulted in Network Time Synchronization being 
skipped.

If I do "systemctl disable systemd-timesyncd" and reboot, chrony is
properly loaded and it runs.

If I do "systemctl enable systemd-timesyncd" again and reboot, chrony
is shown as "inactive (dead)" again.

At this point, if I edit 
/etc/systemd/system/multi-user.target.wants/chrony.service
to remove the Conflicts line and reboot, chrony is properly loaded and it runs.

[ I'm reporting this as "important" because I believe it to be the kind
  of bug that should be fixed in a point release of Debian 10 ].

[ Cc to Michael Biebl in case he would like to comment on the issue ].

Thanks.

Bug#947935: ITP: opentmpfiles -- standalone utility written to process systemd-style tmpfiles.d files

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: opentmpfiles
  Version : 0.2
  Upstream Author : William Hubbs 
* URL : https://github.com/OpenRC/opentmpfiles
* License : BSD-2-clause
  Programming Lang: Shell
  Description : standalone utility written to process systemd-style 
tmpfiles.d files

This is a standalone utility written to process systemd-style tmpfiles.d files
so that they can be handled on systems with or without systemd installed.

Bug#947912: hwloc: lstopo default scale is too small with graphical window on HiDPI screens

[Samuel Thibault]

Samuel Thibault, le jeu. 02 janv. 2020 01:55:15 +0100, a ecrit:
> Vincent Lefevre, le jeu. 02 janv. 2020 01:48:43 +0100, a ecrit:
> > It is possible to change the font size with --fontsize, but this
> > does not work well as the space between the elements is not large
> > enough.
> 
> You can use --gridsize to fix that part.
> 
> But yes, ideally lstopo would automatically use the dpi of the display,
> to scale the font & grid sizes.

Actually there was already support for this, but it only took the dpi
value from the Xserver, which is most often hardwired to 96 :/ I have
added code to get the dpi value from Xft when available, that will be in
hwloc 2.2.

Samuel

Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]

[Tobias Frost]

Control: tags -1 moreinfo

Tagging moreinfo as currently not actionable (needs an update from
Fabian)

Bug#926025: emacs-gtk: Crash in redisplay_internal() due to use of emacs_abort()

[Simon Josefsson]

FWIW, I also get this crash when opening one of my folders (nnimap)
using Gnus that is shipped with Emacs.  A more complete backtrace can be
found below.

/Simon

Fatal error 6: Aborted
Thread 1 "emacs" received signal SIGABRT, Aborted.
raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Filen eller katalogen finns inte.
(gdb) bt
#0  raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x004f6f37 in terminate_due_to_signal (sig=sig@entry=6, 
backtrace_limit=backtrace_limit@entry=40) at ./debian/build-src/src/emacs.c:394
#2  0x00511643 in emacs_abort () at ./debian/build-src/src/sysdep.c:2426
#3  0x004574ea in redisplay_internal () at 
./debian/build-src/src/lisp.h:2797
#4  0x00459c22 in redisplay_preserve_echo_area 
(from_where=from_where@entry=13) at ./debian/build-src/src/xdisp.c:14630
#5  0x005ab860 in Fdelete_process (process=61304133) at 
./debian/build-src/src/process.c:1078
#6  0x005b35f5 in kill_buffer_processes (buffer=buffer@entry=0) at 
./debian/build-src/src/process.c:7836
#7  0x004f6dfa in shut_down_emacs (sig=sig@entry=6, 
stuff=stuff@entry=0) at ./debian/build-src/src/lisp.h:855
#8  0x004f6f63 in terminate_due_to_signal (sig=sig@entry=6, 
backtrace_limit=backtrace_limit@entry=40) at ./debian/build-src/src/lisp.h:855
#9  0x00511643 in emacs_abort () at ./debian/build-src/src/sysdep.c:2426
#10 0x004574ea in redisplay_internal () at 
./debian/build-src/src/lisp.h:2797
#11 0x00459c22 in redisplay_preserve_echo_area 
(from_where=from_where@entry=13) at ./debian/build-src/src/xdisp.c:14630
#12 0x005ab860 in Fdelete_process (process=59467093) at 
./debian/build-src/src/process.c:1078
#13 0x005b35f5 in kill_buffer_processes (buffer=buffer@entry=0) at 
./debian/build-src/src/process.c:7836
#14 0x004f6d34 in shut_down_emacs (sig=sig@entry=0, 
stuff=stuff@entry=0) at ./debian/build-src/src/lisp.h:855
#15 0x004c3efd in x_connection_closed (dpy=dpy@entry=0x2ae86c0, 
error_message=, 
error_message@entry=0x7fff5880 "X protocol error: BadLength (poly 
request too large or internal Xlib length error) on protocol request 139", 
ioerror=ioerror@entry=false) at ./debian/build-src/src/lisp.h:855
#16 0x004c7d49 in x_error_quitter (display=0x2ae86c0, event=, event=) at ./debian/build-src/src/xterm.c:9904
#17 0x004c7dcb in x_error_handler (display=0x2ae86c0, 
event=0x7fff5a40) at ./debian/build-src/src/xterm.c:9874
#18 0x7684b11a in _XError () from /lib/x86_64-linux-gnu/libX11.so.6
#19 0x76848077 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#20 0x7684811d in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#21 0x76848a55 in _XEventsQueued () from 
/lib/x86_64-linux-gnu/libX11.so.6
#22 0x7683a7b7 in XPending () from /lib/x86_64-linux-gnu/libX11.so.6
#23 0x770e420d in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
#24 0x76bbd669 in g_main_context_prepare () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x76bbe06b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x76bbe207 in g_main_context_pending () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x773b2b9d in gtk_events_pending () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x004c4917 in XTread_socket (terminal=, 
hold_quit=0x7fff5d40) at ./debian/build-src/src/xterm.c:9142
#29 0x004fe1c9 in gobble_input () at 
./debian/build-src/src/keyboard.c:6910
#30 0x004fe875 in handle_async_input () at 
./debian/build-src/src/keyboard.c:7146
#31 process_pending_signals () at ./debian/build-src/src/keyboard.c:7160
#32 0x005d8dd7 in xftfont_open (f=, entity=70284725, 
pixel_size=15) at ./debian/build-src/src/xftfont.c:391
#33 0x00586aa4 in font_open_entity (f=0x1010c80 
, entity=70284725, pixel_size=15) at 
./debian/build-src/src/font.c:2903
#34 0x005db72a in fontset_find_font (fontset=fontset@entry=59386213, 
c=c@entry=9200, face=face@entry=0x41b9720, charset_id=charset_id@entry=-1, 
fallback=fallback@entry=true) at ./debian/build-src/src/lisp.h:855
#35 0x005db9b1 in fontset_font (fontset=fontset@entry=59386213, 
c=c@entry=9200, face=face@entry=0x41b9720, id=-1) at 
./debian/build-src/src/fontset.c:788
#36 0x005dbcbc in face_for_char (f=0x1010c80 , 
face=face@entry=0x41b9720, c=9200, pos=, object=)
at ./debian/build-src/src/fontset.c:990
#37 0x00448473 in FACE_FOR_CHAR (object=, pos=, character=, face=0x41b9720, f=)
at ./debian/build-src/src/dispextern.h:1818
#38 get_next_display_element (it=it@entry=0x7fff87f0) at 
./debian/build-src/src/xdisp.c:7303
#39 0x0044f698 in display_line (it=it@entry=0x7fff87f0, 
cursor_vpos=cursor_vpos@entry=0) at ./debian/build-src/src/xdisp.c:21409
#40 0x0045450b in try_window (window=window@entry=16919605, pos=..., 

Bug#934297: RFS: bibtexconv/1.1.16-1

[Tobias Frost]

Control: tags -1 moreinfo

Hi Thomas,

reviewing this package, I have some comments:

- Can you please merge the d/changelog entries for (in Debian)
unreleased versions?
- The Debian changelog seems incomplete, I see (packaing) changes which
are not documented. Please also try to expand a bit on the changes, e.g
did the SV update require you add changes? (documenting "why has this
changed" is important as additional information to the "what")
- You do not need to specify the standards versions 4th digit, this
digit is for editorial changes only. So it is sufficient to declare
compatiblitliy with e.g 4.4.1 (which has been released since you put
this package to mentors)
- d/test/control is a empty file. I don't think that is right.

nitpicks:
d/compat can be obsoleted. (
https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/
)


Cheers,
-- 
tobi

Bug#947933: RFS: python-mongoengine/0.19.0-1 -- Python 3 Document-Object Mapper for working with MongoDB

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-mongoengine"

 * Package name: python-mongoengine
   Version : 0.19.0-1
   Upstream Author : Harry Marr harry.m...@gmail.com
 * URL : http://mongoengine.org/
 * License : MIT
 * Vcs : 
https://salsa.debian.org/python-team/modules/python-mongoengine

   Section : python

It builds those binary packages:

  python3-mongoengine - Python 3 Document-Object Mapper for working 
with MongoDB
  python-mongoengine-doc - Python Document-Object Mapper for working 
with MongoDB (documentation)


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


  https://mentors.debian.net/package/python-mongoengine

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-mongoengine/python-mongoengine_0.19.0-1.dsc


Changes since the last upload:

   * New upstream version 0.19.0
   * d/control
 - Add python3-dateutil and python3-pil to suggests
 - Add Rules-Requires-Root: no
   * Add CI in salsa

Regards,
Håvard

Bug#947932: RFS: vfu/4.18-1 [QA] [RC] -- Versatile text-based filemanager

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "vfu"

 * Package name: vfu
   Version : 4.18-1
   Upstream Author : Vladi Belperchinov-Shabanski  

 * URL : http://cade.datamax.bg/vfu/
 * License : GPL-2
 * Vcs : None
   Section : utils

It builds those binary packages:

  vfu - Versatile text-based filemanager

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vfu/vfu_4.18-1.dsc

Changes since the last upload:

   * QA upload.
   * Update to new upstream release of 4.18.
 - Repack without *.out
 - Repack without config.log files
 - Repack without config.status files
   * Remove manpage patch applied upstream.
   * Add patch for ftbfs with GCC-9. (Closes: #925852)
   * Update Standards-Version to 4.4.1
   * Update compat level to 12
   * Simplify d/rules
 - Add -g to generate debug symbols
 - Install files in the old path
   * Install the manpage


-- 
Regards
Sudip

Bug#937648: python-click: Python2 removal in sid/bullseye

[peter green]

unblock 937648 by 936731

hi,

I have been working to get rid of cruft packages in testing, python-click is 
the main thing holding the python-colorama cruft package in testing.

Looking at the remaining "blockers", rows and nipype are not in testing, so I 
think we can disregard them (especially as python-click is already uninstallable in 
unstable). That leaves incremental, which I have just NMUd to eliminate the build-depends 
and recommends on python-click.

Looking at the "update output" from britney there are also two reverse depends 
that are fixed in unstable, but not in testing. Namely ceph (struggling to migrate to 
testing, hopefully will be fixed soon) and flask (blocked from migrating to testing by 
impacket and polenum, which are both scheduled for autoremoval).

Once ceph and flask are migrated to testing, I belive it will be time to drop 
python2 support from python-click too. Do you agree?

Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1

[Julien Cristau]

On Tue, Dec 31, 2019 at 18:25:04 -0500, Sandro Tosi wrote:

> On Tue, Dec 31, 2019 at 6:11 PM Julien Cristau  wrote:
> >
> > Nak. I don't want to drop python support at this stage.
> 
> can you explain why? there is no package in debian depending on
> python-hglib, and in a week it will be auto-removed from testing
> because of this
> 
Because I find this removal premature and distasteful.  I was hoping my
downgrading this bug would be a hint, but you decided to ignore that.

Cheers,
Julien

Bug#929024: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator

[Marco d'Itri]

On Jan 02, Martin Hoffmann  wrote:

> > > Building a real package will still require a few more crates to be
> I think you can just ask the Debian Rust team to include them or
> somesuch?
I have packaged all missing dependencies: at this point the only blocker 
is ring and possibly other not up to date dependencies (I have not 
checked all of them).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#933631: kazoo: test failures

[Gianfranco Costamagna]

control: severity -1 serious

tests now depend on python2 RC buggy packages.

G.

On Thu, 1 Aug 2019 09:27:12 +0200 Gianfranco Costamagna 
 wrote:
> Source: kazoo
> Version 2.6.1-1
> Severity: important
> 
> Hello, looks like kazoo 2.6.1-1 started failing his tests wrt 2.5.0.
> 
> I found two issues:
> 1) ZOEKEEPER_VERSION not being correctly found on the system.
> "fixed by exporting it on debian/tests"
> export ZOOKEEPER_VERSION="3.4.13"
> 2) missing python-objgraph in debian/tests/control
> 
> unfortunately there are some "test_acl" and "test_ssl" failures, such as
> http://debomatic-amd64.debian.net/distribution#unstable/kazoo/2.6.1-1.1/autopkgtest
> 
> - >> end captured logging << -
> 
> ==
> FAIL: test_invalid_sasl_auth (kazoo.tests.test_client.TestAuthentication)
> --
> Traceback (most recent call last):
>   File "/tmp/autopkgtest.EU6u1A/build.vPf/src/kazoo/tests/test_client.py", 
> line 256, in test_invalid_sasl_auth
> self.assertRaises(ConnectionLoss, client.start)
> AssertionError: ConnectionLoss not raised
> ==
> ERROR: test_get_acls (kazoo.tests.test_client.TestClient)
> --
> Traceback (most recent call last):
>   File "/tmp/autopkgtest.EU6u1A/build.vPf/src/kazoo/tests/test_client.py", 
> line 832, in test_get_acls
> self.assertTrue(acl in client.get_acls('/a')[0])
>   File "/tmp/autopkgtest.EU6u1A/build.vPf/src/kazoo/client.py", line 1171, in 
> get_acls
> return self.get_acls_async(path).get()
>   File "/tmp/autopkgtest.EU6u1A/build.vPf/src/kazoo/handlers/utils.py", line 
> 75, in get
> raise self._exception
> NoAuthError: 
>  >> begin captured logging << 
> kazoo.client: Level 5: ZK loop started
> kazoo.client: Level 5: Skipping state change
> kazoo.client: INFO: Connecting to 127.0.0.1:20010, use_ssl: False
> kazoo.client: Level 5: Using session_id: None session_passwd: 
> 
> kazoo.client: DEBUG: Sending request(xid=None): Connect(protocol_version=0, 
> last_zxid_seen=0, time_out=800, session_id=0, 
> passwd='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 
> read_only=None)
> kazoo.client: Level 5: Read response Connect(protocol_version=0, 
> last_zxid_seen=0, time_out=4000, session_id=144264043061379102, 
> passwd='*\x14\xe3\xae\xa6\x8e.\xa4\x84\xcd\xb6G)\xd5#\xff', read_only=False)
> kazoo.client: Level 5: Session created, session_id: 144264043061379102 
> session_passwd: 2a14e3aea68e2ea484cdb64729d523ff
> negotiated session timeout: 4000
> connect timeout: 1333
> read timeout: 2666.6667
> kazoo.client: INFO: Zookeeper connection established, state: CONNECTED
> kazoo.client: DEBUG: Sending request(xid=1): 
> Exists(path='/kazootests337e91d9e8534e879c85db206a6560ff', watcher=None)
> kazoo.client: Level 5: Reading for header ReplyHeader(xid=1, zxid=4294967719, 
> err=-101)
> kazoo.client: DEBUG: Sending request(xid=2): 
> Exists(path='/kazootests337e91d9e8534e879c85db206a6560ff', watcher=None)
> kazoo.client: Level 5: Reading for header ReplyHeader(xid=2, zxid=4294967719, 
> err=-101)
> kazoo.client: DEBUG: Sending request(xid=3): 
> Create(path='/kazootests337e91d9e8534e879c85db206a6560ff', data='', 
> acl=[ACL(perms=31, acl_list=['ALL'], id=Id(scheme='world', id='anyone'))], 
> flags=0)
> kazoo.client: Level 5: Reading for header ReplyHeader(xid=3, zxid=4294967720, 
> err=0)
> kazoo.client: DEBUG: Received response(xid=3): 
> u'/kazootests337e91d9e8534e879c85db206a6560ff'
> kazoo.client: DEBUG: Sending request(xid=4): 
> Create(path='/kazootests337e91d9e8534e879c85db206a6560ff/a', data='', 
> acl=[ACL(perms=31, acl_list=['ALL'], id=Id(scheme='digest', 
> id=u'user:smGaoVKd/cQkjm7b88GyorAUz20='))], flags=0)
> kazoo.client: Level 5: Reading for header ReplyHeader(xid=4, zxid=4294967721, 
> err=0)
> kazoo.client: DEBUG: Received response(xid=4): 
> u'/kazootests337e91d9e8534e879c85db206a6560ff/a'
> kazoo.client: DEBUG: Sending request(xid=5): 
> GetACL(path='/kazootests337e91d9e8534e879c85db206a6560ff/a')
> kazoo.client: Level 5: Reading for header ReplyHeader(xid=5, zxid=4294967721, 
> err=-102)
> kazoo.client: DEBUG: Received error(xid=5) NoAuthError()

Bug#947920: RFS: pdf2djvu/0.9.15-1 [NMU] -- PDF to DjVu converter

[Sudip Mukherjee]

On Thu, Jan 2, 2020 at 8:30 AM Woodrow Shen  wrote:
>
> Thanks, Paul.
>
> I've followed this page to update #945185. with setting retitle/owner.

Also add your name  as maintainer in d/control and reupload for
sponsoring, and add it to the changelog. That will actually make you
the new maintainer.

-- 
Regards
Sudip

Bug#929024: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator

[Martin Hoffmann]

Hi Marco,

Marco d'Itri via RPKI wrote:
> On Dec 29, Marco d'Itri via RPKI  wrote:
> 
> > Building a real package will still require a few more crates to be

I think you can just ask the Debian Rust team to include them or
somesuch?

> Right now I am stuck on rpki depending on a very old version of ring.
> The verification API has changed since then and I do not know enough 
> Rust to update rpki.

Ring is one of those things where you can’t depend on multiple versions
(because assembler or C or something). We currently are still on that
old version because something Krill uses depends on it. This should be
fixed soon.

Now that all of the HTTP dependencies have released version with for
the new async world with a path to API stability, I will move to that
world as well and then clean up and stabilise all dependencies
throughout all our crates. Which also is the last big thing before I am
happy to go 1.0.

Kind regards,
Martin 

Bug#947467: python-incremental, reccomends and build-depends on package that depends on obsolete package.

[peter green]

Since there has been no maintainer response I have gone ahead and NMU'd this. 
The debdiff (attatched) is the same as previously other than filling in the bug 
number and target suite.


diff -Nru incremental-16.10.1/debian/changelog 
incremental-16.10.1/debian/changelog
--- incremental-16.10.1/debian/changelog2016-11-03 20:27:56.0 
+
+++ incremental-16.10.1/debian/changelog2019-12-27 12:48:06.0 
+
@@ -1,3 +1,14 @@
+incremental (16.10.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-depends and reccomends on python-click (Closes: 947467)
+  * Disable python 2 autopkgtests and remove associated test dependencies.
+  * Disable testsuite for python 2 (keep it enabled for python 3)
+  * Add note to package description about incremental.update functionality
+and python-click.
+
+ -- Peter Michael Green   Fri, 27 Dec 2019 12:48:06 +
+
 incremental (16.10.1-3) unstable; urgency=medium
 
   * Recommend python Twisted and Click, in order to use incremental.update
diff -Nru incremental-16.10.1/debian/control incremental-16.10.1/debian/control
--- incremental-16.10.1/debian/control  2016-11-03 20:27:56.0 +
+++ incremental-16.10.1/debian/control  2019-12-27 12:48:06.0 +
@@ -7,7 +7,6 @@
python-all (>= 2.6.6-3),
python-setuptools (>= 0.6b3),
python-twisted-core,
-   python-click,
python3-all,
python3-setuptools (>= 0.6b3),
python3-twisted,
@@ -20,12 +19,16 @@
 Package: python-incremental
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}
-Recommends: python-click, python-twisted-core
+Recommends: python-twisted-core
 Provides: ${python:Provides}
 Description: Library for versioning Python projects.
  Incremental is a small library that versions your Python projects.
  .
  This package provides the Python 2.x module.
+ .
+ The incremental.update functionality requires the click module which is
+ no longer available for python 2 in Debian. If you require this functionality
+ we suggest using python 3.
 
 Package: python3-incremental
 Architecture: all
diff -Nru incremental-16.10.1/debian/rules incremental-16.10.1/debian/rules
--- incremental-16.10.1/debian/rules2016-11-03 17:40:25.0 +
+++ incremental-16.10.1/debian/rules2019-12-27 12:48:06.0 +
@@ -2,6 +2,10 @@
 
 export PYBUILD_NAME=incremental
 
+# Don't test python 2 because python-click is not available anymore.
+export PYBUILD_DISABLE_python2=test
+export PYBUILD_DISABLE_python2-dbg=test
+
 # XXX Unit tests seem to leave cruft around, for some reason
 export PYBUILD_AFTER_TEST=rm -rf {build_dir}/incremental.tests.*
 
diff -Nru incremental-16.10.1/debian/tests/control 
incremental-16.10.1/debian/tests/control
--- incremental-16.10.1/debian/tests/control2016-11-03 20:27:56.0 
+
+++ incremental-16.10.1/debian/tests/control2019-12-27 12:47:49.0 
+
@@ -1,7 +1,5 @@
-Tests: unit-tests-2 unit-tests-3
+Tests: unit-tests-3
 Restrictions: needs-root
 Depends: @,
- python-twisted-core,
- python-click,
  python3-twisted,
  python3-click

Bug#946394: Bug#946395: RFS: mercurial-extension-utils/1.5.0-1 -- Contains functions for writing Mercurial extensions

[Tobias Frost]

Control: tags -1 moreinfo 

On Wed, 11 Dec 2019 21:11:17 +0100 Christoph Mathys  Would it be better to just wait until mercurial has switched and
then add this package again?

No need to have it removed :)
To avoid that it being removed from Debian by following the
instructions in the bug #937012 (the section with the usertag py2keep)

(I'm marking the bug moreinfo as it seems not to be actionable right
now and to avoid that potential sponsors checks this only to find out
that there is nothing actionable)

--
tobi

Bug#947847: Should we standardize with /usr/bin/sysusers ?

[Thomas Goirand]

Hi Michael (and anyone else working on systemd),

To me, it looks like systemd is installing in /usr/bin/systemd-sysusers.
However, opensysusers is installing a binary in /usr/bin/sysusers.
Probably, we should standardize on /usr/bin/sysusers, rather than
/usr/bin/systemd-sysusers, and install alternative on /usr/bin/sysusers
then we can write this in the policy that everyone should use "sysusers"
rather than the specific implementation. I'd then install
/usr/bin/opensysuser-sysusers as the alternative for my package.

Also, opensysusers is providing man pages, but I'm not sure if we should
use them, install alternatives for them as well, or use use the ones
from systemd. Right now, I believe I'd prefer to use the ones from
systemd, as this is what opensysusers references to.

Your thoughts about the 2 points above?

Cheers,

Thomas Goirand (zigo)

Bug#947931: RM: ghostwriter [armel mips64el ppc64el s390x] -- RoQA; ANAIS

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: Sebastien CHAVAUX 

Hi,

The binary package ghostwriter can't be built on these architectures
due to missing build-dependency qtwebengine5-dev.

With this removal, ghostwriter 1.8.0-2 should be able to migrate from
unstable to testing.

Sebastien, I hope you don't mind that I have filed this one for you.
The tracker https://tracker.debian.org/pkg/ghostwriter indicates your
package can't go to testing: it's a regression that the binaries for
some of the architectures do not exist in the new version. It can be
fixed by requesting a removal per https://wiki.debian.org/ftpmaster_Removals.


--
Juhani

Bug#947891: avahi-daemon: segfaults after upgrade to buster with airprint service

[Andreas Henriksson]

Control: forwarded -1 https://github.com/lathiat/avahi/pull/257

On Thu, Jan 02, 2020 at 09:41:50AM +0100, Andreas Henriksson wrote:
[...]
> This is where the actual explosion happens:
> https://sources.debian.org/src/avahi/0.7-5/avahi-daemon/static-services.c/#L630
[...]

I've confirmed my suspicion that u->buf is simply NULL and strlen() will
crash if passed a NULL argument.

Patch has been pushed both to debian packaging git repo (so should be
part of next upload) as well as upstream merge request.

Regards,
Andreas Henriksson

Bug#947924: ITP: haskell-bytestring -- Fast, compact, strict and lazy byte strings with a list interface

[Mike Gabriel]

Control: close -1

Hi Sean,

On  Do 02 Jan 2020 10:33:48 CET, Sean Whitton wrote:


control: tag -1 +moreinfo

Dear Mike,

On Thu 02 Jan 2020 at 08:45am +01, Mike Gabriel wrote:


Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: haskell-bytestring
  Version : 0.10.10.0
  Upstream Author : Duncan Coutts 
* URL : https://hackage.haskell.org/package/bytestring
* License : BSD-3
  Programming Lang: Haskell
  Description : Fast, compact, strict and lazy byte strings  
with a list interface


This library is bundled with ghc.  I believe that it shouldn't be
packaged separately.


thanks for that info. Closing this ITP again, then...

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



pgpFmxuAQKrwM.pgp
Description: Digitale PGP-Signatur

Bug#947734: TLS1.3 bug not simple... may interact with stunnel4!

[Simon Iremonger]

This bug, seems to be not quite so simple .

For example, is possible to  /connect -x www.openssl.org 443
which is apparently TLS1.3-enabled  and then GET / HTTP/1.0
with no issue.

But stunnel4 service providing TLS1.3 and this failure does happen!.
Puzzle...

--Simon

Bug#947924: ITP: haskell-bytestring -- Fast, compact, strict and lazy byte strings with a list interface

[Sean Whitton]

control: tag -1 +moreinfo

Dear Mike,

On Thu 02 Jan 2020 at 08:45am +01, Mike Gabriel wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
>
> * Package name: haskell-bytestring
>   Version : 0.10.10.0
>   Upstream Author : Duncan Coutts 
> * URL : https://hackage.haskell.org/package/bytestring
> * License : BSD-3
>   Programming Lang: Haskell
>   Description : Fast, compact, strict and lazy byte strings with a list 
> interface

This library is bundled with ghc.  I believe that it shouldn't be
packaged separately.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#947930: transition: gspell

[Laurent Bigonville]

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

Hello,

The soname of the gspell library has bumped its soname from
libgspell-1-1 to libgspell-1-2

I rebuilt all the rdeps and they all build fine with the new library.
BUT ATM there is an issue with gnome-software (and sysprof) on ppc64el
that should be fixed first before we can start the transition.

The following packages needs a source upload as they also need to be
updated to use enchant-2 to avoid having both enchant(1) and enchant-2
linked inside the same binary:

geary
gnome-builder
evolution

Kind regards,

Laurent Bigonville

Ben file:

title = "gspell";
is_affected = .depends ~ "libgspell-1-1" | .depends ~ "libgspell-1-2";
is_good = .depends ~ "libgspell-1-2";
is_bad = .depends ~ "libgspell-1-1";


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

Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#947929: frescobaldi: Redirect TMPDIR to ram disk, because of automatic engraving

[Silvério Santos]

Package: frescobaldi
Version: 3.0.0+ds1-2
Severity: wishlist
Tags: newcomer

Dear Maintainer,

with the automatic engraving function activated Frescobaldi constantly compiles
the .ly source code in at least one file (layout, e.g. .pdf), sometimes also
more (+ .midi). This happens almost after every change in the source code, so
this behavior wears out SSDs. To work around this I propose to set up a tmpfs
ram disk and redefine the TMPFS env var to that path for Frescobaldi. Since I
found no option inside the software, I did it on loading the software:

Manual new line to /etc/fstab:
none /media/username/frescoram tmpfs

Manual change to the Frescobaldi menu entry:
TMPDIR=/media/username/frescoram/ bash -c 'frescobaldi "%F"'

To be honest, with the small files I use, there is no major speedup, but this
might be different for bigger projects. Instead, the small size of the files
are perfect for today's usual computers to dynamically redirect a tiny part of
their multi-GB RAM in order to protect the hardware (200 KB in my case!). Also,
if used up, tmpfs starts to swap instead of reporting to be full.

Obviously this is a quickly available solution, but only a workaround. It could
be useful to have this integrated into the software, where the amount of
available RAM and other things, like the creation of the ram disk, can be
programatically taken into account.



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

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

Versions of packages frescobaldi depends on:
ii  libportmidi01:217-6
ii  python3 3.7.5-1
ii  python3-ly  0.9.5-3
ii  python3-poppler-qt5 0.24.2-3+b4
ii  python3-pyqt5   5.13.2+dfsg-1
ii  python3-pyqt5.qtsvg 5.13.2+dfsg-1
ii  python3-pyqt5.qtwebkit  5.13.2+dfsg-1
ii  tango-icon-theme0.8.90-7

Versions of packages frescobaldi recommends:
ii  lilypond  2.19.81+really-2.18.2-13

Versions of packages frescobaldi suggests:
ii  hyphen-de [hyphen-hyphenation-patterns]  1:6.3.4-1
ii  lilypond-doc 2.19.81+really-2.18.2-13

-- debconf-show failed

Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

[Bernd Zeimetz]

Hi,

upstream's comment to the current winpdb:

I started porting winpdb-reborn to Python 3 / Phoenix but the amount of
effort exceeds my availability. So: WINPDB ON PYTHON 3 IS BUGGY AND NOT
WORKING.

Did you test winpdb with the patches applied here? Does everything work
as expected?

I did not upload a new version as I wanted to keep it out of testing for
that reason, sorry for not stating that in the bug report.


Bernd




On 1/2/20 5:45 AM, Debian Bug Tracking System wrote:
> Your message dated Wed, 1 Jan 2020 23:40:22 -0500 (EST)
> with message-id 
> and subject line 
> has caused the Debian Bug report #762332,
> regarding winpdb: diff for NMU version 1.4.8-2.1
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 

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

Bug#904215: civicrm: CIVI-SA-2018-07: Remote Code Execution in Quickform

[Dmitry Smirnov]

On Thursday, 2 January 2020 7:50:39 PM AEDT Salvatore Bonaccorso wrote:
> >   https://wiki.debian.org/UpstreamGuide
> 
> Ah I see there was already a mentioning of requesting CVEs *but* it
> was pointing to a not anymore available site of poeple.redhat.com, I
> updated the reference to
> https://github.com/RedHatProductSecurity/CVE-HOWTO (and furthermore
> asked there to not mention anymore DWF for assigning CVEs as well,
> siee https://github.com/RedHatProductSecurity/CVE-HOWTO/issues/5).

Excellent. Thank you.

-- 
Cheers,
 Dmitry Smirnov.

---

The cure for the evils of democracy is more democracy.
-- H. L. Mencken



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

Bug#947422: [Pkg-javascript-devel] Bug#947422: node-babel depends on itself for build, then updating core-js is blocked

[Xavier]

Le 02/01/2020 à 08:18, Xavier a écrit :
> Hi,
> 
> I tried to embed core-js@2.6.x in node-babel-runtime. I pushed my work
> into a new "unstable" branch.
> 
> @praveen, could you review ?
> 
> Cheers,
> Xavier

Bad, babel-runtime/core-js/ dir is no more generated...

Bug#904215: civicrm: CIVI-SA-2018-07: Remote Code Execution in Quickform

[Salvatore Bonaccorso]

Hi

On Thu, Jan 02, 2020 at 06:57:39PM +1100, Dmitry Smirnov wrote:
> On Thursday, 2 January 2020 6:20:23 PM AEDT Salvatore Bonaccorso wrote:
> > The good thing on having a CVE id for the vulnerabilities is helping
> > other vendors to track the issues properly 'cross-vendor' in an unique
> > way. If every upstream would use individual identifiers to track their
> > vulnerabilities, this makes the work of downsteams security teams much
> > harder. Nowdays MITRE has improved a lot on their processes on
> > assigning CVEs, and good filled reports at https://cveform.mitre.org/
> > get fastly assigned a CVE respectively (this somehow depends though on
> > how good the report is done). I know some upstreams did in past make
> > frustrating experiations, and do not want to try that out again.
> 
> Thank you so much, that is exactly what I've been looking for.
> I'll pass that to upstream.
> 
> It would be great to add your explanation to "Debian Upstream Guide" for easy 
> reference:
> 
>   https://wiki.debian.org/UpstreamGuide

Ah I see there was already a mentioning of requesting CVEs *but* it
was pointing to a not anymore available site of poeple.redhat.com, I
updated the reference to
https://github.com/RedHatProductSecurity/CVE-HOWTO (and furthermore
asked there to not mention anymore DWF for assigning CVEs as well,
siee https://github.com/RedHatProductSecurity/CVE-HOWTO/issues/5).

Regards,
Salvatore

Bug#947928: rdesktop crash with segmentation error

[Antonio]

Package: rdesktop
Version: 1.9.0-1+b1
Severity: normal

Dear Maintainer,
rdesktop crash with this error:

Autoselecting keyboard map 'it' from locale
Protocol(warning): Protocol negotiation failed with reason: SSL not
allowed by server
Retrying with plain RDP.
Errore di segmentazione

Found this issue at https://github.com/rdesktop/rdesktop/issues/277.

Recompiling from the source solve the problem.

Is it possible to update the package provided by repository?

Thanks,
Antonio



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

Kernel: Linux 5.4.7-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT), LANGUAGE=it (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rdesktop depends on:
ii  libasound21.1.9-1
ii  libc6 2.29-7
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgnutls30   3.6.11.1-2
ii  libgssapi-krb5-2  1.17-6
ii  libhogweed5   3.5.1+really3.5.1-2
ii  libnettle73.5.1+really3.5.1-2
ii  libpcsclite1  1.8.25-3
ii  libtasn1-64.15.0-2
ii  libx11-6  2:1.6.8-1
ii  libxcursor1   1:1.2.0-2
ii  libxrandr22:1.5.1-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
ii  pcscd  1.8.25-3

-- no debconf information