Bug#922431: closed by Michael Gilbert (Re: Bug#922431: chromium: URL chrome://tracing does not work any more)

[Sébastien Helleu]

On Sat, Feb 16, 2019 at 01:33:06AM +, Debian Bug Tracking System wrote:
> 
> Tracing is disabled in debian starting with 72.0.3626.81-1.  Its
> implementation relies on many sourceless javascript files.
> 
> Best wishes,
> Mike

Then maybe the "Audits" tab in DevTools could be removed? (not sure if that's
easy to do that).

Because it seems broken when you try to perform an audit on a site, there's an
error: "Ah, sorry! We ran into an error: Protocol error (Tracing.start):
'Tracing.start' was not found".

I spent many hours to understand it was related to the latest version available
in Debian, so I think this can confuses other people as well.

-- 
Sébastien Helleu

web: weechat.org / flashtux.org
irc: FlashCode @ irc.freenode.net

Bug#922447: lighttpd: autopkgtest regression

[Paul Gevers]

Source: lighttpd
Version: 1.4.53-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of lighttpd the autopkgtest of lighttpd fails in
testing when that autopkgtest is run with the binary packages of
lighttpd from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
lighttpd   from testing1.4.53-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lighttpd

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lighttpd/1936982/log.gz

autopkgtest [00:11:07]: test defconfig: [---
2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't
exist: /var/cache/lighttpd/uploads
2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir
/var/cache/lighttpd/compress/ Permission denied
2019-02-16 00:11:07: (server.c.1472) Configuration of plugins failed.
Going down.
autopkgtest [00:11:07]: test defconfig: ---]
autopkgtest [00:11:08]: test defconfig:  - - - - - - - - - - results - -
- - - - - - - -
defconfigFAIL non-zero exit status 253
autopkgtest [00:11:08]: test defconfig:  - - - - - - - - - - stderr - -
- - - - - - - -
2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't
exist: /var/cache/lighttpd/uploads
2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir
/var/cache/lighttpd/compress/ Permission denied
2019-02-16 00:11:07: (server.c.1472) Configuration of plugins failed.
Going down.



signature.asc
Description: OpenPGP digital signature

Bug#920459: Toulbar2 issue is caused by doxygen 'cascade of FTBFS'

[Andreas Tille]

Control: retitle -1 Doxygen breaks toulbar2
Control: affects 921779 toulbar2
Control: reassign -1 doxygen

Hi,

I've verified the situation of the build failure and it
shows the typical problem caused by bug #921779.  Thus
I'm reassigning the bug to doxygen.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#824495: Use of the Build-Conflicts field

[Ansgar]

Sean Whitton writes:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases.  See #824495 for the discussion.
>
> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.
>
> (1) a package FTBFSs when: another package that is part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
>
> (2) a package FTBFSs when: a package that is NOT part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
>
> Is (1) an RC-severity bug in the package that FTBFSs?  Is (2)?

How many packages would be affected by (1) or (2)?

I think both are less problematic than the case where the maintainer
uploaded a package which has different features than a rebuild on a
buildd.　That would result in a rebuild (NMUs, next regular upload by
someone else or a changed build environment, binNMUs) to change the
features available to users.  Something we really don't want; note that
this could also happen in security or stable updates.

(Having Build-Conflicts for the additional features case is probably not
implementable with reasonable effort given how autotools and others
enable automatic feature-detection by default which isn't really what
one wants...)

Failing to build in non-standard environments is in contrast a fairly
friendly failure mode.  So it should not be a serious bug (whether RC or
not is something for the release team).

> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.

I doubt we have, but let's ignore that.

Ansgar

Bug#922334: ibus breaks KDE

[Osamu Aoki]

Hi,

I just installed KDE (testing) to see...

I agree this is not the best situation for people under non-Gnome.

On Fri, Feb 15, 2019 at 04:33:08PM -0800, Charles Samuels wrote:
> > > If I exit that, the keyboard stopped working.
> > 
> > You killed input method... so your key stop working.  It's nice if ibus
> > tray is robust to restart automatically to enable keyboard.  But ...
> > Excuse me this is not important bug.
> 
> I didn't "kill" the input method. I choose "Exit" from its right-click-menu.

Yah.  Right click menu has "Exit" which stops panel process.

That certainly causes lots of problem on keyboard input to running
processes.  Maybe "Exit" shouldn't be there to prevent people to stop it
casually.  You are not supposed to exit this panel process.

> > > Why does ibus start automatically in a KDE session but just installing it?

For people in Asia, it or its alternatives such as uim, fcitx are the
way to do keyboard input.  This is the program designed to steal
keyboard inputs and convert them to many different UNICODE input data
stream.  It can also help people to input Arabic, Hebrew, Indic, any
East European non-English characters via modern infrastructure.

GNOME used to configure it with ibus-setup but now it has its internal
component covering tasks which was handled by ibus-setup etc.  So I
don't face this problem involving ibus-setup which is still used by
other DE.  (Wayland transition has its own problem here ...)

> > > Exiting ibus shouldn't break my keyboard, it should just turn off
> > > input method features.
> > 
> > I don't use KDE.  So far on GNOME side, panel thing is not used.
> > Any fix suggestion is welcome.
> 
> I don't have any idea what's even going on here still. I've never heard of an 
> input method that consumes all keystrokes. I would love to give a specific 
> suggestion to fix this, but I don't even know how im-config gets activated.
> 
> > For now, this is user configuration issue.
> 
> With all due respect, a user who runs into the same issue isn't going report 
> the issue, they're going to consider Debian broken and install Fedora because 
> keyboard functionality is so fundamental that should not be broken by merely 
> installing a package or "Exit"ing from a feature most English speakers don't 
> even use.

But English speaker don't need to install this.  So wishlist.

Do I think this as bad situation ... I think so too.

Can I fix this ... no (time, technical skill, ...)

Did KDE or LXDE folks helped me, ... so far no

See other old problems ...
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813111

 I don't know how many of problems are solved externally.

What I need is people who is interested to keep their favorite GUI
platform to help me with functioning patches.

Osamu

Bug#922437: cacti: Please also filter out Network Discover error message

[Paul Gevers]

Control: tags -1 pending

Hi Jeremy,

On 15-02-2019 23:16, Jeremy Bicha wrote:
>  -e "AUTOM8 \[PID: [0-9]\+\] Network Discover is now running" \

I am sorry that I missed it in my upload.

Will fix with my next upload (which may or may not come soon).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#922395: smokeping: fails to stop and to upgrade: start-stop-daemon: matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure

[Gabriel Filion]

On 2019-02-15 10:33 p.m., Gabriel Filion wrote:
> On 2019-02-15 7:53 a.m., Axel Beckert wrote:
>> sorry for the late report, but smokeping failed to configure (probably
>> after the recent upgrade) for a few days for me now:
>>
>> # dpkg --configure -a
>> Setting up smokeping (2.7.3-1) ...
>> apache2_invoke: Enable module cgi
>> [ ok ] Restarting Apache httpd web server: apache2
>> apache2_invoke smokeping: already enabled
>> [ ok ] Reloading Apache httpd web server: apache2.
>> [] Shutting down latency logger daemon: smokepingstart-stop-daemon: 
>> matching only on non-root pidfile /var/run/smokeping/smokeping.pid is 
>> insecure
> 
>> This seems to happen since dpkg 1.19.3. According changelog entry:
> 
> Thanks for bringing this to our attention!
> 
> dpkg 1.19.3 was migrated to testing only a couple days before smokeping
> 2.7.3-1, so maybe when Antoine and I were working on this release our
> tests were running on a previous dpkg version: I've tested out an
> install of smokeping on a fresh install with the init script but I
> didn't notice any error about the pid.
> 
> I'll run more tests to try and reproduce this.

I was able to reproduce this bug by switching an amd64 debian sid VM to
boot using sysvinit, and then to run "dpkg-reconfigure smokeping"

when using the systemd unit, the pid file is owned by root:root and
we're not encountering this issue.

I've found an example for a fix in #920466 that worked for me: adding
"--exec $DAEMON" to the s-s-d command that stops the daemon makes it
possible to stop the daemon without error.

I'll push this fix to salsa and ask for Antoine to review and upload.



signature.asc
Description: OpenPGP digital signature

Bug#824495: Use of the Build-Conflicts field

[Scott Kitterman]

On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote:
> Hello,
> 
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases.  See #824495 for the discussion.
> 
> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.
> 
> (1) a package FTBFSs when: another package that is part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
> 
> (2) a package FTBFSs when: a package that is NOT part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
> 
> Is (1) an RC-severity bug in the package that FTBFSs?  Is (2)?
> 
> It is worth noting that in both cases, the fix is highly non-disruptive
> to maintainer workflows: you just add the build-conflicts metadata.  But
> how easy it is to fix the bug does not determine whether or not that bug
> is RC.
> 
> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.

I'll bite.

I think "reasonable standard development workstation install" is the wrong 
class of standard (whether I have a grasp on it or not).  If it's not going to 
cause an FTBFS on a buildd, I think it's not RC.  That would limit it to 
packages that are build-depends (direct or indirect) of other packages, i.e. 
no leaf packages.

So my answer to both your questions is no.

Scott K

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

Bug#824495: Use of the Build-Conflicts field

[Sean Whitton]

Hello,

Use of the Build-Conflicts field is currently mostly optional, but Ian
Jackson and I have been working on text for Debian Policy that would
require its use in certain cases.  See #824495 for the discussion.

There are two cases which we think that everyone would agree that there
is a bug, but we are not sure that the bug would be considered to be RC.
We are posting to -devel to see if, in fact, we do have a consensus that
these bugs would be RC, or not.

(1) a package FTBFSs when: another package that is part of a "reasonable
standard development workstation install" is present, but the first
package does not declare a Build-Conflicts against the second

(2) a package FTBFSs when: a package that is NOT part of a "reasonable
standard development workstation install" is present, but the first
package does not declare a Build-Conflicts against the second

Is (1) an RC-severity bug in the package that FTBFSs?  Is (2)?

It is worth noting that in both cases, the fix is highly non-disruptive
to maintainer workflows: you just add the build-conflicts metadata.  But
how easy it is to fix the bug does not determine whether or not that bug
is RC.

For the purposes of this e-mail, let's assume that we have a good grasp
on what a "reasonable standard development workstation install" means.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#921593: accent translations

[James Van Zandt]

I am attaching a patch that does the following:

There were translations (HTML or unicode or both) for several specific
normal text characters (a, o, n, etc.) with accents.  I added
translations for rest of the accents on p. 52 of the TeXbook using
pre-composed characters where available, otherwise characters with
combining class "above" or "below".

I added translations for all the math accents listed on p. 135 of the
TeXbook
 similarly, but using ... to get italic characters.

The translations for \~u and \~U were incorrect.  They had the hex
unicode values, but lacked the "x".

\dot was translated as a common period, but should be an accent.

There were several translations for dotless i or j with accents.  I
added translations for those symbols without accents.

I corrected the translation for \models to U+22a7, as per
https://www.compart.com/en/unicode/U+22A8, (The former translation
U+22a8 is the symbol for "true", which is similar to the one for
"models" but not as tall.  There's no record of a symbol "not
models".  U+22ad (decimal 8877) is the Unicode character for "not
true", which is the symbol for "true" with a stroke added.  However,
neither \true nor \false are standard macros in LaTeX, so there is no
need to provide those translations.)

I added translations for many more macros - all the plain TeX symbols
listed here:
http://mirrors.ibiblio.org/CTAN/macros/latex/contrib/unicode-math/unimath-symbols.pdf


There are Unicode translations of several letters with a dot under
accent, and a character with combining class "below".  However,
neither Chrome nor Firefox on Linux render them.

For the accent \vec or \overrightarrow as I've translated them, Chrome
unaccountably changes the font.  Firefox does a better job with lower
case letters, but it fails to raise the accent high enough for the
upper case letters.  I have not tried other browsers.


Most of the new translations use Unicode, but so did some of the
existing translations, even without the --unicode option.  In general,
where I found a named HTML entity, I put it in the --html-entity
section, and the corresponding numeric code in the --unicode section.
Otherwise, I just put the translation in the math macros section that
is always used.

I would appreciate your forwarding this patch to the upstream authors.  It
is meant to be applied after my first patch (that added translations for
cosh, etc.).

For what it's worth, I'm also attaching the test file I used to exercise
most of these translations.


accent-translations
Description: Binary data

 @Article{   a-sample,
  author =	 {J{\"u}rgen Prestin and Daniela Ro\c{s}ca},
  title =	 {On some cubature formulas on the sphere},
  journal =	 {J. Approximation Theory},
  year =	 2019,
  volume =	 2,
  number =	 1,
  pages =	 {11-22},
  month =	 mar,
  abstract =	 {We construct interpolatory cubature rules on the
  two-dimensional sphere, using the fundamental system
  of points obtained by Laín Fernández [Polynomial
  Bases on the Sphere, Logos-Verlag, Berlin, 2003;
  Localized polynomial bases on the sphere,
  Electron. Trans. Numer. Anal. 19 (2005) 84–93]. \\
		  \\
  {\bf Functions:} \\
  \cosh x, {\hbox{cosh}} x	\\
  \tanh x, {\hbox{tanh}} x	\\
		  \sinh x, {\hbox{sinh}} x	\\   
  \sup  x, {\hbox{sup}}  x	\\
  \cos  x, {\hbox{cos}}  x	\\
		  \tan  x, {\hbox{tan}}  x	\\	
  \sin  x, {\hbox{sin}}  x	\\
		  {x\over y}, over (division)  	\\

{\bf Plain text accents (TeXbook, p. 52):}\\
\; \'a\; \'e\; \'i\; \'j\; \'o\; \'u\; \'x\; \'A\; \'E\; \'I\; \'O\; \'U\; \'X \quad \backslash ', grave accent\\
\; \`a\; \`e\; \`i\; \`j\; \`o\; \`u\; \`x\; \`A\; \`E\; \`I\; \`O\; \`U\; \`X \quad \backslash `, acute accent\\
\; \^a\; \^e\; \^i\; \^j\; \^o\; \^u\; \^x\; \^A\; \^E\; \^I\; \^O\; \^U\; \^X \quad \backslash ^, circumflex or hat\\
\; \"a\; \"e\; \"i\; \"j\; \"o\; \"u\; \"x\; \"A\; \"E\; \"I\; \"O\; \"U\; \"X \quad \backslash ", umlaut or dieresis\\
\; \~a\; \~e\; \~i\; \~j\; \~o\; \~u\; \~x\; \~A\; \~E\; \~I\; \~O\; \~U\; \~X \quad tilde\\
\; \=a\; \=e\; \=i\; \=j\; \=o\; \=u\; \=x\; \=A\; \=E\; \=I\; \=O\; \=U\; \=X \quad \backslash =, macron or bar\\
 \u a \u e \u i \u j \u o \u u \u x \u A \u E \u I \u O \u U \u X \quad \backslash u, breve accent\\
 \v a \v e \v i \v j \v o \v u \v x \v A \v E \v I \v O \v U \v X \quad \backslash v, hacek or "check"\\
 \H a \H e \H i \H j \H o \H u \H x \H A \H E \H I \H O \H U \H X \quad \backslash H, long Hungarian umlaut\\
\; \.a\; \.e\; \qquad \qquad \.o\; \.u\; \.x\; \.A\; \.E\  \.I\; \.O\; \.U\; \.X \quad \backslash ., dot accent\\
\;\t xy \quad \backslash t, tie-after accent \\
 \c a \c b \c c \c d \c e \c f \c g \c h \c i \c j \c k \c l \c m \c n \c o \c p \c q \c r \c s \c t \c u \c v \c w \c x \c y \c z , cedilla accent \\
 \d a \d b \d c \d d \d e \d f \d g \d h \d i \d j \d 

Bug#922395: smokeping: fails to stop and to upgrade: start-stop-daemon: matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure

[Gabriel Filion]

Hello,

On 2019-02-15 7:53 a.m., Axel Beckert wrote:
> sorry for the late report, but smokeping failed to configure (probably
> after the recent upgrade) for a few days for me now:
> 
> # dpkg --configure -a
> Setting up smokeping (2.7.3-1) ...
> apache2_invoke: Enable module cgi
> [ ok ] Restarting Apache httpd web server: apache2
> apache2_invoke smokeping: already enabled
> [ ok ] Reloading Apache httpd web server: apache2.
> [] Shutting down latency logger daemon: smokepingstart-stop-daemon: 
> matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure

> This seems to happen since dpkg 1.19.3. According changelog entry:

Thanks for bringing this to our attention!

dpkg 1.19.3 was migrated to testing only a couple days before smokeping
2.7.3-1, so maybe when Antoine and I were working on this release our
tests were running on a previous dpkg version: I've tested out an
install of smokeping on a fresh install with the init script but I
didn't notice any error about the pid.

I'll run more tests to try and reproduce this.



signature.asc
Description: OpenPGP digital signature

Bug#922446: dgit: failed call to git-debrebase when switching native->non-native

[Sean Whitton]

Package: dgit
Version: 8.3
Severity: normal

Hello,

https://git.spwhitton.name/pandoc-citeproc-preamble, commit
36bcd441baa328ea8bf377b791867f5e9e032353, branch 'experimental'

I switched the package from native to non-native, and dgit/gdr decided
this means it was a gdr branch.  I have never used gdr with this package.

spwhitton@iris:~/src/pandoc-citeproc-preamble>dgit sbuild
Format `3.0 (quilt)', need to check/update patch stack
git-debrebase: snag ignored (-funclean-mixed): found mixed 
upstream/packaging commit (d66301d8aca7be2821a083dd7cbefb20bdf164ad)
git-debrebase: snag ignored (-funclean-mixed): found mixed 
upstream/packaging commit (8819e8fe1d3a56c80d7613f829ef70f43ec41eb5)
git-debrebase: snag ignored (-funclean-mixed): found mixed 
upstream/packaging commit (73a9136ac3567732a5aabf0f5592b96cfbe26459)

git-debrebase: error: found unprocessable commit, cannot cope: origin 
commit (39d4085e124a80d4eda6838753e73b26b17ed14f)
git-debrebase: Branch does not seem to be meant to be a git-debrebase 
branch?
git-debrebase: Wrong branch, or maybe you needed git-debrebase 
convert-from-*.
dgit: failed command: git-debrebase --noop-ok -funclean-mixed 
-funclean-ordering make-patches --quiet-would-amend

dgit: error: subprocess failed with error exit status 255

Workaround: `dgit --git-debrebase=true sbuild`.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

[Marek Marczykowski-Górecki]

On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
> Creating new binary packages etc... is not an option anymore during the
> Buster freeze.

Ok, I can carry myself a startup script calling actual xl directly. But
one thing would be very useful to have in buster - avoid starting
dom0 related services in guest. Otherwise even package installation
fails (if you happen to have the same version of xen packages in dom0
and domU). Would the below patch be acceptable?

-8<-

From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 
Subject: [PATCH] Do not start dom0 services if running inside domU

Signed-off-by: Marek Marczykowski-Górecki 
---
 debian/xen-utils-common.xen.init | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
index 4b793d5ac2..d73e827514 100644
--- a/debian/xen-utils-common.xen.init
+++ b/debian/xen-utils-common.xen.init
@@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
exit 0
 fi
 
+if grep -q '[^0-]' /sys/hypervisor/uuid; then
+   log_warning_msg "Xen guest detected"
+   exit 0
+fi
+
 XENCONSOLED="$ROOT"/bin/xenconsoled
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
 XENSTORED="$ROOT"/bin/xenstored
-- 
2.17.2


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Bug#915354: Bug#921482: RFS: note/1.3.26-3 +help

[eamanu15]

I've just upload to m.d.n the update.

https://mentors.debian.net/debian/pool/main/n/note/note_1.3.26-3.dsc

El vie., 15 de feb. de 2019 a la(s) 15:06, eamanu15 (
emmanuelaria...@gmail.com) escribió:

> Hi,
>
>
> El vie., 15 de feb. de 2019 a la(s) 14:27, Dmitry Bogatov (
> kact...@debian.org) escribió:
>
>>
>> [2019-02-11 22:00] eamanu15 
>> > If you look
>> >
>> https://salsa.debian.org/eamanu-guest/note/commit/b2fbec0443dd078dfbcf05efab7729ee3b2e6e3e
>> > you will see that I set myself as maintainer. The Version of note on
>> salsa
>> > was: 1.3.22
>> > But on unstable was 1.3.26
>> >
>> > For this reason, I download the files from package.debian
>> > the 1.3.26 and updated it on salsa:
>> >
>> https://salsa.debian.org/eamanu-guest/note/commit/0bb88562fd7c3b2a2035bd0d0f5b919b4a24af15
>> >
>> > But, when I continue working on the package on
>> >
>> https://salsa.debian.org/eamanu-guest/note/commit/5bc4330c7f174713549f4bf4e1839d669e637551
>> > I forgot set myself as maintainer. Was my foul.
>> >
>> > For this reason In this new package version 1.3.26-3 I add me
>> > on Maintainer field.
>>
>> So I believe simple "Set myself as Maintainer" would do. Or am I missing
>> something again?
>>
>
> Nope, you are right. I will write that
>
> Thanks
>
>> --
>> Note, that I send and fetch email in batch, once every 24 hours.
>>  If matter is urgent, try https://t.me/kaction
>>
>>--
>>
>
>
> --
> Arias Emmanuel
> http://eamanu.com
> Github/Gitlab; @eamanu
> Debian: @eamanu-guest
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#922444: racket: Install Package doesn't work in DrRacket

[Mike Manilone]

Package: racket
Version: 7.1+dfsg1-1
Severity: normal

Dear Maintainer,

In a recent version of Racket, the "Install Package" under "File" menu doesn't
work and reports an internal error:

cadr: contract violation
  expected: (cons/c any/c pair?)
  given: #f
  context...:
   /usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by-
source.rkt:534:4: adjust-deps method in by-source-panel%
   /usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by-
source.rkt:422:4: adjust-all method in by-source-panel%
   /usr/share/racket/collects/racket/private/class-internal.rkt:3554:0:
continue-make-object
   /usr/share/racket/collects/racket/private/class-internal.rkt:3508:0: do-
make-object
   /usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui.rkt:44:0: make-pkg-
installer8
   /usr/share/racket/collects/racket/contract/private/arrow-val-first.rkt:428:3
   /usr/share/racket/pkgs/gui-lib/mred/private/mrmenu.rkt:250:14: command
method in basic-selectable-menu-item%
   /usr/share/racket/collects/racket/private/more-scheme.rkt:148:2: call-with-
break-parameterization
   /usr/share/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-
exception-handler
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:430:6
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:481:32
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:629:3

Since I and many others are relying on this function (installing a package) for
learning purposes, this problem may render Racket effectively unusable for
these people. I hope you can consider fixing this problem. Thank you very much!

Regards



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

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

Versions of packages racket depends on:
ii  libc6  2.28-6
ii  libffi63.2.1-9
ii  racket-common  7.1+dfsg1-1

Versions of packages racket recommends:
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpng16-16  1.6.36-5
ii  libssl1.11.1.1a-1
ii  racket-doc   7.1+dfsg1-1

racket suggests no packages.

-- no debconf information

Bug#922443: texlive-extra-utils: latexpand script: detection of comments is buggy

[Vincent Lefevre]

Package: texlive-extra-utils
Version: 2018.20190131-1
Severity: normal
Tags: patch upstream
Forwarded: https://gitlab.com/latexpand/latexpand/merge_requests/6

In the latexpand script, the detection of comments is buggy:
if a % is not at the beginning of a line, it will not be regarded
as introducing a comment, unless it is preceded by a backslash;
in short, the meaning of a backslash has been reversed.

This means that if one has a line like

 % and then \input it with a command in babelbst.tex.

(with a space before the "%"), latexpand attempts to open the
file named "it".

I don't think this is a security bug, but users should be careful
when working on 3rd-party .tex files, if sanitization does not
take care of this bug and other limitations.

I've attached a patch.

This may not be sufficient because code like \\% is not considered,
but the behavior has improved.

-- 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-r--r-- 1 root root 2879 2019-02-12 01:34:10 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2018-09-02 14:32:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2019-01-31 04:53:23 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2019-01-31 04:53:23 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2019-01-31 04:53:23 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2019-01-31 04:53:23 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 2019-02-02 17:01:20 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages texlive-extra-utils depends on:
ii  libunicode-linebreak-perl  0.0.20170401-1+b1
ii  python 2.7.15-4
ii  tex-common 6.10
ii  texlive-base   2018.20190131-1
ii  texlive-binaries   2018.20181218.49446-1
ii  texlive-latex-base 2018.20190131-1

Versions of packages texlive-extra-utils recommends:
ii  ghostscript9.26a~dfsg-0+deb9u1
ii  libfile-homedir-perl   1.004-1
ii  libyaml-tiny-perl  1.73-1
ii  ruby   1:2.5.1
ii  texlive-latex-recommended  2018.20190131-1

Bug#922442: There is a security weakness in p7zip password encryption. IV for AES-CBC is generated from a very poor RNG (poorly seeded) and half of it is always zeroes.

[3lbios]

Package: p7zip
Version: 9.20.1~dfsg.1-4.1+deb8u3
Severity: normal
Tags: security patch



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv6l

Kernel: Linux 4.14.90+
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages p7zip depends on:
ii  libc6   2.19-18+deb8u10
ii  libgcc1 1:4.9.2-10+deb8u2
ii  libstdc++6  4.9.2-10+deb8u2

p7zip recommends no packages.

Versions of packages p7zip suggests:
pn  p7zip-full  

-- no debconf information
>From eb9809b3236084fbfbdcdd4f7c5b7fe0fcd6524c Mon Sep 17 00:00:00 2001
From: Michal Stanek 
Date: Tue, 12 Feb 2019 23:54:51 +0100
Subject: [PATCH] Fix cryptography weaknesses in KDF and the RNG used for AES
 IV.

Mix in OS randomness for RNG seed. Increase KDF iterations from 1000 to 1 to get it closer to modern standards.
Use full 16 bytes for AES IV instead of just 8.
---
 CPP/7zip/Crypto/7zAes.cpp   | 2 +-
 CPP/7zip/Crypto/RandGen.cpp | 9 +
 CPP/7zip/Crypto/WzAes.cpp   | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/CPP/7zip/Crypto/7zAes.cpp b/CPP/7zip/Crypto/7zAes.cpp
index d33b562..64fe7b6 100644
--- a/CPP/7zip/Crypto/7zAes.cpp
+++ b/CPP/7zip/Crypto/7zAes.cpp
@@ -164,7 +164,7 @@ STDMETHODIMP CEncoder::ResetInitVector()
 {
   for (unsigned i = 0; i < sizeof(_iv); i++)
 _iv[i] = 0;
-  _ivSize = 8;
+  _ivSize = 16;
   g_RandomGenerator.Generate(_iv, _ivSize);
   return S_OK;
 }
diff --git a/CPP/7zip/Crypto/RandGen.cpp b/CPP/7zip/Crypto/RandGen.cpp
index f5ea31f..c141806 100644
--- a/CPP/7zip/Crypto/RandGen.cpp
+++ b/CPP/7zip/Crypto/RandGen.cpp
@@ -10,6 +10,8 @@
 
 #ifndef _WIN32
 #include 
+#include 
+#include 
 #define USE_POSIX_TIME
 #define USE_POSIX_TIME2
 #endif
@@ -58,6 +60,13 @@ void CRandomGenerator::Init()
 LARGE_INTEGER v;
 if (::QueryPerformanceCounter())
   HASH_UPD(v.QuadPart);
+#else
+// get real randomness from the OS and mix it in
+uint64_t randbytes;
+ssize_t rv = 0;
+while (rv != sizeof(randbytes))
+  rv = getrandom((void *), sizeof(randbytes), 0);
+HASH_UPD(randbytes);
 #endif
 
 #ifdef USE_POSIX_TIME
diff --git a/CPP/7zip/Crypto/WzAes.cpp b/CPP/7zip/Crypto/WzAes.cpp
index 4572f06..db81a39 100644
--- a/CPP/7zip/Crypto/WzAes.cpp
+++ b/CPP/7zip/Crypto/WzAes.cpp
@@ -24,7 +24,7 @@ namespace NWzAes {
 
 const unsigned kAesKeySizeMax = 32;
 
-static const UInt32 kNumKeyGenIterations = 1000;
+static const UInt32 kNumKeyGenIterations = 1;
 
 STDMETHODIMP CBaseCoder::CryptoSetPassword(const Byte *data, UInt32 size)
 {
-- 
2.17.1

>From eb9809b3236084fbfbdcdd4f7c5b7fe0fcd6524c Mon Sep 17 00:00:00 2001
From: Michal Stanek 
Date: Tue, 12 Feb 2019 23:54:51 +0100
Subject: [PATCH] Fix cryptography weaknesses in KDF and the RNG used for AES
 IV.

Mix in OS randomness for RNG seed. Increase KDF iterations from 1000 to 1 to get it closer to modern standards.
Use full 16 bytes for AES IV instead of just 8.
---
 CPP/7zip/Crypto/7zAes.cpp   | 2 +-
 CPP/7zip/Crypto/RandGen.cpp | 9 +
 CPP/7zip/Crypto/WzAes.cpp   | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/CPP/7zip/Crypto/7zAes.cpp b/CPP/7zip/Crypto/7zAes.cpp
index d33b562..64fe7b6 100644
--- a/CPP/7zip/Crypto/7zAes.cpp
+++ b/CPP/7zip/Crypto/7zAes.cpp
@@ -164,7 +164,7 @@ STDMETHODIMP CEncoder::ResetInitVector()
 {
   for (unsigned i = 0; i < sizeof(_iv); i++)
 _iv[i] = 0;
-  _ivSize = 8;
+  _ivSize = 16;
   g_RandomGenerator.Generate(_iv, _ivSize);
   return S_OK;
 }
diff --git a/CPP/7zip/Crypto/RandGen.cpp b/CPP/7zip/Crypto/RandGen.cpp
index f5ea31f..c141806 100644
--- a/CPP/7zip/Crypto/RandGen.cpp
+++ b/CPP/7zip/Crypto/RandGen.cpp
@@ -10,6 +10,8 @@
 
 #ifndef _WIN32
 #include 
+#include 
+#include 
 #define USE_POSIX_TIME
 #define USE_POSIX_TIME2
 #endif
@@ -58,6 +60,13 @@ void CRandomGenerator::Init()
 LARGE_INTEGER v;
 if (::QueryPerformanceCounter())
   HASH_UPD(v.QuadPart);
+#else
+// get real randomness from the OS and mix it in
+uint64_t randbytes;
+ssize_t rv = 0;
+while (rv != sizeof(randbytes))
+  rv = getrandom((void *), sizeof(randbytes), 0);
+HASH_UPD(randbytes);
 #endif
 
 #ifdef USE_POSIX_TIME
diff --git a/CPP/7zip/Crypto/WzAes.cpp b/CPP/7zip/Crypto/WzAes.cpp
index 4572f06..db81a39 100644
--- a/CPP/7zip/Crypto/WzAes.cpp
+++ b/CPP/7zip/Crypto/WzAes.cpp
@@ -24,7 +24,7 @@ namespace NWzAes {
 
 const unsigned kAesKeySizeMax = 32;
 
-static const UInt32 kNumKeyGenIterations = 1000;
+static const UInt32 kNumKeyGenIterations = 1;
 
 STDMETHODIMP CBaseCoder::CryptoSetPassword(const Byte *data, UInt32 size)
 {
-- 
2.17.1

>From eb9809b3236084fbfbdcdd4f7c5b7fe0fcd6524c Mon Sep 17 00:00:00 2001
From: Michal Stanek 
Date: Tue, 12 Feb 2019 23:54:51 +0100
Subject: [PATCH] Fix cryptography weaknesses in KDF and the RNG 

Bug#922334: ibus breaks KDE

[Charles Samuels]

> > If I exit that, the keyboard stopped working.
> 
> You killed input method... so your key stop working.  It's nice if ibus
> tray is robust to restart automatically to enable keyboard.  But ...
> Excuse me this is not important bug.

I didn't "kill" the input method. I choose "Exit" from its right-click-menu.

> 
> Please exit GUI environment if you want to reconfigure.  Please rondomly
> kill process and ask nothing happens.

I did no such thing.

> 
> > Why does ibus start automatically in a KDE session but just installing it?
> 
> See above.

???

> 
> > Exiting ibus shouldn't break my keyboard, it should just turn off
> > input method features.
> 
> I don't use KDE.  So far on GNOME side, panel thing is not used.
> Any fix suggestion is welcome.

I don't have any idea what's even going on here still. I've never heard of an 
input method that consumes all keystrokes. I would love to give a specific 
suggestion to fix this, but I don't even know how im-config gets activated.

> For now, this is user configuration issue.

With all due respect, a user who runs into the same issue isn't going report 
the issue, they're going to consider Debian broken and install Fedora because 
keyboard functionality is so fundamental that should not be broken by merely 
installing a package or "Exit"ing from a feature most English speakers don't 
even use.

> To stop ibus running while it is installed,
> 
> option1: remove im-config
> option2: use im-config to set system wide IM to NONE.

Until I reported this bug, I didn't even know ibus and im-config existed.

Charles

Bug#922334: ibus breaks KDE

[Osamu Aoki]

control: tags -1 - upstream
control: severity -1 wishlist
control: retitle -1 make keyboard input riobust when panel is killed

Hi,

Please note you are the first to complain for the stable system which is
out there for almost 2 years. If there were something so grossly bad, I
should have heard... 

On Fri, Feb 15, 2019 at 09:35:09AM -0800, Charles Samuels wrote:
> I performed an experiment where I installed a basic Debian stretch in a VM. 
> Then I installed KDE and saw that it was working fine.
> 
> Then I installed ibus. KDE continued to work fine.
> 
> I saw ibus was running and there was the ibus icon in the tray.

That's because "recommends" pulls in im-config which starts ibus daemon.
This is good default since whoever needs to use ibus needs to start it.

> If I exit that, the keyboard stopped working.

You killed input method... so your key stop working.  It's nice if ibus
tray is robust to restart automatically to enable keyboard.  But ...
Excuse me this is not important bug.

Please exit GUI environment if you want to reconfigure.  Please rondomly
kill process and ask nothing happens.

> Why does ibus start automatically in a KDE session but just installing it?

See above.

> Exiting ibus shouldn't break my keyboard, it should just turn off
> input method features.

I don't use KDE.  So far on GNOME side, panel thing is not used.
Any fix suggestion is welcome.

For now, this is user configuration issue.

To stop ibus running while it is installed, 

option1: remove im-config
option2: use im-config to set system wide IM to NONE.

Read im-config

Osamu

Bug#922441: Always allow user to quit/break out/suspend back to his shell

[積丹尼 Dan Jacobson]

Package: w3m
Version: 0.5.3-37

When w3m is connecting to a (malfunctioning) site, the user sees

"Opening socket..."

If for some reason there is no further response from the site,
the user has no way to stop w3m, and return to his shell.

Let's compare the same thing with lynx.
Making HTTPS connection to myhealthbank.nhi.gov.tw

At this point, even if nothing further happens, the user can hit ^C and
return to his shell. With w3m, even ^Z doesn't let him get back.

Bug#846645:

[Lehmann Schulz]

Je ne sais pas si vous recevez la proposition que je vous ai envoyée.

Bug#922019: cdimage.debian.org: Non-free live builds missing contrib and non-free components

[Steve McIntyre]

Hi Daniel,

On Mon, Feb 11, 2019 at 03:52:01AM -0600, Daniel Lewart wrote:
>Package: cdimage.debian.org
>Severity: normal
>Tags: patch
>
>Debian Images Team,
>
>Unofficial non-free live builds for both stretch and buster
>are missing the contrib and non-free components in base.list.
>
># Stretch live
>$ cat /etc/apt/sources.list.d/base.list
>deb http://deb.debian.org/debian/ stretch main
>#deb-src http://deb.debian.org/debian/ stretch main
>
># Buster live
>$ cat /etc/apt/sources.list.d/base.list
>deb http://deb.debian.org/debian/ buster main
>#deb-src http://deb.debian.org/debian/ buster main

Right, that's as expected. The only non-free bit about those images is
that they include some non-free firmware packages too. Otherwise
they're just the same as the normal free images. Is there a problem
with that?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#922440: Needed a space before >

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-5
Severity: minor

$ dpkg -l *grub*> /tmp/ #Failed to complete. Had to use
$ dpkg -l *grub* > /tmp/

Bug#921136: lintian: hardening-no-fortify-functions possible false positive

[Chris Lamb]

Hi Scott,

> I really don't understand C++ templates very well, but grepping around 
> the  system includes directory, I have a hunch this might be the wmemcpy in 
> question:
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L477

Looks plausible... Alas, I'm really not that about this whole
thing. I will thus leave this bug as "moreinfo" awaiting input from
others.


Regards,

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

Bug#922439: python traceback due to firmware issues

[Arturo Borrero Gonzalez]

Package: chirp
Version: 1:20190104-1
Severity: normal
Tags: upstream

Dear maintainer,

thanks for your work on this package. It's really appreciated.

Today, when uploading a custom config to a Baofeng UV-5R I found this python
traceback:

ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 254, in run
self.__radio.sync_out()
  File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 816, in 
sync_out
_do_upload(self)
  File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 674, in 
_do_upload
raise errors.RadioError(msg % (image_version, radio_version))
RadioError: Upload finished, but the 'Other Settings' could not be sent because 
the firmware version of the image (N5R2407BFB297 ) does not match that of the 
radio (HN5RV011FB297 ).

ERROR: 
ERROR: Clone failed: Upload finished, but the 'Other Settings' could not be 
sent because the firmware version of the image (N5R2407BFB297 ) does not match 
that of the radio (HN5RV011FB297 ).
ERROR: --- Exception Dialog: Upload finished, but the 'Other Settings' could 
not be sent because the firmware version of the image (N5R2407BFB297 ) does not 
match that of the radio (HN5RV011FB297 ). ---
ERROR: None

ERROR: 

The graphical interface showed a dialog window with a similar message.

Not sure if this traceback should be handled more gracefully, or this is
totally expected.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.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 chirp depends on:
ii  python   2.7.15-4
ii  python-gtk2  2.24.0-5.1+b1
ii  python-libxml2   2.9.4+dfsg1-7+b3
ii  python-libxslt1  1.1.32-2
ii  python-serial3.4-4

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information

Bug#835913: ibus: use of dbus-run-session ...

[Osamu Aoki]

Hi,

Thanks for bug report.

I tried to apply proposed patch but it caused build failure.

---
  snip star of build log
Making all in dconf
make[5]: Entering directory '/build/ibus-1.5.19/data/dconf'
LC_ALL=C /usr/bin/intltool-merge  -x -u --no-translations 
org.freedesktop.ibus.gschema.xml.in org.freedesktop.ibus.gschema.xml
sed \
-e 's|@VERSION[@]|1.5.19|g' 00-upstream-settings.5.in > 
00-upstream-settings.5.tmp && \
mv 00-upstream-settings.5.tmp 00-upstream-settings.5
sed \
-e 's|@VERSION[@]|1.5.19|g' ibus.5.in > ibus.5.tmp && \
mv ibus.5.tmp ibus.5
gzip -c 00-upstream-settings.5 > 00-upstream-settings.5.gz.tmp && mv 
00-upstream-settings.5.gz.tmp 00-upstream-settings.5.gz
gzip -c ibus.5 > ibus.5.gz.tmp && mv ibus.5.gz.tmp ibus.5.gz
Merging translations into org.freedesktop.ibus.gschema.xml.
CREATED org.freedesktop.ibus.gschema.xml
/usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas --strict --dry-run  
--schema-file=org.freedesktop.ibus.gschema.xml && mkdir -p . && touch 
org.freedesktop.ibus.gschema.valid
dbus-run-session -- ./make-dconf-override-db.sh > 00-upstream-settings || \
{ rc=$?; rm -f -rf 00-upstream-settings; exit $rc; }
dbus[22693]: Unable to set up transient service directory: XDG_RUNTIME_DIR 
"/run/user/1000" not available: No such file or directory

(process:22700): dconf-CRITICAL **: 23:09:54.363: unable to create directory 
'/run/user/1000/dconf': Permission denied.  dconf will not work properly.

  snip errors ...
(process:22710): dconf-CRITICAL **: 23:09:54.371: unable to create directory 
'/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(process:22710): dconf-CRITICAL **: 23:09:54.371: unable to create directory 
'/run/user/1000/dconf': Permission denied.  dconf will not work properly.
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill 
-l [sigspec]
make[5]: *** [Makefile:809: 00-upstream-settings] Error 2
rm 00-upstream-settings.5 ibus.5
make[5]: Leaving directory '/build/ibus-1.5.19/data/dconf'
---

Do you know how this XDG_RUNTIME_DIR thing?

Osamu
From: Simon McVittie 
Date: Mon, 29 Aug 2016 10:07:40 +0100
Subject: [PATCH] use dbus-run-session to set up dconf overrides

As described in 
I'm trying to reduce how much dbus-launch is used in Debian.
This package currently uses dbus-launch to run some infrastructure bits.

https://bugs.debian.org/835913

Signed-off-by: Osamu Aoki 
---
 data/dconf/Makefile.am   | 2 +-
 data/dconf/make-dconf-override-db.sh | 4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/data/dconf/Makefile.am b/data/dconf/Makefile.am
index 433d993..8182da0 100644
--- a/data/dconf/Makefile.am
+++ b/data/dconf/Makefile.am
@@ -41,7 +41,7 @@ org.freedesktop.ibus.gschema.xml.in: $(top_srcdir)/data/ibus.schemas.in
 
 00-upstream-settings: $(srcdir)/make-dconf-override-db.sh | $(gsettings_SCHEMAS)
 	@$(MKDIR_P) db
-	$(AM_V_GEN) $(srcdir)/make-dconf-override-db.sh > $@ || \
+	$(AM_V_GEN) dbus-run-session -- $(srcdir)/make-dconf-override-db.sh > $@ || \
 		{ rc=$$?; $(RM) -rf $@; exit $$rc; }
 
 man_5_in_files = 00-upstream-settings.5.in ibus.5.in
diff --git a/data/dconf/make-dconf-override-db.sh b/data/dconf/make-dconf-override-db.sh
index 9c650e9..6c1c168 100755
--- a/data/dconf/make-dconf-override-db.sh
+++ b/data/dconf/make-dconf-override-db.sh
@@ -12,9 +12,7 @@ export XDG_CACHE_HOME="$TMPDIR/cache"
 export GSETTINGS_SCHEMA_DIR="$TMPDIR/schemas"
 mkdir -p $XDG_CONFIG_HOME $XDG_CACHE_HOME $GSETTINGS_SCHEMA_DIR
 
-eval `dbus-launch --sh-syntax`
-
-trap 'rm -rf $TMPDIR; kill $DBUS_SESSION_BUS_PID' ERR
+trap 'rm -rf $TMPDIR' ERR
 
 # in case that schema is not installed on the system
 glib-compile-schemas --targetdir "$GSETTINGS_SCHEMA_DIR" "$PWD"
-- 
2.20.1

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

Control: tags -1 - moreinfo


On Thu, 14 Feb 2019 19:28:29 + Simon McVittie wrote:

> On Sat, 09 Feb 2019 at 23:26:53 +0100, Francesco Poli wrote:
> > On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:
> > > I guess I already mentioned the two alternatives (runuser/setpriv).
> > [...]
> > 
> > Maybe setpriv is equivalent to s6-setuidgid.
> > If this is the case, it can be used as an alternative to s6-setuidgid.
> 
[...]
> Running `setpriv --reuid NAME --init-groups PROGRAM ARGS` appears to be
> equivalent to `s6-setuidgid NAME PROGRAM ARGS`.

OK, thanks for the explanation.
I'll try to find some time to experiment and apply this change to
apt-listbugs. Since buster is already in soft freeze, the modification
will probably have to be meant for buster+1 ...

[...]
> > I would like some insight especially on [message #30], regarding the
> > fact that runuser does something basically equivalent to what su does,
> > and thus seems to be unfit to irreversibly drop root privileges
> 
> The major difference between {setpriv,s6-setuidgid} and runuser is that
> runuser, like su, sets up a new PAM session and re-initializes some
> standard environment variables.
> 
> Also like su, if run with -l, it also tries to behave like a login shell
> (clears more environment variables, changes to the target user's home
> directory, etc.) and runs a different PAM stack (which registers with
> systemd-logind, if installed, as a new login session).
> 
> However, runuser is not setuid (unlike su), so it cannot increase
> privileges, only drop them. The only thing it *can* do is to drop root
> privileges; so if you consider it to be unfit to do that for some reason,
> it would have no purpose at all.

As far as I understand it (after reading the [web page] cited in
the commit where I introduce the s6 recommendation into apt-listbugs),
the problem with su and similar programs is not that they cannot drop
root privileges, but that they cannot do so irreversibly.

[web page]: 

However, this is not especially important now, since we are talking
about replacing s6-setuidgid with setpriv...

[...]
> > and
> > regarding my search for a command that works like s6-setuidgid, but
> > runs the given command inside the user's login shell (with all the
> > environment that the user would get on a normal login).
> 
> As stated, this isn't really well-defined. Whether and how this is
> possible depends what you mean by "a normal login". The execution
> environment the user would get from login(1) as invoked by getty(8),
> from a display manager like xdm, and from sshd are all different (they
> invoke different PAM stacks); and that's before you've even entered
> any shells.
[...]

Wow, thanks a lot for the very long and detailed explanations!
They were an interesting read that clarified some points.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpkexsv1GzgQ.pgp
Description: PGP signature

Bug#576359: usb bootdrive utilities in Debian

[Matt Taggart]

Today I was looking for utilities to create bootable USB drives. In WNPP
I discovered quite a few ITP/RFPs for these types of tools:

https://bugs.debian.org/cgi-bin/bugreport.cgi?915458
multibootusb -- A cross platform utility to create multi boot live Linux
on a removable USB disk

https://bugs.debian.org/cgi-bin/bugreport.cgi?576359
usb-creator-to-be-renamed -- startup disk creator#718301
fedora-liveusb-creator -- Cross-platform tool for installing live
operating systems on to USB flash drives

https://bugs.debian.org/cgi-bin/bugreport.cgi?732647
mintstick -- USB stick formatter and ISO image writer

https://bugs.debian.org/cgi-bin/bugreport.cgi?831981
mkusb - Tool to make boot drives.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718301
fedora-liveusb-creator -- Cross-platform tool for installing live
operating systems on to USB flash drives (now MediaWriter)

https://bugs.debian.org/cgi-bin/bugreport.cgi?869875
woeusb -- Bootable USB Storage Creator for Windows Installer/PE

And already in debian there is debootstick and some other efi/iso tools.

Some of these are old and may not be supported/useful any more.
Some of these may be distro/OS specific,
But hopefully there is one that is being maintained and is generic
enough to replace what the others do so we don't need to maintain all
these things.

Submitters/participants, please reply to your bugs (trim cc list
accordingly) and let us know what's going on with these.

-- 
Matt Taggart
tagg...@debian.org

Bug#785356: RE

[Jong, Mirella de]

We are involved in commercial financing, wholesale commercial lending, 
commercial brokering, operating under an appraisal firm with the aim of 
providing private investment funding for entrepreneurs utilising the SECs 
popular private placement programs.

Kindly advice if you have any viable project that requires funding. please 
contact me directly for more details: besheu...@hotmail.com

Regards,
W. Cadu (Phd)




















"De informatie verzonden met dit bericht is uitsluitend bestemd voor de 
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is 
verboden. Openbaarmaking,vermenigvuldiging, verspreiding en/of verstrekking van 
deze informatie aan derden is niet toegestaan.

Het is mogelijk dat tijdens het transport van dit bericht fouten zijn ontstaan 
zodat het bericht onjuist is overgekomen. Hiervoor kunnen wij geen 
aansprakelijkheid erkennen. Uitsluitend het door de bevoegde persoon dan wel 
het bevoegde bestuursorgaan ondertekende papieren document is bindend. Wij 
adviseren u om bij twijfel over de juistheid of volledigheid contact met ons op 
te nemen".

Bug#920355: debian-policy: Permit branch specifications ("-b") in Mercurial Vcs-Hg headers

[Sean Whitton]

control: tag -1 +pending

Hello,

On Thu 24 Jan 2019 at 05:05PM +01, Chris Lamb wrote:

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 44080c9..013aae4 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -973,10 +973,11 @@ repository where the Debian source package is 
> developed.
>- Mtn (Monotone)
>- Svn (Subversion)
>
> -In the case of Git, the value consists of a URL, optionally followed
> -by the word ``-b`` and the name of a branch in the indicated
> -repository, following the syntax of the ``git clone`` command. If no
> -branch is specified, the packaging should be on the default branch.
> +In the case of Git and Mercurial, the value consists of a URL,
> +optionally followed by the word ``-b`` and the name of a branch in
> +the indicated repository, following the syntax of the ``git clone``
> +or ``hg clone`` command. If no branch is specified, the packaging
> +should be on the default branch.
>
>More than one different VCS may be specified for the same package.

Seconded and committed, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#908698: smarty3: CVE-2018-16831

[Mike Gabriel]

Hi Moritz, Salvatore,

On  Do 27 Dez 2018 21:44:33 CET, Salvatore Bonaccorso wrote:


Hi Mike,

On Thu, Nov 22, 2018 at 08:00:07PM +0100, Moritz Mühlenhoff wrote:
On Fri, Oct 26, 2018 at 04:46:39PM +,  
mike.gabr...@das-netzwerkteam.de wrote:

> Hi,
>
> On Friday, 26 October 2018, Moritz Mühlenhoff wrote:
> > On Tue, Sep 18, 2018 at 05:06:14PM +, Mike Gabriel wrote:
> > > Hi,
> > >
> > > On  Mo 17 Sep 2018 23:20:33 CEST, Moritz Mühlenhoff wrote:
> > >
> > > > On Mon, Sep 17, 2018 at 09:07:38PM +, Mike Gabriel wrote:
> > > > > I have looked at the changes between 3.1.33 (just  
uploaded to unstable) and

> > > > > 3.1.31 (in stable). They are awful. Read the below...
> > > > >
> > > > > 15:42 < sunweaver> Hi all, I have just looked into
> > > > > https://security-tracker.debian.org/tracker/CVE-2018-16831
> > > > > 15:43 < sunweaver> even for stretch, it is pretty much  
impossible to
> > > > > backport the patch series (at least for patches, all  
containing tons of

> > > > > regexp with
> > > > > multitudes of slashes and backslashes).
> > > > > 15:43 < sunweaver> totall insane...
> > > > > 15:44 < sunweaver> in fact, my recommendation for jessie  
and stretch would
> > > > > be (with my maintainer hat _and_ LTS team hats on at  
once): bring the latest

> > > > > upstream release to jessie/stretch.
> > > > > 15:44 < sunweaver> In jessie, we need to upgrade  
smarty-lexer as well for

> > > > > that.
> > > > > 15:46 < sunweaver> the 4 patches we needed at least are these...
> > > > > 15:47 < sunweaver>  
https://github.com/smarty-php/smarty/commit/8d21f38dc35c4cd6b31c2f23fc9b8e5adbc56dfe
> > > > > 15:47 < sunweaver>  
https://github.com/smarty-php/smarty/commit/f9ca3c63d1250bb56b2bda609dcc9dd81f0065f8
> > > > > 15:47 < sunweaver>  
https://github.com/smarty-php/smarty/commit/2e081a51b1effddb23f87952959139ac62654d50
> > > > > 15:47 < sunweaver>  
https://github.com/smarty-php/smarty/commit/c9dbe1d08c081912d02bd851d1d1b6388f6133d1

> > > > > 15:48 < sunweaver> and these four sit on top of this...
> > > > > 15:48 < sunweaver>  
https://github.com/smarty-php/smarty/commit/f7a53162058de410a35a9848e6d0795d7c252aaf

> > > > > 15:48 < sunweaver> and 10+ other commits.
> > > > > 15:48 < sunweaver> all tackling the same code passage.
> > > > > 15:49 < sunweaver> @all: can we reach consensus that  
latest upstream release

> > > > > would be best for jessie LTS and stretch (OT here).
> > > > >
> > > > > The pile of patches is so awful, I strongly advise getting latest
> > > > > smarty-lexer and latest smarty3 from unstable into stable  
with thorough
> > > > > testing of dependent application (gosa, FusionDirectory,  
slbackup-php, ...).
> > > > > Most of them are maintained by me and I have running  
setups for testing this

> > > > > (except 1 package in Debian IIRC).
> > > >
> > > > If you have reasonable test coverage of the reverse deps,  
we can do that.

> > > >
> > > > But let's wait for a few more days to spot eventual  
regressions reported
> > > > in unstable first. Also, make sure to coordinate the  
release of the DLA with
> > > > the DSA, otherwise we end up with a situation where  
oldstable has a higher

> > > > version number than stable.
> > > >
> > > > Cheers,
> > > > Moritz
> > >
> > > I will wait another week with this. I'd like to get this  
solved before my

> > > VAC (6th Oct - 21st Oct).
> >
> > What's the status?
> >
> > Cheers,
> > Moritz
> >
>
> I am still waiting for upstream to verify / confirm my patch.  
Ping dropped Monday this week.


Any feedback?


Did you got any feedback on it?



No. However, this week I took some time and tested my patch more  
intensively. It throws PHP exceptions on certain code paths.


Need to reinvestigate and update my patch... It's on my list, so stay  
tuned. Sorry for the long delay on my side.


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 (4354) 8390 139

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



pgpeKIqfA56xv.pgp
Description: Digitale PGP-Signatur

Bug#917431: debian-policy: virtual packages: logind, default-logind

[Sean Whitton]

control: tag -1 +pending

Hello Simon,

On Sun 30 Dec 2018 at 03:52PM +00, Simon McVittie wrote:

> Maybe "via D-Bus and " or "via D-Bus and sd-login(3)"?

I've committed the latter.

> If a logind provider such as elogind doesn't result in the libsystemd
> sd-login APIs working (at least as well as they would with the provided
> logind version), would you consider that to be a bug in the provider?
> I asked this earlier in the bug and didn't notice an answer (my apologies
> if there has been one that I missed).
>
> I ask because libsystemd users like dbus and policykit-1 cannot be linked
> to both libsystemd and libelogind without compiling the daemon twice and
> somehow arranging to run the right one for the installed system, which
> I think is an undesirable level of complexity; for Debian, we should be
> preferring the library that matches our default installation, which is
> libsystemd. Derivatives like Devuan that don't have libsystemd at all
> are of course free to link their libsystemd users to libelogind instead.

We don't seem to have a consensus on this question yet.  I don't
properly understand the issue, but it doesn't seem like it needs to
block adding the virtual packages to the list.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922438: uucico hangs when supervised by systemd

[Jörg Sommer]

Package: uucp
Version: 1.07-25
Severity: normal

Hi,

I've found many uucio processes still alive after the call-out to the
server and uux run. They are all sitting in this block in unix/detach.c:

  /* We'll always wind up as a child of process number 1, right?
 Right?  We have to wait for our parent to die before
 reenabling SIGHUP.  */
  while (getppid () != 1)
sleep (1);

I've put my user session under supervision of systemd. Hence, the fork not
ended as child of init (pid = 1), but as child of my `systemd --user`
process, whose pid is not 1. Therefore, it's waiting there forever to
become a child process of pid 1.

I've applied this patch and it fixed the problem:

diff -u /tmp/uucp-1.07-24/unix/detach.c /tmp/uucp-1.07-25/unix/detach.c
--- /tmp/uucp-1.07-24/unix/detach.c 2003-05-29 08:08:48.0 +0200
+++ /tmp/uucp-1.07-25/unix/detach.c 2019-02-15 23:13:33.044217199 +0100
@@ -98,10 +98,8 @@
   if (ipid != 0)
_exit (EXIT_SUCCESS);
 
-  /* We'll always wind up as a child of process number 1, right?
-Right?  We have to wait for our parent to die before
-reenabling SIGHUP.  */
-  while (getppid () != 1)
+  /* We have to wait for our parent to die before reenabling SIGHUP. */
+  while (getppid () == igrp)
sleep (1);
 
   ipid = getpid ();

The assumption that the new parent of an orphaned child becomes the init
process is no longer true control groups (cgroups).

Regards Jörg

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

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

Versions of packages uucp depends on:
ii  bsd-mailx [mailx]   8.1.2-0.20180807cvs-1
ii  cu  1.07-25
ii  libc6   2.28-7
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  mailutils [mailx]   1:3.5-2
ii  netbase 5.6
ii  systemd-cron [cron-daemon]  1.5.14-2

Versions of packages uucp recommends:
ii  exim4  4.92~RC6-1
ii  logrotate  3.14.0-4

uucp suggests no packages.

-- Configuration Files:
/etc/uucp/call [Errno 13] Keine Berechtigung: '/etc/uucp/call'
/etc/uucp/passwd [Errno 13] Keine Berechtigung: '/etc/uucp/passwd'

-- no debconf information

-- 
Ein Mensch sieht ein und das ist wichtig,
nichts ist ganz falsch und nichts ganz richtig.
   (Eugen Roth)


signature.asc
Description: PGP signature

Bug#922207: Wine + AnyRail 6.1 - messing up KDE Desktop

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 minor

This sounds a lot like this upstream bug:
https://bugs.winehq.org/show_bug.cgi?id=23676

It is in a different app and only seen with mesa and ati drivers, not
nvidia.  Which driver do you use?

Does AnyRail allow you to disable 3d rendering?

Best wishes,
Mike

Bug#848579: calibre: Archos Tablet (101b oxygen) not recognised (android 6)

[Nicholas D Steeves]

Control: owner -1 !
Control: tag +1 moreinfo

Hi Florian,

On Wed, Dec 21, 2016 at 06:32:30PM +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2016-12-20 at 19:09 +, Florian Gruel wrote:
> > When I plug the tablet , it appears in nemo and nautilus as a MTP device, it
> > seams to be OK.
> 
> Showing up is one part. Are you able to perform I/O on it ?

I also believe that this bug is probably a libmtp one.  This bug has
been waiting two years for a reply, so I'm thinking about
closing it as invalid when buster is released, if there as not been a
follow-up by that time.  I'm guessing that will be August or
September.

Debian 9 (stretch) shipped with libmtp_1.1.13-1, which is newer than
what existed when you submitted this bug (1.1.12).  Would you please confirm if
I/O can be performed on your Archos Tablet through the file-manager?

In buster we now have 1.1.16-1, and in sid 1.1.16-2.  Testing if your
tablet works with one of these would also be appreciated.


Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#869875: ITP: woeusb

[Matt Taggart]

I was looking at #869875 since I was looking for something like woeusb.
The upstream packaging was able to produce a debian package with some
minor modifications (to follow normal debian process rather than
upstream's package build process and mk-build-deps/gdebi stuff).

I was looking at how it works and discovered in the source that it does
a wget from a github url in order to grab a raw uefi-ntfs image file

  https://github.com/slacka/WoeUSB/blob/master/src/woeusb#L1167

that repository in turn gets it from the uefi-ntfs project

  https://github.com/pbatard/uefi-ntfs

which also depends on EfiFS

  https://github.com/pbatard/efifs

Obviously this is bad for security/Free Software/reliability reasons.

But all of the above appear to be Free Software, so it might be possible
to package them and have that image file available via a binary package
at runtime when woeusb needs it.

Thanks,

-- 
Matt Taggart
tagg...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#841524: Depend or Suggest markdown package for preview to work

[Nicholas D Steeves]

On Fri, Oct 21, 2016 at 01:38:24PM +0300, Tommi Vainikainen wrote:
> Package: elpa-markdown-mode
> Version: 2.1-1
> Severity: normal
> 
> elpa-markdown-mode should either Depend or Suggest markdown package so
> that markdown-preview function would work correctly. If not Depends,
> then it would be also nice to give nice error message about missing
> command instead of preview page in a browser containing "/bin/bash:
> markdown: command not found".
> 

List of supported converters from upstream README.md: markdown |
libtext-multimarkdown-perl | pandoc

Also available in Debian: discount | python3-markdown

Also from the README
  `markdown-command` - the command used to run Markdown (default:
   `markdown`)

Given that markdown-mode is configured upstream to use "bin:markdown",
it seems more reasonable (and easy!) to just Recommends markdown, and
then add a list of alternatives to Suggests.  This way it works out of
the box, and the user can consult Suggests when interpreting the
upstream README.md.

One thing I'm not sure about is if "discount | python3-markdown"
should be included in the list of Suggests...  They both claim to pass
the Markdown 1.0 test suite, and including these alternatives seems
like a good-neighbourly thing to, so I'm leaning towards including
them.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#922437: cacti: Please also filter out Network Discover error message

[Jeremy Bicha]

Source: cacti
Version: 1.2.1+ds1-2

Could you add this to your tests/check-all-pages error filter?

 -e "AUTOM8 \[PID: [0-9]\+\] Network Discover is now running" \

As seen at

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/i386/c/cacti/20190215_215735_89ae3@/log.gz

It was added to the Ubuntu package earlier at
https://launchpad.net/ubuntu/+source/cacti/1.2.1+ds1-1ubuntu1

Thanks,
Jeremy Bicha

Bug#922401: Fix how format on load & save option is taken into account.

[Bastian Germann]

Why do you think the severity is so important that it needs to be
backported? My understanding is that the full text search is buggy but
the IDE can be executed and used generally. It is not a show stopper.
The better thing to do would be asking upstream if they want to do a
minor 3.12.3 release.

Bug#922228: shim: unreproducible build due to embedded ephemeral certificate

[Luca Boccassi]

Control: tags -1 patch

On Wed, 13 Feb 2019 12:53:09 + Luca Boccassi 
wrote:
> Dear Mantainer,
> 
> As requested on debian-efi, opening a bug trying to collate all
> information and rationale with regards to using the Debian key to
sign
> MoK and FB.
> 
> The debian-efi developers and collaborators, as discussed during the
> secure boot sprint [1], would like the things we (Debian) sign to be
> reproducible so anybody can make sure that nobody (including Debian)
> sneaked in any changes.
> Albeit the shim binary gets signed by Microsoft (and not by Debian)
the
> same logic should apply to it: We want to make sure that nothing got
> changed in shim by anybody.
> 
> Although a run of diffoscope would show that the only things changing
> are the ephemeral embedded key (and the host kernel version), this is
a
> manual step that would not be easily accessible to non-tech-savvy
> users. Having reproducibility "just work" by default means that the
CI
> can take care of it, and notice regressions automatically.
> 
> The Debian key, other than for fwupdate, kernel image and GRUB, is
> already used to also sign all the Linux kernel modules, which are
~3.4k
> for linux-image-4.9.0-8-amd64, multiplied by our number of
> architectures and sub-architectures. So, using it for MoK and FB as
> well doesn't seem to add much more exposure, in the grand scheme of
> things.
> 
> The work to make src:shim use the Debian signing infrastructure was
> already done last year by Philipp, and is available on Salsa [2].
> 
> In case it can help to share the workload, I will try to do some work
> later today to cherry-pick those commits and send an MR on Salsa for
> the latest version.
> 
> Thank you for your work on Shim!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> [1] https://etherpad.wikimedia.org/p/debian-secure-boot-2018
> [2] https://salsa.debian.org/pmhahn/shim

Dear Maintainer,

I have opened an MR on Salsa which ports the changes from Philipp and
adds another patch to avoid using uname during the build:

https://salsa.debian.org/vorlon/shim/merge_requests/1

I have tested this on sid-amd64 and it seems to work as intended.

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#922349: eatmydata: ld.so “secure-execution mode” considerations?

[Thorsten Glaser]

Hi,

>at first sight I'm not a huge fan of that. LD_PRELOAD and setuid stuff is
>always a bit tricky, because abusing setuid files (and libraries here) might
>mean privilege escalation. At lot of attacks in the past just abused setuid
>binaries to do bad stuff in order to gain root privilege.

that’s unfortunately true.

>I'm unsure if and how it can be used with eatmydata, but considering the

Not sure, I’d think not?

>Maybe Aurelien and Florian (on team@ but CC:ed just in case) have some input
>on this too? It might be worth asking opinions on oss-sec as well.

OK. Can you do the oss-sec part, I don’t know about it.


That means we’re not setting precedent here with eatmydata. Then let
me please immediately add another preloadable library (not yet finished)
to the question scope. (Sorry Mattia.)

The other library (codename xunihex) is LD_PRELOADable in order to
implement an X11 IME (input method) using the same-process method.
Well, really only part of it… in fact, all it does is extend the
“default” IME (the one handling things like the Compose key with
user-configurable sequences) by Ctrl-Shift-u… handling like found
in the UIM IME (used by Gtk+ applications). It does this by wrapping
functions like _XimLocalFilter that are part of the standard XFree86
IME implementation used by X.org, using RTLD_NEXT.

That means that, yes, it catches keystrokes, but, again, it only
applies when manually invoked (by adding to LD_PRELOAD), and to
catch X11 keystrokes, easier methods like XGrabKey or the record
extension exist.

Perhaps, if it’s best to consider these LD_PRELOADable libraries
that could benefit from the glibc suid bit case-by-case, this can
be “preapproved”?

Thanks in advance,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#922426: RM: freeplayer -- ROM; Affected by Qt4 Removal; Upstream Dead

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

As requested by the package maintainer [1], please remove package freeplayer
from Debian Archive. This package has a dead upstream as is unlikely to
migrate to Qt5 in the foreseeable future.

--
Regards,
Boyuan Yang

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874882;msg=26


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

Bug#862073: [rb-general] Uploading buildinfo files to buildinfo.debian.net

[Vagrant Cascadian]

On 2019-02-15, Holger Levsen wrote:
> I've just been re-reading this old and joyful thread... :)

I come back to it now and then myself... :)


> On Thu, Oct 25, 2018 at 12:56:20PM -0700, Vagrant Cascadian wrote:
>> I started the process of uploading all the .buildinfo files available on
>> ftp.debian.org to buildinfo.debian.net.
>> 
>> Then I hope to set up a cron job to do uploads at least daily with a
>> little better error-handling Would be more ideal to have something
>> more formally integrated into infrastructure, but maybe I can work out a
>> proof-of-concept implementation as a basis for something that can be
>> integrated.
>
> did you manage to setup this cron job?

I had thought I left more detail about the current status, but
apparently not! Thanks for the nudge.

I have a cron job running on coccia.debian.org since November, as my own
"vagrant" user:

  coccia.debian.org:~vagrant/rb-buildinfos/upload-buildinfos

Logs for various upload passes in are the same directory, which should
probably be migrated to sqlite or some real database. The script is
checked into it's own git repository, but not properly pushed
anywhere.

The cron job runs several times per day, checking the queues for
buildinfos uploaded both the current day yesterday to make sure we don't
miss a .buildinfo file uploaded in the middle of a processing run. If
coccia were down for longer than 24 hours, it might need to manually be
run to check for missing ones.

The vast majority of buildinfo files uploaded to the archive should be
present in buildinfo.debian.net since November 2018. I also "manually"
uploaded all the available buildinfo files from 2017-2018 (most of the
very small number from 2016 failed for one reason or another).

There are a small number of buildinfo uploads that buildinfo.debian.net
rejects for some reason probably related to ed25519 signing keys:

  https://github.com/lamby/buildinfo.debian.net/issues/51

There are a few individual developers uploading unsigned .buildinfo
files, as well as a few buildds for non-release architectures
(e.g. hurd-i386, kfreebsd-*). To hadle those, I actually had a
legitimate use for the technique described in:

  https://xkcd.com/1181/

Which basically means I don't even bother attempting to upload unsigned
buildinfo files.


So, it's working, but we probably would need a little more work on it to
integrate into debian's infrastructure.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922436: sqitch: Can't locate IO/Pager.pm in @INC (you may need to install the IO::Pager module)

[Tommi Vainikainen]

Package: sqitch
Version: 0.-1
Severity: important

Tried to run 'sqitch log' and I got

Can't locate IO/Pager.pm in @INC (you may need to install the IO::Pager module) 
(@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 
/usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 522) 
line 1,  line 1.
BEGIN failed--compilation aborted at (eval 522) line 1,  line 1.

Installing libio-pager-perl fixes. That dependency was removed in
https://salsa.debian.org/perl-team/modules/packages/sqitch/commit/97fb25a47677c3e1712f58b3c52c48fd1a7dcd23
 ?



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

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

Versions of packages sqitch depends on:
ii  libclone-perl  0.38-2+b1
ii  libconfig-gitlike-perl 1.16-1
ii  libdatetime-perl   2:1.42-1
ii  libdatetime-timezone-perl  1:2.09-1+2018g
ii  libdbd-pg-perl 3.5.3-1+b2
ii  libdbi-perl1.636-1+b1
ii  libdevel-stacktrace-perl   2.0200-1
ii  libencode-locale-perl  1.05-1
ii  libfile-homedir-perl   1.00-1
ii  libhash-merge-perl 0.300-1
ii  libintl-perl   1.26-2
ii  libipc-run3-perl   0.048-1
ii  libipc-system-simple-perl  1.25-3
ii  liblist-moreutils-perl 0.416-1+b1
ii  libmoo-perl2.002005-1
ii  libnamespace-autoclean-perl0.28-1
ii  libpath-class-perl 0.37-1
ii  libperlio-utf8-strict-perl 0.006-1+b2
ii  libstring-formatter-perl   0.102084-1
ii  libstring-shellquote-perl  1.03-1.2
ii  libsub-exporter-perl   0.986-1
ii  libtemplate-tiny-perl  1.12-1
ii  libthrowable-perl  0.200013-1
ii  libtry-tiny-perl   0.28-1
ii  libtype-tiny-perl  1.05-1
ii  liburi-db-perl 0.19-1
ii  liburi-perl1.71-1
ii  perl   5.24.1-3+deb9u5
ii  postgresql-client-11 [postgresql-client]   11.1-2
ii  postgresql-client-9.6 [postgresql-client]  9.6.10-0+deb9u1
ii  sqlite33.16.2-5+deb9u1

Versions of packages sqitch recommends:
ii  libclass-xsaccessor-perl  1.19-2+b7
ii  libtemplate-perl  2.24-1.2+b3
ii  libtype-tiny-xs-perl  0.012-1+b2

sqitch suggests no packages.

-- no debconf information

Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

[Mykola Nikishov]

Package: webext-lightbeam
Followup-For: Bug #904933

Control: severity -1 important
Control: tags -1 patch

It does have a major effect on the usability of a package by
preventing user from installing it in the first place (i.e., Raspberry
Pi with a limited free space on an SD card).

There is also a fix [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904933#15

-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages webext-lightbeam depends on:
pn  texlive-fonts-extra  

Versions of packages webext-lightbeam recommends:
ii  firefox  65.0.1-1
ii  firefox-esr  60.5.1esr-1~deb9u1

webext-lightbeam suggests no packages.

Bug#922435: chameleon-cursor-theme: Wrong link in package description

[Thomas Vincent]

Package: chameleon-cursor-theme
Severity: minor

Dear Maintainer,

I noticed that the "Preview" link in the long description of 
chamaleon-cursor-theme does not work.
Indeed, I believe it should be 
https://www.gnome-look.org/content/show.php?content=38459 instead of the 
current http://www.kde-look.org/content/show.php?content=38459 .

Thanks for maintaining chameleon-cursor-themes!

Cheers,
Thomas


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

Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#862073: [rb-general] Uploading buildinfo files to buildinfo.debian.net

[Holger Levsen]

Hi Vagrant,

I've just been re-reading this old and joyful thread... :)

On Thu, Oct 25, 2018 at 12:56:20PM -0700, Vagrant Cascadian wrote:
> I started the process of uploading all the .buildinfo files available on
> ftp.debian.org to buildinfo.debian.net.
> 
> Then I hope to set up a cron job to do uploads at least daily with a
> little better error-handling Would be more ideal to have something
> more formally integrated into infrastructure, but maybe I can work out a
> proof-of-concept implementation as a basis for something that can be
> integrated.

did you manage to setup this cron job?


-- 
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#921680: ufw cannot determine iptables version, fails

[Jamie Strandboge]

On Thu, 07 Feb 2019, PanaColina wrote:

> Package: ufw
> Version: 0.36-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> On clean new install of ufw, any ufw command
> (eg: "ufw status") results in:
> "ERROR: Couldn't determine iptables version"
> 
> Additional packages automatically installed at the same time:
>  iptables 1.8.2-3
>  libnftables0 0.9.0-2
>  libnftnl11 1.1.2-2
>  nftables 0.9.0-2
> 
> Assuming some conflict, I removed nftables and libnftables0, but error
> persists.
> 
> ufw is set as dependent on libnftnl11, and of course iptables
> 

I cannot reproduce this with the current 4.19 kernel or on an older 4.17 kernel
(like you have-- you may want to consider upgrading).

$ dpkg -l|grep -E '(ufw|iptables|nft)'|awk '{print $1, $2, $3}'
ii iptables 1.8.2-3
ii libnftables0:amd64 0.9.0-2
ii libnftnl11:amd64 1.1.2-2
ii libnftnl7:amd64 1.1.1-1
ii nftables 0.9.0-2
ii ufw 0.36-1

$ /sbin/iptables --version
iptables v1.8.2 (nf_tables)

$ sudo ufw status
Status: inactive

$ sudo ufw enable
Firewall is active and enabled on system startup

$ sudo ufw status
Status: active

To Action  From
-- --  
22/tcp ALLOW   Anywhere
22/tcp (v6)ALLOW   Anywhere (v6)


It continues to work with iptables-legacy (using update-alternatives; I updated
the alternative, ran ufw disable and rebooted):

$ /sbin/iptables --version
iptables v1.8.2 (legacy)

$ sudo ufw status
Status: inactive

$ sudo ufw enable
Firewall is active and enabled on system startup

$ sudo ufw status
Status: active

To Action  From
-- --  
22/tcp ALLOW   Anywhere
22/tcp (v6)ALLOW   Anywhere (v6)


What is the output of 'sudo /usr/share/ufw/check-requirements'?

What is the output of '/sbin/iptables --version'?


> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.17.17 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages ufw depends on:
> ii  debconf [debconf-2.0]  1.5.70
> ii  iptables   1.8.2-3
> ii  lsb-base   10.2018112800 
> ii  python33.7.2-1
> ii  ucf3.0038+nmu1
> 
> ufw recommends no packages.
> 
> Versions of packages ufw suggests:
> ii  rsyslog  8.40.0-1+b1
> 
> -- debconf information:
>   ufw/existing_configuration:
>   ufw/allow_known_ports:
>   ufw/enable: false
>   ufw/allow_custom_ports:
-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Sean Whitton]

Hello,

On Thu 14 Feb 2019 at 08:45PM +01, Christian Kastner wrote:

> On 2012-08-21 14:34:50 +0200 Andreas Tille  wrote:> I
> would propose the following addition to
>>
>>   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>>
>> --- 8< -
>> Files-Excluded
>> --
>>
>> Whitespace-separated list: list of patterns indicating files removed
>> from upstream source.
> It appears as if Files-Excluded in d/changelog has become a de facto
> standard in the meantime, so I'd like to ping the Policy Team and ask
> whether/when we can expect an official blessing of this standard :-)
>
> I've been updating my crufty packages and lintian has repeatedly
> reported debian-rules-contains-unnecessary-get-orig-source-target. Most
> of my targets were indeed simple calls to uscan, but I used to maintain
> a dedicated d/files-excluded file (which I'd pass on with the
> --copyright-file option) just for the Files-Excluded data.
>
> I moved everything to d/copyright now, but having this sanctioned
> officially would be welcomed by us pedants.

Contrary to an older e-mail in this bug, the consensus among the Policy
Editors is that we can add new, optional fields to the copyright-format
spec without bumping its version number.  This is because the addition
of optional fields is backwards compatible.

I have not read the whole thread, but a quick scan suggests that all we
are waiting for here is for someone to write a patch against current
Policy's master branch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922434: sass-elisp: Should depend on generic emacs

[Mykola Nikishov]

Package: sass-elisp
Severity: important

I have emacs-lucid installed and it provides both emacs and emacsen
which should be enough for sass-elisp but it wants a versioned emacs
package.

Instead, it would be better to depend on unversioned emacs or virtual
emacsen package (not sure which one is better).

Severity is important as it has a major effect on the usability of a
package by preventing user from installing it in the first place,
however, without rendering it completely unusable to everyone.

--8<---cut here---start->8---
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Building tag database...
The following NEW packages will be installed:
  emacs-gtk{ab} [1:26.1+1-3.2]  emacs23{a} [1:26.1+1-3.2]  haml-elisp{a} 
[1:3.1.0-3.1]  sass-elisp [3.0.15-4.1]  
The following packages are RECOMMENDED but will NOT be installed:
  ruby-haml  ruby-sass  
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,619 kB of archives. After unpacking 43.0 MB will be used.
The following packages have unmet dependencies:
 emacs-lucid : Conflicts: emacs-gtk but 1:26.1+1-3.2 is to be installed
 emacs-gtk : Conflicts: emacs-lucid but 1:26.1+1-3.2 is installed
The following actions will resolve these dependencies:

 Remove the following packages:   
1) emacs-lucid [1:26.1+1-3.2 (now, testing, unstable)]



Accept this solution? [Y/n/q/?] Abort.
--8<---cut here---end--->8---


-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages sass-elisp depends on:
pn  emacs23 | emacs24
pn  emacs25 | emacs24 | emacs23  
ii  emacsen-common   3.0.4
pn  haml-elisp   

Versions of packages sass-elisp recommends:
pn  ruby-sass  

sass-elisp suggests no packages.

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important
 
Feb 15 14:21:09 lxc009 kernel: INFO: task rsync:1762 blocked for more than 120 
seconds.
Feb 15 14:21:09 lxc009 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 Debian 
4.19.16-1~bpo9+1
Feb 15 14:21:09 lxc009 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 15 14:21:09 lxc009 kernel: rsync   D0  1762   1761 0x0100
Feb 15 14:21:09 lxc009 kernel: Call Trace:
Feb 15 14:21:09 lxc009 kernel:  ? __schedule+0x3f5/0x880
Feb 15 14:21:09 lxc009 kernel:  schedule+0x32/0x80
Feb 15 14:21:09 lxc009 kernel:  rwsem_down_write_failed+0x216/0x3e0
Feb 15 14:21:09 lxc009 kernel:  ? call_rwsem_down_write_failed+0x13/0x20
Feb 15 14:21:09 lxc009 kernel:  call_rwsem_down_write_failed+0x13/0x20
Feb 15 14:21:09 lxc009 kernel:  down_write+0x29/0x40
Feb 15 14:21:09 lxc009 kernel:  btrfs_file_llseek+0x45/0x2c0 [btrfs]
Feb 15 14:21:09 lxc009 kernel:  ? syscall_trace_enter+0x117/0x2c0
Feb 15 14:21:09 lxc009 kernel:  ksys_lseek+0x80/0xa0
Feb 15 14:21:09 lxc009 kernel:  do_syscall_64+0x55/0x110
Feb 15 14:21:09 lxc009 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 15 14:21:09 lxc009 kernel: RIP: 0033:0x7fdf52e99af7
Feb 15 14:21:09 lxc009 kernel: Code: Bad RIP value.
Feb 15 14:21:09 lxc009 kernel: RSP: 002b:7ffd039de2e8 EFLAGS: 0246 
ORIG_RAX: 0008
Feb 15 14:21:09 lxc009 kernel: RAX: ffda RBX: 558f0c8dca90 RCX: 
7fdf52e99af7
Feb 15 14:21:09 lxc009 kernel: RDX:  RSI: 001e012c RDI: 
0001
Feb 15 14:21:09 lxc009 kernel: RBP: 0004 R08: 001e0130 R09: 
0004
Feb 15 14:21:09 lxc009 kernel: R10: 000f0096 R11: 0246 R12: 

Feb 15 14:21:09 lxc009 kernel: R13: 001e012c R14:  R15: 
001e012c

Bug#921022: Info received (firefox-esr: Update to version 60.5.0esr-1~deb9u1 breaks netflix DRM installation, downgrade to 60.4.0esr-1~deb9u1 fixes it)

[Eric Dégenètais]

Version 60.5.1esr-1~deb9u1 is apparently not affected when it comes to 
Netflix DRM modules.

Bug#922433: nasm: CVE-2019-8343: Use after free in paste_tokens

[Salvatore Bonaccorso]

Source: nasm
Version: 2.14-1
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.nasm.us/show_bug.cgi?id=3392556

Hi,

The following vulnerability was published for nasm.

CVE-2019-8343[0]:
| In Netwide Assembler (NASM) 2.14.02, there is a use-after-free in
| paste_tokens in asm/preproc.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-8343
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8343
[1] https://bugzilla.nasm.us/show_bug.cgi?id=3392556

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[gregor herrmann]

On Fri, 15 Feb 2019 18:29:14 +0100, Xavier wrote:

> > For the skippable part:
> > - If I understand this correctly (from your text above and the spec
> >   [1]) then a skipped syntax.t and use.t would also lead to losing
> >   the benefit of faster migration? Do we want this?
> The benefit will be lost only if smoke test is skipped. I think it's a
> good thing (other tests are "superficial" <=> no benefit). Today if this
> test is skipped, it is considered by autopkgtest as "success"

Ah, I see. Ok, a lost benefit only for the skipped smoke tests
probably makes sense.
 
> > - As for the implementation in [0]:
> >   not sure if the "exit 0" in smoke is correct

This still confuses me.
Shouldn't it "exit $?" or just nothing (line 174)?

> > - What about the skipped tests within use.t and syntax.t? Should they
> >   or some of them also exit 77?
> runner do it for them. 

Well, only partially. First of all, runners can run more than one
test in a subdirectory (even if we currently only have 3 files in 4
subdirectories, with 3 times 1 and 1 time zero), second, there are
several places in syntax.t and use.t were all or parts of the tests
are skipped. -- But:

> I didn't modify them if all is skipped as it has
> no effect on a test marked as "superficial": 0 or 77 gives the same
> result: no benefit, no penalty

… this "no benefit, no penalty" makes it indeed kind of moot :)
 
> > In general I still don't have the full picture of what benefits and
> > penalties for testing migration will result from which combination of
> > the changes under which circumstances.
> 
> The only effect of this is that if smoke test is skipped, there is no
> benefit. And I think it's more clear to have the real result:
> 
> # EXAMPLE 1, SKIP use.t => benefit OK
> autopkgtest [18:23:17]:  summary
> command1: PASS
> command2: FAIL exit 77 (marked as skippable) # I don't remember the
>  # exact message
> command3: PASS (superficial)
> 
> # EXAMPLE 2, SKIP smoke => no benefit
> command1: FAIL exit 77 (marked as skippable)
> command2: PASS (superficial)
> command3: PASS (superficial)
> 
> # EXAMPLE 3, real failure in smoke => penalty
> command1: FAIL
> command2: PASS (superficial)
> command3: PASS (superficial)
> 
> # EXAMPLE 4, real failure in use.t => penalty
> command1: PASS
> command2: FAIL
> command3: PASS (superficial)

Thanks alot for those examples, they make it indeed easier for me to
understand the effects!

So, hm, yeah, I guess that all makes sense …


I hope someone else also has some minutes to think it through :)


(Random note, so we don't forget it: There are a few adjusted copies
of the autodep8 file in various packages as debian/tests/control
which should also be adjusted, at least in git for the next upload.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Josh With: Milk cow blues


signature.asc
Description: Digital Signature

Bug#922432: httping: Selecting a port number doesn't work

[Nelson A. de Oliveira]

Package: httping
Version: 2.5-5
Severity: normal

Hi!

httping's manual says:

=
   -p portnumber
  -p can be used together with -h. -p selects  the  portnumber  to
  probe.
=

But it doesn't seem to be working:

=
$ httping -p 443 josm.openstreetmap.de
PING josm.openstreetmap.de:80 (/):
connected to 95.216.72.248:80 (253 bytes), seq=0 time=522,23 ms
=

See that it's still using port 80

"httping --help" also says:

=
-p x / --portportnumber (e.g. 80) - use with -h
=

But testing with -h I don't see any difference:

=
$ httping -p 443 -h josm.openstreetmap.de
PING josm.openstreetmap.de:80 (/):
connected to 95.216.72.248:80 (253 bytes), seq=0 time=533,90 ms
=

So either I did completely misunderstand the portnumber option or it's
really not working as expected.

Thank you!

Best regards,
Nelson

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

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

Versions of packages httping depends on:
ii  libc6 2.28-6
ii  libfftw3-double3  3.3.8-2
ii  libncursesw6  6.1+20181013-1
ii  libssl1.1 1.1.1a-1
ii  libtinfo6 6.1+20181013-1
ii  openssl   1.1.1a-1

httping recommends no packages.

httping suggests no packages.

-- no debconf information

Bug#922431: chromium: URL chrome://tracing does not work any more

[Sebastien Helleu]

Package: chromium
Version: 72.0.3626.81-1
Severity: normal

Dear Maintainer,

With chromium version 72.0.3626.81, the URL chrome://tracing does not work any 
more.
It displays this error:

-
This site can’t be reached The webpage at chrome://tracing/ might be 
temporarily down or it may have moved permanently to a new web address.

ERR_INVALID_URL
-

The extension Lighthouse, depending on this tracing feature does not work any 
more.
The error is: "Protocol error (Tracing.start): 'Tracing.start' wasn't found".

It is a regression, it was OK with chromium version 72.0.3626.53.

I reported the bug in Chromium bug tracker, but they answered it might be an 
issue
with Debian packaging (since the same version works fine on Ubuntu).

The chromium bug is: 
https://bugs.chromium.org/p/chromium/issues/detail?id=931143

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)

Versions of packages chromium depends on:
ii  chromium-common  72.0.3626.81-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-4
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.2.0-20
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.1-1
ii  libavformat587:4.1.1-1
ii  libavutil56  7:4.1.1-1
ii  libc62.28-7
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libcups2 2.2.10-3
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-20
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libopenjp2-7 2.3.0-1.1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-5
ii  libpulse012.2-4
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.2.0-20
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  72.0.3626.81-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 72.0.3626.81-1
ii  dunst [notification-daemon]  1.3.2-1
ii  fonts-liberation 1:1.07.4-9
ii  libgl1-mesa-dri  18.3.3-1
pn  libu2f-udev  
pn  upower   

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.2.0-20
ii  libc6   2.28-7
ii  libgcc1 1:8.2.0-20
ii  libstdc++6  8.2.0-20

-- no debconf information

Bug#922416: cache.commit() doesn't release the archives lock

[Julian Andres Klode]

On Fri, Feb 15, 2019 at 05:00:58PM +, Marga Manterola wrote:
> Package: python-apt
> Version: 1.8.3
> 
> Hi!
> 
> I have tools that use python-apt to interact with the system. Until
> recently I was using an old version of python-apt (1.4.0~beta3) and it was
> working fine.  I'm now migrating to the latest version (1.8.3) and I've
> encountered a problem with it.
> 
> When testing this version, I found a problem that seems to be related to
> the changes in locking.  The code that's failing is using the cache,
> calling cache.commit and after that's done, calling another command via
> subprocess that also interacts with apt.  The problem that I'm encountering
> is that this other command can't acquire the archives lock.
> 
> Following the code, I've realized that while the commit() function acquires
> a lock [1] (by calling get_lock on the Acquire object), it never actually
> releases this lock.
> 
> From my understanding of the C++ code, the lock is released when the object
> is garbage collected [2] and calling shutdown (which is what the commit()
> code does) is not enough.

This is correct. But the fetcher should be collected at the end of the
SystemLock block, as it goes out of scope and thus ref count drops to 0, so
it's odd that it does not work for you.


> 
> The cache.update() function code is quite different in this regard.  It
> obtains and releases the code explicitly, instead of relying on the Acquire
> object [3]. I don't know if there's a reason behind these two different
> locking behaviors, but it seems to me that the commit one is wrong and it
> would be better to make it acquire and release the lock locally instead of
> relying on the Acquire object being garbage collected

So, this was a bug fix:

https://salsa.debian.org/apt-team/python-apt/commit/618a8e47e6ec74b21ab952da6e85ae327f87cbf7>
 

There might be a solution with explicit locking that also takes care of
keepig the lock open as long as needed. I guess we could do explicit locking
in both fetch_archives and commit().


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#921386: ITP: embree -- High Performance Ray Tracing Kernels

[Matteo F. Vescovi]

On 2019-02-04 at 23:04 (+01), Matteo F. Vescovi wrote:
> * Package name: embree
>   Version : 3.4.0
>   Upstream Author : Intel Corporation
> * URL : http://embree.github.io/
> * License : Apache-2.0
>   Programming Lang: C++ mostly
>   Description : High Performance Ray Tracing Kernels

[...]

FTR, Intel has released 3.5.0 version meanwhile and I've updated the
packaging accordingly.

Cheers.


-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#892929: Still bad packaging still broken

[PICCORO McKAY Lenz]

issue was fixed.. but a special note:

issue was reported at 3.9.2 but in that time when i use gambas oficial
debian package with sid, issue was reproducible, later use the own made
with correct depends issue was gone with 3.9.2

that's why i cited the previous mail that currently the official packaging
guidelines at http://gambaswiki.org/wiki/howto/package are being updated
according to the creator himself... and we should collaborate with the
upstream project to define this well and thus save efforts...

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


El vie., 15 de feb. de 2019 a la(s) 14:34, Bastian Germann (
bastiangerm...@fishpost.de) escribió:

> Piccoro, you explained at a later state that the issue was solved
> upstream, so I guessed for the current gambas3 testing version this
> issue should be fixed. You did not explain anything for the testing
> version.
>
> So if you still experience the described issue for your testing install,
> I am willing to work on this. But I cannot reproduce the issue using the
> testing gambas3-ide package. I am going to close this as fixed if nobody
> is confirming the issue for the testing version.
>
> A note here: Installing the PPA version and then, without uninstalling
> it, installing gambas3-ide is not supported. (Piccoro mentioned this
> approach in another issue)
>

Bug#922430: lft: Segmentation fault when using nonexistent interface

[Nelson A. de Oliveira]

Package: lft
Version: 3.8-2
Severity: important

Hi!

lft segfaults when defining a nonexistent network interface.
For example, I wrongly used "-D" instead "-d" here:

lft -D 443 josm.openstreetmap.de

gdb's thread apply all bt full output is attached.

Thank you!

Best regards,
Nelson

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

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

Versions of packages lft depends on:
ii  libc6   2.28-6
ii  libpcap0.8  1.8.1-6

lft recommends no packages.

lft suggests no packages.

-- no debconf information
Starting program: /usr/sbin/lft -D 443 josm.openstreetmap.de

Program received signal SIGSEGV, Segmentation fault.
__strnlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:117
117 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.

Thread 1 (process 13787):
#0  __strnlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:117
No locals.
#1  0x77c1a7ee in __strncpy_sse2 (s1=0x7fffe230 
"\310\342\377\377\377\177", s2=0x0, n=15)
at ../string/strncpy.c:29
size = 
#2  0x6dcb in strncpy (__len=15, __src=0x0, 
__dest=0x7fffe230 "\310\342\377\377\377\177")
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106
No locals.
#3  lft_getifaddr (ifname=ifname@entry=0x0) at lft_ifname.c:52
ifr = {ifr_ifrn = {ifrn_name = 
"\310\342\377\377\377\177\000\000\273\347\377\377\377\177\000"}, 
  ifr_ifru = {ifru_addr = {sa_family = 80, 
  sa_data = 
"\000\000\000\000\000\000\310\342\377\377\377\177\000"}, ifru_dstaddr = {
  sa_family = 80, sa_data = 
"\000\000\000\000\000\000\310\342\377\377\377\177\000"}, 
ifru_broadaddr = {sa_family = 80, 
  sa_data = 
"\000\000\000\000\000\000\310\342\377\377\377\177\000"}, ifru_netmask = {
  sa_family = 80, sa_data = 
"\000\000\000\000\000\000\310\342\377\377\377\177\000"}, 
ifru_hwaddr = {sa_family = 80, 
  sa_data = 
"\000\000\000\000\000\000\310\342\377\377\377\177\000"}, ifru_flags = 80, 
ifru_ivalue = 80, ifru_mtu = 80, ifru_map = {mem_start = 80, 
mem_end = 140737488347848, 
  base_addr = 0, irq = 0 '\000', dma = 0 '\000', port = 0 '\000'}, 
ifru_slave = 
"P\000\000\000\000\000\000\000\310\342\377\377\377\177\000", 
ifru_newname = 
"P\000\000\000\000\000\000\000\310\342\377\377\377\177\000", 
ifru_data = 0x50 }}
addr = 
#4  0xe66f in LFTExecute (sess=0x55572670) at lft_lib.c:3963
addr = {s_addr = 3137404928}
ebuf = 
"\037\000\000\000\000\000\000\000P\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\003\000\000\000\060",
 '\000' , 
"[\000\000\000w\000\000\000\220\002\000\000\000\000\000\000\370E\274\367\377\177\000\000\a\000\000\000\000\000\000\000\000\220\324\367\377\177\000\000\004\000\000\000\000\000\000\000\070\345\377\377\377\177\000\000\001\000\000\000\000\000\000\000\305\320\364\200\000\000\000\000\260\234VUUU\000\000\303\265\306\367\377\177\000\000*\000\000\000:",
 '\000' , 
"\\\000\000\000D\000\000\000\265\347\377\377\377\177\000\000\266\347\377\377\377\177\000\000\000\000\000\000\000\000\000\000"...
#5  0x69c7 in main (argc=4, argv=0x7fffe538) at lft.c:375
sess = 0x55572670
ch = 
cp = 
tb = {tv_sec = 1550258905, tv_usec = 593777}

Bug#922429: RM: mpqc-openmpi [all] -- RoQA; cruft binary

[Adam D. Barratt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

The upload of mpqc 2.3.1-19 stopped building the mpqc-openmpi binary
package. Please remove it from the archive.

Regards,

Adam

Bug#858382: the documentations does not work unless we install all the gamba packages

[PICCORO McKAY Lenz]

> So, my question rephrased: When you install the current testing
> gambas3-ide package (currently version 3.12.2-1), does downloading the
> offline documentation work without installing any additional packages?
> If not, which packages do you need to install on top?
>
I think it's better to work alongside with the upstream project...
currently the official packaging guidelines at
http://gambaswiki.org/wiki/howto/package are being updated according to the
creator himself... I think we should collaborate with the upstream project
to define this well and thus save efforts... because knowing well which
package is needed requires time and in each change of the original project
this will also changes! you can follow at
http://gambaswiki.org/bugtracker/edit?object=BUG.1531

i cannot test directly due i use jessie but when use the debian package
does not work ..
then i packaged my own follow the upstream rules
http://gambaswiki.org/wiki/howto/package and currently works!but got new
problems due Debian dependences are more refined!

El vie., 15 de feb. de 2019 a la(s) 14:14, Bastian Germann (
bastiangerm...@fishpost.de) escribió:

> Installing gambas3 from PPA and then Debian packages is not a common use
> case. If you do so, you are on your own and cannot expect support.
> Please try to stick to the issue's topic.
>
was a example! and a direct consecuence to not follow upstream rules to
package!

Bug#921751: python-rdflib-tools: CVE-2019-7653: Code injection from current working directory working directory

[Andreas Tille]

On Fri, Feb 15, 2019 at 04:04:31PM +0100, chrysn wrote:
> 
> > I used to be member of the DPMT group back on Alioth[2], can you add me on
> > salsa? Then I can make the package ready for sponsor-upload-from-git
> > once moved.
> 
> I've incorporated the changes from the move and an update to
> standards-version, and set the changelog to indicate release readiness.
> Would you sponsor the latest version (81346975) of [1] to close this
> issue?

I have uploaded with an additional change to set DPMT as Maintainer
and you as Uploader since this is policy if you are maintaining in
this repository tree.

Thanks for working on this

   Andreas.

> [1]: https://salsa.debian.org/python-team/modules/rdflib

-- 
http://fam-tille.de

Bug#922428: "free(): invalid pointer", SIGABRT

[Jim Paris]

Package: golang-docker-credential-helpers
Version: 0.6.1-1
Severity: normal
Tags: upstream patch

See
  https://github.com/docker/docker-credential-helpers/issues/104

This was fixed upstream post-0.6.1:
  
https://github.com/docker/docker-credential-helpers/commit/73e5f5dbfea31ee3b8ebbf189785fa69731c

The symptom is that I get the following error:

$ docker-credential-secretservice list
free(): invalid pointer
SIGABRT: abort
PC=0x7f2b60cf285b m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x7f2b60cf285b
stack: frame={sp:0x7fff1248b2e0, fp:0x0} stack=[0x7fff11c8c708,0x7fff1248b730)
7fff1248b1e0:  7fff1248b658  00cfe8c0
7fff1248b1f0:  7fff1248b658  00cfceb0
7fff1248b200:  7f2b617eeb2c  7f2b614d140a
7fff1248b210:  7f2b617eeb2c  00565080
7fff1248b220:  00c4200ae020  00c4200ae018
7fff1248b230:    7fff1248b658
7fff1248b240:  0200  7f2b61a41b33
7fff1248b250:  0005  
7fff1248b260:    7f2b60eb05f0
7fff1248b270:  7fff1248b600  7f2b61a484ca
7fff1248b280:    
7fff1248b290:  0002  0050
7fff1248b2a0:    7f2b617ccbb5
7fff1248b2b0:  00cfc800  726f273d30677261
7fff1248b2c0:  306772612c277375  72662e67726f273d
7fff1248b2d0:  6f746b7365646565  00021fa0
7fff1248b2e0: <  0088
7fff1248b2f0:  00c420018090  000d
7fff1248b300:  00c42001a050  004f
7fff1248b310:  00c420016200  0011
7fff1248b320:  00c42001c030  002a
7fff1248b330:    00451f91 
7fff1248b340:    
7fff1248b350:    
7fff1248b360:  fffe7fff  
7fff1248b370:    
7fff1248b380:    
7fff1248b390:    
7fff1248b3a0:    
7fff1248b3b0:    
7fff1248b3c0:    
7fff1248b3d0:    
runtime: unknown pc 0x7f2b60cf285b
stack: frame={sp:0x7fff1248b2e0, fp:0x0} stack=[0x7fff11c8c708,0x7fff1248b730)
7fff1248b1e0:  7fff1248b658  00cfe8c0
7fff1248b1f0:  7fff1248b658  00cfceb0
7fff1248b200:  7f2b617eeb2c  7f2b614d140a
7fff1248b210:  7f2b617eeb2c  00565080
7fff1248b220:  00c4200ae020  00c4200ae018
7fff1248b230:    7fff1248b658
7fff1248b240:  0200  7f2b61a41b33
7fff1248b250:  0005  
7fff1248b260:    7f2b60eb05f0
7fff1248b270:  7fff1248b600  7f2b61a484ca
7fff1248b280:    
7fff1248b290:  0002  0050
7fff1248b2a0:    7f2b617ccbb5
7fff1248b2b0:  00cfc800  726f273d30677261
7fff1248b2c0:  306772612c277375  72662e67726f273d
7fff1248b2d0:  6f746b7365646565  00021fa0
7fff1248b2e0: <  0088
7fff1248b2f0:  00c420018090  000d
7fff1248b300:  00c42001a050  004f
7fff1248b310:  00c420016200  0011
7fff1248b320:  00c42001c030  002a
7fff1248b330:    00451f91 
7fff1248b340:    
7fff1248b350:    
7fff1248b360:  fffe7fff  
7fff1248b370:    
7fff1248b380:    
7fff1248b390:    
7fff1248b3a0:    
7fff1248b3b0:    
7fff1248b3c0:    
7fff1248b3d0:    

goroutine 1 [syscall]:
runtime.cgocall(0x4af750, 0xc420067cf0, 0x428904)
/usr/lib/go-1.10/src/runtime/cgocall.go:128 +0x64 fp=0xc420067cc0 
sp=0xc420067c88 pc=0x403ac4
github.com/docker/docker-credential-helpers/secretservice._Cfunc_free(0xcef090)
_cgo_gotypes.go:111 +0x41 fp=0xc420067cf0 sp=0xc420067cc0 pc=0x4ad731
github.com/docker/docker-credential-helpers/secretservice.Secretservice.List.func5(0xcef090)

/build/golang-github-docker-docker-credential-helpers-0.6.1/obj-x86_64-linux-gnu/src/github.com/docker/docker-credential-helpers/secretservice/secretservice_linux.go:96
 +0x56 fp=0xc420067d28 sp=0xc420067cf0 pc=0x4af166
github.com/docker/docker-credential-helpers/secretservice.Secretservice.List(0x0,
 0x4fcfe0, 0xc4200962e0)

Bug#919831: Javadoc -link makes broken links if module name matches package name

[Markus Koschany]

Hi tony!

Am 15.02.19 um 15:42 schrieb tony mancill:
[...]
> Hi Markus,
> 
> We independently executed identical experiments, which I'm glad for,
> because I would have wanted some external verification before uploading
> any of this to unstable.  (I started building the r-build-deps of
> libplexus-languages-java using ratt, but my laptop isn't the best place
> to build 559 packages and many packages are FTBFS right now anyway due
> to the javadoc problems.)
> 
> I believe the comment in debian/README.source about updating src:maven
> is simply out of date.  I don't see any (obvious) versioned references
> to maven-javadoc-plugin in the current maven source package.

Ok, I have just removed README.source. I think it is a bit confusing.

> So I'm not sure what the next step is, other than continuing to watch
> commits to upstream maven-javadoc-plugin and see if I can figure out why
> 3.1.0~pre0-$foo doesn't work in our environment. 

I find that really strange because I thought the latest Git snapshot
would fix the bug.

> Or now that we're into the freeze, do we want to talk about actions with
> more far-reaching consequences?
> 
> Any thoughts on whether we should focus on fixing javadoc generation or
> look at other ways to mitigate the FTBFS?

Like burning all those -doc packages? :)

In my opinion we could ask Robert Scholte for advice. He is chairman of
Apache Maven and directly involved in fixing this bug. If he doesn't
know

However I think I have found a workaround, and we all love workarounds,
don't we.

In your initial post you pointed to a related bug report. [1] That made
me think and also read the fine Maven Javadoc documentation. There is an
option called detectJavaApiLink

https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#detectJavaApiLink

If I add

detectJavaApiLink=false to debian/maven.properties in libparanamer-java,
the package builds from source again.

Maybe we should patch our tools and set this property to false and move
on for now? Hopefully in a few months this will just work again without
changing this option, when maven-javadoc-plugin et al. have been
catching up?

Cheers,

Markus


[1] https://github.com/oracle/opengrok/issues/2629




signature.asc
Description: OpenPGP digital signature

Bug#922427: linear scale calibration problem

[Joey Hess]

Package: iftop
Version: 1.0~pre4-6
Severity: normal

The way iftop calibrates its linear scale, it seems to often make the
scale much wider than the actual available network bandwidth, leading to
bar graphs that are quite narrow, often 1 character wide or 0 characters
wide, for network connections that are pushing relatively a lot of
traffic. This makes it not very useful to spotting at a glance what is
eating bandwidth.

I generally press L to switch to log scale, which avoids the problem,
showing big wide bars.

For example, I've started iftop when the network is nearly completely
idle. It picked a scale 1KB-8KB, which is fine. Then I started a
download, which ran at 300-615KB/s. This causes the scale to change to
2MB-12MB. Since my wifi connection happens to be limited to around
1MB/s, this guarantees bars will never be more than a few characters
wide.

Here's how that displays after downloading for several minutes:

2.38MB  4.77MB   7.15MB  9.54MB 
11.9MB
└───┴───┴┴───┴
darkstar.kitenet.:51000 => kitenet.net:ssh  849KB  6.87KB  5.68KB  
5.95KB
### <= 57.7MB   478KB   381KB   
410KB
──
TX: cum:   1.10MB   peak:   9.33KBrates:   7.07KB  4.95KB  
6.71KB
RX:72.0MB648KB  466KB   325KB   
457KB
TOTAL: 73.1MB657KB  473KB   330KB   
463KB

("RX:" is highlighted and I've marked the top highlight using "###".)

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE
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 iftop depends on:
ii  libc62.28-6
ii  libncurses6  6.1+20181013-1
ii  libpcap0.8   1.8.1-6
ii  libtinfo66.1+20181013-1

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#915311: dumb-init FTBFS on mips*: test failures

[Shengjing Zhu]

Hi,

I've uploaded this NMU to DELAYED/2-day. Hope it works.

On Thu, Feb 14, 2019 at 1:03 AM Shengjing Zhu  wrote:
>
> diff -Nru dumb-init-1.2.2/debian/changelog dumb-init-1.2.2/debian/changelog
> --- dumb-init-1.2.2/debian/changelog2019-01-27 14:30:06.0 +0800
> +++ dumb-init-1.2.2/debian/changelog2019-02-14 00:50:21.0 +0800
> @@ -1,3 +1,10 @@
> +dumb-init (1.2.2-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Add patch to fix tests on slow machines. (Closes: #915311)
> +
> + -- Shengjing Zhu   Thu, 14 Feb 2019 00:50:21 +0800
> +
>  dumb-init (1.2.2-1) unstable; urgency=medium
>
>[ Ondřej Nový ]
> diff -Nru dumb-init-1.2.2/debian/patches/increase-test-sleep-time.patch 
> dumb-init-1.2.2/debian/patches/increase-test-sleep-time.patch
> --- dumb-init-1.2.2/debian/patches/increase-test-sleep-time.patch   
> 1970-01-01 08:00:00.0 +0800
> +++ dumb-init-1.2.2/debian/patches/increase-test-sleep-time.patch   
> 2019-02-14 00:50:21.0 +0800
> @@ -0,0 +1,18 @@
> +Description: increase test sleep time
> + The test will fail on some slow machines if the sleep time
> + is too short.
> +Author: Shengjing Zhu 
> +Bug-Debian: https://bugs.debian.org/915311
> +Last-Update: 2019-02-14
> +
> +--- dumb-init-1.2.2.orig/tests/child_processes_test.py
>  dumb-init-1.2.2/tests/child_processes_test.py
> +@@ -80,7 +80,7 @@ def spawn_process_which_dies_with_childr
> + # we need to sleep before the shell exits, or dumb-init might 
> send
> + # TERM to print_signals before it has had time to register 
> custom
> + # signal handlers
> +-'{python} -m testing.print_signals & sleep 0.1'.format(
> ++'{python} -m testing.print_signals & sleep 1'.format(
> + python=sys.executable,
> + ),
> + ),
> diff -Nru dumb-init-1.2.2/debian/patches/series 
> dumb-init-1.2.2/debian/patches/series
> --- dumb-init-1.2.2/debian/patches/series   2019-01-27 14:20:28.0 
> +0800
> +++ dumb-init-1.2.2/debian/patches/series   2019-02-14 00:46:35.0 
> +0800
> @@ -1 +1,2 @@
>  build.patch
> +increase-test-sleep-time.patch

-- 
Shengjing Zhu

Bug#892929: Still bad packaging still broken

[Bastian Germann]

Piccoro, you explained at a later state that the issue was solved
upstream, so I guessed for the current gambas3 testing version this
issue should be fixed. You did not explain anything for the testing version.

So if you still experience the described issue for your testing install,
I am willing to work on this. But I cannot reproduce the issue using the
testing gambas3-ide package. I am going to close this as fixed if nobody
is confirming the issue for the testing version.

A note here: Installing the PPA version and then, without uninstalling
it, installing gambas3-ide is not supported. (Piccoro mentioned this
approach in another issue)

Bug#922357: internetarchive: new upstream version available

[Antoine Beaupré]

Control: forwarded -1 https://github.com/jjjake/internetarchive/issues/292

On 2019-02-15 01:02:50, Linda Lapinlampi wrote:
> Package: internetarchive
> Version: 1.8.1-1
> Severity: wishlist
>
> Dear Maintainer,
>
> a new version 1.8.2 (or later) is available from upstream, since
> 2018-07-02. Please consider packaging it to Debian.
>
> Changelog: https://archive.org/services/docs/api/internetarchive/updates.html

Where is that release actually available? It's not on GitHub:

https://github.com/jjjake/internetarchive/releases
https://github.com/jjjake/internetarchive/tags

Nor is it on PyPI:

https://pypi.org/project/internetarchive/#history

I've forwarded the bug upstream.

A.
-- 
VBscript: la simplicité du C, la puissance du BASIC
- Mathieu Petit-Clair

Bug#922179: shim-signed depends on packages not repos

[Cyril Brulebois]

Control: severity -1 serious
Control: affects -1 src:debian-installer

Hi Matthew,

Thanks for filing this bug report.

Matthew Crews  (2019-02-12):
> Package: shim-signed
> Version: 1.28+nmu1+0.9+1474479173.6c180c6-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Attempted to install shim-signed, it depends on:
> 
> * shim 0.9+1474479173.6c180c6-1, however version 15+1533136590.3beb971-2 is 
> the one in the repos
> * secureboot-db, however that package is not in the sid repos at all.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> N/A
> 
>* What was the outcome of this action?
> 
> Failed to install
> 
>* What outcome did you expect instead?
> 
> I expected shim-signed to be installable.

Right, this also breaks the build of the debian-installer source package
on amd64 since its build dependencies cannot be satisfied.

Having checked that with the maintainer a couple hours ago, it seems a
round-trip to get a new signature is needed: so they're aware already.

Adjusting severity and marking this as affecting d-i, adding the
installer team in copy.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#922425: grub-common: Export and use GRUB_CMDLINE_LINUX_RECOVERY

[Kyle Rankin]

Package: grub-common
Version: 2.02+dfsg1-10
Severity: wishlist

Currently grub does not allow you to set Linux boot arguments that apply
*only* to the "recovery" mode set in /etc/grub.d/10_linux. Instead,
options that you set in GRUB_CMDLINE_LINUX in /etc/default/grub get 
applied both to recovery modes and prepended to GRUB_CMDLINE_LINUX_DEFAULT
for the default boot option. In the process of working on a method to
boot from an OpenPGP smartcard (recent support added to
cryptsetup-initramfs) I ran into this issue as I needed to override the
default /etc/crypttab options with the cryptopts kernel argument in the
case a user loses their OpenPGP smartcard and needs to revert to a LUKS
passphrase in recovery mode.

Implementing the ability to set kernel command line arguments that only
apply during recovery mode would require changes to changes to 3 total
lines, one to export the existing GRUB_CMDLINE_LINUX_RECOVERY variable
so it can be used in /etc/default/grub:

/usr/sbin/grub-mkconfig line 222:

  GRUB_CMDLINE_LINUX_DEFAULT \

becomes

  GRUB_CMDLINE_LINUX_DEFAULT \
  GRUB_CMDLINE_LINUX_RECOVERY \


And two changes that use variable, if set, instead of overwriting it:

/etc/grub.d/10_linux line 91:

  GRUB_CMDLINE_LINUX_RECOVERY=recovery

becomes

  GRUB_CMDLINE_LINUX_RECOVERY="$GRUB_CMDLINE_LINUX_RECOVERY recovery"

/etc/grub.d/10_linux line 93:

  GRUB_CMDLINE_LINUX_RECOVERY=single

becomes

  GRUB_CMDLINE_LINUX_RECOVERY="$GRUB_CMDLINE_LINUX_RECOVERY single"


This change shouldn't have any negative impact on existing users if they
don't set the variable, apart from adding a space to their kernel
command line for the recovery boot options.

--
Kyle Rankin


signature.asc
Description: PGP signature

Bug#858382: the documentations does not work unless we install all the gamba packages

[Bastian Germann]

Installing gambas3 from PPA and then Debian packages is not a common use
case. If you do so, you are on your own and cannot expect support.
Please try to stick to the issue's topic.

I will not try to have a different approach to documentation in Debian
than upstream. If anybody wants to improve the situation, I am happy to
take patches and even post them upstream if you do not know how to do
that yourselves.

So, my question rephrased: When you install the current testing
gambas3-ide package (currently version 3.12.2-1), does downloading the
offline documentation work without installing any additional packages?
If not, which packages do you need to install on top?

Bug#921971: (no subject)

[Jelmer Vernooij]

control: tags -1 -wontfix

I don't think this should be wontfix. This is not impossible to address, but
not as simple as the current patch suggests.

E.g. looking at the upgrade checklist in policy
(https://www.debian.org/doc/debian-policy/upgrading-checklist.html), a quick
glance shows that the following upgrades should be safe:

* 4.2.0 => 4.2.1 (since it relaxes a condition)
* 4.1.0 => 4.1.1 (just so long as we check that debian/changelog is present)

or, with a little bit more work:

* 3.9.3 => 3.9.4

Bug#921653: texlive-latex-extra: docindex.sty relies on unavailable xhj.sty, galley2.sty

[Braun Gábor]

Hi Hilmar,

> Upstream refused the bug, see [1]. They suggest to contact the author of
> docindex

I have problems finding contact information for the author.
I would welcome any ideas what else to try.

I have looked at the documentation for packages authored by
Lars Hellström, and only found the email address 
lars.hellst...@math.umu.se (in e.g. xdoc2.pdf)
but I have received an 550 Address rejected answer for my email sent 
there.

An Internet search finds many people named Lars Hellström.

> My impression is that this xdoc package is rather an academic
> experiment, which was never meant to be used by real end users. The
> Debian solution would be easy: put it on the blacklist.

Yes, the package looks abandoned.

Best wishes,

Gábor

Bug#915354: Bug#921482: RFS: note/1.3.26-3 +help

[eamanu15]

Hi,


El vie., 15 de feb. de 2019 a la(s) 14:27, Dmitry Bogatov (
kact...@debian.org) escribió:

>
> [2019-02-11 22:00] eamanu15 
> > If you look
> >
> https://salsa.debian.org/eamanu-guest/note/commit/b2fbec0443dd078dfbcf05efab7729ee3b2e6e3e
> > you will see that I set myself as maintainer. The Version of note on
> salsa
> > was: 1.3.22
> > But on unstable was 1.3.26
> >
> > For this reason, I download the files from package.debian
> > the 1.3.26 and updated it on salsa:
> >
> https://salsa.debian.org/eamanu-guest/note/commit/0bb88562fd7c3b2a2035bd0d0f5b919b4a24af15
> >
> > But, when I continue working on the package on
> >
> https://salsa.debian.org/eamanu-guest/note/commit/5bc4330c7f174713549f4bf4e1839d669e637551
> > I forgot set myself as maintainer. Was my foul.
> >
> > For this reason In this new package version 1.3.26-3 I add me
> > on Maintainer field.
>
> So I believe simple "Set myself as Maintainer" would do. Or am I missing
> something again?
>

Nope, you are right. I will write that

Thanks

> --
> Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>
>--
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#918965: adequate tells about broken-symlink in quassel-data

[Scott Kitterman]

See the package Suggests.  This is intentional.

Scott K

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Matthijs Kooijman]

Hi Steve,

> In fact, one of the projects I've been trying to get to for a couple
> of years now is simplifying things by going the other way: using GRUB
> for everything and dropping syslinux on Debian media.

Hm, that's another interesting thought. I was aiming for syslinux, since
our current setup uses that (along with some custom configuration).
However, that seems to be impossible to work with secure boot (which
would be nice to have) and impossible to boot from optical media (which
for my personal case is not an issue).

I could imagine switching to grub completely (which means that this
issue changes from "add syslinux-efi" to "make grub-pc & grub-efi work
for hdd images"), though that's probably a bit more work for me and my
client.  I'll dig in a bit deeper to see how much work that would be.

Thanks for everyone's input so far!

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[Xavier]

Le 15/02/2019 à 18:29, Xavier a écrit :
> Le 15/02/2019 à 17:57, gregor herrmann a écrit :
>> On Wed, 13 Feb 2019 21:23:00 +0100, Xavier Guimard wrote:
>>
>>> Some suggestions for pkg-js-autopkgtest based on pkg-js-autopkgtest
>>> discussion with autodep8 maintainers:
>>>  - tests skipped should return a 77 exit code and all tests marked as
>>>"Restrictions: skippable". It avoids to consider that a test succeeds
>>>if maintainer skipped it, but needs a merge request to autodep8. See
>>>
>>> https://salsa.debian.org/ci-team/autodep8/blob/master/support/nodejs/generate
>>>(changed by MR !11)
>>>  - runtime-deps* tests should be tagged as "Restrictions: superficial"
>>>since these tests don't really test package features but just Perl
>>>syntax
>>>
>>> Then with this 2 changes, if "build-deps.d" is skipped, success won't
>>> give the benefit of 3-days-reduce.
>>
>> Thanks for your work and the pull request [0]!
>>
>> Some thoughts and more questions:
>>
>> For the skippable part:
>> - If I understand this correctly (from your text above and the spec
>>   [1]) then a skipped syntax.t and use.t would also lead to losing
>>   the benefit of faster migration? Do we want this?
> 
> The benefit will be lost only if smoke test is skipped. I think it's a
> good thing (other tests are "superficial" <=> no benefit). Today if this
> test is skipped, it is considered by autopkgtest as "success"
> 
>>   Or does it just have no influence?
> 
> skippable has no influence if test succeed, but don't consider that test
> has failed if a 77 code is returned
> 
>> - As for the implementation in [0]:
>>   not sure if the "exit 0" in smoke is correct
>> - What about the skipped tests within use.t and syntax.t? Should they
>>   or some of them also exit 77?
> 
> runner do it for them. I didn't modify them if all is skipped as it has
> no effect on a test marked as "superficial": 0 or 77 gives the same
> result: no benefit, no penalty
> 
>> For the superficial part:
>> Hm, yeah, use.t and syntax.t don't test that everything in the
>> package is fully functional; still, this "superficial" feels a bit
>> weird. But probably it's correct according to [1].
>>
>> In general I still don't have the full picture of what benefits and
>> penalties for testing migration will result from which combination of
>> the changes under which circumstances.
> 
> The only effect of this is that if smoke test is skipped, there is no
> benefit. And I think it's more clear to have the real result:

I found the exact message, it is very clear:

# EXAMPLE 1, SKIP use.t => benefit OK
autopkgtest [18:23:17]:  summary
command1: PASS
command2: SKIP exit status 77 and marked as skippable
command3: PASS (superficial)

# EXAMPLE 2, SKIP smoke => no benefit
command1: SKIP exit status 77 and marked as skippable
command2: PASS (superficial)
command3: PASS (superficial)

# EXAMPLE 3, real failure in smoke => penalty
command1: FAIL
command2: PASS (superficial)
command3: PASS (superficial)

# EXAMPLE 4, real failure in use.t => penalty
command1: PASS
command2: FAIL
command3: PASS (superficial)

Cheers,
Xavier

Bug#920995: spatialite: hangs during virtualknn test

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 2/10/19 9:24 PM, Sebastiaan Couwenberg wrote:
> On 1/31/19 2:17 PM, Bas Couwenberg wrote:
>> On 2019-01-31 13:36, Andreas Beckmann wrote:
>>> during a test rebuild of spatialite/experimental I noticed that it hangs
>>> during the virtualknn test. After killing that process the build
>>> continued and succeeded. I think this has so far happened more than
>>> once, not sure if on amd64 or or i386 or both.
>>
>> I've confirmed this issue in an amd64 experimental chroot, and forwarded
>> the issue upstream:
>>  
>> https://www.gaia-gis.it/fossil/libspatialite/tktview/2cad2f4b9df468fa062f624638d4ac6072611821
> 
> Upstream has tracked down the issue and committed a fix:
> 
>  https://www.gaia-gis.it/fossil/libspatialite/ci/90180e065dfdd8fa?sbs=0
> 
> A new (beta) release should be published next week, so I'll wait for
> that instead of adding a patch with the fix since the issue only affects
> the package in experimental.

The release hasn't happened yet, so I've added the patch.

A new upload to experimental will follow shortly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[Xavier]

Le 15/02/2019 à 17:57, gregor herrmann a écrit :
> On Wed, 13 Feb 2019 21:23:00 +0100, Xavier Guimard wrote:
> 
>> Some suggestions for pkg-js-autopkgtest based on pkg-js-autopkgtest
>> discussion with autodep8 maintainers:
>>  - tests skipped should return a 77 exit code and all tests marked as
>>"Restrictions: skippable". It avoids to consider that a test succeeds
>>if maintainer skipped it, but needs a merge request to autodep8. See
>>
>> https://salsa.debian.org/ci-team/autodep8/blob/master/support/nodejs/generate
>>(changed by MR !11)
>>  - runtime-deps* tests should be tagged as "Restrictions: superficial"
>>since these tests don't really test package features but just Perl
>>syntax
>>
>> Then with this 2 changes, if "build-deps.d" is skipped, success won't
>> give the benefit of 3-days-reduce.
> 
> Thanks for your work and the pull request [0]!
> 
> Some thoughts and more questions:
> 
> For the skippable part:
> - If I understand this correctly (from your text above and the spec
>   [1]) then a skipped syntax.t and use.t would also lead to losing
>   the benefit of faster migration? Do we want this?

The benefit will be lost only if smoke test is skipped. I think it's a
good thing (other tests are "superficial" <=> no benefit). Today if this
test is skipped, it is considered by autopkgtest as "success"

>   Or does it just have no influence?

skippable has no influence if test succeed, but don't consider that test
has failed if a 77 code is returned

> - As for the implementation in [0]:
>   not sure if the "exit 0" in smoke is correct
> - What about the skipped tests within use.t and syntax.t? Should they
>   or some of them also exit 77?

runner do it for them. I didn't modify them if all is skipped as it has
no effect on a test marked as "superficial": 0 or 77 gives the same
result: no benefit, no penalty

> For the superficial part:
> Hm, yeah, use.t and syntax.t don't test that everything in the
> package is fully functional; still, this "superficial" feels a bit
> weird. But probably it's correct according to [1].
> 
> In general I still don't have the full picture of what benefits and
> penalties for testing migration will result from which combination of
> the changes under which circumstances.

The only effect of this is that if smoke test is skipped, there is no
benefit. And I think it's more clear to have the real result:

# EXAMPLE 1, SKIP use.t => benefit OK
autopkgtest [18:23:17]:  summary
command1: PASS
command2: FAIL exit 77 (marked as skippable) # I don't remember the
 # exact message
command3: PASS (superficial)

# EXAMPLE 2, SKIP smoke => no benefit
command1: FAIL exit 77 (marked as skippable)
command2: PASS (superficial)
command3: PASS (superficial)

# EXAMPLE 3, real failure in smoke => penalty
command1: FAIL
command2: PASS (superficial)
command3: PASS (superficial)

# EXAMPLE 4, real failure in use.t => penalty
command1: PASS
command2: FAIL
command3: PASS (superficial)

Cheers,
Xavier

Bug#922334: ibus breaks KDE

[Charles Samuels]

I performed an experiment where I installed a basic Debian stretch in a VM. 
Then I installed KDE and saw that it was working fine.

Then I installed ibus. KDE continued to work fine.

I saw ibus was running and there was the ibus icon in the tray. If I exit 
that, the keyboard stopped working.

Why does ibus start automatically in a KDE session but just installing it?

Exiting ibus shouldn't break my keyboard, it should just turn off input method 
features.

Bug#915354: Bug#921482: RFS: note/1.3.26-3 +help

[Dmitry Bogatov]

[2019-02-11 22:00] eamanu15 
> If you look
> https://salsa.debian.org/eamanu-guest/note/commit/b2fbec0443dd078dfbcf05efab7729ee3b2e6e3e
> you will see that I set myself as maintainer. The Version of note on salsa
> was: 1.3.22
> But on unstable was 1.3.26
>
> For this reason, I download the files from package.debian
> the 1.3.26 and updated it on salsa:
> https://salsa.debian.org/eamanu-guest/note/commit/0bb88562fd7c3b2a2035bd0d0f5b919b4a24af15
>
> But, when I continue working on the package on
> https://salsa.debian.org/eamanu-guest/note/commit/5bc4330c7f174713549f4bf4e1839d669e637551
> I forgot set myself as maintainer. Was my foul.
>
> For this reason In this new package version 1.3.26-3 I add me
> on Maintainer field.

So I believe simple "Set myself as Maintainer" would do. Or am I missing
something again?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#922424: dh-make: consistent .ex extension

[Dmitry Bogatov]

Package: dh-make
Version: 2.201802
Severity: wishlist

Dear Maintainer,

please generate example files with consistent extension, either .ex or
.EX, not both. See content of `debian/' directory, just generated with
dh_make:

build-alternative.cron.d.ex
build-alternative.doc-base.EX
build-alternative-docs.docs
changelog
compat
control
copyright
manpage.1.ex
manpage.sgml.ex
manpage.xml.ex
menu.ex
postinst.ex
postrm.ex
preinst.ex
prerm.ex
README.Debian
README.source
rules
source
watch.ex
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp5VCDgASYWW.pgp
Description: PGP signature

Bug#922422: dnsmasq: missing Vcs fields

[Dmitry Bogatov]

Package: dnsmasq
Version: 2.80-1
Severity: wishlist

Dear Maintainer,

please provide Vcs-* fields in debian/control. It makes contribution
much easier.


pgpg06aF3PDNS.pgp
Description: PGP signature

Bug#921971: lintian-brush: fixer for out-of-date-standards-version

[Dmitry Bogatov]

control: tags -1 +wontfix

[2019-02-13 14:35] Jelmer Vernooij 
> The goal for lintian-brush is that you can safely run it without
> having to second-guess it.

Fine. Then marking as wont-fix.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Matthijs Kooijman]

Hey Luca,

> > So for the secure boot case in binary_grub-efi, what we do is that
> > if the signed monolithic EFI binaries are available we copy those
> > instead of building a new image.
> >
> > ...
> >
> > https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79
Aha! Turns out I was looking at an old version, I messed up my git
checkout apparently. That script indeed does what I would expect:
Install shim alongside grub and use signed grub to make shim load it.

> Ah silly me, I forgot something simple but quite fundamental: the point
> of syslinux is to avoid using grub entirely.

But indeed, I was aiming for syslinux, so none of this secure boot stuff
will actually work with syslinux.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#922423: initscripts: formatting of scripts

[Dmitry Bogatov]

Package: initscripts
Severity: wishlist

initscripts currently quite inconsistent in programming style and
formatting, using mix of tabs and spaces, test and [ ] and so on.

It would be nice to have it uniformed. I believe, it would help to have
some common patterns abstracted.


pgpcKo9ddJZOg.pgp
Description: PGP signature

Bug#841270: RFS: debrequest/0.2 ITP

[Dmitry Bogatov]

[2019-02-13 17:07] Mattia Rizzolo 
> So…
>
> On Wed, Feb 13, 2019 at 11:31:53AM +, Dmitry Bogatov wrote:
> > [2019-02-02 17:27] Mattia Rizzolo 
> > > Also, I'd like for you to check with the mentors.d.n code and make sure
> > > the template matches, keeping in mind that there is some kind of plan to
> > > make mentors send such mail automatically.
> > 
> > While formatting was inspired by mentors.d.o, the whole idea of
> > debrequest is that it produce much more detailed template.  Probably,
> > the most important feature is automatic deduction of programming
> > language. Also, dgit tries to accomodate to different workflows, like
> > dgit.
>
> I don't think anything but the dgit bit would be problematic to see also
> in mentors (where it wouldn't be relevant anyway, due to the nature of
> dgit).  Hence, I don't understand your issue with this.

Thank you for your review. I am sorry to admit, that I do not have
dedication to do all required generalizations to fit debrequest into
devscripts and/or merge into mentors.d.o. Feel free to close this bug.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#922421: src:sysvinit: maintainer script checks for ancient version

[Dmitry Bogatov]

Package: src:sysvinit
Severity: wishlist

sysvinit maintainer scripts have number of special cases, depending on
upgrade from very old versions. Debian does not support skip upgrades,
so many of this special cases could be safely removed.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpSdcPrPxVV0.pgp
Description: PGP signature

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Linda Lapinlampi]

A small update on this ITP:

The attached source is the current state of this package, UNRELEASED.
It's not fit for the Debian distribution just yet; but I'll allow eager
early testers to find the source from here.

+debian1 version should follow soon for sid, to be sponsored. I'll
polish it a little further and go through the Debian Policy once more to
check for any remaining issues before this.


matrix-archive-keyring_2015.12.09+debian0.10.tar.xz
Description: application/xz

Bug#922420: got an unexpected keyword argument 'bg'

[Enrico Zini]

Package: gandi-cli
Version: 1.2-1
Severity: serious

Hello,

trying to use the gandi CLI, I get this:

$ gandi ip detach 
Traceback (most recent call last):
  File "/usr/bin/gandi", line 11, in 
load_entry_point('gandi.cli==1.2', 'console_scripts', 'run-gandi')()
  File "/usr/share/gandi-cli/gandi/cli/__main__.py", line 8, in main
cli(obj={})
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
  File "/usr/share/gandi-cli/gandi/cli/core/cli.py", line 162, in invoke
click.Group.invoke(self, ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 64, in 
new_func
return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
TypeError: detach() got an unexpected keyword argument 'bg'

It looks like --background has been added to the command line parser,
but not to the function arguments to which the command line parser
result is sent.


Enrico

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

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

Versions of packages gandi-cli depends on:
ii  python33.7.2-1
ii  python3-pkg-resources  40.7.1-1

gandi-cli recommends no packages.

gandi-cli suggests no packages.

-- no debconf information

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

On 11 February 2019 at 15:12, Evan Miller wrote:
| An official release of libxls 1.5.0 is here:
| 
| https://github.com/libxls/libxls/releases/tag/v1.5.0 

| 
| It fixes all known vulnerabilities. Thanks for your patience everyone.

And Jenny did her thing with a new readxl, which is now on CRAN ... as
getting into Debian as r-cran-readxl as I type this.

Thanks everybody for the help with this -- especially Evan for the hard
schlepping of all those buckets of cold water.  Up the hill, both ways...

Dirk

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

Bug#922418: pandoc: Please reference texlive-latex-base package in the "install pdflatex" error message

[Jonas Smedegaard]

Quoting Chris Lamb (2019-02-15 18:10:13)
>   % pandoc -o output.pdf input.md
>   pdflatex not found. Please select a different --pdf-engine or install 
> pdflatex
> 
> I think this could be improved user-interface wise as pdflatex is
> in the "texlive-latex-base" package (and not a hypothetical "pdflatex"
> package).
> 
> A patch is attached that turns this into:
> 
>   % pandoc -o output.pdf input.md
>   pdflatex not found. Please select a different --pdf-engine or install 
> pdflatex from the texlive-latex-base package

Great!

I'll expand that to the other clues now listed only in long description.

Thanks a lot!

 - Jonas

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

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


signature.asc
Description: signature

Bug#922418: pandoc: Please reference texlive-latex-base package in the "install pdflatex" error message

[Chris Lamb]

Source: pandoc
Version: 2.2.1-3
Severity: minor
Tags: patch

Hi,

  % pandoc -o output.pdf input.md
  pdflatex not found. Please select a different --pdf-engine or install pdflatex

I think this could be improved user-interface wise as pdflatex is
in the "texlive-latex-base" package (and not a hypothetical "pdflatex"
package).

A patch is attached that turns this into:

  % pandoc -o output.pdf input.md
  pdflatex not found. Please select a different --pdf-engine or install 
pdflatex from the texlive-latex-base package


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-
diff --git a/src/Text/Pandoc/Error.hs b/src/Text/Pandoc/Error.hs
index feb047f..73885ff 100644
--- a/src/Text/Pandoc/Error.hs
+++ b/src/Text/Pandoc/Error.hs
@@ -103,7 +103,7 @@ handleError (Left e) =
 PandocSyntaxMapError s -> err 67 s
 PandocFailOnWarningError -> err 3 "Failing because there were warnings."
 PandocPDFProgramNotFoundError pdfprog -> err 47 $
-pdfprog ++ " not found. Please select a different --pdf-engine or 
install " ++ pdfprog
+pdfprog ++ " not found. Please select a different --pdf-engine or 
install " ++ pdfprog ++ " from the texlive-latex-base package"
 PandocPDFError logmsg -> err 43 $ "Error producing PDF.\n" ++ logmsg
 PandocFilterError filtername msg -> err 83 $ "Error running filter " ++
 filtername ++ ":\n" ++ msg

Bug#911655: AX_PATH_BDB_NO_OPTIONS makes broken assumptions for cross compilation

[Elimar Riesebieter]

Control: affects -1 - src:moc

* Helmut Grohne  [2018-10-23 08:19 +0200]:

> Package: autoconf-archive
> Version: 20170928-2
> Tags: patch upstream
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:moc
> 
> The AX_PATH_BDB_NO_OPTIONS is broken for cross compilation and that
> breaks moc. The macro assumes that $ac_cpp does not emit #line markers.
> For native compilation, $ac_cpp will be "cpp" and that assumption is ok.
> For cross compilation, it will be "-gcc -E" and that one emits
> #line markers. The macro inserts a line
> 
> AX_PATH_BDB_STUFF DB_VERSION_MAJOR,DB_VERSION_MINOR,DB_VERSION_PATCH
> 
> and then tries to parse what comes back from the preprocessor. In the
> cross compilation, that line is split up into many lines and the parsing
> fails.
> 
> If you do not want #line markers, you must pass -P to $ac_cpp. The
> attached patch implements that.

Should be fixed by moc 2.6.0~svn-r2994-3.

Elimar
-- 
  We all know Linux is great... it does infinite loops in 5 seconds.
-Linus Torvalds


signature.asc
Description: PGP signature

Bug#922419: RFP: node-karma-firefox-launcher -- A Karma plugin. Launcher for Firefox/Chrome

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-karma-firefox-launcher
  Version : 1.1.0
  Upstream Author : Google, Inc.
* URL : 
https://notabug.org/makenotabuggreatagain/karma-firefox-launcher
* License : MIT
  Programming Lang: javascript
  Description : A Karma plugin. Launcher for Firefox/Chrome

Karma is a test runner for javascript/nodejs projects.

node-karma-firefox-launcher is a plugin for Karma, that allows for customized
launching of various versions of firefox(and Chrome) within the karma test 
framework.

node-karma-firefox-launcher is a prerequisite of 
libjs-jquery-datetimepicker ( #921920 )

Bug#922417: mupdf: does not support -geometry standard X11 option

[Thorsten Glaser]

Package: mupdf
Version: 1.14.0+ds1-3
Severity: minor

/usr/bin/mupdf[31]: -g: unknown option
/usr/bin/mupdf[31]: -e: unknown option
/usr/bin/mupdf[31]: -o: unknown option
/usr/bin/mupdf[31]: -m: unknown option
/usr/bin/mupdf[31]: -e: unknown option
/usr/bin/mupdf[31]: -t: unknown option

Please support -geometry like xterm does. (I could use -r but my
display has a non-integer dpi, so I’d prefer to set the pixels.)

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages mupdf depends on:
ii  libc62.28-5
ii  libfreetype6 2.9.1-3
ii  libharfbuzz0b2.3.0-1
ii  libjbig2dec0 0.15-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-1.1
ii  libssl1.11.1.1a-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
ii  mupdf-tools  1.14.0+ds1-3

-- no debconf information

Bug#922334: ibus breaks KDE

[Charles Samuels]

Hi Osamu,

On Friday, February 15, 2019 8:11:03 PM PST Osamu Aoki wrote:
> Hi,
> 
> On Thu, Feb 14, 2019 at 09:41:11AM -0800, Charles Samuels wrote:
> > Package: ibus
> > Version: 1.5.14-3
> > Severity: important
> > Tags: upstream
> 
> Can you explain why you placed "Tags: upstream"?
> Any of the upstream changes in their recent ibus release has fix in it?

That tag is in error.

> 
> By the way, please install ibus-qt4 and possibly ibus-clutter first and
> reboot system to see if problem goers away..> .

I installed ibus-qt4 and rebooted. Nothing. I then installed ibus-clutter and 
restarted, still nothing.

Note that KDE uses Qt5 (not qt4).

> > Merely having the ibus package installed breaks KDE's Plasma
> > Shell. Keystrokes into certain applications fails, such
> > as KWallet and the Alt-F2 KRunner. These tools fail to receive
> > 99% of keystrokes.
> 
> Wait you are using stable system ... h you don't seem to use any
> input method.  You are using input of GTK and QT4 apps via xim.
> 
> > A similar bug with workarounds is listed here:
> > 
> > https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1633721
> > 
> > For me, `ibus-daemon -d -s` seemed to work.

It worked, but it broke KDE's input configuration, such keymap changes with 
double-shift and everything in the "Keyboard Hardware and Layout" window. So 
even that is inadequate.

Since "krunner" is one of the broken apps, and it's still running, I did an 
experiment:

$ tr '\0' '\n' < /proc/`pidof krunner`/environ | grep -E '(ibus|IM)' | sort
CLUTTER_IM_MODULE=ibus
GTK_IM_MODULE=xim
LC_TIME=en_CA.UTF-8
QT4_IM_MODULE=ibus
QT_IM_MODULE=ibus
XDG_RUNTIME_DIR=/run/user/1000
XMODIFIERS=@im=ibus

And from a Konsole in which things are working:

$ env | grep -E '(ibus|IM)' | sort
CLUTTER_IM_MODULE=ibus
GTK_IM_MODULE=xim
LC_TIME=en_US.UTF-8
QT4_IM_MODULE=ibus
QT_IM_MODULE=ibus
XDG_RUNTIME_DIR=/run/user/1000
XMODIFIERS=@im=ibus

The only difference is LC_TIME, which is weird but not seemingly related.

> If you are not using ibus with any input-method, removing this is one
> option.  (Maybe this is pulled in by Gnome... then may not be easy...)

I have a third-party package installed which depends on ibus for some reason. 
I filed a bug with them as well, but the root cause is still that installing 
ibus breaks kde.

> 
> > -- Package-specific info:
> > default-display-manager: /usr/bin/sddm
> 
> You are KDE guy!

Correct, I run a KDE session.

I ran im-config and wound up with this in my .xinputrc:

# im-config(8) generated on Fri, 15 Feb 2019 08:43:45 -0800
run_im xim
# im-config signature: 00f07bacb5352b457537832981e99432  -

I doublechecked that this exact configuration is sufficient by removing it and 
then adding it again. KDE works normally, including the KDE "Keyboard Hardware 
and Layout" options.

Please let me know how else I can help to resolve this properly.

Charles

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[gregor herrmann]

On Wed, 13 Feb 2019 21:23:00 +0100, Xavier Guimard wrote:

> Some suggestions for pkg-js-autopkgtest based on pkg-js-autopkgtest
> discussion with autodep8 maintainers:
>  - tests skipped should return a 77 exit code and all tests marked as
>"Restrictions: skippable". It avoids to consider that a test succeeds
>if maintainer skipped it, but needs a merge request to autodep8. See
>
> https://salsa.debian.org/ci-team/autodep8/blob/master/support/nodejs/generate
>(changed by MR !11)
>  - runtime-deps* tests should be tagged as "Restrictions: superficial"
>since these tests don't really test package features but just Perl
>syntax
> 
> Then with this 2 changes, if "build-deps.d" is skipped, success won't
> give the benefit of 3-days-reduce.

Thanks for your work and the pull request [0]!

Some thoughts and more questions:

For the skippable part:
- If I understand this correctly (from your text above and the spec
  [1]) then a skipped syntax.t and use.t would also lead to losing
  the benefit of faster migration? Do we want this?
  Or does it just have no influence?
- As for the implementation in [0]:
  not sure if the "exit 0" in smoke is correct
- What about the skipped tests within use.t and syntax.t? Should they
  or some of them also exit 77?

For the superficial part:
Hm, yeah, use.t and syntax.t don't test that everything in the
package is fully functional; still, this "superficial" feels a bit
weird. But probably it's correct according to [1].

In general I still don't have the full picture of what benefits and
penalties for testing migration will result from which combination of
the changes under which circumstances.


Cheers,
gregor


[0] 
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/merge_requests/2
[1] 
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Cat Power: The Greatest


signature.asc
Description: Digital Signature

Bug#922415: Zap /var/lib/dpkg/available* and save the user four megabytes

[積丹尼 Dan Jacobson]

Package: dpkg
Version: 1.19.4
Severity: minor

How about removing
/var/lib/dpkg/available
/var/lib/dpkg/available-old
or at least zapping them to zero bytes.
They haven't been updated in five years,
and you could save the user four megabytes.

OK maybe they still update on some people's systems, but not mine.

Indeed four megabytes is bigger than the biggest file,
$ find /var/lib/dpkg -type f|xargs ls -og|sort -k 3nr,3|sed q
-rwxr-xr-x 1 2260721 02-09 06:22 
/var/lib/dpkg/info/keyboard-configuration.config

of all
$ find /var/lib/dpkg -type f|wc -l
5796

files in the entire tree.

P.S., remember to remove all the mentions of the "available file" from the man 
page too.