Bug#908179: pkgsel: [INTL:fr] French debconf translation update

[Alban Vidal]

Package: pkgsel
Version: 0.58
Severity: wishlist
Tags: patch l10n


Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of pkgsel debconf templates to French.
# Copyright (C) 2004-2018, French l10n team 

# This file is distributed under the same license as the pkgsel package.
#
# Translators:
# Christian Perrier , 2002-2004.
# Pierre Machard , 2002-2004.
# Denis Barbier , 2002-2004.
# Philippe Batailler , 2002-2004.
# Michel Grentzinger , 2003-2004.
# Christian Perrier , 2005, 2006, 2007, 2008, 2009, 2010, 
2011.
# Alastair McKinstry , 2001.
# Cedric De Wilde , 2001.
# Christian Perrier , 2004, 2005, 2006, 2007, 2008, 2009, 
2010, 2012, 2013, 2014, 2015, 2016, 2017.
# Christophe Fergeau , 2000-2001.
# Christophe Merlet (RedFox) , 2001.
# Free Software Foundation, Inc., 2000-2001, 2004, 2005, 2006.
# Grégoire Colbert , 2001.
# Tobias Quathamer , 2007, 2008.
# Alban Vidal , 2018.
msgid ""
msgstr ""
"Project-Id-Version: pkgsel 0.58\n"
"Report-Msgid-Bugs-To: pkg...@packages.debian.org\n"
"POT-Creation-Date: 2018-06-27 14:00+0200\n"
"PO-Revision-Date: 2018-08-28 07:19+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: text
#. Description
#. Main menu item
#. should not be more than 55 columns
#. pkgsel is the module that installs packages by running tasksel to
#. select "tasks". Please use "install *software*" and not
#. "install *packages*" which is less adapted for non technical users
#: ../pkgsel.templates:1001
msgid "Select and install software"
msgstr "Choisir et installer des logiciels"

#. Type: text
#. Description
#. This appears in a progress bar when running pkgsel
#. The text is used when pkgsel is launched, before it installs packages
#: ../pkgsel.templates:2001
msgid "Setting up..."
msgstr "Mise en place…"

#. Type: text
#. Description
#. This appears in a progress bar when running pkgsel
#. The text is used when upgrading already installed packages.
#: ../pkgsel.templates:4001
msgid "Upgrading software..."
msgstr "Mise à niveau des logiciels…"

#. Type: text
#. Description
#. This appears in a progress bar when running pkgsel
#. The text is used when running tasksel to allow selecting packages
#. Tasksel will then display its own screens
#: ../pkgsel.templates:5001
msgid "Running tasksel..."
msgstr "Exécution de « tasksel »…"

#. Type: text
#. Description
#. This appears in a progress bar when running pkgsel
#. The text is used at the end of the installation phase while
#. cleaning up pkgsel's stuff
#: ../pkgsel.templates:6001
msgid "Cleaning up..."
msgstr "Nettoyage…"

#. Type: text
#. Description
#: ../pkgsel.templates:8001
msgid "Running ${SCRIPT}..."
msgstr "Exécution du script ${SCRIPT}…"

#. Type: select
#. Choices
#: ../pkgsel.templates:9001
msgid "No automatic updates"
msgstr "Pas de mises à jour automatiques"

#. Type: select
#. Choices
#: ../pkgsel.templates:9001
msgid "Install security updates automatically"
msgstr "Installation automatique des mises à jour de sécurité"

#. Type: select
#. Description
#: ../pkgsel.templates:9002
msgid "Updates management on this system:"
msgstr "Gestion des mises à jour sur ce système :"

#. Type: select
#. Description
#: ../pkgsel.templates:9002
msgid ""
"Applying updates on a frequent basis is an important part of keeping the "
"system secure."
msgstr ""
"La mise en œuvre régulière des mises à jour est un point important pour "
"conserver un système sécurisé."

#. Type: select
#. Description
#: ../pkgsel.templates:9002
msgid ""
"By default, security updates are not automatically installed, as security "
"advisories should be reviewed before manual installation of the updates "
"using standard package management tools."
msgstr ""
"Par défaut, les mises à jour de sécurité ne sont pas installées "
"automatiquement, car les annonces de sécurité doivent être examinées avant "
"l'installation manuelle des mises à jour en utilisant le gestionnaire de "
"paquets par défaut."

#. Type: select
#. Description
#: ../pkgsel.templates:9002
msgid ""
"Alternatively the unattended-upgrades package can be installed, which will "
"install security updates automatically. Note however that automatic "
"installation of updates may occasionally cause unexpected downtime of "
"services provided by this machine in the rare cases where the update is not "
"fully backward-compatible, or where the security advisory requires the "
"administrator to perform some other manual operation."
msgstr ""
"Sinon, le paquet unattended-upgrades peut être installé, automatisant les "
"mises à jour de sécurité. Cependant, veuillez noter que, "
"dans de rares cas, l'installation des mises à jour peut occasionnellement "
"provoquer un arrêt 

Bug#908178: tasksel: [INTL:fr] French debconf translation update

[Alban Vidal]

Package: tasksel
Version: 3.45
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of tasksel debconf templates to French.
# Copyright (C) 2013, 2017, 2018, French l10n team 

# This file is distributed under the same license as the tasksel package.
#
# Translators:
# Christian Perrier , 2004, 2005, 2006.
# Alban Vidal , 2018.
msgid ""
msgstr ""
"Project-Id-Version: tasksel 3.45\n"
"Report-Msgid-Bugs-To: task...@packages.debian.org\n"
"POT-Creation-Date: 2018-05-23 01:37+0200\n"
"PO-Revision-Date: 2018-08-28 07:02+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../templates:1001 ../templates:2001
msgid "Choose software to install:"
msgstr "Logiciels à installer :"

#. Type: multiselect
#. Description
#: ../templates:1001
msgid ""
"At the moment, only the core of the system is installed. To tune the system "
"to your needs, you can choose to install one or more of the following "
"predefined collections of software."
msgstr ""
"Actuellement, seul le système de base est installé. Pour adapter "
"l'installation à vos besoins, vous pouvez choisir d'installer un ou "
"plusieurs ensembles prédéfinis de logiciels."

#. Type: multiselect
#. Description
#: ../templates:2001
msgid ""
"You can choose to install one or more of the following predefined "
"collections of software."
msgstr ""
"Vous pouvez choisir d'installer un ou plusieurs des ensembles suivants de "
"logiciels."

#. Type: multiselect
#. Description
#: ../templates:3001
msgid "This can be preseeded to override the default desktop."
msgstr "Cela peut être préconfiguré pour sélectionner le bureau par défaut."

#. Type: title
#. Description
#: ../templates:4001
msgid "Software selection"
msgstr "Sélection des logiciels"

#~ msgid "${ORIGCHOICES}"
#~ msgstr "${CHOICES}"

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Alastair McKinstry]

On 06/09/2018 21:51, Jeff Squyres (jsquyres) wrote:

On Sep 6, 2018, at 2:19 PM, Adrian Bunk  wrote:

With thanks to Santiago Vila we finally figured out how to reproduce it.

 From a failed build log:
I: NOTICE: Log filtering will replace 'build/openmpi-LjweZK/openmpi-3.0.1' with 
'<>'
I: NOTICE: Log filtering will replace 'build/openmpi-LjweZK' with '<>'

Note the -L in the random string.


Excellent !

Now to figure how to patch libtool to escape / handle this properly. 
I'll try working on it today / this weekend



Oh wow, so your tmpdir just happens to contain "-L" and that causes the problem?

...unfortunately, I'm unable to replicate this issue.  :-\


I've been able to reproduce it.



Are you able to cause this problem running by hand?

Here's what I tried:

-
$ cd /home/jsquyres/openmpi-releases
$ mkdir -p build/openmpi-LjweZK
$ cd build/openmpi-LjweZK
$ tar xf ../../openmpi-3.0.1.tar.bz2
$ cd openmpi-3.0.1
$ ./configure --prefix=$HOME/bogus |& tee config.out
$ make -j 32 |& tee make.out
-

I also tried with a VPATH build (same general recipe as above, but in a vpath 
subdir)

Neither of these resulted in the problem.

What's different / why can't I reproduce?

I am using:

Autoconf 2.69
Automake 1.15 (*** you are using 1.15.1 -- do we think that makes a difference?)
Libtool 2.4.6

I am also using gcc 7.3.0.

Here's the directory I built in:

 /home/jsquyres/openmpi-releases/build/openmpi-LjweZK/openmpi-3.0.1

I'm *not* running on Debian -- I'm running on an RHEL machine -- but this seems 
like a path issue, not a distro issue, so I'm kinda hoping that that doesn't 
matter...

Any thoughts?


Something about Debian's libtool still implicated, then.

regards

Alastair

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#908160: FTBFS: build from source fails with undefined reference to `minor'

[Ritesh Raj Sarraf]

Control: tag -1 +pending


Hello Scott,


You patch did not apply clean. But anyways, I've looked at the change
and applied it myself. It will be part of the next upload.


Thanks,
Ritesh


On Thu, 2018-09-06 at 16:00 -0400, Scott Moser wrote:
> Package: open-iscsi
> Version: 2.0.874-5ubuntu7
> Severity: serious
> Tags: patch
> Justification: fails to build from source (but built successfully in
> the past)
> 
> Current build of open-iscsi (2.0.874-5ubuntu7) will fail to build
> from
> source.
> 
> Build fails with:
> 
>   ./iscsiuio/src/unix/libs/bnx2x.c:754: undefined reference to
> `minor'
>   collect2: error: ld returned 1 exit status
> 
> 
> This is reported to Ubuntu in bug 1791154
>   https://bugs.launchpad.net/bugs/1791154
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#907925: jhead: Interger overflow while running jhead

[Hanfang Zhang]

Hi Salvatore,

I have done that and the CVE ID is CVE-2018-16554. But the status of it is
preserved. Thanks.

Regards,
Hanfang

Salvatore Bonaccorso  于2018年9月5日周三 下午11:05写道：

> Hi Hanfang,
>
> On Tue, Sep 04, 2018 at 03:32:02PM +0800, Hanfang Zhang wrote:
> > This bug was found by Hanfang Zhang at Sichuan University. Request a
> > CVE ID. Thanks.
>
> Can you please request a CVE via the webform at
> https://cveform.mitre.org/ and once the CVE assigned loop it back
> here?
>
> Thanks already,
>
> Regards,
> Salvatore
>

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Carsten Schoenert]

Am 06.09.18 um 22:45 schrieb Markus Koschany:
> FF-ESR will soon be upgraded to the new Firefox ESR release and that is
> not compatible with XUL addons anymore. It is technically possible to
> support this use case but it is not supported by us.

Correct, FF 60esr should be entering stable-security more or less within
the next hours, so told by by security team yesterday. It would be just
a waist of time to create a possibility of co-installation.

(BTW: Thunderbird will follow in the next days.)

And I never thought about such a possibility in detail simply because
the "original" Debian way is to have just one FF ESR package on the
system. If users install a separate additional FF package they are on
their own, but the system is flexible enough to get this handled.

-- 
Regards
Carsten Schoenert

Bug#908177: evince: Rename of desktop file from evince.desktop to org.gnome.Evince.desktop breaks MIME/mailcap ordering (PDFs open with gimp)

[Michael Biebl]

Am 07.09.18 um 05:49 schrieb Josh Triplett:
> Package: evince
> Version: 3.30.0-1
> Severity: important
> 
> evince 3.30 renamed the desktop file from evince.desktop to
> org.gnome.Evince.desktop. update-mime, the tool to generate
> /etc/mailcap, processes desktop files in order by name. Because of this
> rename, GIMP now has a higher priority for PDF and PostScript files than
> Evince does, causing mutt and similar to open PDF and PostScript files
> with GIMP by default.

What would you suggest should be done about this?
Renaming the desktop file back to evince.desktop is not really an option.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#908177: evince: Rename of desktop file from evince.desktop to org.gnome.Evince.desktop breaks MIME/mailcap ordering (PDFs open with gimp)

[Josh Triplett]

Package: evince
Version: 3.30.0-1
Severity: important

evince 3.30 renamed the desktop file from evince.desktop to
org.gnome.Evince.desktop. update-mime, the tool to generate
/etc/mailcap, processes desktop files in order by name. Because of this
rename, GIMP now has a higher priority for PDF and PostScript files than
Evince does, causing mutt and similar to open PDF and PostScript files
with GIMP by default.

Bug#908176: jhead: Buffer Overflow while running jhead

[Hanfang Zhang]

Package: jhead
Version: 1:3.00-7
Vulerability type: Buffer Overflow

An buffer overflow bug was found in jhead, which allows attackers to casue
a denial of service via a crafted JPEG file.

Components: gpsinfo.c -> ProcessGpsInfo() ->line 164
```
case TAG_GPS_ALT://BUG
sprintf(ImageInfo.GpsAlt + 1, "%.2fm",
ConvertAnyFormat(ValuePtr, Format));
break;
```
Output:
```
gdb-peda$ bt
#0  0x77739428 in __GI_raise (sig=sig@entry=0x6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7773b02a in __GI_abort () at abort.c:89
#2  0x7777b7ea in __libc_message (do_abort=do_abort@entry=0x2,
fmt=fmt@entry=0x7789349f "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x7781d15c in __GI___fortify_fail (msg=,
msg@entry=0x77893430 "buffer overflow detected")
at fortify_fail.c:37
#4  0x7781b160 in __GI___chk_fail () at chk_fail.c:28
#5  0x7781a6c9 in _IO_str_chk_overflow (fp=,
c=) at vsprintf_chk.c:31
#6  0x7777f6b0 in __GI__IO_default_xsputn (f=0x7fff79b0,
data=, n=0x19) at genops.c:455
#7  0x7775625a in __GI___printf_fp_l (fp=fp@entry=0x7fff79b0,
loc=, info=info@entry=0x7fff7530,
args=args@entry=0x7fff7510) at printf_fp.c:1236
#8  0x77756bd9 in ___printf_fp (fp=fp@entry=0x7fff79b0,
info=info@entry=0x7fff7530,
args=args@entry=0x7fff7510) at printf_fp.c:1257
#9  0x777530b9 in _IO_vfprintf_internal (s=s@entry=0x7fff79b0,
format=,
format@entry=0x40f640 "%.2fm", ap=ap@entry=0x7fff7ae8) at
vfprintf.c:1631
#10 0x7781a754 in ___vsprintf_chk (s=0x61659f 
"944473296573929042", flags=0x1, slen=0x13,
format=0x40f640 "%.2fm", args=args@entry=0x7fff7ae8) at
vsprintf_chk.c:82
#11 0x7781a6ad in ___sprintf_chk (s=,
flags=flags@entry=0x1, slen=slen@entry=0x13,
format=format@entry=0x40f640 "%.2fm") at sprintf_chk.c:31
#12 0x00409649 in sprintf (__fmt=0x40f640 "%.2fm", __s=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:33
#13 ProcessGpsInfo (DirStart=,
OffsetBase=OffsetBase@entry=0x6182d8
"MM", ExifLength=ExifLength@entry=0x13e)
at gpsinfo.c:164
#14 0x00407980 in ProcessExifDir (DirStart=DirStart@entry=0x6182e0
"", OffsetBase=OffsetBase@entry=0x6182d8 "MM",
ExifLength=ExifLength@entry=0x13e, NestingLevel=NestingLevel@entry=0x0)
at exif.c:867
#15 0x00407b86 in process_EXIF (ExifSection=ExifSection@entry=0x6182d0
"\001FExif", length=length@entry=0x146)
at exif.c:1035
#16 0x00404ab3 in ReadJpegSections (infile=infile@entry=0x617070,
ReadMode=ReadMode@entry=READ_METADATA) at jpgfile.c:287
#17 0x00404dce in ReadJpegSections (ReadMode=READ_METADATA,
infile=0x617070) at jpgfile.c:126
#18 ReadJpegFile (FileName=FileName@entry=0x7fffe376 "poc",
ReadMode=READ_METADATA) at jpgfile.c:375
#19 0x00402ac1 in ProcessFile (FileName=0x7fffe376 "poc") at
jhead.c:896
#20 0x0040183c in main (argc=argc@entry=0x2,
argv=argv@entry=0x7fffdff8)
at jhead.c:1729
#21 0x77724830 in __libc_start_main (main=0x4016b0 ,
argc=0x2, argv=0x7fffdff8, init=,
fini=, rtld_fini=,
stack_end=0x7fffdfe8) at ../csu/libc-start.c:291
#22 0x00402219 in _start ()

```
ConvertAnyFormat function converts ValuePtr to another data type by using
Format value. When Format value equals to 11, the ValuePtr should be
convert to double type. There is no type checking in the parameters in
sprintf function. In this case, “%.2fm” corresponds to the float type data,
ConvertAnyFormat() corresponds to the double type data. So it causes
undesirable behavior including buffer overflow.  Replacing sprintf with
snprintf may fix this bug.


poc
Description: Binary data

Bug#886358: chromium: Enable Hangouts screensharing extension

[Josh Triplett]

reopen 886358
thanks

On Mon, 27 Aug 2018 17:20:14 +0200 Philipp Hahn  wrote:
> Sorry for re-opeing this bug, but it cost me some time to find that
> Debian disables the shreen sharing extention in its build of chromium.
> 
> > This is the intended default configuration.  For those that would like
> > it enabled in their version, the suggested patch is correct.
> 
> Can you at least clarify *why* that feature is disabled? Neither my web
> search nor looking in the Debian source package found any hint:
> * Does it make the package non-free/contrib
> * Is it an security issue?
> * or is there some other technical reason to disable it in Debian?
> 
> After re-compiling chromium with that extension enabled I was finally
> able to use the screen sharing extension with my colleges.

The new text in README.Debian does not answer any of these questions.
Quoting the relevant section in its entirety:

> Built-in Extensions
> ===
>
> The debian package disables most built-in upstream extensions by default
> since users have stated concern about enabled features that they have not
> specifically requested.  This includes things like Google Hangouts, etc.
>
> There are two exceptions, the pdfium extension for viewing pdf files
> directly in the browser and the two-factor authentication extension.
>
> If you would like to use one of the upstream built-ins that are currently
> disabled, please edit debian/rules to enable it and rebuild the package
> from source.  See debian bug #886358 for more information.

This is not in any way an explanation. "users have stated concern" -
*what* concern?

Rebuilding the Chromium package is not a viable path for most people,
especially since the package gets updated regularly.

Having this disabled breaks the ability to do screen sharing in Hangouts
meetings.

Having this enabled causes...what problem, precisely?

I'm not suggesting that this extension is the ideal method to enable
that functionality; indeed, there are more standard WebRTC features that
could work instead. But that's not the question at hand.

At the very least, this needs an explanation commensurate with "why is
it important to break people's ability to do screen sharing by default
in a way they won't easily discover and can't easily fix". If there's a
reason that outweighs that, it needs to be documented. And if there
*isn't* a reason that outweighs that, then please enable this extension.

Bug#908175: ITP: xxhash -- Extremely fast hash algorithm

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 

* Package name: xxhash
  Version : 0.6.5
  Upstream Author : Yann Collet
* URL : http://www.xxhash.com/
* License : GPL (utility), BSD (library)
  Programming Lang: C
  Description : Extremely fast hash algorithm

xxHash is an Extremely fast Hash algorithm, running at RAM speed limits.
It successfully completes the SMHasher test suite which evaluates collision,
dispersion and randomness qualities of hash functions. Code is highly portable,
and hashes are identical on all platforms (little / big endian).


Necessary for newer versions of dvisvgm.
Only Go versions (3!) and R is available:
golang-github-cespare-xxhash-dev - implementation of the 64-bit xxHash 
algorithm (XXH64)
golang-github-oneofone-xxhash-dev - native implementation of the 
excellent XXHash hashing algorithm
golang-github-pierrec-xxhash-dev - pure Go implementation of xxHash (32 
and 64 bits versions)
r-cran-digest - GNU R package for 'hash digest' of R data structures

Best

Norbert

Bug#905262: RFS: golang-github-tcnksm-go-gitconfig

[Jongmin Kim]

On Thu, Sep 06, 2018 at 01:39:48PM -0400, Alexandre Viau wrote:
> On 2018-09-05 10:42 PM, Jongmin Kim wrote:
> > Sorry. Could you please wipe the team's repository? I will upload there.
> > Thank you!
> 
> I have deleted the repository.
> 
> Feel free to re-create it and ask me to review your new packaging.

Thanks a lot. I created our team's repository and pushed:
https://salsa.debian.org/go-team/packages/golang-github-tcnksm-go-gitconfig

Now it's ready for packaging. Could you please review again and upload?
Thank you!


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#905240: RFS: golang-github-rivo-tview

[Jongmin Kim]

On Thu, Sep 06, 2018 at 01:37:48PM -0400, Alexandre Viau wrote:
> On 2018-09-05 10:36 PM, Jongmin Kim wrote:
> > On Wed, Sep 05, 2018 at 09:54:50PM -0400, Alexandre Viau wrote:
> >> On 2018-09-01 02:05 AM, Jongmin Kim wrote:
> >>> I tried to make the repository to keep the upstream's commit history,
> >>> instead of using 'pristine-tar'. In result, I created again a new
> >>> repository in my namespace:
> >>> https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview
> >>>
> >>> Would you please consider to use this for packaging, instead of using
> >>> our team's repo? Thank you!
> >> Are you suggesting that we replace the team's repository? Or are you
> >> suggesting to keep it in your namespace?
> >>
> >> Are you able to just update the team's repository to the latest and
> >> greatest and have me review that instead?
> >>
> >> It may be that you are not able to overwrite existing commits. In that
> >> case, I am willing to wipe the repository for you.
> >>
> >> Let me know what you need.
> > Ah, I suggest that we replace the team's repository.
> >
> > I cannot overwrite the existing commits (because all the branches are
> > protected, and I don't have a right to overwrite them). Would you please
> > wipe the team's repository? Then I will upload there. Thank you!
> 
> I have deleted the repository.
> 
> Feel free to re-create it and ask me to review your new packaging.

Thanks a lot. I created our team's repository and pushed:
https://salsa.debian.org/go-team/packages/golang-github-rivo-tview

Now it's ready for packaging. Could you please review again and upload?
Thank you!


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#908172: Acknowledgement (ITP: fortio -- Fortio load testing library, command line tool, advanced echo server and web UI in go (golang). Allows to specify a set query-per-second load and record lat

[Laurent Demailly]

Started the work on https://github.com/fortio/fortio/pull/300/files
but could use some help and guidance to make it actually work and be correct

Bug#908174: icc-profiles: several profiles should be moved to icc-profiles-free

[Norbert Preining]

Package: icc-profiles
Version: 2.1-2
Severity: important

Hi Jonas,

it was nice to meet you in Taiwan, great to see people in person ;-)

I just saw that you are uploading/maintaining icc-profiles, and we had a
some discussion about this on the TeX Live mailing list.

I think that many of the profiles are free and should be moved to
icc-profiles-free. Quoting just one license statement:
License: ICC
 This profile is made available by the International Color Consortium,
 and may be copied, distributed, embedded, made, used, and sold without
 restriction. Altered versions of this profile shall have the original
 identification and copyright information removed and shall not be
 misrepresented as the original profile.
Comment:
 Apparently applies generally to color profiles with ICC listed as
 copyright holder in the embedded Creator field, according to
 .
This *is* a free license. In former times there was a lintian error
about this, but on my pushing and contacting the ftp-masters this was
changed and these are now considered free. Please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786946
for the start on the discussion and the ftp-master clarification request
in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787338
My guess is that many more of these profiles in icc-profiles are free
and should be moved, the one that started the discussion in the first
bug report 
sRGB_IEC61966-2-1_black_scaled.icc
being a notable exception because it is NOT covered by the same
licensing terms as the others.

Thanks

Norbert


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

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

icc-profiles depends on no packages.

Versions of packages icc-profiles recommends:
ii  icc-profiles-free  2.0.1+dfsg-1

icc-profiles suggests no packages.

-- no debconf information
Norbert

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

Bug#908170: texlive-latex-extra: \documentclass[italian]{europecv} causes "File ended while scanning definition of \ecv@cvofkey"

[Norbert Preining]

tags 908170 + pending
thanks

Hi Francesco,

(btw, wintermute is also the name of an episode in The Long Dark, one of
my favorite games ;-)

> By trial and error, I found out that the attached patch fixes (or works
> around) the issue.
> 
> Is there a better fix, by chance?

No, this is the correct fix, it is a typo to have the \ there.

It is already fixed upstream at
https://github.com/gsilano/EuropeCV/
see commit

https://github.com/gsilano/EuropeCV/commit/b168ca441b2aa7cd8b289f71fd2a67185085f21a
and will be in the next release.

Best

Norbert

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

Bug#854388: systemd: lid switch not detected on acer chromebook

[Michael Biebl]

Control: tags -1 + moreinfo

On Mon, 6 Feb 2017 15:45:20 +0100 "Milan P. Stanic"  wrote:
> Package: systemd
> Version: 232-15
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>Installed Debian on the acer chromebook R13 (mediatek MT8173 SOC,
>board called elm (oak)) armv8 with the kernel source from chromeos
>site and built myself for that device.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>By closing screen logind does not detect lid switch
> 
>* What was the outcome of this action?
>Device does not suspend
> 
>* What outcome did you expect instead?
>Suspend
> 
> During boot kernel recognizes that the device have lid switch, here is
> the log from journalctl:
> Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> property of node '/gpio-keys/lid[0]' - status (0)
> Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> property of node '/gpio-keys/power[0]' - status (0)
> Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> property of node '/gpio-keys/tablet_mode[0]' - status (0)
> Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> property of node '/gpio-keys/volume_down[0]' - status (0)
> Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> property of node '/gpio-keys/volume_up[0]' - status (0)
> Feb 05 17:20:01 zarya kernel: input: gpio-keys as 
> /devices/gpio-keys/input/input5
> 
> but systemd-logind does not report that it is watching any of these
> keys, as it does on another armv7 or amd64 where I tested lid switch.

what's the output of evtest on those devices?

> evtest detect all these when I run it to test does kernel works, here it
> is output of invoking it:
> 
> No device specified, trying to scan all of /dev/input/event*
> Available devices:
> /dev/input/event0:cros_ec
> /dev/input/event1:Elan Touchscreen
> /dev/input/event2:Elan Touchpad
> /dev/input/event3:mtk-rt5650 Headset Jack
> /dev/input/event4:mtk-rt5650 HDMI Jack
> /dev/input/event5:gpio-keys
> Select the device event number [0-5]: 5
> Input driver version is 1.0.1
> Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
> Input device name: "gpio-keys"
> Supported events:
> Event type 0 (EV_SYN)
> Event type 1 (EV_KEY)
> Event code 114 (KEY_VOLUMEDOWN)
> Event code 115 (KEY_VOLUMEUP)
> Event code 116 (KEY_POWER)
> Event type 5 (EV_SW)
> Event code 0 (SW_LID) state 0
> Event code 1 (SW_TABLET_MODE) state 0
> Properties:
> Testing ... (interrupt to exit)
> Event: time 1486391966.918428, type 5 (EV_SW), code 0 (SW_LID), value 1


This looks quite a bit different here:

# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
...
Select the device event number [0-20]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0
Input device name: "Lid Switch"
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
Event code 0 (SW_LID) state 0


I wonder if logind does not detect the lid switch device as it
apparently also does all sort of other events.

Can you post the output of running
SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

You need to stop the already running logind via
systemctl stop systemd-logind (make sure to run those commands from a
tty and not from within X)




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841740: systemd periodically kills gnome-terminal session

[Michael Biebl]

On Sun, 23 Oct 2016 00:18:55 +0100 luke  wrote:
> Package: systemd
> Version: 231-9
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> systemd is periodically killing a bunch of userspace daemons
> (including gnome terminal sessions, and gvfs)
> 
> ```

Luke, do you still run into this issue on a up-to-date buster/sid system?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#810886: udev: Boggus interface name for 3G/LTE modem

[Michael Biebl]

On Wed, 13 Jan 2016 12:46:07 +0100 m...@linux.it (Marco d'Itri) wrote:
> On Jan 13, Laurent Bigonville  wrote:
> 
> > On my new lenovo laptop, the interface name for the 3G/LTE modem seems
> > boggus: enx
> It really reports ff:ff:ff:ff:ff:ff as its own MAC address, so...
> 
> > cdc_ncm 2-4:1.0 usb0: register 'cdc_ncm' at usb-:00:14.0-4, CDC NCM, 
> > ff:ff:ff:ff:ff:ff
> > cdc_ncm 2-4:1.0 enx: renamed from usb0
> Is this a firmware bug or does it need to be configured by some 
> userspace tool?

bigon, seems we somehow got stuck at this point.
Can you follow up here.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905090: wine-development: Causing SEGV when using Qt.

[Michael Gilbert]

control: tag -1 upstream
control: severity -1 minor

This might be this upstream bug:
https://bugs.winehq.org/show_bug.cgi?id=45199

3.13 was the first version built with gcc8.  You could try rebuilding
with either gcc7 or with -O1 instead of -O2.

Best wishes,
Mike

Bug#720520: lesspipe advises using missing mkisofs package

[Kenyon Ralph]

Package: less
Version: 481-2.1
Tags: patch
Followup-For: Bug #720520

Dear Maintainer,

Patch attached.

BTW, it would be easier to make contributions if the packaging were in
a git repository hosted on https://salsa.debian.org/.

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

Kernel: Linux 4.15.13-x86_64-linode106 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages less depends on:
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u3
ii  libtinfo56.0+20161126-1+deb9u2

less recommends no packages.

less suggests no packages.

-- no debconf information
--- lesspipe.orig   2018-09-06 17:27:05.235401068 -0700
+++ lesspipe2018-09-06 17:29:21.739432651 -0700
@@ -141,7 +141,7 @@
if [ -x "`which isoinfo`" ]; then iso_list "$1"
else
echo "No isoinfo available"
-   echo "Install mkisofs to view ISO 
images"
+   echo "Install genisoimage to view ISO 
images"
fi
;;
 
@@ -150,7 +150,7 @@
file "$1" | grep -q ISO\.9660 && 
iso_list "$1"
else
echo "No isoinfo available"
-   echo "Install mkisofs to view ISO 
images"
+   echo "Install genisoimage to view ISO 
images"
fi
;;
 

Bug#908088: [Pkg-utopia-maintainers] Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

On 07/09/2018 11:38, Michael Biebl wrote:

It's also not necessary to send more screenshots.


I think I have covered the range of behaviours. I will only provide more 
screenshots if I think they provide compelling evidence as to the cause. 
 :-)


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908088: [Pkg-utopia-maintainers] Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

On 07/09/2018 11:33, Michael Biebl wrote:

On 9/7/18 01:15, Ben Caradoc-Davies wrote:

Another reboot, and a different set of corruption. A mostly black
background with a few pixels of grey and black garbage at the top left.
Screenshot attached.

I can't reproduce the problem (using openbox+wmdocker)
So I suspect this might be related to the XFCE tray.


Thanks, Michael. There are some similar reports for xfce4-panel, but 
they predate GTK 3.24. I will reassign this bug to xfce4-panel. I am 
picking xfce4-panel because it provides the systray, which I think is 
the "Notification Area", in which nm-applet is displayed.


I tried changing themes and the behaviour did not change.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908173: dump1090-mutability: German debconf translation of dump1090

[Mathias F. Popp]

Package: dump1090-mutability
Version: 1.15-20180310
Severity: normal
Tags: l10n

Dear Maintainer,

find attached the German language debconf PO-file.

We ran into issues with this template:

#. Type: string
#. Description
#: ../dump1090-mutability.templates:10001
msgid ""
"Additionally, if the maximum range is larger than 180NM, when local position "
"decoding is used (when insufficient position messages have been received for "
"global position decoding), it is limited to only those positions that would "
"unambiguously decode to a single position within the given receiver range."
msgstr ""



I took the liberty and rearranged that sentence:


#. Type: string
#. Description
#: ../dump1090-mutability.templates:10001
msgid ""
"Additionally, if the maximum range is larger than 180NM, when local position "
"decoding is used (when insufficient position messages have been received for "
"global position decoding), it is limited to only those positions that would "
"unambiguously decode to a single position within the given receiver range."

msgstr ""
"Für den Fall, dass die maximale Reichweite größer als 180 NM ist, gilt "
"außerdem: \n"
"Wenn zu wenig Standortnachrichten für eine globale Positionsdekodierung "
"empfangen wurden und daher die lokale Positionsdekodierung durchgeführt "
"wird, bleibt diese begrenzt auf jene Positionen, die sich auf einen "
"eindeutigen Standort innerhalb der Reichweite des Empfängers auflösen lassen."


I hope, it's still correct and that you may find the alternative English 
version useful.


Kind regards,

Mathias

Bug#809321: systemd-rfkill state save/restore issues

[Michael Biebl]

Control: tags -1 + moreinfo



On Tue, 29 Dec 2015 11:49:32 +0100 Yuri D'Elia  wrote:
> Package: systemd
> Version: 228-2+b1
> Severity: normal
> 
> [... after a few months wondering why wifi/rfkill doesn't work anymore as it
> should, I bump into a newfound systemd-rfkill.service/socket]
> 
> I'd like my system to start soft-killed by default. I can do that with
> laptop-mode-tools or tlp, but now both conflict in behavior with this service.
> 
> Fine for me, but apparently there's no way to make systemd-rfkill do what I
> want.
> 
> My first question would be, why exactly do I need a *kernel* parameter
> (systemd.restore_state) to change the restore behavior?
> 
> Looks like we require the state directory to be mounted, so there's no reason
> this cannot be specified there. I get this might be useful for boot issues, 
> but
> only in *addition* to a configuration file.
> 
> Second, restore_state=0 doesn't prevent (as stated) to save at shutdown. If I
> could prevent state changes to be saved, I would be fine to restore from my
> (manually set) state.

Is this still an issue with v239?
TBH, I'm not quite sure what your particular problem is.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#842760: localectl documentation bad, many problems

[Michael Biebl]

Control: tags -1 help

On Mon, 31 Oct 2016 13:29:39 + David Lawyer  wrote:
> Package: systemd
> Version 231-4
> 
> It seems that the keymap system is not only poorly documented but that
> "man localectl" isn't clear.

It would be great if you could send patches for the improving the
documentation, best upstream at https://github.com/systemd/systemd/

Ideally, one commit for each separate issue you see, so the changes can
be reviewed more easily.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#864341: systemd-sysctl: failed to apply sysctl config at bootup

[Michael Biebl]

On Wed, 30 Aug 2017 08:30:55 +0200 Arturo Borrero Gonzalez
 wrote:
> Hi,
> 
> any news? We are being hit by this bug, which is a bit annoying.
> Are upstream systemd developers aware of this issue?
> 

I don't see a systemd bug here, tbh. So I didn't raise this upstream.

I might be completely wrong on this one though, so feel free to raise
this upstream yourself.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#898260: systemd: HP notebook ZBook 17 G4 - WLAN hardware button not working

[Michael Biebl]

On Mon, 25 Jun 2018 00:35:50 +0200 =?ISO-8859-1?Q?Ren=E9?= Krell
 wrote:
> Hello Michael,
> 
> yes, I'm interested, but I still had no success when following the
> rough advises. I need more time for another attempt.

Any updates? Did you have success and forwarded this upstream?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905024: systemd: systemctl --host=... status foo.service breaks terminal without dbus

[Michael Biebl]

On Mon, 30 Jul 2018 20:35:32 +0200 Michael Prokop  wrote:
> Package: systemd
> Version: 239-7
> Severity: normal
> 
> Hi,
> 
> this bug report is about an issue which I consider a usability
> issue. I'm happy to forward/discuss this with upstream, though I'd
> like to discuss this within Debian and pkg-systemd team before.
> 
> When invoking:
> 
>   # systemctl --host=... status ssh.service
> 
> then the terminal kind of breaks, if dbus isn't present.
> For example if `PermitRootLogin yes` is set in sshd_config
> and trying to connect to the local system *without* dbus being
> present I get:
> 
>   root@debian-sid01:~# systemctl --host=$(hostname) status ssh.service
>   root@debian-sid01's password:
>   root@debian-sid01:~# 
> root@debian-sid01:~#·root@debian-sid01:~#·root@debian-sid01:~#·root@debian-sid01:~#·
> 
> So whenever pressing the  key the prompt gets worse (and only
> a `reset` fixes that). :) As soon as dbus is present/available it
> works as intended though.
> 
> This is quite irritating, not even getting an error/warning message.
> 
> I'm aware that dbus is inside Recommends and withouth dbus quite
> some functionality is missing, though I'm wondering if there's
> anything that could be improved here? Any opinions/ideas?


This sounds like an upstream issue, so it's probably best to raise it
there. On the other hand, dbus-less systems are considered very much
special cases by upstream, so I'm not sure how sympathetic to this issue
they will be. But you can try.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#904913: systemd: systemctl cat 'foo*' (using shellglob patterns) only lists active units

[Michael Biebl]

On Sun, 5 Aug 2018 10:02:44 +0200 Michael Biebl  wrote:

> So yes, this sounds like a bug to me and it would be great if you can
> raise this upstream.

Just curious, did you get around to file an upstream bug report?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905381: systemd FTCBFS for arm64: uses the build architecture compiler/linker for src/boot/efi

[Michael Biebl]

On 9/7/18 01:49, Michael Biebl wrote:
> Once the package has been reviewed and merged upstream
s/package/patch/, just to avoid confusion

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905503: networkd doesn't like fritzbox' IPv6 announcement, interface degraded

[Michael Biebl]

Control: tags -1 + help

Hi Marc

On Fri, 10 Aug 2018 20:29:51 +0200 Marc Haber
 wrote:
> The Fritzbox is an extremely common DSL router in middle europe, and
> dual-stack networking is becoming increasingly common. Deutsche Telekom
> and 1&1, two of Germany's largest ISPs for consumer DSL, both provide
> dual-stacked Internet. This issue should be addressed in stretch.

I'm happy to consider cherry-picking the necessary commits for stretch if
a/ someone figures out the necessary upstream commits
b/ the commits are (easily) backportable and not too invasive
c/ tests the resulting package

I can do b/, i.e. the backport/cherry-pick/review part, but would rely
on help with a/ and c/ (as I have no setup to debug and test this)

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?





signature.asc
Description: OpenPGP digital signature

Bug#908172: ITP: fortio -- Fortio load testing library, command line tool, advanced echo server and web UI in go (golang). Allows to specify a set query-per-second load and record latency histograms a

[Laurent Demailly]

Package: wnpp
Severity: wishlist
Owner: Laurent Demailly 

* Package name: fortio
  Version : 1.2.1
  Upstream Author : Laurent Demailly 
* URL : https://github.com/fortio/fortio
* License : Apache 2.0
  Programming Lang: Go
  Description : Fortio load testing library, command line tool,
advanced echo server and web UI in go (golang). Allows to specify a
set query-per-second load and record latency histograms and other
useful stats.


See https://fortio.org and https://github.com/fortio/fortio/#fortio

Fairly wide use in containers/micro services and golang land (istio, kubernetes)
and generally useful advanced load testing. Compares to wrk and httpbin:
https://github.com/fortio/fortio/wiki/FAQ#how-is-fortio-different-from-wrk

I do need a sponsor and would love co maintainers

Bug#905381: systemd FTCBFS for arm64: uses the build architecture compiler/linker for src/boot/efi

[Michael Biebl]

On Fri, 3 Aug 2018 22:17:20 +0200 Michael Biebl  wrote:
> Hi
> 
> Am 03.08.2018 um 22:08 schrieb Helmut Grohne:
> > In any case, the attached patch fixes the cross build problem for arm64.
> > Please consider applying or improving it.
> 
> It would be great if you could submit your patch as PR upstream at
> https://github.com/systemd/systemd

Once the package has been reviewed and merged upstream, I'm happy to
cherry-pick it into the Debian package.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#908171: sssd: please package for stretch-backports

[Jerome Charaoui]

Source: sssd
Version: 1.15.0-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please package sssd version 1.16.3 (or later) for stretch-backports.

I recently hit a serious issue with version 1.15.0-3 of the sssd package on
stretch. The system would become unresponsive for long periods (up to a few
hours) if many users attempted login in quick succession.

Installing my own backport of version 1.16.3 fixed the problem.

Thank you,

- -- Jerome



- -- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEC1ozuKJtYBCcUJxsg+M719TdTKEFAluRteQSHGplcm9tZUBy
aXNldXAubmV0AAoJEIPjO9fU3UyhvNYP/0bDfFXE4ASkB44tOntMO8xFwolnKIiM
e1jj3u/2IMzLlKLCBOPf2kmeyqTJM6x7eBUaYMyJ9luABkxtQy2MJ7awCEQ2wn5Y
KaAlcQxnsQ2goNE7N1i8xhKkih43DMoYcMOmk6SGTUXCOq0hBXg1TRqA3cd1MIKv
+lZqAeBhzCEWnQY8kRMMxFe/ie9cI9PEjsPZ2XRFKyD7fNLOcBvcuiQSGAWKcm95
3Qo4Z45rmUCG4euPeC4FD7oXY9xaQhmVgEDR5K/Y+weHZOtQNsJHYseOTLKFjIDK
gFBtVMVOS3cuAERDpp3iL6Gb0MG5uzMhgq3fA0lHoehKkaAckQMUF+5Alado8+j9
9sJBAnWzgh+gIThAim/c/87xfdaaBfisTLbexbBih0MNfCBR+hBHfMhm80o27eyE
Fq61l3MaB8wnGqp168lXBcK3f05u1meLq5pAhM+bOEzX64SL9PSfVwRjEUo+bYqX
faylGTDgHNQHt5zm9ybWlv6hPB3n/t+WwryYLMirfhcgNVkOxvbt9T3O/8KDGZxa
jc6M3/G0CX4qOPt+8bxZWAYgWa6/WQuRALZOvY7+Ij2T4wn3aMz5UPqGP5WVF5S3
+yu6bKueGsspQb2kvXUlmK2EDr1eQgvkpEkYHCptaTMeikeBamnCOj97sgmPTIUi
Lphmp1d6xbH1
=f/ep
-END PGP SIGNATURE-

Bug#908088: [Pkg-utopia-maintainers] Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Michael Biebl]

On 9/7/18 01:33, Michael Biebl wrote:
> On 9/7/18 01:15, Ben Caradoc-Davies wrote:
>> Another reboot, and a different set of corruption. A mostly black
>> background with a few pixels of grey and black garbage at the top left.
>> Screenshot attached.
> 
> I can't reproduce the problem (using openbox+wmdocker)

Correction: openbox+tint2

It's also not necessary to send more screenshots.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#842683: ia32 builds

[dann frazier]

I spent some time trying to get a 32-bit OVMF image to build, but I
haven't been successful. Each of the EdkShellPkg, FatPkg and
OvmfPkgIa32 packages fail to build in unique ways.

Bug#908088: [Pkg-utopia-maintainers] Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Michael Biebl]

On 9/7/18 01:15, Ben Caradoc-Davies wrote:
> Another reboot, and a different set of corruption. A mostly black
> background with a few pixels of grey and black garbage at the top left.
> Screenshot attached.

I can't reproduce the problem (using openbox+wmdocker)
So I suspect this might be related to the XFCE tray.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#901180: release notes fails to build in a clean checkout

[Héctor Orón Martínez]

Hello
Missatge de Baptiste Jammet  del dia dj., 6 de
set. 2018 a les 19:57:
>
> Hello,
>
> Dixit Miroslav Kure, le 04/09/2018 :
>
> >I believe cs translation was excluded from builds quite some years ago,
> >so if it got reactivated again, please disable it / mark as obsolete
> >as needed. AFAIK there is noone working on the translation and I do
> >not see this changing in the near future.
>
> Thanks for your feedback.
> Indeed, ca & cs translations are disabled in the Makefile.
> So we just need to have a working transcount script for 1) have a
> successfull build and 2) taking care of future (or reactivated) xml
> translations.
>
> As nobody disagree, I plan to push the attached change during the
> week-end.

Sure, please go ahead! I am trying to find someone interested on doing
'ca' translation, so we might be able to reactivate it in future.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#908163: RFS: wfrench/1.2.4

[Adam Borowski]

On Thu, Sep 06, 2018 at 10:10:21PM +0200, guillaume pernot wrote:
>  * Package name: wfrench
>Version : 1.2.4

>   Changes since the last upload:
> 
>   * New maintainer (Closes: #858663)
>   * Added verbs from verbiste (Closes: #329474)
>   * debian/control:
>   - Bumped Standards-Version to 4.2.1.

Hi!
Not mentioned in the changelog is turning the package into format: native.
That's pretty certainly not the right thing to do: "native" packages are
those which make no sense outside Debian, which doesn't apply to a word
list.  Even if there's no other upstream, you can take over and generate
such a tarball yourself -- but that's still something some other distro
may want.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

Another reboot, and a different set of corruption. A mostly black 
background with a few pixels of grey and black garbage at the top left. 
Screenshot attached.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908161: Please enable building a riscv64 kernel image

[Ben Hutchings]

On Thu, 2018-09-06 at 22:59 +0100, James Cowgill wrote:
> Hi!
> 
> On 06/09/2018 21:06, Karsten Merker wrote:
> > Unfortunately, with the patch applied the kernel itself builds
> > successfully, but the package build process then fails with
> > 
> > -8<--8<--8<--8<--8<-
> > 
> > make[3]: Leaving directory 
> > '<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> > debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 
> > none riscv64
> > ABI is not completely versioned!  Refusing to continue.
> > 
> > Unversioned symbols:
> > _mcount  module: vmlinux, version: 
> > 0x, export: EXPORT_SYMBOL
> > return_to_handlermodule: vmlinux, version: 
> > 0x, export: EXPORT_SYMBOL
> > Can't read ABI reference.  ABI not checked!
> > make[2]: *** [debian/rules.real:217: 
> > debian/stamps/build_riscv64_none_riscv64] Fehler 1
> > 
> > -8<--8<--8<--8<--8<-
> > 
> > I'm somewhat stuck here - is this an upstream issue or
> > have I overlooked something on the packaging side? Pointers
> > welcome :).
> 
> I sent this upstream patch for this:
> http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html

Why not remove the export of return_to_handler?

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#908161: Please enable building a riscv64 kernel image

[James Cowgill]

Hi!

On 06/09/2018 21:06, Karsten Merker wrote:
> Unfortunately, with the patch applied the kernel itself builds
> successfully, but the package build process then fails with
> 
> -8<--8<--8<--8<--8<-
> 
> make[3]: Leaving directory 
> '<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none 
> riscv64
> ABI is not completely versioned!  Refusing to continue.
> 
> Unversioned symbols:
> _mcount  module: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> return_to_handlermodule: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> Can't read ABI reference.  ABI not checked!
> make[2]: *** [debian/rules.real:217: 
> debian/stamps/build_riscv64_none_riscv64] Fehler 1
> 
> -8<--8<--8<--8<--8<-
> 
> I'm somewhat stuck here - is this an upstream issue or
> have I overlooked something on the packaging side? Pointers
> welcome :).

I sent this upstream patch for this:
http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html

James



signature.asc
Description: OpenPGP digital signature

Bug#908170: texlive-latex-extra: \documentclass[italian]{europecv} causes "File ended while scanning definition of \ecv@cvofkey"

[Francesco Poli (wintermute)]

Package: texlive-latex-extra
Version: 2018.20180824-1
Severity: normal
Tags: patch


Hello!

With

  \documentclass[helvetica,narrow,italian,
 noflag,logo,totpages,booktabs]{europecv}

I get the following error:

  ! File ended while scanning definition of \ecv@cvofkey.
  
  l.3 \usepackage
  ! Emergency stop.
  
  l.3 \usepackage
  !  ==> Fatal error occurred, no output PDF file produced!

which does not occur, if I use:

  \documentclass[helvetica,narrow,english,
 noflag,logo,totpages,booktabs]{europecv}

By trial and error, I found out that the attached patch fixes (or works
around) the issue.

Is there a better fix, by chance?

Could you please apply my patch (or a better fix) and/or
forward my bug report upstream, as appropriate?

Thanks for your time and helpfulness!
Bye.


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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1592 Aug 29 21:58 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 24 04:11 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 24 04:11 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 23  2017 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 24 04:11 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 24 04:11 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3957 Aug 29 21:57 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Oct 14  2015 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 23  2017 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-1
ii  python 2.7.15-3
ii  tex-common 6.09
ii  texlive-base   2018.20180824-1
ii  texlive-binaries   2018.20180824.48463-1
ii  texlive-latex-recommended  2018.20180824-1
ii  texlive-pictures   2018.20180824-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2018.20180824-1
ii  texlive-plain-generic  2018.20180824-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.22-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.2.0+dfsg-1
ii  texlive-latex-extra-doc 2018.20180824-1

Versions of packages tex-common depends on:
ii  dpkg  1.19.0.5+b1
ii  ucf   3.0038

Versions of packages tex-common 

Bug#698668: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Ben Hutchings]

Are you still waiting for agreement from any contributors, or is this
ready to apply?

Ben.

On Fri, 2018-08-03 at 15:41 +0100, Ben Hutchings wrote:
> The GNU Free Documentation License allows for a work to specify
> Invariant Sections that are not allowed to be modified.  (Debian
> considers that this makes such works non-free.)
> 
> The Linux Media Infrastructure userspace API documentation does not
> specify any such sections, but it also doesn't say there are none (as
> is recommended by the license text).  Make it explicit that there are
> none.
> 
> References: https://bugs.debian.org/698668
> Signed-off-by: Ben Hutchings 
> ---
>  Documentation/media/media_uapi.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/media/media_uapi.rst 
> b/Documentation/media/media_uapi.rst
> index 28eb35a1f965..5198ff24a094 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
>  
>  Permission is granted to copy, distribute and/or modify this document
>  under the terms of the GNU Free Documentation License, Version 1.1 or
> -any later version published by the Free Software Foundation. A copy of
> -the license is included in the chapter entitled "GNU Free Documentation
> -License".
> +any later version published by the Free Software Foundation, with no
> +Invariant Sections. A copy of the license is included in the chapter
> +entitled "GNU Free Documentation License".
>  
>  .. only:: html
>  
-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#908169: libasio-dev: Asio on Linux stalls in epoll

[Shane Loretz]

Package: libasio-dev
Version: 1:1.10.8-1
Severity: normal

Dear Maintainer,

The version of libasio-dev in sid can deadlock if used in multiple threads.

https://github.com/chriskohlhoff/asio/issues/180

It looks like the bug is fixed in the version in experimental (1.12.0).
Is there something I can do to help migrate the version in experimental to
unstable?

The issue was also reported downstream.
https://bugs.launchpad.net/ubuntu/+source/asio/+bug/1771903

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

Kernel: Linux 4.15.0-33-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

libasio-dev depends on no packages.

Versions of packages libasio-dev recommends:
ii  libboost-date-time-dev  1.62.0.1
ii  libboost-dev1.62.0.1
ii  libboost-regex-dev  1.62.0.1
ii  libssl-dev  1.1.1~~pre9-1

libasio-dev suggests no packages.

-- no debconf information

Bug#851560: dhcpcd5: update to new upstream version

[Maximilian Engelhardt]

The latest version of dhcpcd is currently 7.0.7:

https://roy.marples.name/archives/dhcpcd-discuss/0002151.html

Thanks,
Maxi

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

Bug#908161: Please enable building a riscv64 kernel image

[Ben Hutchings]

Some minor clarifications:

On Thu, 2018-09-06 at 22:28 +0100, Ben Hutchings wrote:
[...]
> Any symbol exported from an assembly-language file won't automatically
> get a symbol version, since there's no type information there.  The way
> to fix this is to include (or directly) add the function prototypes in

"... include (or directly add) ..."

> arch/riscv/include/asm/asm-prototypes.h.
> 
> I don't think that return_to_handler should be exported at all.  No
> other architecture does.

"No other architecture exports it."

[...]
> I'm removing the patch tag as this patch isn't usable.  Please add it
> again when you send another patch.  Also, you are welcome to send a
> merge request on Gitlab instead of a patch; I find easier to discuss
> changes that way.

By "Gitlab" I mean salsa.debian.org.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#908161: Please enable building a riscv64 kernel image

[Ben Hutchings]

Control: tag -1 - patch

On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> Source: linux
> Version: 4.19~rc2-1~exp1
> Severity: wishlist
> Tags: patch
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hello,
> 
> starting with version 4.19rc2, the mainline Linux kernel includes
> all drivers necessary for running a riscv64 system in qemu, so it
> would be great if the "linux" source package could be extended to
> build a linux-image-*-riscv64 binary package.
> 
> Attached is a patch that tries to add the necessary bits.

This config sets a whole lot of things to be built-in, but our policy
is to build everything as modules if it works properly work as a
module.  This will also cause the building of installer udebs to fail
(empty packages are treated as a fatal error).

It also seems to have some redundant settings.  debian/config/config is
always used first (see README.source), so don't repeat anything that's
in there.

Finally you should use kconfigeditor2 to add headings to the config
file.  You need to check out the kernel-team.git repository, and then
in the linux repository run something like:

../kernel-team/utils/kconfigeditor2/process.py .

> Unfortunately, with the patch applied the kernel itself builds
> successfully, but the package build process then fails with
> 
> -8<--8<--8<--8<--8<-
> 
> make[3]: Leaving directory 
> '<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none 
> riscv64
> ABI is not completely versioned!  Refusing to continue.
> 
> Unversioned symbols:
> _mcount  module: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> return_to_handlermodule: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> Can't read ABI reference.  ABI not checked!
> make[2]: *** [debian/rules.real:217: 
> debian/stamps/build_riscv64_none_riscv64] Fehler 1
> 
> -8<--8<--8<--8<--8<-
> 
> I'm somewhat stuck here - is this an upstream issue or
> have I overlooked something on the packaging side? Pointers
> welcome :).

It's an upstream issue, but not a fatal error there.  For Debian it is
a fatal error becasue unversioned symbols potentially undermine code
signing.

Any symbol exported from an assembly-language file won't automatically
get a symbol version, since there's no type information there.  The way
to fix this is to include (or directly) add the function prototypes in
arch/riscv/include/asm/asm-prototypes.h.

I don't think that return_to_handler should be exported at all.  No
other architecture does.  As for _mcount, that is declared in
, so  should just be:

/* SPDX-License-Identifier: GPL-2.0 */
#include 

--

Finally, you have added module lists for installer udebs, but this
won't have any effect unless you also add the new architecture and
flavour to debian/installer/kernel-versions.

--

I'm removing the patch tag as this patch isn't usable.  Please add it
again when you send another patch.  Also, you are welcome to send a
merge request on Gitlab instead of a patch; I find easier to discuss
changes that way.

Ben.

> Regards,
> Karsten
-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#908155: Coordination with upstream developers not universally applied

[Thorsten Glaser]

On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote:

> "You have to forward these bug reports to the upstream developers so that they
> can be fixed in a future upstream release."
>
> That's not the current/best practice for a number of packages, either because
> of the sheer volume of bug reports/size of the package or because some of the
> bugs are very specific to the reporters setup and having the Debian maintainer
> as a middle person forwarding information back and forth would be useless
> (e.g. for the Linux kernel where a lot of bug reports are hardware-specific).

I respectfully disagree.

In just as many cases, the middle person is necessary, because it’s
a burden to the end user (and often enough virtually impossible) to

• register an account on 10'000 upstream bugtrackers, with 30 different
  kinds of bug tracking systems (if any), themselves (one for each pak‐
  kage they use)

  ‣ finding the tracker in the first place

  ‣ reporting it in the correct tracker, against the correct
component, in the correct format, etc.

• keep track of the state of these bugs (we have debbugs with a sub‐
  scription interface as a single consistent interface for a reason)

• respond to back-questions from upstream (which version, compile
  options, why did you patch X, etc)

  ‣ deal with upstreams not interested in bugreports for anything stable

• tell upstream convincingly enough that no, you can’t just build
  and use their git master

  ‣ (the real package maintainers could pick the proposed fix and
put it in experimental, though, or prepare, if necessary, a
special build for the reporter to test back)

• well, build the proposed fix for testing

• reproduce the bug with older (think oldstable-security) or newer
  (think sid, for a stable user) versions

• keep track of whatever upstream versions and whatever Debian
  versions carry the fix (those can differ quite a lot)

• be able to judge whether it’s a security-relevant problem

• speak upstream’s language (both programming and human) well
  enough for both sides to understand stuff

• etc.

Furthermore, it’s considered nice to upstream to filter out
Debian-specific bugs instead.

One could even argue with Social Contract §4 here, but I’m
not going quite as far.

Yes, I’ve also been guilty of asking users to report things
upstream as they aren’t packaging-specific. (I’d still move
or copy them upstream if the reporter is unable or unwilling.)
However, I *still* think the language of DevRef should be
*strongly* urging DDs (and other package maintainers) towards
being a bidirectional bug report gateway, at least for real
problems (I can understand being annoyed with upstream feature
requests).

Yes, that doesn’t scale when you maintain “a lot of” packages.
However, it *is* something you have signed up for when you
started maintaining your first package. Perhaps you should
look for help (bug triage and forwarding could even be done,
in part, by less involved people).

I also think that upstreams, conversely, should have an eye
on packaging bugtrackers, but that can explode quickly… I’m
trying for mine (Debian, CentOS/RedHat, Gentoo, Arch seems
to be a manageable subset, and I pick up weird ones like Void
on the occasion).

So, perhaps upstream can help those “a lot of” maintainers, too.

This also means that there should be a good relationship
between the package maintainers and upstreams. In those,
it’s easier to deal with bugreports than when someone
totally unknown goes to upstream and reports a bug (“uh,
a clueless end user… meh, let’s ignore it”). It’s basically
the *definition* of a distribution and its maintainers to
coordinate between upstreams, other packages and distro-wide
policies, and users and other downstreams. It’s your *job*!

I’m trying to be constructive here, but in the end, I still
think that this was something package maintainers (at least
DDs) have read beforehand and signed up for, so there’s no
room to complain now, and I strongly believe that the current
wording should either not be changed at all, or changed in a
way that still strongly supports users unable (by lack of
knowledge, skills, or just time) to report directly upstream.

Thanks for having read till the end,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#908168: okular: CVE-2018-1000801

[Salvatore Bonaccorso]

Source: okular
Version: 4:17.12.2-2
Severity: important
Tags: patch security upstream
Forwarded: https://bugs.kde.org/show_bug.cgi?id=398096

Hi,

The following vulnerability was published for okular.

CVE-2018-1000801[0]:
| okular version 18.08 and earlier contains a Directory Traversal
| vulnerability in function "unpackDocumentArchive(...)" in
| "core/document.cpp" that can result in Arbitrary file creation on the
| user workstation. This attack appear to be exploitable via he victim
| must open a specially crafted Okular archive. This issue appears to
| have been corrected in version 18.08.1

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000801
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000801
[1] https://bugs.kde.org/show_bug.cgi?id=398096
[2] 
https://cgit.kde.org/okular.git/commit/?id=8ff7abc14d41906ad978b6bc67e69693863b9d47

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Jeff Squyres (jsquyres)]

On Sep 6, 2018, at 2:19 PM, Adrian Bunk  wrote:
> 
> With thanks to Santiago Vila we finally figured out how to reproduce it.
> 
> From a failed build log:
> I: NOTICE: Log filtering will replace 'build/openmpi-LjweZK/openmpi-3.0.1' 
> with '<>'
> I: NOTICE: Log filtering will replace 'build/openmpi-LjweZK' with 
> '<>'
> 
> Note the -L in the random string.

Oh wow, so your tmpdir just happens to contain "-L" and that causes the problem?

...unfortunately, I'm unable to replicate this issue.  :-\

Are you able to cause this problem running by hand?

Here's what I tried:

-
$ cd /home/jsquyres/openmpi-releases
$ mkdir -p build/openmpi-LjweZK
$ cd build/openmpi-LjweZK
$ tar xf ../../openmpi-3.0.1.tar.bz2
$ cd openmpi-3.0.1
$ ./configure --prefix=$HOME/bogus |& tee config.out
$ make -j 32 |& tee make.out
-

I also tried with a VPATH build (same general recipe as above, but in a vpath 
subdir)

Neither of these resulted in the problem.

What's different / why can't I reproduce?

I am using:

Autoconf 2.69
Automake 1.15 (*** you are using 1.15.1 -- do we think that makes a difference?)
Libtool 2.4.6

I am also using gcc 7.3.0.

Here's the directory I built in:

/home/jsquyres/openmpi-releases/build/openmpi-LjweZK/openmpi-3.0.1

I'm *not* running on Debian -- I'm running on an RHEL machine -- but this seems 
like a path issue, not a distro issue, so I'm kinda hoping that that doesn't 
matter...

Any thoughts?

-- 
Jeff Squyres
jsquy...@cisco.com

Bug#908098: dgit: Bulding with "dgit cowbuilder" does not allow building source,any,all packages

[Sean Whitton]

Hello,

On Thu 06 Sep 2018 at 10:34AM +0100, Ian Jackson wrote:

> I can't see a way to make this work *perfectly* without trying to find
> out how the builders are configured.  It's bad enough having to walk
> dpkg-buildpackage's command line options, but trying to process
> pbuilder and sbuild configuration would be really hard.
>
> So I think it will be necessary to tell dgit, separately, that you
> want to run lintian.  In that case I don't think it is necessary for
> the lintian invocation to be done by the builder.  It could be done by
> dgit.  (Presumably, if you tell dgit that you want to run lintian, it
> could then arrange to tell your builder not to do so as well -
> overriding config is a lot easier than parsing it.)
>
> I wonder if a fix to
> #905399 Want hooks
> would suffice ?  In particular, could it be made easy enough to use
> that enabling lintian would be easy ?  Or maybe this is fundamental
> enough in Debian packaging that it should be its own option.

On Thu 06 Sep 2018 at 06:13PM +0100, Ian Jackson wrote:

> There is an additional difficulty with this which I have just throght
> of.  The natural consequence of the above would be that lintian would
> be run in the dgit invocation environment, not in the builder's
> chroot.  This matters because in the usual case, the latter will be
> unstable's lintian, whereas the invocation environment might well be
> testing or even stable.  I'm not sure whether this matters very much.

This is the reason that people configure their builders to run Lintian,
AFAIK.  However, I think it is the wrong solution.  The right thing to
do, in my view, is use dgit hooks, as you suggest, and further apt pin
lintian to be installed from unstable, even onto your Debian stable or
testing laptop.  The Lintian maintainers ensure that Lintian is always
installable on stable because that is how lintian.debian.org works, so
this isn't a hack.

The reason why I think this is the right thing to do is that I think you
should always be running Lintian from unstable, even if you are
preparing an upload targeted for another suite.

This is because Lintian often gains new tags that are relevant for
uploads to a suite even when the version of Lintian in that suite would
not complain.  By contrast, it is rare that Lintian from sid complains
about something where both (i) the version of Lintian in the target
suite would not complain; and (ii) the complaint is not valid when
uploading to that suite.

So in short, I think that running Lintian from unstable matters, but
running Lintian from the target suite is not the way to do that, and can
have disadvantages when compared to running the version from unstable.
So dgit should not grow lots of extra code to ensure the source package
is available inside the builder's chroot such that Lintian can be run
there.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#908098: dgit: Bulding with "dgit cowbuilder" does not allow building source,any,all packages

[Sean Whitton]

Hello,

On Thu 06 Sep 2018 at 08:31PM +0200, Ruben Undheim wrote:

> So the lintians for the source package don't appear if manually running 
> lintian
> /var/cache/pbuilder/result/mypackage*.changes on a package built with "dgit
> cowbuilder". But if you build with normal cowbuilder they appear. This problem
> in itself therefore has nothing to do with triggers.

What is your dgit build-products-dir setting?  That directory is where
you will find a _multi.changes including the source and binary packages.

I suspect that your build-products-dir is not
/var/cache/pbuilder/result.  You probably need to configure either or
both pbuilder or dgit to put build products somewhere else.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907911: linux: Resetting chip after gpu hang (crash dump) when zooming on the opencaching.de map

[Moritz Mühlenhoff]

On Tue, Sep 04, 2018 at 04:35:07PM +, Thorsten Glaser wrote:
> forwarded 907911 https://bugs.freedesktop.org/show_bug.cgi?id=107824
> thanks
> 
> Ben Hutchings dixit:
> 
> >Please can you also report this upstream as requested in the error
> 
> According to DevRef §3.1.4 that’s your job as maintainer

I've filed #908155 against developers-reference to fix this.

Cheers,
Moritz

Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

After a suspend-reboot, the background is multicoloured. It looks 
perhaps like the superposition of other icons? Although I do not 
recognise which. Screenshot attached.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908167: Add firefox-esr-l10n-ne-np to task-nepali-desktop

[Moritz Muehlenhoff]

Package: tasksel
Version: 3.45
Severity: wishlist

I noticed that starting with the 60.x series Firefox ESR now provides
a firefox-esr-l10n-ne-np language pack. That sounds like a useful
thing to add to task-nepali-desktop

Cheers,
Moritz

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Markus Koschany]

Am 06.09.2018 um 22:24 schrieb Mykola Nikishov:
> Markus Koschany  writes:
> 
>> This is correct because the old XUL format does no longer work with
>> Firefox 62. It is not possible to install them both at the same time.
> 
> Yes, I know that FF62 and XUL extensions are not compatible.
> 
> My hope was if it is possible to have FF-ESR and FF-62 installed at the
> same time, it should be possible to use xul-ext-ublock-origin and
> webext-ublock-origin respectively.
> 
> In other words, it is not technically possible to have, at the same time:
> - Firefox ESR with xul-ext-ublock-origin/stable
> - Firefox 62 with webext-ublock-origin
> 
> Even with different profiles?

FF-ESR will soon be upgraded to the new Firefox ESR release and that is
not compatible with XUL addons anymore. It is technically possible to
support this use case but it is not supported by us.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Santiago Vila]

On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote:
> On Mon, Sep 03, 2018 at 03:31:30PM +0200, Santiago Vila wrote:
>
> > FTBFS bugs have always been serious. Do you have a statement from a
> > member of the release team saying specifically that those bugs
> > should be buster-ignored?
> > 
> > (That's what we should really do, btw, if we wanted a serious bug not
> > to be RC).
> 
> https://release.debian.org/buster/rc_policy.txt
> ...
> 4. Autobuilding
> ...
>   Packages must autobuild without failure on all architectures on
>   which they are supported.
> ...

Ok, I started saying "FTBFS = serious" but the above does not really
count as a counter-example. We agree that a FTBFS bug in an unreleased
arch is not RC, that's completely out of the discussion.

In our case single-core amd64 is the same arch as multi-core amd64, so
a FTBTS in single-core amd64 is a FTBFS in amd64 for all purposes, and
amd64 is a released architecture.

Moreover, the above paragraph has more than one possible interpretation.

For some people (maybe you), "autobuild" in the phrase above is
only what happens in buildd.debian.org.

For me, autobuilding is just what autobuilders do. There is a set of
autobuilders in buildd.debian.org, there is another in
reproducible-builds, and I also have my own autobuilders.

You will have noticed that we usually report FTBFS bugs when a package
fails to build in any "correctly" configured autobuilder, we don't wait
for the build failure to happen on buildd.debian.org.

Literally tons and tons of FTBFS bugs have been filed on the basis
that the package failed to build in standard-configured autobuilders
(not necessarily buildd.debian.org).

I think this supports my interpretation of "autobuilding".

> Other cases of problems that do not happen when autobuilding like for
> example building with locales other than C are also usually considered
> Severity: important.

I agree with this, for a FTBFS bug to be reported as serious, it
usually needs to happen in an autobuilder which is not misconfigured.

The standard autobuilder has LANG=C and if not we call it misconfigured,
and for that reason most people do not usually report those bugs as important.

But being single-core in no way is a "misconfiguration", and I refuse
to consider such thing on the same "level" as building with a locale
different than C. An autobuilder which is single-core is not "defective".

[...]
> > Missing build-depends, for example, have always been serious bugs,
> > even if they do not happen in the official buildds.
> > 
> > Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC"
> > are not always the same thing.
> 
> This case has an own item in the list:
> 
> https://release.debian.org/buster/rc_policy.txt
> ...
> 4. Autobuilding
> 
>   Packages must list any packages they require to build beyond those
>   that are "build-essential" in the appropriate Build-Depends: fields.
> ...
> 
> There doesn't seem to be a similar special case for single-core machines.

I'm not sure what exactly you mean here.

There is not a special case for Intel CPUs. If official autobuilders
on amd64 had all of them Intel CPUs and a package FTBFS on AMD, it
would be a serious bug, because being Intel would be accidental, not
part of the "standard to build Debian packages".

> > You are perhaps assuming that I'm trying to build all packages on a
> > single machine which is able to build everything.
> >...
> 
> No, what I am saying is that you are focussing on a case that is
> mostly irrelevant in practice, and that trying to make it a high
> priority for other people to solve such issues is therefore a
> waste of time.

I'm not really "focusing" on single-core, it's just what I usually do
to build packages, that's all. In my QA work, 99% of the bugs I find
are not related to the number of CPUs at all.

Our problem is that you are trying to make single-core users as
second-class citizens of the amd64 architecture (in a similar way
unreleased architectures are already second-class because their FTBFS
may not be serious), while I still believe they deserve exactly the
same level of support of multi-core users, because there is only one
amd64 architeture, not two.

> [...]
> For VMs it would be a waste of money to pay for a VM that has a huge 
> amount of RAM and storage but only one CPU for building packages.
> It is both faster and cheaper to use a multi-CPU VM for that.

That's simply not true. Here is the math:

In the best case scenario, a machine with 2 CPU will usually cost
double than a single-CPU. It will build the package in half of the
time, but since it cost double per minute, the total cost is
approximately the same, not cheaper at all.

But that's only the best case scenario. The worst case scenario is
that you build all packages using 2 CPU but only a proportion of them
support (and benefit from) parallel build. For those who don't we are
wasting completely the extra CPU.

So no, it's not 

Bug#908166: swt4-gtk: compilation with openjdk-10 results in empty jar

[Jochen Sprickerhof]

Source: swt4-gtk
Severity: normal

Hi,

I tried to rebuild this as part of fixing #907990 but only got an empty
jar. It compiles fine with openjdk-8, though.


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

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

Bug#908165: sympa: CVE-2018-1000671

[Salvatore Bonaccorso]

Source: sympa
Version: 6.2.16~dfsg-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/sympa-community/sympa/issues/268

Hi,

The following vulnerability was published for sympa, filled to start
tracking the upstream issue. AFAIK, there is no fix avaialbe yet.

CVE-2018-1000671[0]:
| sympa version 6.2.16 and later contains a CWE-601: URL Redirection to
| Untrusted Site ('Open Redirect') vulnerability in The "referer"
| parameter of the wwsympa.fcgi login action. that can result in Open
| redirection and reflected XSS via data URIs. This attack appear to be
| exploitable via Victim's browser must follow a URL supplied by the
| attacker. This vulnerability appears to have been fixed in none
| available.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000671
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000671
[1] https://github.com/sympa-community/sympa/issues/268

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#908079: Buster: No window title bars in KDE?

[Martin Steigerwald]

local10 - 06.09.18, 18:22:
> Also:
> 
> # dpkg -S kwin_x11
> dpkg-query: no path found matching pattern *kwin_x11*

% dpkg -S kwin_x11
kwin-x11: /usr/lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so
kwin-x11: /usr/bin/kwin_x11

(with http://ftp.de.debian.org/debian/ as mirror)

As of now kwin-x11 package is available for buster:

% rmadison kwin-x11
kwin-x11   | 4:5.8.6-1 | stable | amd64, arm64, armel, armhf, i386, 
mips, mips64el, mipsel, ppc64el, s390x
kwin-x11   | 4:5.13.4-1| testing| amd64, arm64, armel, armhf, i386, 
mips, mips64el, mipsel, ppc64el, s390x
kwin-x11   | 4:5.13.4-1| unstable   | amd64, arm64, armel, armhf, i386, 
mips, mips64el, mipsel, ppc64el, s390x

So I´d use "apt update" and if the package then still is not available,
check your /etc/apt/sources.list. Maybe your mirror is outdated.

But again, this is no user support forum. Please use debian-kde mailing
list.

Thanks,
-- 
Martin

Bug#908164: dh-make-perl: Suggests to use dselect

[Axel Beckert]

Package: dh-make-perl
Version: 0.103

dh-make-perl gives quite outdated recommendations and suggests to run
"dselect update" (!) if it is unable to obtain version information for
some module:

Unable to obtain version information for Class::Accessor. You may need to 
install and run "dselect update" at /usr/share/perl5/Debian/Control/FromCPAN.pm 
line 351.
Unable to obtain version information for Parse::RecDescent. You may need to 
install and run "dselect update" at /usr/share/perl5/Debian/Control/FromCPAN.pm 
line 351.

Please change that to "apt update" since fewer and fewer systems have
dselect installed: https://qa.debian.org/popcon.php?package=dpkg (And
probably even fewer administrators even know about it.)

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dh-make-perl depends on:
ii  debhelper  11.3.5
ii  dpkg-dev   1.19.0.5
ii  fakeroot   1.23-1
ii  libapt-pkg-perl0.1.34
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.51-1
ii  libconfig-ini-perl 1:0.025-1
ii  libdebian-source-perl  0.103
ii  libdpkg-perl   1.19.0.5
ii  libemail-address-xs-perl   1.04-1
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.22-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libmodule-depends-perl 0.16-3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libsoftware-license-perl   0.103013-2
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.88-1
ii  libwww-perl6.35-2
ii  libyaml-libyaml-perl   0.72+repack-1
ii  libyaml-perl   1.26-1
ii  make   4.2.1-1.2
ii  perl [libcpan-meta-perl]   5.26.2-7

Versions of packages dh-make-perl recommends:
ii  apt   1.6.4
ii  apt-file  3.1.6
ii  git   1:2.19.0~rc2-1
ii  libdpkg-parse-perl0.03-2
ii  libmodule-build-perl  0.422400-1
ii  libsys-cpu-perl   0.61-2+b3
ii  pristine-tar  1.44

dh-make-perl suggests no packages.

-- no debconf information

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Paul Gevers]

Hi,

On 06-09-18 22:09, Andreas Tille wrote:
> I've added a todo item

Ack.

>> On the other hand, I don't care enough that
>> I want you to fix this all right now (you can close this bug if you
>> want), but I think this bug exposed a bug in the auto-generation of r
>> dependencies in general. I suspect you as r maintainers do want to fix that.
> 
> You are right that somebody should fix this.  I admit I have quite some
> RC bugs on my todo list and will leave this for somebody else / some
> later point in time.

Ack

> BTW, do you have any idea why that bug is filed against Debian Med
> packaging list[1] while the maintainer of the package is
> r-pkg-t...@alioth-lists.debian.net?

tracker.d.o?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Mykola Nikishov]

Markus Koschany  writes:

> This is correct because the old XUL format does no longer work with
> Firefox 62. It is not possible to install them both at the same time.

Yes, I know that FF62 and XUL extensions are not compatible.

My hope was if it is possible to have FF-ESR and FF-62 installed at the
same time, it should be possible to use xul-ext-ublock-origin and
webext-ublock-origin respectively.

In other words, it is not technically possible to have, at the same time:
- Firefox ESR with xul-ext-ublock-origin/stable
- Firefox 62 with webext-ublock-origin

Even with different profiles?

-- 
Mykola
https://manandbytes.git{lab,hub}.io/

Bug#908079: Buster: No window title bars in KDE?

[Martin Steigerwald]

local10 - 06.09.18, 18:06:
> luser@tstsrv:~$ kwin_x11 --replace &
> [1] 12686
> bash: kwin_x11: command not found
> luser@tstsrv:~$

kwin_x11 is in package kwin-x11 (as dpkg -S tells).

But the Debian bugtracker is no user support forum. Please use debian-
kde mailing list. The bugtracker is for bug reports and improvement 
suggestions only.

Thanks,
-- 
Martin

Bug#908163: RFS: wfrench/1.2.4

[guillaume pernot]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wfrench
   Version : 1.2.4
   Upstream Author : (none)
 * URL : (none)
 * License : GPL2+
   Section : text

It builds this package:

  wfrench- French dictionary words for /usr/share/dict

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

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


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

  dget -x
  https://mentors.debian.net/debian/pool/main/w/wfrench/wfrench_1.2.4.dsc

  Changes since the last upload:

  * New maintainer (Closes: #858663)
  * Added verbs from verbiste (Closes: #329474)
  * debian/control:
  - Bumped Standards-Version to 4.2.1.

Regards,
 guillaume pernot

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Ben Hutchings]

On Tue, 2018-09-04 at 11:43 -0700, Geoff Levand wrote:
[...]
> At this point I feel our choices are:
> 
> 1) Merge the kernel config patch I proposed and add a comment to
> the arm64 Installation Guide about the need to add 'hest_disable=1'
> to the kernel command line for the m400.
> 
> 2) Merge the kernel config patch and the
> 'Add fix for broken HPE moonshot ACPI-APEI support' patch I proposed.
> 
> 3) Remove the CONFIG_ACPI_APEI options from the the kernel config patch
> I proposed and merge that.
> 
> I prefer #2, which would get us ACPI_APEI support and a seamless
> install for m400 users.
> 
> If there is anything you recommend I could try it.  I'm not apposed
> to any solution.  I just want to get the kernel config updated so
> Buster better supports newer systems.

I also favour #2.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#908162: grub-efi-amd64-signed: cryptdisk support missing

[Tollef Fog Heen]

Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+6
Severity: critical
Justification: makes the system completely unbootable

When grub-efi-amd64-signed is installed and /boot is on an encrypted
file system and GRUB_ENABLE_CRYPTODISK=y is present in
/etc/default/grub, the system fails to boot, since cryptodisk appears to
be missing from the installed image.

Removing grub-efi-amd64-signed works around the problem, since it then
seems to use a locally built image?  I suspect just adding cryptodisk to
GRUB_MODULES in grub's debian/build-efi-images would be sufficient to
make this work correctly.

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

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

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908158: [Pkg-mozext-maintainers] Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Carsten Schoenert]

Control: severity -1 wishlist

Am 06.09.18 um 21:53 schrieb Mykola Nikishov:
> While using Firefox ESR with xul-ext-ublock-origin/stable in a default
> profile, user should be able to run Firefox 62 with
> webext-ublock-origin in a separate profile. But right now,
> webext-ublock-origin
> 
> Breaks: xul-ext-ublock-origin
> 
> and it is impossible to have them both installed.

That's nothing that we want to have, it's currently the correct
behavior. FF ESR 60.0 isn't accepting XUL based AddOns anymore.

You can always install the AddOns from Mozilla directly within your
local profile. A local installed AddOn is always overruling the package
based installation. So simply use the upstream AddOn here in your setup
for non ESR FF versions.

-- 
Regards
Carsten Schoenert

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Andreas Tille]

On Thu, Sep 06, 2018 at 09:48:40PM +0200, Paul Gevers wrote:
> > So I would need to force the Debian revision
> > manually in.
> 
> Or improve that auto-generation. I think (but haven't tested), that
> adding a -~~ (or something along those lines) to any upstream version in
> such relations will prevent an upstream hyphen from being treated as the
> separator between the upstream version and the Debian revision number.

I've added a todo item


https://salsa.debian.org/r-pkg-team/dh-r/commit/a7b22d1c5834fb920fe286aad57536f8ffbdac6b
 
> > What do you think about waiting until tomorrow when
> > the issue should heal automatically once r-cran-ade4 will migrate
> > to testing?
> 
> That is just hiding the bug.

I agree.

> On the other hand, I don't care enough that
> I want you to fix this all right now (you can close this bug if you
> want), but I think this bug exposed a bug in the auto-generation of r
> dependencies in general. I suspect you as r maintainers do want to fix that.

You are right that somebody should fix this.  I admit I have quite some
RC bugs on my todo list and will leave this for somebody else / some
later point in time.

BTW, do you have any idea why that bug is filed against Debian Med
packaging list[1] while the maintainer of the package is
r-pkg-t...@alioth-lists.debian.net?

Kind regards

   Andreas.


[1] 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-September/065335.html

-- 
http://fam-tille.de

Bug#908161: Please enable building a riscv64 kernel image

[Karsten Merker]

Source: linux
Version: 4.19~rc2-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

starting with version 4.19rc2, the mainline Linux kernel includes
all drivers necessary for running a riscv64 system in qemu, so it
would be great if the "linux" source package could be extended to
build a linux-image-*-riscv64 binary package.

Attached is a patch that tries to add the necessary bits. 
Unfortunately, with the patch applied the kernel itself builds
successfully, but the package build process then fails with

-8<--8<--8<--8<--8<-

make[3]: Leaving directory 
'<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none 
riscv64
ABI is not completely versioned!  Refusing to continue.

Unversioned symbols:
_mcount  module: vmlinux, version: 
0x, export: EXPORT_SYMBOL
return_to_handlermodule: vmlinux, version: 
0x, export: EXPORT_SYMBOL
Can't read ABI reference.  ABI not checked!
make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] 
Fehler 1

-8<--8<--8<--8<--8<-

I'm somewhat stuck here - is this an upstream issue or
have I overlooked something on the packaging side? Pointers
welcome :).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From d1d47c22d5c41bb3b1924d2534aa06e86a16c10d Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Sat, 1 Sep 2018 23:02:11 +0200
Subject: [PATCH] Build a kernel image for riscv64

---
 debian/config/riscv64/config  | 79 +++
 debian/config/riscv64/defines |  6 +-
 debian/config/riscv64/none/defines|  3 +
 debian/installer/modules/riscv64/ata-modules  |  1 +
 .../installer/modules/riscv64/btrfs-modules   |  1 +
 .../modules/riscv64/compress-modules  |  1 +
 debian/installer/modules/riscv64/crc-modules  |  1 +
 .../modules/riscv64/crypto-dm-modules |  1 +
 .../installer/modules/riscv64/crypto-modules  |  1 +
 .../installer/modules/riscv64/event-modules   |  1 +
 debian/installer/modules/riscv64/ext4-modules |  1 +
 debian/installer/modules/riscv64/fat-modules  |  1 +
 debian/installer/modules/riscv64/fuse-modules |  1 +
 debian/installer/modules/riscv64/i2c-modules  |  1 +
 .../installer/modules/riscv64/input-modules   |  1 +
 .../installer/modules/riscv64/isofs-modules   |  1 +
 debian/installer/modules/riscv64/jfs-modules  |  1 +
 debian/installer/modules/riscv64/kernel-image |  1 +
 debian/installer/modules/riscv64/leds-modules |  1 +
 debian/installer/modules/riscv64/loop-modules |  1 +
 debian/installer/modules/riscv64/md-modules   |  1 +
 debian/installer/modules/riscv64/mmc-modules  |  1 +
 debian/installer/modules/riscv64/mtd-modules  |  1 +
 .../modules/riscv64/multipath-modules |  1 +
 debian/installer/modules/riscv64/nbd-modules  |  1 +
 debian/installer/modules/riscv64/nic-modules  |  1 +
 .../modules/riscv64/nic-shared-modules|  1 +
 .../installer/modules/riscv64/nic-usb-modules |  1 +
 .../modules/riscv64/nic-wireless-modules  |  1 +
 debian/installer/modules/riscv64/pata-modules |  1 +
 debian/installer/modules/riscv64/ppp-modules  |  1 +
 debian/installer/modules/riscv64/sata-modules |  1 +
 .../modules/riscv64/scsi-core-modules |  1 +
 debian/installer/modules/riscv64/scsi-modules |  2 +
 .../modules/riscv64/squashfs-modules  |  1 +
 debian/installer/modules/riscv64/udf-modules  |  1 +
 .../installer/modules/riscv64/uinput-modules  |  1 +
 debian/installer/modules/riscv64/usb-modules  |  1 +
 .../modules/riscv64/usb-storage-modules   |  1 +
 .../installer/modules/riscv64/virtio-modules  |  1 +
 debian/installer/modules/riscv64/zlib-modules |  1 +
 41 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 debian/config/riscv64/config
 create mode 100644 debian/config/riscv64/none/defines
 create mode 100644 debian/installer/modules/riscv64/ata-modules
 create mode 100644 debian/installer/modules/riscv64/btrfs-modules
 create mode 100644 debian/installer/modules/riscv64/compress-modules
 create mode 100644 debian/installer/modules/riscv64/crc-modules
 create mode 100644 debian/installer/modules/riscv64/crypto-dm-modules
 create mode 100644 debian/installer/modules/riscv64/crypto-modules
 create mode 100644 debian/installer/modules/riscv64/event-modules
 create mode 100644 debian/installer/modules/riscv64/ext4-modules
 create mode 100644 debian/installer/modules/riscv64/fat-modules
 create mode 100644 debian/installer/modules/riscv64/fuse-modules
 create mode 100644 debian/installer/modules/riscv64/i2c-modules
 create mode 

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Markus Koschany]

Am 06.09.2018 um 21:53 schrieb Mykola Nikishov:
> Package: webext-ublock-origin
> Severity: normal
> 
> While using Firefox ESR with xul-ext-ublock-origin/stable in a default
> profile, user should be able to run Firefox 62 with
> webext-ublock-origin in a separate profile. But right now,
> webext-ublock-origin
> 
> Breaks: xul-ext-ublock-origin
> 
> and it is impossible to have them both installed.

This is correct because the old XUL format does no longer work with
Firefox 62. It is not possible to install them both at the same time.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#908160: FTBFS: build from source fails with undefined reference to `minor'

[Scott Moser]

Package: open-iscsi
Version: 2.0.874-5ubuntu7
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

Current build of open-iscsi (2.0.874-5ubuntu7) will fail to build from
source.

Build fails with:

  ./iscsiuio/src/unix/libs/bnx2x.c:754: undefined reference to `minor'
  collect2: error: ld returned 1 exit status


This is reported to Ubuntu in bug 1791154
  https://bugs.launchpad.net/bugs/1791154

Attached is the fix I am uploading to Ubuntu.

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

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

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-0ubuntu1
ii  libisns0   0.97-2build1
ii  libmount1  2.32-0.1ubuntu1
ii  lsb-base   9.20170808ubuntu1
ii  udev   239-7ubuntu7

Versions of packages open-iscsi recommends:
ii  busybox-initramfs  1:1.27.2-2ubuntu4
ii  finalrd3

open-iscsi suggests no packages.

-- debconf information excluded
commit e8ddf2765525522924a03f668220ba8f256a58d8
Author: Scott Moser 
Date:   Thu Sep 6 15:38:20 2018 -0400

Include  to properly define minor()

LP: #1791154

diff --git 
a/debian/patches/bugfixes/include-sys-sysmacros.h-to-properly-define-minor.patch
 
b/debian/patches/bugfixes/include-sys-sysmacros.h-to-properly-define-minor.patch
new file mode 100644
index ..ba92af5f
--- /dev/null
+++ 
b/debian/patches/bugfixes/include-sys-sysmacros.h-to-properly-define-minor.patch
@@ -0,0 +1,28 @@
+Description: Include  to properly define minor()
+Author: Scott Moser 
+Bug-Debian: https://bugs.launchpad.net/bugs/1791154
+Last-Update: 2018-09-06
+Origin: upstream, 
https://github.com/open-iscsi/open-iscsi/commit/6d68ef5871c94c6ebbbe6e6b1fe0bc2dce711052
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- a/iscsiuio/src/unix/libs/bnx2x.c
 b/iscsiuio/src/unix/libs/bnx2x.c
+@@ -50,6 +50,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "config.h"
+ 
+--- a/iscsiuio/src/unix/libs/bnx2.c
 b/iscsiuio/src/unix/libs/bnx2.c
+@@ -46,6 +46,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "config.h"
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 34608a68..d98a5c63 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -13,3 +13,4 @@ security/Ensure-strings-from-peer-are-copied-correctly.patch
 security/Skip-useless-strcopy-and-validate-CIDR-length.patch
 security/Check-iscsiuio-ping-data-length-for-validity.patch
 iscid-conf-use-systemd.socket-patch
+bugfixes/include-sys-sysmacros.h-to-properly-define-minor.patch

Bug#906019: wireguard-dkms: DKMS module version string not correct

[Daniel Kahn Gillmor]

On Thu 2018-09-06 09:15:32 +0200, Sedat Dilek wrote:
> let's look at my current installed dkms kernel-modules and especially
> virtualbox-dkms and compare with wireguard-dkms.
 […]
> In my POV 'dkms status' should only show the upstream version.
> Special patched versions of *-dkms packages from Debian can be shown
> when loading the module like virtualbox-dkms does.
>
> Not sure what dkms package offers for mechanisms to automatically
> modify the version string.
>
> Honestly, it's just cosmetics.

hm, i am a bit unsure that "cosmetics" is a good justification, but the
truth is that we haven't modified the sources for the wireguard kernel
module for ages -- so the version that we're running really is identical
to the upstream version, and probably should be reported as such.

I'm uploading 0.0.20180904-2 with this change -- but i've implemented it
slightly differently than you proposed:


https://salsa.debian.org/debian/wireguard/commit/c02ff8cd1cfa4c08ca593fbc06ecca8074a2c472

Let me know if there are any other problems!  I appreciate your bringing
this up.

  --dkg

PS in the future, when supplying diffs, i recommend using the "unified"
   diff format (diff -u) instead of "normal" -- unified is a lot easier
   to read, and is really the most widely-used standard in the F/LOSS
   community.


signature.asc
Description: PGP signature

Bug#907703: ghostscript: Bug 699654(2): preserve LockSafetyParams in the nulldevice

[Salvatore Bonaccorso]

Control: retitle -1 ghostscript: CVE-2018-16509

Hi

The full set for the now assigned CVE-2018-16509 is actually:

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=5516c614dc33662a2afdc377159f70218e67bde5
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=78911a01b67d590b4a91afac2e8417360b934156
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=79cccf641486a6595c43f1de1cd7ade696020a31
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=520bb0ea7519aa3e79db78aaf0589dae02103764

Regards,
Salvatore

Bug#908159: emacs: Saving clipboard to X clipboard manager takes forever on exit

[Dylan Thurston]

Package: emacs
Version: 1:25.2+1-11
Severity: normal

Emacs takes a long time on exit, with the status message "Saving
clipboard to X clipboard manager". Eventually there's a message sent
to stderr:

dpt@tulip:~$ emacs -Q
Error saving to X clipboard manager.
If the problem persists, set 'x-select-enable-clipboard-manager' to nil.

To reproduce, start 'emacs -Q', type some text and cut it, and then
exit with C-x C-c.

Similar behaviour seems to occur when closing an emacsclient window
with C-x # as well.

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:25.2+1-11

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#863039: libwvstreams4.6-base: wvdial crashes with Assertion `*current_task->stack_magic == WVTASK_MAGIC' failed

[Lothar Braun]

The patch also fixes the problem for me. 

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Mykola Nikishov]

Package: webext-ublock-origin
Severity: normal

While using Firefox ESR with xul-ext-ublock-origin/stable in a default
profile, user should be able to run Firefox 62 with
webext-ublock-origin in a separate profile. But right now,
webext-ublock-origin

Breaks: xul-ext-ublock-origin

and it is impossible to have them both installed.

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

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

Versions of packages webext-ublock-origin depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-1

Versions of packages webext-ublock-origin recommends:
ii  chromium 69.0.3497.81-1
ii  firefox  62.0~b16-1
ii  firefox-esr  52.9.0esr-1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Paul Gevers]

Hi tille,

On 06-09-18 21:32, Andreas Tille wrote:
> Anyway, the dependency relations of R packages are autogenerated
> in ${R:Depends}.

I suspected as much.

> So I would need to force the Debian revision
> manually in.

Or improve that auto-generation. I think (but haven't tested), that
adding a -~~ (or something along those lines) to any upstream version in
such relations will prevent an upstream hyphen from being treated as the
separator between the upstream version and the Debian revision number.

> What do you think about waiting until tomorrow when
> the issue should heal automatically once r-cran-ade4 will migrate
> to testing?

That is just hiding the bug. On the other hand, I don't care enough that
I want you to fix this all right now (you can close this bug if you
want), but I think this bug exposed a bug in the auto-generation of r
dependencies in general. I suspect you as r maintainers do want to fix that.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#899983: More info and workaround

[Niels Thykier]

Hi,

Thanks for the report and sorry for the late reply.

I am glad you figured out a solution. :)

On Fri, 25 May 2018 14:22:49 +0300 Emel Hasdal  wrote:
> Well it appears that this is explained in dh_installsystemd man pages:
> *--name=**name*Install the service file as *name.service* instead of the
> default filename, which is the *package.service*. When this parameter is
> used, *dh_installsystemd* looks for and installs files named
> *debian/package.name.service* instead of the usual *debian/package.service*.
> Moreover, maintainer scripts are only generated for units that match the
> given *name*.
> 
> It is just not obvious from the help that this is only the case for
> packages except for the main package. For the main package, name.service
> seems to work.
> 
> 
> So, please close this issue.
> 
> [...]
Before I close it, could you perhaps mention if there is something we
could do to improve the documentation that would have helped you find
the solution sooner?

Thanks,
~Niels

Bug#908157: korganizer: KOrganizer creates inexplicable kpasswdserver requests

[Patrick Uven]

Package: korganizer
Version: 4:17.12.3-2
Severity: minor
Tags: upstream

Dear Maintainer,

I've created a remote owncloud calendar in KOrganizer, consisting of a carddav
and a caldav component. After that I started to notice inexplicable messages in
my syslog that seem to be coming from KOrganizer. I can not guarantee that
these messages weren't present before I had created that calendar, but I didn't
notice them before. I haven't used KOrganizer before I created that owncloud
calendar.

   * What was the outcome of this action?

My syslog shows the following line (repeated 6 times) every time I open and
close the configuration of my remote owncloud calendar in KOrganizer as well as
every ~10 minutes:

Sep  6 21:03:03  org.kde.kpasswdserver[819]:
org.kde.kio.kpasswdserver: User = "" , WindowId = 0

   * What outcome did you expect instead?

No log messages or log messages with more information to match them to an
application and event.

It is possible that it is a display bug or the messages have another source,
but KOrganizer looks like the most likely source of them. It's not a big
problem, but those messages fill my syslog and don't really give me any
information on what is happening.



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

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

Versions of packages korganizer depends on:
ii  kdepim-runtime   4:17.12.3-2
ii  kio  5.49.0-1
ii  libc62.27-5
ii  libgcc1  1:8.2.0-4
ii  libkf5akonadicalendar5abi1   4:17.12.3-1
ii  libkf5akonadicontact54:17.12.3-2
ii  libkf5akonadicore5abi1   4:17.12.3-3
ii  libkf5akonadimime5   4:17.12.3-1
ii  libkf5akonadinotes5  4:17.12.3-1
ii  libkf5akonadisearchpim5  4:17.12.3-1
ii  libkf5akonadiwidgets5abi14:17.12.3-3
ii  libkf5calendarcore5abi1  4:17.12.3-1
ii  libkf5calendarsupport5abi1   4:17.12.3-1
ii  libkf5calendarutils5 4:17.12.3-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:17.12.3-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5eventviews54:17.12.3-2
ii  libkf5holidays5  1:5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement517.12.3-1
ii  libkf5incidenceeditor5abi1   17.12.3-2
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kdepimdbusinterfaces5  4:17.12.3-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  17.12.3-1
ii  libkf5libkdepim-plugins  4:17.12.3-1
ii  libkf5libkdepim5 4:17.12.3-1
ii  libkf5libkdepimakonadi5  4:17.12.3-1
ii  libkf5mailtransport5 17.12.3-1
ii  libkf5mailtransportakonadi5  17.12.3-1
ii  libkf5mime5abi1  17.12.3-2
ii  libkf5newstuff5  5.49.0-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi1 4:17.12.3-1
ii  libkf5pimcommonakonadi5  4:17.12.3-1
ii  libkf5pimtextedit5abi1   17.12.3-2
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libphonon4qt5-4  4:4.10.1-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libqt5widgets5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-4
ii  phonon4qt5   4:4.10.1-1

korganizer recommends no packages.

korganizer suggests no packages.

-- no debconf information

Bug#904164: Text of some PDF invisible: some font thing failed

[Mathias Brodala]

Hi,

After the last system updates the issue has appeared again and this time
I am not able to fix it via "fc-cache -f":

> $ fc-cache -fv
> /usr/share/fonts: caching, new cache contents: 0 fonts, 5 dirs
> /usr/share/fonts/X11: caching, new cache contents: 0 fonts, 5 dirs
> /usr/share/fonts/X11/100dpi: caching, new cache contents: 358 fonts, 0 dirs
> /usr/share/fonts/X11/Type1: caching, new cache contents: 8 fonts, 0 dirs
> /usr/share/fonts/X11/encodings: caching, new cache contents: 0 fonts, 1 dirs
> /usr/share/fonts/X11/encodings/large: caching, new cache contents: 0 fonts, 0 
> dirs
> /usr/share/fonts/X11/misc: caching, new cache contents: 89 fonts, 0 dirs
> /usr/share/fonts/X11/util: caching, new cache contents: 0 fonts, 0 dirs
> /usr/share/fonts/cMap: caching, new cache contents: 0 fonts, 0 dirs
> /usr/share/fonts/cmap: caching, new cache contents: 0 fonts, 5 dirs
> /usr/share/fonts/cmap/adobe-cns1: caching, new cache contents: 0 fonts, 0 dirs
> /usr/share/fonts/cmap/adobe-gb1: caching, new cache contents: 0 fonts, 0 dirs
> /usr/share/fonts/cmap/adobe-japan1: caching, new cache contents: 0 fonts, 0 
> dirs
> /usr/share/fonts/cmap/adobe-japan2: caching, new cache contents: 0 fonts, 0 
> dirs
> /usr/share/fonts/cmap/adobe-korea1: caching, new cache contents: 0 fonts, 0 
> dirs
> /usr/share/fonts/truetype: caching, new cache contents: 0 fonts, 6 dirs
> /usr/share/fonts/truetype/ancient-scripts: caching, new cache contents: 30 
> fonts, 0 dirs
> /usr/share/fonts/truetype/dejavu: caching, new cache contents: 6 fonts, 0 dirs
> /usr/share/fonts/truetype/freefont: caching, new cache contents: 12 fonts, 0 
> dirs
> /usr/share/fonts/truetype/kochi: caching, new cache contents: 4 fonts, 0 dirs
> /usr/share/fonts/truetype/liberation: caching, new cache contents: 16 fonts, 
> 0 dirs
> /usr/share/fonts/truetype/openoffice: caching, new cache contents: 1 fonts, 0 
> dirs
> /usr/share/fonts/type1: caching, new cache contents: 0 fonts, 1 dirs
> /usr/share/fonts/type1/gsfonts: caching, new cache contents: 35 fonts, 0 dirs
> /usr/X11R6/lib/X11/fonts: skipping, no such directory
> /usr/local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
> /home/me/.local/share/fonts: skipping, no such directory
> /home/me/.fonts: caching, new cache contents: 631 fonts, 0 dirs
> /usr/share/fonts/X11: skipping, looped directory detected
> /usr/share/fonts/cMap: skipping, looped directory detected
> /usr/share/fonts/cmap: skipping, looped directory detected
> /usr/share/fonts/truetype: skipping, looped directory detected
> /usr/share/fonts/type1: skipping, looped directory detected
> /usr/share/fonts/X11/100dpi: skipping, looped directory detected
> /usr/share/fonts/X11/Type1: skipping, looped directory detected
> /usr/share/fonts/X11/encodings: skipping, looped directory detected
> /usr/share/fonts/X11/misc: skipping, looped directory detected
> /usr/share/fonts/X11/util: skipping, looped directory detected
> /usr/share/fonts/cmap/adobe-cns1: skipping, looped directory detected
> /usr/share/fonts/cmap/adobe-gb1: skipping, looped directory detected
> /usr/share/fonts/cmap/adobe-japan1: skipping, looped directory detected
> /usr/share/fonts/cmap/adobe-japan2: skipping, looped directory detected
> /usr/share/fonts/cmap/adobe-korea1: skipping, looped directory detected
> /usr/share/fonts/truetype/ancient-scripts: skipping, looped directory detected
> /usr/share/fonts/truetype/dejavu: skipping, looped directory detected
> /usr/share/fonts/truetype/freefont: skipping, looped directory detected
> /usr/share/fonts/truetype/kochi: skipping, looped directory detected
> /usr/share/fonts/truetype/liberation: skipping, looped directory detected
> /usr/share/fonts/truetype/openoffice: skipping, looped directory detected
> /usr/share/fonts/type1/gsfonts: skipping, looped directory detected
> /usr/share/fonts/X11/encodings/large: skipping, looped directory detected
> /var/cache/fontconfig: not cleaning unwritable cache directory
> /home/me/.cache/fontconfig: cleaning cache directory
> /home/me/.fontconfig: not cleaning non-existent cache directory
> fc-cache: succeeded

An "fc-cat" run afterwards:

> $ fc-cat -v | grep Directory
> /usr/X11R6/lib/X11/fonts: No such file or directory
> /home/me/.local/share/fonts: No such file or directory
> Directory: /usr/share/fonts
> Directory: /usr/local/share/fonts
> Directory: /root/.fonts
> Directory: /usr/share/fonts/X11
> Directory: /usr/share/fonts/cMap
> Directory: /usr/share/fonts/cmap
> Directory: /usr/share/fonts/truetype
> Directory: /usr/share/fonts/type1
> Directory: /usr/share/fonts/X11/100dpi
> Directory: /usr/share/fonts/X11/Type1
> Directory: /usr/share/fonts/X11/encodings
> Directory: /usr/share/fonts/X11/misc
> Directory: /usr/share/fonts/X11/util
> Directory: /usr/share/fonts/cmap/adobe-cns1
> Directory: /usr/share/fonts/cmap/adobe-gb1
> Directory: /usr/share/fonts/cmap/adobe-japan1
> Directory: /usr/share/fonts/cmap/adobe-japan2
> Directory: /usr/share/fonts/cmap/adobe-korea1
> 

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Andreas Tille]

On Thu, Sep 06, 2018 at 08:50:23PM +0200, Paul Gevers wrote:
> > so I fail to see why there should be an additional versioned depends
> > for the test should be needed.  I wonder why this is fulfilled by
> > 
> > r-cran-ade4 1.7-11-2+b1
> > 
> > ?  Seems I'm missing something really obvious. :-(
> 
> Seems like it:
> paul@testavoira ~ $ dpkg --compare-versions 1.7-11-2+b1 gt 1.7-13 && \
> echo true
> true
> 
> So the version in testing fulfills the requirement.

Arrgh - I think I had checked this - probably a cut-n-pasto ...

Anyway, the dependency relations of R packages are autogenerated
in ${R:Depends}.  So I would need to force the Debian revision
manually in.  What do you think about waiting until tomorrow when
the issue should heal automatically once r-cran-ade4 will migrate
to testing?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#907698: libdrm2: regression: breaks firefox WebGL

[Jörg-Volker Peetz]

Hi Julien,

meanwhile, with firefox version 62.0-1 and drm version 2.4.94-1 WebGL is working
again in firefox.
So, for me everything is settled.

Regards,
Jörg.

Bug#884881: apt-cacher-ng: Remap-... directives without TargetURLs are incompatible with ForceManaged

[Eduard Bloch]

Hallo,
* Alexander Cherepanov [Thu, Dec 21 2017, 01:14:16AM]:
> Package: apt-cacher-ng
> Version: 2-1~bpo8+1
> Tags: security
> 
> It seems the conf line 'Remap-secdeb: security.debian.org' doesn't work with
> 'ForceManaged: 1'. It works without ForceManaged -- files are put in cache
> under secdeb. And it works with ForceManaged if you add
> 'security.debian.org' once more time as TargetURLs.

Yes, it doesn't and the example is wrong. ForceManaged always requires the
admin to specify the target servers.

I will change the example. Thanks.

Regards,
Eduard.

Bug#908062: dch --lts has wrong version number

[Mattia Rizzolo]

Control: tag -1 pending

On Wed, Sep 05, 2018 at 12:53:14PM -0400, Antoine Beaupré wrote:
> On 2018-09-05 12:50:07, Antoine Beaupre wrote:
> > dch --lts currently creates a changelog entry for wheezy and a +deb7uX
> > version number. wheezy is now ELTS and it's jessie that's LTS.
> >
> > The attached patch should fix this.
> 
> The patch was also pushed to the git repository.

Not sure about what git repository you are talking about, as I haven't
seen anything on salsa.d.o/debian/devscripts, but I've now applied your
patch (after tweaking the message and adding a changelog entry) :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#906550: managed to get it working

[Alexandre Viau]

Hey,

I managed to get it working after all.

Uploading soon.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#860431: post-microsoft URL

[Jeffrey Cliff]

https://notabug.org/themusicgod1/cp will have to do for an upstream link,
now that microsoft bought github.

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Paul Gevers]

Hi till,

On 06-09-18 14:12, Andreas Tille wrote:
> On Wed, Sep 05, 2018 at 08:40:15PM +0200, Paul Gevers wrote:
>> Looking at the error, you seem to be missing a versioned (test)
>> dependency on r-cran-ade4.
> 
> Looking at
> 
>https://packages.debian.org/source/unstable/r-cran-adegraphics

You meant https://packages.debian.org/sid/r-cran-adegraphics here.

> it has a versioned Depends
> 
> r-cran-ade4 (>= 1.7-13)
> 
> so I fail to see why there should be an additional versioned depends
> for the test should be needed.  I wonder why this is fulfilled by
> 
> r-cran-ade4 1.7-11-2+b1
> 
> ?  Seems I'm missing something really obvious. :-(

Seems like it:
paul@testavoira ~ $ dpkg --compare-versions 1.7-11-2+b1 gt 1.7-13 && \
echo true
true

So the version in testing fulfills the requirement.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#906550: upstream bug closed

[Alexandre Viau]

Hello,

You might notice that this bug was marked as forwarded.

The pull request in question only fixes a small part of the problem.

I have tried updating to the new upstream version but the build system
for the documentation package has completely changed.

Originally, I was not interested in documenting the documentation
package, it was uploaded as an NMU and I have kept it there ever since.

I would consider dropping the documentation package unless someone steps
in and provides me with a patch that allows me to include it again.

For now, I will prepare a new version in the git repository, waiting to
be uploaded. Anyone willing to help could check out the packaging
repository and possibly play around with it, trying to build the
documentation package.

After a while, I'll just upload the package, without the documentation
binary.


-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#907987: libextractor: CVE-2018-16430: Out of Bound Read

[Chris Lamb]

Hi Salvatore,

> > > libextractor: CVE-2018-16430: Out of Bound Read
> > 
> > Happy to prepare a stable-security upload of this if team@security.d.o
> > are interested?
> 
> Think this will not be needed this time, but thanks for the offer!
> Maintainer prepared an update for the previous two CVEs

CVE-2018-14346 & CVE-2018-14347?

(I see these are fixed in jessie)


Regards,

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

Bug#908150: ITP: gnucap-python -- Python bindings for the GNU circuit analysis package

[Steffen Möller]

Hi Felix,

you may be interested in https://wiki.debian.org/Teams/pkg-electronics

Cheers,

Steffen

Bug#908156: xpra cannot create directories in /run

[Alex]

Package: xpra
Version: 2.3.3+dfsg1-1
Severity: important

Dear Maintainer,
xpra in debian buster does not work anymore. The error messages when
trying to start it from another host with xpra start are:

$ xpra start ssh:remotehost:10 --encoding=vp9 --min-quality=50 --start=konsole

2018-09-01 00:16:30,119 Xpra gtk2 client version 0.17.6-r14322
2018-09-01 00:16:30,120  running on Linux debian 9.5
Warning: failed to import GStreamer:
 GStreamer 1.0: Namespace Gst not available
 GStreamer 0.10: could not import gobject (could not find _PyGObject_API object)
2018-09-01 00:16:30,419 Error: failed to query sound subsystem:
2018-09-01 00:16:30,419  query did not return any data
2018-09-01 00:16:30,772 PyOpenGL warning: missing accelerate module
2018-09-01 00:16:38,282  detected keyboard: rules=evdev, model=pc101, layout=de
2018-09-01 00:16:38,283  desktop size is 1920x1080 with 1 screen:
2018-09-01 00:16:38,284   :0.0 (508x285 mm - DPI: 96x96) workarea: 1920x1020
2018-09-01 00:16:38,284 monitor 1 (309x174 mm - DPI: 157x157)

(Then SSH connects)

Warning: failed to write script file in '/run/user/1000/xpra':
 [Errno 2] No such file or directory: '/run/user/1000/xpra'
 ($XDG_RUNTIME_DIR has not been created?)
Warning: cannot use the system proxy for 'start' subcommand,
 failed to connect to '/run/xpra/system':
 [Errno 2] No such file or directory
 more information may be available in your system log
2018-09-01 00:17:07,417 Warning: failed to write script file in 
'/run/user/1000/xpra':
2018-09-01 00:17:07,417  [Errno 2] No such file or directory: 
'/run/user/1000/xpra'
2018-09-01 00:17:07,418  ($XDG_RUNTIME_DIR has not been created?)
Entering daemon mode; any further errors will be reported to:
  /home/allo/.xpra/:10.log
xpra initialization error:
 failed to identify the new server display!
bash: /xpra/run-xpra: Datei oder Verzeichnis nicht gefunden
Warning: cannot use the system proxy for 'start' subcommand,
 failed to connect to '/run/xpra/system':
 [Errno 2] No such file or directory
 more information may be available in your system log
2018-09-01 00:17:29,904 Warning: failed to write script file in 
'/run/user/1000/xpra':
2018-09-01 00:17:29,904  [Errno 2] No such file or directory: 
'/run/user/1000/xpra'
2018-09-01 00:17:29,905  ($XDG_RUNTIME_DIR has not been created?)
Entering daemon mode; any further errors will be reported to:
  /home/allo/.xpra/:10.log
xpra initialization error:
 failed to identify the new server display!
2018-09-01 00:17:30,787 The SSH process has terminated with exit code 0
2018-09-01 00:17:30,788  the command line used was:
2018-09-01 00:17:30,788  ssh -x -T neptune xpra initenv;~/.xpra/run-xpra 
_proxy_start :10 "--start=konsole" --encoding=vp9 || 
$XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start :10 "--start=konsole" 
--encoding=vp9 || xpra _proxy_start :10 "--start=konsole" --encoding=vp9

After that, xpra terminates.

with kind regards,
Alex

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages xpra depends on:
ii  adduser   3.117
ii  init-system-helpers   1.54
ii  libavcodec58  7:4.0.2-1+b1
ii  libavformat58 7:4.0.2-1+b1
ii  libavutil56   7:4.0.2-1+b1
ii  libc6 2.27-5
ii  libglib2.0-0  2.56.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libpam0g  1.1.8-3.8
ii  libswscale5   7:4.0.2-1+b1
ii  libturbojpeg0 1:1.5.2-2+b1
ii  libvpx5   1.7.0-3
ii  libwebp6  0.6.1-2
ii  libx11-6  2:1.6.6-1
ii  libx264-152   3:0.152.2851+gitba24899-dmo2
ii  libx265-160   2.8-4
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxkbfile1   1:1.0.9-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python2.7.15-3
ii  python-gi-cairo   3.28.3-1
ii  python-gtk2   2.24.0-5.1+b1
ii  python-rencode1.0.5-1+b2
ii  x11-xserver-utils 7.7+8
ii  xserver-xorg-input-void   1:1.4.1-1+b2
ii  xserver-xorg-video-dummy  1:0.3.8-1+b1

Versions of packages xpra recommends:
ii  keyboard-configuration 1.185
ii  ksshaskpass [ssh-askpass]  4:5.13.4-1
ii  kwalletcli [ssh-askpass]   3.01-1
ii  openssh-client 1:7.7p1-4
ii  python-dbus1.2.8-2+b1
ii  python-gtkglext1   1.1.0-9.1
ii  python-imaging 4.3.0-2
ii  python-lz4 

Bug#860431: missing RFP

[Jeffrey Cliff]

Control: retitle -1 RFP: golang-github-cespare-cp-dev -- File Copying for Go

Bug#908134: libpodofo-dev: Wrong linker flag -lpodofo-0 returned from pkg-config

[Mattia Rizzolo]

Control: tag -1 upstream patch
Control: forwarded: https://sourceforge.net/p/podofo/tickets/30
Control: found -1 0.9.5-1

On Thu, Sep 06, 2018 at 03:19:49PM +0200, Bart Libert wrote:
> When I do pkg-config --libs libpodofo-0, I get:
> 
> -lpodofo-0
> 
> However, using this flag, the linker will fail with
> 
> /usr/bin/ld: cannot find -lpodofo-0
> 
> If I just use -lpodofo, everything is fine.
> 
> This is a problem for me as I am using meson to build my project, and this 
> uses pdk-config to get the correct flags

Interesting, so nobody is using pkg-config with libpodofo or something,
I suppose…

Forwarded upstream, otherwise I'll eventually upload this:

|--- src/libpodofo.pc.in(revision 1937)
|+++ src/libpodofo.pc.in(working copy)
|@@ -6,5 +6,5 @@
| Name: @CMAKE_PROJECT_NAME@
| Description: A C++ library to work with the PDF file format
| Version: @PODOFO_VERSION@
|-Libs: -L${libdir} -lpodofo-@PODOFO_VERSION_MAJOR@
|+Libs: -L${libdir} -lpodofo
| Cflags: -I${includedir}


OOI, why did you file this against the experimental version?  Isn't
unstable affected as well?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#860431: golang github mixup

[Jeffrey Cliff]

Control: retitle -1 golang-github-cespare-cp-dev -- File Copying for Go

Bug#908098: dgit: Bulding with "dgit cowbuilder" does not allow building source,any,all packages

[Ruben Undheim]

Hi Ian!

> > a cowbuilder hook) can see lintian errors in the source. I missed a
> > few lintians because of it some time back, and then I stopped using
> > "gbp cowbuilder" as a consequence.
> 
> Mmmm.

sorry, should be "dgit cowbuilder".
 
> > In other words, the .changes file produced does not list the .dsc and
> > .orig.tar.gz files. Even when adding the dpkg-buildpackage switch -F, dgit
> > seems to override it.
> 
> Yes, indeed it does.  It builds the source separately, and merges that
> with the builder-generated changes.
> 
> > Do you think it would be possible to add a command line switch for this? Or
> > maybe just respect whatever "dpkg-buildpackage switch" is chosen?
> 
> The dpkg-buildpackage switches control the generation of source
> packages, but not anything to do with lintian.  So that isn't the
> answer I think.
 
So the lintians for the source package don't appear if manually running lintian
/var/cache/pbuilder/result/mypackage*.changes on a package built with "dgit
cowbuilder". But if you build with normal cowbuilder they appear. This problem
in itself therefore has nothing to do with triggers.

> > I think this applies for the other "builders" in dgit also (sbuild,
> > pbuilder..).
> 
> Yes.

In the function "massage_dbp_args" in dgit, the argument is this:

  # Since we split the source build out so we can do strange things
  # to it, massage the arguments to dpkg-buildpackage so that the
  # main build doessn't build source (or add an argument to stop it
  # building source by default).

I do not completely understand. What would fall apart if you just let
dpkg-buildpakcage build the source?


Cheers
Ruben

Bug#908155: Coordination with upstream developers not universally applied

[Moritz Muehlenhoff]

Source: developers-reference
Severity: normal

"3.1.4. Coordination with upstream developers" says

"You have to forward these bug reports to the upstream developers so that they
can be fixed in a future upstream release."

That's not the current/best practice for a number of packages, either because
of the sheer volume of bug reports/size of the package or because some of the
bugs are very specific to the reporters setup and having the Debian maintainer
as a middle person forwarding information back and forth would be useless
(e.g. for the Linux kernel where a lot of bug reports are hardware-specific).

The current formulation will cause false expections for end users.

Maybe alternatively make this

"You can either forward these bug reports to the upstream developers yourself
or ask the reporter to report them upstream, so that they can be fixed in a
future upstream release."

Cheers,
Moritz

Bug#908146: libreoffice-dictionaries: Dealing with Breaks/Replaces against ancient dicts in other myspell/hunspell packages.

[Mattia Rizzolo]

Hi Agustin!

On Thu, Sep 06, 2018 at 07:00:16PM +0200, Agustin Martin wrote:
> I have recently received some bug reports about making transitional myspell
> packages to hunspell packages contained in lo-dicts. Some of them refer to
> myspell packages containing old versions of the same dict shipped with
> lo-dicts, so version in lo-dicts should really be used.

I saw and acted upon similar bugs already in the past, nothing
particularly new to be explained :)

> I think this should be dealt previously from inside lo-dicts adding
> appropriate Breaks/Replaces, and old packages made transitional afterwards.

Note that if you also look for a home to keep those transitional
packages, we can also build them within lo-dicts (we would drop them
after buster, which also means after ubuntu 18.04, so everything's
great).
But from what I can see the source packages you mentions in this bug
report are building something else anyway, so I guess they can also keep
building those transitional packages.

> A proposed patch is added.

Please just confirm you won't need anything else, and I'll upload your
patch quickly so you can turn the rest into transitional packages :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature