Bug#918206: pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Graham Inggs]

Control: severity -1 serious
Control: tags -1 + ftbfs

On Fri, 4 Jan 2019 at 12:30, Bas Couwenberg  wrote:
> The autopkgtest for your package fail with python-numpy
> (1:1.16.0~rc1-3), this increased the required age of python-numpy which
> blocks the gdal transition.

The autopkgtest failure seems to have started on 2018-12-21 [1] after
the upload of matplotlib.

Anyway, pandas now FTBFS and needs to be made compatible with the new
python-numpy and matplotlib packages.


[1] https://ci.debian.net/packages/p/pandas/unstable/amd64/

Bug#920865: havp: add support for clamav 0.101

[Christian Hilgers]

Hi Sebastian,

thanks for the patch. I will update havp this weekend. 
I would like to include your name and email. Is that ok?

Bye 
Christian 

> Am 29.01.2019 um 23:34 schrieb Sebastian Andrzej Siewior 
> :
> 
> Source: havp
> Version: 0.92a-4
> Severity: important
> tags: patch
> 
> havp does not compile against new clamav. The patch attached does solve
> the issue.
> 
> Sebastian
> 

Bug#920976: kdiff3: Some files could not be processed

[Tobias Frost]

Package: kdiff3
Version: 1.7.90-3
Severity: normal

Dear Maintainers,

since recently I kdiff3 fails to analyze directories and a dialog with
the message in the title comes up. As a consequence, kdiff3 no longer
detects in the tree view if a file is identical (the square indicators
which normally would be green for A and B then are black).
They are counted as "different" then.

I'm running kdiff3 on gnome, if that matters.

Let me know if I can do something to help debugging!

Cheers,

tobi

PS: I've just run kdiff3 on some old package I have sponsored,
and interstling, in this case I've got an different error dialog.

The command I've used was
kdiff3 new/$package-1.3/debian/ new2/$package-1.3/debian/
and then the dialog had the addtiional information that files
could not be found in "A" (e.g debian/compat, but it seems that I did
not detect any single file that was identical. Interestingly e.g
d/changelog was not in the list of above example)

PPS: I run it through strace, I attach the file. (I terminated kdiff3
after it showed the dialog, before dimissing it.)



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

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

Versions of packages kdiff3 depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-5
ii  libkf5configcore5 5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5parts5  5.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg-2
ii  libqt5gui55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg-2
ii  libqt5widgets55.11.3+dfsg-2
ii  libstdc++68.2.0-15

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.7.90-3

kdiff3 suggests no packages.

-- no debconf information


kdiff3-strace.xz
Description: application/xz

Bug#920900: libicu-dev: Command icu-config disappeared from libicu-dev

[Juhani Numminen]

On Wed, 30 Jan 2019 13:41:32 +0100 Vlastimil Zima  
wrote:
> Package: libicu-dev
> Version: 63.1-6
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> after upgrading libicu-dev, I can't install PyICU using pip, due to an error:
> 
> FileNotFoundError: [Errno 2] No such file or directory: 'icu-config': 
> 'icu-config'
> 
> I found no replacement of the icu-config, hence I assume the file disappeared 
> by an accident.
> 
> When I downgrade libicu-dev back to 60.2-6, it works.

Hi,

I'm not the maintainer but here's some further information.

That is already reported as a bug in PyICU:
https://github.com/ovalhub/pyicu/issues/92

It appears the removal of icu-config is due to it being deprecated upstream, 
and not
working with Debian's multi-arch system. So its disappearance is not an 
accident.
https://bugs.debian.org/898820

Quoting from http://userguide.icu-project.org/howtouseicu
"The recommended way to use ICU in Makefiles is to use the pkg-config files 
[...]
This is preferred over the deprecated icu-config script."


Regards,
Juhani

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Thu, Jan 31, 2019 at 7:14 AM Akira TAGOH  wrote:
>
> On Thu, Jan 31, 2019 at 8:07 AM Keith Packard  wrote:
>
> > > This would avoid collision between one and origins. and assuming that
> > > flatpaks can load config from host too, we could have:
> > >
> > > 10-salt.conf (from host):
> > > 
> >
> > I'd leave this out and not have salt in the host.
>
> Sure. though implicit thing may breaks something easily like own salt
> affects 'remap-dir' unexpectedly. that should be documented carefully.
> or should we have salt attribute in remap-dir and dir elements
> instead? that would be obvious.

As I said in an earlier email, it needs to be in the individual dir
elements, because a global salt is not right.

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Wed, Jan 30, 2019 at 10:33 AM Akira TAGOH  wrote:
>
> On Wed, Jan 30, 2019 at 5:02 AM Keith Packard  wrote:
> > Yes, that was the plan. Alexander suggested the following syntax:
> >
> >  /usr/share/fonts
> >
> > I think this will work, although it seems a bit fragile. In particular,
> > if the host has salt for some directories, those will be defined
> > relative to the host paths, not the flatpak paths.
>
> Right. though this syntax looks primitive. it might manages to be done
> if one writes everything for what they want. but if we can have easier
> way - which can be done with minimal effort and inheritance for others
> from host - that may be better.
>
> > Do we need to process the 'salt' elements and 'remap-dir' elements in
> > order and remap old salt elements as remap-dir elements get loaded? That
> > also seems fragile to me.
>
> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path. for flatpak case, they want to have a global salt to
> change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set
> salt from host in 'remap-dir' to build cache filenames on host (for
> /run/host/fonts and so on).
> This would avoid collision between one and origins. and assuming that
> flatpaks can load config from host too, we could have:

We don't want a global salt for everything in the container. In
reality things are more complicated than that. For example, an app may
bundle fonts, which will be in like /app/share/fonts, in addition to
the runtime fonts in /usr/share/fonts. These come from different
places and may individually be different in a different (or updated)
app, so the directories need to have different salts.

Also, it is quite possible that some host font directory is *not*
remapped, but still visible to the app. For example /opt/fonts for an
app that has filesystem access. If for whatever reason fontconfig
looks at this directory it should not apply any salt for it.

Bug#920975: slick-greeter: does not add itself to lightdm-greeter alternatives group

[John Crawley]

Package: slick-greeter
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

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


   * What led up to the situation?
Installed slick-greeter on a Debian Buster system already using lightdm 
with lightdm-gtk-greeter.
   * What exactly did you do (or not do) that was effective (or 
ineffective)?
Looked at the Debian alternatives group "lightdm-greeter" to select 
slick-greeter.

   * What was the outcome of this action?
/usr/share/xgreeters/slick-greeter.desktop exists, but was not a member 
of the above group.

   * What outcome did you expect instead?
Expected to be able to set lightdm-greeter to 
/usr/share/xgreeters/slick-greeter.desktop


Debian's lightdm expects (in 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf) its greeter to be set 
by the alternative "lightdm-greeter", but slick-greeter overrules this 
in 50-slick-greeter.conf.
If, instead of using 50-slick-greeter.conf, slick-greeter set an 
alternative in the lightdm-greeter group it would be easy for users to 
switch greeters. Now it is necessary for a user or sysadmin to edit 
/etc/lightdm/lightdm.conf, or else uninstall the unused greeter.


lightdm-gtk-greeter already does this in debian/{postinst,prerm} files 
and slick-greeter could use the same method.


John

-- 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/1 CPU core)
Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages slick-greeter depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-5
ii  libcairo21.16.0-2
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.4-1
ii  liblightdm-gobject-1-0   1.26.0-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  lightdm  1.26.0-3
ii  python3  3.7.2-1
ii  python3-gi   3.30.4-1

slick-greeter recommends no packages.

slick-greeter suggests no packages.

-- no debconf information

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Tue, Jan 29, 2019 at 9:02 PM Keith Packard  wrote:
>
> Akira TAGOH  writes:
> Do we need to process the 'salt' elements and 'remap-dir' elements in
> order and remap old salt elements as remap-dir elements get loaded? That
> also seems fragile to me.
>
> Perhaps some command that the flatpak could run to generate host salt
> values so that it could remap them into new salt elements using the
> mapped paths?
>
> Alternatively, we could just assume that only flatpak will use the salt
> mechanism and leave this for a future enhancement?

I think in practice salt on the host-side of something like this will
only be there if we're using multiple levels of containers, which all
pass down the outermost fonts. I don't think this is going to be very
common at all, so maybe just ignoring it for now is fine?

Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Xavier]

Le 30/01/2019 à 23:47, Jonas Smedegaard a écrit :
> Quoting Xavier (2019-01-30 22:54:53)
>> Le 30/01/2019 à 22:34, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2019-01-30 22:26:57)
 Le 29/01/2019 à 22:17, Jonas Smedegaard a écrit :
> Source package contains below  several files embedding code 
> from external project fileOverview Kickass, without source 
> included.
> 
> Just a clarification: Name of external project is Popper.js: 
> "fileOverview" is just a marker, and "Kickass" is first word of 
> Popper.js short description.
> 
> 
 I succeed to build source, but this needs:
>>> [snip]
>>>
>>> This bugreport tracks twitter-bootstrap4 violating Policy in 
>>> shipping code without source.
>>>
>>> For discussing packaging of that source in a separate package, 
>>> please file an ITP bugreport (or an RFP bugreport if you don't 
>>> intent on doing the work yourself), and let's discuss packaging 
>>> issues there.
> 
>> Also is it OK if I remove dist/bootstrap.bundle.* in Files-Excluded ?
> 
> Sorry, I don't understand your question.
> 
> What do you mean by "also"?  Did I miss some previous conversation that 
> this is an addition of?
> 
> Are you asking if it is ok to violate Debian Policy here?  Or is your 
> question a different one? Please try rephrase...

That's not what I said. Anyway Jérémy found a way to patch this "grave
policy violation". In the same way, should you open a similar bug to any
of the packages which embeds bootstrap?

Bug#919215: Fwd: minissdpd 1.5.20180223-5: Please translate debconf PO for the package minissdpd

[Yangfl]

Hi,

Please consider updating your translations according to the lastest templates.

Thanks

-- Forwarded message -
From: Yangfl 
Date: 2019年1月31日周四 下午3:10
Subject: minissdpd 1.5.20180223-5: Please translate debconf PO for the
package minissdpd
To: Debian Internationalization 


Dear Debian I18N people,

I would like to know if some of you would be interested in translating
minissdpd.

minissdpd already includes da.po de.po fr.po nl.po pt.po pt_BR.po
ru.po zh_CN.po zh_TW.po.
Do not translate it to da de pt nl zh (the translators will be
contacted separately at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=minissdpd).

languagetranslated fuzzy untranslated
-
  da 5   5 1
  de 5   5 1
  fr 4   3 4
  nl 5   5 1
  pt 5   5 1
  pt_BR  4   3 4
  ru 4   3 4
  zh_CN  9   2
  zh_TW  5   5 1

Please send the updated file to me, or submit it as a wishlist bug
against minissdpd.

The deadline for receiving the updated translation is 2019-02-06.

If you have read so far, please find the POT file in attachment.

Thanks in advance,

---

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the minissdpd package.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: minissdpd\n"
"Report-Msgid-Bugs-To: miniss...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-31 14:58+0800\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid "MiniSSDP daemon configuration"
msgstr ""

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"The MiniSSDP daemon is being installed (perhaps as a dependency for UPnP "
"support) but will not function correctly until it is configured."
msgstr ""

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"MiniSSDP is a daemon used by MiniUPnPc to speed up device discovery. For "
"security reasons, no out-of-box default configuration can be provided, so it "
"requires manual configuration."
msgstr ""

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"Alternatively you can simply override the recommendation and remove "
"MiniSSDP, or leave it unconfigured - it won't work, but MiniUPnPc (and UPnP "
"applications) will still function properly despite some performance loss."
msgstr ""

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid "Start the MiniSSDP daemon automatically?"
msgstr ""

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid ""
"Choose this option if the MiniSSDP daemon should start automatically, now "
"and at boot time."
msgstr ""

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid "Interfaces to listen on for UPnP queries:"
msgstr ""

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"The MiniSSDP daemon will listen for requests on one interface, and drop all "
"queries that do not come from the local network. Please enter the LAN "
"interfaces or IP addresses of those interfaces (in CIDR notation) that it "
"should listen on, separated by space."
msgstr ""

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"Interface names are highly preferred, and required if you plan to enable "
"IPv6 port forwarding."
msgstr ""

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid "Enable IPv6 listening?"
msgstr ""

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid ""
"Please specify whether the MiniSSDP daemon should listen for IPv6 queries."
msgstr ""


templates.pot
Description: MS-Powerpoint presentation

Bug#920859: libreoffice-kde5: Crash when minimizing file save dialog

[Rene Engelhard]

forwarded 920859 https://bugs.documentfoundation.org/show_bug.cgi?id=123077
thanks

Hi,

On Thu, Jan 31, 2019 at 01:48:43AM +0100, Michael Weghorn wrote:
> On 30/01/2019 22.34, Rene Engelhard wrote:
> > Upstream says:
> > 
> > 14:44 < _rene_> bubli: 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920859. known? (gtk3_kde5)
> > 14:45 <@bubli> _rene_: Neven seen before
> > 14:49 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has quit [Ping timeout: 
> > 268 seconds]
> > 14:51 < mst___> caolan, so a) the clipboard locking in VclGtkClipboard 
> > looks broken b) since LO 5.3, commit 
> > ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60 works around the breakage 
> > because my extension here will always hold the SolarMutex 
> > now so the main thread doesn't get a chance to run anyway
> > 14:52 < IZBot> core - try to avoid the deadlock around the clipboard,  - 
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60
> > 14:52 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has joined 
> > #libreoffice-dev
> > 14:55 < michaelweghorn> _rene_: I can reproduce here and can take a look, 
> > but probably not before next week
> 
> I have created an upstream bug and am currently working on a fix:
> https://bugs.documentfoundation.org/show_bug.cgi?id=123077

OK, thanks.

Regards,

Rene

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Yep, that looks good to me.

I don't time this week to hack on the code, and it looks like you're
doing great anyways; let me know if you need help in any way with the
implementation work.

-- 
-keith


signature.asc
Description: PGP signature

Bug#918788: ImportError: No module named backports.functools_lru_cache

[Stefano Rivera]

Control: tag -1 +unreproducible +moreinfo

> Package: python-backports.functools_lru_cache
> Version: 1.5-1

> -- System Information:
> Debian Release: 9.5
>   APT prefers stable
>   APT policy: (900, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)

Hrm. Given version 1.5-1 is not in stable and the package name was
incorrect in this bug report, I'm guessing it was filed from a different
system.

Can you provide more information from the system you've seen this on?
What version of python2.7 is present? Any other python-backports.*
packages?

I'd be interested in seeing the apt output for when the above packages
were installed, /var/log/apt/term.log*

I'm guessing you're missing 
/usr/lib/python2.7/dist-packages/backports/__init__.py
If you sudo touch /usr/lib/python2.7/dist-packages/backports/__init__.py
you should be able to get it back.

But the question is why that happened to you. I can't reproduce this
issue, so I can't find anything to fix.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data

[Scott Kitterman]

On Sat, 26 Jan 2019 08:47:52 -0800 Paul Hardy  wrote:
> Unicode's new version for 2019 is attached, with data files in
> http://www.unicode.org/ivd/data/ explicitly mentioned as covered under
> the license.  The source text is at
> http://www.unicode.org/copyright.html.

According to my wrangling of codesearch.debian.net, unicode.org gets mentioned 
in over 1,000 packages and it's mostly about this data.  I think that's enough 
to merit inclusion in common-licenses.

Scott K

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

Bug#264589: -- Hei! Hyvä asiakaamme,

[S-Pankki]

-- 
Hei! 
Hyvä asiakaamme,  
Verkkopankin käyttäjiä koskeva PSD2-direktiivin astui voimaan 13.01.2019
tästä johtuen verkkopalveluiden käyttäjien 
on tehtävä järjestelmäpäivitys ja päivittää yhteystiedot ajantasalle.  
Päivitä tietosi ja tehkää järjestelmäpäivitys  tästä  [1] 

Prosessi järjestelmän ja tietojen päivittämiseksi on tehty 
mahdollisimman helpoksi ja sujuvaksi.  
Käsittelemme rekistereissämme kaikkien asiakkaidemme tietoja samojen
käsittely- ja tietoturvaperiaatteiden mukaisesti.  

Kaikkien asiakkaidemme tiedot ovat esimerkiksi pankkisalaisuuden, 
vakuutussalaisuuden tai vastaavan salassapitovelvoitteen alaisia tietoja
riippumatta siitä, onko kyse henkilö- vai yritysasiakkaasta. 
Tietojen luovuttaminen on mahdollista vain asiakkaan antaman
suostumuksen tai lain perusteella.  

Ilman päivitystä pankkipalveluita voidaan joutua rajoittamaan. 
Päivitykset perustuvat 13.01.2019 voimaan tulleeseen PSD2-direktiiviin 
Rajoitukset koskevat maksukortteja ja verkkopankkia tai muuta tilin
käyttöä. 
Terveisin  
Asiakaspalvelu 
S-Pankkis 

Links:
--
[1] https://form.jotformeu.com/90298566035363

Bug#264589: Hyvä asiakaamme,

[S-Pankki]

-- 
Hei! 
Hyvä asiakaamme,  
Verkkopankin käyttäjiä koskeva PSD2-direktiivin astui voimaan 13.01.2019
tästä johtuen verkkopalveluiden käyttäjien 
on tehtävä järjestelmäpäivitys ja päivittää yhteystiedot ajantasalle.  
Päivitä tietosi ja tehkää järjestelmäpäivitys  tästä  [1] 

Prosessi järjestelmän ja tietojen päivittämiseksi on tehty 
mahdollisimman helpoksi ja sujuvaksi.  
Käsittelemme rekistereissämme kaikkien asiakkaidemme tietoja samojen
käsittely- ja tietoturvaperiaatteiden mukaisesti.  

Kaikkien asiakkaidemme tiedot ovat esimerkiksi pankkisalaisuuden, 
vakuutussalaisuuden tai vastaavan salassapitovelvoitteen alaisia tietoja
riippumatta siitä, onko kyse henkilö- vai yritysasiakkaasta. 
Tietojen luovuttaminen on mahdollista vain asiakkaan antaman
suostumuksen tai lain perusteella.  

Ilman päivitystä pankkipalveluita voidaan joutua rajoittamaan. 
Päivitykset perustuvat 13.01.2019 voimaan tulleeseen PSD2-direktiiviin 
Rajoitukset koskevat maksukortteja ja verkkopankkia tai muuta tilin
käyttöä. 
Terveisin  
Asiakaspalvelu 
S-Pankkis 

Links:
--
[1] https://form.jotformeu.com/90298566035363

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Akira TAGOH]

On Thu, Jan 31, 2019 at 8:07 AM Keith Packard  wrote:
> We may want a command line tool that extracts data from the config
> for use by flatpak in building the dynamic configuration, including
> things like salt values per directory. Yeah, that might be made to
> work with flatpak essentially manually overriding the salt configuration
> so that it uses the flatpak-relative names.

Aha. yeah, that's a good idea.

> > This would avoid collision between one and origins. and assuming that
> > flatpaks can load config from host too, we could have:
> >
> > 10-salt.conf (from host):
> > 
>
> I'd leave this out and not have salt in the host.

Sure. though implicit thing may breaks something easily like own salt
affects 'remap-dir' unexpectedly. that should be documented carefully.
or should we have salt attribute in remap-dir and dir elements
instead? that would be obvious.

> The salt here would need to have CDATA for the target directories, and I
> think flatpack wants to split the dynamic from static config bits.
>
> Dynamic (built at runtime):
>
>  /run/host/fonts
>
> Static (built in the flatpak):
>
>  /usr/share/fonts

Yep, that looks good to me.

> I think a dir-reset makes a lot of sense so that the flatpak can control
> the set of font paths used. Building a command-line tool that flatpak
> can use to discover the relevant fontconfig information seems like a
> useful improvement; as I recall, flatpak is currently assuming
> /usr/share/fonts and ~/.fonts are used on the host.
>
> --
> -keith



-- 
Akira TAGOH

Bug#920974: dpkg 1.19.4 FTBFS with t-file test failure

[Frank Schaefer]

Source: dpkg
Version: 1.19.4

When building dpkg-1.19.4 from source via dpkg-buildpackage v1.18.24,
I encountered a test failure:

./t-file .
not ok 23 - strcmp 'this is a test string
Failed 1/26 subtests

This is due to a test_str() against vb.buf in lib/dpkg/t/t-file.c,
where vb.buf is apparently not guaranteed to be NULL-terminated.  I'm
honestly not sure how this test ever passed under these circumstances.

Change the test_str() to "test_mem(vb.buf, ==, ref_data,
strlen(ref_data))", and I get a solid pass.

--
Frank Schaefer
"If a server crashes in a server farm and no one pings it, does it
still cost four figures to fix?"

Bug#920552: Fwd: Bug#920552: procps: Enable regular file and FIFO protection

[Craig Small]

Hi Debian Kernel maintainers,
  I have had a request to add some kernel system configuration lines in for
procps.  What is the planned changes for the kernel? The previous bug
report which got the protection for hard and soft symlinks had a analogous
change occurring in the  kernel too, so it was the same either way and was
added for non-Debian kernel users.

I can't actually see what the Debian systemd people use for sysctl
configuration files, I think they use the procps one so the upstream
systemd-sysctl change won't mean much here.

 - Craig

-- Forwarded message -
From: Frederik Himpe 
Date: Sun, 27 Jan 2019 at 09:15
Subject: Bug#920552: procps: Enable regular file and FIFO protection
To: Debian Bug Tracking System 


Package: procps
Version: 2:3.3.15-2
Severity: normal

In analogy with bug #889098, procps should by default enabling the regular
file
and FIFO protection added in 4.19 by setting:

fs.protected_regular = 1
fs.protected_fifos = 1

This will be done by default in systemd 241, but as Debian does not use
Systemd's sysctl settings, it should be made in procps.

References:
https://github.com/torvalds/linux/commit/30aba6656f
https://github.com/systemd/systemd/commit/2732587540035227fe59e4b64b60127352611b35
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889098



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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-5
ii  libncurses6  6.1+20181013-1
ii  libncursesw6 6.1+20181013-1
ii  libprocps7   2:3.3.15-2
ii  libtinfo66.1+20181013-1
ii  lsb-base 10.2018112800

Versions of packages procps recommends:
ii  psmisc  23.2-1

procps suggests no packages.

-- no debconf information

Bug#920973: advancecomp: advzip seemingly unable to handle large zip files

[Marc Lehmann]

Package: advancecomp
Version: 1.20-1
Severity: normal

Dear Maintainer,

advzip sometimes fails with this error message:

   Failed read end of central directory on 00-archive/20170303.zip

the zip file itself can be handled fine by other utilities.

After experimenting with a number of zip files, it seems this error occurs
for zip files larger than 4GB, probably caused by a 64 bit uncleanlyness
in the code.

This is corrobated by strace'ing it - for example, when running "advzip -2
-z" on a zip file with size 0x1e289f20a, it does a lot of llseeks around
0x0e2896000 before bailing out, which is suspiciously near the lower 3
2bits of the filesize.

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

Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages advancecomp depends on:
ii  libc6   2.28-2
ii  libgcc1 1:8.2.0-13
ii  libstdc++6  8.2.0-13
ii  zlib1g  1:1.2.11.dfsg-1

advancecomp recommends no packages.

advancecomp suggests no packages.

-- no debconf information

Bug#897054: qemu: add support for AMD Zen SMT (Hyperthreading)

[Adam Feng]

I'm not sure what "The developer have impleted differently the AMD patch
but with Qemu 3.0.0/3.1 i don't need this fix." means. Does it mean the
qemu developers have implemented the patch in a different way? Regardless,
qemu 3.1 gives me the following warning,

"(qemu) qemu-system-x86_64: warning: This family of AMD CPU doesn't support
hyperthreading(2)
Please configure -smp options properly or try enabling topoext feature."

I'm trying to run qemu 3.1 on my Threadripper 1950x and that CPU does
indeed support hyperthreading. How do I enable topoext feature like what
the warning message suggests?

Bug#920970: dgit: should ensure .orig is not in the .changes when the .orig is already in DEFERRED

[Sean Whitton]

Hello,

On Wed 30 Jan 2019 at 07:24PM -0700, Sean Whitton wrote:

> When the user passes --delayed, dgit could check
> https://ftp-master.debian.org/deferred/status to see whether the .orig
> is already in DEFERRED, and if so, remove it from the .changes file.
>
> (I was able to work around this by manually qremoving the .orig from the
> changes, resigning the .changes and .dsc, and uploading again; I
> appreciate this kind of messing about is discouraged with dgit, but I
> was keen to avoid another roundtrip with my sponsee.)

Hmm.  After this, with both the -1 and -2 uploads in DEFERRED, I tried
to `dcut cancel` the -1 upload so that I could be sure an ftp-master
would not try to review -1 in the interval before -2's DEFERRED timer
ran out.

This caused queued to delete the .orig.tar, such that, presumably, the
-2 would be REJECTed immediately upon its DEFERRED timer elapsing.
Nice.  I have had to `dcut cancel` the -2 upload too and ask my sponsee
for a -3 changelog entry.

So maybe dgit should simply look at DEFERRED, and if the package is
already there with the same upstream version number, say "you should
`dcut cancel` that upload before pushing this one" to avoid the
situation I got myself into.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920752: gcompris-qt-data: Gcompris Debian version is missing activities found in flatpak version

[Matthew Crews]

On Wed, 30 Jan 2019 13:49:35 +0100 Johnny Jazeix  wrote:
> Hi,
> 
> can you be more precise on which activities are missing?
> 
> Regards,
> 
> Johnny

I can.

Under the Pig (science?) section, the Debian version is missing "Land
Safe" and "Pilot a Submarine"

Under Konqi (Games?) section, the Debian version is missing "Balance Box"

Fortunately, those three seem to be the only ones missing.

Cheers.

-Matt



signature.asc
Description: OpenPGP digital signature

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

control: tag -1 -pending

Hello Birger,

On Wed 30 Jan 2019 at 04:44PM -07, Sean Whitton wrote:

> Pushed to DELAYED/14!

*sigh*

I have been fighting with Debian's upload queue for the past few hours
because I discovered that the -2 upload was not processed.

I was able to get it processed through to DEFERRED through some manual
hacking of the .changes file, but then when I cancelled the -1 upload,
the -2 upload was left in a state that would cause it to be REJECTed 14
days from now (the .orig.tar.gz was removed).

Could you `dch "Try upload again."; dch -r; git commit; git push`,
please?  Then I can try again with a -3 upload.

I would do this myself but I don't have push access to the swaywm-team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920971: freecad: C++ exception on DXF import

[Wookey]

Package: freecad
Version: 0.17+dfsg1-8
Severity: normal
Tags: upstream


I tried to import the file houseplan.dxf
(http://wookware.org/house/houseplan.dxf)
I got this error:
Gui::Command::activated(0): Unknown C++ exception thrown

However I did also get a model containing Shape001 to Shape2829 which
all appear to be individual lines (so that's probably correct as
'Create simple part shapes' was selected in the import preferences
dialog). Not very useful but 'correct' :-)

The exception seems bad though. Possibly this bug should be redirected
to the DXF parsing library, but I'm not sure which one is in use.

Wookey

Bug#920970: dgit: should ensure .orig is not in the .changes when the .orig is already in DEFERRED

[Sean Whitton]

Package: dgit
Version: 8.3

Hello,

1) `dgit push --delayed=14` where that push includes a new .orig, wait for it 
to be processed

2) dch "fix something"; dch -r; git commit -a; dgit sbuild; dgit push 
--delayed=14

This second dgit push will be discarded by queued, because the .orig is
already waiting in DEFERRED:

Jan 30 23:53:42 processing DELAYED/14-day/sway_1.0~beta.2-2_multi.changes
Jan 30 23:53:42 DELAYED/14-day/sway_1.0~beta.2-2_multi.changes is already 
present on target host:
Jan 30 23:53:42 14-day/sway_1.0~beta.2.orig.tar.gz
Jan 30 23:53:42 Job sway_1.0~beta.2-2_multi.changes removed.

When the user passes --delayed, dgit could check
https://ftp-master.debian.org/deferred/status to see whether the .orig
is already in DEFERRED, and if so, remove it from the .changes file.

(I was able to work around this by manually qremoving the .orig from the
changes, resigning the .changes and .dsc, and uploading again; I
appreciate this kind of messing about is discouraged with dgit, but I
was keen to avoid another roundtrip with my sponsee.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920889: clamsmtp: [INTL:ru] Updated Russian translation of debconf template

[Sidorov Dmitriy]

Package: clamsmtp
Severity: wishlist
Tags: l10n patch

Hi,

I don't know why I am in maintain list. I've made some corrections in
translation.

With regards,
Dmitriy Sidorov


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

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

Versions of packages clamsmtp depends on:
ii  adduser3.118
pn  clamav-daemon  
ii  debconf [debconf-2.0]  1.5.70
ii  dpkg   1.19.2
ii  libc6  2.28-5
ii  lsb-base   10.2018112800

Versions of packages clamsmtp recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.92~RC4-3

clamsmtp suggests no packages.


clamsmtp_1.10-17_ru.po
Description: Binary data

Bug#821115: Querido usuario

[Ali Hassan Abdullah Alblushi]

Querido usuario
Su contraseña expirará finalmente hoy Haga clic 
aquí para validar su dirección de 
correo electrónico.
Gracias
Administrador de sistema???

Bug#882395: still seeing this in buster

[Harlan Lieberman-Berg]

tag 882395 +wontfix
thanks

On Thu, 24 Jan 2019 20:48:01 +0100 Hans-Christoph Steiner  wrote:
> I'm still seeing this in buster

Hello!

Yes, this is expected behavior.  Because certbot is intended for
administrators to be relatively hands-off, and especially for
administrators who are not very experienced, certbot will install its
own ciphersuites.  If this is not desired, you can avoid it by not
using the apache plugin for installation, and only using it for
authentication.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920859: libreoffice-kde5: Crash when minimizing file save dialog

[Michael Weghorn]

Hi,

On 30/01/2019 22.34, Rene Engelhard wrote:
> Upstream says:
> 
> 14:44 < _rene_> bubli: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920859. known? (gtk3_kde5)
> 14:45 <@bubli> _rene_: Neven seen before
> 14:49 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has quit [Ping timeout: 
> 268 seconds]
> 14:51 < mst___> caolan, so a) the clipboard locking in VclGtkClipboard looks 
> broken b) since LO 5.3, commit ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60 works 
> around the breakage 
> because my extension here will always hold the SolarMutex now 
> so the main thread doesn't get a chance to run anyway
> 14:52 < IZBot> core - try to avoid the deadlock around the clipboard,  - 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60
> 14:52 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has joined #libreoffice-dev
> 14:55 < michaelweghorn> _rene_: I can reproduce here and can take a look, but 
> probably not before next week

I have created an upstream bug and am currently working on a fix:
https://bugs.documentfoundation.org/show_bug.cgi?id=123077

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#920969: libipc-run3-perl: typo in short description

[Vincent Lefevre]

Package: libipc-run3-perl
Version: 0.048-1
Severity: normal

The short description is

  run a subprocess with input/ouput redirection
  ^

should be "output".

-- 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-2-amd64 (SMP w/8 CPU cores)
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 libipc-run3-perl depends on:
ii  perl  5.28.1-3

libipc-run3-perl recommends no packages.

libipc-run3-perl suggests no packages.

-- no debconf information

Bug#826899: superseded by bug#901365 (inform6-library: Inform6 Library has been updated to 6.12.2)

[Ben Finney]

Control: notfound 901365 6.12~dfsg.1
Control: found 901365 inform6-library/6.12~dfsg.1-1
Control: merge 901365 -1
Control: severity -1 wishlist

On 09-Jun-2016, David Griffith wrote:

> I released version 6.12.1 of the Inform 6 Standard Library a couple days 
> ago.

This is superseded by the later report of upstream version “6.12.2”,
in Debian bug#901365. I am merging these two bug reports.

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\ so, Brain, but first you'd have to take that whole bridge |
_o__) apart, wouldn't you?” —_Pinky and The Brain_ |
Ben Finney 

Bug#920968: libdata-uniqid-perl: typo in short description

[Vincent Lefevre]

Package: libdata-uniqid-perl
Version: 0.12-1
Severity: normal

The short description is:

  Perl extension for simple genrating of unique id's
^

First, the second "e" is missing. Then I don't think "generating" is
correct; it should be "generation".

-- 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-2-amd64 (SMP w/8 CPU cores)
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 libdata-uniqid-perl depends on:
ii  perl  5.28.1-3

libdata-uniqid-perl recommends no packages.

libdata-uniqid-perl suggests no packages.

-- no debconf information

Bug#920967: RFS: dvdisaster/0.79.6-3

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: dvdisaster
   Version : 0.79.6-3
   Upstream Author : Carsten Gnörlich 
 * URL : 
https://web.archive.org/web/20180428070843/http://dvdisaster.net/
 * License : GPL-3+
   Section : otherosfs

  It builds these binary packages:

disaster - data loss/scratch/aging protection for CD/DVD media
dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media 
(documentation)

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

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


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

dget -ux 
https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.6-3.dsc

  This release is for experimental.

  Changes since the last upload:

  dvdisaster (0.79.6-3) experimental; urgency=medium

* Merge changes from 0.79.5-7.
* Update gbp.conf for debian/experimental branch.

   -- Carlos Maddela   Thu, 31 Jan 2019 08:59:58 +1100


  Regards,
   Carlos Maddela

Bug#920741: check-all-the-things: "sh: 1: sh: file: not found"

[Paul Wise]

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 
https://github.com/collab-qa/check-all-the-things/commit/339048536a81ac5f41b52146446de1e8c8a93270

On Wed, 2019-01-30 at 14:57 +0100, Jakub Wilk wrote:
> * Paul Wise , 2019-01-29, 08:29:
> > Where do you think the check should happen and what should happen?
> > 
> > * At the same time as checking for the magic module
> >* Error out
> 
> I think this would be the best.

Implemented.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#920966: RFS: dvdisaster/0.79.5-7

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: dvdisaster
   Version : 0.79.5-7
   Upstream Author : Carsten Gnörlich 
 * URL : 
https://web.archive.org/web/20180428070843/http://dvdisaster.net/
 * License : GPL-3+
   Section : otherosfs

  It builds these binary packages:

disaster - data loss/scratch/aging protection for CD/DVD media
dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media 
(documentation)

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

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


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

dget -ux 
https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.5-7.dsc

  Changes since the last upload:

  * Add debian/gbp.conf to conform with DEP14 conventions.
  * Build with Debhelper compat level 12.
  * Set "Rules-Requires-Root: no".
  * Simplify process by which mutable files are backed up and restored.
  * Build as verbosely as possible.
  * Fix location of manual.
  * Fix dh_auto_build overrides to take advantage of parallel builds.
  * Fix format security compilation warning in GCC-8.
  * Change homepage to one archived at web.archive.org.
http://dvdisaster.net has been unavailable for a while now.
Not certain if this is permanent though, as the domain name still
exists for mail.
  * Add support for nodoc build profile.
  * Add more details to upstream metadata.
  * Indicate compliance with Debian Policy 4.3.0.


  Regards,
   Carlos Maddela

Bug#915426: git breaks git-remote-hg autopkgtest

[Jonathan Nieder]

Hi again,

On 25 January 2019, Jonathan McCrohan wrote:

> I am happy to work on fixing up the FTBFS, but
> because I am not a DD, I would need a sponsor to upload for me.

I'm happy to sponsor an upload, especially if this is a first step
toward team maintenance with Jonas (who I can speak from experience in
saying is a very pleasant person to collaborate with) and that upload
removes me from Uploaders.  It's the least I can do. :)

If you run into any trouble, just ask.

Thanks,
Jonathan

Bug#920360: certbot: does not work if python is set to python3 in update-alternatives

[Harlan Lieberman-Berg]

tag 920360 +moreinfo -d-i
thanks

On Thu, Jan 24, 2019 at 1:06 PM Pascal Grafe  wrote:
> Package does not install/work if python is set to python3 in update-
> alternatives.

Hello!  Can you please provide the error that you're experiencing?
/usr/bin/certbot directly invokes /usr/bin/python3 with the shebang,
so what /usr/bin/python is set to shouldn't matter.  (Additionally,
I've tested it and it appears to still work even if it is set that
way.)

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920565: certbot modifies /etc/letsencrypt everytime certbot is executed.

[Harlan Lieberman-Berg]

tag 920565 +upstream
severity 920565 minor
forwarded 920565 https://github.com/certbot/certbot/issues/6726
thanks

On Sat, Jan 26, 2019 at 8:57 PM Jim Popovitch  wrote:
> It is recommended (citation needed!) to not modify files/dirs in /etc/
> every time a cmd is executed, rather only when config files are
> modified.

Sent this one upstream!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#888903: jsbeautifier,node-js-beautify: both ship /usr/bin/js-beautify

[Jérémy Lal]

Package: node-js-beautify
Version: 1.7.5+dfsg-1
Followup-For: Bug #888903

Hi,

i find it funny that no one even tried to solve this bug:
both packages (python-jsbeautifier, node-js-beautify)
have the same upstream !
The solution here is to provide two dpkg-alternative to
/usr/bin/js-beautify.

It's blocking postcss, it would be nice to quickly fix this.

Jérémy

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

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

Versions of packages node-js-beautify depends on:
ii  node-config-chain  1.1.11-1
ii  node-mkdirp0.5.1-1
ii  node-nopt  3.0.6-3
ii  nodejs 10.15.1~dfsg-1

node-js-beautify recommends no packages.

node-js-beautify suggests no packages.

Bug#920895: certbot: post-hook command: service apache2 stop

[Harlan Lieberman-Berg]

On Wed, Jan 30, 2019 at 6:24 AM Xavier Bestel  wrote:
> Certbot says it will stop apache after renewing certificates (although 
> apparently it doesn't).

Hello!

Very strange.  What is in your /etc/letsencrypt/renewal-hooks
sub-directories?  Does `grep hook
/etc/letsencrypt/renewal/awak.mobi.conf` return any rows?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920957: linux-image-4.9.0-8-amd64: USB HID devices disconnect and reregister frequently

[agent]

I'll check latest on Saturday, maybe earlier.Regards,Michael


Von meinem Samsung Galaxy Smartphone gesendet.
 Ursprüngliche Nachricht Von: Salvatore Bonaccorso 
 Datum: 30.01.19  23:35  (GMT+01:00) An: Michael Fischer 
, 920...@bugs.debian.org Betreff: Re: Bug#920957: 
linux-image-4.9.0-8-amd64: USB HID devices
  disconnect and reregister frequently 
Hi Michael,

On Wed, Jan 30, 2019 at 11:02:30PM +0100, Michael Fischer wrote:
> Package: src:linux
> Version: 4.9.130-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> Having USB keyboard and/or USB mouse connected leads to the problem.
> Same is true on three other systems, running 686-pae or 686 with the
> same kernel version Installing linux-image-4.19.0-0.bpo.1-amd64
> fixes the problem reliably. Also in case of 686 or 686-pae kernels

Can you confirm, does the issue still persist as well with the
4.9.144-2 version currently pending in proposed-updates (and to be
included in the next point release)?

Regards,
Salvatore

Bug#920964: pcsx2: Can't map DualShock 3 if using backported linux-image

[N G]

Package: pcsx2
Version: 1.4.0+dfsg-2
Severity: normal

Dear Maintainer,

When using linux-image 4.9 from stable repositories PCSX2 recognizes correctly
the dualshock 3:  PLAYSTATION(R)3 Controller - but 19, axes: 27, hats: 0

While when using any kernel from backports (at the moment 4.19) it's recognized
wrong:  PLAYSTATION(R)3 Controller - but 17, axes: 6, hats: 0

I've been having this issue with every linux-image from backports.  It seems to
be only working with the default linux-image. I was wondering if there's a
workaround for Debian 9.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



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

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

Versions of packages pcsx2 depends on:
ii  libaio1 0.3.110-3
ii  libasound2  1.1.3-5
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libgl1  1.1.0-1~bpo9+1
ii  libgl1-mesa-glx 18.2.8-2~bpo9+1
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  liblzma55.2.2-1.2+b1
ii  libpng16-16 1.6.28-1
ii  libportaudio2   19.6.0-1
ii  libsdl2-2.0-0   2.0.5+dfsg1-2
ii  libsoundtouch1  1.9.2-2+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libwxbase3.0-0v53.0.4+dfsg-4~bpo9+1
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4~bpo9+1
ii  libx11-62:1.6.4-3+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages pcsx2 recommends:
ii  libasound2-plugins  1.1.1-1
ii  libc6 [libc6-i686]  2.24-11+deb9u3

pcsx2 suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: package pcsx2 is not installed

Bug#920776: sparse: new upstream release

[Jonathan Nieder]

Uwe Kleine-König wrote:

>  sparse (0.6.0-1) unstable; urgency=medium
>  .
>* New upstream version (Closes: #920776)

Wonderful.  Thanks for your quick work.

Jonathan

Bug#920963: dh-runit: copy-edits to dh_runit(1) manpage

[Jonathan Nieder]

Package: dh-runit
Version: 2.8.3
Severity: minor
Justification: documentation

Reading the dh_runit(1) manpage, I ran into a few small nits that
made it harder to read.  Mostly:

- some missing or extra articles ("a" or "the")
- F<> markup showing up in list items
- some word usage nits (e.g. "different" meaning "various" and so on)

A patch follows with some suggested edits.  I'm happy to explain any
details that seem unclear and I won't be hurt if you clear up the text
in a different way.  I'm cc-ing debian-l10n-english since they tend to
be very good at this kind of editing for readability.

debian-l10n-english: you can find the source file in dh_runit in
https://salsa.debian.org/runit-team/dh-runit.git, and you can preview
the output by running "perldoc ./dh_runit".

Thoughts of all kinds welcome, as always.

diff --git a/debian/changelog b/debian/changelog
index 5facc36..431b3e7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-runit (2.8.4) UNRELEASED; urgency=medium
+
+  * Copy-edit dh_runit(1) documentation.
+
+ -- Jonathan Nieder   Wed, 30 Jan 2019 15:44:58 -0800
+
 dh-runit (2.8.3) unstable; urgency=medium
 
   * Document runit:Breaks substitution variable
diff --git a/dh_runit b/dh_runit
index 447ae70..7baad5f 100755
--- a/dh_runit
+++ b/dh_runit
@@ -122,77 +122,80 @@ B [S>] [I 
I] ...
 =head1 DESCRIPTION
 
 B is a debhelper program that is responsible for
-installing and enabling I runscripts. If file named
-F.runit> exists, then different actions
-are performed, depending on its format.
+installing and enabling I runscripts. If a file named
+F.runit> exists, then it ensures appropriate actions
+are performed based on its content.
 
-For runit, every unit of supervision, simply speaking program, is
-represented by directory under F, containing at least F
-executable file. Every enabled program is represented by symbolic link
-under F (which itself is symbolic link to
+For runit, each unit of supervision (or, simply speaking, program) is
+represented by a directory under F, containing at least a F
+executable file. Each enabled unit of supervision is represented by a
+symbolic link under F (which itself is a symbolic link to
 F) pointing to some directory under
 F.
 
-B reads it's arguments from command line and
-F.runit> by two, with first one being an
-file/directory and second one is options. If first argument is file,
-it is considered 'run' script, and it is installed under
-F, executable bit is added. If first argument is
-directory, it is copied as whole under F.
+B reads arguments from the command line and
+F.runit> in pairs, with the first item being the
+path to a file or directory and the second being a set of options.
+If the first argument names a file, it is treated as a 'run' script
+to be installed at F as an executable file. If the first
+argument names a directory, that directory is copied as a whole to
+F.
 
-Options are comma-separated, like to mount. Unsupported option
-is error, following are supported:
+Options are comma separated, like mount options. Unrecognized options
+are errors. The following options are recognized:
 
 =over
 
 =item I
 
-With this option, runscript is installed, but not enabled by
-default. It means that corresponding service will not be started.
-System administrator can always do it manually or via
-update-service(8).
+Install the runscript but do not enable it by default.
+This means that the corresponding service will not be started.
+The service can be enabled manually by the system administrator or
+automatically using update-service(8).
 
 =item I=preferred-name
 
-By default, name of directory under F for given runscript
-is basename of first argument of pair. This option allows you to
-be explicit about it.
+By default, the name of the directory under F for a given
+runscript is the basename of the path argument naming it. This
+option allows overriding that default with an explicitly chosen
+directory name.
 
 =item I
 
-Install standard F script, which invokes svlogd(8) with
-rights of dedicated user. It is error, if first argument in pair
-is directory, which already contains F script.
+Install a standard F script that invokes svlogd(8) with
+the rights of the dedicated user. Specifying this option produces
+an error if the path argument names a directory that already
+contains a F script.
 
 =item I
 
-If you need no other options, put this one.
+If you don't need other options, specify this one.
 
 =back
 
 =head1 SUBSTITUTION VARIABLES
 
-Package, created with help of B does not depends on B,
-but should add I variable into I field in 
I
-to ensure, that no breakages are caused by too old version of B package.
+Packages using B do not depend on B but should include the
+I variable in their I field in I
+to ensure that no breakages are caused by a too-old version of B 
package.
 
 =head1 EXAMPLES
 
-This section contains several example snippets from F.runit>
+This 

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

control: tag -1 +pending

Hello Birger,

On Wed 30 Jan 2019 at 11:31PM +01, Birger Schacht wrote:

> Argl, I'm sorry for having overlooked this

Well, me too :)

>> Could you make this change as a -2 upload, please?  Since I have already
>> pushed the -1, it is cleaner to do it that way.
> Yes, fixed and pushed in 0a31ddda to salsa

Pushed to DELAYED/14!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920938: autopkgtests fail with: Cannot open input file: No such file or directory

[Iain Lane]

Hi,

You're giving the tests the wrong input filename - that is a bug in
pcapfix (the tests weren't updated for the .pcap move).

The second thing is that returning 254 on errors breaks autopkgtest, so
it would be good if you could change exit codes 128 < code < 255 into
one below 128. That's arguably an autopkgtest bug, so you might not want
to fix it, but if you do it will help the testers.

Cheers,
Iain

On Wed, Jan 30, 2019 at 07:06:47PM +0100, Robert Krause wrote:
> Hi Iain,
> 
> thank you for this bug report.
> 
> Did I get it right that is a bug in the tool (pcapfix) itself and not the
> testing process?
> 
> I am a bit confused, since I did not change any return codes since version
> 1.1.4.
> Nevertheless it is correct, that pcapfix returns negative numbers in case of
> errors.
> I can fix this and turn them positive if this will make autopkgtest work
> again.
> 
> Is "no such file" also a bug of pcapfix or is it the test case. I checked
> file opening function and process and it works on my system.
> 
> Thanks in advance.
> 
> Cheers,
> Robert
> 
> On 2019-01-30 18:48, Iain Lane wrote:
> > Package: src:pcapfix
> > Version: 1.1.4-1
> > Severity: normal
> > 
> > Hi,
> > 
> >   Removing autopkgtest-satdep (0) ...
> >   autopkgtest [15:14:06]: test command1: pcapfix
> > debian/test/test_2018.pcap
> >   autopkgtest [15:14:06]: test command1: [---
> >   [-] Cannot open input file: No such file or directory
> >   pcapfix 1.1.4 (c) 2012-2019 Robert Krause
> > 
> >   [*] Reading from file: debian/test/test_2018.pcap
> >   autopkgtest [15:14:07]: ERROR: testbed failure: testbed auxverb
> > failed with exit code 254
> > 
> > The path to the .pcap file is wrong since 1.1.4-1.
> > 
> > In addition, the last line shows that the exit status of the test
> > command is making autopkgtest think that *it* failed rather than the
> > test command. It only supports exit 0-125 - is there any chance you
> > could chop off any larger exit codes please? In a script, something like
> > (untested)
> > 
> >   #!/bin/sh
> >   pcapfix ...; RC=$?
> >   if [ "${RC}" -gt 125 ]; then
> > RC=125
> >   fi
> >   exit ${RC}
> > 
> > (The closest bit of documentation I can find for this is in [0]:
> > 
> >   program's exit status will be that of the testbed command if the
> >   latter exits with a value from 0..125.
> > 
> >   ...
> > 
> >   If program fails it will exit 254 or 255
> > 
> > Where "program" is not the test program: it is an autopkgtest-internal
> > program to execute a given command inside the testbed.)
> > 
> > Thanks!

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#920962: aptitude: couldn't install both gcc-8-base:i386 and :amd64

[Jiri Palecek]

Package: aptitude
Version: 0.8.11-6
Severity: normal

Dear Maintainer,

I was installing a clean (buster) system from amd64 archive, but also
wanted to install wine32. However, this package only exists in i386 so I
added the architecture and selected wine32 in aptitude. However, it
didn't allow me to continue and the resolver couldn't find any
resolution. Upon investigation, the situation was like this:

 - the conflict was around gcc-8-base
 - gcc-8-base:amd64 was out of date and needed to be upgraded
 - gcc-8-base breaks gcc-8-base of any other version
 - this constraint was making the resolver unhappy, and even upgrading
   gcc-8-base:amd64 to the same version as newly installed
   gcc-8-base:i386 didn't flag this dependency as satisfied (ie. there
   was still conflict)

Installing the package with "apt install wine32" wen't without any
problems.

Regards
Jiri Palecek

-- Package-specific info:
Terminal: eterm-color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-gate.so.1 (0xb7f96000)
libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 
(0xb7922000)
libncursesw.so.6 => /lib/i386-linux-gnu/libncursesw.so.6 (0xb78e)
libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xb78b7000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 
(0xb78af000)
libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xb77a2000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb766c000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/i386-linux-gnu/libboost_iostreams.so.1.67.0 (0xb765)
libboost_system.so.1.67.0 => 
/usr/lib/i386-linux-gnu/libboost_system.so.1.67.0 (0xb7649000)
libxapian.so.30 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.30 
(0xb7402000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb73e1000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb726)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb715a000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb713c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6f5e000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb6f44000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6f25000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb6f12000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb6ee6000)
liblz4.so.1 => /usr/lib/i386-linux-gnu/liblz4.so.1 (0xb6ec6000)
libzstd.so.1 => /usr/lib/i386-linux-gnu/libzstd.so.1 (0xb6e2d000)
libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb6e06000)
/lib/ld-linux.so.2 (0xb7f97000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6dfe000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6df4000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb6dea000)

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.20.0-trunk-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-6
ii  libapt-pkg5.0 1.8.0~beta1
ii  libboost-iostreams1.67.0  1.67.0-10
ii  libboost-system1.67.0 1.67.0-10
ii  libc6 2.28-4
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-15
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.1-1
ii  libsqlite3-0  3.26.0+fossilbc891ac6b-1
ii  libstdc++68.2.0-15
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.9-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
pn  tasksel 

-- no debconf information

Bug#917864: closed by Gianfranco Costamagna (Re: Fails to build for non-current kernel version)

[Ben Hutchings]

On Wed, 2019-01-30 at 16:03 +0100, Gianfranco Costamagna wrote:
> Hello Ben,
> > The bug is in the makefile you provide to module-assistant.
> 
> I'm sorry but I have no clue about how to fix it...
> Can you please help me in fixing the issue?

In debian/virtualbox-guest-source.files/rules/, you call the kernel
build system like this:

$(MAKE) -C $(KSRC) M=$(CURDIR)

But in the clean rule, you call the upstream Makefiles directly, and
they try to use the kernel build scripts for the running kernel.  You
should probably use something like:

$(MAKE) -C $(KSRC) M=$(CURDIR) clean

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path.

Or, more likely, no salt at all for the outermost layer as it doesn't
really add anything here.

> for flatpak case, they want to have a global salt to
> change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set
> salt from host in 'remap-dir' to build cache filenames on host (for
> /run/host/fonts and so on).

We may want a command line tool that extracts data from the config
for use by flatpak in building the dynamic configuration, including
things like salt values per directory. Yeah, that might be made to
work with flatpak essentially manually overriding the salt configuration
so that it uses the flatpak-relative names.

> This would avoid collision between one and origins. and assuming that
> flatpaks can load config from host too, we could have:
>
> 10-salt.conf (from host):
> 

I'd leave this out and not have salt in the host.

> 50-flatpak.conf (sandbox specific):
> /run/host/fonts
> 
> /usr/share/fonts

The salt here would need to have CDATA for the target directories, and I
think flatpack wants to split the dynamic from static config bits.

Dynamic (built at runtime):

 /run/host/fonts
 
Static (built in the flatpak):

 /usr/share/fonts



>
> First salt element affects to 'remap-dir' and second one overrides it
> for paths and change a salt in sandbox.

I think we can put that into the remap-dir element as both of those 
are built at runtime?

> To make things easier, we may also want to export all of dir elements
> from fonts.conf to the separate file. flatpak can replace it with
> 50-flatpak.conf in this case. or the file operation isn't desirable,
> let's implement dir-reset element or something like that.

I think a dir-reset makes a lot of sense so that the flatpak can control
the set of font paths used. Building a command-line tool that flatpak
can use to discover the relevant fontconfig information seems like a
useful improvement; as I recall, flatpak is currently assuming
/usr/share/fonts and ~/.fonts are used on the host.

-- 
-keith


signature.asc
Description: PGP signature

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Julian Gilbey]

On Wed, Jan 30, 2019 at 11:27:51PM +0100, Hilmar Preuße wrote:
> On 30.01.19 12:52, Julian Gilbey wrote:
> 
> Hi Julian,
> 
> > Interesting!  It turns out that on my system, PostScript files are
> > opened in Inkscape (due to bug#902141), and Inkscape gives the error
> > message:
> > 
> > ps2pdf failed:
> > 
> > Error: /undefinedfilename in (/tmp/texdoc.kS0Odf/ifsym.ps)
> > 
> > etc.
> > 
> > I set the system up to use gv instead, and was told:
> > 
> > gv: Cannot open file /tmp/texdoc.2e0sf6/ifsym.ps (No such file or directory)
> > 
> > So I guess the bug is still there
> > 
> OK, I always just tried to reproduce on unstable w/o GNOME, as I don't
> have an unstable system running GNOME. Today I tried on stable/GNOME and
> could reproduce the issue. Do you run GNOME/unstable?

I'm running XFCE/testing, hence using xdg-open rather than
gnome-open.  But the result is the same.

> The code you mentioned initially now looks completely different. The
> view.tlu did not change much between stable and unstable. When comparing
> the code between unstable & git I don't see essential changes, so I'd
> suspect that the issue is also available in git. Further I don't see git
> commits for this topic in the last 1/2 year.

Yes, indeed.  I haven't looked at the view.tlu code recently, but it
still appears to be texdoc which is doing the unzipping.

> @Norbert: are you aware of the issue? Should we simply open a new issue
> for investigation?

Best wishes,

   Julian

Bug#920961: dansguardian: Add support fort clamav 0.101.0

[Sebastian Andrzej Siewior]

Source: dansguardian
Version: 2.10.1.1-5.1
Severity: important
Tags: patch

The patch attached lets python-clamav compile against clamav from
experimental (it does not compile unstable anymore).

Sebastian
From: Sebastian Andrzej Siewior 
Date: Wed, 30 Jan 2019 23:53:48 +0100
Subject: [PATCH] dansguardian: Add clamav 0.101.0 support

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/contentscanners/clamav.cpp | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/contentscanners/clamav.cpp b/src/contentscanners/clamav.cpp
index cb5e5be1b3fc..55ad90fdb13d 100644
--- a/src/contentscanners/clamav.cpp
+++ b/src/contentscanners/clamav.cpp
@@ -131,6 +131,7 @@ int clamavinstance::scanMemory(HTTPHeader * requestheader, HTTPHeader * docheade
 	const char *vn = NULL;
 	int fd;
 	std::string fname;
+	struct cl_scan_options scan_options;
 
 #ifdef HAVE_CLAMAV_SHM
 	if (use_shm) {
@@ -172,7 +173,11 @@ int clamavinstance::scanMemory(HTTPHeader * requestheader, HTTPHeader * docheade
 	}
 
 #ifdef CL_INIT_DEFAULT
-	rc = cl_scandesc(fd, , NULL, engine, CL_SCAN_STDOPT);
+	memset(_options, 0, sizeof(scan_options));
+	scan_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+	scan_options.parse = ~0;
+
+	rc = cl_scandesc(fd, NULL, , NULL, engine, _options);
 #else
 	rc = cl_scandesc(fd, , NULL, engine, , CL_SCAN_STDOPT);
 #endif
@@ -201,7 +206,13 @@ int clamavinstance::scanFile(HTTPHeader * requestheader, HTTPHeader * docheader,
 	lastmessage = lastvirusname = "";
 	const char *vn = NULL;
 #ifdef CL_INIT_DEFAULT
-	int rc = cl_scanfile(filename, , NULL, engine, CL_SCAN_STDOPT );
+	struct cl_scan_options scan_options;
+	int rc;
+
+	memset(_options, 0, sizeof(scan_options));
+	scan_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+	scan_options.parse = ~0;
+	rc = cl_scanfile(filename, , NULL, engine, _options);
 #else
 	int rc = cl_scanfile(filename, , NULL, engine, , CL_SCAN_STDOPT );
 #endif
-- 
2.11.0

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Felipe Sateler]

On Wed, Jan 30, 2019 at 7:47 PM Axel Beckert  wrote:

> Hi Felipe,
>
> a short reply with that information I can gather without much effort:
>
> Felipe Sateler wrote:
> > > But we also had reports where this happend
> > > with systemd, so this doesn't seem to be depend on the init system (at
> > > most at the init system's default features) and hence also the package
> > > cgroupfs-mount can't be held guilty for this.
> >
> > Can you point me at one? (sorry, I'm late to this bug and currently
> ENOTIME
> > to read the entire backlog). It seems this should not happen on systemd
> > systems, because systemd properly isolates udev to its own cgroup when
> > starting.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764#122


Ah, thanks. That example is running with systemd as pid1, but not running
udev as a systemd-managed daemon. This is good, because it means the
diagnosis has not been refuted.

-- 

Saludos,
Felipe Sateler

Bug#907297: breeze-gtk-theme: Breaks xfce4-notes (invalid string constant in "/usr/share/themes/Breeze/gtk-2.0/widgets/styles")

[Dmitry Smirnov]

On Thursday, 31 January 2019 8:19:38 AM AEDT Maximiliano Curia wrote:
> I couldn't reproduce the issue, executing xfce4-notes shows no errors in
> the termianl and it seems to be working fine, this of course, while using
> the breeze theme.

Interestingly enough this issue is very persistent and it existed for a long 
time. Yesterday I've opened #920876 only to realize that I've already 
reported that as #907297 earlier...


> Is there anything special about your setup that could
> somehow caused that the other files in
> /usr/share/themes/Breeze/gtk-2.0/widgets/ directory could not be loaded? A
> limit on the number of open files, perhaps?

Nothing like this, I can't think of anything special.
I've observed this problem on two installations under Cinnamon...

In both cases I had to uninstall "breeze-gtk-theme".

Do you think Breaks/Conflicts could be declared between "breeze-gtk-theme" 
and "xfce4-notes"?

-- 
Cheers,
 Dmitry Smirnov.

---

Free speech is the bedrock of liberty and a free society. And yes, it
includes the right to blaspheme and offend.
-- Ayaan Hirsi Ali, 2010


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

Bug#920858: [Pkg-javascript-devel] Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Jonas Smedegaard]

Quoting Xavier (2019-01-30 22:54:53)
> Le 30/01/2019 à 22:34, Jonas Smedegaard a écrit :
> > Quoting Xavier (2019-01-30 22:26:57)
> >> Le 29/01/2019 à 22:17, Jonas Smedegaard a écrit :
> >>> Source package contains below  several files embedding code 
> >>> from external project fileOverview Kickass, without source 
> >>> included.

Just a clarification: Name of external project is Popper.js: 
"fileOverview" is just a marker, and "Kickass" is first word of 
Popper.js short description.


> >> I succeed to build source, but this needs:
> > [snip]
> > 
> > This bugreport tracks twitter-bootstrap4 violating Policy in 
> > shipping code without source.
> > 
> > For discussing packaging of that source in a separate package, 
> > please file an ITP bugreport (or an RFP bugreport if you don't 
> > intent on doing the work yourself), and let's discuss packaging 
> > issues there.

> Also is it OK if I remove dist/bootstrap.bundle.* in Files-Excluded ?

Sorry, I don't understand your question.

What do you mean by "also"?  Did I miss some previous conversation that 
this is an addition of?

Are you asking if it is ok to violate Debian Policy here?  Or is your 
question a different one? Please try rephrase...


> Note that "fileOverview Kickass" is provided by popper.js

It seems it _is_ Popper.js - see above.


 - 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#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Axel Beckert]

Hi Felipe,

a short reply with that information I can gather without much effort:

Felipe Sateler wrote:
> > But we also had reports where this happend
> > with systemd, so this doesn't seem to be depend on the init system (at
> > most at the init system's default features) and hence also the package
> > cgroupfs-mount can't be held guilty for this.
> 
> Can you point me at one? (sorry, I'm late to this bug and currently ENOTIME
> to read the entire backlog). It seems this should not happen on systemd
> systems, because systemd properly isolates udev to its own cgroup when
> starting.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764#122

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#920960: libreoffice: recommends obsolete metapackage fonts-noto-hinted

[Gabriele Stilli]

Package: libreoffice
Version: 1:6.1.5~rc1-2
Severity: minor

Hi,

libreoffice recommends fonts-noto-hinted which, by its own description,
is an obsolete metapackage depending on fonts-noto-{,ui-}core.

It's probably a good idea to depend on current packages.

Kind regards,
Gabriele Stilli

Bug#920942: transition: libfm-qt

[Lisandro Damián Nicanor Pérez Meyer]

Even if I am an indirect user of lxqt but considering my Qt maintainer hat, 
looking at the changelog and the few packages involved: please consider an 
exception for this case. Our stable users will really appreciate it.

Thanks for considering it, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#920928: [Pkg-fonts-devel] Bug#920928: fonts-ibm-plex: doesn't clean up legacy files

[Christoph Anton Mitterer]

On Wed, 2019-01-30 at 20:37 +0100, Fabian Greffrath wrote:
> Apparently this is a leftover of fontconfig registering this font. My
> file system is full of directories like this.

Hmm could be... but packages should then clean this up properly and not
leave behind stale legacy files/dirs forever :-)

And if it affects all font-packages, then all should do so.


Cheers,
Chris.

Bug#920957: linux-image-4.9.0-8-amd64: USB HID devices disconnect and reregister frequently

[Salvatore Bonaccorso]

Hi Michael,

On Wed, Jan 30, 2019 at 11:02:30PM +0100, Michael Fischer wrote:
> Package: src:linux
> Version: 4.9.130-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> Having USB keyboard and/or USB mouse connected leads to the problem.
> Same is true on three other systems, running 686-pae or 686 with the
> same kernel version Installing linux-image-4.19.0-0.bpo.1-amd64
> fixes the problem reliably. Also in case of 686 or 686-pae kernels

Can you confirm, does the issue still persist as well with the
4.9.144-2 version currently pending in proposed-updates (and to be
included in the next point release)?

Regards,
Salvatore

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Hilmar Preuße]

On 30.01.19 12:52, Julian Gilbey wrote:

Hi Julian,

> Interesting!  It turns out that on my system, PostScript files are
> opened in Inkscape (due to bug#902141), and Inkscape gives the error
> message:
> 
> ps2pdf failed:
> 
> Error: /undefinedfilename in (/tmp/texdoc.kS0Odf/ifsym.ps)
> 
> etc.
> 
> I set the system up to use gv instead, and was told:
> 
> gv: Cannot open file /tmp/texdoc.2e0sf6/ifsym.ps (No such file or directory)
> 
> So I guess the bug is still there
> 
OK, I always just tried to reproduce on unstable w/o GNOME, as I don't
have an unstable system running GNOME. Today I tried on stable/GNOME and
could reproduce the issue. Do you run GNOME/unstable?

The code you mentioned initially now looks completely different. The
view.tlu did not change much between stable and unstable. When comparing
the code between unstable & git I don't see essential changes, so I'd
suspect that the issue is also available in git. Further I don't see git
commits for this topic in the last 1/2 year.

@Norbert: are you aware of the issue? Should we simply open a new issue
for investigation?

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



signature.asc
Description: OpenPGP digital signature

Bug#821397: intent to sponsor an upload to NEW

[Birger Schacht]

Hi,

On 1/30/19 10:46 PM, Sean Whitton wrote:
> control: tag -1 -pending
> 
> Hello,
> 
> On Wed 30 Jan 2019 at 02:42PM -07, Sean Whitton wrote:
> 
>> Thank you.  I've pushed it to DELAYED/14, after which it will land in
>> the NEW queue.
> 
> Er.  After doing this, I immediately discovered this error in
> d/copyright:
> 
> License: LGPL-2.1-or-later
> 
> should be
> 
> License: LGPL-2.1+
Argl, I'm sorry for having overlooked this

> Could you make this change as a -2 upload, please?  Since I have already
> pushed the -1, it is cleaner to do it that way.
Yes, fixed and pushed in 0a31ddda to salsa

Thanks and cheers,
Birger

> 
> Sorry, all, for the noise.
> 

Bug#920959: python-clamav: Add support fort clamav 0.101.0

[Sebastian Andrzej Siewior]

Source: python-clamav
Version: 0.4.1-8
Severity: important
Tags: patch

The patch attached lets python-clamav compile against clamav from
experimental (it does not compile unstable anymore).

Sebastian
From: Sebastian Andrzej Siewior 
Date: Wed, 30 Jan 2019 23:22:55 +0100
Subject: [PATCH] python-clamav: add support for clamav 0.101.0

CL_SCAN_GENERAL_ALLMATCHES with all parses should do what CL_SCAN_STDOPT
did.

Signed-off-by: Sebastian Andrzej Siewior 
---
 pyclamav.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/pyclamav.c b/pyclamav.c
index 7ccd57239b97..0315c62ea81a 100644
--- a/pyclamav.c
+++ b/pyclamav.c
@@ -191,6 +191,7 @@ static PyObject *pyclamav_scanfile(PyObject *self, PyObject *args)
   char *file_to_scan;
   unsigned long int size = 0;
   const char *virname;
+  struct cl_scan_options scan_options;
   int ret = 0;
 
   /* Raise exception if database error */
@@ -209,8 +210,11 @@ static PyObject *pyclamav_scanfile(PyObject *self, PyObject *args)
 PyErr_SetString(PyExc_ValueError,  "Argument is not a filename");
 return NULL; 
   }
+  memset(_options, 0, sizeof(scan_options));
+  scan_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+  scan_options.parse = ~0;
 
-  ret = cl_scanfile(file_to_scan, , , engine, CL_SCAN_STDOPT);
+  ret = cl_scanfile(file_to_scan, , , engine, _options);
 
   /* Test return code */
   switch (ret) {
-- 
2.11.0

Bug#920956: ITP: fonts-recommended -- set of recommended fonts

[Keith Packard]

Adam Borowski  writes:

> Fonts people: as the first stab, I'll upload my picks with Fabian's input,
> then let's have a flamewar.

Can you point us at the proposed list?

-- 
-keith


signature.asc
Description: PGP signature

Bug#920958: rust-ripgrep build-dependencies unsatisfiable in testing

[peter green]

Package: rust-ripgrep
Version: 0.9.0-4


The following packages have unmet dependencies:
 builddeps:rust-ripgrep : Depends: librust-bytecount-0.3+default-dev (>= 
0.3.1~~) but it is not installable
  Depends: librust-memmap-0.6+default-dev but it is not 
installable


This appears to be fixed in unstable, but unfortunately there are other issues 
preventing unstable's version from migrating to testing.

Bug#920486: CVE-2018-20685 and CVE-2019-6111 for netkit-rsh

[Salvatore Bonaccorso]

Hi,

>  netkit-rsh (0.17-20) unstable; urgency=medium
>  .
>* Fix CVE-2018-20685 and CVE-2019-6111. (Closes: #920486)
>  Thanks Hiroyuki YAMAMORI for the heads up.

FTR, I have asked MITRE if those two CVEs should be used as well for
netkit-rsh or if it would need two new CVEs.

Regards,
Salvatore

Bug#920957: linux-image-4.9.0-8-amd64: USB HID devices disconnect and reregister frequently

[Michael Fischer]

Package: src:linux
Version: 4.9.130-2
Severity: important
Tags: upstream

Dear Maintainer,

Having USB keyboard and/or USB mouse connected leads to the problem. Same is 
true on three other
systems, running 686-pae or 686 with the same kernel version
Installing linux-image-4.19.0-0.bpo.1-amd64 fixes the problem reliably. Also in 
case of 686 or
686-pae kernels


-- Package-specific info:
** Version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 
root=UUID=746870cc-290f-4be3-aafa-d2749b200e8c ro bootdegraded=true

** Not tainted

** Kernel log:
[   12.970272] Bluetooth: HCI socket layer initialized
[   12.970340] Bluetooth: L2CAP socket layer initialized
[   12.970418] Bluetooth: SCO socket layer initialized
[   13.230396] Bluetooth: HCI UART driver ver 2.3
[   13.230471] Bluetooth: HCI UART protocol H4 registered
[   13.230537] Bluetooth: HCI UART protocol BCSP registered
[   13.230603] Bluetooth: HCI UART protocol LL registered
[   13.230668] Bluetooth: HCI UART protocol ATH3K registered
[   13.230794] Bluetooth: HCI UART protocol Intel registered
[   13.230900] Bluetooth: HCI UART protocol Broadcom registered
[   13.230968] Bluetooth: HCI UART protocol QCA registered
[   13.231033] Bluetooth: HCI UART protocol AG6XX registered
[   13.231099] Bluetooth: HCI UART protocol Marvell registered
[   13.259352] input: PC Speaker as /devices/platform/pcspkr/input/input9
[   13.451167] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   13.766482] [drm] Initialized
[   13.922180] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   13.922359] sd 1:0:0:0: Attached scsi generic sg1 type 0
[   13.922534] sd 2:0:0:0: Attached scsi generic sg2 type 0
[   13.922702] sd 3:0:0:0: Attached scsi generic sg3 type 0
[   13.922877] sd 4:0:0:0: Attached scsi generic sg4 type 0
[   14.261987] [drm] Memory usable by graphics device = 2048M
[   14.262057] [drm] Replacing VGA console driver
[   14.262954] Console: switching to colour dummy device 80x25
[   14.263138] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   14.263146] [drm] Driver supports precise vblank timestamp query.
[   14.263664] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   14.383212] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   14.383797] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[   14.383981] snd_hda_intel :00:1b.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   14.384009] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0
[   14.498431] fbcon: inteldrmfb (fb0) is primary device
[   14.538301] Console: switching to colour frame buffer device 240x67
[   14.552978] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: 
line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
[   14.552983] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   14.552987] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   14.552990] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   14.552993] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0
[   14.552995] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   14.553000] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
[   14.553004] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[   14.553007] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[   14.567320] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   14.843919] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[   14.846110] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[   14.846217] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[   14.846321] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[   14.846426] input: HDA Intel PCH Line Out Front as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[   14.846531] input: HDA Intel PCH Line Out Surround as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[   14.846638] input: HDA Intel PCH Line Out CLFE as 
/devices/pci:00/:00:1b.0/sound/card0/input17
[   14.846743] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input18
[   14.846849] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input19
[   14.846954] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1b.0/sound/card0/input20
[   16.346676] iTCO_vendor_support: vendor-support=0
[   16.435556] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   16.435742] iTCO_wdt: Found a Bay Trail SoC TCO device (Version=3, 
TCOBASE=0x0460)
[   16.436144] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   16.600133] 

Bug#920942: transition: libfm-qt

[Scott Kitterman]

On Wed, 30 Jan 2019 20:32:02 +0100 Emilio Pozuelo Monfort  
wrote:
...
> - Can you get this into experimental first so that we can check that there 
are
> no issues, e.g. that the package builds on all architectures?
...
It's through New and accepted into experimental.

Scott K

Bug#920941: libvncserver: diff for NMU version 0.9.11+dfsg-1.3

[Salvatore Bonaccorso]

Control: tags 920941 + patch

Hi Peter,

I've prepared an NMU for libvncserver (versioned as 0.9.11+dfsg-1.3). The diff
is attached to this message. I did upload this time without delay
given the fixes were needed from the previous fixes (incomplete fixes
for CVEs).

I have pushed as well the changes to the packaging repository on
salsa.

it is a bit short on time, but it might maybe possible to still upload
new upstream version in time for buster?

Regards,
Salvatore
diff -Nru libvncserver-0.9.11+dfsg/debian/changelog libvncserver-0.9.11+dfsg/debian/changelog
--- libvncserver-0.9.11+dfsg/debian/changelog	2019-01-02 16:26:53.0 +0100
+++ libvncserver-0.9.11+dfsg/debian/changelog	2019-01-30 22:39:15.0 +0100
@@ -1,3 +1,20 @@
+libvncserver (0.9.11+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * LibVNCClient: ignore server-sent cut text longer than 1MB (CVE-2018-20748)
+(Closes: #920941)
+  * LibVNCClient: ignore server-sent reason strings longer than 1MB
+(CVE-2018-20748) (Closes: #920941)
+  * LibVNCClient: fail on server-sent desktop name lengths longer than 1MB
+(CVE-2018-20748) (Closes: #920941)
+  * LibVNCClient: remove now-useless cast (CVE-2018-20748) (Closes: #920941)
+  * Error out in rfbProcessFileTransferReadBuffer if length can not be
+allocated (CVE-2018-20749) (Closes: #920941)
+  * Limit lenght to INT_MAX bytes in rfbProcessFileTransferReadBuffer()
+(CVE-2018-20750) (Closes: #920941)
+
+ -- Salvatore Bonaccorso   Wed, 30 Jan 2019 22:39:15 +0100
+
 libvncserver (0.9.11+dfsg-1.2) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0001-LibVNCClient-ignore-server-sent-cut-text-longer-than.patch libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0001-LibVNCClient-ignore-server-sent-cut-text-longer-than.patch
--- libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0001-LibVNCClient-ignore-server-sent-cut-text-longer-than.patch	1970-01-01 01:00:00.0 +0100
+++ libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0001-LibVNCClient-ignore-server-sent-cut-text-longer-than.patch	2019-01-30 22:39:15.0 +0100
@@ -0,0 +1,32 @@
+From: Christian Beier 
+Date: Sat, 29 Dec 2018 14:16:58 +0100
+Subject: LibVNCClient: ignore server-sent cut text longer than 1MB
+Origin: https://github.com/LibVNC/libvncserver/commit/c5ba3fee85a7ecbbca1df5ffd46d32b92757bc2a
+Bug-Debian: https://bugs.debian.org/920941
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-20748
+
+This is in line with how LibVNCServer does it
+(28afb6c537dc82ba04d5f245b15ca7205c6dbb9c) and fixes part of #273.
+---
+ libvncclient/rfbproto.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
+index 4541e0d53ad3..8792dbf67c48 100644
+--- a/libvncclient/rfbproto.c
 b/libvncclient/rfbproto.c
+@@ -2217,6 +2217,11 @@ HandleRFBServerMessage(rfbClient* client)
+ 
+ msg.sct.length = rfbClientSwap32IfLE(msg.sct.length);
+ 
++if (msg.sct.length > 1<<20) {
++	rfbClientErr("Ignoring too big cut text length sent by server: %u B > 1 MB\n", (unsigned int)msg.sct.length);
++	return FALSE;
++}  
++
+ buffer = malloc((uint64_t)msg.sct.length+1);
+ 
+ if (!ReadFromRFBServer(client, buffer, msg.sct.length)) {
+-- 
+2.20.1
+
diff -Nru libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0002-LibVNCClient-ignore-server-sent-reason-strings-longe.patch libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0002-LibVNCClient-ignore-server-sent-reason-strings-longe.patch
--- libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0002-LibVNCClient-ignore-server-sent-reason-strings-longe.patch	1970-01-01 01:00:00.0 +0100
+++ libvncserver-0.9.11+dfsg/debian/patches/CVE-2018-20748/0002-LibVNCClient-ignore-server-sent-reason-strings-longe.patch	2019-01-30 22:39:15.0 +0100
@@ -0,0 +1,88 @@
+From: Christian Beier 
+Date: Sat, 29 Dec 2018 14:40:53 +0100
+Subject: LibVNCClient: ignore server-sent reason strings longer than 1MB
+Origin: https://github.com/LibVNC/libvncserver/commit/e34bcbb759ca5bef85809967a268fdf214c1ad2c
+Bug-Debian: https://bugs.debian.org/920941
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-20748
+
+Fixes #273
+---
+ libvncclient/rfbproto.c | 45 +++--
+ 1 file changed, 21 insertions(+), 24 deletions(-)
+
+diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
+index 8792dbf67c48..ba7d70a71575 100644
+--- a/libvncclient/rfbproto.c
 b/libvncclient/rfbproto.c
+@@ -412,11 +412,29 @@ rfbBool ConnectToRFBRepeater(rfbClient* client,const char *repeaterHost, int rep
+ extern void rfbClientEncryptBytes(unsigned char* bytes, char* passwd);
+ extern void rfbClientEncryptBytes2(unsigned char *where, const int length, unsigned char *key);
+ 
++static void
++ReadReason(rfbClient* client)
++{
++uint32_t reasonLen;
++char 

Bug#920942: transition: libfm-qt

[Alf Gaida]

Hi Emilio,

it build just fine, i currently run it, i uploaded it to my private repo
with an attached build server before.

The new version is important. PCManFM-Qt is the main part of LXQt, the
new released version is the finished porting to C++ with lots of bug
fixes and enhancements. Further more - the version that is currently in
sid and testing should under no circumstances go to stable - reason: it
isn't. We was forced upstream to do the migration stepwise, 0.13 was the
first step needed. 0.14.0 is the polished version with only a few new
functionality and lots of fixed bugs (major and minor). Might sound
hard, but i would not have the needed thick skin and the balls to put
this into stable, it would be a clear dis-service for our users.

I guess that there might be some symbol bugs in some architectures but
they will be easy to fix. amd64 and i386 should just build fine.

https://github.com/lxqt/libfm-qt/blob/master/CHANGELOG - that is the
very condensed form of the changes, i find the git log unreadable for
mere humans - even if i should know what we have changed.

Alf


On 30.01.19 20:32, Emilio Pozuelo Monfort wrote:
> On 30/01/2019 19:28, Alf Gaida wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>>
>>
>> impacted packages:
>> * pcmanfm-qt
>> * lximage-qt
>>
>> The new release of LXQt was after transition freeze, there are only these 
>> two dependend packages,
>> so i don't know that this need a transition. The sources of pcmanfm-qt and 
>> lximage-qt are already
>> uploaded and in the repo. Sorry for the mess, my current knowledge was that 
>> transitions are
>> only needed if more than a handful of packages are involved.
> 
> It's best to ask during the freeze even if there are only a few rdeps.
> 
> - Do the rdeps build fine against the new libfm-qt?
> - Can you get this into experimental first so that we can check that there are
> no issues, e.g. that the package builds on all architectures?
> - Why is this new version important? Any bug fixes or important features that
> you think should be in buster?
> 
> Emilio
> 

Bug#920858: [Pkg-javascript-devel] Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Xavier]

Le 30/01/2019 à 22:34, Jonas Smedegaard a écrit :
> Quoting Xavier (2019-01-30 22:26:57)
>> Le 29/01/2019 à 22:17, Jonas Smedegaard a écrit :
>>> Source: twitter-bootstrap4
>>> Version: 4.2.1+dfsg1-1
>>> Severity: serious
>>> Justification: Policy 2.1
>>>
>>> Source package contains below  several files embedding code from
>>> external project fileOverview Kickass, without source included.
>>>
>>> Thanks to Xavier for noticing (although only as comment in copyright
>>> file).
>>>
>>>
>>>  - Jonas
>>
>> I succeed to build source, but this needs:
> [snip]
> 
> This bugreport tracks twitter-bootstrap4 violating Policy in shipping 
> code without source.
> 
> For discussing packaging of that source in a separate package, please 
> file an ITP bugreport (or an RFP bugreport if you don't intent on doing 
> the work yourself), and let's discuss packaging issues there.
> 
> 
>  - Jonas

Also is it OK if I remove dist/bootstrap.bundle.* in Files-Excluded ?

Note that "fileOverview Kickass" is provided by popper.js

Bug#920956: ITP: fonts-recommended -- set of recommended fonts

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: fonts-recommended
  Description : set of recommended fonts
 This metapackage is a list of fonts that, in the opinion of some members
 of the Debian Fonts team, is reasonable to have on most GUI systems if
 you don't care about bloat.  The selection is pretty arbitrary, but it
 includes:
 * compatibility with other operating systems
 * basic coverage of all writing systems
 * all symbols and emojis
 * fonts just nice to have

Reason for the package: d-i defaults are very conservative, then you waste
time picking which fonts to install.

Fonts people: as the first stab, I'll upload my picks with Fabian's input,
then let's have a flamewar.

Bug#532093: AleVT in dvb-apps

[Göran Weinholt]

Tobias Grimm  writes:

> Hello Göran!
>
> dvb-apps doesn't seem to be actively been worked on by upstream as
> well. The last upstream commit was about 5 years ago. But it's still
> younger than the original alevt. So I guess alevt can indeed be
> "merged" into dvb-apps. dvb-apps can need a little help as well. There
> have only been NMU's since 2013.

If alevt in dvb-apps is not being worked on either (they even moved it
to "legacy"), then the cookie that I bit into is a little bit bigger
than I first thought. In light of dvb-apps being dead upstream it isn't
really right to replace alevt with dvb-apps.

I'm leaning more towards setting up a proper upstream project for alevt
and keeping the alevt package separate from dvb-apps. I have had some
fascination with teletext even since I was a little child, so I think
it'll be fun.

> I've moved linuxtv-dvb-apps to Salsa last year:
>
> https://salsa.debian.org/vdr-team/linuxtv-dvb-apps
>
> ...but unfortunately couldn't find the time to work on this package.
> Currently I'm busy getting the VDR packages up-to-date, so any help
> would be welcome!

But why did upstream move it to the legacy section of the website? Doing
something like that makes it look like there are replacements for all
the included tools (at least apart from alevt). Do you think the package
still is relevant for Debian?

Regards,

-- 
Göran Weinholt
Debian Developer
https://weinholt.se/

Bug#920955: crossfire-server: /var/games/crossfire is not owned by games:games

[Neil Muller]

Package: crossfire-server
Version: 1.71.0+dfsg1-1+b1
Severity: important

Dear Maintainer,

In a fresh install of the crossfire server, the /var/games/crossfire
directory is owned by root:root. Since the server runs under the games
user, this means that, without manual intervention, the server cannot
save any data - it's possible to connect to the server and play, but
accounts and characters will not be saved.

The log directory /var/log/crossfire is also owned by root, which
prevents the game from logging anything as well, which isn't ideal
either.

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

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

Versions of packages crossfire-server depends on:
ii  bzip2 1.0.6-8.1
ii  crossfire-common  1.71.0+dfsg1-1
ii  crossfire-maps1.71.0-1
ii  libc6 2.24-11+deb9u3
ii  libcurl3-gnutls   7.52.1-5+deb9u8
ii  libpython2.7  2.7.13-2+deb9u3

crossfire-server recommends no packages.

crossfire-server suggests no packages.

-- no debconf information

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

control: tag -1 -pending

Hello,

On Wed 30 Jan 2019 at 02:42PM -07, Sean Whitton wrote:

> Thank you.  I've pushed it to DELAYED/14, after which it will land in
> the NEW queue.

Er.  After doing this, I immediately discovered this error in
d/copyright:

License: LGPL-2.1-or-later

should be

License: LGPL-2.1+

Could you make this change as a -2 upload, please?  Since I have already
pushed the -1, it is cleaner to do it that way.

Sorry, all, for the noise.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920885: ntp: segmentation fault in libc-2.24.so[7f9cf2783000+195000]

[Bernhard Übelacker]

Hello Vincas Dargis,
I guess the provided information may not be enough for the
maintainer to find the cause or make a fix.

And I am just curious, but this "0x2f9b8" are just the "195000" from
the kernel log line? I am not sure, but would here not make
0x7f9cf2783000 - 0x7f9cf2803676 = 0x80676 more sense?
That way we would end in the strlen function, at least an instruction
with offset ...676 like the instruction pointer "ip".

But to get more information of a crash you could consider
installing a core dump collector like systemd-coredump.

Then a first backtrace would be already written to the logs.
You could list the cores collected at least of the current boot:

coredumpctl list

(previous boots might just get stored in /var/lib/systemd/coredump)

And get more information from the core by e.g.:

coredumpctl gdb [PID]
bt

Even better would be if debug symbols are installed like
described in [1], in this case ntp-dbgsym.

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols




root@debian:~# apt install gdb binutils ntp ntp-dbgsym

root@debian:~# addr2line -e /lib/x86_64-linux-gnu/libc-2.24.so 0x80676
/build/glibc-yWQXbR/glibc-2.24/string/../sysdeps/x86_64/strlen.S:106

root@debian:~# gdb -q -ex 'b main' -ex 'run' -ex 'dele 1' --args /usr/sbin/ntpd
Reading symbols from /usr/sbin/ntpd...Reading symbols from 
/usr/lib/debug/.build-id/5a/8c27a9b583247c96d38ca88835dc36f0ad253d.debug...done.
done.
Breakpoint 1 at 0x12390: file ntpd.c, line 400.
Starting program: /usr/sbin/ntpd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffed28) at ntpd.c:400
400 ntpd.c: Datei oder Verzeichnis nicht gefunden.
(gdb) b strlen.S:106
Breakpoint 2 at 0x76cd9676: strlen.S:106. (2 locations)
(gdb) disassemble 0x76cd9676-0x16,0x76cd9676+0x16
Dump of assembler code from 0x76cd9660 to 0x76cd968c:
   0x76cd9660 :  mov%rdi,%rax
   0x76cd9663 :  mov%rdi,%rcx
   0x76cd9666 :  and$0xfff,%rcx
   0x76cd966d :  cmp$0xfcf,%rcx
   0x76cd9674 :  ja 0x76cd96e0 
   0x76cd9676 :  movdqu (%rax),%xmm4
   0x76cd967a :  pcmpeqb %xmm0,%xmm4
   0x76cd967e :  pmovmskb %xmm4,%edx
   0x76cd9682 :  test   %edx,%edx
   0x76cd9684 :  je 0x76cd968a 
   0x76cd9686 :  bsf%edx,%eax
   0x76cd9689 :  retq   
   0x76cd968a :  and$0xfff0,%rax
End of assembler dump.

Bug#920859: libreoffice-kde5: Crash when minimizing file save dialog

[Rene Engelhard]

found 920859 1:6.2.0~rc2-1
tag 920859 + confirmed
tag 920859 + upstream
forwarded 920859 Michael Weghorn 
thanks

Hi,

On Tue, Jan 29, 2019 at 10:22:28PM +0100, Helmar Gerloni wrote:
> LibreOffice crashes when minimizing the file save dialog. Steps to reproduce:
> 
> 1. Start LibreOffice
> 2. File -> New -> Text Document (or other)
> 3. File -> Save As... - save dialog appears
> 4. Minimize dialog window - dialog and LibreOffice windows get minimized
> 5. Maximize windows again
> 
> Dialog window crashes, KDE crash pop-up menu appears "lo_kde5filepicker 
> Closed Unexpectedly".

Mmh.

> LibreOffice remains blocked and can only be killed.

I am not actually surprised here given it then probably still tries to
talk to the (now gone) lo_kde5filepicker process...

Upstream says:

14:44 < _rene_> bubli: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920859. known? (gtk3_kde5)
14:45 <@bubli> _rene_: Neven seen before
14:49 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has quit [Ping timeout: 268 
seconds]
14:51 < mst___> caolan, so a) the clipboard locking in VclGtkClipboard looks 
broken b) since LO 5.3, commit ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60 works 
around the breakage 
because my extension here will always hold the SolarMutex now 
so the main thread doesn't get a chance to run anyway
14:52 < IZBot> core - try to avoid the deadlock around the clipboard,  - 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed7e74ae1c7ecfc29df152a8397fb9f6e1763a60
14:52 -!- NaveenNaidu_ [~NaveenNai@223.186.44.102] has joined #libreoffice-dev
14:55 < michaelweghorn> _rene_: I can reproduce here and can take a look, but 
probably not before next week

Regards,

Rene

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

control: tag -1 +pending

Hello Birger,

On Wed 30 Jan 2019 at 09:13PM +01, Birger Schacht wrote:

> done in 0d9ddb3b ;)

Thank you.  I've pushed it to DELAYED/14, after which it will land in
the NEW queue.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920847: init-d-script: add do_restart_prepare and do_reload_prepare handlers

[Mathieu Mirmont]

On Wed, Jan 30, 2019 at 08:48:59PM +, Dmitry Bogatov wrote:
> Thank you for your contribution.  Your patch looks good, but given
> upcoming freeze, to avoid surprises, I intend to upload your patch into
> unstable after release. Upload to experimental is due in several weeks.
> 
> Will it do for you?

Sure, no problem.

Thanks.

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#920858: [Pkg-javascript-devel] Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Xavier]

Le 29/01/2019 à 22:17, Jonas Smedegaard a écrit :
> Source: twitter-bootstrap4
> Version: 4.2.1+dfsg1-1
> Severity: serious
> Justification: Policy 2.1
> 
> Source package contains below  several files embedding code from
> external project fileOverview Kickass, without source included.
> 
> Thanks to Xavier for noticing (although only as comment in copyright
> file).
> 
> 
>  - Jonas

I succeed to build source, but this needs:
 - to upgrade: rollup-plugin-babel, browserslist
 - to package or upgrade at least (I reduced this list to the minimum
possible): node-releases, rollup-plugin-babel, trim-right, @babel/core
@babel/generator @babel/helper-annotate-as-pure
@babel/helper-builder-binary-assignment-operator-visitor
@babel/helper-call-delegate @babel/helper-define-map
@babel/helper-explode-assignable-expression @babel/helper-function-name
@babel/helper-get-function-arity @babel/helper-hoist-variables
@babel/helper-member-expression-to-functions
@babel/helper-module-imports @babel/helper-module-transforms
@babel/helper-optimise-call-expression @babel/helper-plugin-utils
@babel/helper-regex @babel/helper-remap-async-to-generator
@babel/helper-replace-supers @babel/helpers @babel/helper-simple-access
@babel/helper-split-export-declaration @babel/helper-wrap-function
@babel/highlight @babel/parser
@babel/plugin-proposal-async-generator-functions
@babel/plugin-proposal-json-strings
@babel/plugin-proposal-object-rest-spread
@babel/plugin-proposal-optional-catch-binding
@babel/plugin-proposal-unicode-property-regex
@babel/plugin-syntax-async-generators @babel/plugin-syntax-json-strings
@babel/plugin-syntax-object-rest-spread
@babel/plugin-syntax-optional-catch-binding
@babel/plugin-transform-arrow-functions
@babel/plugin-transform-async-to-generator
@babel/plugin-transform-block-scoped-functions
@babel/plugin-transform-block-scoping @babel/plugin-transform-classes
@babel/plugin-transform-computed-properties
@babel/plugin-transform-destructuring
@babel/plugin-transform-dotall-regex
@babel/plugin-transform-duplicate-keys
@babel/plugin-transform-exponentiation-operator
@babel/plugin-transform-for-of @babel/plugin-transform-function-name
@babel/plugin-transform-literals @babel/plugin-transform-modules-amd
@babel/plugin-transform-modules-commonjs
@babel/plugin-transform-modules-systemjs
@babel/plugin-transform-modules-umd @babel/plugin-transform-new-target
@babel/plugin-transform-object-super @babel/plugin-transform-parameters
@babel/plugin-transform-regenerator
@babel/plugin-transform-shorthand-properties
@babel/plugin-transform-spread @babel/plugin-transform-sticky-regex
@babel/plugin-transform-template-literals
@babel/plugin-transform-typeof-symbol
@babel/plugin-transform-unicode-regex @babel/preset-env @babel/template
@babel/traverse @babel/types

However, generated code is readable, not minified and contains some
comments, perhaps not enough. So I think it's not a significant DFSG break.

I won't package all of them so if we consider than using generated
dist/* files is a policy break, I think that twitter-bootstrap4 can't be
released in buster.

Another crazy alternative: embeds that (4,8 Mo) ! I won't do it.

Bug#920858: [Pkg-javascript-devel] Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Jonas Smedegaard]

Quoting Xavier (2019-01-30 22:26:57)
> Le 29/01/2019 à 22:17, Jonas Smedegaard a écrit :
> > Source: twitter-bootstrap4
> > Version: 4.2.1+dfsg1-1
> > Severity: serious
> > Justification: Policy 2.1
> > 
> > Source package contains below  several files embedding code from
> > external project fileOverview Kickass, without source included.
> > 
> > Thanks to Xavier for noticing (although only as comment in copyright
> > file).
> > 
> > 
> >  - Jonas
> 
> I succeed to build source, but this needs:
[snip]

This bugreport tracks twitter-bootstrap4 violating Policy in shipping 
code without source.

For discussing packaging of that source in a separate package, please 
file an ITP bugreport (or an RFP bugreport if you don't intent on doing 
the work yourself), and let's discuss packaging issues there.


 - 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#788851: Patch for acct

[Marcos Fouces]

Hello Dominique

Thanks for your report.

I also believe that is not a acct bug as you admit ("...so the cause may
be the kernel having an open file handle.")

BTW. i cannot reproduce this bug myself. Could you please check if the
problem persist with a newer kernel?

If no more info is provided i eventually close this bug.

Greetints,

Marcos.

Bug#920841: awesome breaks lua-lgi autopkgtest: Typelib file for namespace 'GdkPixbuf' (any version) not found

[Reiner Herrmann]

On Wed, Jan 30, 2019 at 07:45:52PM +0100, Paul Gevers wrote:
> On 30-01-2019 09:05, Reiner Herrmann wrote:
> > Will it automatically re-run the test at some later time or not?
> 
> We retrigger regressions once a day.

Ok, good to know. :)

> 
> > Because I would assume that the trigger for "awesome/4.3-3" is now
> > already run...
> 
> But it seems you already retriggered it manually.

Yes, I noticed the retrigger button on PTS.

Thanks!

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#846278: light-locker is counterproductive

[Philippe Caillaud]

Hello Tomas.

What you describe/understand as "magic" about F7/F8 is simple (I don't 
know if it's a but or a feature) :


1/ once you're logged with lightdm, and you have your X session, only 
ONE Xorg server is running :


user@system:~$ ps a | grep Xorg
  675 tty7 Ssl+   0:37 /usr/lib/xorg/Xorg :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch


2/ after direct or undirect (suspend to RAM) session locking, there are 
2 Xorg servers running :


user@system:~$ ps a | grep Xorg
   675 tty7 Ssl+   0:32 /usr/lib/xorg/Xorg :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 2788 tty8 Ssl+   0:00 /usr/lib/xorg/Xorg :1 -seat seat0 -auth 
/var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch


On the 1st Xorg server, your normal session, "covered" by the screen 
lock announcement.

On the 2nd Xorg server, the login window.

3/ once logged again, your have again one Xorg server, with your normal 
session ("uncovered" by the announcement).


user@system:~$ ps a | grep Xorg
  675 tty7 Ssl+   0:37 /usr/lib/xorg/Xorg :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch



On my own system, I'm still observing a strange behavior (with 
light-locker 1.8.0-3) :
* if I close the lid, the system suspends to RAM, and when I reopen, I 
get the login window, and once logged, the normal session.
* but if I ask for the Suspend-to-RAM through the Xfce logout window 
(choice between logout, reboot, shutdown, S-to-RAM or S-to-Disk), then 
after awakening, I can generally see briefly the logout window (over 
normal session), then black screen (and it looks even that the screen is 
switched off), and then I have to switch to VT8 to get the login 
window... (and often I have to press Ctrl-Alt-F8 or F7 several times 
before seeing anything).


Yours,

Philippe.

Following in another e-mail : some extracts of my /var/log/syslog.

Le 29/01/2019 à 09:30, Tomas Pospisek a écrit :

Package: light-locker
Version: 1.8.0-3
Followup-For: Bug #846278

After upgrading from Debian 'stretch' to 'buster' I am seeing similar
behavior as the other reporters here:

* when I close the lid, the system suspends to RAM.
* when I reopen, I get a black screen
   * clicking around, moving the mouse, pressing shift, space or any key
 doesn't have any effect
* then I switch to CTRL-ALT-F1, a text terminal appears
* I switch back to CTRL-ALT-F7, now the lock screen appears, with the
   text "you will be redirected shortly" (in german, so I'm not sure
   about the exact english wording).
* again clicking around, pressing keys, but the lock screen remains in
   "you will be redirected shortly"
* then I press CTRL-ALT-F8 (yes F8!!) and I see the lightdm graphical
   login screen (I suppose it's lightdm that is responsible for the
   login screen)
* once logged in I can switch to CTRL-ALT-F1 to the text terminal and
   back to CTRL-ALT-F7 (yes F7!!) and my normal desktop appears

* I had very spurious problems with the lock screen (say once in three
   months) under Debian stretch
* however under 'buster' the problem is 100% repeatable
* I have tried with both light-locker 1.8.0-3 and 1.8.0-2

* after uninstalling light-locker, everything "just works" that is,
   after resume I am presented the lightdm login screen

Some findings:

* so, for some reason, the lock screen seems to be appearing on F7 and
   the desktop on F8. Once I am logged in, the desktop seems to be
   magically switching over to F7.
* the lock screen is serving no purpose as far as I can see and it
   actually breaks the users' system. Logging back in is not possible
   without that weird workaround/hack above.

Given the above (I can't see the use for light-locker, given that
lightdm presents a login screen anyway) I suggest to drop
the package from Debian. And/or remove it from the Suggests of
xfce4-session and lxqt-session, because at least here it effectively
breaks xfce4-session and lxqt-session.

It'd be useful to know on how many "buster" systems light-locker
works vs. how many it breaks.

*t

PS: I'll add a Cc: Debian Xfce Maintainers,
 LXQt Packaging Team  for the
 xfce4-session and lxqt-session packages later.

Bug#907297: breeze-gtk-theme: Breaks xfce4-notes (invalid string constant in "/usr/share/themes/Breeze/gtk-2.0/widgets/styles")

[Maximiliano Curia]

Control: severity -1 normal
Control: tag -1 + unreproducible

¡Hola Dmitry!

El 2018-08-26 a las 15:53 +1000, Dmitry Smirnov escribió:

Package: breeze-gtk-theme
Version: 5.13.4-1
Severity: normal
Control: affects -1 xfce4-notes



breeze-gtk-theme breaks xfce4-notes:




$ xfce4-notes
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:7: error: invalid string constant 
"notebook", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:2: error: invalid string constant 
"scrollbar", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:4: error: invalid string constant 
"entry", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:4: error: invalid string constant 
"entry", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string constant 
"default", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string constant 
"default", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:8: error: invalid string constant 
"range", expected valid string constant
^C




I could only use xfce4-notes after uninstalling "breeze-gtk-theme"...


I couldn't reproduce the issue, executing xfce4-notes shows no errors in the 
termianl and it seems to be working fine, this of course, while using the 
breeze theme.


Thus setting the severity back to normal, and tagging the issue as 
unreproducible. Is there anything special about your setup that could somehow 
caused that the other files in /usr/share/themes/Breeze/gtk-2.0/widgets/ 
directory could not be loaded? A limit on the number of open files, perhaps?


Happy hacking,
--
"Brilliant opportunities are cleverly disguised as insolvable problems."
-- Gardener's Philosophy

"The reverse is also true." -- Corollary
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#908329: lightdm: LightDM shuts down the screen on lock and won't turn it on

[Rafał Olejnik]

On Mon, 28 Jan 2019 08:44:29 +0100 Olivier Berger 
 wrote:

> On Sat, Dec 08, 2018 at 09:41:03PM +0100, Mikhail Morfikov wrote:
> >
> > I think I have a similar (or the same) issue.
> >
> > Basically, when I lock the screen (via light-locker), the screen 
goes black,
> > but it doesn't turn off. Keystrokes and mouse seem to dead because 
they don't
> > turn the screen on. When I press ctrl+alt+F7, then I get the 
message: "This
> > session is locked, you'll be redirected to the login dialog in a 
few sec", and
> > after a few seconds I get the login screen. I don't even have to 
wait for the
> > redirect -- I can simply press ctrl+al+F7 and ctrl+alt+F8 (I have 
to press both
> > of them). One curious thing -- when I start typing while the screen 
is black,
> > the login form can be filled with password, and after pressing 
enter I can log

> > in.
> >
>
> Happens the same here, with XFCE, lighdm and light-locker and an Intel
> Corporation HD Graphics 620 card.
>
> Hope this helps.
>
> Best regards,
> --
> Olivier BERGER
> https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 
2048R/0xF9EAE3A65819D7E8

> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
>

>


Confirm, i'm having this issue on two systems with xfce 4.12.5, lightdm 
1.26.0-3, ligt-locker 1.8.0-3 and two different intel cards:


00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller (rev 06)
    Subsystem: Lenovo 4th Gen Core Processor Integrated Graphics 
Controller

    Kernel driver in use: i915
    Kernel modules: i915

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 
(rev 07)

    Subsystem: Dell UHD Graphics 620
    Kernel driver in use: i915
    Kernel modules: i915

So far couldn't find any solution but have seen more ppl complaining.

--
Regards,
Rafał Olejnik

Bug#541486: install-info: [manpage] install-info - Please add EXAMPLES section

[Hilmar Preusse]

On 14.08.09 Jari Aalto (jari.aa...@cante.net) wrote:

Hi Jari,

> The program contains many options and its call syntax offers various
> arguments.
> 
> Please add EXAMPLES section to the manual page to typical use cases
> (options, files, directories).
> 
We got a response from Karl Berry, but he did not respond to our
mailing list. ;-(


I agree, but I'm not going to have a chance to do this any time soon.
If you or someone else can send me text, I'll be happy to include it, of
course.

By the way, any such patch should be relative to the --help message, not
the man page.  The man page is generated with help2man.

Another possibility is to add more documentation about install-info to
texinfo.txi.  Currently it is effectively the same as the --help
message.


Are you willing to contribute and generate some examples you'd like to
see in the man page?

Thanks,
  Hilmar


signature.asc
Description: PGP signature

Bug#920927: [Pkg-zfsonlinux-devel] Bug#920927: zfs-dkms: module FTBFS for i386 kernel

[Andreas Beckmann]

On 2019-01-30 20:12, Petter Reinholdtsen wrote:
> 
> [Andreas Beckmann]
>> zfs-dkms does not build a kernel module for e.g. the 4.19.0-2-686 i386
>> kernel. This happened in a i386 chroot on a amd64 host, but this should
>> not really be a problem, since this setup works fine for other
>> packages.
> 
> Are you sure this isn't intentional?  It is strongly recommended not to
> use ZFS on 32 bit architectures, if I recall correctly.

"intentional" would have been to fail with a clear error message during
the configure step (optionally recommending an override option), not
after successfully compiling tons of source files to fail in some crypto
code with a dubious error message:
  #error Assembler code is only available for x86 and AMD64 systems
I didn't even try it on a non-x86 platform :-)

This looks rather like completely "untested".


Andreas

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Felipe Sateler]

On Tue, Jan 29, 2019 at 9:39 PM Axel Beckert  wrote:

>
> Then I uninstalled not all of them at once but each of them one by
> one. And the one after whose purging
>
> # service udev restart
> # udevadm control --reload-rules
>
> didn't kill my processes anymore was cgroupfs-mount.
>
> So for some reason this killing only seems to happen on my box if
> cgroupfs-mount is installed. Then again, this is only necessary if
> systemd is not installed.


Thanks everyone for the detailed debugging. This appears to be the culprit:
udev tries to detect if running under systemd, and if so will kill its
entire cgroup (to cleanup leftover processes). Looks like cgroupfs-mount is
fooling udev into thinking it is running under systemd.

Could someone attach gdb to udev, break on the function `on_post`, trigger
the bug, and report what does `manager->cgroup` contain?



> But we also had reports where this happend
> with systemd, so this doesn't seem to be depend on the init system (at
> most at the init system's default features) and hence also the package
> cgroupfs-mount can't be held guilty for this.
>

Can you point me at one? (sorry, I'm late to this bug and currently ENOTIME
to read the entire backlog). It seems this should not happen on systemd
systems, because systemd properly isolates udev to its own cgroup when
starting.


>
> Which IMHO again leaves either src:systemd or src:linux as rc-buggy
> package.
>

I think something like this might be sufficient to work around the bug in
sysvinit systems:

% git diff
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index fb8724ea87..a03b65a773 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1814,7 +1814,7 @@ static int run(int argc, char *argv[]) {

 dev_setup(NULL, UID_INVALID, GID_INVALID);

-if (getppid() == 1) {
+if (getppid() == 1 && sd_booted()) {
 /* get our own cgroup, we regularly kill everything udev
has left behind
we only do this on systemd systems, and only if we are
directly spawned
by PID1. otherwise we are not guaranteed to have a
dedicated cgroup */


-- 

Saludos,
Felipe Sateler

Bug#920158: stterm: Crash when displaying emoji

[Paride Legovini]

control: forwarded 920158
https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6

Timothy Allen wrote on 30/01/2019:
> On Tue, 2019-01-29 at 23:56 +0100, Paride Legovini wrote:
>> I will report it there, unless you want to report it
>> yourself (see https://suckless.org/community/).

Turns out the issue is known and it's actually an Xft bug:

https://lists.suckless.org/dev/1901/33147.html

https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6

Paride

Bug#536793: ebb always assumes 100ppi

[Hilmar Preusse]

On 13.07.09 Anthony DeRobertis (anth...@derobert.net) wrote:

Hi Anthony,

Long response time, I know.

> Package: texlive-base-bin
> Version: 2007.dfsg.2-6
> Severity: normal
> File: /usr/bin/ebb
> 
> When you run ebb, it always assumes 100ppi in computing the bouding box.
> This is a compile-time setting, the PIX2PT macro in the source:
> 
>   #define PIX2PT (72.0/100.0)
>   void do_jpeg (FILE *file, char *filename)
>   {
>   ...
> 
> It'd be nice if it (a) took a command line argument to specify the ppi
> and (b) used the ppi information in the bitmap image file, if present
> (e.g., PNG can)
> 
The current manual page reads:

OUTPUT FORMATS
   Here are more details about the bb and xbb formats:

   The  original  ebb (from dvipdfm) ignored density information in bitmap
   images, and generated bounding boxes with 100px = 72bp = 1in.  Unfortu‐
   nately, screenshots (especially) tend to look bad with this approach.

   So,  extractbb  (from  dvipdfmx)  uses  density information if present.
   Otherwise, it generates bounding box with 100px = 100bp.  This is  what
   pdfTeX does.

Is this OK or you? Can we close the issue?

Hilmar


signature.asc
Description: PGP signature

Bug#920607: Debian Buster installer on qnap ts-21x / Fujitsu Q700 : /dev/mtdblock* missing

[Uwe Kleine-König]

Control: retitle -1 spi-orion not included in any udeb for armel-marvell

Hello,

On Wed, Jan 30, 2019 at 07:04:51PM +0100, Bernhard Übelacker wrote:
> Hello Everyone,
> I also tried to install current testing to a qnap ts-119P II.
> 
> On Tue, 29 Jan 2019 21:43:50 +0100 =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= 
>  wrote:
> > On 1/27/19 12:13 PM, Lukas Straub wrote:
> > > Package: linux
> > > Version: 4.19.12-1
> > > 
> > > Hello Everyone,
> > > I tried the latest Buster Installer on my Fujitsu Q700 (rebranded
> > > qnap ts-21x) and Everything works except that /dev/mtdblock* devices
> > > are missing so flashing the kernel and initrd fails.
> > 
> > I see the spi-orion-Driver is not loaded. Does /dev/mtd* appear if you do
> > 
> > modprobe spi-orion
> > modprobe m25p80
> 
> Unfortunately I found just the m25p80.ko right after boot,
> the spi-orion.ko is missing.
> Should that be downloaded by the installer later or
> already included in the initrd?

Ah, I missed this bug is about the installer, not the regular
(installed) system. Indeed spi-orion is not included in any udeb.

Maybe adding spi-orion to
debian/installer/modules/armel-marvell/mtd-modules is the right fix
here, but I don't understand enough about the generation of udebs to
judge if this is right.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3

[Beniamino Galvani]

On Mon, Jan 28, 2019 at 10:36:16AM +0100, Andrej Shadura wrote:
> On Wed, 16 Jan 2019 at 21:51, Different55  wrote:
> >
> > Alright, not entirely sure if I did this right but I followed Debian's 
> > Building Tutorial to download and build wpa_supplicant with the changes you 
> > linked. One exception, I use wpa_supplicant through NetworkManager and 
> > could not work out where I needed to create a wpa_supplicant.conf, so I 
> > changed the one line in config.c to:
> >
> > { INT(no_oper_classes_ie), 1 },
> >
> > which I'm hoping makes the default "on" instead of "off." Sadly doesn't 
> > appear to have made a difference, although it didn't make anything worse 
> > either.
> >
> > Tiny mostly-uninteresting side note, I gave wpa_supplicant 2.7 a try on my 
> > desktop this morning and had the same problems with a Qualcomm Atheros 
> > AR9462 Wireless Adapter.
> 
> Forwarding Different55’s message from the Debian bug here:
> 
> Sure thing! Sadly doesn't seem to make a difference. I've included
> another log, this time starting from the time wpa_supplicant was
> brought back up to a little bit after I got the popup that the
> connection had failed.

Hi,

> ...
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7273] 
> device (wls8): state change: need-auth -> prepare (reason 'none', 
> sys-iface-state: 'managed')
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7281] 
> device (wls8): state change: prepare -> config (reason 'none', 
> sys-iface-state: 'managed')
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7286] 
> device (wls8): Activation: (wifi) connection 'Depeche Modem' has security, 
> and secrets exist.  No new secrets needed.
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7286] 
> Config: added 'ssid' value 'Depeche Modem'
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7287] 
> Config: added 'scan_ssid' value '1'
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7287] 
> Config: added 'bgscan' value 'simple:30:-80:86400'
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7287] 
> Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256'
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7287] 
> Config: added 'psk' value ''

Here NetworkManager enables optional PMF:

> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7287] 
> Config: added 'ieee80211w' value '1'
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7841] 
> device (wls8): supplicant interface state: ready -> disconnected
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.7942] 
> device (wls8): supplicant interface state: disconnected -> inactive
> Jan 27 21:32:01 Empanada NetworkManager[582]:   [1548646321.8001] 
> device (wls8): supplicant interface state: inactive -> scanning
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: SME: Trying to 
> authenticate with xx:xx:xx:xx:xx:xx (SSID='Depeche Modem' freq=2442 MHz)
> Jan 27 21:32:02 Empanada kernel: wls8: authenticate with xx:xx:xx:xx:xx:xx
> Jan 27 21:32:02 Empanada NetworkManager[582]:   [1548646322.8513] 
> device (wls8): supplicant interface state: scanning -> authenticating
> Jan 27 21:32:02 Empanada kernel: wls8: send auth to xx:xx:xx:xx:xx:xx (try 
> 1/3)
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: Trying to associate 
> with xx:xx:xx:xx:xx:xx (SSID='Depeche Modem' freq=2442 MHz)
> Jan 27 21:32:02 Empanada NetworkManager[582]:   [1548646322.8562] 
> device (wls8): supplicant interface state: authenticating -> associating
> Jan 27 21:32:02 Empanada kernel: wls8: authenticated
> Jan 27 21:32:02 Empanada kernel: wls8: associate with xx:xx:xx:xx:xx:xx (try 
> 1/3)
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: Associated with 
> xx:xx:xx:xx:xx:xx
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: 
> CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> Jan 27 21:32:02 Empanada kernel: wls8: RX AssocResp from xx:xx:xx:xx:xx:xx 
> (capab=0x411 status=0 aid=6)
> Jan 27 21:32:02 Empanada kernel: wls8: associated
> Jan 27 21:32:02 Empanada NetworkManager[582]:   [1548646322.8693] 
> device (wls8): supplicant interface state: associating -> associated
> Jan 27 21:32:02 Empanada NetworkManager[582]:   [1548646322.8756] 
> device (wls8): supplicant interface state: associated -> 4-way handshake
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: WPA: Key negotiation 
> completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=CCMP]
> Jan 27 21:32:02 Empanada kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wls8: link 
> becomes ready
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: CTRL-EVENT-CONNECTED - 
> Connection to xx:xx:xx:xx:xx:xx completed [id=0 id_str=]
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: WPA: Failed to 
> configure IGTK to the driver
> Jan 27 21:32:02 Empanada wpa_supplicant[10450]: wls8: RSN: Failed to 
> configure IGTK

Could you please configure a more verbose debug level and paste the
lines related 

Bug#920954: ptunnel-ng: Incomplete debian/copyright?

[Chris Lamb]

Source: ptunnel-ng
Version: 1.32-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Thorsten Alteholz , 
ftpmas...@debian.org

Hi,

I just ACCEPTed ptunnel-ng from NEW but noticed it was missing 
attribution in debian/copyright for at least src/win32/*.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload. Thanks!


Regards,

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

Bug#920847: init-d-script: add do_restart_prepare and do_reload_prepare handlers

[Dmitry Bogatov]

control: tags -1 +confirmed

[2019-01-29 20:44] Mathieu Mirmont 
> Package: sysvinit
> Version: 2.93-3
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> My package uses init-d-script and relies on defining a custom
> "do_start_prepare" function to prevent starting the daemon if a
> specific file exists.
>
> While this works fine, it fails when the init.d script is invoked with
> "restart" or "reload". In this case the "do_start_prepare" function is
> not called. There doesn't seem to be a similar mechanism for "restart"
> and "reload". This makes my init.d script significantly more
> complicated to implement (cleanly).
>
> Please consider the attached patch.

Thank you for your contribution.  Your patch looks good, but given
upcoming freeze, to avoid surprises, I intend to upload your patch into
unstable after release. Upload to experimental is due in several weeks.

Will it do for you?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#920698: mosh-server not found

[Dmitry Bogatov]

control: tags -1 +wontfix

[2019-01-28 05:12] Keith Winstein 
> Hello -- unfortunately mosh-server does need to be installed on the server
> (it is sort of like ssh in this respect). You can either install it from a
> package (which probably requires root -- you would need to ask the
> sysadmin), or you can compile it from source, install it in your own home
> directory, and give the location when starting mosh (e.g. "mosh
> --server=/home/kaction/bin/mosh-server"). There are some instructions at
> https://mosh.org you may find helpful.

Oh, I see. Thank you. Tagging as wontfix for future reference.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#914788: Please don't enable getty services for tty devices that don't exist

[Dmitry Bogatov]

[2019-01-27 18:56] Andras Korn 
> > Complicated. And depends on $0 trickery. We, at sysvinit team, had
> > problems with $0 trickery.
>
> How is this trickery? We're just obtaining the name of the script being
> executed, and its path.

Relying on $0 makes me uneasy.  Because one day I may want to re-use this
code, but feed it another $0.  No, it is not theoretical issue.

> > What is so bad about cluttering environment of daemon?
>
> Normally you'd want to avoid passing unnecessary environment variables to
> daemons. Maybe they'll affect its operation in some way; maybe they'll
> affect a child process of the daemon that inherits them. It's relying on
> undefined behaviour.

I do not buy this argument.  For ages we started daemons with
/etc/init.d/{foo} scripts from root shell (and even with sudo), with all
kind of environment variables, including rather nasty ones, like GREP or
LESS, and we are still fine.

But probably executing services with `env -0' is good idea, thank you.

> > > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > > because the /etc/default/foo variables would be lost during the exec since
> > > we want to avoid exporting them.)
> >
> > This too. I want daemontools-style take precedence over sysvinit style.
>
> FWIW, I think the whole thing is creeping featurism,

One extra source of variables, implemented with 3 lines of shell? Well,
your definition of 'featurism' is much stricter then mine.

> but if you think you must do it, I'd prefer it being done sensibly --
> i.e. not depending on undefined behaviour, not leaking environment
> variables. I think this is a stronger argument than personal
> preference (yours or mine).

Sure. But see above.

> > And what if there were no tty on installation time, and after that they
> > appeared? (No idea, why, never dealt with devices without tty.)
>
> That's a pathological hypothetical case; I'd say we wait until it happens,
> and then deal with it. (You might also ask: what about hypothetical systems
> where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> always prevents getty from starting?)

Okay. I buy it. I will unconditionally include this code:

if ! test -c /dev/@TTY@ ; then
rm /etc/service/getty-@TTY@
exit 0
fi

and upload to experimental. Should there be no report of that
pathological case, I will merge these changes into unstable after
Buster.  Will it do for you?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#920953: ruby-haml-rails FTBFS: invalid byte sequence in US-ASCII (ArgumentError)

[Adrian Bunk]

Source: ruby-haml-rails
Version: 1.0.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=ruby-haml-rails=all=1.0.0-1=1548295203=0

...
┌──┐
│ Checking Rubygems dependency resolution on ruby2.5   │
└──┘

Invalid gemspec in [haml-rails.gemspec]: No such file or directory - git
/usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:145:in `gsub!': invalid byte 
sequence in US-ASCII (ArgumentError)
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:145:in `block in 
load_modified_gemspec'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:144:in `each'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:144:in 
`load_modified_gemspec'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:121:in `load_gemspec'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:34:in `block in 
initialize'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:33:in `chdir'
from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:33:in `initialize'
from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:77:in `new'
from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:77:in 
`do_check_dependencies'
from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:67:in `run_tests'
from /usr/bin/gem2deb-test-runner:61:in `'
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-haml-rails 
returned exit code 1
make: *** [debian/rules:18: binary-indep] Error 1

Bug#920687: ceni: Please rename the binary from "Ceni" to "ceni" and move it to the /

[Dmitry Bogatov]

control: tags -1 +confirmed

[2019-01-28 12:58] jim_p 
> part   text/plain 994
> Package: ceni
> Severity: minor
>
> Dear Maintainer,
>
> Please consider renaming /usr/bin/Ceni to /usr/bin/ceni. That's all :)
>
> I installed it as soon as I found out it has reached our repos and
> then I tried launching it as "ceni" with no luck.

There is more of it. There is also uppercased version of manpage;
.desktop file referes to uppercased version of binary; Ceni script
referes to itself with uppercased name. Sure, I can patch it all, but it
seems upstream favors the uppercased name.

Uppercased naming of binaries is quite unusual, but I can't recall it
being Policy violation.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#920618: initscripts: errors with /dev/shm on Hurd

[Dmitry Bogatov]

[2019-01-28 13:40] Samuel Thibault 
> > Do you mean, that you plan to resolve current bug via changes in
> > src:hurd?
>
> That's be the idea yes.
>
> > > The same patch creates /run/lock and /run/utmp, I guess initscripts
> > > handles that too?
> > 
> > Yes, initscripts handle them too. See /etc/init.d/bootmisc.sh
>
> Ok, can somebody check that things work fine when dropping that part
> too?

I wouldn't be me, sorry.

I start to lose track of recent Hurd issues. As I understand, this bug
should be reassigned to src:hurd.

If there are more issues in sysvinit=2.93-6, please file them to BTS.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --