Bug#932769: have a look at patch from CentOS

[Sven Hartge]

On 31.07.19 08:37, Sven Hartge wrote:

> This was ISC-Bug 45457:
> https://bugs.isc.org/Public/Bug/Display.html?id=45457
> 
> This bug has been fixed in ISC DHCP 4.3.6.
> 
> The commit implementing this is
> https://gitlab.isc.org/isc-projects/dhcp/commit/3e88222f1c2f7a365b9fde018bb4bf86520b51d6

I misread, it was fixed for 4.4.0. The commit is the correct one though.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#933385: [Pkg-libvirt-maintainers] Bug#933385: libvirt-daemon: encrypted qemu virtual machines do not start after upgrade to buster: permission denied

[Guido Günther]

Hi,
On Wed, Jul 31, 2019 at 07:41:50AM +0200, Dominik Reusser wrote:
> Hi Guido,
> thanks for your support.
> 
> I can confirm that changes to /etc/apparmor.d/libvirt/TEMPLATE.qemu are
> taking effect. Besides the secret file, also the location of my
> vm-image-files needs to be configured in the template file.
> 
> I added the following to get the VM running:
> 
>   /etc/libvirt/secret/** r,
>   /var/lib/libvirt/images/** rwk,

Great! Thanks for reporting back.
 -- Guido

Bug#933518: Provide /usr/lib/nodejs/terser/bin/uglifyjs as an alternative to uglifyjs command

[Pirate Praveen]

Package: node-terser
Version: 4.1.2-3
Severity: wishlist

terser is a drop in replacement for uglifyjs. It'd be nice to provide the same 
command using alternatives mechanism (/etc/alternatives) to transparently 
update to terser from uglifyjs. If we do, please add Provides: uglifyjs too.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933066: ruby-gnome2: autopkgtest regression with GLib 2.60.x: format_size now uses non-breaking space

[Paul Gevers]

Control: affects -1 src:atk1.0

Hi,

On 26-07-2019 12:39, Simon McVittie wrote:
> Source: ruby-gnome2
> Version: 3.3.2-1
> Severity: serious
> Justification: 
> https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
> Tags: upstream fixed-upstream patch
> Forwarded: 
> https://github.com/ruby-gnome2/ruby-gnome2/commit/ac9762af255f276800e0863d1dd07ab9dd653d1b
> User: debian...@lists.debian.org
> Usertags: regression
> X-Debbugs-CC: debian...@lists.debian.org
> 
> ruby-gnome2's autopkgtest fails when run against GLib 2.60.x from unstable,
> with 7 failures all similar to this:
> 
> Failure: test_gb(TestGLibFileUtils::#format_size)
> /tmp/autopkgtest-lxc.6g_rx45a/downtmp/build.TEl/src/glib2/test/test-file-utils.rb:61:in
>  `test_gb'
>  58: end
>  59:
>  60: def test_gb
>   => 61:   assert_equal("1.0 GB", GLib.format_size(1000 * 1000 * 1000))
>  62: end
>  63:
>  64: def test_over_guint32_value
> <"1.0 GB"> expected but was
> <"1.0 GB">
> 
> I think the difference here is that the expected result has a space but
> the actual result has a UTF-8 non-breaking space (U+00A0 NO-BREAK SPACE)
> as a result of https://gitlab.gnome.org/GNOME/glib/issues/1625 having
> been fixed. This is a bit more obvious in the Python bindings:
> 
> $ python3
 from gi.repository import GLib
 GLib.format_size(1000*1000*1000)
> '1.0\xa0GB'
> 
> This appears to have been fixed upstream in
> https://github.com/ruby-gnome2/ruby-gnome2/commit/ac9762af255f276800e0863d1dd07ab9dd653d1b
> (but note that I haven't tested that patch myself). Please consider
> applying it.
> 
> Thanks,
> smcv
> 

This affects the new version of atk1.0 as well, hence making the
maintainers aware of this bug.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#932769: have a look at patch from CentOS

[Sven Hartge]

On 31.07.19 00:20, Thomas Lange wrote:

> First I can confirm this bug. Some time ago I had two servers which
> caused a huge amount of dhcp requests to log the DHCP server (managed
> by a different departement). They told me one server did 30 requests
> per seconds.

> I've looked at the CentOS 8 sources and found this patch:
> 
>>  # If we receive a DHCP offer in dhclient and it's DECLINEd in 
>> dhclient-script,
>>  # backoff for an amount of time before trying again
>>  %patch6 -p1 -b .backoff
> 
> The patch is in the directory SOURCES called
> dhcp-dhclient-decline-backoff.patch. Since I'm not good in C
> programming it would be good I someone else can have a look if Debian
> should include this patch. I'll attach the patch from Centos.

The patch does not apply cleanly to the version in unstable and from
looking at the code, upstream seems to have seen this problem as well
and changed the client to wait for 10 seconds after a DECLINE before
doing a DISCOVER again.

This was ISC-Bug 45457:
https://bugs.isc.org/Public/Bug/Display.html?id=45457

This bug has been fixed in ISC DHCP 4.3.6.

The commit implementing this is
https://gitlab.isc.org/isc-projects/dhcp/commit/3e88222f1c2f7a365b9fde018bb4bf86520b51d6

So for Debian this problem only exists in oldoldstable (Jessie) and
oldstable (Stretch).

In my opinion this change should be pulled into Stretch and possibly Jessie.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#933517: texlive-science-doc: Has to run mktexlsr to make docs visible to texdoc

[Hilmar Preusse]

Package: texlive-science-doc
Version: 2019.20190710-1
Severity: normal

I've installed the texlive-science-doc, which delivers
a lot of fine documentation.

root@amd64-sid:~# apt install texlive-science-doc

Selecting previously unselected package texlive-science-doc.
(Reading database ... 149879 files and directories currently installed.)
Preparing to unpack .../texlive-science-doc_2019.20190710-1_all.deb ...
Unpacking texlive-science-doc (2019.20190710-1) ...
Setting up texlive-science-doc (2019.20190710-1) ...
root@amd64-sid:~#

I'd expect that texdoc is able to display the doc right after the
installatin, but the files are not found:

hille@amd64-sid:~$ dpkg -L texlive-science-doc|grep html
/usr/share/doc/texlive-doc/latex/bosisio/accenti.html
/usr/share/doc/texlive-doc/latex/bosisio/dblfont.html
/usr/share/doc/texlive-doc/latex/bosisio/envmath.html
/usr/share/doc/texlive-doc/latex/bosisio/evenpage.html
/usr/share/doc/texlive-doc/latex/bosisio/graphfig.html
/usr/share/doc/texlive-doc/latex/bosisio/index.html
/usr/share/doc/texlive-doc/latex/bosisio/mathcmd.html
/usr/share/doc/texlive-doc/latex/bosisio/quotes.html
/usr/share/doc/texlive-doc/latex/bosisio/sobolev.html
/usr/share/doc/texlive-doc/latex/isomath/README.html
/usr/share/doc/texlive-doc/latex/isomath/isomath.html
/usr/share/doc/texlive-doc/latex/isomath/isomath.sty.html
/usr/share/doc/texlive-doc/latex/polexpr/polexpr.html
/usr/share/doc/texlive-doc/latex/tablor/tablor.html
hille@amd64-sid:~$ texdoc polexpr
Sorry, no documentation found for "polexpr".
If you are unsure about the name, try full-text searching on CTAN.
Search form: 

I had to run mktexlsr manually before texdoc starts working:

root@amd64-sid:~# mktexlsr
mktexlsr: Updating /usr/local/share/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.

hille@amd64-sid:~$ texdoc polexpr
hille@amd64-sid:~$ xterm: bad command line option "-x"

usage:  xterm [-/+132] [-C] [-Sccn] [-T string] [-/+ah] [-/+ai] [-/+aw]


As the postinst script of the package is generated by dh_installtex,
the problem is probably not sitting in the doc package itself. This
issue is just a reminder I'll reassign, once I know the correct
package.

Hilmar

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Jul 31 08:15 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 2470 Jul 31 08:15 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 15:28 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jul 10 03:09 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jul 10 03:09 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Mar  7 10:01 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jul 10 03:09 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jul 10 03:09 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3342 Jul 11 14:12 
/var/lib/texmf/tex/generic/config/language.dat
###

Bug#933516: gnome-keyring: should expose whether it is using an unencrypted keyring

[Helmut Grohne]

Package: gnome-keyring
Version: 3.28.2-5
Severity: important
Tags: security

I've come accross a bad interaction between gnupg2 and gnome-keyring.
With the help of Daniel Kahn Gillmor, I could sort out some of the
causes. In essence, pinentry-gnome3 focus-steals a check box that
effectively stores your gpg pass phrase unencrypted on disk forever.

gnome-keyring is a dependency of other packages (such as evolution) and
as such not conciously installed. Once installed, it automatically
starts and provides its services to client applications. It somehow
decides how to store its keyring and the default seems to be encrypted,
but in some situations it degrades to an unencrypted keyring without any
user interaction. You cannot rely on your gnome-keyring to be encrypted.
Now pinentry-gnome3 offers a checkbox to store your gpg pass phrase in
this (possibly unencrypted) keyring. pinentry-gnome3 has the habit of
stealing focus, which is prone to unintended actions such as checking
exactly that box.

It is difficult to blame any single one of these aspects for the whole
interaction. Each aspect makes sense of its own, but the combination is
bad.

To alleviate that, Daniel proposes that gnome-keyring (or maybe it is
libsecret, please reassign if necessary) communicates how the keyring is
stored. Then, client applications such as pinentry-gnome3 can base
policy decisions on the results. It would make sense for pinentry-gnome3
to only offer the "save in password manager" checkbox if the keyring is
actually protected in some way. The first step to getting there is
providing the information (== this bug report).

Daniel also provided a way to prevent this interaction in general:
echo no-allow-external-cache >> ~/.gnupg/gpg-agent.conf
Doing so prevents any pinentry to ever share its passphrase with other
applications such as gnome-keyring. Depending on how you use gpg (e.g.
when password-store is your primary password manager), this may be your
intended policy. It seems though that --no-allow-external-cache is not a
sane default standard gnome installations.

Helmut

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Steven Shiau]

Hi Dr. Philip,

Thank you very much for your explanation. It's nice to know you are 
still watching squashfs-tools, and let us know where the problem is for 
the package squashfs-tools in the Debian repository. I salute you.

Appreciate.

Steven

On 2019/7/31 上午 11:01, Phillip Lougher wrote:

Hi Steven,

The reason why the hacked Debian version of Mksquashfs performs badly
is because the Debian "maintainer" has applied a so called
reproducibility patch that *completely* breaks the parallelism in
Mksquashfs.

The offending patch is 0016-remove-frag_deflator_thread.patch

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjo0r7Bkd7jAhWLi1wKHaFTCTIQFjAAegQIARAB&url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fatt%3D1%3Bbug%3D919207%3Bfilename%3D0016-remove-frag_deflator_thread.patch%3Bmsg%3D24&usg=AOvVaw0EmPWZdGm1kergUjSyBGyP

As Squashfs author and maintainer I would not recommend *anyone* to
use the squashfs-tools currently packaged by Debian.

As for "squashfs-tools-ng", this is a rogue project masquerading as an
official new upstream.  It is neither official nor a new upstream.  As
Squashfs author and maintainer I completely disassociate that project
with the Squashfs project.

I have publicly stated that this project is spreading falsehoods and
that it is defamatory to me as the Squashfs author and maintainer.

See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#34

Yours

Dr Phillip Lougher
Squashfs author and maintainer


--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#933515: ITP: r-cran-tufte -- Tufte's Styles for R Markdown Documents

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: r-cran-tufte
  Version : 0.5
  Upstream Author : Yihui Xie
* URL : https://cran.r-project.org/package=tufte
* License : MIT
  Programming Lang: GNU R
  Description : Tufte's Styles for R Markdown Documents

Provides R Markdown output formats to use Tufte styles for PDF and HTML output.
The Tufte handout style is a style that Edward Tufte uses in his books and
handouts. Tufte’s style is known for its extensive use of sidenotes, tight
integration of graphics with text, and well-set typography. This style has been
implemented in LaTeX and HTML/CSS, respectively.

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

Bug#933385: [Pkg-libvirt-maintainers] Bug#933385: libvirt-daemon: encrypted qemu virtual machines do not start after upgrade to buster: permission denied

[Dominik Reusser]

Hi Guido,
thanks for your support.

I can confirm that changes to /etc/apparmor.d/libvirt/TEMPLATE.qemu are
taking effect. Besides the secret file, also the location of my
vm-image-files needs to be configured in the template file.

I added the following to get the VM running:

  /etc/libvirt/secret/** r,
  /var/lib/libvirt/images/** rwk,

Greetings
Dominik


Am Di., 30. Juli 2019 um 11:50 Uhr schrieb Guido Günther :

> control: -1 retitle qemu domain with encryption via qemu:commandline
> denied by apparmor
> control: -1 tag wontfix
>
> Hi Dominik,
> On Tue, Jul 30, 2019 at 11:29:49AM +0200, Dominik Reusser wrote:
> >   
> > 
> >  value='secret,id=sec0,file=/etc/libvirt/secrets/Feigenbaum.secret'/>
> > 
> >  value='driver=qcow2,file.filename=/var/lib/libvirt/images/Feigenbaum.qcow2,encrypt.key-secret=sec0'/>
> >   
>
> So you're using custom command line arguments. Which is not supported:
>
> https://libvirt.org/drvqemu.html#qemucommand
>
> since there's no way for libvirt's apparmor helper to figure out what
> you want.
>
> You should use libvirt's volume encryption:
>
> https://libvirt.org/formatstorageencryption.html#StorageEncryption
>
> if that fails either we need to fix that but that's something we can
> support since we have the information in a structured form and can make
> virt-aa-helper know about it.
>
> If you want to keep using apparmor and your current configuration modify
>
> /etc/apparmor.d/libvirt/TEMPLATE.qemu
>
> to allow access to that file. Something like
>
> /etc/libvirt/secrets/** r,
>
> might already do the trick.
>
> Note that this will allow all domains to access that file but it might
> be better than turning off apparmor completely.
>
> In case you work something out please add this to the bug since others
> might be hitting issues with custom command lines too.
>
> Cheers,
>  -- Guido
>

Bug#932618: transition: librsync

[Andrey Rahmatullin]

On Wed, Jul 31, 2019 at 02:06:50AM +, Holger Levsen wrote:
> > Turns out I had some extra time for this flying back from DebConf and it
> > needed changes to only one file for this, so new rdiff-backup with
> > librsync2 was uploaded yesterday...
> 
> src:librsync is currently still to be removed from bullseye on August
> 9th, because #776246 was only fixed in experimental...
In experimental and unstable.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#932428: , Bug#932767, Bug#932781: gnome-shell crashes involving monitor changes

[Jörn Heissler]

On Tue, Jul 30, 2019 at 11:19:38 +0100, Simon McVittie wrote:
> I've found an upstream commit that might be the solution for all of these
> crashes. Please try mutter 3.30.2-8 and gnome-shell 3.30.2-10 when they
> become available in unstable. After upgrading you will need to log out
> and back in (or reboot) for the new code to be used.
> 
> The actual fix is in mutter, but the updated gnome-shell has a different
> crash fix, and while you're restarting GNOME anyway we might as well get
> wider testing for the updated gnome-shell too...

I now installed gnome-shell==3.30.2-10 and mutter==3.30.2-8. No further
crashes yet. Should there be another crash, I'll let you know.

Thank you!


signature.asc
Description: PGP signature

Bug#900890: jugglemaster is dead upstream

[Helmut Grohne]

Control: tags -1 + bullseye sid

Hi Olly,

On Wed, Jul 31, 2019 at 10:52:42AM +1200, Olly Betts wrote:
> We're trying to move wx dependencies to using the GTK3 build of wx (see
> #933452).  In many cases just updating the B-Ds should be enough, but
> each package updated really needs testing so now seems a good time to
> get jugglemaster out of testing (assuming you still plan not to have it
> in bullseye).

Given that the instructions were very easy, I simply performed the
update and tested jugglemaster aferwards. So #933452 likely isn't going
to cause problems.

I expect that this is not the last transition in the bullseye cycle. For
this reason I intend to continue the deprecation plan.  Having
jugglemaster removed from testing means that its deprecation becomes
more visible while still being reversible if someone speaks up.

Thank you for your previous and current porting work.

Helmut

Bug#933505: bamtools - ppc64el -run-unit-test hangs

[Andreas Tille]

Control: tags -1 help

Hi,

unfortunately I have no idea what to do to solve this
except to exclude this architecture.  Any hint would
be more than welcome.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#478594: latex-beamer: Please support email on title slide

[Josh Triplett]

On Tue, Jul 30, 2019 at 09:34:15PM +0200, Hilmar Preuße wrote:
> Am 30.04.2008 um 00:49 teilte Josh Triplett mit:
> 
> Hi Josh,
> 
> I'm going through some old bugs.
> 
> > I often want to put my email address on the title slide, so people who
> > see my presentation on the web have a way to contact me.  Currently,
> > if I want to do this with beamer, either I must use the hack of
> > putting it in the author field (which disrupts other uses of the
> > author string in the presentation theme), or I must manually construct
> > a title slide.  I'd like to have an optional email command which
> > specifies an email address to use on the title slide.
> > 
> I'm not familiar w/ beamer. Does there exists an acceptable solution yet?

No, the situation has not changed at all. The issue remains.

Bug#933514: tmux: Screen garbling in ncurses apps

[T. Joseph Carter]

Package: tmux
Version: 2.9a-2
Severity: important

The latest version of tmux has issues with screen updates under GNOME
Terminal with ncurses apps. This causes eg weechat's scrollback (pgup,
pgdn) to not draw correctly, causes specific issues with aptitude as
well.

I think this may be the result of the cherry-pick of 38b8a198bac6 from
upstream, you may need an additional patch as well.

I suspect the version of tmux found in experimental will not have this
problem, but I haven't tested it yet. I expect you're holding it due to
the freeze, but I do not believe 2.9a-2 makes a good release candidate.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.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 tmux depends on:
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20190713-1
ii  libutempter01.1.6-3+b1

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Phillip Lougher]

On Wed, Jul 31, 2019 at 4:01 AM Phillip Lougher
 wrote:
>
> Hi Steven,
>
> The reason why the hacked Debian version of Mksquashfs performs badly
> is because the Debian "maintainer" has applied a so called
> reproducibility patch that *completely* breaks the parallelism in
> Mksquashfs.
>

I would recommend all Debian users to compile the Squashfs-tools from
source, from the *official* repository.

https://github.com/plougher/squashfs-tools

Yours sincerely

Dr Phillip Lougher
Squashfs Author and Maintainer

> The offending patch is 0016-remove-frag_deflator_thread.patch
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjo0r7Bkd7jAhWLi1wKHaFTCTIQFjAAegQIARAB&url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fatt%3D1%3Bbug%3D919207%3Bfilename%3D0016-remove-frag_deflator_thread.patch%3Bmsg%3D24&usg=AOvVaw0EmPWZdGm1kergUjSyBGyP
>
> As Squashfs author and maintainer I would not recommend *anyone* to
> use the squashfs-tools currently packaged by Debian.
>
> As for "squashfs-tools-ng", this is a rogue project masquerading as an
> official new upstream.  It is neither official nor a new upstream.  As
> Squashfs author and maintainer I completely disassociate that project
> with the Squashfs project.
>
> I have publicly stated that this project is spreading falsehoods and
> that it is defamatory to me as the Squashfs author and maintainer.
>
> See:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29
>
> and
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#34
>
> Yours
>
> Dr Phillip Lougher
> Squashfs author and maintainer

Bug#931377: RFS: gcc-8-doc/8.3.0-1 [put in ITP, ITA, RC, NMU if applicable]

[Adam Borowski]

On Tue, Jul 30, 2019 at 10:43:08PM +0300, Dmitry Eremin-Solenikov wrote:
> > > I can also backport gcc-doc-defaults afterwards.
> >
> > Good idea, yeah.
> 
> Uploaded to mentors.d.o

In bpo-NEW, thanks!  These packages were sorely missing from Buster.

About that VLOCAL part: I think it'd be nice to have it in unstable as well,
to ease future backports, and to reduce their diffs.  The variable would be
empty in regular versions.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Phillip Lougher]

Hi Steven,

The reason why the hacked Debian version of Mksquashfs performs badly
is because the Debian "maintainer" has applied a so called
reproducibility patch that *completely* breaks the parallelism in
Mksquashfs.

The offending patch is 0016-remove-frag_deflator_thread.patch

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjo0r7Bkd7jAhWLi1wKHaFTCTIQFjAAegQIARAB&url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fatt%3D1%3Bbug%3D919207%3Bfilename%3D0016-remove-frag_deflator_thread.patch%3Bmsg%3D24&usg=AOvVaw0EmPWZdGm1kergUjSyBGyP

As Squashfs author and maintainer I would not recommend *anyone* to
use the squashfs-tools currently packaged by Debian.

As for "squashfs-tools-ng", this is a rogue project masquerading as an
official new upstream.  It is neither official nor a new upstream.  As
Squashfs author and maintainer I completely disassociate that project
with the Squashfs project.

I have publicly stated that this project is spreading falsehoods and
that it is defamatory to me as the Squashfs author and maintainer.

See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#34

Yours

Dr Phillip Lougher
Squashfs author and maintainer

Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv

[Jon Hreg]

Probably it is a bug in the libleveldb.
I hope, however, that it is sufficient to have reported the bug here, and in 
case the cause is in another package, the maintainer of that package will be 
notified.

Bug#933513: glibc: mips{64,n32}r6{,el} ln wrong ld.so filename

[YunQiang Su]

Package: src:glibc
Version: 2.28-10

diff -Nru glibc-2.28/debian/sysdeps/mips64r6el.mk
glibc-2.28/debian/sysdeps/mips64r6el.mk
--- glibc-2.28/debian/sysdeps/mips64r6el.mk 2019-02-10
16:13:53.0 +
+++ glibc-2.28/debian/sysdeps/mips64r6el.mk 2019-05-01
17:24:19.0 +
@@ -60,7 +60,7 @@
 # create a symlink for the 32 bit dynamic linker in /lib
 define libc6-mips32_extra_pkg_install
 mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf /libo32/ld-linux-mipsn8.so.1 debian/libc6-mips32/lib
 endef

 endif # multilib
diff -Nru glibc-2.28/debian/sysdeps/mips64r6.mk
glibc-2.28/debian/sysdeps/mips64r6.mk
--- glibc-2.28/debian/sysdeps/mips64r6.mk   2019-02-10
16:13:53.0 +
+++ glibc-2.28/debian/sysdeps/mips64r6.mk   2019-05-01
17:24:19.0 +
@@ -60,7 +60,7 @@
 # create a symlink for the 32 bit dynamic linker in /lib
 define libc6-mips32_extra_pkg_install
 mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf /libo32/ld-linux-mipsn8.so.1 debian/libc6-mips32/lib
 endef

 endif # multilib
diff -Nru glibc-2.28/debian/sysdeps/mipsn32r6el.mk
glibc-2.28/debian/sysdeps/mipsn32r6el.mk
--- glibc-2.28/debian/sysdeps/mipsn32r6el.mk2019-02-10
16:13:53.0 +
+++ glibc-2.28/debian/sysdeps/mipsn32r6el.mk2019-05-01
17:24:19.0 +
@@ -60,7 +60,7 @@
 # create a symlink for the 32 bit dynamic linker in /lib
 define libc6-mips32_extra_pkg_install
 mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf /libo32/ld-linux-mipsn8.so.1 debian/libc6-mips32/lib
 endef

 endif # multilib
diff -Nru glibc-2.28/debian/sysdeps/mipsn32r6.mk
glibc-2.28/debian/sysdeps/mipsn32r6.mk
--- glibc-2.28/debian/sysdeps/mipsn32r6.mk  2019-02-10
16:13:53.0 +
+++ glibc-2.28/debian/sysdeps/mipsn32r6.mk  2019-05-01
17:24:19.0 +
@@ -62,7 +62,7 @@
 # create a symlink for the 32 bit dynamic linker in /lib
 define libc6-mips32_extra_pkg_install
 mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf /libo32/ld-linux-mipsn8.so.1 debian/libc6-mips32/lib
 endef

 endif # multilib

-- 
YunQiang Su

Bug#933512: RM: python-libconcord -- NBS; Python 2 bindings package retired

[Scott Talbert]

Package: ftp.debian.org
Severity: normal

Bug#933511: partman-base: reformatting md raid 0.90 metadata does not delete metadata

[Michael Hudson-Doyle]

Source: partman-base
Severity: normal
Tags: d-i patch

Dear Maintainer,

As reported in

https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558

installing over a drive previously used as a md raid can leave a system
that does not boot.  I tried and failed to convince parted upstream this
was their bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853) so
it probably makes sense to fix it in parted_server instead.

I'm attaching a WIP patch to this report. I'll probably upload something
like this to Ubuntu once I've tested it a bit.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-55-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/Makefile.am b/Makefile.am
index f93bf8e..e8027ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,8 @@ bin_PROGRAMS = parted_server parted_devices partmap
 bin_SCRIPTS = partman partman-command partman-commit
 
 parted_server_SOURCES = parted_server.c
-parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS)
+parted_server_CPPFLAGS = $(blkid_CFLAGS)
+parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS) 
$(blkid_LIBS)
 
 parted_devices_SOURCES = parted_devices.c
 parted_devices_LDADD = $(libparted_LIBS)
diff --git a/configure.ac b/configure.ac
index 987cc4d..3d081ff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,6 +7,7 @@ AC_DEFINE([_POSIX_C_SOURCE], [200809L], [Define the POSIX 
version])
 AC_PROG_CC
 
 PKG_CHECK_MODULES([libparted], [libparted])
+PKG_CHECK_MODULES([blkid], [blkid])
 
 AC_ARG_VAR([libparted_fs_resize_LIBS], [linker flags for libparted-fs-resize])
 AC_MSG_CHECKING([for libparted >= 3.1])
diff --git a/debian/changelog b/debian/changelog
index 51396e4..47c7341 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+partman-base (206ubuntu4~ppa4) eoan; urgency=medium
+
+  * parted_server.c: Wipe all known superblocks from device in
+command_new_label. (LP: #1828558)
+
+ -- Michael Hudson-Doyle   Tue, 30 Jul 2019 
10:18:37 +1200
+
 partman-base (206ubuntu3) eoan; urgency=medium
 
   * Revert previous upload, it is intentional to use non-part names, to
diff --git a/debian/control b/debian/control
index 2556d5d..e5d08a7 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: standard
 Maintainer: Ubuntu Installer Team 
 XSBC-Original-Maintainer: Debian Install System Team 

 Uploaders: Anton Zinoviev , Colin Watson 
, Christian Perrier , Max Vozeler 

-Build-Depends: debhelper (>= 9), dh-autoreconf, dh-di (>= 2), pkg-config, 
po-debconf (>= 0.5.0), libparted-dev (>= 2.2)
+Build-Depends: debhelper (>= 9), dh-autoreconf, dh-di (>= 2), pkg-config, 
po-debconf (>= 0.5.0), libparted-dev (>= 2.2), libblkid-dev
 XS-Debian-Vcs-Browser: https://salsa.debian.org/installer-team/partman-base
 XS-Debian-Vcs-Git: https://salsa.debian.org/installer-team/partman-base.git
 
diff --git a/parted_server.c b/parted_server.c
index 41784b7..bfff500 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
Logging
@@ -1864,6 +1865,57 @@ command_change_file_system()
 oprintf("OK\n");
 }
 
+/*
+ * wipe all superblocks libblkid knows about from a device
+ * (condensed from wipefs in util-linux)
+ */
+static int
+do_wipe(char *devname)
+{
+blkid_probe pr = NULL;
+int fd = -1;
+int r = -1;
+
+fd = open(devname, O_RDWR | O_EXCL);
+
+log("do_wipe open(%s), %d", devname, fd);
+
+if (fd < 0)
+goto error;
+
+pr = blkid_new_probe();
+if (!pr || blkid_probe_set_device(pr, fd, 0, 0) != 0) {
+log("setting up probe failed");
+goto error;
+}
+
+blkid_probe_enable_superblocks(pr, 1);
+blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_MAGIC |  /* 
return magic string and offset */
+  BLKID_SUBLKS_TYPE |   /* 
return superblock type */
+  BLKID_SUBLKS_BADCSUM);/* 
accept bad checksums */
+
+blkid_probe_enable_partitions(pr, 1);
+blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC |
+ BLKID_PARTS_FORCE_GPT);
+
+while (blkid_do_probe(pr) == 0) {
+char *type = "unknown";
+blkid_probe_lookup_value(pr, "TYPE", &type, NULL);
+log("wiping superblock of type %s", type);
+if (blkid_do_wi

Bug#932618: transition: librsync

[Holger Levsen]

On Tue, Jul 30, 2019 at 09:06:32AM +0300, Otto Kekäläinen wrote:
> Turns out I had some extra time for this flying back from DebConf and it
> needed changes to only one file for this, so new rdiff-backup with
> librsync2 was uploaded yesterday...

src:librsync is currently still to be removed from bullseye on August
9th, because #776246 was only fixed in experimental...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#933510: nfs-kernel-server: nproc manpage description confuses me

[Trent W. Buck]

Package: nfs-kernel-server
Version: 1:1.3.4-2.5
Severity: minor
File: /usr/share/man/man8/rpc.nfsd.8.gz

The manpage says:

> nproc
>
> specify the number of NFS server threads.
> By default, just one thread is started.
> However, for optimum performance several threads should be used.
> The actual figure depends on the number of and the work load created by 
> the NFS clients, but
> a useful starting point is 8 threads.
>
> Effects of modifying that number can be checked using the nfsstat(8) 
> program.

The "just one thread" confused me, because it sounds (to me) like it's saying 
"nproc is 1 by default".
But this is clearly false - nproc is 8 by default in all of these places:

https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/utils/nfsd/nfsd.c/#L32

https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/debian/nfs-utils_env.sh/#L12

https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/debian/nfs-kernel-server.default/#L2

I now think nproc is the *MAXIMUM* number of knfsd kernel threads, and that
the "by default" line is really just saying that Linux will start one knfsd 
up-front, and
start and stop additional knfsd kernel threads on-demand as NFS client load 
grows/shrinks.

If my current understanding is correct, I suggest the following wording:

  nproc
the maximum number of NFS server kernel threads.

A single thread is started immediately.
Additional threads are started/stopped automatically as demand 
grows/shrinks.

The optimal nproc depends on both the number and workload of NFS clients.
The default is 8, which is a good first guess.
Do not set nproc to 1, as that will (usually? always?) be slow.
Use nfsstat(8) to determine optimal nproc for your site.

Bug#888899: e4defrag: Unsigned integer overflow in failure count when new files created

[Laurence Parry]

I just ran e4defrag on an image cache updated to buster, which had had
some files cleared and so had space to add new ones. This resulted in
following output, demonstrating an invalid failure count close to
ULONGLONG_MAX as predicted in #15:

# e4defrag -v /cache/
...
[291614/288339]/cache/3e/64d513fb1b5568145d22a2d665d58a3e:  100%
extents: 1 -> 1   [ OK ]

Success:[ 291356/288339 ]
Failure:[ 18446744073709548599/288339 ]
Total extents:  1817550->1326154
Fragmented percentage:   18%->16%

# e4defrag --version
e4defrag 1.44.5 (15-Dec-2018)

-- 
Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Steven Shiau]

On 2019/3/31 上午 02:41, László Böszörményi (GCS) wrote:

Hi Steven,

On Sat, Feb 2, 2019 at 10:03 AM Steven Shiau  wrote:

The mksquashfs from squashfs-tools 1:4.3-11 somehow can not make use all
CPU cores. I found this when making a Debian live Sid system on my
Stretch amd64 machine. Hence I have tried different versions of
squashfs-tools. For mksquashfs from squashfs-tools 1:4.3-11 , I ran it by:
time sudo mksquashfs squashfs-root filesystem.squashfs.new -b 1024k
-comp xz -Xbcj x86 -e boot -no-progress

  Is there any way I can generate that set of files / directory you are
using for mksquashfs?
Anyway, please try the upcoming squashfs-tools package release[1] and
report back to me. Indeed it is slower than -9 on my data, but only
around 20%.

Thanks in advance,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/squashfs-tools_4.3-12.dsc


Hi László,
This issue still remains in 1:4.3-13. Anything I can help to improve this?
Or shall we gradually switch to squashfs-tools-ng is the upstream is more 
active:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965
Thank you very much.

Steven
--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI

[Chris Lamb]

Felix Lechner wrote:

> > caching the result of the former if the tests and some other key files
> > have not changed.
> 
> Will it also force an update of the test packages when the build chain
> has changed? It may expose Lintian bugs like #932339.

Whilst my *current* implementation does not rebuild if a build-depends
version changes, we would only need to include these package version
in the hash key. It would then (correctly) cache miss in that instance
and rebuild the test packages. It's a shame we would not have
a .buildinfo file at this point...

I'm not going to implement this bit just yet until I solve the more
deeper problem of it, well, not actually caching anything at the
moment. See previous messages for more background.


Regards,

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

Bug#933370: chrony won't start

[Ross Boylan]

[Ross]
> >I've run into other problems with services starting before all
> >filesystems were mounted; I wonder if that's an issue here (not on the
> >machine right now).
> >i.e., /usr isn't mounted when timesync first checks for chrony, and so
> >it thinks things are OK.
>
[Vincent]
> I don’t think it’s feasible as the -.mount unit is unconditionally
> active. As for separate /usr partition, that’s the role of the initramfs
> to mount it.

Unfortunately, this is one area I can speak from authority: it is
absolutely possible for services to start before all critical mounts
have happened. Bug#933139 has gory details.  Among other issues, bind
attempted to start before /var was mounted.

As for how or if systemd and initramfs are integrated, I don't know.
I am using an initrd, and it didn't prevent the problem just
mentioned.

For something that was supposed to make our lives easier (replace
twisty code with simple declarations), systemd seems to be rather
hard.

Ross

P.S. I'll do a whole file override if it comes to hacking the
conflicts directive.  Alternatively, would just disabling, in the
systemd sense, timesyncd make things work?

Bug#932584: Epydoc and Pydoctor

[Kenneth Pronovici]

(I'm the maintainer for epydoc.)

I took a pass through the pydoctor code.  The epydoc module is
imported in pydoctor/html.py, where it's an optional import:

try:
from epydoc.markup import epytext
EPYTEXT = True
except:
print "no epytext found"
EPYTEXT = False

Later on, in the doc2html() method, the code checks EPYTEXT and falls
back on a boring docstring implementation ("Generate an HTML
representation of a docstring in a really boring way") if the module
isn't available.   This file has a docstring which says "The old HTML
generator.  Deprecated, do not use", so it may not be relevant.

The epydoc module is also imported in pydoctor/epydoc2stan.py:

def get_parser(formatname):
try:
mod = __import__('epydoc.markup.' + formatname,
 globals(), locals(), ['parse_docstring'])
except ImportError, e:
return None, e
else:
return mod.parse_docstring, None

Like html.py, epydoc2stan.py falls back on a boring docstring method
if get_parser() returns None.

Based on this analysis, it seems to me that epydoc isn't a strict
dependency for pydoctor.  I think that pydoctor should still continue
to work even without the epydoc module available, albeit with somewhat
different output.

Given that epydoc does not work properly in Python 3, and it's beyond
my capabilities to fix it, there aren't too many options here.  Either
we remove pydoctor's dependency on epydoc, or we remove pydoctor from
the archive.

I don't see any evidence that upstream is developing a Python 3
version of this code.  This means that python-pydoctor will have to be
removed from the archive eventually.   Maybe now is the time to do it?

Otherwise, I will see if I can determine how well the package works
without epydoc installed.  If it works (i.e. doesn't blow up) and I
don't hear back with other instructions, I will eventually NMU my
changes to remove the epydoc dependency.   Given that I haven't gotten
any replies for more than 18 months now, I won't wait that long before
doing this NMU.

KEN

-- 
Kenneth J. Pronovici 

Bug#933509: oz depends on cruft package.

[Peter Michael Green]

Package: oz
Version: 0.16.0-2
Severity: serious
Tags: bullseye, sid

oz depends on the python-monotonic binary package which is no longer 
built by the python-monotonic source package.

Bug#933508: borg umount fails because fusermount command is missing

[Marcel Ranft]

Package: borgbackup
Version: 1.0.9-1
Severity: minor

An exception occurs when trying to use "borg umount" because "fusermount" could 
not be found. I think borgbackup is missing a dependency for the fuse package.

Steps to reproduce the error:
apt install borgbackup
borg init --encryption=none /opt/testrepo/
borg create /opt/testrepo::testarchive /opt/scripts/
borg mount /opt/testrepo/::testarchive /opt/mnt/
borg umount /opt/mnt

error message:
Local Exception.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 2052, in main
    exit_code = archiver.run(args)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1997, in run
    return func(args)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 564, in do_umount
    return umount(args.mountpoint)
  File "borg/platform_linux.pyx", line 148, in borg.platform_linux.umount 
(borg/platform_linux.c:4217)
  File "/usr/lib/python3.5/subprocess.py", line 247, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1282, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'fusermount'

Platform: Linux services 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 
(2019-07-19) x86_64
Linux: debian 9.9
Borg: 1.0.9  Python: CPython 3.5.3
PID: 8244  CWD: /opt
sys.argv: ['/usr/bin/borg', 'umount', '/opt/mnt']
SSH_ORIGINAL_COMMAND: None

Bug#933370: chrony won't start

[Vincent Blut]

On Tue, Jul 30, 2019 at 01:27:55PM -0700, Ross Boylan wrote:

On Tue, Jul 30, 2019 at 12:57 PM Vincent Blut  wrote:


On Tue, Jul 30, 2019 at 12:05:23AM -0700, Ross Boylan wrote:
>See below.
>
>On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut  wrote:
>
>> Hello Ross,
>>
>> On Mon, Jul 29, 2019 at 12:13:16PM -0700, Ross Boylan wrote:
>
>> >It looks as if systemd-timesyncd is creating a stop job for chrony
>> >even though the former includes
>
>>
>> What’s the status of systemd-timesyncd here? Is it started?
>
>I'm never sure with systemd exactly which things I should focus on for
>the status, but the results below see to indicate systemd-timesyncd is
>not running even though it's enabled.  The start condition failed,
>which I gather is not quite good enough to assure it never started.
>
>root@barley:~# systemctl status systemd-timesyncd
>● systemd-timesyncd.service - Network Time Synchronization
>   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
>enabled; vendor preset: enabled)
>  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
>   └─disable-with-time-daemon.conf
>   Active: inactive (dead)
>Condition: start condition failed at Mon 2019-07-29 12:35:49 PDT; 11h ago
>   └─ ConditionFileIsExecutable=!/usr/sbin/chronyd was not met
> Docs: man:systemd-timesyncd.service(8)
>
>Jul 29 12:35:49 barley systemd[1]: Condition check resulted in Network 
Time…ped.
>Hint: Some lines were ellipsized, use -l to show in full.

For the avoidance of doubt, this is the result right after booting your
system?


I ran the commands immediately above well after the start of the
system, though I think they were the same just after the start.
However, I had manually started chrony before getting the previous output.


Ok, thanks!


Anyway, this is the expected state.

>> Also, could you attach the output of:
>> $ systemctl show systemd-timesyncd.service
>
>root@barley:~# date; systemctl show systemd-timesyncd.service
> [snip…]

Nothing seems suspicious here. However, I observe that systemd-timesyncd
is pulled in way earlier than chronyd (and all other NTP implementation
provided in Debian) in the boot process. This is due to its unit file
which contains sysinit.target in the “Before=” dependency directive.

>> Thanks for these logs. To have a bigger picture, could you please

..


So far, the initial transactions seem correctly done:
↳systemd-timesyncd.service starts before sysinit.target


Except, at least in my reading of the man page, it should never start
because one of its conditions fails.
You pointed to a bug saying it doesn't actually work that way.


Sorry, I took an unfortunate shortcut. I should have said that the units 
and their dependencies are *queued* to a temporary transaction waiting 
for systemd to check the consistency of that transaction. But they are 
not yet in the run queue.



I've run into other problems with services starting before all
filesystems were mounted; I wonder if that's an issue here (not on the
machine right now).
i.e., /usr isn't mounted when timesync first checks for chrony, and so
it thinks things are OK.


I don’t think it’s feasible as the -.mount unit is unconditionally 
active. As for separate /usr partition, that’s the role of the initramfs 
to mount it.



[snip…]

systemd-timesyncd.service wants chrony.service to be stopped to
continue.


I didn't get that from the config files.  For timesyncd they seemed to
say it shouldn't start if chrony was present, not that chrony should
stop.


Here, this isn’t the “ConditionFileIsExecutable=!/usr/sbin/chronyd” that 
is verified, but “Conflicts=chrony.service”. The former is checked 
latter in the process.
As systemd-timesyncd conflicts on chrony, if it wants to start it will 
need to stop chrony. But as above, I made a nasty shortcut as that part 
of the log don’t show what has been run, but what has been *queued* in 
the transaction.



However, chrony's files say it should not run if timesyncd (or several
other timeservices) is running.


Well, it says that if it wants to start, systemd-timesyncd will have to 
be stopped.



>Jul 29 11:30:46 barley systemd[1]: Added job chrony.service/stop to
>transaction.
>Jul 29 11:30:46 barley systemd[1]: chrony.service: chrony.service/stop
>would change existing job.
>Jul 29 11:30:46 barley systemd[1]: chrony.service: Deleting
>chrony.service/stop to minimize impact.

Here I’m not sure about what’s happening. I *think* that systemd rejects
the request for the chrony.service to be stopped.


I thought it was rejecting the request because it knows it already has
received a stop request.


Really, I don’t know.


My knowledge of systemd is meager, and so you should weight my
statements accordingly :)

Nothing more to add and so I'll snip the rest.  It's weird how it
seems to be looping, but maybe those are multiple log entries for the
same event?

Thanks for your offer of help on the overrides.  I think I know how to
do it, but I do have one quest

Bug#932109: libglib2.0-0: Caja crash due buggy libglib2.0-0 in Buster

[Dio Putra]

Sorry, I had been quite busy for several days.

On Wed, 17 Jul 2019 22:59:57 +0100 Simon McVittie  wrote:

Control: reassign -1 caja 1.20.3-1

On Thu, 18 Jul 2019 at 04:28:00 +0700, Dio Putra wrote:
>Stack trace of thread
> 1413:
>#0 0x7fa05c053673
> g_type_check_instance_cast (libgobject-2.0.so.0)
>#1 0x562d365df197
> caja_extensions_get_for_type (caja)
>#2 0x562d365f47f1
> caja_file_invalidate_extension_info_internal (caja)

This looks like it indicates a bug in caja: caja_extensions_get_for_type()
calls g_type_check_instance_cast() and passes an invalid object pointer
to it.

Looking at the code of caja_extensions_get_for_type(), that would
probably mean that one of the Extension structs in the caja_extensions
linked list has ext->state set to a true value and ext->module pointing
to something that is not a valid object, probably freed memory. My guess
would be a reference-counting bug somewhere. (The G_OBJECT() macro
actually calls g_type_check_instance_cast().)

If you don't know for sure that a crash is caused by a library, it's
usually best to report it as a bug in the application/executable that
crashed, and let the maintainer of the application reassign it to the
library if they find evidence that it's a library bug. That way, the
bug report has all the details of the application/executable and all
the libraries it depends on.

I'm assuming that you have the version of caja from buster.

Yeah, it's caja from buster version.



Please tell the caja maintainers (via the bug address) whether there is
a way to reproduce this bug, like a particular sequence of actions that
makes caja crash: if there is, that will make it much more likely that
someone can find a solution.

Last time I remember that I had to editing the user-dirs.dirs file with:
$ sed -i 's/Destop/Desktop/g' $HOME/.config/user-dirs.dirs

Not sure how to reproduce this bug, it's quite hard for me due 
randomness of using caja.


It would also be useful to check the systemd journal for any log messages
that show warnings or errors from caja. If there aren't any, running caja
from a terminal might result in you seeing some warning messages from caja
before the crash - if so, those messages would be very useful information.

Running caja from terminal doesn't show any debug message. Like:
$ caja
$

There's no any warning/error.


smcv

Bug#900890: jugglemaster is dead upstream

[Olly Betts]

Control: severity -1 serious

On Wed, Jun 06, 2018 at 02:06:02PM +0200, Helmut Grohne wrote:
>  * After buster is released, raise severity of this bug to serious to
>kick it out of testing.
[...]
> If you happen to read this after buster without severity serious, I
> likely forgot and am happy if someone else does that.

OK - we're now at this stage, so I've raised the severity.

>  * If nobody complains, request removal from Debian.
> 
> If you happen to read this as someone porting jugglemaster to a newer
> library version (e.g. ffmpeg/wx/aa). Please speak up in this bug before
> performing the porting to avoid useless work. I'm happy to consider an
> accelerated deprecation if the need arises. I'm also happy to consider
> keeping it longer provided that it does not slow down any library
> transitions.

We're trying to move wx dependencies to using the GTK3 build of wx (see
#933452).  In many cases just updating the B-Ds should be enough, but
each package updated really needs testing so now seems a good time to
get jugglemaster out of testing (assuming you still plan not to have it
in bullseye).

Cheers,
Olly

Bug#932585: Does not seem to actually require epydoc

[Kenneth Pronovici]

The package has a Build-Depends-Indep and a Depends on python-epydoc,
but there is no reference to epydoc anywhere in the source code or in
the debian package structure.

It's not clear why these dependencies were added in 0.8.0~dev650-1
back in 2014.  However, the package builds successfully without
python-epydoc installed in my unstable chroot.

The INSTALL file with the source package says that everything should
be ok as long as the module imports cleanly.  I also tested this in my
unstable chroot.

Since it doesn't seem to be needed, I am going to NMU a new package
removing these dependencies.  That will resolve this bug.

KEN

-- 
Kenneth J. Pronovici 

-

mars:~/projects/dev/debian/unstable/pywbem> schroot -c unstable-amd64

mars:~/projects/dev/debian/buster/pywbem> python
Python 2.7.16+ (default, Jul  8 2019, 09:45:29)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywbem
>>>

mars:~/projects/dev/debian/buster/pywbem> apt-cache show python-pywbem
Package: python-pywbem
Status: install ok installed
Priority: extra
Section: python
Installed-Size: 847
Maintainer: Debian Python Modules Team

Architecture: all
Source: pywbem
Version: 0.8.0~dev650-1.1
Depends: python (<< 2.8), python (>= 2.7), python:any (>= 2.6.6-7~),
python-m2crypto, python-twisted-web, python-twisted-core
Description-en: Python WBEM Client and Provider Interface
 PyWBEM is a Python library that implements a Web Based Enterprise
 Management (WBEM) client.  It performs WBEM operations using the
 CIM-XML and CIM Operations over HTTP protocols as defined by the
 Distributed Management Task Force (DMTF).  WBEM is used to remotely
 describe and manage distributed computing environments.  It is a peer
 and perhaps successor to the SNMP protocol.
Description-md5: 4a8c6b688ada327da8965cfb75662489
Homepage: http://pywbem.sourceforge.net/

Bug#933507: RFS: openldap/2.4.48+dfsg-1~bpo10+1

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Dear mentors and backporters,

I am looking for a sponsor to perform the initial upload of openldap to 
buster-backports, since it will be NEW. I am DM for the package and can 
take care of future uploads myself.


Rationale for backporting: while the client library (libldap) is mature 
and stable, the OpenLDAP server (slapd) is more actively developed, so 
advanced slapd users often prefer to run the latest upstream version.


The backport is a simple rebuild; no changes are needed to build in 
buster at this time.


The package can be found on mentors.debian.net:

https://mentors.debian.net/package/openldap
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.48+dfsg-1~bpo10+1.dsc

The changes since stable are:

openldap (2.4.48+dfsg-1~bpo10+1) buster-backports; urgency=medium
.
  * Rebuild for buster-backports.
.
openldap (2.4.48+dfsg-1) unstable; urgency=medium
.
  * New upstream release.
- fixed slapd to restrict rootDN proxyauthz to its own databases
  (CVE-2019-13057) (ITS#9038) (Closes: #932997)
- fixed slapd to enforce sasl_ssf ACL statement on every connection
  (CVE-2019-13565) (ITS#9052) (Closes: #932998)
- added new openldap.h header with OpenLDAP specific libldap interfaces
  (ITS#8671)
- updated lastbind overlay to support forwarding authTimestamp updates
  (ITS#7721) (Closes: #880656)
  * Update Standards-Version to 4.4.0.
  * Add a systemd drop-in to set RemainAfterExit=no on the slapd service, so
that systemd marks the service as dead after it crashes or is killed.
Thanks to Heitor Alves de Siqueira. (Closes: #926657, LP: #1821343)
  * Use more entropy for generating a random admin password, if none was set
during initial configuration. Thanks to Judicael Courant.
(Closes: #932270)
  * Replace debian/rules calls to dpkg-architecture and dpkg-parsechangelog
with variables provided by dpkg-dev includes.
  * Declare R³: no.
  * Create a simple autopkgtest that tests installing slapd and connecting to
it with an ldap tool.
  * Install the new openldap.h header in libldap2-dev.

Thank you,
Ryan

Bug#932575: More Work

[Kenneth Pronovici]

I have filed a package removal request for spe (bug #933504), because
it appears to be unsupported upstream and there's no evidence that a
Python 3 version is under development.  I CC'd the maintainers and
uploaders.

I NMU'd python-mode a few minutes ago to remove the recommendation on
pychecker.  The package existed for several years without this
recommendation early in its life.  The main consequence is that users
will get an error if they try to run a pychecker-related command
without having pychecker installed.   Users can always install
pychecker manually if they want to keep using it.  I added
documentation in the README.Debian about this and pointed users at
pylint instead.

I'll remove the moreinfo tag on this bug if/when the package removal
for spe is executed.

KEN

-- 
Kenneth J. Pronovici 

Bug#570376: texdoc barfs if BROWSER has multiple colon-separated commands

[Julian Gilbey]

On Tue, Jul 30, 2019 at 10:21:22PM +0200, Hilmar Preuße wrote:
> Hi Julian,
> 
> I'm going through some old bugs.

Hi Hilmar,

Thanks for this!

> > I try running the command "texdoc eqnarray" and I get the error
> > message:
> > sh: links:lynx: not found
> > 
> > This is because my BROWSER environment variable contains "links:lynx",
> > as allowed in the specification of the BROWSER variable.
> > 
> > So texdoc should parse this variable (and perhaps others), using the
> > first one available.
> > 
> I can still reproduce the issue and I have some comments. I used the
> documentation progress20030701, which is in texlive-latex-extra-doc.
> 
> 1. What kind of specification are you referring to? Is this a Debian
> specification, if not where can I find it?

Ooh, that's a good question.

It seems that it was a project started by Eric Raymond, described
here: http://www.catb.org/~esr/BROWSER/ 

man(1) has a description of BROWSER matching this, and bts(1) follows
the same convention, as does the python webbrowser module,
apparently.

However, sensible-browser does not respect this, and I can't easily
find any other mentions of it.

Ho hum...  So it looks like it never really caught on.

> 2. In addition to variable browser you can set the var BROWSER_texdoc,
> which specifies just one browser program. This way you can make texdoc
> work w/ changing the value of BROWSER.

Yes, though that is a hack ;-)

I think the solution is just to ensure that BROWSER only has one
executable listed!

Best wishes,

   Julian

Bug#932769: have a look at patch from CentOS

[Thomas Lange]

First I can confirm this bug. Some time ago I had two servers which
caused a huge amount of dhcp requests to log the DHCP server (managed
by a different departement). They told me one server did 30 requests
per seconds.


I've looked at the CentOS 8 sources and found this patch:

>  # If we receive a DHCP offer in dhclient and it's DECLINEd in 
> dhclient-script,
>  # backoff for an amount of time before trying again
>  %patch6 -p1 -b .backoff

The patch is in the directory SOURCES called
dhcp-dhclient-decline-backoff.patch. Since I'm not good in C
programming it would be good I someone else can have a look if Debian
should include this patch. I'll attach the patch from Centos.



dhcp-dhclient-decline-backoff.patch
Description: Binary data

-- 
regards Thomas

Bug#929197: biber: FTBFS when separate libunicode-collate-perl package is installed

[Norbert Preining]

On Mon, 29 Jul 2019, Hilmar Preuße wrote:
> I did it the way round now: I adapted the patch from upstream so it
> applies to our repo. The package can and needs to be built w/
> libunicode-collate-perl > 1.27. All is on github now.

Thanks for your work. After acceptance, please tag and push the tag.
Thanks.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#930399: NMU for python-mode

[Kenneth Pronovici]

Later this evening, I will NMU python-mode to remove the Recommends:
pychecker from debian/control.

This change puts python-mode back to the state it was in as of 1.0-3.1
(prior to the fix for 458997). The package should still work in
general, except that the pychecker-related commands will fail unless
pychecker is installed manually.   I will also update
debian/README.Debian to make this clear.

KEN

-- 
Kenneth J. Pronovici 

Bug#933506: Fwd: Re: boost1.67- ppc64el -autopkgtest hangs

[Thierry fa...@linux.ibm.com]

Package: boost1.67
Version: 1.67.0-13

debci tests hangs for a while when on intel it pass in 30mn.
boost1.67  
1.67.0-13  
stable  
ppc64el  	Fail 
5h 20m 2s
boost1.67  
1.67.0-13  
testing  
ppc64el  	Fail 
	3h 42m 8s
boost1.67  
1.67.0-13  
unstable  
ppc64el  
Fail 	2h 21m 52s

Bug#933505: bamtools - ppc64el -run-unit-test hangs

[Thierry fa...@linux.ibm.com]

Package: bamtools
Version: 2.5.1+dfsg-3

bamtools-2.5.1+dfsg/debian/tests$ sh run-unit-test
6


_debci reports_
bamtools  
2.5.1+dfsg-3  
stable  	ppc64el 
 	Fail 	2h 49m 24s
bamtools  
2.5.1+dfsg-3  
testing  
ppc64el  	Fail 
2h 47m 47s
bamtools  
2.5.1+dfsg-3  
unstable  
ppc64el  	Fail 
	2h 47m 47s


--
Thierry Fauck @ fr.ibm.com

Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Tue, Jul 30, 2019 at 01:57:08PM -0400, Scott Talbert wrote:
> I'll look into adding the blocking indications to the tracking bug, but
> admittedly, I'm not very good with the BTS (and documentation isn't the
> best).

I've just run a "bts" command to mark all the open "please rebuild" bugs
as blocking the transition bug.

> On Tue, 30 Jul 2019, Tobias Frost wrote:
> > FTR, darkradiant is also affected by #900678.
> 
> I'm not sure that we can afford to wait for a fix for #900678.  There is no
> movement upstream on that and it's more than just a fix - rather wxGLCanvas
> needs to be ported to something like EGL instead of GLX.  I can send you a
> patch that adds the workaround to use X for you to consider.

Although forcing X under GTK3 is a workaround, it's really no worse than
sticking with GTK2 - the GTK2 build only works because GTK2 doesn't
support Wayland directly at all, and so there use of X is implicitly
forced.

Cheers,
Olly

Bug#933504: RM: spe -- ROM; Python 2 package; appears dead upstream; depends on Pychecker

[Kenneth J. Pronovici]

Package: ftp.debian.org
Severity: normal

I am filing this bug to remove spe per the recommendation of the FTP Masters.  

I am requesting that this package be removed from the archive so I can continue
with the removal of pychecker, which is obsolete, unsupported, and requires
Python 2.  

I filed a bug with spe in early June but have not heard back since then.  There
hasn't been a maintainer upload for this package since 2013, even though there
have been 3 NMUs.  From what I can tell, the spe upstream is no longer active.
I do not see any evidence that a Python 3 version of spe is under development.  
As a result, this package will eventually need to be removed from buster anyway.
I would just like to move up that timeline so I can finish removing pychecker.

I have CC'd the maintainer address (which might be dead?) as well as the two
listed uploaders (Stefano Canepa and Stani M).

Thanks,

KEN

Bug#933094: transition: octomap

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Jul 26, 2019 at 03:55:23PM +, Jose Luis Rivero wrote:
> I'm filing this bug for a transition of octomap. It is in experimental.
> It builds on all architectures in testing, where it built previously.

Please go ahead.

Thanks,

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

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

Bug#931173: Also breaks official Openstack Debian

[Thomas Goirand]

On 7/30/19 1:45 PM, Michael Anderson wrote:
> Using the Openstack Debian image
> (https://cloud.debian.org/cdimage/openstack/current-10/debian-10-openstack-amd64.qcow2)
> with the following cloud-config:
> 
>  network-config 
> version: 1
> config:
>     - type: physical
>   name: eth0
>   mac_address: '4e:3c:c1:69:fe:cc'
>   subnets:
>   - type: static
>     address: '10.110.10.45'
>     netmask: '255.255.255.0'
>     gateway: '10.110.10.1'
>   - type: dhcp6
>     - type: nameserver
>   address:
>   - '213.133.100.100'
>   - '213.133.99.99'
>   - '213.133.98.98'
> ---
> 
>  /etc/network/interfaces 
> 
> results in duplicate configurations for eth0:
> 
> root@foo2:/home/debian# cat $(find /etc/network/interfaces* -type f)
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The normal eth0
> allow-hotplug eth0
> iface eth0 inet dhcp
> 
> # Additional interfaces, just in case we're using
> # multiple networks
> allow-hotplug eth1
> iface eth1 inet dhcp
> 
> allow-hotplug eth2
> iface eth2 inet dhcp
> 
> # Set this one last, so that cloud-init or user can
> # override defaults.
> source /etc/network/interfaces.d/*
> 
> 
> 
>  /etc/network/interfaces.d/50-cloud-init.cfg 
> 
> # This file is generated from information provided by
> # the datasource.  Changes to it will not persist across an instance.
> # To disable cloud-init's network configuration capabilities, write a file
> # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
> # network: {config: disabled}
> auto lo
> iface lo inet loopback
>     dns-nameservers 213.133.100.100 213.133.99.99 213.133.98.98
> 
> auto eth0
> iface eth0 inet static
>     address 10.110.10.45/24
>     gateway 10.110.10.1
> 
> # control-alias eth0
> iface eth0 inet6 dhcp
> 
> 
> If I pass a dhcp configuration to cloud-config, the image fails to boot.

Hi,

If you intend to do that, why don't you simply remove
/etc/network/interfaces then (maybe with a userscript...)?

Cheers,

Thomas Goirand (zigo)

Bug#909306: qt3d5-dev: Qt53DExtrasConfig.cmake missing

[Dmitry Shachnev]

Hi Mike!

On Tue, Jul 30, 2019 at 09:03:20AM -0700, Mike Bird wrote:
> I am returning to Qt programming after a long absence.
>
> Removing these files creates far more problems than are purportedly avoided.
> A significant fraction of the examples fail even to compile now.  (Maybe the
> examples should be removed also?)
>
> Qt, and new concepts in Qt, are traditionally introduced by these examples.
> Broken examples make for a very unsatisfying experience.
>
> We know some APIs are unstable but we need to use them.  And we would
> like the examples to work as they always do upstream.
>
> I tried to rebuild the broken packages locally but the files are even
> removed from the source package so I cannot simply undo a broken patch.

As there is request from two people to enable this API, I will do so in the
next upload. Maybe it will be a separate package like qt3d5-unstable-dev, in
which case it will have to go through the NEW queue (so you will have to
wait before it reaches the repository).

Just one comment for now: you say that the files are removed from source
package. However that is not true, we only remove some assets from examples
because they have licensing problems:

https://salsa.debian.org/qt-kde-team/qt/qt3d/blob/experimental/debian/copyright#L4

For a local build, you should remove these lines in the first place:

https://salsa.debian.org/qt-kde-team/qt/qt3d/blob/experimental/debian/rules#L30

After that, you may also need to add new lines to debian/qt3d5-dev.install.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#933273: nullmailer logcheck rules no longer work

[Marc SCHAEFER]

On Tue, Jul 30, 2019 at 03:27:08PM -0300, David Bremner wrote:
> Jul 28 22:12:08 rocinante nullmailer-send[30788]: From:  to: 
> 
> 
> That doesn't seem to be specific to my configuration, but I thought I
> should check before adding another regex. Do you not have such lines? Do
> you actually want them in the logcheck output?

Yes I have those, but countrary to the other lines which are quite generic,
I found it useful to have those. I am filtering per from/to in local
rules, not nullmailer rules.

Now, if you want to filter them too, no problem for me.

Here is the whole picture that I am running for a few days on a few systems
without any output:

#/etc/logcheck/ignore.d.server/nullmailer
nullmailer-send\[[0-9]+\]: Rescanning queue\.
nullmailer-send\[[0-9]+\]: Trigger pulled\.
nullmailer-send\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
nullmailer-send\[[0-9]+\]: Starting delivery: host: .+ protocol: [a-z]+ file: 
[0-9\.]+
nullmailer-send\[[0-9]+\]: Sent file\.
nullmailer-send\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
nullmailer-send\[[0-9]+\]: smtp: Succeeded:
nullmailer-send\[[0-9]+\]: Message-Id: <.+>

You may however want to be more specific on the above rules (prefixing ^\w{3} [ 
:0-9]{11} [._[:alnum:]-]+ nullmailer)

And this is my local rule:

#/etc/logcheck/ignore.d.server/local
nullmailer-send\[[0-9]+\]: From: <(root|logcheck)@falken.alphanet.ch> to: 

Bug#933318: python-os-cloud-config (build-)depends on cruft packages.

[Thomas Goirand]

On 7/29/19 8:44 AM, Peter Michael Green wrote:
> Package: python-os-cloud-config
> Severity: serious
> Tags: bullseye, sid
> 
> python-os-cloud-config depends on a number of binary packages that are
> no longer built by their corresponding source packages, including
> 
> python-glanceclient
> python-ironicclient
> python-keystoneclient
> python-neutronclient
> python-novaclient
> python-oslo.config
> python-oslo.i18n
> python-pbr
> 
> Presumablly this package needs to migrate to python3 if it is going to
> stay around at all.

Hi!

Good catch. I just requested its removal, it's of no use in Debian.

Cheers,

Thomas Goirand (zigo)

Bug#933503: RM: python-os-cloud-config -- ROM; No need for this package in Debian

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal

Hi,

We don't need this package in Debian unless someone wants to do the huge
task of porting TripleO to Debian. Let's remove it.

Cheers,

Thomas Goirand (zigo)

Bug#932474: [pkg-gnupg-maint] Bug#932474: scdaemon: Additional udev rules for librem key

[Jeremiah C. Foster]

On Sat, 2019-07-20 at 14:57 -0400, Daniel Kahn Gillmor wrote:
> Control: tags 932474 + moreinfo
> 
> Hi Jeremiah--

Hello Daniel!

> On Fri 2019-07-19 17:24:34 -0400, Jeremiah C. Foster wrote:
> > I would like to add a USB VID:PID pair to the scdaemon package,
> > please find a diff attached.
> 
> I'm really happy to see Librem getting this stuff working, and I'd be
> happy to try to get this merged shortly.

Thank you in advance.

> > +## Librem Key
> > +SUBSYSTEM=="usb", ATTR{idVendor}=="4c4b", ATTR{idProduct}=="4c05",
> > ENV{ID_SMARTCARD_READER}="1",
> > ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
> 
> I'm sure you understand that we don't want to misattribute either
> vendorIDs or vendors.

I do understand that and am grateful for the attention to detail.

>   I tried to look up 0x4c4b (19531 decimal) in the
> "Valid USB Vendor ID Numbers" list distributed by the USB
> implementers
> forum here:
> 
> https://www.usb.org/developers
> 
> It says it's update quarterly, but the version i looked at is from
> late
> May:
> 
> https://usb.org/sites/default/files/vendor_ids052019.pdf
> 
> Was this a recently-assigned vendor ID? 

Yes, but I must apologize for providing you incorrect infomation.
Purism's vendor ID is actually 12653 or 0x316d.

>  Can you provide some evidence
> of the assignment?

The document you point to shows our assignment of 0x316d as "Purism
SPC". Of course our patch has to be updated accordingly -- please find
attached an updated patch.

Many thanks,

Jeremiah
--- /lib/udev/rules.d/60-scdaemon.rules-o	2019-07-19 13:48:34.591954821 -0700
+++ /lib/udev/rules.d/60-scdaemon.rules	2019-07-19 13:49:50.319551666 -0700
@@ -36,6 +36,8 @@
 SUBSYSTEM=="usb", ATTR{idVendor}=="20a0", ATTR{idProduct}=="4108", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
 SUBSYSTEM=="usb", ATTR{idVendor}=="20a0", ATTR{idProduct}=="4109", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
 SUBSYSTEM=="usb", ATTR{idVendor}=="20a0", ATTR{idProduct}=="4211", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
+## Librem Key
+SUBSYSTEM=="usb", ATTR{idVendor}=="316d", ATTR{idProduct}=="4c4b", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
 ## Gnuk Token
 SUBSYSTEM=="usb", ATTR{idVendor}=="234b", ATTR{idProduct}=="", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
 ## Alcor Micro Corp cardreader (in ThinkPad X250)


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

Bug#932944: passwordsafe 1.00+dfsg-1+deb9u1 flagged for acceptance

[Jonathan Wiltshire]

Control: tags -1 + pending

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: passwordsafe
Version: 1.00+dfsg-1+deb9u1

Explanation: 

Bug#933218: libsdl2-image 2.0.1+dfsg-2+deb9u2 flagged for acceptance

[Jonathan Wiltshire]

Control: tags -1 + pending

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: libsdl2-image
Version: 2.0.1+dfsg-2+deb9u2

Explanation: multiple security issues

Bug#931386: fribidi 0.19.7-1+deb9u1 flagged for acceptance

[Jonathan Wiltshire]

Control: tags -1 + pending

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: fribidi
Version: 0.19.7-1+deb9u1

Explanation: fix right-to-left output in text edition of d-i

Bug#930942: cacti 1.2.2+ds1-2+deb10u1 flagged for acceptance

[Jonathan Wiltshire]

Control: tags -1 + pending

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

Explanation: fix some issues upgrading from the version in stretch

Bug#933502: amanda-server: fails to start because of wrong glib version

[Andrea Borgia]

Package: amanda-server
Version: 1:3.5.1-2+b3
Severity: normal

Dear Maintainer,

My last successful backup was july 27th, packages have been updated to what is 
currently in testing.
Running amcheck or amdump, I get the following error:
** (process:7278): CRITICAL **: 22:45:24.730: GLib version too old (micro 
mismatch): Amanda was compiled with glib-2.60.5, but linking with 2.58.3

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

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

Versions of packages amanda-server depends on:
ii  amanda-common  1:3.5.1-2+b3
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  libc6  2.28-10
ii  libcurl4   7.65.1-1
ii  libglib2.0-0   2.58.3-3
ii  libjson-perl   4.02000-1
ii  libssl1.1  1.1.1c-1
ii  perl   5.28.1-6

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
ii  amanda-client  1:3.5.1-2+b3
ii  cpio   2.12+dfsg-9
pn  gnuplot

-- no debconf information

Bug#933501: aptitude cannot search for packages newer than in the archive

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.11-7
Severity: wishlist

Consider the case
# set libffi6
# apt-cache policy $@
libffi6:
  Installed: 3.3~20160224-1
  Candidate: 3.3~20160224-1
  Version table:
 *** 3.3~20160224-1 100
100 /var/lib/dpkg/status
 3.2.1-9 500
500 http://opensource.nchc.org.tw/debian unstable/main i386 Packages
# apt-show-versions|grep newer
libffi6:i386 3.3~20160224-1 newer than version in archive
# aptitude --verbose show $@|egrep Version\|State
Version: 3.3~20160224-1
State: installed
Version: 3.2.1-9
State: installed (3.3~20160224-1), upgrade available (3.2.1-9)

Actually technically that should be downgrade, not upgrade.*

But my main point is there is no search pattern to detect it.
not ~U, not ~o, etc. Probably no combination either.
So one must rely on apt-show-versions to find it.

*(As we see in
# aptitude purge $@
...
The following actions will resolve these dependencies:
 Downgrade the following packages:
1) libffi6 [3.3~20160224-1 (now) -> 3.2.1-9 (unstable)]
)

Bug#933393: jackson-databind: CVE-2019-14439 CVE-2019-14379

[Salvatore Bonaccorso]

Control: retitle -1 jackson-databind: CVE-2019-14439 CVE-2019-14379

There seem to have been a confusion around the CVE to be assigned for
https://github.com/FasterXML/jackson-databind/issues/2389 . Whilst the
subject contains still CVE-2019-14361 the right CVE looks to be
CVE-2019-14439 according to
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14439 .

Regards,
Salvatore

Bug#933500: lintian: Please warn against Alioth in Homepage

[Jakub Wilk]

Package: lintian
Version: 2.16.0
Severity: wishlist

Some packages still have alioth.debian.org in their Homepage fields:

  $ grep-aptavail -F Homepage alioth -ns Homepage | shuf
  http://debtags.alioth.debian.org
  http://alioth.debian.org/projects/spell-norwegian/
  https://debian-live.alioth.debian.org/live-build/
  ...

Please give them a warning.

--
Jakub Wilk

Bug#933370: chrony won't start

[Ross Boylan]

On Tue, Jul 30, 2019 at 12:57 PM Vincent Blut  wrote:
>
> On Tue, Jul 30, 2019 at 12:05:23AM -0700, Ross Boylan wrote:
> >See below.
> >
> >On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut  wrote:
> >
> >> Hello Ross,
> >>
> >> On Mon, Jul 29, 2019 at 12:13:16PM -0700, Ross Boylan wrote:
> >
> >> >It looks as if systemd-timesyncd is creating a stop job for chrony
> >> >even though the former includes
> >
> >>
> >> What’s the status of systemd-timesyncd here? Is it started?
> >
> >I'm never sure with systemd exactly which things I should focus on for
> >the status, but the results below see to indicate systemd-timesyncd is
> >not running even though it's enabled.  The start condition failed,
> >which I gather is not quite good enough to assure it never started.
> >
> >root@barley:~# systemctl status systemd-timesyncd
> >● systemd-timesyncd.service - Network Time Synchronization
> >   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
> >enabled; vendor preset: enabled)
> >  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
> >   └─disable-with-time-daemon.conf
> >   Active: inactive (dead)
> >Condition: start condition failed at Mon 2019-07-29 12:35:49 PDT; 11h ago
> >   └─ ConditionFileIsExecutable=!/usr/sbin/chronyd was not met
> > Docs: man:systemd-timesyncd.service(8)
> >
> >Jul 29 12:35:49 barley systemd[1]: Condition check resulted in Network 
> >Time…ped.
> >Hint: Some lines were ellipsized, use -l to show in full.
>
> For the avoidance of doubt, this is the result right after booting your
> system?

I ran the commands immediately above well after the start of the
system, though I think they were the same just after the start.
However, I had manually started chrony before getting the previous output.

> Anyway, this is the expected state.
>
> >> Also, could you attach the output of:
> >> $ systemctl show systemd-timesyncd.service
> >
> >root@barley:~# date; systemctl show systemd-timesyncd.service
> > [snip…]
>
> Nothing seems suspicious here. However, I observe that systemd-timesyncd
> is pulled in way earlier than chronyd (and all other NTP implementation
> provided in Debian) in the boot process. This is due to its unit file
> which contains sysinit.target in the “Before=” dependency directive.
>
> >> Thanks for these logs. To have a bigger picture, could you please
..
>
> So far, the initial transactions seem correctly done:
> ↳systemd-timesyncd.service starts before sysinit.target

Except, at least in my reading of the man page, it should never start
because one of its conditions fails.
You pointed to a bug saying it doesn't actually work that way.

I've run into other problems with services starting before all
filesystems were mounted; I wonder if that's an issue here (not on the
machine right now).
i.e., /usr isn't mounted when timesync first checks for chrony, and so
it thinks things are OK.

>   ↳units conflicting with systemd-timesyncd are stopped
> ↳multi-user.target starts
>   ↳chrony.service starts
> ↳systemd-timesyncd.service stops
>

> >Jul 29 11:30:43 barley systemd[1]: Found redundant job
> >systemd-timesyncd.service/stop, dropping from transaction.
> >Jul 29 11:30:43 barley systemd[1]: chrony.service: Installed new job
> >chrony.service/start as 163
> >Jul 29 11:30:43 barley systemd[1]: run-systemd-timesync.mount: Collecting.
> >Jul 29 11:30:43 barley systemd[1]: var-lib-systemd-timesync.mount: 
> >Collecting.
> >Jul 29 11:30:44 barley systemd-sysusers[599]: Group systemd-timesync
> >already exists.
> >Jul 29 11:30:44 barley systemd-sysusers[599]: User systemd-timesync
> >already exists.
> >Jul 29 11:30:46 barley systemd[1]: Pulling in
> >systemd-timesyncd.service/start from sysinit.target/start
>
> And here we can see that before starting sysinit.target (again),
> systemd-timesyncd.service is started.
>
> >Jul 29 11:30:46 barley systemd[1]: Added job
> >systemd-timesyncd.service/start to transaction.
> >Jul 29 11:30:46 barley systemd[1]: Pulling in system.slice/start from
> >systemd-timesyncd.service/start
> >Jul 29 11:30:46 barley systemd[1]: Pulling in var.mount/start from
> >systemd-timesyncd.service/start
> >Jul 29 11:30:46 barley systemd[1]: Pulling in -.mount/start from
> >systemd-timesyncd.service/start
> >Jul 29 11:30:46 barley systemd[1]: Pulling in time-sync.target/start
> >from systemd-timesyncd.service/start
> >Jul 29 11:30:46 barley systemd[1]: Pulling in shutdown.target/stop
> >from systemd-timesyncd.service/start
> >Jul 29 11:30:46 barley systemd[1]: Pulling in chrony.service/stop from
> >systemd-timesyncd.service/start
>
> systemd-timesyncd.service wants chrony.service to be stopped to
> continue.

I didn't get that from the config files.  For timesyncd they seemed to
say it shouldn't start if chrony was present, not that chrony should
stop.
However, chrony's files say it should not run if timesyncd (or several
other timeservices) is running.

>
> >Jul 29 11:30:46 barley systemd[1]: Added job chr

Bug#570376: texdoc barfs if BROWSER has multiple colon-separated commands

[Hilmar Preuße]

Control: found 570376 2019.20190710-1

Am 18.02.2010 um 13:44 teilte Julian Gilbey mit:

Hi Julian,

I'm going through some old bugs.

> I try running the command "texdoc eqnarray" and I get the error
> message:
> sh: links:lynx: not found
> 
> This is because my BROWSER environment variable contains "links:lynx",
> as allowed in the specification of the BROWSER variable.
> 
> So texdoc should parse this variable (and perhaps others), using the
> first one available.
> 
I can still reproduce the issue and I have some comments. I used the
documentation progress20030701, which is in texlive-latex-extra-doc.

1. What kind of specification are you referring to? Is this a Debian
specification, if not where can I find it?
2. In addition to variable browser you can set the var BROWSER_texdoc,
which specifies just one browser program. This way you can make texdoc
work w/ changing the value of BROWSER.

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



signature.asc
Description: OpenPGP digital signature

Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error

[william l-k]

Package: libreoffice-base
Version: 1:6.3.0~rc2-1
Severity: important

As of today Jul 30 2019, a sub form no longer works that has worked for years.

The pop up says that there is a problem with my SQL statement for MariaDB
server version near ':link_from_ID)' at line one. But this isn't from a query I
knowingly wrote. All of the reports relying on them still function fine. Adding
data to the master form works, but the linked sub-form does not. If there is a
work around to try I'm all ears.






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

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

Versions of packages libreoffice-base depends on:
ii  libc6 2.28-10
ii  libgcc1   1:9.1.0-10
ii  libreoffice-base-core 1:6.3.0~rc2-1
ii  libreoffice-base-drivers  1:6.3.0~rc2-1
ii  libreoffice-core  1:6.3.0~rc2-1
ii  libstdc++69.1.0-10
ii  uno-libs3 6.3.0~rc2-1
ii  ure   6.3.0~rc2-1

Versions of packages libreoffice-base recommends:
ii  default-jre [java6-runtime]   2:1.11-72
ii  libreoffice-java-common   1:6.3.0~rc2-1
ii  libreoffice-writer1:6.3.0~rc2-1
ii  openjdk-10-jre [java6-runtime]10.0.2+13-2
ii  openjdk-11-jre [java6-runtime]11.0.4+11-1
ii  openjdk-8-jre [java6-runtime] 8u222-b10-1
ii  openjdk-9-jre [java6-runtime] 9.0.4+12-4
ii  oracle-java8-jdk [java6-runtime]  8u65

Versions of packages libreoffice-base suggests:
ii  libreoffice-report-builder  1:6.3.0~rc2-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2
ii  fonts-opensymbol2:102.11+LibO6.3.0~rc2-1
ii  libboost-date-time1.67.01.67.0-13
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1
ii  libclucene-core1v5  2.3.3.4+dfsg-1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.2.10-6
ii  libcurl3-gnutls 7.65.1-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.30.1-2
ii  libeot0 0.01-5
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.1.0-10
ii  libglib2.0-02.60.6-1
ii  libgpgmepp6 1.12.0-6
ii  libgraphite2-3  1.3.13-7
ii  libgstreamer-plugins-base1.0-0  1.16.0-2
ii  libgstreamer1.0-0   1.16.0-2
ii  libharfbuzz-icu02.5.3-1
ii  libharfbuzz0b   2.5.3-1
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-3
ii  libldap-2.4-2   2.4.48+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.21-1
ii  libnss3 2:3.45-1
ii  libnumbertext-1.0-0 1.0.5-1
ii  libodfgen-0.1-1 0.1.7-1
ii  liborcus-0.14-0 0.14.1-6
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-5
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:6.3.0~rc2-1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.1.0-10
ii  libx11-62:1.6.7-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.28-2
ii  libxmlsec1-nss  1.2.28-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2
ii  uno-libs3   6.3.0~rc2-1
ii  ure 6.3.0~rc2-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libreoffice-core recommends:
ii  gstreamer1.0-libav 1.16.0-2
ii  gstreamer1.0-plugins-bad   1.16.0-2
ii  gstreamer1.0-plugins-base  1.16.0-2
ii  gstreamer1.0-plugins-good  1.16.0-2
ii  gstreamer1.0-plugins-ugly  1.16.0-2
ii  libpaper-utils  

Bug#933437: trustedqsl: Please rebuild against wxWidgets GTK 3 package

[Christoph Berg]

Re: s...@techie.net 2019-07-30 <20190730140545.6ccbe22a0...@bear.techie.net>
> 1) Update your Build-Depends
>libwxgtk3.0-dev -> libwxgtk3.0-gtk3-dev

Fwiw, this almost works. The only problem is that in the main window,
the buttons are only visible after hovering over them with the mouse
once. (See attached screenshots 1 and 2 before and after hovering.)

I'm still uploading the new version, this is a minor problem only even
if it's in the main view.

Christoph

Bug#932598: Upgrade to buster fails with start-stop-daemon error

[Andreas Beckmann]

Hi Ron,

On 21/07/2019 05.42, Ron Murray wrote:
> On upgrade to buster, sendmail upgrade failed with this message:
> 
>> start-stop-daemon: matching only on non-root pidfile 
>> /var/run/sendmail/mta/sendmail.pid is insecure
> 
> Some work with Google found Debian bug #922395, which, although not
> for sendmail, pointed the way to the solution.

I've just uploaded sendmail 8.15.2-13 to unstable, it would be great if
you could test this s.t. I have a datapoint whether this fix should be
applied to buster, too.

Thanks

Andreas

Bug#933498: Update/test yarnpkg with webpack 4

[Pirate Praveen]

Package: yarnpkg
Version: 1.13.0-1
Severity: important

Webpack 4.7.0 is available in experimental. I'd like to upload it to 
unstable as soon as possible. Please make sure yarnpkg works with 
webpack 4.


See https://wiki.debian.org/Javascript/Nodejs/Webpack4 for more 
information.

Bug#933497: mcpp: CVE-2019-14274

[Salvatore Bonaccorso]

Source: mcpp
Version: 2.7.2-4
Severity: normal
Tags: security upstream
Forwarded: https://sourceforge.net/p/mcpp/bugs/13/

Hi,

The following vulnerability was published for mcpp, filling the bug
for tracking the issue itself.

CVE-2019-14274[0]:
| MCPP 2.7.2 has a heap-based buffer overflow in the do_msg() function
| in support.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14274
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14274
[1] https://sourceforge.net/p/mcpp/bugs/13/

Regards,
Salvatore

Bug#932198: Issue solved

[Mike Gabriel]

Control: severity -1 important

Hi,

thanks for the feedback.

On  Di 30 Jul 2019 18:09:13 CEST, Robert Middleton wrote:


I have fixed this issue on my end; it may be an erroneous bug on the
upgrade portion.

About the time that I upgraded from stretch->buster, I also turned on
the SSL connections on slapd.  It seems that earlier versions of
fusiondirectory will connect to localhost just fine, but because of
the SSL cert it seems like it was failing.

Bad connection string:

ldap://localhost:389

Good connection string:

ldap://ldap.example.com:389

Regardless, the error that comes back is still completely useless,
since it does not tell you anything about possible SSL errors.

-Robert Middleton


Lowering severity to important.

Mike
--

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

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



pgpCgpfh24AZz.pgp
Description: Digitale PGP-Signatur

Bug#933496: libminini: doesn't ship needed headers files

[Gianfranco Costamagna]

Source: libminini
Version 1.2.a+ds-2
Severity: serious
tags: patch

Hello, I discovered libminini stopped using cmake and switched to plain 
Makefiles...
but is not installing anymore the required headers

diff -Nru libminini-1.2.a+ds/debian/patches/Makefile.patch 
libminini-1.2.a+ds/debian/patches/Makefile.patch
--- libminini-1.2.a+ds/debian/patches/Makefile.patch2019-07-29 
05:32:00.0 +0200
+++ libminini-1.2.a+ds/debian/patches/Makefile.patch2019-07-30 
21:54:11.0 +0200
@@ -12,7 +12,7 @@
 +
 +CPPFLAGS += -fPIC
 +
-+HEADERS := minIni.h
++HEADERS := *.h
 +SRCS := minIni.cc
 +OBJS := $(SRCS:.cc=.o)
 +


this makes utox FTBFS in sid...

btw what is the rationale behind dropping the cmake file? I can help fixing it 
if needed... not sure why you dropped it!


/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wpointer-arith -Wimplicit-fallthrough=5 -Werror=implicit-function-declaration 
-Wno-misleading-indentation -fno-strict-aliasing -fPIC -flto   -std=gnu11 -o 
CMakeFiles/utox.dir/src/messages.c.o   -c /<>/src/messages.c
[ 82%] Building C object CMakeFiles/utox.dir/src/notify.c.o
/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wpointer-arith -Wimplicit-fallthrough=5 -Werror=implicit-function-declaration 
-Wno-misleading-indentation -fno-strict-aliasing -fPIC -flto   -std=gnu11 -o 
CMakeFiles/utox.dir/src/notify.c.o   -c /<>/src/notify.c
[ 83%] Building C object CMakeFiles/utox.dir/src/qr.c.o
/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wpointer-arith -Wimplicit-fallthrough=5 -Werror=implicit-function-declaration 
-Wno-misleading-indentation -fno-strict-aliasing -fPIC -flto   -std=gnu11 -o 
CMakeFiles/utox.dir/src/qr.c.o   -c /<>/src/qr.c
/<>/src/messages.c: In function ???messages_draw_filetransfer???:
/<>/src/messages.c:907:47: warning: format ???%lu??? expects 
argument of type ???long unsigned int???, but argument 4 has type 
???uint64_t??? {aka ???long long unsigned int???} [-Wformat=]
  907 | p += snprintf(p, speed - p, "/s %lus",
  | ~~^
  |   |
  |   long unsigned int
  | %llu
  908 |file->speed ? (file->size - 
file->progress) / file->speed : 0);
  |
~
  | 
 |
  | 
 uint64_t {aka long long unsigned int}
[ 85%] Building C object CMakeFiles/utox.dir/src/screen_grab.c.o
/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wpointer-arith -Wimplicit-fallthrough=5 -Werror=implicit-function-declaration 
-Wno-misleading-indentation -fno-strict-aliasing -fPIC -flto   -std=gnu11 -o 
CMakeFiles/utox.dir/src/screen_grab.c.o   -c /<>/src/screen_grab.c
[ 86%] Building C object CMakeFiles/utox.dir/src/self.c.o
/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wpointer-arith -Wimplicit-fallthrough=5 -Werror=implicit-function-declaration 
-Wno-misleading-indentation -fno-strict-aliasing -fPIC -flto   -std=gnu11 -o 
CMakeFiles/utox.dir/src/self.c.o   -c /<>/src/self.c
[ 87%] Building C object CMakeFiles/utox.dir/src/settings.c.o
/usr/bin/cc  -isystem /usr/include/minIni -isystem /usr/include/qrcodegen  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat

Bug#933370: chrony won't start

[Vincent Blut]

On Tue, Jul 30, 2019 at 12:05:23AM -0700, Ross Boylan wrote:

See below.

On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut  wrote:


Hello Ross,

On Mon, Jul 29, 2019 at 12:13:16PM -0700, Ross Boylan wrote:



>It looks as if systemd-timesyncd is creating a stop job for chrony
>even though the former includes




What’s the status of systemd-timesyncd here? Is it started?


I'm never sure with systemd exactly which things I should focus on for
the status, but the results below see to indicate systemd-timesyncd is
not running even though it's enabled.  The start condition failed,
which I gather is not quite good enough to assure it never started.

root@barley:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
  Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
enabled; vendor preset: enabled)
 Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
  └─disable-with-time-daemon.conf
  Active: inactive (dead)
Condition: start condition failed at Mon 2019-07-29 12:35:49 PDT; 11h ago
  └─ ConditionFileIsExecutable=!/usr/sbin/chronyd was not met
Docs: man:systemd-timesyncd.service(8)

Jul 29 12:35:49 barley systemd[1]: Condition check resulted in Network Time…ped.
Hint: Some lines were ellipsized, use -l to show in full.


For the avoidance of doubt, this is the result right after booting your 
system?

Anyway, this is the expected state.


Also, could you attach the output of:
$ systemctl show systemd-timesyncd.service


root@barley:~# date; systemctl show systemd-timesyncd.service
[snip…]


Nothing seems suspicious here. However, I observe that systemd-timesyncd 
is pulled in way earlier than chronyd (and all other NTP implementation 
provided in Debian) in the boot process. This is due to its unit file 
which contains sysinit.target in the “Before=” dependency directive.


Thanks for these logs. To have a bigger picture, could you please 
show me something like that instead:

$ journalctl -b | grep -E "(chrony|timesync)"


# xzcat journal201907291130.xz | grep -E "(chrony|timesync)"
Jul 29 11:30:43 barley systemd[1]: Pulling in
systemd-timesyncd.service/start from sysinit.target/start
Jul 29 11:30:43 barley systemd[1]: Added job
systemd-timesyncd.service/start to transaction.
Jul 29 11:30:43 barley systemd[1]: Pulling in system.slice/start from
systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in var.mount/start from
systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in -.mount/start from
systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in time-sync.target/start
from systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in shutdown.target/stop
from systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in chrony.service/stop from
systemd-timesyncd.service/start
Jul 29 11:30:43 barley systemd[1]: Added job chrony.service/stop to transaction.
Jul 29 11:30:43 barley systemd[1]: Pulling in chrony.service/start
from multi-user.target/start
Jul 29 11:30:43 barley systemd[1]: Added job chrony.service/start to
transaction.
Jul 29 11:30:43 barley systemd[1]: Pulling in sysinit.target/start
from chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in system.slice/start from
chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in -.mount/start from
chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in var.mount/start from
chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in ntp.service/stop from
chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in openntpd.service/stop
from chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in ntpsec.service/stop from
chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in shutdown.target/stop
from chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Pulling in
systemd-timesyncd.service/stop from chrony.service/start
Jul 29 11:30:43 barley systemd[1]: Added job
systemd-timesyncd.service/stop to transaction.
Jul 29 11:30:43 barley systemd[1]: chrony.service: Looking at job
chrony.service/start conflicted_by=no
Jul 29 11:30:43 barley systemd[1]: chrony.service: Looking at job
chrony.service/stop conflicted_by=no
Jul 29 11:30:43 barley systemd[1]: chrony.service: Fixing conflicting
jobs chrony.service/start,chrony.service/stop by deleting job
chrony.service/stop
Jul 29 11:30:43 barley systemd[1]: systemd-timesyncd.service: Looking
at job systemd-timesyncd.service/stop conflicted_by=yes
Jul 29 11:30:43 barley systemd[1]: systemd-timesyncd.service: Looking
at job systemd-timesyncd.service/start conflicted_by=no
Jul 29 11:30:43 barley systemd[1]: systemd-timesyncd.service: Fixing
conflicting jobs
systemd-timesyncd.service/stop,systemd-timesyncd.service/start by
deleting job systemd-timesyncd.service/start


So far, the initial transactions seem correctly done:
↳systemd-timesyncd.service starts befor

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Max Hofer]

Am Dienstag, 30. Juli 2019, 01:21:43 CEST schrieb Jiri Palecek:
> On 29. 07. 19 22:12, Max Hofer wrote:
> >> I was also hit by this bug after upgrading yesterday (it has been few
> >> weeks since I updated the machine). Just like others, I also had to
> >> downgrade the following packages to 2.02 to get it working.
> >> 
> >> 1. grub-common
> >> 2. grub2-common
> >> 3. grub-efi-amd64-bin
> >> 4. grub-efi-amd64
> >> 5. grub-pc-bin
> > 
> > I hit the same problem today. Could you please provide the information,
> > how you downgraded the packages on a non bootable system?
> 
> You gotta find something that boots. Either installation pendrive or CD,
> or live CD or another disc. Then mount your regular disk as in
> somedirectory, mount /proc, /sys, /dev in somedirectory, chroot into
> somedirectory and then it is a simple matter for apt. (You may have to
> edit sources.list)
> 
> I went through it with my qemu images.
> 
> Regards
> 
>  Jiri Palecek
Thx for pointing me in the right direction, I was able to fix my problem.

It seems my system broke because the install_devices was configured to the 
partition and not the device.

$ lsblk --output NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,PTTYPE,MODEL
NAME   TYPE   SIZE FSTYPE MOUNTPOINT PTTYPE MODEL
sdadisk 232.9G   dosSamsung_SSD_840_EVO_250GB
├─sda1 part   333M ext4   /  dos
├─sda2 part 1K   dos
├─sda5 part   8.4G btrfs  /usr   dos
├─sda6 part   2.8G btrfs  /var   dos
├─sda7 part  27.7G swap   [SWAP] dos
├─sda8 part   380M btrfs  /tmp   dos
└─sda9 part 193.4G btrfs  /home  dos

# Configuration which broke my system with the upgrade from 2.02 to 2.04
$ sudo debconf-show grub-pc|grep install_devices:
* grub-pc/install_devices: /dev/disk/by-id/ata-
Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B-part1

# Configuration which worked when I upgraded from 2.02 to 2.04
$ sudo debconf-show grub-pc|grep install_devices:
* grub-pc/install_devices: /dev/disk/by-id/ata-
Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B

I vaguely remember that one of the grub upgrades (a long time ago) asked me if 
I would like to change the installation location but as far as I remember I 
never changed it.

Regards
Max

Bug#933495: ganeti: virtio-net multiqueue support broken

[Joerg Jaspert]

Source: ganeti
Version: 2.16.0-5
Severity: important

Dear Maintainer,

using virtio-net multiqueue support with ganeti on buster is broken in a
way to be unusable. Its current code leads to generating one tap device
per queue - instead of one tap device that handles the multiple queues.

As such one can not currently use it, and is limited to just one queue,
which can drastically limit the possible network speed.

(Yes, its broken ONLY when using multiqueue, hence no grave or
something. Plain singlequeue works fine. Still, it limits it a lot, so
important)

The fix is simple and ought to be fine for a stable update, it can be
found in https://github.com/ganeti/ganeti/pull/1326 - its basically 6
lines of changes and 6 new lines added in ganetis code.

--
bye, Joerg

Bug#932795: How to handle FTBFS bugs in release architectures

[Adrian Bunk]

On Tue, Jul 30, 2019 at 09:05:04PM +0200, Santiago Vila wrote:
> Quoting Debian Policy:
> 
>  Packages should build reproducibly, which for the purposes of this
>  document [19] means that given
> 
> a version of a source package unpacked at a given path;
> a set of versions of installed build dependencies;
> a set of environment variable values;
> a build architecture; and
> a host architecture,
>   
>  repeatedly building the source package for the build architecture on
>  any machine of the host architecture with those versions of the build
>  dependencies installed and exactly those environment variable values
>  set will produce bit-for-bit identical binary packages.
> 
> 
> So, according to this definition, if we can find a set of environment
> variable values and installed build-dependencies and a machine for
> which the package does not build at all (as I happen to find from time
> to time), then repeatedly building the source package in such machine
> will certainly not produce bit-for-bit identical binary packages,
> because it will not produce any binary packages at all, and therefore
> the package will not be reproducible by definition.

According to the this definition of reproducibility a package that would
not build on a machine with 256 MB RAM would not be reproducible.

> Of course, this could be a bug in the wording,
>...

They just wanted to get something about reproducibility into policy,
the current wording is not a usable technical definition.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#931377: RFS: gcc-8-doc/8.3.0-1 [put in ITP, ITA, RC, NMU if applicable]

[Dmitry Eremin-Solenikov]

вт, 30 июл. 2019 г. в 18:23, Adam Borowski :
>
> On Tue, Jul 30, 2019 at 05:12:33PM +0300, Dmitry Eremin-Solenikov wrote:
> > I have uploaded gcc-8-doc targeted buster-backports. Would you agree
> > to sponsor it?
>
> Looks good, in bpo-NEW.

Thank you!

> > I can also backport gcc-doc-defaults afterwards.
>
> Good idea, yeah.

Uploaded to mentors.d.o

-- 
With best wishes
Dmitry

Bug#933493: RFS: gcc-9-doc/9.1.0-1

[Dmitry Eremin-Solenikov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gcc-9-doc"

 * Package name: gcc-9-doc
   Version : 9.1.0-1
   Upstream Author : FSF
 * URL : https://gcc.gnu.org/
 * License : GFDL-1.2+, GFDL-1.3+, GPL-2+, GPL-3+
   Section : doc

It builds those binary packages:

cpp-9-doc_9.1.0-1_all.deb non-free/doc optional
gcc-9-doc_9.1.0-1_all.deb non-free/doc optional
gcc-9-doc_9.1.0-1_amd64.buildinfo non-free/doc optional
gccgo-9-doc_9.1.0-1_all.deb non-free/doc optional
gfortran-9-doc_9.1.0-1_all.deb non-free/doc optional
gnat-9-doc_9.1.0-1_all.deb non-free/doc optional
  
To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/gcc-9-doc


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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/g/gcc-9-doc/gcc-9-doc_9.1.0-1.dsc

More information about gcc-9-doc can be obtained from https://www.example.com.

Changes since the last upload:

gcc-9-doc (9.1.0-1) unstable; urgency=medium

  * New upstream branch.
  * Synced patches with gcc-9, 9.1.0-10
  * New upstream version 9.1.0
  * d/patches: refresh patches
  * d/control: bump Standards-Version to 4.4.0, no changes needed.

 -- Dmitry Eremin-Solenikov   Tue, 30 Jul 2019 18:28:18 
+0300

Regards,
 Dmitry Eremin-Solenikov

Bug#933494: djview-plugin: Please update Recommends: list and use chromium instead of chromium-browser

[Boyuan Yang]

Package: djview-plugin
Severity: normal
Version: 4.11-1

Dear djview maintainer,

The Chromium browser has renamed from chromium-browser to "chromium". Please
update your dependency list accordingly.

Thanks,
Boyuan Yang


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

Bug#478594: latex-beamer: Please support email on title slide

[Hilmar Preuße]

Am 30.04.2008 um 00:49 teilte Josh Triplett mit:

Hi Josh,

I'm going through some old bugs.

> I often want to put my email address on the title slide, so people who
> see my presentation on the web have a way to contact me.  Currently,
> if I want to do this with beamer, either I must use the hack of
> putting it in the author field (which disrupts other uses of the
> author string in the presentation theme), or I must manually construct
> a title slide.  I'd like to have an optional email command which
> specifies an email address to use on the title slide.
> 
I'm not familiar w/ beamer. Does there exists an acceptable solution yet?

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



signature.asc
Description: OpenPGP digital signature

Bug#538103: latex-beamer: Wrong navigation bottun position when "show notes on second screen=bottom"

[Hilmar Preuße]

forwarded 538103 https://github.com/josephwright/beamer/issues/370
stop

Am 23.07.2009 um 04:33 teilte Ryo IGARASHI mit:

Hi Ryo,

https://bugs.debian.org/538103

> The navigation icon position and real "button" position is diverges
> when I set "show notes on second screen=bottom" option.
> 
> The minimum example is as follows:
> 
> \documentclass{beamer}
> \usepackage{pgfpages}
> \setbeameroption{show notes on second screen=bottom}
> 
> \begin{document}
> \begin{frame} \frametitle{1}
>   1
>   \note{a}
> \end{frame}
> \end{document}
> 
> I compiled the above source with pdflatex.
> The navigation icons appear in the real presentation page,
> but the actual navigation "button" (where I can push) are
> in the lower note page.
> I assume that something is wrong with the navigation position calculation.
> 
I searched a while for the issue and found the following thread on
stackexchange. It explains a little bit, why it is not possible to fix
your problem very easily.

https://tex.stackexchange.com/questions/350993/beamer-presentation-with-notes-navigation-does-not-work-properly-and-destinati

Regarding the second part of the problem:

x.map}pdfTeX warning (ext4): destination with the same identifier
(name{Navigat
ion1}) has been already used, duplicate ignored

\pgfpages@shipoutshipoutbox ...physicalpagesizes }
  \endgroup
l.10 \end{document}
   pdfTeX warning (ext4): destination with the same
identifier
(name{page.1}) has been already used, duplicate ignored

\pgfpages@shipoutshipoutbox ...physicalpagesizes }
  \endgroup
l.10 \end{document}
   ] (./538103.aux) )

There is already an issue open @github, hence I mark your bug as
forwarded. Please keep in mind, that fixing this part of the issue won't
solve your problem w/ the navigation bottom.

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



signature.asc
Description: OpenPGP digital signature

Bug#932965: Fix ES module exports in node-magic-string : what is left?

[Julien Puydt]

Hi,

the original report was about shipping the files correctly and fixing
the ES module exports.

For the first part you already committed a fix, and for the later, I had
a look and the end of dist/magic-string.es.js is:

export { Bundle, SourceMap };
export default MagicString$1;
//# sourceMappingURL=magic-string.es.js.map


which looks quite correct as far as I understand things.

Can I upload?

JP

Bug#932965: Fix ES module exports in node-magic-string : what is left?

[Pirate Praveen]

On 2019-07-31 00:33, Julien Puydt wrote:

Hi,

the original report was about shipping the files correctly and fixing
the ES module exports.

For the first part you already committed a fix, and for the later, I 
had

a look and the end of dist/magic-string.es.js is:

export { Bundle, SourceMap };
export default MagicString$1;
//# sourceMappingURL=magic-string.es.js.map


which looks quite correct as far as I understand things.


It is correct for rollup's implementation of ES modules, but node esm 
loader (node --experimental-modules command) does not support it. See 
https://github.com/nodejs/help/issues/2081


node currently considers a file as ES module only if package.json has a 
"type": "module" field or the file extension is .mjs.


So upstream has to decide, but we will have to wait till esm loader 
becomes stable in node core first before we request upstream to change 
it.


For now, we can use module.createRequire() option to load commonjs. See 
esm branch of node-rollup.



Can I upload?


Yes.


JP

Bug#932795: How to handle FTBFS bugs in release architectures

[Santiago Vila]

Quoting Debian Policy:

 Packages should build reproducibly, which for the purposes of this
 document [19] means that given

a version of a source package unpacked at a given path;
a set of versions of installed build dependencies;
a set of environment variable values;
a build architecture; and
a host architecture,

 repeatedly building the source package for the build architecture on
 any machine of the host architecture with those versions of the build
 dependencies installed and exactly those environment variable values
 set will produce bit-for-bit identical binary packages.


So, according to this definition, if we can find a set of environment
variable values and installed build-dependencies and a machine for
which the package does not build at all (as I happen to find from time
to time), then repeatedly building the source package in such machine
will certainly not produce bit-for-bit identical binary packages,
because it will not produce any binary packages at all, and therefore
the package will not be reproducible by definition.

Of course, this could be a bug in the wording, but if we really meant
that the packages only need to be identical when they are actually
produced, the wording should be like this instead:

 repeatedly building the source package will either produce a build
 failure or bit-for-bit identical binary packages.

I guess this is not the type of reproducibility we should aim for.

Thanks.

Bug#933492: RM: merkaartor -- ROM; No release since 2016, FTBFS with PROJ 6 & GDAL 3

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove merkaartor from the archive, it hasn't had a new release
since 2016 and FTBFS with PROJ 6 & GDAL 3.

Kind Regards,

Bas

Bug#930635: SyntaxError: 'import' and 'export' may appear only with 'sourceType: module'

[Pirate Praveen]

On Mon, 17 Jun 2019 12:56:06 +0500 Pirate Praveen  
wrote:
> grunt default
> Running "clean:build" (clean) task
>  >> 5 paths cleaned.
> 
> Running "bundle:build" (bundle) task
> options.entry is deprecated, use options.input
>  >> SyntaxError: 'import' and 'export' may appear only with 
> 'sourceType: module' (2:0)
>  >> at error (/usr/lib/nodejs/rollup/dist/rollup.js:222:12)
>  >> at Object.error$$1 [as error] 
> (/usr/lib/nodejs/rollup/dist/rollup.js:6075:6)
>  >> at /usr/lib/nodejs/rollup/dist/rollup.js:6084:28
>  >> at process._tickCallback (internal/process/next_tick.js:68:7)
> Warning: Task "bundle:build" failed. Use --force to continue.
> 
> Aborted due to warnings.
> 
> Seems it uses rollup 0.24 to build.

Fixed in 3.8.2+dfsg-2
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933273: nullmailer logcheck rules no longer work

[David Bremner]

Marc SCHAEFER  writes:

> Package: nullmailer
> Version: 1:2.2-3
>
> In buster, nullmailer now seems to report as nullmailer-send in syslog:
>
>Jul 28 08:02:08 falken nullmailer-send[586]: Trigger pulled.
>Jul 28 08:02:08 falken nullmailer-send[586]: Rescanning queue.
>Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery, 1 
> message(s) in queue.
>Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery: [ ... ]
>
> thus
>
>sed --in-place 's/nullmailer/nullmailer-send/' 
> /etc/logcheck/ignore.d.server/nullmailer
>
> is required (and maybe everywhere else).
>
> Also some more lines needs filtering (e.g. Message-Id: <.+>) and the order in 
> Starting delivery
> changed.

Thanks for the report and the patch. I saw a few issues in testing
it. One is that the test for Message-Id needs to be case insensitive (at
least w.r.t Id) for my setup. The other thing I noticed is that
nullmailer-send is a bit chattier for me. I have lines of the form

Jul 28 22:12:08 rocinante nullmailer-send[30788]: From:  to: 

That doesn't seem to be specific to my configuration, but I thought I
should check before adding another regex. Do you not have such lines? Do
you actually want them in the logcheck output?

d

Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer

[Felix Lechner]

Hi intrigeri,

On Tue, Jul 30, 2019 at 6:16 AM intrigeri  wrote:
>
> I have WIP locally that also migrates Lintian away from
> Parse::DebianChangelog. I did not finish it yet but if it helps,
> I could push my current branch somewhere.

I knew Lintian would be high on your list and got to work immediately:

https://salsa.debian.org/lintian/lintian/merge_requests/234

I plan more improvements and will share them when appropriate. We
could also cooperate on making a new library available to others.

Kind regards,
Felix Lechner

Bug#901148: timidity: Timidity needed by solfege

[Alain Bertrand]

Package: timidity
Version: buster version as 2019/07/30
Followup-For: Bug #901148

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I upgraded from Stretch to Buster and sound completely disappeared.
Removing Timidity fixed the problem but made me unable to use gnu solfege as it
depends on timidity.
*** End of the template - remove these template lines ***


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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages timidity depends on:
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libflac8  1.3.2-3
ii  libice6   2:1.0.9-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libncurses6   6.1+20181013-2
ii  libogg0   1.3.2-1+b1
ii  libpng16-16   1.6.36-6
ii  libsm62:1.2.3-1
ii  libspeex1 1.2~rc1.2-1+b2
ii  libtinfo6 6.1+20181013-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages timidity recommends:
ii  fluid-soundfont-gm  3.1-5.1

Versions of packages timidity suggests:
pn  fluid-soundfont-gs  
ii  freepats20060219-1
pn  pmidi   
pn  timidity-daemon 

Bug#933491: swanctl.conf must not be world-readable

[Vladimir Bezhenar]

Package: strongswan-swanctl
Version: 5.7.2-1

By default file /etc/swanctl/swanctl.conf is world-readable
(permissions 644). This file can contain passwords for EAP
authentications, therefore it must not be world-readable, as this
information is confidential.

Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package

[Scott Talbert]

On Tue, 30 Jul 2019, Tobias Frost wrote:


(I guess more than 10 packages are affected, so I guess this qualifies
as mass-bug-filing and should be discussed on devel as recommended in
dev-rev §7.1. Would be great if you could follow this procedure. Another
nice thing would be to add blocking indications to the transition bug,
it makes a bit clearer and might help for peeking for fixes -- this is
something I found useful when I did the libpng transition. Thanks for
considering!)


We did discuss this on debian-devel back in November, although technically 
it appears that I didn't mention that we planned to do mass-bug-filing.


https://lists.debian.org/debian-devel/2018/11/msg00551.html

I'll look into adding the blocking indications to the tracking bug, but 
admittedly, I'm not very good with the BTS (and documentation isn't the 
best).



If everything seems to be working fine, that's probably all you need to do.

There are a couple of known issues:
1) If your package uses wxGLCanvas, this doesn't currently work when running
under Wayland.  As a workaround, you can force use of X.  See bug: [2]
2) If your package uses graphics contexts, it may encounter a problem with
coordinate overflow.  See bug: [3]


FTR, darkradiant is also affected by #900678.


I'm not sure that we can afford to wait for a fix for #900678.  There is 
no movement upstream on that and it's more than just a fix - rather 
wxGLCanvas needs to be ported to something like EGL instead of GLX.  I can 
send you a patch that adds the workaround to use X for you to consider.



It might be also affected by [3], how to test that?
There is at least another issue: On my Tuxedo with a QHD+ display, one
area in the windows is no longer using the whole area, but only a
fraction of it. I see that also in slic3r and slic3r-prusa, but I did not
test yet if it requires a QHD+ display to trigger the bug.


To be honest, I'm not sure how to test that one.  Perhaps we could ask the 
kicad developers.  They seem to have switched to the GTK 3 build at least 
on Fedora so perhaps they have figured it out.


Thanks,
Scott

Bug#933406: [anbox] BUGFIX for Condition check resulted in Anbox Container Manager being skipped

[borissh1983]

On Tuesday, 30 July 2019 20:52:02 IDT borissh1...@gmail.com wrote:
> On Tuesday, 30 July 2019 20:38:24 IDT Shengjing Zhu wrote:
> > On Tue, Jul 30, 2019 at 9:21 PM  wrote:
> > > Package: anbox
> > > Version: 0.0~git20190124-1
> > > Severity: important
> > > 
> > > When starting anbox-container-manager.service it fail with "Condition
> > > check
> > > resulted in Anbox Container Manager being skipped" and anbox
> > > session-manager failing to start.
> > > 
> > > This bug prevent starting anbox.
> > > 
> > > transcript:
> > > $ sudo modprobe ashmem_linux
> > > $ sudo modprobe binder_linux
> > > $ sudo systemctl start anbox-container-manager.service
> > > $ sudo tail -f /var/log/syslog
> > > Jul 30 04:19:58 buster systemd[1]: Condition check resulted in Anbox
> > > Container Manager being skipped.
> > > 
> > > $env ANBOX_LOG_LEVEL=debug  anbox session-manager
> > > [ 2019-07-30 04:20:36] [daemon.cpp:61@Run] Failed to connect to socket
> > > /run/ anbox-container.socket: No such file or directory
> > > 
> > > This quilt patch fixes that issue.
> > 
> > I'm not sure how this patch fixes your problem...
> > 
> > "Condition check resulted in Anbox Container Manager being skipped."
> > is caused by this line in anbox-container-manager.service:
> > 
> > ```
> > ConditionPathExists=/var/lib/anbox/android.img
> > ```
> > 
> > You should have a file named /var/lib/anbox/android.img, please read
> > /usr/share/doc/anbox/README.Debian and download an Android rootfs
> > image.
> 
> That file exist,  but the shell script that should bring the bridge up will
> not be run. and the only error you get is the line I had added here.
> 
> When I applied the patch I was able to start anbox.

I'm so sorry, I must have made some during my tests.  After reinstalling anbox  
I can see it had started even without that patch.

Sorry for wasting your time.

Bug#704527: biber: Character "(" not allowed in key although valid in BiBTeX

[Hilmar Preuße]

Control: reassign 704527 biber

Am 02.04.2013 um 14:55 teilte Harri Kiiskinen mit:

Hi Harri,

Long standing issue, I know.

> biber does not seem to accept the character "(" in a bibtex key. This
> is rather irritating, as the old bibtex did accept it along some
> other non-letter characters. This may of course be a conscious choice
> of the developers, but in any case it breaks the backwards
> compatibility of the databases (and for me, a lot of documents) and
> perhaps should be investigated. In older versions of biber there was
> an option to select a different type of parser, which in fact did
> circumvent the problem, but this option has obviously been removed.
> 
A few years has gone, we are at biber 2.12 currently. Could you re-check
if the problem has been solved meanwhile? If not please provide a test
case. Thanks!

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



signature.asc
Description: OpenPGP digital signature

Bug#933406: [anbox] BUGFIX for Condition check resulted in Anbox Container Manager being skipped

[borissh1983]

On Tuesday, 30 July 2019 20:38:24 IDT Shengjing Zhu wrote:
> On Tue, Jul 30, 2019 at 9:21 PM  wrote:
> > Package: anbox
> > Version: 0.0~git20190124-1
> > Severity: important
> > 
> > When starting anbox-container-manager.service it fail with "Condition
> > check
> > resulted in Anbox Container Manager being skipped" and anbox
> > session-manager failing to start.
> > 
> > This bug prevent starting anbox.
> > 
> > transcript:
> > $ sudo modprobe ashmem_linux
> > $ sudo modprobe binder_linux
> > $ sudo systemctl start anbox-container-manager.service
> > $ sudo tail -f /var/log/syslog
> > Jul 30 04:19:58 buster systemd[1]: Condition check resulted in Anbox
> > Container Manager being skipped.
> > 
> > $env ANBOX_LOG_LEVEL=debug  anbox session-manager
> > [ 2019-07-30 04:20:36] [daemon.cpp:61@Run] Failed to connect to socket
> > /run/ anbox-container.socket: No such file or directory
> > 
> > This quilt patch fixes that issue.
> 
> I'm not sure how this patch fixes your problem...
> 
> "Condition check resulted in Anbox Container Manager being skipped."
> is caused by this line in anbox-container-manager.service:
> 
> ```
> ConditionPathExists=/var/lib/anbox/android.img
> ```
> 
> You should have a file named /var/lib/anbox/android.img, please read
> /usr/share/doc/anbox/README.Debian and download an Android rootfs
> image.

That file exist,  but the shell script that should bring the bridge up will not 
be run. and the only error you get is the line I had added here.

When I applied the patch I was able to start anbox.

Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)

[Paul Gevers]

Control: reopen -1

Hi Domenico,

On 30-07-2019 19:09, Debian Bug Tracking System wrote:
>* Autopkgtest on libc-bin-dbgsym instead of dwarves-dbgsym. Closes: 
> #923717.

Unless I am very much mistaken, this is not really fixing the issue. The
problem is that the unstable debug archive isn't available during
migration testing (that's bug #917528, to be fixed in debci). Hence, the
test will still fail if it needs the libc-bin-dbgsym package from
unstable. Please add the skip-not-installable restriction as I
recommended in my initial bug report.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#933097: RFA: ascii -- interactive ASCII name and synonym chart

[Kartik Kulkarni]

Hello,
I would like to adopt this package.

Regards,
Kartik Kulkarni

Bug#520450: fmtutil-sys read TEXMFHOME

[Hilmar Preuße]

Am 19.03.2009 um 22:17 teilte Jörg Sommer mit:

Hi Jörg,

> a upgrade of texlive-base-bin failed, because fmtutil-sys included my
> files in TEXMFHOME. Some files there are broken, which made the call
> failed. My TEXMFHOME is /home/joerg/.texmf.
> 
> % grep /home/jo fmtutil.UXmKocvQ
> (/home/joerg/.texmf/tex/latex/hyperref/hyperref.sty
> (/home/joerg/.texmf/tex/latex/hyperref/hyperref.sty
> 
> The fmtutil-sys program should not look at the private config files of
> root/any user.
> 
Meanwhile the fmtutil has undergone a major rewrite: it is now a perl
script instead of shell. As far as I understand the comments in the
source code, fmtutil still reads home dir of root, but not that of
normal users.

Do you still see the issue?

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



signature.asc
Description: OpenPGP digital signature

Bug#933406: [anbox] BUGFIX for Condition check resulted in Anbox Container Manager being skipped

[Shengjing Zhu]

On Tue, Jul 30, 2019 at 9:21 PM  wrote:
>
> Package: anbox
> Version: 0.0~git20190124-1
> Severity: important
>
> When starting anbox-container-manager.service it fail with "Condition check
> resulted in Anbox Container Manager being skipped" and anbox session-manager
> failing to start.
>
> This bug prevent starting anbox.
>
> transcript:
> $ sudo modprobe ashmem_linux
> $ sudo modprobe binder_linux
> $ sudo systemctl start anbox-container-manager.service
> $ sudo tail -f /var/log/syslog
> Jul 30 04:19:58 buster systemd[1]: Condition check resulted in Anbox Container
> Manager being skipped.
>
> $env ANBOX_LOG_LEVEL=debug  anbox session-manager
> [ 2019-07-30 04:20:36] [daemon.cpp:61@Run] Failed to connect to socket /run/
> anbox-container.socket: No such file or directory
>
> This quilt patch fixes that issue.
>

I'm not sure how this patch fixes your problem...

"Condition check resulted in Anbox Container Manager being skipped."
is caused by this line in anbox-container-manager.service:

```
ConditionPathExists=/var/lib/anbox/android.img
```

You should have a file named /var/lib/anbox/android.img, please read
/usr/share/doc/anbox/README.Debian and download an Android rootfs
image.

-- 
Shengjing Zhu

Bug#932192: nano: More color, and Better default options

[Benno Schulenberg]

Hello Jerome,

For which languages or types of files would you like to see
syntaxes added?  Just adding as many syntaxes as possible does
not seem like a good idea.  You must give some rationale why a
certain syntax would be good to include by default.

> Also add by default option like -c (line number) and -s ispell .
Why do you want to have linenumbers enabled by default for all users?
Do you think the average user would appreciate that?  If yes, then
please explain why you think so.

If the user wants spell checking and 'spell' is not installed,
he or she should figure out what kind of spell checker to use --
nano can not figure this out for them.

> also --softwrap but this one should be discuss.
Enabling softwrap by default... is not a good idea, because nano
gives no indication that softwrap is on (unlike emacs: with a
trailing backslash), and the cursor moves as if the wrapped stuff
is a separate line (unlike vim: it skips to the next true line).

Benno

Bug#767872: tex4ht: htlatex fails without non-zero exit status

[Hilmar Preuße]

Am 03.11.2014 um 07:19 teilte Johannes Schauer mit:

Hi Johannes,

> steps to reproduce:
> 
> $ apt-get install tex4ht
> $ touch test.tex
> $ tex4ht test.tex
> [...cannot find latex...]
> $ echo $?
> 0
> 
> So even though the command just failed, its exit status is zero.
> 
Seems to be solved to me...somehow:

hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/767872$ touch test.tex
hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/767872$ tex4ht test.tex

tex4ht.c (2018-07-03-10:36 kpathsea)
tex4ht test.tex
--- warning --- Can't find/open file `test.dvi'
--- error --- Can't find/open file `test.dvi'
hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/767872$ echo $?
1

I moved the latex binary out of the way. Do you assume your issue to be
solved?

Or did you want instead file a bug report for htlatex , were the issue
is still reproducible (test1 is a valid LaTeX input file):

hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/767872$ htlatex test1
/usr/bin/htlatex: 2: latex: not found
/usr/bin/htlatex: 3: latex: not found
/usr/bin/htlatex: 4: latex: not found

tex4ht.c (2018-07-03-10:36 kpathsea)
tex4ht -f/test1
  -i~/tex4ht.dir/texmf/tex4ht/ht-fonts/
--- warning --- Can't find/open file `test1.dvi'
--- error --- Can't find/open file `test1.dvi'

t4ht.c (2018-07-04-14:25 kpathsea)
t4ht -f/test1
(/usr/share/texlive/texmf-dist/tex4ht/base/unix/tex4ht.env)
--- warning --- Can't find/open file `test1.lg'
hille@debian-amd64-sid:~/devel/TeXLive/open_bugs/767872$ echo $?
0

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



signature.asc
Description: OpenPGP digital signature

Bug#933490: RM: modestmaps-js -- ROM; Dead upstream

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 933489

Please remove modestmaps-js from the archive, it's dead upstream like it
Python counterpart modestmaps-py which was removed recently as well.

Kind Regards,

Bas

Bug#932518: marked as done (buster-pu: package yubikey-personalization/1.19.3-3)

[Jonathan Wiltshire]

Control: reopen -1

p-u bugs will be closed by the stable release managers when the package is 
published in a point release.


On 30 July 2019 17:30:05 BST, Debian Bug Tracking System 
 wrote:
>Your message dated Tue, 30 Jul 2019 18:21:10 +0200
>with message-id <20190730162110.4fzwgmrh72xlaxy5@bogus>
>and subject line Re: Bug#932518: buster-pu: package
>yubikey-personalization/1.19.3-3
>has caused the Debian Bug report #932518,
>regarding buster-pu: package yubikey-personalization/1.19.3-3
>to be marked as done.
>
>This means that you claim that the problem has been dealt with.
>If this is not the case it is now your responsibility to reopen the
>Bug report if necessary, and/or fix the problem forthwith.
>
>(NB: If you are a system administrator and have no idea what this
>message is talking about, this may indicate a serious mail system
>misconfiguration somewhere. Please contact ow...@bugs.debian.org
>immediately.)
>
>
>-- 
>932518: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932518
>Debian Bug Tracking System
>Contact ow...@bugs.debian.org with problems

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.