Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]

[Paul Gevers]

Control: tags -1 moreinfo

Hi Mo,

On 09-06-2019 05:41, Mo Zhou wrote:
> Following
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u
> I've not uploaded it yet but asking for permission first.

Thanks.

> Fix a GRAVE stable RC due to linux's unexporting several
> fpu-related symbols:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929
> 
> This is the very only purpose of this upload.
> The solution in this upload is cherry-picked from upstream,
> which directly disable the SIMD thing for linux (>= 4.19.38).
> 
> I scanned the rest historical patches we have applied to
> zfs 0.7.12. Some of them fix crashes and segfaults but they
> don't look fatal enough and would inflate the debdiff hence
> incur rejection. Let's forget them.
> 
> I've tested this patch on Buster with a manually-built
> 4.19.48 kernel (make defconfig, make, make bindeb-pkg).
> 
> Full source:
> https://people.debian.org/~lumin/upload/zfs-linux_0.7.12-2+deb10u1_source.changes
> Debdiff: attached.
> 
> (include/attach the debdiff against the package in testing)
> 
> unblock zfs-linux/0.7.12-2+deb10u1

We are not promising to unblock the package, but we recognize it that
you can't help it that the kernel is breaking your package in the
future. So please upload to tpu, have the package built and please
solicit people to test the package. Please report back with the results.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB

[Otto Kekäläinen]

Hello!

Great news!

I created project and invited you to developer if you want to have it
group maintained under the MariaDB team :
https://salsa.debian.org/mariadb-team/mariadb-connector-odbc/

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Thomas Calderon]

Hi there,

It's unfortunate that OCaml has removed the support for ocamlopt for armel,
it sounds like CamlCrush will not be able to ship for armel.
Is it required that I create an updated Debian release excluding armel as a
target or as you said, ftpmaster can just remove the binaries?
I would have thought that I have to specifically exclude it in the
Architecture field?

Thanks,

Thomas

On Thu, May 23, 2019 at 7:15 PM plugwash 
wrote:

> package: caml-crush
> tags: buster,sid
> severity: serious
> x-debbugs-cc: debian-ocaml-ma...@lists.debian.org
>
> caml-crush build-depends on ocaml-native-compilers. In stretch this was
> a real package. In buster it is a virtual package provided by ocaml-base
> on most architectures, but does not seem to exist at all on armel. In
> the ocaml changelog I see "drop support for ocamlopt on armel as
> suggested by upstream" which I suspect reflects this change.
>
> If this package can be reasonablly made to work without
> ocaml-native-compilers on armel then you should do so, if you belive it
> is not reasonable to support this package on armel please
> reassign/retitle this to ftpmaster so they can remove the armel binaries.
>

Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Peter,

On 13-06-2019 10:34, plugwash wrote:
> Recently I became aware of two issues in mu-editor. A tool for beginning
> python programmers.
> 
> I was informed that the "debug" button in mu-editors default python mode was
> broken in the Debian packaged version of mu. While this does not render
> the software totally unusable it is a pretty major deficiency.
> 
> The cause of the breakage is that the debug helper program 
> /usr/share/mu-editor/mu-debug.py fails to find the python module mu.app
> due to not having /usr/share/mu-editor in it's sys.path. The main mu 
> executable
> is in /usr/share/mu-editor, so it finds the modules through the default 
> sys.path[0], but the debug helper script is in /usr/share/mu-editor/mu so it
> does not find them. My fix was to make the debug helper script modify 
> sys.path[0] before importing mu.app.
> 
> While working on the above issue I discovered that the clean target did not
> clean up completely (in violation of policy 4.9) and this was making working 
> on
> the package irritating, so I added some extra rm commands to clean up the 
> stray
> files.
> 
> Is there any chance of getting at least the first and preferablly both of 
> these
> fixes into buster?
> 
> A debdiff is attatched. 
> 
> unblock mu-editor/1.0.2+dfsg-2.1

These bugs are not RC. You filed the bug today. Please coordinate with
the maintainer first before filing unblock bugs for an NMU so quickly.
And fix your bug meta-data please.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Arnaud Rebillout]

On 6/13/19 3:31 PM, Paul Gevers wrote:
> Control: retitle -1 unblock: docker.io [pre-approval]
> Control: tags -1 moreinfo
>
> Hi Arnaud,
>
> On 10-06-2019 06:44, Arnaud Rebillout wrote:
>> I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
>> before I do that I'd like to ask a question to the release team.
>>
>> For now in testing we have docker.io 18.09.1, and on top of that I've
>> been importing upstream patches to fix RC bugs, because from what I
>> understand from the Policy, that's what I should do.
> During the freeze we only want targeted fixes for bugs of severity
> important and higher (BTS definition) [freeze-policy], yes
>
>> The 18.09 series of docker is a so-called "LTS", and that's exactly why
>> it's THIS release in particular that I targeted for Buster, rather than
>> a more recent release. Every now and then upstream releases a new dot
>> release, the latest to date is 18.09.6 (released in May).
> ... but it's possible that new upstream releases *are* targeted bug
> fixes. However, ...
>
>> According to the upstream changelog, these are mostly fixes. And to get
>> an idea of the volume, between 18.09.1 to 18.09.6, there was 142
>> commits, which is rather small compared to the size of docker's codebase.
> you as the maintainer have to do the checking. And, "mostly" doesn't
> qualify. 142 is *not* small at this moment of the release [last-weeks].
>
>> So it seems to me that upstream really only adds fixes to the 18.09
> ^^^ I'd like you to make that assertion much stronger.
> Convince yourself 100%, so you can convince us. Is there a LTS policy
> that describes what upstream considers acceptable? Does it align with
> our bug severity important or higher? Do they test thoroughly? Etc...
>
>> series, and I also think that our users would be better served if they
>> could have the latest version of this series in Buster, rather than what
>> I'm doing now: only patching 18.09.1 with whatever bug was reported in
>> Debian and marked RC, and ignoring all the other bugs that were reported
>> and fixed upstream.
> I care for bugs that are reported in the Debian BTS, but that doesn't
> mean that it's all we care about. We have had multiple unblock requests
> where the maintainer was evaluating the changes done upstream and
> convinced themselves that they all qualified. By doing the evaluation
> they were often able to convince us. In some cases they didn't. I can
> only assume that a lot of unblock requests were not filed because the
> maintainer couldn't convince themselves.
>
>> Hence I'd like to ask the release team if they think it would be
>> suitable to unblock docker.io to allow the version 18.09.6 to be
>> uploaded in Buster? Or, better, wait for the next 18.09.7 that will
>> include the CVE fix, probably in the next days?
> Upstream releases are not acceptable at this moment in the release.
> After what I wrote above, obviously with the exception where you can
> convince yourself and us that *everything* in the release is qualifying
> our freeze criteria [freeze-policy]. However, if at this moment in the
> freeze [last-weeks] you need so many changes, I seriously wonder if your
> package should be in buster (in general, not necessarily valid for
> docker.io)
>
>> Or should I just stick to 18.09.1, and only upload a new debian version
>> that only includes the CVE fix?
> You'll get an unblock much easier.


I'll go this way then :)

Thanks for taking some time to give such a detailed answer, not only for
docker.io but more generally to get a better grasp on what's suitable or
not during the freeze.

I won't audit the whole 142 commits, even less convince myself or anyone
about what it brings on the table, so I'll stick to fixing the CVE that
is opened at the moment.

Thanks,

  Arnaud

Bug#930324: unblock: nageru/1.8.4-2

[Paul Gevers]

Control: tags -1 moreinfo confirmed

On 12-06-2019 16:12, Steinar H. Gunderson wrote:
> On Wed, Jun 12, 2019 at 04:06:30PM +0200, Ivo De Decker wrote:
>>> Please unblock package nageru
>> I unblocked it, but noticed it's stuck behind gcc-8. Can you prepare a
>> testing-proposed-updates upload?
> 
> Sure! I'll upload tonight.

Please remove the moreinfo tag when the package is available to be
unblocked.

Thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

[plugwash]

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

Recently I became aware of two issues in mu-editor. A tool for beginning
python programmers.

I was informed that the "debug" button in mu-editors default python mode was
broken in the Debian packaged version of mu. While this does not render
the software totally unusable it is a pretty major deficiency.

The cause of the breakage is that the debug helper program 
/usr/share/mu-editor/mu-debug.py fails to find the python module mu.app
due to not having /usr/share/mu-editor in it's sys.path. The main mu executable
is in /usr/share/mu-editor, so it finds the modules through the default 
sys.path[0], but the debug helper script is in /usr/share/mu-editor/mu so it
does not find them. My fix was to make the debug helper script modify 
sys.path[0] before importing mu.app.

While working on the above issue I discovered that the clean target did not
clean up completely (in violation of policy 4.9) and this was making working on
the package irritating, so I added some extra rm commands to clean up the stray
files.

Is there any chance of getting at least the first and preferablly both of these
fixes into buster?

A debdiff is attatched. 

unblock mu-editor/1.0.2+dfsg-2.1
diff -Nru mu-editor-1.0.2+dfsg/debian/changelog 
mu-editor-1.0.2+dfsg/debian/changelog
--- mu-editor-1.0.2+dfsg/debian/changelog   2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/changelog   2019-06-13 02:03:44.0 
+
@@ -1,3 +1,12 @@
+mu-editor (1.0.2+dfsg-2.1) unstable; urgency=medium
+
+  * Non-Maintainer upload.
+  * Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+(Closes: 930457)
+  * Fix clean target.
+
+ -- Peter Michael Green   Thu, 13 Jun 2019 02:03:44 +
+
 mu-editor (1.0.2+dfsg-2) unstable; urgency=medium
 
   * d/gbp.conf: use pristine-tar
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch 
mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch
--- mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
1970-01-01 00:00:00.0 +
+++ mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
2019-06-13 02:03:44.0 +
@@ -0,0 +1,24 @@
+Description:  Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+ Debian installs mu-editor's modules in a directory that is not on the
+ global python path. mu-editor finds the modules through sys.path[0]
+ pointing at /usr/share/mu-editor, unfortunately for mu-debug.py 
+ sys.path[0] is /usr/share/mu-editor/mu, so the modules are not found
+ adjust sys.path[0] in mu-editor.py to fix this issue
+Author: Peter Michael Green 
+Last-Update: 2019-06-13
+Bug-Debian: https://bugs.debian.org/930457
+
+--- mu-editor-1.0.2+dfsg.orig/mu/mu-debug.py
 mu-editor-1.0.2+dfsg/mu/mu-debug.py
+@@ -1,6 +1,11 @@
+ #!/usr/bin/env python3
+ import os
+ import sys
++
++#Remove last path element from sys.path[0] so that mu modules can be found 
relative to this executable.
++import os.path
++sys.path[0] = os.path.dirname(sys.path[0])
++
+ from mu.app import debug
+ 
+ 
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/series 
mu-editor-1.0.2+dfsg/debian/patches/series
--- mu-editor-1.0.2+dfsg/debian/patches/series  2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/patches/series  2019-06-13 02:03:44.0 
+
@@ -8,3 +8,4 @@
 remove-non-dfsg-images-from-docs
 remove-non-dfsg-resources
 test_app_icon_as_string
+mu-debug-alter-sys.path.patch
diff -Nru mu-editor-1.0.2+dfsg/debian/rules mu-editor-1.0.2+dfsg/debian/rules
--- mu-editor-1.0.2+dfsg/debian/rules   2019-02-28 02:43:16.0 +
+++ mu-editor-1.0.2+dfsg/debian/rules   2019-06-13 02:03:44.0 +
@@ -27,6 +27,9 @@
 override_dh_auto_clean:
dh_auto_clean
rm -rf docs/html
+   rm -f debian/mu-editor.1
+   rm -f debian/mu-editor.1.md
+   rm -rf .pytest_cache
 
 override_dh_auto_build:
dh_auto_build

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Paul Gevers]

Control: retitle -1 unblock: docker.io [pre-approval]
Control: tags -1 moreinfo

Hi Arnaud,

On 10-06-2019 06:44, Arnaud Rebillout wrote:
> I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
> before I do that I'd like to ask a question to the release team.
>
> For now in testing we have docker.io 18.09.1, and on top of that I've
> been importing upstream patches to fix RC bugs, because from what I
> understand from the Policy, that's what I should do.

During the freeze we only want targeted fixes for bugs of severity
important and higher (BTS definition) [freeze-policy], yes

> The 18.09 series of docker is a so-called "LTS", and that's exactly why
> it's THIS release in particular that I targeted for Buster, rather than
> a more recent release. Every now and then upstream releases a new dot
> release, the latest to date is 18.09.6 (released in May).

... but it's possible that new upstream releases *are* targeted bug
fixes. However, ...

> According to the upstream changelog, these are mostly fixes. And to get
> an idea of the volume, between 18.09.1 to 18.09.6, there was 142
> commits, which is rather small compared to the size of docker's codebase.

you as the maintainer have to do the checking. And, "mostly" doesn't
qualify. 142 is *not* small at this moment of the release [last-weeks].

> So it seems to me that upstream really only adds fixes to the 18.09

^^^ I'd like you to make that assertion much stronger.
Convince yourself 100%, so you can convince us. Is there a LTS policy
that describes what upstream considers acceptable? Does it align with
our bug severity important or higher? Do they test thoroughly? Etc...

> series, and I also think that our users would be better served if they
> could have the latest version of this series in Buster, rather than what
> I'm doing now: only patching 18.09.1 with whatever bug was reported in
> Debian and marked RC, and ignoring all the other bugs that were reported
> and fixed upstream.

I care for bugs that are reported in the Debian BTS, but that doesn't
mean that it's all we care about. We have had multiple unblock requests
where the maintainer was evaluating the changes done upstream and
convinced themselves that they all qualified. By doing the evaluation
they were often able to convince us. In some cases they didn't. I can
only assume that a lot of unblock requests were not filed because the
maintainer couldn't convince themselves.

> Hence I'd like to ask the release team if they think it would be
> suitable to unblock docker.io to allow the version 18.09.6 to be
> uploaded in Buster? Or, better, wait for the next 18.09.7 that will
> include the CVE fix, probably in the next days?

Upstream releases are not acceptable at this moment in the release.
After what I wrote above, obviously with the exception where you can
convince yourself and us that *everything* in the release is qualifying
our freeze criteria [freeze-policy]. However, if at this moment in the
freeze [last-weeks] you need so many changes, I seriously wonder if your
package should be in buster (in general, not necessarily valid for
docker.io)

> Or should I just stick to 18.09.1, and only upload a new debian version
> that only includes the CVE fix?

You'll get an unblock much easier.

Paul

[freeze-policy] https://release.debian.org/buster/freeze_policy.html
[last-weeks]
https://lists.debian.org/debian-devel-announce/2019/06/msg3.html



signature.asc
Description: OpenPGP digital signature

Bug#930457: mu-editor: debugger broken.

[Peter Green]

reassign 930457 mu-editor thanks (sorry screwed up the headers)

 Ben Nuttal recently informed my that trying to use the "debug" button in 
mu-editor in Debian buster results in


Traceback (most recent call last):

File "/usr/share/mu-editor/mu/mu-debug.py", line 4, in 

from mu.app import debug

ModuleNotFoundError: No module named 'mu'


Investigation shows that this is the result of failure to find mu-related 
python modules. mu-editor itself finds them because the mu-editor executable 
(AFTER following the symlink) is located in /usr/share/mu-editor but the 
mu-debug helper script is in a subdirectory and so does not find them.

The simplest fix seems to be to adjust sys.path[0] in mu-debug.py I whipped up 
(and tested) a patch to do that. While working on that I noticed that the clean 
target was broken, so I fixed that too. knowledgejunkie: are you ok if I go 
ahead and NMU this and ask the release team for an unblock? (if I get no 
response i'll NMU in 5 days, but I'd really like to move sooner given how 
little time is available before release)

Bug#929830: syslog shows netlink error

[Vincent Bernat]

 ❦ 13 juin 2019 09:03 +02, michael-dev :

>> Is there anything special on your setup? Lots of interface running or
>> interfaces cycling (VM)?
>
> This has happened both in virtual and non-virtual machines, some of
> them only have one interface, others have two or three.
> I also do not see spurious link up/down messages in dmesg, so
> interfaces should not have cycled.

Are there all 32bits x86 hosts?

If it happens in a few hours/days, could you run it through valgrind?
You will need to install lldpd-dbgsym (see
https://wiki.debian.org/AutomaticDebugPackages) and run the following
command:

  valgrind --leak-check=full lldpd -dd

It will use more memory than usual but when you see the memory growing a
lot, you can Ctrl-C and you'll get a report that would help to find
where the leak is.
-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

On Wed, Jun 12, 2019 at 10:44 PM Faustin Lammler  wrote:
> do you still have the build log, if not, can you give me your build
> steps and environment so I can try to reproduce the error?

No, however I think it should be reproducible in all environments.

It's too late for Buster isn't it?

It might make more sense to do this split in 10.4.

-- 
Olaf

Bug#846583: Microsoft-Konten team

[Adriana Bobinec]

Diese Nachricht wird an Sie gesendet, um Sie darüber zu informieren, dass Ihr 
Microsoft-Konto bald abläuft, wenn es nicht aktualisiert wird. Wir 
benachrichtigen Sie aufgrund des erneut übermittelten Updates in unserer 
Datenbank.

Wenn Sie diesen Account weiterhin nutzen möchten, klicken Sie bitte auf 
Aktualisieren und Upgrade auf unsere 
Dienste. Wenn Sie diese Nachricht ignorieren, wird das Konto geschlossen
Hinweis: Dieses Aktualisierung ist unmittelbar nach dem Empfang dieser 
Nachricht erforderlich

Vielen Dank,
Konten Team.


?

Bug#930466: libfaudio-dev not multi-arch installable as it ships binary /usr/bin/faudio_tests.

[Christian Klein]

Package: libfaudio-dev
Version: 19.06.07-1
Severity: important
Tags: patch

When trying to do a multiarch-install of libfaudio-dev for amd64 and i386 on my
machine, I get the following error:

Unpacking libfaudio-dev:i386 (19.06.07-1) ...
dpkg: error processing archive /var/cache/apt/archives/libfaudio-
dev_19.06.07-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/bin/faudio_tests', which is different from
other instances of package libfaudio-dev:i386
Errors were encountered while processing:
 /var/cache/apt/archives/libfaudio-dev_19.06.07-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

As Faudio is mainly needed to build and cross-compile wine on amd64, this
renders the package mostly useless.

faudio_tests are the unit tests for the Faudio package, which should most
likely not be shipped, especially not as part of the -dev package.

When I build faudio from the upstream source, the tests are not even build at
all.

The fix is to not ship the binary, I included a trivial patch for this.


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500,
'unstable-debug'), (350, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libfaudio-dev depends on:
ii  libfaudio0  19.06.07-1

libfaudio-dev recommends no packages.

libfaudio-dev suggests no packages.
diff -Naur faudio-19.06.07.orig/debian/libfaudio-dev.install 
faudio-19.06.07/debian/libfaudio-dev.install
--- faudio-19.06.07.orig/debian/libfaudio-dev.install   2019-06-13 
08:45:02.172434065 +0200
+++ faudio-19.06.07/debian/libfaudio-dev.install2019-06-13 
08:46:36.585944833 +0200
@@ -2,4 +2,3 @@
 
 usr/lib/*/*.so
 
-usr/bin/faudio_tests

Bug#881554: [linux-target-packaging] Bug#881554: python-configshell-fb: Please migrate away from Epydoc if possible

[Ritesh Raj Sarraf]

Control: tag -1 +pending


Hello Kenneth,

So for Buster release, I've let the epydoc support be enabled as is.
For post Buster, I have dropped the epydoc dependency altogether as it
is not a hard dependency.

Thanks,
Ritesh

On Sun, 2017-11-12 at 19:18 -0500, Kenneth Pronovici wrote:
> Source: python-configshell-fb
> Severity: wishlist
> 
> Hi,
> 
> If possible, please consider moving away from the use of Epydoc in
> your
> package.  Epydoc is basically unmaintained upstream.  Also, it is
> only
> supported for Python 2, so it will reach its end of life along with
> Python 2 sometime in 2020.
> 
> I will continue to maintain the Epydoc packages in Debian as long as
> I
> can, acting as de facto upstream.  However, once Python 2 is
> unsupported
> in Debian, I'm not sure that we'll have too many options to keep it
> alive.  Migrating it to Python 3 is a fairly large job that I don't
> have the time or the expertise to take on right now.
> 
> For my own Python code, I have recently converted to Sphinx using the
> Napolean plugin.  At [1], I can offer you (or your upstream) a hack-
> ish
> script to convert common Epydoc markup to Google-style docstrings.
> It's
> not perfect, but it would get you much of the way toward working
> code.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#929697: fixed in pyglet 1.3.0-2.1

[Paul Gevers]

Hi,

On Tue, 04 Jun 2019 21:03:47 + Reinhard Tartler
 wrote:
>* Disable ClockTimingTestCase (Closes: #929697)

^^ If this is supposed to go into buster, somebody has to prepare a
targeted upload to unstable (d/copyright improvement can stay). Most of
the current delta is not acceptable for an unblock at this stage of the
release, so without action, we will remove pyglet from buster soon. To
be clear, I'm *not* offering tpu.

Paul

Bug#929830: syslog shows netlink error

[michael-dev]

Am 11.06.2019 12:45, schrieb Vincent Bernat:

Is there anything special on your setup? Lots of interface running or
interfaces cycling (VM)?


This has happened both in virtual and non-virtual machines, some of them 
only have one interface, others have two or three.
I also do not see spurious link up/down messages in dmesg, so interfaces 
should not have cycled.


Regards,
M. Braun

Bug#930465: jami: Strange KDE integration ('gnome-ring' window title, no window border)

[Petter Reinholdtsen]

Package: jami
Version: 20190215.1.f152c98~ds1-1

Hi.  When testing jami in Buster with KDE, I get a window without the
normal borders, and the window title is 'gnome-ring'.  Perhaps the title
should change to 'jami' and the borders could be recovered?

-- 
Happy hacking
Petter Reinholdtsen

Bug#929908: unblock: tomcat9/9.0.16-4

[Paul Gevers]

Control: tags -1 moreinfo confirmed

Hi Emmanuel,

> unblock tomcat9/9.0.16-4

Please upload the package soon and remove the moreinfo tag when it can
be unblocked.

Thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930464: mednafen: PS1 emulation regression

[Stephen Kitt]

Package: mednafen
Version: 1.22.1+dfsg-1
Severity: serious
Tags: patch
Justification: regression

Dear Maintainer,

Upstream fixed a PS1 regression in 1.22.2; in 1.22.1, a few games are
unplayable (SimCity 2000 and Rise 2 for example). The attached patch
fixes this.

Regards,

Stephen


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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mednafen depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  libmpcdec62:0.1~r495-1+b1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libsndfile1   1.0.27-3
ii  libstdc++66.3.0-18+deb9u1
ii  libtrio2  1.16+dfsg1-3+b2
ii  libvorbisidec11.0.2+svn18153-1+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mednafen recommends:
ii  mednaffe  0.8.4-1+b1

mednafen suggests no packages.

-- no debconf information
--- a/src/psx/cdc.cpp
+++ b/src/psx/cdc.cpp
@@ -1874,7 +1874,7 @@
 
   if(CommandLoc_Dirty)
SeekTarget = CommandLoc;
-  else
+  else if(DriveStatus != DS_PAUSED && DriveStatus != DS_STANDBY)
SeekTarget = CurSector;
 
   PSRCounter = 33868800 / (75 * ((Mode & MODE_SPEED) ? 2 : 1)) + 
CalcSeekTime(CurSector, SeekTarget, DriveStatus != DS_STOPPED, DriveStatus == 
DS_PAUSED);

Bug#930463: mednafen: potential unchecked memory access in the Lynx emulator

[Stephen Kitt]

Package: mednafen
Version: 0.9.41+dfsg-2+b1
Severity: serious
Tags: patch security
Justification: security

Dear Maintainer,

(Note for the security team: this has been published in the 1.22.2
upstream release. I’m not aware of any exploit for this issue. This is
qualified as a potential security issue by upstream, hence the
“serious” severity rather than grave. The patch applies to both the
Stretch and Buster versions.)

Upstream fixed a potential unchecked memory access in the Lynx
emulator in the latest release of Mednafen; the attached patch fixes
it.

Regards,

Stephen


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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mednafen depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  libmpcdec62:0.1~r495-1+b1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libsndfile1   1.0.27-3
ii  libstdc++66.3.0-18+deb9u1
ii  libtrio2  1.16+dfsg1-3+b2
ii  libvorbisidec11.0.2+svn18153-1+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mednafen recommends:
ii  mednaffe  0.8.4-1+b1

mednafen suggests no packages.

-- no debconf information
diff -rupN 1.22.1/src/lynx/ram.h 1.22.2/src/lynx/ram.h
--- 1.22.1/src/lynx/ram.h   2019-01-27 22:52:37.0 -0800
+++ 1.22.2/src/lynx/ram.h   2019-04-23 14:54:58.0 -0700
@@ -65,8 +65,8 @@ class CRam : public CLynxBase
 
voidReset(void) MDFN_COLD;
 
-   voidPoke(uint32 addr, uint8 data){ mRamData[addr]=data;};
-   uint8   Peek(uint32 addr){ return(mRamData[addr]);};
+   voidPoke(uint32 addr, uint8 data){ 
mRamData[(uint16)addr]=data;};
+   uint8   Peek(uint32 addr){ return(mRamData[(uint16)addr]);};
uint32  ReadCycle(void) {return 5;};
uint32  WriteCycle(void) {return 5;};
uint32   ObjectSize(void) {return RAM_SIZE;};
diff -rupN 1.22.1/src/lynx/susie.cpp 1.22.2/src/lynx/susie.cpp
--- 1.22.1/src/lynx/susie.cpp   2019-01-27 22:52:37.0 -0800
+++ 1.22.2/src/lynx/susie.cpp   2019-04-23 14:54:58.0 -0700
@@ -58,13 +58,9 @@
 // wa can access this directly without the hassle of
 // going through the system object, much faster
 //
-//#define RAM_PEEK(m)  (mSystem.Peek_RAM((m)))
-//#define RAM_POKE(m1,m2)  (mSystem.Poke_RAM((m1),(m2)))
-//#define RAM_PEEKW(m) (mSystem.PeekW_RAM((m)))
-
-#define RAM_PEEK(m)(mRamPointer[(m)])
-#define RAM_PEEKW(m)   
(mRamPointer[(m)]+(mRamPointer[(m)+1]<<8))
-#define RAM_POKE(m1,m2){mRamPointer[(m1)]=(m2);}
+#define RAM_PEEK(m)(mRamPointer[(uint16)(m)])
+#define RAM_PEEKW(m)   
(mRamPointer[(uint16)(m)]+(mRamPointer[(uint16)((m)+1)]<<8))
+#define RAM_POKE(m1,m2)
{mRamPointer[(uint16)(m1)]=(m2);}
 
 uint32 cycles_used=0;
 
@@ -838,7 +834,7 @@ uint32 CSusie::PaintSprites(void)
 
 INLINE void CSusie::WritePixel(uint32 hoff,uint32 pixel)
 {
-uint32 scr_addr=mLineBaseAddress+(hoff/2);
+const uint16 scr_addr=mLineBaseAddress+(hoff/2);
 
 uint8 dest=RAM_PEEK(scr_addr);
 if(!(hoff&0x01))
@@ -861,7 +857,7 @@ INLINE void CSusie::WritePixel(uint32 ho
 
 INLINE uint32 CSusie::ReadPixel(uint32 hoff)
 {
-uint32 scr_addr=mLineBaseAddress+(hoff/2);
+const uint16 scr_addr=mLineBaseAddress+(hoff/2);
 
 uint32 data=RAM_PEEK(scr_addr);
 if(!(hoff&0x01))
@@ -883,7 +879,7 @@ INLINE uint32 CSusie::ReadPixel(uint32 h
 
 INLINE void CSusie::WriteCollision(uint32 hoff,uint32 pixel)
 {
-uint32 col_addr=mLineCollisionAddress+(hoff/2);
+const uint16 col_addr=mLineCollisionAddress+(hoff/2);
 
 uint8 dest=RAM_PEEK(col_addr);
 if(!(hoff&0x01))
@@ -906,7 +902,7 @@ INLINE void CSusie::WriteCollision(uint3
 
 INLINE uint32 CSusie::ReadCollision(uint32 hoff)
 {
-uint32 col_addr=mLineCollisionAddress+(hoff/2);
+const uint16 col_addr=mLineCollisionAddress+(hoff/2);
 
 uint32 data=RAM_PEEK(col_addr);
 if(!(hoff&0x01))
diff -rupN 1.22.1/src/lynx/sysbase.h 1.22.2/src/lynx/sysbase.h
--- 

Bug#930462: ERROR: unable to download video data: HTTP Error 403: Forbidden

[Arnaud Fontaine]

Package: youtube-dl
Version: 2019.01.17-1.1
Severity: grave

Hi,

I get  this error when  trying to download  videos from youtube.  Updating the
package to 2019.06.08 fixes the issue.

Cheers,
Arnaud Fontaine

Bug#930461: RFS: ddupdate/0.6.3-1

[Alec Leamas]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ddupdate
   Version : 0.6.3-1
   Upstream Author : Alec leamas
 * URL : https://github.com/leamas/ddupdate
 * License : MIT
   Section : net

It builds those binary packages:

  ddupdate - Tool updating DNS data for dynamic IP addresses

To access further information about this package, please visit:

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

Alternatively, one can download the package with dget:

dget -x
https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.3-1.dsc

More info: https://github.com/leamas/ddupdate

Changes since the last upload:

  ddupdate (0.6.3-1) sid; urgency=medium
*  New upstream release
*  Bump Standards-Version

-- Alec Leamas