Bug#964741: [Pkg-javascript-devel] Bug#964741: node-node-sass: embeds code copy of sass-spec

[merkys]

Hello,

On 2020-07-09 23:03, Jonas Smedegaard wrote:
> If sass-spec as packaged for Debian is unsuitable for node-node-sass,
> then please file bugreport(s) against that other package
> clarifying what is needed/broken.

nodejs package node-sass-spec is not built from sass-spec source
currently. I have filed #964758 for that.

Best,
Andrius

Bug#964758: sass-spec: package node-sass-spec

[merkys]

Source: sass-spec
Control: block 964741 by -1

Binary nodejs package node-sass-spec could be built from the sass-spec
source package. As node-sass-spec is already embedded in at least one
Debian package (node-node-sass), please package node-sass-spec in order
to deduplicate the code.

Andrius

Bug#964723: Ordering of entries: the calibre opens everything problem

[Charles Plessy]

Hi Enrico,

thanks a lot for your email, you are touching something important.

Frankly speaking, mailcap is old.  We are therefore stuck in a state
where changing it is very difficult and involves taking decisions that
are very "cleaving".  What is our priority: portability ? compatibility ?
ability to run on extermely low-powered processors ?  Or are we ready
to rewrite it, to innovate, to make major changes that may not be
adopted by other distros, to replace it by something entirely different ?

My own take on that problem is to make it "optional" instead of
"standard", so that people can develop alternatives, or try to entirely
live without it (probably using XDG as a replacement).

One problem is that the mime-support ships /etc/mime.types, which is
needed by many programs beyond the mailcap system.  I proposed to move
it to base-files and the answer was "I don't think it would be a good
idea".  So maybe we need a mime.types package, priority standard, that
contains this single file.  Or maybe you can help me to make Santiago
change his mind.  http://bugs.debian.org/787571

Second problem: I proposed on debian-devel to make mailcap optional in
2019 and the only answer I got was: "I don't really see a benefit to this."
https://lists.debian.org/debian-devel/2019/08/msg00306.html
Frankly speaking, this makes me fear that resistance can spark after I
would have invested my time in working on it.

(I also proposed to hijack /usr/bin/open so that Mac users would feel
at home, but as you can guess, the answer was kind of "no", or more
precisely: wait 5 years before seing it happen.  Actually, I wish I had
done it. https://lists.debian.org/debian-devel/2014/04/msg00822.html)

In summary, I think xdg-open could be the standard default on all
systems even if they do not have a Destkop environment installed.
Actually, xdg-open falls back on mailcap in these cases and I think that
a bunch of tools are already calling xdg-open directly.  So we would
need a tool that draws information from /usr/share/applications instead
of /usr/lib/mime, and voilà we would just have to make xdg-open aware
of it.

Thanks again for your thoughts; it is long overdue that the mailcap
systems evolves and at least stops standing in the way of change.  If I
can count on your support and on Debian's benevolence, I am more than
happy to push major changes.

Have a nice week-end,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#937009: mercurial switch to python3 in debian unstable - July 16th, 2020

[Sandro Tosi]

Hello,
this email is to inform the maintainers of the reverse dependencies of
mercurial of the plan to upload to unstable the python3 version next
Thursday. We want to be extra-safe with the switch, hence this email.

In To: to this email the maintainers mailing list + key other MLs and
addresses, in Bcc: the real people listed in Maintainer/Uploaders of
the involved packages, apologies if you received more than 1 copy of
it.

The full list of the packages, as produced by dak, is available at the
bottom of this email.

There has been a test rebuilt, via ratt, as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937009#142 and it
doesnt look like there's any failure in the build process due to the
switch (except for meson, which indirectly build-depends on python2
without listing it).

Mercurial is also used as part of the normal operation of a program,
and that cannot be tested automatically, nor via a rebuild. The
python3 version of mercurial is available in experimental
(5.4.1-1+exp1); if you could test it against your package to make sure
it works as you intended, that would help the transition.

Mercurial has an extensive test suite, which passes 100% with python3,
so we dont expect any failure while using the `mercurial` command, but
some interfaces/operations may have changed.

If we dont hear otherwise, we plan to upload the python3 version of
mercurial in unstable on or around next Thursday, July 16th.

This effort will greatly benefit the broader effort of py2removal, by
allowing the chain removal of several other packages.

Regards,
Sandro


$ dak rm -Rn mercurial
Will remove the following packages from unstable:

 mercurial |5.4.1-1 | source, amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
mercurial-common |5.4.1-1 | all

Maintainer: Python Applications Packaging Team


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
git-remote-hg: git-remote-hg
hg-git: mercurial-git
hgsubversion: hgsubversion
mercurial-buildpackage: mercurial-buildpackage
mercurial-crecord: mercurial-crecord
mercurial-extension-utils: mercurial-extension-utils
mercurial-keyring: mercurial-keyring
python-hgapi: python3-hgapi
python-hglib: python3-hglib
sphinx-patchqueue: python-sphinx-patchqueue

# Broken Build-Depends:
check-manifest: mercurial
composer: mercurial
devpi-common: mercurial
git-remote-hg: mercurial
golang-github-masterminds-vcs-dev: mercurial
haskell-filestore: mercurial
hg-git: mercurial (>= 4.8~)
hgsubversion: mercurial (>= 5.2-1~)
jags: mercurial
meson: mercurial
pepper: mercurial
python-hgapi: mercurial
python-hglib: mercurial (>= 1.9)
reposurgeon: mercurial
ros-rosinstall: mercurial
ros-vcstools: mercurial
ros-wstool: mercurial
setuptools-scm: mercurial

Dependency problem found.

Bug#964755: i3: Memory leak consumes all available memory

[Gabriel Krisman Bertazi]

Michael Stapelberg  writes:

> Is this fixed with commit
> https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0
> already (not yet released)? Or are we talking about a separate leak?

I'm not sure. I wasn't aware of this commit but it sounds very
promising.  Let me give it some test and report back.

-- 
Gabriel Krisman Bertazi

Bug#964755: i3: Memory leak consumes all available memory

[Michael Stapelberg]

Is this fixed with commit
https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0
already (not yet released)? Or are we talking about a separate leak?

On Fri, Jul 10, 2020 at 3:03 AM Gabriel Krisman Bertazi
 wrote:
>
> Package: i3
> Version: 4.18-1
> Severity: important
>
> Dear Maintainer,
>
> I've seen my xorg grow in memory usage through the course of the day,
> until it consumes all RAM available and starts swapping, even when the
> machine is left idle.  This is 100% reproducible on my system, after
> killing X and restarting it, it starts to eat memory again.
>
> I'm reporting this against i3 instead of xorg, because I found other
> Debian derivative users reporting this issue against i3, and it doesn't
> seem to reproduce on other X based WM.
>
> I reproduced this on a machine after a fresh install of bullseye, with
> the package version below.
>
> In my system, it is taking around 1 day to fill up 10GB of RAM.
>
> I'm happy to apply patches and test packages you provide to help debug
> this.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3 depends on:
> ii  i3-wm  4.18-1
>
> Versions of packages i3 recommends:
> ii  dunst   1.4.1-1
> ii  i3lock  2.11.1-1
> ii  i3status2.13-3
> ii  suckless-tools  45-1
>
> i3 suggests no packages.
>
> -- no debconf information



-- 
Best regards,
Michael

-- 
Best regards,
Michael

Bug#964558: Please change the ibus Recommends in ibus-data to a Suggests

[Osamu Aoki]

Gunnar

On Wed, 2020-07-08 at 18:09 +0200, Gunnar Hjalmarsson wrote:
> Package: src:ibus
> Version: 1.5.22-5
> I would suggest that "Recommends: ibus" in ibus-data is replaced
> with "Suggests: ibus".

I think what you suggest seems to be a reasonable fix to the current
excessive package pull-in situation.  (But it may cause some issue ...
see below)

This ibus-data is a new data only package for emoji and a few static
data.  If any external binary executable ZZZ accesses this data, it is
a bad idea for ibus-data to recommend an executable package which may
not be of interest of ZZZ.  (ZZZ being emoji picker under KDE in this
case)

This reminded me to check current package dependency chain and package
split situation of src:ibus.

The binary ibus (bin:ibus) package has a few aspects:

 * the key entry point of package dependency chain to access ibus
   related binaries (libraries)
 * provider of 3 key executable components.
* XIM support daemon: ibus-daemon (ibus as a wrapper)
* ibus set up utility: ibus-setup (ibus-ui-gtk3)
* Emoji picker: ibus-ui-emojier  (ibus as a wrapper)

Making "Suggests: ibus" will cause lack of access to ibus-ui-emojier
for KDE.  Is this what they wants?  (Maybe not ... please check if
"ibus emoji" command access requirement under KDE)

Maybe it is time to re-organize ibus package splits.

Modern keyboard input path is provided to most application binaries via
GTK library or QT applications (not via XIM).

GNOME DE doesn't require daemon in bin:ibus but depends on bin:libibus-
1.0-5 via gnome-shell.  In other word, under Debian Default
GNOME/Wayland ibus-daemon is not really needed to have a functional
system. (Excluding uxterm/Rxvt for CJK.  We have many GTK/QT terminals)
The same will be true for KDE.

GNOME DE seems to use its own "ibus-setup" equivalent in javascript and
doesn't use ibus-setup in bin:ibus.

GNOME DE also seems to use its own "ibus emoji" equivalent, too.  So
emoji related binary in bin:ibus isn't used, maybe ... 

Since Wayland doesn't offer xkb to support non-ASCII character input
support,  ibus-infrastructure seems to support it with data in ibus-
data such as /usr/share/ibus/component/simple.xml.  If ibibus-1.0-5
uses any part of this new ibus-data package changing dependency as
following may be an idea.  (I am not sure)

 * Replace "Recommends: ibus" in ibus-data with "Suggests: ibus".
 * Drop "Depends: ibus-data" in ibus.
 * Add "Depends: ibus-data" in libibus-1.0-5.

Please note
 ibus --(depends)--> gir1.2-ibus-1.0 --(depends)--> libibus-1.0-5 

Osamu

Bug#870641: screen stays off after light-locker locked it and no way to turn it back on

[Aaron Lu]

buster, light-locker 1.8.0-3

how to reproduce:
1 under xfce, lock the screen;
2 the display turned off
3 when I need to use it, pressing keyboard or moving mouse will not turn
  the screen back on.

I have this problem on both my laptop(which has a single integrated
intel card and my desktop which has an integraed intel card and an
additional ati card).

Workarounds for me:
1 Blindly type my password and hit enter and the screen will be back on
  with unlocked desktop - not ideal but usable.
2 hit ctrl-alt-f1(actually, any of f1-f7) will turn the screen back on
  and then press ctrl-alt-f8 will show me the lock screen and I can type
  my password there and unlock.

Hopefully this little problem can be solved. Thanks.

Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)

[gregor herrmann]

On Thu, 09 Jul 2020 18:42:23 +0300, Boian Bonev wrote:

> > It's not enabled by default, but you can add
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
> > to debian/rules to add the flag.
> -export LDFLAGS=-Wl,-z,now $(shell dpkg-buildflags --get LDFLAGS)
> +export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
> 
> Looks much cleaner in this way.

Great.
 
> > But I guess in this case a Breaks would be more appropriate than a
> > Conflicts.
> > Cf. 7.3 and 7.4 in Debian Policy
> > https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
> > ff.
> I have changed Conflicts to Breaks+Replaces and it seems to work OK.
> Because both packages would install the same file, only Breaks wouldn't
> do, IMO, correct me if I am worng.

Right, if a file is taken over, an additional Replaces is indeed
needed; good catch.
  
> > Well, you could write an autopkgtest :)
> > Cf. https://ci.debian.net/doc/file.MAINTAINERS.html ,
> > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
> > etc.
> > (But IMO that's not required for a first upload.)
> Writing a good test is quite far from trvial for this program. I will
> need some scartch space to write files to, run couple of processes that
> do IO in the scratch area according to some predefined pattern, collect
> the data via iotop (needs root) in batch mode and verify if the
> collected data matches the expected pattern... I would estimate that as
> about 2x the complexity of iotop itself.

Ack, I totally see that this is a non-trivial task in this case.
Maybe something to keep in the back of your mind for long dark winter
nights :)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Cat Stevens: Girl, You'll Be A Woman Soon


signature.asc
Description: Digital Signature

Bug#964757: python-pebble: why is this package under "Debian GCC Maintainers"?

[Sandro Tosi]

Source: python-pebble
Severity: minor

Hello,
why is this package maintained under "Debian GCC Maintainers" and not DPMT? it
seems like it's a better fit no?

Regards,
Sandro


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

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

Bug#917095: python3-pyfftw: alignment tests fail on several arches

[Drew Parsons]

On 2020-07-10 02:55, Thorsten Glaser wrote:



...

This still fails, even on x32, which is an x86 architecture õÕ


I’ve commented upstream. The funniest thing is that, when I run
the test that fails inside the build chroot, manually, (just with
more debugging output) it passes!

https://github.com/pyFFTW/pyFFTW/issues/128#issuecomment-656290711

I therefore propose to skip the problematic tests on most
architectures.

Another interesting difference is that the build has 2 failues
whereas my local build has 12 so the binary build might be
dependent on the system it was built on, which is… dangerous,
and, for a binary distribution, obviously inappropriate.



It's tricky problem to resolve.  Let's encourage upstream to take up a 
guest account on our Debian test machines so he can probe directly.


In the mean time I can skip tests as a work-around, and see if problems 
show up in actual usage.


Drew

Bug#962304: amazon-ecr-credential-helper includes no documentation

[Karp, Samuel]

Control: tags -1 + pending

Bug#964756: v4l-utils: please consider using clang in arch:all part only

[Thorsten Glaser]

Hi!

I’ve been looking into this again, due to M-A version skew.

According to the build log, clang is used for bpf_protocols only;
this seems to be architecture-independent.

Because clang isn’t available on every Debian architecture, especially
new ones, but src:v4l-utils is deep inside dependency chains and thus
needs to be available for things to even build, this is… unsatisfactory.

Could you extract bpf_protocols from src:v4l-utils so that the bpf
target code is generated as part of an arch:all build?

I see three ways for this:

Either it’s generated in build-indep of src:v4l-utils and shipped as
arch:all data package which is used at runtime by the components that
need it.

Or it’s extracted from src:v4l-utils into another package, whose
arch:all build result contains it and then becomes a Build-Depends
of src:v4l-utils which copies it instead of rebuilding it.

Or, perhaps, src:v4l-utils produces an arch:all package from its
build-indep that contains the output, and Build-Depends-Arch on
_that_ (so the arch:any build build-depens on the output of the
arch:all build, requiring a split build, but that’s possible in
Debian nowadays, AFAICT) and takes the build results from there.

Update, just before actually sending the mail (BTS clone takes
a few minutes): I see that the bpf files *are* already installed
and dynamically loaded (/lib/udev/rc_keymaps/protocols), so just
splitting an arch:all package ir-keytable-common from ir-keytable
that contains them and making sure the arch:any build will still
let the binary contain the bpf loader would do the trick.

Thanks for your consideration,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#964755: i3: Memory leak consumes all available memory

[Gabriel Krisman Bertazi]

Package: i3
Version: 4.18-1
Severity: important

Dear Maintainer,

I've seen my xorg grow in memory usage through the course of the day,
until it consumes all RAM available and starts swapping, even when the
machine is left idle.  This is 100% reproducible on my system, after
killing X and restarting it, it starts to eat memory again.

I'm reporting this against i3 instead of xorg, because I found other
Debian derivative users reporting this issue against i3, and it doesn't
seem to reproduce on other X based WM.

I reproduced this on a machine after a fresh install of bullseye, with
the package version below.

In my system, it is taking around 1 day to fill up 10GB of RAM.

I'm happy to apply patches and test packages you provide to help debug
this.

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

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

Versions of packages i3 depends on:
ii  i3-wm  4.18-1

Versions of packages i3 recommends:
ii  dunst   1.4.1-1
ii  i3lock  2.11.1-1
ii  i3status2.13-3
ii  suckless-tools  45-1

i3 suggests no packages.

-- no debconf information

Bug#962574: ITP: dephell -- project management for Python

[Nicholas D Steeves]

Hi Scott, devel, and Python team,

Nicholas D Steeves  writes:

> Control: block -1 by 962574
>
> Tomlkit seems to be required for self-tests.
>

Thank you for taking care of tomlkit so quickly!  I wish I had more time
and energy to make faster progress with DepHell.  Today I discovered it
appears to require packaging 14 dephell-.* modules, listed here:

  https://pypi.org/search/?q=dephell

so it's going to be a while (months) before I complete this ITP (which
blocks my solution for converting pyproject.toml to setup.py for fissix
and thus Bowler).  If anyone would like to help out with the dephell-.*
dependencies to speed this process along, please go ahead, and let me
know if you'd like a comaintainer/second Uploader.  Failing that, I'll
get to it as soon as I can :-)

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#964754: debhelper: inconsistent handling of wildcards in output from executable debhelper config files

[Andreas Beckmann]

Package: debhelper
Version: 13.2
Severity: normal

Wildcards work in executable "install" files, but not in executable "docs" 
files.

debhelper(7) says:

Otherwise, the output will be used exactly as-is.  Notably, debhelper will
not expand wildcards or strip comments or strip whitespace in the output.

dh_install is probably an exception and globbing works because it's done later:

  @install=filedoublearray($file); # no globbing here; done below

while dh_installdocs does it immediately (which is skipped on executable $file):

  @docs = filearray($file, \@search_dirs, $error_handler);

I'm not sure if not expanding wildcards in executable "docs" etc. is a good
idea, since it prevents one from using something like

  #!dh-exec
  docs/*
  docs-arm/* [arm64]

tiny example package attached:

$ fakeroot debian/rules binary 
dh binary
   dh_update_autotools_config
   dh_autoreconf
   create-stamp debian/debhelper-build-stamp
   dh_testroot
   dh_prep
   dh_install
   dh_installdocs
cp: cannot stat 'doc/*': No such file or directory
dh_installdocs: error: cp --reflink=auto -a doc/\* 
debian/dhtest/usr/share/doc/dhtest returned exit code 1
make: *** [debian/rules:3: binary] Error 1

chmod -x debian/docs and it's fine ...


Andreas

PS: This limitation seems to be very vague:

   Substitution limits
   To avoid infinite loops and resource exhaustion, debhelper will stop 
with an error
   if the text contains many substitution variables (50) or [...]

Is that
- 50 distinct variables?
- 50 substitutions per line in the input?
- 50 substitutions in total? (What about large files with 100 lines with 
${DEB_HOST_MULTIARCH}?)
- something different?

Andreas


dhtest.tar.gz
Description: application/gzip

Bug#964753: ITP: r-cran-conquer -- GNU R package for convolution-type smoothed quantile regression

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-conquer
  Version : 1.0.1
  Upstream Author : Xuming He, Xiaoou Pan, Kean Ming Tan, and Wen-Xin Zhou
* URL or Web page : https://cran.r-project.org/package=conquer
* License : GPL-3
  Description : GNU R package for convolution-type smoothed quantile 
regression

This package is now a (Build-)Depends of r-cran-quantreg which has been in
Debian since 2014.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))

[Yunqiang Su]

On Mon, 11 May 2020 13:15:23 +0100 Simon McVittie  wrote:
> Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed: 
> t1.y0.approx_eq(t2.y0, (epsilon, 1))
> Control: severity -1 wishlist
> Control: tags -1 + confirmed wontfix
> Control: notforwarded -1
> 
> On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote:
> > On 2020-05-06 11:19, Simon McVittie wrote:
> > > There seems to be a strong correlation where this test passes on a Rhino
> > > Labs UTM8 but fails on a Loongson 3A. Are there known issues with
> > > Loongson 3A hardware, or is there different FPU behaviour, or something?
> > 
> > Thanks for the analysis. Yep the Loongson 3A is known for having an FPU
> > bug that could explain that behaviour. Basically it treats the madd,
> > msub, nmadd and nmsub instructions as fused while they should not.
> 
> It seems strange to me that a release architecture is using
> known-to-be-faulty hardware for buildds. Is there any possibility of
> replacing those machines, or taking them out of the buildd rotation
> entirely?
> 
> In particular, we treated this as a RC bug, and prioritized reporting
> it upstream; but we should not be wasting upstreams' time with issues
> that are a result of faulty hardware. I don't think we can expect every
> package maintainer, or every upstream maintainer, to know that Debian's
> mips*el buildds have this bug and that failing build-time tests that
> touch floating-point are likely to be not a real bug in the software.
> 
> At the same time, I don't want to disable build-time tests or ignore
> their results, because for most architectures they are the only evidence
> we have that a package works at all.
> 
> > I am going to blacklist librsvg from the Loongson 3A based buildds so
> > that it doesn't happen again.
> 
> Thanks. I'll add a check to d/rules to make the build fail sooner if a
> Loongson-3A CPU is detected (when not building with nocheck), to make
> sure this blacklisting mechanism doesn't regress.

For gcc, we patched it to not use madd.fmt. We should so the same thing to llvm.
Let’s do it.

> 
> smcv
> 
> 

Bug#964730: ITP: gpsshogi -- Shogi playing program based on OpenShogiLib

[Paul Wise]

On Thu, Jul 9, 2020 at 4:18 PM Yann Dirson wrote:

> This is rather an Intent to Resurrect, as gpsshogi was in Debian
> 2 releases ago.

Please note the extra steps needed when reintroducing packages,
principally reopening the bugs that were closed by the removal of the
package from Debian.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#964728: gtk-doc-tools: gtkdoc-scangobj fails in mipsel / Loongson when building webkit2gtk

[YunQiang Su]

 于2020年7月10日周五 上午12:28写道：
>
> On Thu, 09 Jul 2020 at 17:42:35 +0200, Alberto Garcia wrote:
> > the mipsel build of webkit2gtk is failing because of gtkdoc-scangobj:
> ...
> > This is only happening on the mipsel builds, and I cannot reproduce
> > the problem in eller.debian.org. Adrian Bunk says it fails on the
> > Loongson buildds but succeeds on the others.
>
> gtkdoc-scangobj works by compiling a small C program that it uses
> to introspect GObject types. According to the build log, that program
> exited with status -6 (which is probably Python's representation of it
> being killed by signal 6, which is SIGABRT?) with no output.

I will have a try to debug it.

>
> The Loongson 3A "is known for having an FPU bug" (see #959845) -

Because we have no choice...
The only two type of mips64el machines that we can purchase are Loongson
and Cavium. Both of them have some (different) bugs.

And in fact the most of users of mips64el port are using Loongson.
We are working on replace the real old Loongson 3A 1000 machines with 3000.
3000 may has less (but not none) bugs.

> perhaps that could be related, if webkit2gtk contains GObject types
> with G_TYPE_FLOAT or G_TYPE_DOUBLE values? I'm not sure what individual
> packages can do about this, or why we are using known-faulty CPUs on
> official buildds.
>
> This is likely to be "won't fix" (or rather "can't fix") for
> gtk-doc-tools, unless someone with a suitably faulty FPU can reproduce
> the bug and figure out what is going on.
>
> Workaround: instead of
>
> 8<
> ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
> EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF
> else
> EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON
> endif
> 8<
>
> webkit2gtk could use something like
>
> 8<
> binaries := $(shell dh_listpackages)
>
> ifneq (,$(filter %-doc,$(binaries)))
> EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF
> else
> EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON
> endif
> 8<
>
> together with
>
> 8<
> Package: libwebkit2gtk-4.0-doc
> Build-Profiles: 
> 8<
>
> so that you don't run gtk-doc in architecture-specific builds, only in
> builds that include Architecture: all. That would also be faster, and you
> might be able to move gtk-doc-tools from Build-Depends to
> Build-Depends-Indep (usually you can for Meson, but not for Autotools
> because it's needed at dh_autoreconf time; I don't know which category
> CMake falls into).
>
> smcv
>


-- 
YunQiang Su

Bug#964752: RFP: gosop -- Stateless OpenPGP command-line interface (Go)

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: gosop
  Version : 0.17.0
  Upstream Author : Proton Technologies AG 
* URL : https://github.com/ProtonMail/gosop
* License : MIT
  Programming Lang: Go
  Description : Stateless OpenPGP command-line interface (Go)

This package contains a Go-based implementation of the Stateless
OpenPGP command-line interface, aka "sop".  It is useful as a
minimalist utility, and as a component in test suites and other
OpenPGP-based verification tools.

Its command-line binary is named "gosop".

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

Getting this into debian would make it easier to run OpenPGP
interoperability testing, and would encourage feedback and development
between different OpenPGP implementors.

--dkg


signature.asc
Description: PGP signature

Bug#963561: ITP: eclipse-wtp -- Eclipse Web Tools Platform

[tony mancill]

On Thu, Jul 09, 2020 at 11:22:16AM +0100, Sudip Mukherjee wrote:
> Hi All,
> 
> On Tue, Jun 23, 2020 at 07:50:17PM +0100, Sudip Mukherjee wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sudip Mukherjee 
> > Control: block 943552 by -1
> > 
> > * Package name: eclipse-wtp
> 
> So, one of the plugin has the name:
> org.eclipse.wst.common.emfworkbench.integration which generates a package:
> libeclipse-wst-common-emfworkbench-integration-java and lintian is giving
> a warning about "very long filename".
> What is the preferred solution for this? Can I rename the plugin to:
> org.eclipse.wst.common.emfworkbench ? or just ignore the lintian warning?

In my opinion, you should prefer consistent naming and ignore (or
override) the lintian warning.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#964259: Info received (Bug#964259: Acknowledgement (libseccomp2 upgraded from 2.4.1-0ubuntu0.18.04.2 => 2.4.3-1ubuntu3.18.04.2 , logwatch service stopped))

[Private]

An update - closing this "bug" report

My apologies for wasting your time but the failure of the logwatch custom setup 
for msmtp on July 2 had nothing to do with Debian or any upgrades.

The date format used by msmtp for their logs uses a leading 0 (zero) for days 
with single digits whereas the standard syslog date format uses a leading blank.

As long as the day was double digit (I installed the custom setup on June 15 so 
all dates were good until June 309) logwatch properly found the relevant dates. 
 But when, on July 2, logwatch tried to process the July 1 report, it could 
find no matching dates for "yesterday" and therefore did not report any 
activity for msmtp.

Problem now fixed and Debian had nothing to do with it.

R

-Original Message-
From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org] 
Sent: July 5, 2020 9:51 AM
To: priv...@ayuda.ca
Subject: Bug#964259: Info received (Bug#964259: Acknowledgement (libseccomp2 
upgraded from 2.4.1-0ubuntu0.18.04.2 => 2.4.3-1ubuntu3.18.04.2 , logwatch 
service stopped))

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Kees Cook 

If you wish to submit further information on this problem, please
send it to 964...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
964259: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964259
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#963024: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u2

[Joachim Falk]

Hi Adam,

Am 09.07.20 um 21:44 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
>
> [SNIP]
>
> Please go ahead.

I just have uploaded tigervnc/1.9.0+dfsg-3+deb10u2 to proposed-updates.

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#960969: sbuild: fail to work in unshare mode

[Johannes Schauer]

Hi,

On Mon, 18 May 2020 23:29:49 +0200 Aurelien Jarno  wrote:
> I have tried to get sbuild working in unshare mode. Here are the steps I
> have followed, from what I understood they should be sufficient:
> 
> sudo sysctl kernel.unprivileged_userns_clone=1
> sbuild-createchroot --chroot-mode=unshare --make-sbuild-tarball 
> ~/.cache/sbuild/sid-amd64.tar.gz sid `mktemp -d` http://deb.debian.org/debian/
> sbuild -d sid hello
> 
> The last step is unsuccessful, it seems to fail to execute any comment.
> I have attached the output of the last command running with debug in
> case it could help.

this sounds very similar to what is described in #950684 which is now
(hopefully) fixed in git. I never got to reproduce #950684 on my own system and
similarly, I also am unable to reproduce your problem. Thus, it would be
helpful if you could clone the git repository and from the master branch
execute:

$ PERL5LIB=$(pwd)/lib bin/sbuild-createchroot --chroot-mode=unshare 
--make-sbuild-tarball ~/.cache/sbuild/sid-amd64.tar.gz sid `mktemp -d` 
http://deb.debian.org/debian/
$ PERL5LIB=$(pwd)/lib bin/sbuild --chroot-mode=unshare -d sid hello

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#962366: gajim crashes at startup

[debacle]

On 2020-07-09 23:03, Robert Pommrich wrote:
> Awesome WM started via LightDM. 

Could you try a different one just to confirm or rule out, that
it is related to your desktop environment? To my knowledge, the
package runs fine on XFCE and Gnome, at least. Thanks!

Bug#964750: hypercorn build-dependencies unsatisfiable in testing.

[peter green]

Package: hypercorn
Version: 0.9.4-1
Severity: serious
Tags: patch
Justification: rc policy "packages must be buildable within the same release"

hypercorn build-depends on python3-asynctest, which is built from the 
python-asynctest source
package.

According to bug 954554 python3-asynctest is incompatible with the version of 
python3 currently
in testing/unstable. A patch exists but according to discussion in that bug 
report it has been
rejected by both the upstream and the Debian maintainers of python-asynctest.

As a result the python-asynctest and hypercorn source packages (and their 
corresponding binary
packages) were autoremoved from testing on the 1st of June.

Unfortunately, due to a bug in the testing migration scripts* hypercorn 
re-entered testing on the
26th of June.

Bug 954554 had a link to an upstream patch for hypercorn to stop using, I 
applied the relavent parts
of said upstream patch to the Debian hypercorn package, updated the 
build-dependencies accordingly
and was able to succesfully build the package.

Alternatively the upstream change seems to be included in the latest upstream 
release of hypercorn,
so uploading that would be another option.

A debdiff is attached, I may upload this later as a team upload (I don't see 
how this patch can
affect runtime functionality but I'd still rather get a sanity check from 
someone who actually.
uses the package).

* see https://lists.debian.org/debian-release/2020/06/msg00375.html
diff -Nru hypercorn-0.9.4/debian/changelog hypercorn-0.9.4/debian/changelog
--- hypercorn-0.9.4/debian/changelog2020-04-17 11:36:29.0 +
+++ hypercorn-0.9.4/debian/changelog2020-07-09 19:51:28.0 +
@@ -1,3 +1,13 @@
+hypercorn (0.9.4-2) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Apply upstream patch to move away from asynctest and move towards
+the testing functionality in the standard library.
+  * Update build-depenencies, remove build-dependency on python3-asynctest
+and add build-dependency on python3-all-dev (>= 3.8.2-3) | python3-mock
+
+ -- Peter Michael Green   Thu, 09 Jul 2020 19:51:28 +
+
 hypercorn (0.9.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru hypercorn-0.9.4/debian/control hypercorn-0.9.4/debian/control
--- hypercorn-0.9.4/debian/control  2020-04-17 11:36:29.0 +
+++ hypercorn-0.9.4/debian/control  2020-07-09 19:51:28.0 +
@@ -14,7 +14,7 @@
  python3-priority,
  python3-toml,
  python3-typing-extensions,
- python3-asynctest,
+ python3-all-dev (>= 3.8.2-3) | python3-mock,
  python3-hypothesis,
  python3-pytest,
  python3-pytest-asyncio,
diff -Nru hypercorn-0.9.4/debian/patches/series 
hypercorn-0.9.4/debian/patches/series
--- hypercorn-0.9.4/debian/patches/series   1970-01-01 00:00:00.0 
+
+++ hypercorn-0.9.4/debian/patches/series   2020-07-09 19:46:12.0 
+
@@ -0,0 +1 @@
+update-testing.patch
diff -Nru hypercorn-0.9.4/debian/patches/update-testing.patch 
hypercorn-0.9.4/debian/patches/update-testing.patch
--- hypercorn-0.9.4/debian/patches/update-testing.patch 1970-01-01 
00:00:00.0 +
+++ hypercorn-0.9.4/debian/patches/update-testing.patch 2020-07-09 
19:51:18.0 +
@@ -0,0 +1,274 @@
+This patch is based on the upstream commit detailed below and was
+adapted to apply to the Debian hypercorn package by Peter Michael
+Green
+
+Specifically  changes to tox.ini and .gitlab-ci.yml were removed
+from the patch as those files do not  seem to exist in the Debian
+Hypercorn 0.9.4 Package.
+
+
+commit 80e2ad5db107c42d42471ea64764d2b42202349c
+Author: pgjones 
+Date:   Sun May 31 18:53:02 2020 +0100
+
+Update testing
+
+Switch from asynctest to the stdlib (with a backport as AsyncMock was
+introduced in 3.8) and update the base python versions to 3.8.
+
+diff --git a/setup.cfg b/setup.cfg
+index 3e4a8f0..36c4ad2 100644
+--- a/setup.cfg
 b/setup.cfg
+@@ -21,9 +21,6 @@ ignore_missing_imports = True
+ [mypy-aioquic.*]
+ ignore_missing_imports = True
+ 
+-[mypy-asynctest.*]
+-ignore_missing_imports = True
+-
+ [mypy-cryptography.*]
+ ignore_missing_imports = True
+ 
+diff --git a/setup.py b/setup.py
+index 5e4e461..392ef5a 100644
+--- a/setup.py
 b/setup.py
+@@ -25,8 +25,8 @@ INSTALL_REQUIRES = [
+ ]
+ 
+ TESTS_REQUIRE = [
+-"asynctest",
+ "hypothesis",
++"mock",
+ "pytest",
+ "pytest-asyncio",
+ "pytest-cov",
+diff --git a/tests/protocol/test_h11.py b/tests/protocol/test_h11.py
+index 3a635fa..eaef1dd 100755
+--- a/tests/protocol/test_h11.py
 b/tests/protocol/test_h11.py
+@@ -1,13 +1,12 @@
+ import asyncio
+ from typing import Any
+-from unittest.mock import call
++from unittest.mock import call, Mock
+ 
+ import h11
+ import pytest
+ from _pytest.monkeypatch import MonkeyPatch
+ 
+ import hypercorn.protocol.h11
+-from asynctest.mock import CoroutineMock, Mock as AsyncMock
+ from hypercorn.asyncio.tcp_server import EventWrapper
+ from hypercorn.config 

Bug#838907: network-manager-openvpn: Network Manager adds weird routes after connecting to OpenVPN

[Jan Korbel]

Hello.

Problem still exists in up-to-date unstable.

OpenVPN-in-OpenVPN is not working with Network manager. It works w/o Network 
manager
(if second tunnel started by openvpn init script).

First tunnel is "redirect-gateway def1", second without gw redirect.

Routes:

1. non working
nm - first tunnel to public_srv1
nm - second tunnel to public_srv2

Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 50 00 tun0
0.0.0.0 192.168.43.51   0.0.0.0 UG60000 wlan0
   192.168.43.51   255.255.255.255 UGH   60000 wlan0
   192.168.43.51   255.255.255.255 UGH   60000 wlan0 
--- PROBLEM
...
192.168.43.00.0.0.0 255.255.255.0   U 60000 wlan0
192.168.43.51   0.0.0.0 255.255.255.255 UH60000 wlan0
192.168.239.33  192.168.239.41  255.255.255.255 UGH   50 00 tun1
192.168.239.41  0.0.0.0 255.255.255.255 UH50 00 tun1
192.168.239.48  0.0.0.0 255.255.255.240 U 50 00 tun0

2. working
nm - first tunnel to public_srv1
openvpn - second tunnel to public_srv2

Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 50 00 tun0
0.0.0.0 192.168.43.54   0.0.0.0 UG60000 wlan0
   192.168.43.54   255.255.255.255 UGH   60000 wlan0
...
192.168.43.00.0.0.0 255.255.255.0   U 60000 wlan0
192.168.43.54   0.0.0.0 255.255.255.255 UH60000 wlan0
192.168.239.33  192.168.239.41  255.255.255.255 UGH   0  00 tun1
192.168.239.41  0.0.0.0 255.255.255.255 UH0  00 tun1
192.168.239.48  0.0.0.0 255.255.255.240 U 50 00 tun0

Regards,

JK

Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps

[Sandro Tosi]

Hello FTP Masters,

On Wed, Jun 24, 2020 at 11:57 PM Sandro Tosi  wrote:
>
> Package: ftp.debian.org
> Severity: normal
>
> cython has just been removed, and the remaining rdeps are not in testing as RC
> for other reasons, so let's not wait on them

can you please proceed with this removal? thanks!

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

Bug#962366: gajim crashes at startup

[Robert Pommrich]

On 9 July 2020 19:36:25 CEST, deba...@debian.org wrote:
>Control: tag -1 + moreinfo
>
>Do you try to run Gajim on X11 or on Wayland?
X11
>On which desktop environment and/or window manager?
>

Awesome WM started via LightDM. 

>Thank you!

Regards

Bug#964748: aufs: CVE-2020-11935

[Salvatore Bonaccorso]

Source: aufs
Version: 5.2+20190909-1.1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for aufs: CVE-2020-11935[0].

For Debian's kernel this is not directly an issue as CONFIG_IMA is not
enabled, see details in the tracker and the launchpad bugreport[1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-11935
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11935
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873074

Regards,
Salvatore

Bug#964740: debian-ports-archive-keyring 2019.11.05~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964740 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: debian-ports-archive-keyring
Version: 2019.11.05~deb10u1

Explanation: increase the expiration date of the 2020 key (84C573CD4E1AFD6C) by 
one year; add "Debian Ports Archive Automatic Signing Key (2021); move the 2018 
key (ID: 06AED62430CB581C) to the removed keyring

Bug#964736: ITP: public-inbox -- Mailing list archiver

[Uwe Kleine-König]

Hello Eric,

On 7/9/20 10:15 PM, Eric Wong wrote:
> Uwe Kleine-König  wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Uwe Kleine-König 
>>
>> * Package name: public-inbox
>>   Version : 1.5.0
>>   Upstream Author : Eric Wong  and others
>> * URL : https://www.public-inbox.org/
>> * License : AGPL-3.0
>>   Programming Lang: Perl
>>   Description : versatile mailing (list) archiver
>>
>> This software powers https://lore.kernel.org/ and also
>> http://www.public-inbox.org/ itself. It's the server-side counter part
> 
> +Cc: m...@public-inbox.org

The original mail should have been Cc:d already to there.

> Probably better to list https://public-inbox.org/hosted.html

noted.

> instead of its "homepage" as an example.  Also, no need for
> "www.", URLs with Message-IDs are long enough as they are and
> I'm unlikely to ever to want multiple IPs/hosts behind
> public-inbox.org.

I don't feel strong here. I doubt that the homepage field will be used
to create a Message-Id-Link from it.

>> for b4 that is already packaged in Debian.
>>
>> Currently I evaluate it to provide an archive for several work related
>> mailing lists.
>>
>> Depending on the outcome of this evaluation I might or might not actually
>> package public-inbox. But as deploying is easy using debian packages I
>> will create at least simple packaging which should at a minimum give a
>> good start for someone to pick up from me.
> 
> Great to hear.  I'm somewhat familiar with Debian packaging and
> debhelper, so I can help.

I already have a prototype at
https://salsa.debian.org/ukleinek/public-inbox

If you want to take a look ... I'm nearly sure the list of dependencies
is incomplete.

> Fwiw, I've been thinking about providing "make deb-pkg" and
> "make bindeb-pkg" targets (identical to what Linux kernel
> provides) for end users to build their own packages, too.  It
> would be non-intrusive to distro packagers (no "debian/"
> directory in VCS).

Here I also don't care much, I'd use the official package :-)

Thanks for your feedback
Uwe

Bug#960885: fdroidserver 1.1.7-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 960885 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fdroidserver
Version: 1.1.7-1~deb10u1

Explanation: fix Litecoin address validation

Bug#964747: libraw: CVE-2020-15503

[Salvatore Bonaccorso]

Source: libraw
Version: 0.19.5-1
Severity: important
Tags: security upstream
Control: found -1 0.19.2-2

Hi,

The following vulnerability was published for libraw.

CVE-2020-15503[0]:
| LibRaw before 0.20-RC1 lacks a thumbnail size range check. This
| affects decoders/unpack_thumb.cpp, postprocessing/mem_image.cpp, and
| utils/thumb_utils.cpp. For example,
| malloc(sizeof(libraw_processed_image_t)+T.tlength) occurs without
| validating T.tlength.

Note that for older versions we need to look at libraw_cxx.cpp
instead. The Red Hat report contains a backported patch which might
help. FWIW the issue is low, and does not need a DSA, but can be fixed
via a point release.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15503
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15503
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1853477

Regards,
Salvatore

Bug#963275: rust-structopt-derive: FTBFS: build-dependency not installable: librust-proc-macro-error-1+default-dev

[Daniel Kahn Gillmor]

On Sun 2020-06-21 21:50:35 +0200, Lucas Nussbaum wrote:
> Source: rust-structopt-derive
> Version: 0.4.8-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This was missing due to rust-proc-macro-error-attr being held in NEW,
which meant that rust-proc-macro-error could not be updated.

Now that r-p-m-e-attr is out of NEW, and rust-proc-macro-error 1.0.3 has
been uploaded to unstable, rust-structopt-derive should build fine.

 --dkg


signature.asc
Description: PGP signature

Bug#953621: Fix Python 3.8 file operations

[Eric Desrochers]

Dear maintainer,

May I suggest we (A) bump "sshuttle" to upstream release "1.0.2" and
take benefit of that to modernize the package to a let's say more modern dh
compat version, ... ?

Or at very least (B) cherry-pick the 3.8 fix[0] into Debian ?

This is highly impacting some Ubuntu users[1], and I'd like to see Debian
fixing it before I can proceed with Ubuntu.

Regards,
Eric

[0]-
https://github.com/sshuttle/sshuttle/commit/6c21addde97c4582b3dccb22bca64c33af3e5eff
[1] - https://launchpad.net/bugs/1873368

Bug#964725: texlive-latex-recommended: Package xparse (required for example via mdframed) gives Undefined control sequence

[Stefan Monnier]

>> An article I was working on started to throw me lots and lots of errors and 
>> not
>> generating any PDF when passed to `pdflatex` after the last upgrade of 
>> Texlive.
[...]
> https://tex.stackexchange.com/questions/550158/undefined-control-sequence-in-expl3
>
> says that it could be caused by a local format file sitting below
> ~/.texmf . Could you check?

Indeed I did

rm -rf ~/.texlive20*

and the problem's gone!  Thanks a lot!

This said, while I now have a solution for my own, I don't think
I should have to do that, so it'd be important to make sure this gets
fixed automatically (e.g. by using a fresh new ~/.texlive rather
than reusing one that may contain stale data, or by detecting the stale
data and removing it on-the-fly).


Stefan

Bug#964746: npm: CVE-2020-15095

[Salvatore Bonaccorso]

Source: npm
Version: 6.14.5+ds-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for npm.

CVE-2020-15095[0]:
| Versions of the npm CLI prior to 6.14.6 are vulnerable to an
| information exposure vulnerability through log files. The CLI supports
| URLs like "protocol://[user[:password]@]ho
| stname[:port][:][/]path". The password value is
| not redacted and is printed to stdout and also to any generated log
| files.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15095
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15095
[1] https://github.com/npm/cli/security/advisories/GHSA-93f3-23rq-pjfp
[2] https://github.com/npm/cli/commit/a9857b8f6869451ff058789c4631fadfde5bbcbc

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#964590: RFP: golang-goipp -- IPP core protocol implementation

[Didier 'OdyX' Raboud]

Le jeudi, 9 juillet 2020, 14.10:44 h CEST Roger Shimizu a écrit :
> I think both are done.
> The gits I pushed to salsa already can be built well.
> Maybe you can just add yourself to uploader and then upload to NEW queue.

Uploaded, thanks for your very kind assistance!

Best regards, OdyX

-- 
OdyX

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

Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)

[Santiago R . R .]

Package: lxc
Version: 1:3.1.0+really3.0.3-8
Severity: important

Dear Maintainer,

After creating an lxc container, I've manually set a MAC address for it.
The container fails to start, giving this output in the logs:

lxc-start container-name 20200709195149.256 ERRORnetwork - 
network.c:setup_hw_addr:2762 - Cannot assign requested address - Failed to 
perform ioctl
lxc-start container-name 20200709195149.256 ERRORnetwork - 
network.c:lxc_setup_netdev_in_child_namespaces:2907 - Failed to setup hw 
address for network device "eth0"
lxc-start container-name 20200709195149.256 ERRORnetwork - 
network.c:lxc_setup_network_in_child_namespaces:3047 - failed to setup netdev
lxc-start container-name 20200709195149.256 ERRORconf - 
conf.c:lxc_setup:3540 - Failed to setup network
lxc-start container-name 20200709195149.257 ERRORstart - 
start.c:do_start:1275 - Failed to setup container "container-name"
lxc-start container-name 20200709195149.257 ERRORsync - 
sync.c:__sync_wait:62 - An error occurred in another process (expected sequence 
number 5)
lxc-start container-name 20200709195149.258 ERRORlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:842 - Received container state 
"ABORTING" instead of "RUNNING"
lxc-start container-name 20200709195149.258 ERRORlxc_start - 
tools/lxc_start.c:main:330 - The container failed to start
lxc-start container-name 20200709195149.259 ERRORlxc_start - 
tools/lxc_start.c:main:333 - To get more details, run the container in 
foreground mode
lxc-start container-name 20200709195149.259 ERRORlxc_start - 
tools/lxc_start.c:main:336 - Additional information can be obtained by setting 
the --logfile and --logpriority options
lxc-start container-name 20200709195149.275 ERRORstart - 
start.c:__lxc_start:1951 - Failed to spawn container "container-name"

In the host I can see this:

...
Jul 09 19:53:42 olimicro audit[4788]: AVC apparmor="STATUS" 
operation="profile_load" profile="/usr/bin/lxc-start" 
name="lxc-container-name_" pid=4788 comm="apparmor_parser"
Jul 09 19:53:42 olimicro kernel: audit: type=1400 
audit(1594324422.794:57): apparmor="STATUS" operation="profile_load" 
profile="/usr/bin/lxc-start" name="lxc-container-name_" pid=4788 
comm="apparmor_parser"
Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered 
blocking state
Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered 
disabled state
Jul 09 19:53:42 olimicro systemd-udevd[4789]: link_config: 
autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 09 19:53:42 olimicro kernel: device vethETHNAME entered promiscuous 
mode
Jul 09 19:53:42 olimicro kernel: IPv6: ADDRCONF(NETDEV_UP): 
vethETHNAME: link is not ready
Jul 09 19:53:42 olimicro systemd-udevd[4789]: Using default interface 
naming scheme 'v240'.
Jul 09 19:53:42 olimicro systemd-udevd[4789]: Could not generate 
persistent MAC address for vethHP689N: No such file or directory
Jul 09 19:53:42 olimicro NetworkManager[935]:   [1594324422.8520] 
manager: (vethHP689N): new Veth device 
(/org/freedesktop/NetworkManager/Devices/37)
Jul 09 19:53:42 olimicro systemd-udevd[4790]: link_config: 
autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 09 19:53:42 olimicro kernel: eth0: renamed from vethHP689N
Jul 09 19:53:42 olimicro systemd-udevd[4790]: Using default interface 
naming scheme 'v240'.
Jul 09 19:53:42 olimicro sudo[4781]: pam_unix(sudo:session): session 
closed for user root
Jul 09 19:53:42 olimicro NetworkManager[935]:   [1594324422.9294] 
manager: (vethETHNAME): new Veth device 
(/org/freedesktop/NetworkManager/Devices/38)
Jul 09 19:53:43 olimicro audit[4795]: AVC apparmor="STATUS" 
operation="profile_remove" profile="/usr/bin/lxc-start" 
name="lxc-container-name_" pid=4795 comm="apparmor_parser"
Jul 09 19:53:43 olimicro kernel: audit: type=1400 
audit(1594324423.898:58): apparmor="STATUS" operation="profile_remove" 
profile="/usr/bin/lxc-start" name="lxc-container-name_" pid=4795 
comm="apparmor_parser"
Jul 09 19:53:44 olimicro kernel: br0: port 4(vethETHNAME) entered 
disabled state
Jul 09 19:53:44 olimicro kernel: device vethETHNAME left promiscuous 
mode
Jul 09 19:53:44 olimicro kernel: br0: port 4(vethETHNAME) entered 
disabled state
Jul 09 19:53:44 olimicro NetworkManager[935]:   [1594324424.5249] 
device (vethETHNAME): released from master device br0

To make the container work, I had to remove the lxc.net.0.hwaddr entry,
start the container and only then copy the autogenerated MAC address in
the config.

This happens on armv7l running buster. I haven't test a similar case on
other architecture nor testing/sid.



-- System Information:
Debian Release: 10.4
  APT prefers 

Bug#964744: test

[Santiago R.R.]

Package: lxc
Version: 1:4.0.2-1
Severity: important

./reportbug-lxc-20200709-4158-b5ttbb8r

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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.30-8
ii  libgcc-s1  10.1.0-4
ii  liblxc11:4.0.2-1
ii  lsb-base   11.1.0

Versions of packages lxc recommends:
ii  apparmor 2.13.4-3
ii  bridge-utils 1.6-3
ii  debootstrap  1.0.123
ii  dirmngr  2.2.20-1
ii  dnsmasq-base [dnsmasq-base]  2.81-4
ii  gnupg2.2.20-1
ii  iproute2 5.7.0-1
ii  iptables 1.8.5-2
ii  libpam-cgfs  1:4.0.2-1
ii  lxc-templates3.0.4-3
ii  lxcfs4.0.3-1
ii  nftables 0.9.6-1
ii  openssl  1.1.1g-1
ii  rsync3.2.2-1
ii  uidmap   1:4.8.1-1

Versions of packages lxc suggests:
pn  btrfs-progs  
ii  lvm2 2.03.07-1+b1
pn  python3-lxc  

-- debconf information excluded

Bug#964743: ITP: r-cran-gridtext -- GNU R improved text rendering support for 'Grid' graphics

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gridtext -- GNU R improved text rendering support for 
'Grid' graphics
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gridtext
  Version : 0.1.1
  Upstream Author : Claus O. Wilke
* URL : https://cran.r-project.org/package=gridtext
* License : MIT
  Programming Lang: GNU R
  Description : GNU R improved text rendering support for 'Grid' graphics
 Provides support for rendering of formatted text using 'grid' graphics.
 Text can be formatted via a minimal subset of 'Markdown', 'HTML', and
 inline 'CSS' directives, and it can be rendered both with and without
 word wrap.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gridtext

Bug#947351: cloud-init 20.2-2~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947351 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cloud-init
Version: 20.2-2~deb10u1

Explanation: new upstream release

Bug#964736: ITP: public-inbox -- Mailing list archiver

[Eric Wong]

Uwe Kleine-König  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Uwe Kleine-König 
> 
> * Package name: public-inbox
>   Version : 1.5.0
>   Upstream Author : Eric Wong  and others
> * URL : https://www.public-inbox.org/
> * License : AGPL-3.0
>   Programming Lang: Perl
>   Description : versatile mailing (list) archiver
> 
> This software powers https://lore.kernel.org/ and also
> http://www.public-inbox.org/ itself. It's the server-side counter part

+Cc: m...@public-inbox.org

Probably better to list https://public-inbox.org/hosted.html
instead of its "homepage" as an example.  Also, no need for
"www.", URLs with Message-IDs are long enough as they are and
I'm unlikely to ever to want multiple IPs/hosts behind
public-inbox.org.

> for b4 that is already packaged in Debian.
> 
> Currently I evaluate it to provide an archive for several work related
> mailing lists.
> 
> Depending on the outcome of this evaluation I might or might not actually
> package public-inbox. But as deploying is easy using debian packages I
> will create at least simple packaging which should at a minimum give a
> good start for someone to pick up from me.

Great to hear.  I'm somewhat familiar with Debian packaging and
debhelper, so I can help.

Fwiw, I've been thinking about providing "make deb-pkg" and
"make bindeb-pkg" targets (identical to what Linux kernel
provides) for end users to build their own packages, too.  It
would be non-intrusive to distro packagers (no "debian/"
directory in VCS).

Bug#964742: src:binutils-mingw-w64: FTBFS on s390x: FAIL: objcopy executable (pr25662)

[Stephen Kitt]

Package: src:binutils-mingw-w64
Version: 8.10
Severity: serious
Justification: ftbfs

Dear Maintainer,

binutils-mingw-w64 FTBFS on s390x and other big-endian architectures;
the test suite fails with

FAIL: objcopy executable (pr25662)

Regards,

The Maintainer

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (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.19.0-9-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)

Bug#964741: node-node-sass: embeds code copy of sass-spec

[Jonas Smedegaard]

Package: node-node-sass
Version: 4.14.1+git20200512.e1fc158+dfsg-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

node-node-sass embeds as part of the source package
a code copy of separate project sass-spec.

sass-spec is already pacakged for Debian.
Please use the existing package, and avoid shipping duplicate code
risking to get out of sync.

Please do think twice before arguing that duplicating code is intended.

If sass-spec as packaged for Debian is unsuitable for node-node-sass,
then please file bugreport(s) against that other package
clarifying what is needed/broken.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8HeAoACgkQLHwxRsGg
ASHURg//efMqYAxsBvSb/Ty6WSFqt1MIRvWZzxYC73jV2LkphUUtEX1KOP7w/ijj
qIavlZCtPAb6DDGx5DgYz7sdvQ83CkttIIjvHVXvGHWNEyaTw5iLhJgOYNwsNVML
owCQL8eBh92uv6LKlhvb60W8lNg1hG6PtujA9XFOlLtq27b885eV+8DwsPK1b9NZ
sRVm7rHnyVym53M9Aoik26Xj4o81rIVsAyD5U+nQKcI3UTgueBsjdrku3NJCxUdt
WjA+Hpsq1oKLmfuCLUPqvNOpUQY+HNizDvKAc453/xtL4060gJpCCFyqMNylkebH
KQjoea+zlC/hlKWkXA6z317s9+u+SCzfTa6A37SEa/hu4dQA7RJJnaG1gW3zr8AX
cgAm9bpcYPe2tFgg2c5zVPIpl7N70oVBFbJi4X8sAOE9e5sCRdBq29nCbnrKVGzN
V6evhjA4H+xmvidVdxhlGVCXE378ZFODJi0E62MTKNAEwYtGQHQS/v0XXqA5PxqA
48VErVm4eu6jAGYd3NtpzUYxhDoeg1oX+kKcWSj6KGUtsHK4sZTLo0fBUfNh6aSw
zMvurLFLYI1QkoHVsYNfuFGhfM0xA4xzdC2F+IW11eWdClqoEfvNmVT2UX6YbPA4
6KXNu4v1z5PYCYvIPQbQq3MpkcP9x4ExeJ+6NbymVzXJj3A2r8o=
=prlH
-END PGP SIGNATURE-

Bug#962059: python-markdown2 2.3.7-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 962059 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: python-markdown2
Version: 2.3.7-2+deb10u1

Explanation: fix cross-site scripting issue [CVE-2020-11888]

Bug#963940: nvidia-graphics-drivers-legacy-390xx 390.138-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963940 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-legacy-390xx
Version: 390.138-1~deb10u1

Explanation: 

Bug#963986: nvidia-graphics-drivers 418.152.00-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963986 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 418.152.00-1

Explanation: new upstream stable release; security fixes [CVE-2020-5963 
CVE-2020-5967]

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Adam D. Barratt]

On Sun, 2020-02-16 at 16:27 +, Ben Hutchings wrote:
> This was discussed on IRC with Julien Cristau, but unfortunately I
> didn't save a log.  The main points that came up were:
> 
> * Executables built for the O32 FP64 ABI require this kernel config
>   change and older kernel versions will refuse to load them.  So the
>   kernel needs to be upgraded before installing any binaries built
>   for the new FP ABI.
> 
> * Normally the support for an additional ABI would be included in
>   release N.0 and used in N+1.  Since this was not present in 10.0,
> it
>   would be possible for users to start upgrading to bullseye while
>   still running a kernel that does not support O32 FP64.  We need to
>   prevent them getting a broken system.
> 
> * Julien proposed that libc6 would have a preinst check on the kernel
>   when it is changed to use the new FP ABI.  Presumably all binaries
>   built for the new FP ABI should also have a versioned dependency on
>   at least this version of libc6.
> 
> So I don't see any reason not to update the kernel configuration
> already, as it will remain compatible with the O32 FPXX binaries in
> buster.  Only the user-space changes in unstable (libc6 and
> toolchain) need to be carefully coordinated.

As far as I can see, this was enabled in 4.19.118-1, but is about to be
reverted due to causing issues. Is that accurate? If so, should we
close this request now?

Regards,

Adam

Bug#964318: gosa login broken with PHP 7.4

[Wolfgang Schweer]

On Mon, Jul 06, 2020 at 12:05:44PM +0200, Wolfgang Schweer wrote:
> In both encrypt and decrypt cases, the chosen cipher method seems to 
> return 0.

This is the case because the chosen method (aes-256-ecb) doesn't use an 
initialization vector ($iv) at all, causing its length ($ivlen) to be 0, 
see e.g. https://usr.ed48.com/php/ssl/?xf=7

So the encrypt/decrypt implementation seems to have been sort of wrong 
before (and only now with PHP 7.4 an error is thrown).

Please check and test the attached changes to 
/usr/share/gosa/include/functions.inc and 
/usr/sbin/gosa-encrypt-passwords; works for me, but then my skills are 
low level and this is a quite sensitive issue.

Wolfgang
diff -u a/functions.inc b/functions.inc
--- a/functions.inc	2020-04-20 07:32:48.0 +0200
+++ b/functions.inc	2020-07-09 21:09:16.311305601 +0200
@@ -3308,11 +3308,10 @@
 }
 
 
-function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
+function cred_encrypt($input, $password) {
+  $cipher = "aes-256-ecb";
   if (in_array($cipher, openssl_get_cipher_methods())) {
-$ivlen = openssl_cipher_iv_length($cipher);
-$iv = openssl_random_pseudo_bytes($ivlen);
-return bin2hex(openssl_encrypt($input, $cipher, $password, OPENSSL_RAW_DATA, $iv));
+return bin2hex(openssl_encrypt($input, $cipher, $password));
   }
 
   return null;
@@ -3320,9 +3319,7 @@
 
 function cred_decrypt($input, $password, $cipher = "aes-256-ecb") {
   if (in_array($cipher, openssl_get_cipher_methods())) {
-$ivlen = openssl_cipher_iv_length($cipher);
-$iv = openssl_random_pseudo_bytes($ivlen);
-return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password, OPENSSL_RAW_DATA, $iv ), "\0\3\4\n");
+return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password, $options=0, ), "\0\3\4\n");
   }
 
   return null;
diff -u a/gosa-encrypt-passwords b/gosa-encrypt-passwords
--- a/gosa-encrypt-passwords	2020-04-20 07:32:00.0 +0200
+++ b/gosa-encrypt-passwords	2020-07-09 21:07:27.143219922 +0200
@@ -1,11 +1,10 @@
 #!/usr/bin/php
 

signature.asc
Description: PGP signature

Bug#964713: stretch-pu: package storebackup/3.2.1-2~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-07-09 at 15:46 +0300, Adrian Bunk wrote:
>   * Set maintainer to Debian QA Group. (see #856299)
>   * Add patch to change the way the lockfile is opened in the Perl
> code.
> (Fixes: CVE-2020-7040) (Closes: #949393)
> 

Please go ahead.

Regards,

Adam

Bug#964715: buster-pu: package mydumper/0.9.5-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confiremd

On Thu, 2020-07-09 at 16:20 +0300, Adrian Bunk wrote:
>   * Link mydumper against libm. (Closes: #956020)
> 
> libmariadb-dev removed some libraries like -lssl and -lm
> from Libs in the pkg-config file.
> 
> This is correct, and reduces the amount of unnecessary linking.
> 
> But in mydumper this exposed a missing -lm
> (OpenSSL is not used directly by mydumper).
> 

Please go ahead.

Regards,

Adam

Bug#964338: buster-pu: package mariadb-10.3 10.3.23-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-07-07 at 21:34 +0300, Otto Kekäläinen wrote:
> Sorry, the changelog is wrong, it was actually not removed, just
> changed location:
> 
> --- a/debian/libmariadb-dev.install
> +++ b/debian/libmariadb-dev.install
> @@ -8,4 +8,4 @@ usr/lib/*/libmysqlservices.a
>  usr/share/aclocal/mysql.m4
>  usr/share/man/man1/mysql_config.1
>  usr/lib/pkgconfig/libmariadb.pc
> usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
> -usr/share/pkgconfig/mariadb.pc
> usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
> +usr/lib/*/pkgconfig/mariadb.pc
> 
> So upstream adopted our view of what the location should be, so the
> move was removed. End result is that location is exactly the same.
> 
> 
> This is the correct changelog:
> 
> mariadb-10.3 (1:10.3.23-0+deb10u1) buster; urgency=high
> 
>   * SECURITY UPDATE: New upstream version 10.3.23. Includes fixes for
> the
> following security vulnerabilities (Closes: #961849):
> - CVE-2020-2752
> - CVE-2020-2760
> - CVE-2020-2812
> - CVE-2020-2814
> - CVE-2020-13249
>   * Backport upstream patch to fix regression in RocksDB ZSTD
> detection
> which prevents a serious bug and also autopkgtest detectable
> regression.
>   * Update libmariadb symbols for upstream release 3.1.8. Upstream
> added one new symbol and it needs to be tracked in the symbols
> file.
> 

OK, please go ahead.

Regards,

Adam

Bug#964714: buster-pu: package appstream-glib/0.7.14-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-07-09 at 15:47 +0300, Adrian Bunk wrote:
>   * Backport upstream fix for FTBFS in the year 2020.
> (Closes: #949169)

Please go ahead.

Regards,

Adam

Bug#963024: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-17 at 22:07 +0200, Joachim Falk wrote:
> The tigervnc-standalone-server/1.9.0+dfsg-3+deb10u1 package is
> affected by a bug in libunwind8 (Bug: #923962) exhibited on
> architectures arm64, armel, and armhf that makes it unusable (Bug:
> #932499) on those architectures.
> 
> As a workaround, the proposed update tigervnc/1.9.0+dfsg-3+deb10u2
> disables building against libunwind on exactly these three
> architectures.
> 

Please go ahead.

Regards,

Adam

Bug#964712: buster-pu: package storebackup/3.2.1-2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-07-09 at 15:46 +0300, Adrian Bunk wrote:
>   * Set maintainer to Debian QA Group. (see #856299)
>   * Add patch to change the way the lockfile is opened in the Perl
> code.
> (Fixes: CVE-2020-7040) (Closes: #949393)
> 

Please go ahead.

Regards,

ADam

Bug#960836: buster-pu: package gnutls28/3.6.7-4+deb10u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-06-07 at 08:45 +0200, Andreas Metzler wrote:
> Control: tags -1 - moreinfo
> Control: retitle -1 buster-pu: package gnutls28/3.6.7-4+deb10u5
> 
> On 2020-05-26 Andreas Metzler  wrote:
> > Control: tags 960836 + moreinfo
> > Please hold on approving this. I will probably need to add a fix
> > for
> > https://gitlab.com/gnutls/gnutls/-/issues/997
> 
> Hello,
> 
> find attached a new version rebased on the latests DSA and featuring
> these additional fixes:

Please go ahead, sorry for the delay.

Regards,

Adam

Bug#964740: buster-pu: package debian-ports-archive-keyring/2019.11.05~deb10u1

[Aurelien Jarno]

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

Hi,

The debian-ports-archive-keyring in buster has the 2020 archive key
expired, as it was wrongly created off by one year. This has been fixed
in testing/sid for some time already, and the same version also adds the
2021 key.

It happened that even if debian-ports only targets sid, this package is
often used to pass the archive key to debootstrap running on a buster
system, including on various CI systems external to Debian.

You will find the debdiff against the current buster version attached.
The changes compared to the version currently in testing/sid is only the
buster changelog entry. Given the changes are minimal, I have already
uploaded the package to the archive. Thanks for considering.

Regards,
Aurelien
diff -Nru 
debian-ports-archive-keyring-2018.12.27/active-keys/debian-ports-archive-2018.key
 
debian-ports-archive-keyring-2019.11.05~deb10u1/active-keys/debian-ports-archive-2018.key
--- 
debian-ports-archive-keyring-2018.12.27/active-keys/debian-ports-archive-2018.key
   2017-12-30 16:53:16.0 +0100
+++ 
debian-ports-archive-keyring-2019.11.05~deb10u1/active-keys/debian-ports-archive-2018.key
   1970-01-01 01:00:00.0 +0100
@@ -1,30 +0,0 @@
--BEGIN PGP PUBLIC KEY BLOCK-
-
-mQINBFpHqKsBEACzweCLMORwZsTstyxlvjGroOqPYwbXkiS3/Pfj7dzcWcaQbz/o
-Myru2n7/FQHb4Rst6c1sC/46DmfuXFOjL4iuQxthCDaE6OIAiKD5F42m8iKyhAFT
-7F2g7UTAaWkcUTuukkcqhR7AKHIyDsJpHz7MgOYMBBr0ZX3IklliMQlE+hlbg2ua
-EWpvI503cO8gqg0SaJy8NVil21sneEszevBU0uR4+GeYu67hthocuicNd8B2IJxR
-WnnrV0FfPHgVaMNSUb5G5fAUbJ1pIoHHkm4kOm0J+DFkg7kPuUMh/YYgRD1gL7sU
-gxC4MSwWnHLpsOfyHx/0L5cbALXK8WPmJ3jnbyZJQzIs/AjQjAwB3ObFGLi7AIIL
-Zh633cZwLTKlngD5IBUMpdcpU7exbjYt+ZcHd+wdaOCG+miyEz4Mr9ddm3MGQXbf
-U9e8g0SnVIYD3pYKcXGE3JQoxIh/zFSCQxeJRvVvUZCpr8e3CZcC5zAdHp38pLaX
-VmZiE+WI5NuAcOUpvsQ1wg449fqaECk86uZvLQhs/KXABUzQOBdHwYjx5ainwrp2
-NkceUOsqDAAxyS6m4mMCUhw+I4KV/H8hPpQnp4nxR+WgsQGVbmztKfQxR/1YsnEg
-O2hnrQ/Bw7Zu73hxE7NrfVjRLOONnz+07qbbPUlZy3UttCvr67vFivPO8wARAQAB
-tFVEZWJpYW4gUG9ydHMgQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIw
-MTgpIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJQBBMBCgA6
-FiEEWOZLm7EbwRIgXbzbBq7WJDDLWBwFAlpHqKsCGwMFCQILY4ACCwkEFQoJCAUW
-AgMBAAIeAQIXgAAKCRAGrtYkMMtYHAxEEACcRaMyuj/R+8vSWk2USW9TvBc7K17q
-h9dpeLJim90QpLPV5Qzib7UFqA9dlUxlBuq12HjtaJJmXUG34koZN1Jv3tldprgq
-AFrlmhQrdKVMOP6p+ppl409rOn84+whaFJBkujHOhuFk5sJQ5ZQNFKv00A3yFH0V
-TyKsqDrz2uUt2oYmf92wqJD7iW7vb8MS7u8p+ywumezPbsDMAcGd08xW4xLA+ckZ
-wTByJy7VGFZoIotV4EX7kjP4wRYe8Rem2aQdhuR+Del/T9XtK+06mfX5iXbT5JQL
-bzLjnLUkhE4U2xd7gi2+I3N/PYvRnVh91z8fwQCMH4BbxZuZylGrOhakAI+1hPT7
-sjUNIlD6vPH8yX8k3LU2PPei9UryBex2XILlx6L5K9/d8XlBs0YuiWUey+sO/MWA
-nE2gPZwZJYt2bm13MzirVPmaLE1iA/A2vaXjF9+M1DOCbHVq4TYrTAoEr7EXAoqj
-KT81DKs0OriMgcDZwI1S3AnEr1nD0Q0aZ+Xg/MSBwSD4IO5PwSd5R7x8wFXt3P3O
-8jReN0+xfqdmcan66jbtEA6hY/6Vz0CwqDu9TSJmRrFDFOkW65zrNM3n2eocpQ2p
-j/Og6Mym1u0TvE3GQtxo2KdFiNN7bvXotsmNlKUdQh0GAtOcZ1iwqRKYXCV8sCLf
-GB2cdUDMU41zqw==
-=Vk6B
--END PGP PUBLIC KEY BLOCK-
diff -Nru 
debian-ports-archive-keyring-2018.12.27/active-keys/debian-ports-archive-2020.key
 
debian-ports-archive-keyring-2019.11.05~deb10u1/active-keys/debian-ports-archive-2020.key
--- 
debian-ports-archive-keyring-2018.12.27/active-keys/debian-ports-archive-2020.key
   2018-12-27 18:22:39.0 +0100
+++ 
debian-ports-archive-keyring-2019.11.05~deb10u1/active-keys/debian-ports-archive-2020.key
   2019-11-05 22:19:45.0 +0100
@@ -12,19 +12,19 @@
 MzNlMCf9SaHUuVpkhsnQ72lnaHsjIXojsaD6f/fVZzlBNZg31EwuF75ZraND/XT6
 uOVjVf17pRBjoAZtgwnK1jRprd2MOo4AC5W8ndiOekOsfWqglItNc7MZqwARAQAB
 tFVEZWJpYW4gUG9ydHMgQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIw
-MjApIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJPBBMBCgA6
-FiEEEXchP3ue8cUoDP7qhMVzzU4a/WwFAlwjtU4CGwMFCQIQqYACCwkEFQoJCAUW
-AgMBAAIeAQIXgAAKCRCExXPNThr9bLlED/j4b3BpdVnSkIG69NV4WASbFYjnQk1q
-lSH6Ss4VNABuBUUO5I4S86R3vtLEOkqpogiInhx3QQwlYB+krGzENH76duu/a6oi
-f7KTJn+CYTJhU8gqJHuVSnoP30EoK/NZ2DK+D51dSGKF1fSmo1rOiv3v5V2ywKwQ
-yYk27v7H8BwiTv8hAISv0ooRA6UKwDTdNbE2JiAqlpW9RgdkAuaYBlzwwaMgDGIN
-lBdbrvam1H7rnaXR9ubLASHjfofJ9i0iuRyu2hhqqEBM3XoQ3GL6B0YfX9OMqPUZ
-Mn3VK2xNmUrNioXUC0J7USpFuofxHPib0j4g07V/2snJkZKEvig4uUrxSBmNc8yH
-WqD3w2Sx1qUKMnYhysyNou8BRVOjYz1SLx76e8lSVnuDd/Z9YIbHN71e4V4SzdSH
-CnRFDOr8PCAz3kzq29rvTISEXFnh/lPnN/4NT9HYxU4ocrPZOcCjEU8h98P0IqVy
-NEX4acgCbSqcYuajYulnhqVypnVvpPCbb90P4CBjINgveI7OynlV8GBX1GFS350d
-gr6fqGi+/qA7xa7FHJGaqmZkmiIOBZ3yYJXX0caHQkv2S8RFtWngCb0700zYCCwE
-f7R5iyid5ZSI/Qq4LVG3N0t2oK+3ETimSLQqoOfjC/j04fj50FAsZhNMwQuOv8BT
-7WZB/Y8wQFql
-=/CLS
+MjApIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJQBBMBCgA6
+AhsDAgsJBBUKCQgFFgIDAQACHgECF4AWIQQRdyE/e57xxSgM/uqExXPNThr9bAUC
+XcHiUAUJA/NkggAKCRCExXPNThr9bBauD/9vMlvkLWK461eOhIy9753fo22mn3Of
+PvTsHbmlNx6FL+kIMKqcjqyOrUSyeW/ksA1vHzlJgOw4/D4RTGoJ3jnmtq6nDudJ
+mcHQ0x4DKjQDWPIJBoo0TckrJCKNALQe3BB34VvZO24umnE7rtcfBJch3CjVbDlU
+I6mVfSktbtGjxNmdW54VVb4Rz6vmsXgA04pbWcDvvT5iUr6ftqgONfd+/OPMnxzJ

Bug#963796: resource-agents 4.2.0-2+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963796 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: resource-agents
Version: 4.2.0-2+deb10u2

Explanation: IPsrcaddr: make proto optional to fix regression when used without 
NetworkManager

Bug#964422: raspi3-firmware 1.20190215-1+deb10u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964422 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: raspi3-firmware
Version: 1.20190215-1+deb10u4

Explanation: fix typo that could lead to unbootable systems

Bug#964228: nmap 7.70+dfsg1-6+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964228 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nmap
Version: 7.70+dfsg1-6+deb10u1

Explanation: update default key size to 2048 bits

Bug#963761: [Pkg-javascript-devel] Bug#963761: node-node-sass: missing versioned dependency relation?: Sass could not find a binding for your current environment

[Jonas Smedegaard]

Quoting mer...@debian.org (2020-07-09 16:42:32)
> On Fri, 26 Jun 2020 18:27:30 +0200 Paul Gevers  wrote:
> > + grunt sass nodeunit
> > Loading "gruntfile.js" tasks...ERROR
> > >> Error: Missing binding
> >
> /usr/lib/x86_64-linux-gnu/nodejs/node-sass/vendor/linux-x64-72/binding.node
> > >> Node Sass could not find a binding for your current environment:
> > Linux 64-bit with Node.js 12.x
> > >>
> > >> Found bindings for the following environments:
> > >>   - Linux 64-bit with Node.js 10.x
> 
> It seems as if node-node-sass was built with libnode < 72, and is now 
> being executed on machine also having libnode72. While in principle 
> such situations are possible, more than one libnodeX package are very 
> unlikely to be present. It would probably be worth stripping the 
> /linux-x64-72/ part from 
> /usr/lib/x86_64-linux-gnu/nodejs/node-sass/vendor/linux-x64-72/binding.node 
> and disabling the resolving mechanism altogether.

Please, Andrius, think twice before repeating the discussion already had 
about node-iconv and node-expat.

I urge you to read through that previous thread (if you haven't 
already), and I recommend that you consider if it is really worth it to 
look at node-node-sass differently from those other packages.

If you find that it is sensible to follow the approach already taken by 
those other packages, but are uncertain how concretely to implement it, 
then I can suggest to look at the most recent git commits for the 
packaging of node-expat: I tried to isolate and minimize the changes 
made for each commit to hopefully be easy to follow.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#964146: mutt 1.10.1-2.1+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964146 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mutt
Version: 1.10.1-2.1+deb10u3

Explanation: don't check IMAP PREAUTH encryption if $tunnel is in use

Bug#964346: wav2cdr 2.3.4-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964346 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: wav2cdr
Version: 2.3.4-2+deb10u1

Explanation: use C99 fixed-size integer types to fix runtime assertion on 64bit 
architectures other than amd64 and alpha

Bug#961833: openstack-debian-images 1.36+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961833 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: openstack-debian-images
Version: 1.36+deb10u1

Explanation: install resolvconf if installing cloud-init

Bug#963942: nvidia-graphics-drivers 390.138-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963942 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 390.138-1

Explanation: new upstream stable release; security fixes [CVE-2020-5963 
CVE-2020-5967]

Bug#960974: postfix 3.4.14-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 960974 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.4.14-0+deb10u1

Explanation: new upstream stable release; fix segfault in the tlsproxy client 
role when the server role was disabled; fix "maillog_file_rotate_suffix default 
value used the minute instead of the month"; fix several TLS related issues; 
README.Debian fixes

Bug#947758: node-handlebars 4.1.0-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947758 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-handlebars
Version: 4.1.0-1+deb10u2

Explanation: disallow calling "helperMissing" and "blockHelperMissing" directly 
[CVE-2019-19919]

Bug#963595: nfs-utils 1.3.4-2.5+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963595 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nfs-utils
Version: 1.3.4-2.5+deb10u1

Explanation: statd: take user-id from /var/lib/nfs/sm [CVE-2019-3689]; don't 
make /var/lib/nfs owned by statd

Bug#964596: cloud.debian.org: Debian 10 EC2: IPv4 address suddenly flushed

[Noah Meyerhans]

On Thu, Jul 09, 2020 at 12:09:44PM +0200, Martin Olsson wrote:
>Severity: major

JFYI, "major" is not a valid severity.  The complete list of severities
is listed at https://www.debian.org/Bugs/Developer#severities  In the
case of this bug, since the behavior is only triggered by customization
of kernel parameters, we should leave it at the BTS default of "normal".

>Install a Debian 9 machine using the official Debian 9 AMI.
> 
>During the hardening of the machine, disable IPv6 completely:
># cat /etc/sysctl.d/disable_ipv6.conf
>net.ipv6.conf.all.disable_ipv6 = 1
>net.ipv6.conf.default.disable_ipv6 = 1
>net.ipv6.conf.eth0.disable_ipv6 = 1
>net.ipv6.conf.lo.disable_ipv6 = 1
> 
>This hardened Debian 9 server works perfectly for a year.

I think there is more to it.  When I launch a Debian 9 with those sysctl
values set, the network is not fully configured and the instance boots
to systemd's "degraded" status.  Journalctl shows:

Jul 09 18:34:11 ip-10-0-0-149 systemd[1]: Started ifup for eth0.
Jul 09 18:34:11 ip-10-0-0-149 systemd[1]: Starting Raise network interfaces...
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: Internet Systems Consortium DHCP 
Client 4.3.5
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: Internet Systems Consortium DHCP Client 
4.3.5
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: Copyright 2004-2016 Internet 
Systems Consortium.
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: Copyright 2004-2016 Internet Systems 
Consortium.
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: All rights reserved.
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: All rights reserved.
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: For info, please visit 
https://www.isc.org/software/dhcp/
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: For info, please visit 
https://www.isc.org/software/dhcp/
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: 
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: Listening on 
LPF/eth0/02:e7:21:78:ad:4a
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: Listening on LPF/eth0/02:e7:21:78:ad:4a
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: Sending on   LPF/eth0/02:e7:21:78:ad:4a
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: Sending on   Socket/fallback
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: DHCPREQUEST of 10.0.0.149 on eth0 to 
255.255.255.255 port 67
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: Sending on   
LPF/eth0/02:e7:21:78:ad:4a
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: Sending on   Socket/fallback
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: DHCPACK of 10.0.0.149 from 10.0.0.1
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: DHCPREQUEST of 10.0.0.149 on eth0 
to 255.255.255.255 port 67
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: DHCPACK of 10.0.0.149 from 10.0.0.1
Jul 09 18:34:11 ip-10-0-0-149 dhclient[269]: bound to 10.0.0.149 -- renewal in 
1560 seconds.
Jul 09 18:34:11 ip-10-0-0-149 sh[258]: bound to 10.0.0.149 -- renewal in 1560 
seconds.
Jul 09 18:34:13 ip-10-0-0-149 ifup[364]: ifup: waiting for lock on 
/run/network/ifstate.eth0
Jul 09 18:34:17 ip-10-0-0-149 sh[258]: Could not get a link-local address
Jul 09 18:34:17 ip-10-0-0-149 sh[258]: ifup: failed to bring up eth0
Jul 09 18:34:17 ip-10-0-0-149 systemd[1]: ifup@eth0.service: Main process 
exited, code=exited, status=1/FAILURE
...
Jul 09 18:34:23 ip-10-0-0-149 systemd[1]: Failed to start Raise network 
interfaces.
Jul 09 18:34:23 ip-10-0-0-149 systemd[1]: networking.service: Unit entered 
failed state.
Jul 09 18:34:23 ip-10-0-0-149 systemd[1]: networking.service: Failed with 
result 'exit-code'.

And:
admin@ip-10-0-0-149:~$ systemctl is-system-running 
degraded

So I think that regardless of what happens when the instance is upgraded
to Debian 10, the system is unhealthy even when running Debian 9 when
modified in the way you've described.

There are a couple of ways that you can disable IPv6 without breaking
things.  You could modify /usr/local/sbin/inet6-ifup-helper to exit with
a '0' status unconditionally, or you could avoid running it altogether.
To do that, remove all the lines containing 'inet6' from
/etc/network/interfaces.  This should ensure that the network is fully
configured and that the system recognizes as such.  In my testing, the
upgrade to buster after performing these changes is successful and there
are no residual issues.

I think it's reasonable to add a check in
/usr/local/sbin/inet6-ifup-helper for future revisions of the stretch
AMI to exit successfully if IPv6 is disabled on $IFACE.

>A reset of the EC2 brings the access back, only to be lost again 1h later.
> 
>(unfortunately, neither dhclient nor the cloud-init scripts syslogged any
>error, so it was pretty hard to figure out what was wrong)

Try journalctl

>It turns out to be the IPv6 hardening that generates problems for
>dhclient/ifup.
> 
>I believe the problem lies in /sbin/dhclient-script :
>        if [ -n "$old_ip_address" ] &&
>           [ "$old_ip_address" != "$new_ip_address" ]; then
>            # leased IP has changed => flush it
>     

Bug#963267: multipath-tools 0.7.9-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963267 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: multipath-tools
Version: 0.7.9-3+deb10u1

Explanation: kpartx: use correct path to partx in udev rule

Bug#964350: intel-microcode 3.20200616.1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964350 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: intel-microcode
Version: 3.20200616.1~deb10u1

Explanation: downgrade some microcodes to previously issued versions, working 
around hangs on boot on Skylake-U/Y and Skylake Xeon E3

Bug#964726: jackson-databind 2.9.8-3+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964726 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: jackson-databind
Version: 2.9.8-3+deb10u2

Explanation: fix multiple security issues affecting BeanDeserializerFactory 
[CVE-2020-9548 CVE-2020-9547 CVE-2020-9546 CVE-2020-8840 CVE-2020-14195 
CVE-2020-14062 CVE-2020-14061 CVE-2020-14060 CVE-2020-11620 CVE-2020-11619 
CVE-2020-3 CVE-2020-2 CVE-2020-1 CVE-2020-10969 CVE-2020-10968 
CVE-2020-10673 CVE-2020-10672 CVE-2019-20330 CVE-2019-17531 and CVE-2019-17267]

Bug#964417: mod-gnutls 0.9.0-1.1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964417 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mod-gnutls
Version: 0.9.0-1.1~deb10u1

Explanation: fix a possible segfault on failed TLS handshake; fix test failures

Bug#964574: file-roller 3.30.1-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964574 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: file-roller
Version: 3.30.1-2+deb10u1

Explanation: security fix [CVE-2020-11736]

Bug#964412: c-icap-modules 0.5.3-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964412 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: c-icap-modules
Version: 0.5.3-1+deb10u1

Explanation: add support for ClamAV 0.102

Bug#964397: libembperl-perl 2.5.0-12+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964397 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libembperl-perl
Version: 2.5.0-12+deb10u1

Explanation: handle error pages from Apache >= 2.4.40

Bug#964589: fwupd 1.2.13-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964589 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fwupd
Version: 1.2.13-1

Explanation: new upstream release; security fix [CVE-2020-10759]

Bug#960600: asunder 2.9.3-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 960600 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: asunder
Version: 2.9.3-3+deb10u1

Explanation: use gnudb instead of freedb by default

Bug#964158: cacti 1.2.2+ds1-2+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964158 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cacti
Version: 1.2.2+ds1-2+deb10u3

Explanation: fix issue where UNIX timestamps after September 13th 2020 were 
rejected as graph start / end; fix remote code execution [CVE-2020-7237], 
cross-site scripting [CVE-2020-7106], CSRF issue [CVE-2020-13231]; disabling an 
user account does not immediately invalidate permissions [CVE-2020-13230]

Bug#963591: exiv2 0.25-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963591 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: exiv2
Version: 0.25-4+deb10u1

Explanation: adjust overly restrictive security patch [CVE-2018-10958 and 
CVE-2018-10999]; fix denial of service issue [CVE-2018-16336]

Bug#963694: libexif 0.6.21-5.1+deb10u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963694 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-5.1+deb10u4

Explanation: fix buffer overflow [CVE-2020-0182] and integer overflow 
[CVE-2020-0198]

Bug#961275: jameica 2.8.4+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961275 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: jameica
Version: 2.8.4+dfsg-1+deb10u1

Explanation: add mckoisqldb to classpath, allowing use of SynTAX plugin

Bug#961379: libntlm 1.5-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961379 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libntlm
Version: 1.5-1+deb10u1

Explanation: fix buffer overflow [CVE-2019-17455]

Bug#964459: libreoffice-kf5: [kf5] [dark theme] unreadable elements: button labels on welcome screen, names in dropdown font list

[Rene Engelhard]

forwarded 964459 https://bugs.documentfoundation.org/show_bug.cgi?id=133929
tag 964459 + upstream
thanks

Hi,

On Wed, Jul 08, 2020 at 12:53:14AM +1000, Thom wrote:
> LibreOffice with VCL plugin kf5 have unreadable button labels on welcome 
> screen sidebar (white text on light gray background) and fontnames in 
> dropdown font list (light gray text on white background) in Writer, Calc, etc.
> 
> LibreOffice with VCL plugin gtk-3 looks fine in same situation.

[libreoffice-kf5-7.0.0~rc1-1-start-screen.png (image/png, attachment)]

This is https://bugs.documentfoundation.org/show_bug.cgi?id=133929

[libreoffice-kf5-7.0.0~rc1-1-writer.png (image/png, attachment)]

For this there's various bugs possible:

https://bugs.documentfoundation.org/buglist.cgi?quicksearch=dark%20theme_id=1166282

ID  Product CompAssignee▲   Status▲ Resolution  Summary Changed
126933  LibreOffWriter  libreoffice-b...@lists.free...  UNCO--- 
LO Writer shows some Buttons almost Unreadable when using High Contrast Theme   
2020-03-16
131978  LibreOffUI  libreoffice-b...@lists.free...  UNCO--- 
With dark color theme spell checking dialog is unreadable   2020-04-23
133306  LibreOffWriter  libreoffice-b...@lists.free...  UNCO--- 
[Dark theme] Spell checker has wrong font foreground2020-05-25
133931  LibreOffCalclibreoffice-b...@lists.free...  UNCO--- 
KDE5/QT5 VCL & dark theme: Calc: every other function name in Function Wizard 
list is unreadable2020-06-27
103656  LibreOffUI  libreoffice-b...@lists.free...  NEW --- 
Read-only bar is unreadable when using dark theme   2020-06-12

for example

So, because you didn't follow the principle of one bug one bugreport -
what are we going to mark it as forwarded to

I'd say https://bugs.documentfoundation.org/show_bug.cgi?id=133929 but
that also would mean that this bug should be closed if that one is
closed regardless of your writer issue.

Regards,

Rene

Bug#964014: Update iptables in buster backports to 1.8.5+ ?

[Etienne Champetier]

Hello Arturo,

I never received your response, this is a copy paste of the archive
https://alioth-lists.debian.net/pipermail/pkg-netfilter-team/Week-of-Mon-20200706/001296.html

>On Tue, 30 Jun 2020 08:10:49 -0400 Etienne Champetier
> wrote:
>> Package: iptables
>> Version: 1.8.3-2~bpo10+1
>>
>> Hello Debian Netfilter Packaging Team,
>>
>> Is it planned to have iptables updated in buster backports to 1.8.5+ ?
>> I need it to fix https://bugzilla.netfilter.org/show_bug.cgi?id=1422
>> At least the following commit:
>> https://git.netfilter.org/iptables/commit/?id=18f01acbdefb211ebfefb728d2b6843c59ae06db
>>
>
>I'm afraid this wont happen soon on my side.
>Among other things, we would need to also backport libnftnl first.
>Would you be able to contribute or help with this in any way?

Rebuild, test and comment here, I will try ;)

Bug#917095: python3-pyfftw: alignment tests fail on several arches

[Thorsten Glaser]

On Sat, 22 Dec 2018, Drew Parsons wrote:

> Upstream is aware of the problem,
> https://github.com/pyFFTW/pyFFTW/issues/128

I wrote:

>This still fails, even on x32, which is an x86 architecture õÕ

I’ve commented upstream. The funniest thing is that, when I run
the test that fails inside the build chroot, manually, (just with
more debugging output) it passes!

https://github.com/pyFFTW/pyFFTW/issues/128#issuecomment-656290711

I therefore propose to skip the problematic tests on most
architectures.

Another interesting difference is that the build has 2 failues
whereas my local build has 12 so the binary build might be
dependent on the system it was built on, which is… dangerous,
and, for a binary distribution, obviously inappropriate.

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

Bug#964351: intel-microcode 3.20200616.1~deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964351 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: intel-microcode
Version: 3.20200616.1~deb9u1

Explanation: downgrade some microcodes to previously released revisions, 
working around hangs on boot on Skylake-U/Y and Skylake Xeon E3

Bug#949367: wpa 2.4-1+deb9u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 949367 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: wpa
Version: 2.4-1+deb9u6

Explanation: fix AP mode PMF disconnection protection bypass [CVE-2019-16275]; 
fix MAC randomisation issues with some cards

Bug#964588: fwupd 0.8.3-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964588 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: fwupd
Version: 0.8.3-1

Explanation: new upstream release; use a CNAME to redirect to the correct CDN 
for metadata; do not abort startup if the XML metadata file is invalid; add the 
Linux Foundation public GPG keys for firmware and metadata; raise the metadata 
limit to 10Mb

Bug#964291: mariadb-10.1 10.1.45-0+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964291 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: mariadb-10.1
Version: 10.1.45-0+deb9u1

Explanation: new upstream stable release; security fixes [CVE-2020-2752 
CVE-2020-2812 CVE-2020-2814]

Bug#963548: Received signal 11 SEGV_MAPERR

[Andrey Gursky]

The bug has been reported upstream:

https://bugs.chromium.org/p/chromium/issues/detail?id=1102805



Forwarding good news from one of numerous dupes of this Debian bug, thanks Riku:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964451#25

On Thu, 9 Jul 2020 10:29:36 + Riku Voipio  wrote:
> This should fix it:
>
> https://salsa.debian.org/chromium-team/chromium/-/commit/b904fa41d40b967dcc8f6984db52f7a2f6a2c83d
>
> We are not building with GCC but this seems to be exactly the place where the 
> crash happens.
> chromium built with this patch has not crashed for the last few hours for me, 
> while before it would
> crash in a few minutes.
>
> Riku



Regards,

Andrey

Bug#964599: [Pkg-roundcube-maintainers] Bug#964599: Roundcube-core Overwrites Local Changes in _styles.less

[Guilhem Moulin]

Control: retitle -1 upgrades overwrites local style customization
Control: severity -1 wishlist

On Thu, 09 Jul 2020 at 06:09:02 -0500, Bryan Walton (Debian) via 
Pkg-roundcube-maintainers wrote:
> _styles.less, located in /usr/share/roundcube/skins/elastic/styles, is a
> file that exists for local customizations of the roundcube templates.  The
> file, as shipped by Debian has one line in it, that reads:
> 
> /* Here you can put your custom styles that will be appended to the output
> css file */

That file (as well as ‘_variables.less’) comes from upstream.  Not sure
how best to add support for local style customization in the package.

 * We could build styles.css at postinst stage.  This is my least
   favorite option, because it adds a runtime dependency on node-less,
   which transitively pulls in 61 new packages (>50MiB additional disk
   space) at install time on a minimal sid chroot with 
`--no-install-recommends`.
   It might also make the package uninstallable if lessc(1) upstream
   changes their CLI interface.  This is not speculation, following a
   node upgrade less recently failed to write output to stdout.  As of
   the current node-less/3.11.2+dfsg-2, `lessc -x` yields
   
   “The compress option has been deprecated. We recommend you use a
   dedicated css minifier, for instance see less-plugin-clean-css.”

   I would much rather have FTBS bugs than a broken postinstall script
   on (some) user systems.

   We could also ship styles.css, demote the dependency to Suggests:
   (which makes more sense than a hard Depends: given local style
   customization are purely optional), and only rebuild it when
   lessc(1) is found in $PATH *and* local changes are detected, keeping
   the file intact in case the command fails.  However this is not
   satisfactory either as it'd make tools like debsums(1) might complain
   that the file doesn't match what's found in the package metadata.
   Plus the postinst script runs with root privileges and it seems
   non-ideal at best to run lessc(1) with these privileges.

 * We could add a note to ‘styles/_*.less’ saying the user needs to
   manually install node-less and manually run `less -x` after each
   upgrade.  Not ideal either, we might preserve local changes to
   ‘styles/_*.less’ but will overwrite the CSS anyway.  That shifts the
   burden from package maintainer onto users.

Any other option?

Avoiding overwriting users changes is the easy part.  We could either
stop shipping ‘styles/_*.less’, or better symlink these files from
‘/etc/roundcube/skins/elastic’ and let dpkg do the magic.  Note that it
is pretty usual to overwrite local changes outside of /etc (that is,
unless the local admin adds a dpkg diversion); despite what the upstream
file reads we never claimed otherwise, so I'm lowering the severity.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#891657: swt-gtk 3.8.2-3+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 891657 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: swt-gtk
Version: 3.8.2-3+deb9u1

Explanation: add missing dependency on libwebkitgtk-1.0-0

Bug#964244: xml-security-c 1.7.3-4+deb9u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964244 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: xml-security-c
Version: 1.7.3-4+deb9u3

Explanation: fix length calculation in the concat method

Bug#892932: websockify 0.8.0+dfsg1-7+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 892932 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: websockify
Version: 0.8.0+dfsg1-7+deb9u1

Explanation: add messing dependency on python{3,}-pkg-resources

Bug#935739: sendmail 8.15.2-8+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935739 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: sendmail
Version: 8.15.2-8+deb9u1

Explanation: fix finding the queue runner control process in "split daemon" 
mode, "NOQUEUE: connect from (null)", removal failure when using BTRFS

Bug#964398: libembperl-perl 2.5.0-10+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964398 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libembperl-perl
Version: 2.5.0-10+deb9u1

Explanation: handle error pages from Apache >= 2.4.40