Bug#883840: Retitling the bug report as per new upstream release of spglib

[Andrius Merkys]

retitle 883840 RFS: spglib/1.10.3-1 [ITP] -- C library for crystal symmetry 
determination
thanks

I have updated the package as per new upstream patch release of "spglib".

Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#894276: lighttpd: mod_openssl.so missing in debian package

[Flynn Marquardt]

Package: lighttpd
Version: 1.4.49-1
Severity: important

Dear Maintainer,

the ssl support in lighttpd is now a separate module.
The module mod_openssl.so is build, but not packaged.

This renders lighttpd unusable in real world use.

Please add /usr/lib/lighttpd/mod_openssl.so to the package.

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

Kernel: Linux 4.15.13 (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)

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.47-2+b2
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.27-2
ii  libfam0   2.7.0-17.2+b1
ii  libpcre3  2:8.39-9
ii  libssl1.1 1.1.0g-2
ii  lsb-base  9.20170808
ii  mime-support  3.60
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages lighttpd recommends:
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils 
pn  lighttpd-doc  
ii  openssl   1.1.0g-2
ii  php-cgi   1:7.2+60
ii  php7.0-cgi [php-cgi]  7.0.28-1
ii  php7.2-cgi [php-cgi]  7.2.3-1
ii  rrdtool   1.7.0-1

-- Configuration Files:
/etc/lighttpd/lighttpd.conf changed [not included]
/etc/logrotate.d/lighttpd changed [not included]

-- no debconf information

Bug#894211: xserver-xorg-video-nouveau: Screen frozen every few seconds for less than a second

[Stanimir Stoyanov]

On Tue, 27 Mar 2018 20:54:47 +0200 Sven Joachim 
wrote:
> On 2018-03-27 14:37 +0300, Stanimir Stoyanov wrote:
>
> > Package: xserver-xorg-video-nouveau
> > Version: 1:1.0.15-2
> > Severity: important
> >
> > Dear Maintainer,
> >
> > After a recent update the system become unusable. Every few seconds
it's frozen
> > for less than a second. From the dmesg I can see the timings match
a loop of
> > entries like
> >
> > [  461.313187] nouveau :01:00.0: pci: failed to adjust lnkctl
speed
> > [  461.381089] snd_hda_intel :01:00.1: Enabling via
vga_switcheroo
> > [  472.791114] snd_hda_intel :01:00.1: Disabling via
vga_switcheroo
> > [  473.091231] snd_hda_intel :01:00.1: Cannot lock devices!
> > [  473.091470] ACPI: \_SB_.PCI0.P0P2.PEGP: failed to evaluate _DSM
>
> What makes you think this is a bug in xserver-xorg-video-
nouveau?  This
> package has not seen "a recent update" (in fact, it has not been
changed
> for 9 months), and your Xorg.1.log shows that X does not even try to
> load the nouveau driver.
>
> Cheers,
>    Sven
>

Hi Sven,

The fact that I see the nouveau lnkctl speed error in the dmesg output 
makes me think it could be related. I've tried setting nomodeset in grub 
- the system boots, but after entering my credentials its showing only 
the gnome background image.


I'm sorry if the cause is not in the driver, and will be grateful for 
any suggestions or directions where to look for the issue.


Cheers,
Stan

Bug#805395: predict.gbm() using single.tree=TRUE does not return the correct predictions with multinomial distribution

[Andreas Tille]

Hi David,

thanks for your quick response.

I need to admit I'm lacking the background to understand your example
but I read your mail that you agree that version 2.1.1 is buggy.  The
bug does not contain any input data to reproduce the issue for version
2.1.3.  Would you be able to reproduce it or may be it is even fixed
in the latest version?  If not could you imagine a fix or do you think
it can be fixed in the upcoming gbm3?  If yes to the last question is
there any estimation when gbm3 will be available from CRAN?

Kind regards

  Andreas

On Tue, Mar 27, 2018 at 09:47:47AM -0700, David Paulsen wrote:
> Hello,
> 
> I clearly could have provided better documentation.
> 
> There was an issue I believe in the predict function when single.tree was
> set to TRUE.
> 
> The first 6 trees of the model are printed out to show the the first two
> trees for each of the three classes.
> 
> The first set of predictions are shown for using 1 and 2 trees.
> 
> The maths show that the manual addition of values from each of the trees
> match the first set of predictions.
> 
> The second set of predictions do not match the expected result from each
> tree.
> 
> Example:
> search document for 0.1126044 shows that the value of a two-tree prediction
> matches arithmetically, but the addend to 0.1126044 is not found in results
> for single.tree prediction.
> 
> search document for -0.04196866 shows that this value is found
> in predictions for two-tree sum and single.tree = TRUE result, and switches
> class position from prediction set 1 to prediction set1 (single.tree).
> 
> David

-- 
http://fam-tille.de

Bug#894267: wamerican: please remove the non-word 'ans' from /usr/share/dict/words

[James Powell]

FYI, I checked with the upstream maintainer first.

> From: Geoff Kuenning 
> To: powe...@pdx.edu
> Subject: Re: Ispell bug: mystery word 'ans' (common misspelling of 'and') in 
> words
> Date: Mon, 26 Mar 2018 19:48:51 -0700
> 
> I don't see it in my master dictionaries.  Apparently it's crept 
> into the Debian dictionary.  "ANS" is a common acronym but I 
> couldn't find a definition for it as a word.  So I agree that it 
> shouldn't be there, but unfortunately I don't know who the Debian 
> maintainers are.
> 
> > (This may be an emacs bug)
> >
> > System: linux
> > Version: Other
> > Conditions:
> > 
> >
> > Description:
> > The words file in /usr/share/dict (which you may not maintain, 
> > but I'm
> > at a loss to find the maintainer) in Debian 9 includes the 
> > mystery
> > word 'ans'.  This is a common misspelling of 'and' and isn't in 
> > my
> > English dictionary, so I'll agitate for its removal.
> >
> > Thank you for your work on ispell.
> >


-- 
James E. Powell, MS
Pronouns: he/his
Applied Physics PhD Candidate
Department of Physics
Portland State University
Home page: http://web.pdx.edu/~powellj
Office: SRTC 409B Phone: +1-503-725-8515

Bug#893332: ghostscript: Ghostscript cannot find Resource directory

[Jean-Philippe MENGUAL]

It was my dame: for space save, I copied /usr/share/ghostscript on
another partition and created a symlink from /usr/share/ghostscript to
the new location. And it does not work, that is gs command requires the
folder exists in /usr/share, and not a symlink.

Regards

signature_jp_2
Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe



Le 27/03/2018 à 21:53, Jean-Philippe MENGUAL a écrit :
> Hi,
>
> Well, after many stupid trials and thanks to a lot of help by you and
> upstream, the most useful thing I can add is:
> 1. I isolated the command which seems to be a problem:
> gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
>     -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
>     -sOutputFile=out.ras \
>     -sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
>     -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
>     -dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
>     -I/usr/share/cups/fonts \
>     input.pdf
>
> Result:
> D [18/Mar/2018:03:56:11 +0100] [Job 71] ./base/gsicc_manage.c:1148: 
> gsicc_open_search(): Could not find default_gray.icc 
> D [18/Mar/2018:03:56:11 +0100] [Job 71] | ./base/gsicc_manage.c:1799: 
> gsicc_set_device_profile(): cannot find device profile
> D [18/Mar/2018:03:56:11 +0100] [Job 71] Unrecoverable error: rangecheck in 
> .putdeviceprops
>
>
>
>
> 2. As requested, I created a simplified gs document, to test results
> without so much filters:
> gs -sDEVICE=tiff24nc -sOutputFile=out.tif input.pdf Here I get:
> default_grau.icc not found, gs says that it cannot find
> default_rgb.icc. and the initial error. Now upstream seems to say it
> is a Debian problem and I am out ou idea. Many thanks for further help
> Regards
> signature_jp_2
> Logo HypraJEAN-PHILIPPE MENGUAL
> DIRECTEUR TECHNIQUE ET QUALITÉ
> 102, rue des poissonniers, 75018, Paris
> Tel : +331 84 73 06 61  Mob : +336 76 34 93 37
> 
> jpmeng...@hypra.fr 
> www.hypra.fr 
> Facebook Hypra  Twitter Hypra
>  Linkedin Jean-Philippe
> 
>
>
> Le 27/03/2018 à 12:32, Brian Potkin a écrit :
>> On Sat 24 Mar 2018 at 19:37:37 +, Brian Potkin wrote:
>>
>>> tags 893332 moreinfo
>>> thanks
>>>
>>>
>>> On Sun 18 Mar 2018 at 04:55:38 +0100, Jean-Philippe MENGUAL wrote:
>>>
 I try to print a test page from CUPS in a Samsung printer.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

 See the log attached (see from line 3455), explaining what happens. I am 
 concerned by job 71 stuff.

* What was the outcome of this action?

 The printing fails.
>>> Thank you for the report and the logs, Jean-Philippe.
>>>
>>> Your upstream report has received advice to follow. How did you go on with 
>>> this?
>>>
>>> You have also posted to debian-user
>>>
>>>   https://lists.debian.org/debian-user/2018/03/msg00662.html
>>>
>>> and advice was offered there. Is there any feedback to give?
>> Jean-Philippe has continued his conversation with upstream at
>>
>> https://bugs.ghostscript.com/show_bug.cgi?id=695873
>>
>> (starting at comment 11) and added to the thread on debian-user. He has
>> been advised to update us on his progress in #893332.
>>
>> Regards,
>>
>> Brian.
>>
>

Bug#894272: gitlab: Problem on upgrade from 8.13 - 9.5 - 10.5. Probably local setup problem

[Pirate Praveen]

On ബുധന്‍ 28 മാർച്ച് 2018 07:03 രാവിലെ, David L wrote:
> -- The start-up result is RESULT.
> Mar 28 02:26:28 kanade.darkbolt.net gitlab-workhorse[29141]: 
> time="2018-03-28T02:26:28+02:00" level=info msg=Starting 
> version="gitlab-workhorse (unknown version)"
> Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]: bundler: failed to 
> load command: sidekiq (/usr/local/bin/sidekiq)

This is still using gem installed sidekiq. You have to remove all the
binaries from /usr/local/bin as well.

sudo rm /usr/local/bin/sidekiq

(possibly more gems that installs a command)

> Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]: LoadError: cannot 
> load such file -- 
> /usr/share/rubygems-integration/all/specifications/bin/sidekiq
> Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]:   
> /usr/local/bin/sidekiq:23:in `load'
> Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]:   
> /usr/local/bin/sidekiq:23:in `'
> Mar 28 02:26:29 kanade.darkbolt.net systemd[1]: gitlab-sidekiq.service: Main 
> process exited, code=exited, status=1/FAILURE
> Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: gitlab-sidekiq.service: 
> Failed with result 'exit-code'.
> Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: Failed to start GitLab 
> Sidekiq Worker.
> -- Subject: Unit gitlab-sidekiq.service has failed






signature.asc
Description: OpenPGP digital signature

Bug#847428: Package the Entire "eclipse.jdt.core"

[殷啟聰 | Kai-Chung Yan]

Thank you for this!

However, the Jack & Jill toolchain is deprecated now and we no longer plan to 
package it...



signature.asc
Description: OpenPGP digital signature

Bug#894180: Fwd: Bug#894180: Acknowledgement (util-linux: Possible still present Bug on "Debian 7/Wheezy" w/ dmesg command on a "SE-208DB/TSBS" External ODD)

[Luis Henrique]

Dear Maintainer

Hi again

Follows below the reference url address with full information of the
External ODD:

*http://www.linux-hardware-guide.com/2013-12-23-samsung-se-208dbtsbs-external-dvd-8x-dvd±rw-24x-cd-rom-24x-cd-rw-5x-dvd-ram-6x-dvd±r-dual-layer-usb-2-0
*
*( Wayback Machine Snapshot (Archive.org) until the site back to be online )

[...]

Review of Linux Compatibility

The Samsung SE-208DB/TSBS is an external DVD writer, which is connected via
USB cable to USB 2.0. It has the USB ID 0e8d:1806 and is identified as:

0e8d:1806 MediaTek Inc.

The drive is fully supported by Linux and gets initialized automatically by
the Linux kernel:

usb 1-1.3: new high-speed USB device number 10 using ehci_hcd

scsi4 : usb-storage 1-1.3:1.0

scsi 4:0:0:0: CD-ROM TSSTcorp CDDVDW SE-208DB TS01 PQ: 0 ANSI: 0

sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray

sr 4:0:0:0: Attached scsi CD-ROM sr0

sr 4:0:0:0: Attached scsi generic sg2 type 5

[...]


The TSST Corporation (Toshiba Samsung Storage Technology -- Toshiba and
Samsung Fusion) stop back in 2016 the manufacturing of Optical Disc Drives,
and this segment was stopped this manner. The another fusion HLDT (Hitachi
/ LG Data Technology - Fusion of Hitachi and LG) continues to manufacturate
still in nowadays "Optical Disc Drives"

*References:*

*https://www.kitguru.net/components/optical-drive/jon-martindale/tsst-has-stopped-manufacturing-optical-drives/*



Thanks.


Best Regards.

Luis, Brazil.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0e8d:1806 MediaTek Inc. 
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 0930:6545 Toshiba Corp. Kingston DataTraveler 102 Flash 
Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Bus 001 Device 022: ID 0930:6545 Toshiba Corp. Kingston DataTraveler 102 Flash 
Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick

Bug#880771: libdwarf/dwarfdump cross compile

[Helmut Grohne]

On Tue, Mar 27, 2018 at 05:10:14PM -0700, David Anderson wrote:
> On 03/26/2018 09:26 PM, Helmut Grohne wrote:
> > Cool. Before we continue, could you do a brief terminology check? Both
> > autotols and Debian (dpkg) use GNU terminology[1] for build/host/target.
> > This notably differs from mozilla terminology and tends to cause
> > confusion. Please stick with GNU terminology, because it is the one that
> > autotools use and it is more expressive than mozilla terminology.
> 
> I would appreciate some more-specific terminology guidance.

I added a link explaining it in very much detail to my last mail. It
tries to clarify the wors "build", "host" and "target". Do you have a
specific question. It was this link:

https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html

Another explanation can be found in man dpkg-architecture on Debian
systems.

> I don't understand mozilla terminology...either.

That can be a good thing as you can avoid confusion by not looking at
mozilla's terminology.

> Where have I gone wrong? Point out an example or two?

It's that this is not obvious. For example, your remark about
AC_TRY_COMPILE can either mean that something went very wrong for you or
that you were incorrectly using "build" there.

Then you said "target library". Either you confused it with "host
library" or elfutils is more complex than I thought and it is
target-dependent (very unusual, but possible in this case). I expected
that "target" would be irrelevant for dwarfutils.

So what you wrote makes little sense to me and it is far from obvious
which part might be wrong, if any.

I suggest that resend your previous mail after carefully checking each
of the words "build", "host", and "target" against their definitions
(and telling which definition you used unless you use GNU terminology).

Helmut

Bug#845297: Bug #845297: Website transition from CVS to Git

[Paul Wise]

On Wed, Mar 28, 2018 at 12:38 AM, Osamu Aoki wrote:
> On Wed, Mar 21, 2018 at 04:06:46PM +0100, Laura Arjona Reina wrote:
> ...
>> I have some questions:
>> 1.- would the cvs2git script allow incremental updates? in case "yes", 
>> wouldn't
>> make more sense to avoid the extra commits related to the conversion? I'm
>> talking about these lines in the script:
>
> No, according to their web site;
>
> http://www.mcs.anl.gov/~jacob/cvs2svn/cvs2git.html
>   cvs2git, like cvs2svn, does not support incremental conversion

Laura was referring to the cvs2git script I attached to the bug
earlier, not the one you mention.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#894063: Pending fixes for bugs in the java3d package

[pkg-java-maintainers]

tag 894063 + pending
thanks

Some bugs in the java3d package are closed in revision
37b91bdedb5d957bec807c53354af001dbae071b in branch 'master' by tony
mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/java3d.git/commit/?id=37b91bd

Commit message:

Link with gcc -shared, not ld; don't explicitly link with libc.

(Closes: #894063)
- Thank you to Matthias Klose for the patch.

Bug#894011: java-common: Please move ia64 to the list of Java 9 architectures

[tony mancill]

On Sun, Mar 25, 2018 at 12:00:27PM +0200, John Paul Adrian Glaubitz wrote:
> Source: java-common
> Version: 0.62
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Hi!
> 
> With OpenJDK9 bootstrapped for ia64, it's now possible to set
> it as the default JDK for ia64. Thus, please move ia64 from the
> list of Java 5 architectures to the list of Java 9 architectures.
 
Hi Adrian,

I will take care of this with the next upload.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#816424: Please support recent version of libuv

[Joe Cheng]

httpuv's master branch has been upgraded to libuv 1.18.0. It should be
releasing to CRAN in the next few weeks.
https://github.com/rstudio/httpuv


On Tue, Mar 27, 2018 at 2:31 AM Andreas Tille  wrote:

> Hi Joe,
>
> the Debian R packaging team maintains your httpuv package in Debian.
> There was a bug reported[1] and the bug reporter suggested the solution
> to replace the code copy of libuv inside httpuv by the Debian packaged
> library.  I tried to do so but I was running into several build errors
> which are caused by the fact that your copy is of
>
> $ head -n1 ChangeLog
> 2013.07.26, Version 0.10.13 (Stable)
>
> while Debian has packaged
>
> $ head -n1 ChangeLog
> 2017.12.02, Version 1.18.0 (Stable)
>
>
> Could you imagine to upgrade your internal code copy to the recent
> version and adapt your code to work with the recent API?
>
> Kind regards
>
> Andreas.
>
> Control: tags -1 upstream
> COntrol: forwarded -1 Joe Cheng 
>
>
> [1] https://bugs.debian.org/816424
>
> --
> http://fam-tille.de
>

Bug#879619: Autopkgtest for ncbi-tools6

[Aaron M. Ucko]

Liubov Chuprikova  writes:

> Thanks a lot for helping me out with this project! I saw your messages to
> Aaron and it was a relief for me that there was a "real" problem to build
> the package. I had it too, but thought, this was with updating package
> dependencies on my computer..

Thanks for adding these tests, and sorry you ran into dpkg errors along
the way!  Please let me know if you have usage questions about any of
this package's tools.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#894275: RFP: cinnamon-applet-multicore-sys-monitor -- System monitor applet (CPU, Memory, Network, Disk IO) for Cinnamon

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: cinnamon-applet-multicore-sys-monitor
  Version : git
  Upstream Author : ?
* URL : 
https://github.com/linuxmint/cinnamon-spices-applets/tree/master/multicore-sys-monitor@ccadeptic23
* License : GPL3
  Programming Lang: JavaScript
  Description : System monitor applet (CPU, Memory, Network, Disk IO) for 
Cinnamon

>From all the system monitor applets I've checked, this seems to be the most
promising one.
Uses gtop.

Bug#806316: wontfix for now

[Sandro Tosi]

On Tue, Mar 27, 2018 at 10:08 PM, Sandro Tosi  wrote:
> Hello Piotr,
>
> On Sun, 5 Jun 2016 20:47:46 +0200 Piotr =?utf-8?Q?O=C5=BCarowski?=
>  wrote:
>> FTR: I didn't apply this patch because exceptions are allowed only in
>> private dirs intentionally - I don't want to deal with all the
>> exceptions while f.e. upgrading Python 3 to new 3.X version.
>> It makes perfect sense in 2.X, but we should not package new stuff for
>> 2.X anyway...
>>
>> I do not close this bug or mark it as wontfix, because even for 3.X we
>> will most probably have to figure something out sooner or later (but I
>> still hope that it will be fixed upstream, in the interpreter)
>
> now i have a valid reason for this feature: it was requested to
> install the test files for pylint. pylint has, on purpose, invalid
> files among these tests, but forcing pycompile/py3compile on them of
> course it will fail, making the package uninstallable as-is;
>
> i'll try shipping customized postinst scripts, but that sucks. is
> there any other solution than having this bug fixed?

and now this:

Usage: pycompile [-V [X.Y][-][A.B]] DIR_OR_FILE [-X REGEXPR]
  pycompile -p PACKAGE

pycompile: error: --exclude option works with private directories
only, please use /usr/share/python/bcep to specify public modules to
skip


it would be really helpful if all these options and restrictions were
documented somewhere, f.e. pycompile manpage and/or --help. like what
is bcep? (what does it that name mean?) is it a file (as it looks from
that message)? reading pycompile code appears as if it's a directory
where files are read from; what's their format?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Andreas Tille  writes:

> Question: Is real m68k hardware used at all or is it just some people
> like you who run qemu instances for whatever reason?  This is an honest
> question since I'm pretty sure that no scientific software (like R and
> others) have any use on m68k and I'm afraid it just drains time from
> you (and other porters) and maintainers.

My understanding is that there are still some users with actual
hardware, but the autobuilders use qemu for better performance and/or
reliability, which I admit doesn't say much for the hardware. ;-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#894274: RFP: cinnamon-applet-gpaste-reloaded -- GPaste support for Cinnamon

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: cinnamon-applet-gpaste-reloaded
  Version : git
  Upstream Author : ?
* URL : 
https://github.com/linuxmint/cinnamon-spices-applets/tree/master/gpaste-reloa...@feuerfuchs.eu
* License : ? Probably something OSS, as based on GNOME Extension
  Programming Lang: JavaScript
  Description : GPaste support for Cinnamon

GPaste is a clipboard management tool. This applet lets you access your 
clipboard through an icon in the panel.

This is a completely re-written GPaste applet based on the gnome shell 
extension. It offers the following features:
Search for entries
Access the native GPaste GUI
Support for multiple histories
Manually add entries to the history
Unlimited instances

Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable

[Mark Brown]

On Tue, Mar 27, 2018 at 08:51:30PM +, Debian FTP Masters wrote:

>* Non-maintainer upload.
>* debian/patches:
>  - Add patch to fix FTBFS with GCC 7. (Closes: #853714)
>  - Add patch to fix FTBFS on architectures with strict alignment
>requirements. (Closes: #836021)

Please don't send unnanounced non-maintainer uploads - note that this
package can't ever be usefully installed or used at the moment as the
rest of the NIS suite isn't split out into separate packages, the RC
bugs are useful for keeping it out of releases.


signature.asc
Description: PGP signature

Bug#806316: wontfix for now

[Sandro Tosi]

Hello Piotr,

On Sun, 5 Jun 2016 20:47:46 +0200 Piotr =?utf-8?Q?O=C5=BCarowski?=
 wrote:
> FTR: I didn't apply this patch because exceptions are allowed only in
> private dirs intentionally - I don't want to deal with all the
> exceptions while f.e. upgrading Python 3 to new 3.X version.
> It makes perfect sense in 2.X, but we should not package new stuff for
> 2.X anyway...
>
> I do not close this bug or mark it as wontfix, because even for 3.X we
> will most probably have to figure something out sooner or later (but I
> still hope that it will be fixed upstream, in the interpreter)

now i have a valid reason for this feature: it was requested to
install the test files for pylint. pylint has, on purpose, invalid
files among these tests, but forcing pycompile/py3compile on them of
course it will fail, making the package uninstallable as-is;

i'll try shipping customized postinst scripts, but that sucks. is
there any other solution than having this bug fixed?

thanks

Bug#893980: www.debian.org: Many mirrors have no or untrusted HTTPS certificates

[Paul Wise]

On Tue, 2018-03-27 at 09:24 +0200, Martin Monperrus wrote:

> If some primary mirrors support HTTPS with a proper certificate

As Rhonda and I said before, that isn't possible because of the
requirements on the ftp.*.debian.org domains.

> What would be great is a list of all mirrors which support HTTPS with
> a proper certificate. That list can be maintained automatically.

I'm sure the mirror monitoring team would welcome help with that,
their code is available here and their results are available here:

https://salsa.debian.org/mirror-team/
https://mirror-master.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#894273: policykit-1-gnome: polkit-gnome-authentication-agent-1 fails to start when hidepid=2

[Chiraag Nataraj]

Package: policykit-1-gnome
Version: 0.105-6
Severity: normal

Dear Maintainer,

I happen to run my system with /proc mounted with hidepid=2 for security 
reasons. I tried starting polkit-gnome-authentication-agent-1 as well as 
mate-polkit and they both failed (I use awesome window manager, so I need to 
start the auth agent manually). Further investigation/sleuthing led me to 
discover that hidepid=2 breaks PolicyKit (it supposedly also breaks 
systemd-logind, but I haven't had any trouble with that yet...maybe that's been 
fixed?). This seems to be completely undocumented, as I ended up discovering 
this on a random forum. Am I missing something or is this completely 
undocumented? And if it is undocumented, can we put a note in the package 
description or in the README? Alternatively, is there a workaround for this and 
can we document that somewhere?

Sincerely,

Chiraag

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

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

Versions of packages policykit-1-gnome depends on:
ii  libc6  2.27-2
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.0-4
ii  libgtk-3-0 3.22.29-2
ii  libpolkit-agent-1-00.113-6
ii  libpolkit-gobject-1-0  0.113-6
ii  policykit-10.113-6

policykit-1-gnome recommends no packages.

policykit-1-gnome suggests no packages.

Bug#891168: miniupnpd po update

[Adriano Rafael Gomes]

On Fri, Mar 02, 2018 at 03:07:58PM +0800, Yangfl wrote:

Control: tags -1 moreinfo

Hi,

Thanks for your translation! I've merged your po. However, as
miniupnpd disabling old options and the refactor of init script, some
strings need updating.

The newest version can be found at
https://salsa.debian.org/miniupnp-team/miniupnpd/blob/debian-sid/debian/po/templates.pot


Hi,

Please accept the update file.

Thanks.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1

[Paul Wise]

On Tue, 2018-03-27 at 22:49 +0200, Alexis Murzeau wrote:

> Can you post your logs ?

Attached.

> I cannot reproduce this error either with sbuild or pbuilder.

I guess the LANG/LC_ALL in your chroots has UTF-8 in the name,
for some reason mine only has LANG=C LC_ALL=C.

Strangely, the RB infra builds fine with LANG=C LC_ALL=C:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/streamlink.html

> I previously encountered this encoding error and it should have been fixed
> by debian/patches/0006-Avoid-use-of-non-ASCII-in-plugins.patch.

You only patched one of the UTF-8 files, not all of them:

$ file src/streamlink/plugins/* | grep -v ASCII
src/streamlink/plugins/showroom.py:   Python script, UTF-8 Unicode 
text executable

This file includes some Chinese characters in the keys of a dict,
so I don't think you will be able to patch them out.

$ grep -C3 --color='auto' -P -n "[^\x00-\x7F]" 
src/streamlink/plugins/showroom.py
42-
43-# the "low latency" streams are rtmp, the others are hls
44-_rtmp_quality_lookup = {
45:"オリジナル画質": "high",
46:"オリジナル画質(低遅延)": "high",
47-"original spec(low latency)": "high",
48-"original spec": "high",
49:"低画質": "low",
50:"低画質(低遅延)": "low",
51-"low spec(low latency)": "low",
52-"low spec": "low"
53-}

So upstream needs to load the plugin files using the UTF-8 encoding.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


streamlink_0.11.0+dfsg-1~bpo9+1_amd64.build
Description: Binary data


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

Bug#893907: lynx: The subdomain name 'news' freezes Lynx

[Thomas Dickey]

On Fri, Mar 23, 2018 at 05:24:03PM +, Pelle Hjek wrote:
> Package: lynx
> Version: 2.8.9dev16-3
> Severity: important

no - "normal" (read the guidelines).
 
> Dear Maintainer,
> 
> When I use Lynx to read a web page, it freezes when the web page starts
> with the subdomain 'news.' For example, on the terminal when I type in
> this:
> 
> lynx news.ycombinator.com
> 
> Then Lynx freezes while displaying this message in the status bar:
> 
> Making NNTP connection to news.ycombinator.com
> 
> Lynx handles https://news.ycombinator.com just fine, but when https://

https isn't the same as http.  This url happens to work with http.

It's trying to connect to nntp because no protocol was specified,
and has done this consistently for quite a while.

I've applied changes which will be in the next patch.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#894272: gitlab: Problem on upgrade from 8.13 - 9.5 - 10.5. Probably local setup problem

[David L]

Package: gitlab
Version: 10.5.6+dfsg-1
Severity: normal

Hi,

I have a gitlab installation working originally on 8.13 version.

This installation stop working when some upgrades for 9.5 enters testing.
I have the same failure from my test installation, some gems installed locally.

History are:

I've upgrade 8.13 to 9.5.4+dfsg-7. Not working because sprockets problem.
I've upgrade 9.5.4 to 10.5.5+dfsg-3. Not working because sprockets problem.

I've done a full backup of installation and database, deleted all locally 
installed gems, apt-get remove gitlab && apt-get remove ruby && purge gitlab && 
apt-get install gitlab.

As I've detected, on some cases, purge fails because there's some process 
running as gitlab user.

My problem:

After a full delete of gitlab & ruby and another dependences, I've do a clean 
install (without restore any backup yet).

Gitlab installs correctly, but, there's a problem starting sidekiq. There's the 
log:


Child worker:
 AssetSize  Chunks Chunk Names
c3789bfe47e4e75a43bd.worker.js  188 kBmain  [emitted]  main
[../../../../../../var/lib/gitlab/.node_modules/diff/dist/diff.js] 
/var/lib/gitlab/.node_modules/diff/dist/diff.js 184 kB {main} [built]

[../../../../../lib/nodejs/babel-loader/lib/index.js!./ide/lib/diff/diff_worker.js]
 /usr/lib/nodejs/babel-loader/lib!./ide/lib/diff/diff_worker.js + 1 modules 1.1 
kB {main} [built]
A dependency job for gitlab.service failed. See 'journalctl -xe' for details.
invoke-rc.d: initscript gitlab, action "start" failed.
● gitlab.service - GitLab Services
   Loaded: loaded (/lib/systemd/system/gitlab.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Thu 2018-03-22 10:43:41 CET; 5 days ago
 Main PID: 4989 (code=exited, status=0/SUCCESS)

Mar 27 19:12:51 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
Mar 27 19:12:51 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
Mar 27 19:27:39 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
Mar 27 19:27:39 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
Mar 27 20:24:02 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
Mar 27 20:24:02 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
Mar 28 02:15:30 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
Mar 28 02:15:30 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned error 
exit status 1
Processing triggers for systemd (238-3) ...
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
kanade:~# journalctl -xe
-- Subject: Unit gitlab-mailroom.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit gitlab-mailroom.service has finished starting up.
-- 
-- The start-up result is RESULT.
Mar 28 02:26:28 kanade.darkbolt.net gitlab-workhorse[29141]: 
time="2018-03-28T02:26:28+02:00" level=info msg=Starting 
version="gitlab-workhorse (unknown version)"
Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]: bundler: failed to 
load command: sidekiq (/usr/local/bin/sidekiq)
Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]: LoadError: cannot 
load such file -- /usr/share/rubygems-integration/all/specifications/bin/sidekiq
Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]:   
/usr/local/bin/sidekiq:23:in `load'
Mar 28 02:26:29 kanade.darkbolt.net gitlab-sidekiq[29135]:   
/usr/local/bin/sidekiq:23:in `'
Mar 28 02:26:29 kanade.darkbolt.net systemd[1]: gitlab-sidekiq.service: Main 
process exited, code=exited, status=1/FAILURE
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: gitlab-sidekiq.service: Failed 
with result 'exit-code'.
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: Failed to start GitLab Sidekiq 
Worker.
-- Subject: Unit gitlab-sidekiq.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit gitlab-sidekiq.service has failed.
-- 
-- The result is RESULT.
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: Dependency failed for GitLab 
Services.
-- Subject: Unit gitlab.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit gitlab.service has failed.
-- 
-- The result is RESULT.
Mar 28 02:27:00 kanade.darkbolt.net systemd[1]: gitlab.service: Job 
gitlab.service/start failed with result 'dependency'.
Mar 28 02:27:00 kanade.darkbolt.net s

Bug#894271: ITP: cmark-gfm -- GitHub enhanced version of cmark, the common markdown parser

[Keith Packard]

Package: wnpp
Severity: wishlist
Owner: Keith Packard 

* Package name: cmark-gfm
  Version : 0.28.3.gfm.12
  Upstream Author : John MacFarlane 
* URL : https://ithub.com/github/cmark
* License : BSD, MIT/X
  Programming Lang: C
  Description : GitHub enhanced version of cmark, the common markdown
parser

Common Markdown provides a useful standardized language for building formatted
documents. The 'cmark' parser, already in Debian, provides a basic parser
implementing the core Common Markdown standard. People involved in the GitHub
system have forked 'cmark' in a way which leaves the core language unchanged
but extends the system to add table and other additional formatting methods.

This extended version of Common Markdown is used within the github system for
formatting .md files in project repositories and, as such, is becoming widely
used within that environment.

I've got preliminary packaging working here:

https://anonscm.debian.org/cgit/users/keithp/cmark-gfm.git/

I'm packaging this so I can use it to replace asciidoc in the altos package as
asciidoc is being deprecated.

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Jason Pleau]

Hi.

I took a few hours last weekend to work on this. While I was able to
have "working" packages for both xpp and i3ipcpp, I could not get
polybar to use them (the whole thing is glued together nicely it seems
and trying to split them caused me headaches).

So I went ahead and worked on packaging the whole repo (and submodules)
together.

Repo: https://salsa.debian.org/jpleau-guest/polybar

Current status: it builds in a chroot and works on my sid install.

TODO:

- There's a few copyright info missing (ie: lib/concurrentqueue)-
- After installing the package, it won't do anything because the config
file is not found (it should be in $HOME/.config/polybar). There is one
shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to
tell the users that when they install the package?

Note that I made a custom get-orig-source rule. The tarball didn't
contain xpp and i3ipcpp (github generated tarballs don't include
submodules). It seems to work fine, feedback welcome on this one..

Thanks

-- 
Jason Pleau

Bug#887740: moon-buggy: Please bump the Debian part of the version number

[Jeremy Bicha]

On Tue, Feb 6, 2018 at 3:50 AM, Raphael Hertzog  wrote:
> So I would also suggest to bump version to 1:1.0.51-12. Not for launchpad,
> but for end users.

Christian, may I do an NMU now to bump the Debian revision number?

Thanks,
Jeremy Bicha

Bug#856086: Bug#885037: monster-masher: Please don't (Build-)Depend on gconfmm2.6

[Jeremy Bicha]

Control: block 894269 by 891701
Control: block 894269 by 856086

On Wed, Feb 28, 2018 at 6:05 AM, Markus Koschany  wrote:
> I don't have any objections if you want to remove them right now but I
> think you can achieve the removal of esound/Gnome2 libs anyway and you
> don't have to wait for us. Just point the ftp team to this bug report.
> This is true for all affected games maintained by the games team. They
> will be broken in unstable but I think this might even raise more
> awareness. Testing users won't be affected.

esound's removal from Testing already happened in early January. This
package and the abandoned synaesthesia are the last packages to block
esound's removal from unstable.

Thanks,
Jeremy Bicha

Bug#894270: installation-reports

[jose jose]

Package: installation-reports

Boot method: TFTP+USB.iso+ ttl pl2303+network
Image version:
https://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
https://cdimage.debian.org/cdimage/weekly-builds/armhf/iso-cd/debian-testing-armhf-xfce-CD-1.iso
Date: 28.03.2018_01:50am msk

Machine:   ---Orange pi zero h2---
Processor: 1.2 Ghz Quad Core H2+ ARM Cortex A7 CPU
Memory:512 MB DDR3 SDRAM
Partitions: < вывод результата команды df -Tl; лучше таблицу разделов в
необработанном (raw) виде>

Вывод результата команд lspci -knn и lspci -nn:

Base System Installation Checklist:
[O] = OK, [E] = Ошибка (описать подробности ниже), [ ] = не пробовал

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:



Installation went fine on the sdcard.
Installed on Orange piZERO .
Loading from the Sdcard does not occur.




==
U-Boot SPL 2017.09-armbian (Nov 22 2017 - 16:49:05)
DRAM: 512 MiB
Failed to set core voltage! Can't set CPU frequency
Trying to boot from MMC1


U-Boot 2017.09-armbian (Nov 22 2017 - 16:49:05 +0100) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
In:serial
Out:   serial
Err:   serial
Net:   phy interface0
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Autoboot in 1 seconds, press  to stop
=> run mmc_boot
switch to partitions #0, OK
mmc0 is current device
** Bad device specification mmc -bootable **
Scanning mmc :1...
Found U-Boot script /boot.scr
2627 bytes read in 153 ms (16.6 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
4121088 bytes read in 511 ms (7.7 MiB/s)
** File not found /dtbs/4.14.0-3-armmp-lpae/sun8i-h3-orangepi-pc.dtb **
SCRIPT FAILED: continuing...
=> 
=>
=> bootz

Starting kernel ...

---Hangs no reaction---

==

Bug#894269: RM: esound -- RoM; RoQA; unmaintained for years

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: eso...@packages.debian.org
Tags: moreinfo

esound has been unmaintained and deprecated for several years. It was
removed from Testing in January.

Please remove it from Debian.

I am adding blocker bugs for the 2 remaining reverse dependencies.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#891701: Intent to file removal bug for synaesthesia

[Jeremy Bicha]

Hi,

It's been a month since this bug was filed without any response.

Please reply immediately if you object to this package being removed
from Debian.

Thanks,
Jeremy Bicha

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Andrew Caudwell]

Upstream has implemented my suggestion to re-add default initialization as
opt-in via a new define:

https://github.com/g-truc/glm/issues/735
https://github.com/g-truc/glm/commit/8390a77b3a278b15259e5ca6e67f7e41badc457b

Could you apply the commit as a patch so maintainers can then define
GLM_FORCE_CTOR_INIT and avoid having to modifying code?

Let me know as then I can then avoid having to embed the current release in
my software.

Thanks


On Fri, Mar 23, 2018 at 3:07 PM, Andrew Caudwell 
wrote:

> Hi,
>
> On Sat, Mar 17, 2018 at 9:31 AM, Guus Sliepen  wrote:
>
>> tags 892861 + wontfix
>> thanks
>>
>> On Wed, Mar 14, 2018 at 10:48:33AM +1300, Andrew Caudwell wrote:
>>
>> > The packaged version of GLM, 0.9.9~a2 is an alpha (the current release
>> is still
>> > 0.9.8.5) and removes the default initialization of vector, matrix and
>> > quaternion types. Because of this code written against any earlier
>> versions of
>> > GLM may now have uninitialized value bugs introduced by this change
>> (e.g. where
>> > GLM types are member variables of a class) or now behave differently
>> (mat4()
>> > previously gave you an identity matrix, now this gives you a zero'd
>> matrix).
>> > Several issues have been raised upstream (including by myself) to re-add
>> > initialization or at least make it optional.
>> > Additionally the requirement in this version to define
>> GLM_ENABLE_EXPERIMENTAL
>> [...]
>> > to use simple functions like length2() has broken multiple packages. I
>> have put
>> > off fixing this since making it compile just exposes the user to the
>> > uninitialized value bugs. Unfortunately this has now meant my gource and
>> > logstalgia debian packages have been removed from debian since they
>> don't
>> > complile with this GLM version.
>>
>> I believe these are intentional changes by the author of GLM. I expect
>> that GLM 1.0.0 will be released before the next release of Debian, and
>> any packages that depend on GLM should instead be fixed to handle the
>> new behavior.
>>
>
> The upstream author hasn't commented on these issues yet so there's no
> reason to assume they will leave things in the current state without at
> least providing at least a work around to the initialization issue.
>
>>
>> Unless I am mistaken, projects depending on GLM can just #define
>> GLM_ENABLE_EXPERIMENTAL and provide explicit default initializers, which
>> will be backwards compatible with older versions of GLM.
>>
>
> Fixing the default initializers issue requires a thorough code review and
> probably debugging with valgrind to find these cases (-Wuninitialized won't
> find these) which I think is an unreasonable burden on maintainers.
>
> Other distros such as Redhat, Gentoo and Arch Linux have continued to
> package the current release 0.9.8.5 with a fix for the GCC 7.3 issue (which
> only requires changing an == to >=):
>
> https://git.archlinux.org/svntogit/community.git/tree/
> trunk/PKGBUILD?h=packages/glm
>
> Ubuntu 18.04 has imported the current Debian unstable libglm-dev package
> which has made resolving this issue more urgent in my view.
>
> My current work around is to embed the patched version of 0.9.8.5 and
> provide a --with-glm option for distros that have a compatible version of
> the library.
>
> Ideally I would like to be able to use the Debian libglm-dev package so I
> hope you reconsider.
>
> Cheers
>
> Andrew
>
>
>
>>
>> --
>> Met vriendelijke groet / with kind regards,
>>   Guus Sliepen 
>>
>
>

Bug#880771: libdwarf/dwarfdump cross compile

[David Anderson]

On 03/26/2018 09:26 PM, Helmut Grohne wrote:
> Cool. Before we continue, could you do a brief terminology check? Both
> autotols and Debian (dpkg) use GNU terminology[1] for build/host/target.
> This notably differs from mozilla terminology and tends to cause
> confusion. Please stick with GNU terminology, because it is the one that
> autotools use and it is more expressive than mozilla terminology.

I would appreciate some more-specific terminology guidance.
I don't understand mozilla terminology...either.

Where have I gone wrong? Point out an example or two?


>
>> Tested with --host=gcc-arm-linux-gnueabihf
> This is not a supported host architecture for Debian.


Oops.

From README just updated to what I actually did:

./configure --host=arm-linux-gnueabihf

DavidA.

-- 
I don't understand where I ever had time to go to work
for 40 hours a week. -- Bill Cheswick in ;login:

Bug#878800: jgit-cli: IllegalStateException: Cannot set value to a final field 'org.eclipse.jgit.pgm.Daemon.enable'

[Jonathan Nieder]

# renders package unusable
severity 878800 grave
quit

Jonathan Nieder wrote:

>  git clone https://kernel.googlesource.com/pub/scm/git/git
>  cd git
>  make -j8
>  cd t
>  ./t5512-ls-remote.sh -v -i

It turns out that this affects the package more deeply than that.
For example:

$ jgit log
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
java.lang.IllegalStateException: Cannot set value to a final field 
'org.eclipse.jgit.pgm.RevWalkTextBuil
tin.commits'.
at org.kohsuke.args4j.spi.Setters.create(Setters.java:32)
at org.kohsuke.args4j.ClassParser.parse(ClassParser.java:38)
at org.kohsuke.args4j.CmdLineParser.(CmdLineParser.java:96)
at org.kohsuke.args4j.CmdLineParser.(CmdLineParser.java:71)
at org.eclipse.jgit.pgm.opt.CmdLineParser.(CmdLineParser.java:119)
at org.eclipse.jgit.pgm.opt.CmdLineParser.(CmdLineParser.java:102)
at org.eclipse.jgit.pgm.TextBuiltin.parseArguments(TextBuiltin.java:224)
at org.eclipse.jgit.pgm.TextBuiltin.execute(TextBuiltin.java:208)
at org.eclipse.jgit.pgm.Main.execute(Main.java:223)
at org.eclipse.jgit.pgm.Main.run(Main.java:124)
at org.eclipse.jgit.pgm.Main.main(Main.java:98)

This means the jgit command cannot be used at all, and that's the only
command provided by this package.

Bug#894267: wamerican: please remove the non-word 'ans' from /usr/share/dict/words

[James E. Powell]

Package: wamerican
Version: 7.1-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Spell checker advised I fix a misspelling using the non-word 'ans'.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Searched my personal and system dictionaries for the word.

   * What was the outcome of this action?

The word is in Debian 9 /usr/share/dict/words:

/usr/share/dict$ grep ans words | head -5
alezans
anglicans
ans
anse
anses

   * What outcome did you expect instead?

/usr/share/dict$ grep ans words | head -5
alezans
anglicans
anse
anses


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



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

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

Versions of packages wamerican depends on:
ii  debconf [debconf-2.0]  1.5.61

wamerican recommends no packages.

wamerican suggests no packages.

-- debconf information:
  shared/packages-wordlist:
  wamerican/languages: american (American English)

Bug#894253: gdc's description contradicts default-d-compiler's description

[Matthias Klose]

Control: reassign -1 default-d-compiler

On 28.03.2018 03:30, Peter De Wachter wrote:
> Package: gdc
> Version: 4:8-20180321-1
> Severity: normal
> 
> Hello,
> 
> The gdc package says:
> 
>> Depends: gdc-8 (>= 8-20180321-1~), libgphobos-dev (= 8-20180321-1)
>> Description-en: D compiler (language version 2), based on the GCC backend
>>  This is a dependency package providing the default D compiler.
>>  Per policy, all packages that contain D sources must use this package
>>  in their Build-Depends line.
> 
> The default-d-compiler package says:
> 
>> Depends: ldc (>= 1:1.8)
>> Description-en: Default D compiler (metapackage)
>>  This is a metapackage installing the default D compiler in Debian
>>  for the respective architecture.
>>  .
>>  Packages building D code should depend on this.
> 
> Only one of these can be true :)

well, did you see any discussion about that? I surely didn't.

Bug#893959: iproute2: tc show option in tc class show and tc filter show not working correctly

[Stephen Hemminger]

On Mon, 26 Mar 2018 13:34:39 +0100
Luca Boccassi  wrote:

> On Sat, 2018-03-24 at 14:43 +0100, Vaclav Zindulka wrote:
> > Package: iproute2
> > Version: 4.14.1-1~bpo9+1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I found some problems in tc class show and tc filter show commands.
> > We
> > use tc in large scale (thousands of subnets) on multiple servers.
> > Whole
> > shaping system is udergoing large overview and I'm rewriting it
> > almost
> > from the scratch. Tc rules are one of key elements so I started to
> > check
> > and change its whole structure. Until now we had everything in parent
> > qdisc 1:0 (all tc filter rules, tc classes). Now I decided to change
> > it,
> > so a lot of classes have its own hfsc qdiscs and in this qdiscs I
> > create
> > whole new structure of tc classes, tc filters a tc qdiscs. Let's say
> > it
> > is a tree within a tree. I can provide simple (prototype) bash
> > script,
> > which led to my discovery. (https://pastebin.com/A57x8fq5 - comments
> > are
> > in czech since I didn't plan to release it anywhere :-) - I can
> > provide
> > further info if needed.
> > 
> > Problem is very annoying since I need to get
> > stats from tc -s class show dev ...etc. 
> > 
> > 1. First problem - tc class show dev enp0s31f6 prints whole structure
> > two times. I compared it with "sudo tc -s class show dev enp0s31f6" |
> > grep
> > -c "class" vs "sudo tc -s class show dev enp0s31f6" | sort | uniq |
> > grep
> > -c "class" which produces about a half of records. Reference class
> > 2000: (produced by my script 2000 - 4fff) is shown twice (same
> > for
> > 2000: root). I'm not sure about behavior of executing command twice
> > in this case but it can't be defined twice for sure. Tc is veeery
> > picky
> > :-)
> > 
> > 2. Second problem - tc filter show dev enp0s31f6 show just the parent
> > 1:0 rules. This one is not so critical, since I don't read stats
> > regularly, but for debugging it is very inconvenient since one has to
> > know classId of whole parent (let's say 2000:0 qdisc in which all
> > those
> > filters reside). When I execute tc filter show dev enp0s31f6 parent
> > 2000: (including colon :-) I get all those defined filter rules and
> > hash
> > tables. But not with base command.
> > 
> > I discovered this on version 4.9 from stable stretch repository. I
> > tried
> > to install backport version 4.14 but resutls were exactly the same. I
> > didn't try to reboot after upgrade yet tho. I'll do this after
> > finishing
> > this bugreport. I didn't try to compile newest version from source
> > since
> > I need some kind of stable solution to put it on 21 servers.
> > 
> > What I expected was to see defined classes just once. And to see tc
> > filter rules with base show command without specifying parent's
> > classid
> > for every hfsc qdisc containing additional rules and hash tables.  
> 
> Hi,
> 
> Since you mentioned it's working in the same way in 4.9 to 4.14 it
> doesn't look like it's a regression, so a better place to ask would
> probably be netdev: http://vger.kernel.org/vger-lists.html#netdev
> 
> Stephen, any comment on the behaviour described above?
> 

No idea, the print code in iproute2 is just taking what kernel
passes back and displays. Most likely it is in hfsc code which to be honest
is not widely used by the kernel maintainers. I wouldn't be surprised if it
had bugs.


pgpC3PGwMtHwY.pgp
Description: OpenPGP digital signature

Bug#881001: Bug#884510: libevocosm: Build-Depends on libcoyotl-dev which is scheduled for removal

[Jeremy Bicha]

Control: tags 881001 -moreinfo
Control: severity 884510 normal
Control: reassign 884510 ftp.debian.org
Control: retitle 884510 RM: libevocosm -- ROM; dead upstream, low popcon

On Tue, Mar 27, 2018 at 6:56 PM, Al Stone  wrote:
> On 03/27/2018 02:01 PM, Jeremy Bicha wrote:
>>> the maintainer of libcoyotl has requested its removal: #881001,
>>> libevocosm is the only remaining user.
>>
>> Both packages have the same maintainer!
>>
>> Al, do you want libevocom removed from Debian too?
>>
>> Thanks,
>> Jeremy Bicha
>>
>
> Whups, forgot about that.  Yes, or at least orphaned.  Upstream is the
> same for both and development stopped quite some time ago.  If someone
> is interested in maintaining these, please pick them up.

Let's just go ahead and remove them both.

Thanks,
Jeremy Bicha

Bug#808276: Fix two description typos

[Anders Jonsson]

tags 808276 +patch
thanks


This changes (conteins->contains) along with another typo (commmand) in 
the same line.



Regards,
Anders Jonsson
From ac779f9fa2d56a0f074d4ae3843a23ddef3edf9f Mon Sep 17 00:00:00 2001
From: Anders Jonsson 
Date: Wed, 28 Mar 2018 00:38:07 +0200
Subject: debian/control: fix typos

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 5ecea76..c52dc6d 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Description: command line tools for libmarisa
  Matching Algorithm with Recursively Implemented StorAge (MARISA) is a static
  and space-efficient trie data structure.
  .
- This package conteins commmand line tools for libmarisa.
+ This package contains command line tools for libmarisa.
 
 Package: libmarisa0
 Architecture: any
-- 
2.16.2

Bug#859103: strip-nondeterminism: does not replace all timestamps in zip archives

[Benjamin Moody]

Package: strip-nondeterminism
Version: 0.034-1
Followup-For: Bug #859103

This is especially annoying because the "local extra field" includes
the file *access* time:

   $ rm -f foo 1.zip 2.zip
   $ touch -d 2015-01-01 foo
   $ zip 1.zip foo
   $ zip 2.zip foo
   $ strip-nondeterminism 1.zip 2.zip
   $ diffoscope 1.zip 2.zip
...
 0010:      0300 1c00 666f  ..fo
-0020: 6f55 5409 0003 50d4 a454 50d4 a454 7578  oUT...P..TP..Tux
+0020: 6f55 5409 0003 50d4 a454 62a1 ba5a 7578  oUT...P..Tb..Zux
 0030: 0b00 0104 e803  04e8 0300 0050 4b01  .PK.
...

(Which makes me think, for testing build reproducibility, it'd be
wise to try one build using noatime and another using
strictatime.  But anyway...)


The problem here is that Archive::Zip::ZipFileMember is not
designed to allow modifying the localExtraField() at all.  From
the man page:

   localExtraField( [ $newField ] )
   localExtraField( [ { field => $newField } ] )
   Gets or sets the extra field that was read from the local header.
   This is not set for a member from a zip file until after the member
   has been written out. The extra field must be in the proper format.

That is to say, before calling $zip->overwrite(),
localExtraField() returns an empty string.  Moreover, for
ZipFileMembers, manually setting the field has no effect - even
if you call overwrite(), then go back and modify the
localExtraFields, then call overwrite() again, it will re-read
the fields from the zip file.

(As far as I can tell, the *only* way to manually specify a
localExtraField using Archive::Zip is to decompress and
recompress each member.)


Here is a rather kludgy patch to make Archive::Zip behave the way
that strip-nondeterminism seems to expect:

--- /usr/share/perl5/Archive/Zip/ZipFileMember.pm
+++ Archive/Zip/ZipFileMember.pm
@@ -43,6 +43,25 @@
   and $self->uncompressedSize == 0);
 }
 
+sub localExtraField {
+my $self = shift;
+
+# If this function is called with an argument, it overrides the
+# original field contents from the source archive.
+if (@_) {
+$self->{'_localExtraFieldUserDefined'} = 1;
+}
+# Otherwise, the value is loaded lazily, the first time it is needed.
+elsif (!defined $self->{'_localExtraFieldUserDefined'}
+   and defined $self->{'externalFileName'}) {
+my $origpos = $self->fh()->tell();
+$self->rewindData();
+$self->fh()->seek($origpos, IO::Seekable::SEEK_SET);
+}
+
+return $self->SUPER::localExtraField(@_);
+}
+
 # Seek to the beginning of the local header, just past the signature.
 # Verify that the local header signature is in fact correct.
 # Update the localHeaderRelativeOffset if necessary by adding the 
possibleEocdOffset.
@@ -156,10 +175,17 @@
 }
 
 if ($extraFieldLength) {
-$bytesRead =
-  $self->fh()->read($self->{'localExtraField'}, $extraFieldLength);
-if ($bytesRead != $extraFieldLength) {
-return _ioError("reading local extra field");
+if ($self->{'_localExtraFieldUserDefined'}) {
+$self->fh()->seek($extraFieldLength, IO::Seekable::SEEK_CUR)
+  or return _ioError("skipping local extra field");
+}
+else {
+$bytesRead =
+  $self->fh()->read($self->{'localExtraField'}, $extraFieldLength);
+if ($bytesRead != $extraFieldLength) {
+return _ioError("reading local extra field");
+}
+$self->{'_localExtraFieldUserDefined'} = 0;
 }
 }
 

Here is a different kludgy approach to work around the issue in
strip-nondeterminism, rewriting the local file headers by hand:

--- /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm
+++ File/StripNondeterminism/handlers/zip.pm
@@ -23,6 +23,7 @@
 
 use File::Temp;
 use Archive::Zip qw/:CONSTANTS :ERROR_CODES/;
+use Fcntl q/SEEK_SET/;
 
 # A magic number from Archive::Zip for the earliest timestamp that
 # can be represented by a Zip file.  From the Archive::Zip source:
@@ -207,11 +208,36 @@
}
$member->cdExtraField(
normalize_extra_fields($member->cdExtraField(), 
CENTRAL_HEADER));
-   $member->localExtraField(
-   normalize_extra_fields($member->localExtraField(), 
LOCAL_HEADER));
}
my $old_perms = (stat($zip_filename))[2] & oct();
$zip->overwrite();
+
+   # Archive::Zip::ZipFileMembers do not allow modifying the
+   # local extra field, so we need to rewrite the local file
+   # headers by hand.  This assumes that normalize_extra_fields
+   # does not change the length of the field(s).
+
+   open(my $fh, '+<', $zip_filename) or die "Unable to open $zip_filename: 
$!";
+   for my $member ($zip->members()) {
+   my $extra_field = 
normalize_extra_fields($member->localExtraField(), LOCAL_HEADER);
+

Bug#894266: redshift: Drop Build-Depends on gconf

[Jeremy Bicha]

Source: redshift
Version: 1.11-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster patch

Your package build-depends on gconf, but gconf will be removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

It looks like all you need to do here is Build-Depend on libglib2.0-dev instead 
of libgconf2-dev. (No patch attached but this is a trivial fix.)

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#881001: Bug#884510: libevocosm: Build-Depends on libcoyotl-dev which is scheduled for removal

[Al Stone]

On 03/27/2018 02:01 PM, Jeremy Bicha wrote:
>> the maintainer of libcoyotl has requested its removal: #881001,
>> libevocosm is the only remaining user.
> 
> Both packages have the same maintainer!
> 
> Al, do you want libevocom removed from Debian too?
> 
> Thanks,
> Jeremy Bicha
> 

Whups, forgot about that.  Yes, or at least orphaned.  Upstream is the
same for both and development stopped quite some time ago.  If someone
is interested in maintaining these, please pick them up.

-- 
Ciao,
al
--
Al Stone Debian Developer
E-mail: a...@debian.org  http://www.debian.org
--

Bug#892528: ant: Depends on GCJ which is going away

[Emmanuel Bourg]

Control: fixed -1 1.9.10-2
Control: close -1

This was fixed by Matthias' NMU.

Bug#847428: Package the Entire "eclipse.jdt.core"

[Emmanuel Bourg]

On Thu, 8 Dec 2016 15:48:36 +0800 seamlikok wrote:

> android-toolchain-jack requires both the existing libecj-java and the
> "org.eclipse.jdt.compiler.apt" module in "eclipse.jdt.core". As the
> upstream of src:ecj is exactly "eclipse.jdt.core", so I wish that the
> entire "eclipse.jdt.core" is packaged in Debian as several non-GUI
> Java libraries.

I upgraded ecj today to the version 3.12.3 (upstream tag 4.6.3) and I
added the compiler.apt classes to /usr/share/java/ecj.jar. Could you
check if it suits your needs for android-toolchain-jack?

Bug#859461: xterm: seperate package for resize would be nice

[Thomas Dickey]

On Tue, Mar 27, 2018 at 06:12:03PM -0400, Thomas Dickey wrote:
> On Tue, Mar 27, 2018 at 11:16:55PM +0200, Julien Cristau wrote:
...
> > I'm not convinced this split is a good idea.  But:
> 
> agreed...
> 
> popcon would probably score this as 10.

...unless it's a dependency of xterm, of course.
 
> > > +Architecture: any
> > > +Multi-Arch: foreign
> > > +Depends:
> > > + ${shlibs:Depends},
> > > + ${misc:Depends},
> > 
> > As-is, this would break upgrades, as it's missing Breaks/Replaces
> > against xterm.

...and then you'd have to followup with xterm depending on resize.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#859461: xterm: seperate package for resize would be nice

[Thomas Dickey]

On Tue, Mar 27, 2018 at 11:16:55PM +0200, Julien Cristau wrote:
> Control: tag -1 - patch
> 
> On Fri, Mar 23, 2018 at 14:21:01 +0100, Uwe Kleine-König wrote:
> 
> > Control: tag 859461 + patch
> > 
> > Hello,
> > 
> > On Mon, Apr 03, 2017 at 01:49:32PM -0600, ben hildred wrote:
> > > Which brings me to my request, split resize into a seprate package and 
> > > depend
> > > on it to preserve existing functionality while allowing headless machines 
> > > to
> > > install just resize.
> > I could make use of this, too. Here is a patch:
> > 
> I'm not convinced this split is a good idea.  But:

agreed...

popcon would probably score this as 10.
 
> > diff --git a/debian/control b/debian/control
> > index 711d5d9b54f2..50d7217da720 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -141,3 +142,13 @@ Description: X terminal emulator
> >   .
> >   Those interested in using koi8rxterm will likely want to install the
> >   xfonts-cyrillic package as well.
> > +
> > +Package: resize
> 
> This isn't a good package name.  It's too generic.

:-)
 
> > +Architecture: any
> > +Multi-Arch: foreign
> > +Depends:
> > + ${shlibs:Depends},
> > + ${misc:Depends},
> 
> As-is, this would break upgrades, as it's missing Breaks/Replaces
> against xterm.
> 
> > +Description: Determine size of virtual terminal
> > + This program is used to (re)set the width and height of your current
> > + terminal to the size of the virtual terminal.

The description is another problem...

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#892531: Pending fixes for bugs in the ecj package

[pkg-java-maintainers]

tag 892531 + pending
thanks

Some bugs in the ecj package are closed in revision
e641e71b0d71dac5b16b53c00b90276966585bd7 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/ecj.git/commit/?id=e641e71

Commit message:

No longer build the -gcj packages (Closes: #892531)

Bug#873240: redshift-gtk: redshift doesn't launch either when launching in the console or at start of computer

[John Scott]

Package: redshift-gtk
Version: 1.11-1
Followup-For: Bug #873240

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've upgraded my packages on Buster, including GLib, and I'm now unable
to reproduce this issue. Redshift's GTK+ interface as well as Blueman's
is now working well for me.

Unless someone is still able to reproduce, we may finally be able to
close this bug, though I'm sure the cause will forever remain a mystery. 

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/2 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 redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-5
ii  python3   3.6.4-1
ii  python3-gi3.26.1-2
ii  python3-xdg   0.25-4
ii  redshift  1.11-1

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.28.0-1

redshift-gtk suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlq6weASHGpzY290dEBw
b3N0ZW8ubmV0AAoJEH1hRKYneTBy3sgIAJCPjPKQtsjsFLOV1g+091wM7VDTlHQr
XR+vHgYFanEmoCu3T7WQKBL+uem4HfKplBu9WQwtyFK0hv4/zHJoc+2k3BFLgFvZ
CxXNdQrnPWA+N3IARsuFMKmjOxWP+EicONqZGPgM2G/CRX8OCU9dUQdy6r44fbpC
F6iJytcLpz/Wa/CkGXih0QZr29qlKUvGbRviMz49MRdjwj0pgE5deOCD3UzzpA4u
0ENctDYZsHxhYs1h4SHtyOlmVsGsdVMJCmL2pc+CHiXe9mU7hWD26rXVgUNyrEzH
QpbnzvwSGr9um4V6ODc7Q9A18I7iYR572jEUrKnNuv2h8Z/TW+aZmz0=
=7eKU
-END PGP SIGNATURE-

Bug#893643: nmu: gnome-dvb-daemon_1:0.2.91~git20170110-3

[Emilio Pozuelo Monfort]

On 20/03/18 21:12, Jeremy Bicha wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-CC: sl...@debian.org
> 
> gnome-dvb-daemon is uninstallable in unstable because it needs to be
> rebuilt against the new gstreamer release. (gstreamer set its
> dependency relationships very tightly.)
> 
> Here's a guess at the wanna-build syntax:
> 
> nmu gnome-dvb-daemon_1:0.2.91~git20170110-3 . ANY . unstable . -m
> "Rebuild against gst-plugins-bad1.0 1.14.0-1"
> dw gnome-dvb-daemon_1:0.2.91~git20170110-3 . ANY . -m
> 'gstreamer1.0-plugins-bad (>= 1.14.0)'

Scheduled.

Emilio

Bug#891259: Pending fixes for bugs in the ecj package

[pkg-java-maintainers]

tag 891259 + pending
thanks

Some bugs in the ecj package are closed in revision
babab3dc1f440f119ffe69ae9b3d4bbe25380db3 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/ecj.git/commit/?id=babab3d

Commit message:

New upstream release (from the R4_6_3 tag, identifies itself as 3.12.3) 
(Closes: #891259)

Bug#893189: transition: llvm-defaults to llvm 6.0

[Emilio Pozuelo Monfort]

On 17/03/18 09:43, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> This is again the time to transition to a more recent version of LLVM.
> This time to 6.0. Just like in bug 832098 & 869752, I propose that we skip 
> one version (5.0 here)
> 
> All supported archs are green:
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-6.0&suite=sid 
> 

> I am rebuilding the packages with v6.0.

How did the rebuild go?

Emilio

Bug#893523: transition: qtbase-opensource-src

[Emilio Pozuelo Monfort]

On 19/03/18 20:22, Lisandro Damián Nicanor Pérez Meyer wrote:
> In order to know what we are facing:
> 
> - #893535 deepin-qt5dxcb-plugin: FTBFS with Qt 5.10.1 in experimental
> - #876934 openorienteering-mapper FTBFS: test failures ← not really
> our bug, compiles with qt 5.10.1 but tests keep failing
> - #893540 telegram-desktop maybe a bug in my chroot?
> 
> And that would be all up to Dependency level 2 (at least for my ben's
> runs). I plan to continue testing tomorrow.

(As said on IRC) Trackers added, please let us know when you test the rest of
the rdeps.

Emilio

Bug#894265: matchbox-window-manager: Depends on gconf

[Jeremy Bicha]

Source: matchbox-window-manager
Version: 
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be removed from 
Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

In a test build, I tried dropping the gconf build-dependency and set 
--disable-gconf but the build wouldn't work. It's interesting because the 
current build doesn't even use gconf so it looks like
this is just a bug in matchbox's build system.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894264: perl: downgrading utf8 key hashes to bytes

[Leszek Dubiel]

Package: perl
Version: 5.24.1-3+deb9u2
Severity: normal

Dear Maintainer,
this optimization has bitten me once again, so I report this as a bug... 

Run the code: 

#!/usr/bin/perl -CSDA
use utf8; 
use strict; 
use warnings; 
my %h; 
$h{'Góry'} = 1; 
'Góry' =~ /\A[[:alnum:]]*\z/ or die "error 1"; 
for (keys %h) { 
$_ =~ /\A[[:alnum:]]*\z/u or die "error 2"; 
}
for (keys %h) { 
$_ =~ /\A[[:alnum:]]*\z/ or die "error 3"; 
}


It prints error 3. This means that perl somehow degrades utf string to
bytes in keys of hases. 

Was discussed here also: 

http://www.perlmonks.org/?node_id=1197369


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

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

Versions of packages perl depends on:
ii  dpkg   1.18.24
ii  libperl5.245.24.1-3+deb9u2
ii  perl-base  5.24.1-3+deb9u2
ii  perl-modules-5.24  5.24.1-3+deb9u2

Versions of packages perl recommends:
ii  netbase  5.4
pn  rename   

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
pn  make
pn  perl-doc

-- no debconf information

Bug#894258: python-asgi-ipc FTBFS with python3-msgpack 0.5.1

[Adrian Bunk]

On Tue, Mar 27, 2018 at 10:39:14PM +0100, Simon McVittie wrote:
> On Tue, 27 Mar 2018 at 23:48:35 +0300, Adrian Bunk wrote:
> > pkg_resources.DistributionNotFound: The 'msgpack-python' distribution was 
> > not found and is required by asgi-ipc
> 
> Looks like more fallout from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893844
> but in this case presumably it'll need sourceful changes.

This is only a test issue, the resulting package is fine if 
python-asgi-ipc is built with nocheck.

> codesearch.debian.net suggests that this might be a more widespread
> problem (but hopefully not all the search hits are release-critical).

python-asgi-ipc is the only package where I found this specific problem.

> smcv

cu
Adrian

-- 

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

Bug#894263: boinc: Renabling use of wxWebView

[Olly Betts]

Source: boinc
Version: 7.9.3+dfsg-1
Severity: normal

Thanks to Scott Talbert we now have a GTK3 build of wxWidgets, which
reinstates the webview package that boinc prefers to use but had to
be disabled because the GTK2 version of the underlying library it uses
was obsolete.

Disabling webview apparently gives reduced functionality, so it would
be good to reenable this now we can.

Feel free to adjust severity - I just went for the default as I'm not
entirely sure of the impact of disabling webview on users, but boinc
upstream didn't seem happy about building without it.

Assuming the upstream code support GTK3
(http://boinc.berkeley.edu/trac/wiki/SoftwarePrereqsUnix doesn't seem to
even mention GTK is needed), it's probably a case of switching BDs from
libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev and libgtk2.0-dev to
libgtk-3-dev (a quick look in codesearch suggests that GTK is needed for
a custom taskbar widget, so that probably needs to match the GTK version
used by wx).

Cheers,
Olly

Bug#894258: python-asgi-ipc FTBFS with python3-msgpack 0.5.1

[Simon McVittie]

On Tue, 27 Mar 2018 at 23:48:35 +0300, Adrian Bunk wrote:
> pkg_resources.DistributionNotFound: The 'msgpack-python' distribution was not 
> found and is required by asgi-ipc

Looks like more fallout from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893844
but in this case presumably it'll need sourceful changes.

codesearch.debian.net suggests that this might be a more widespread
problem (but hopefully not all the search hits are release-critical).

smcv

Bug#894262: regexxer: Intent to remove package from Debian

[Jeremy Bicha]

Source: regexxer
Version: 0.10-3
Severity: serious
Tags: sid buster

regexxer was orphaned 8 years ago. [1]

Its last upstream release, 0.10, was in 2011.

Although there has been some activity in git [2], I think we can consider this 
software unmaintained if it never does releases.

It is blocking the eventual removal of gconf from Debian. Therefore, I intend 
to file a removal bug for this package soon.

[1] https://bugs.debian.org/569345
[2] https://git.gnome.org/browse/regexxer/log/

Thanks,
Jeremy Bicha

Bug#894261: regexxer: Depends on gconf

[Jeremy Bicha]

Source: regexxer
Version: 0.10-3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be removed from 
Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894251: mate-terminal spams systemd journal with dbus max_match_rules_per_connection

[Matt Zagrabelny]

On Tue, Mar 27, 2018 at 3:52 PM, Alex ARNAUD  wrote:

>
> 3) Add the generated file to your reply
>

Done.

And also inline since it is smallish:

[keybindings]
help='disabled'

[profiles/default]
foreground-color='#'
visible-name='Default'
palette='#2E2E34343636:#:#4E4E9A9A0606:#C4C4A0A0:#34346565A4A4:#757550507B7B:#060698209A9A:#D3D3D7D7CFCF:#57575353:#EFEF29292929:#8A8AE2E23434:#FCFCE9E94F4F:#72729F9FCFCF:#ADAD7F7FA8A8:#3434E2E2E2E2:#ECEC'
background-darkness=0.79186602870813394
use-system-font=false
use-theme-colors=false
background-type='transparent'
default-show-menubar=false
font='Liberation Mono 10'
allow-bold=false
scrollback-unlimited=true
bold-color-same-as-fg=true
bold-color='#'
background-color='#'

Please reach out if there is anything else I can provide.

Thanks! (merci beaucoup!)

-m


mate-terminal.conf
Description: Binary data

Bug#799064: bash-completion: "pmount /med" then TAB hangs after upgrade to jessie

[Iiro Laiho]

To quote from here: 
https://unix.stackexchange.com/questions/243972/pmount-hangs-on-bash-autocomplete


The problem with the reference file arises in the function |_pmount()| 
at line 62 of the file (added newlines for readability - not in 
original file):


|devices="$( command ls $(grep -v '^[[:space:]]*#' /etc/pmount.allow )\ 
$(grep 1 /sys/block/*/removable |\ sed -e 
's,/sys/block/,/dev/,;s,/removable:1,*,') 2>/dev/null |\ sort -u | sed 
-e 's,\(^/dev/\)\(.*\),\1\2 \2,' ; \ #this last line is of interest, 
as the errors occur here grep $mdir /proc/mounts | sed -e 
's,.*\($mdir/[^ ]*\).*,\1,' )"|


with the error being that for

|grep $mdir /proc/mounts|

the variable |$mdir| is not defined previously and thus the script hangs.

So I added the definition of |mdir|

|mdir="$(readlink -f /media)"|
as taken from the |_pumount()| function of the same script (see line 
75) at e.g. line 36 as |mdir| seems to be standing for *m*edia (or 
*m*ount) *dir*ectory, i.e. the standard mount point for |pmount|.


Please append the fix to the stock reference file.

Bug#820231: ttf-marvosym: Consider to remove your package

[Jeremy Bicha]

On Tue, Mar 27, 2018 at 5:07 PM, Hilmar Preuße  wrote:
> On 27.03.2018 22:04, Jeremy Bicha wrote:
>> I'm bumping the severity so that this package can be auto-removed from
>> Testing, while removal from Unstable is still blocked.
>>
> Thanks for the reminder!
>
> Meanwhile there is #881704 (ROM; abandoned upstream from Gürkan Myczko)
> and #884509 (reporting that ttf-marvosym still has rdeps.
>
> So I guess this one here can be closed.

No :-)

This bug at severity serious will cause this package to be
auto-removed from testing soon. Therefore, this bug has a purpose and
should not be closed. If this bug is closed, then this package will
re-migrate to Testing 5 days later!

Thanks,
Jeremy Bicha

Bug#859461: xterm: seperate package for resize would be nice

[Julien Cristau]

Control: tag -1 - patch

On Fri, Mar 23, 2018 at 14:21:01 +0100, Uwe Kleine-König wrote:

> Control: tag 859461 + patch
> 
> Hello,
> 
> On Mon, Apr 03, 2017 at 01:49:32PM -0600, ben hildred wrote:
> > Which brings me to my request, split resize into a seprate package and 
> > depend
> > on it to preserve existing functionality while allowing headless machines to
> > install just resize.
> I could make use of this, too. Here is a patch:
> 
I'm not convinced this split is a good idea.  But:

> diff --git a/debian/control b/debian/control
> index 711d5d9b54f2..50d7217da720 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -141,3 +142,13 @@ Description: X terminal emulator
>   .
>   Those interested in using koi8rxterm will likely want to install the
>   xfonts-cyrillic package as well.
> +
> +Package: resize

This isn't a good package name.  It's too generic.

> +Architecture: any
> +Multi-Arch: foreign
> +Depends:
> + ${shlibs:Depends},
> + ${misc:Depends},

As-is, this would break upgrades, as it's missing Breaks/Replaces
against xterm.

> +Description: Determine size of virtual terminal
> + This program is used to (re)set the width and height of your current
> + terminal to the size of the virtual terminal.

Cheers,
Julien

Bug#894260: ITP: ghostwriter -- A distraction-free Markdown editor for Windows and Linux

[Sebastien CHAVAUX]

Package: wnpp
Severity: wishlist
Owner: Sebastien CHAVAUX 

* Package name: ghostwriter
  Version : 1.5.0
  Upstream Author : wereturtle 
* URL : https://wereturtle.github.io/ghostwriter/
* License : GPL-3.0+
  Programming Lang: C, C++, HTML, CSS, QMake, Objective-c++, other...
  Description : A distraction-free Markdown editor for Windows and Linux

Distraction-free, themeable Markdown editor
 ghostwriter is a Markdown editor that provides a themable,
 distraction-free writing environment, along with a live HTML
 preview as you type, easy document navigation with an outline HUD,
 and export to popular document formats with Sundown, Pandoc,
 MultiMarkdown, Discount or cmark processors.  It also features a
 live word count and auto-save. Eliminate distractions in
 fullscreen mode, or concentrate on the current text you are writing
 in focus mode.  It even remembers your last opened file and position
 within the file, so you can pick up where you last left off.

I use this software to write comfortably in markdown, it is very comfortable, 
easy to use. It has a lot of functions:

   * HUD windows can now be closed using the Esc key when they have focus.
   * A new option has been added to highlight double spaces at the end of a 
line.
   * Github-style task lists can be made using the * and + bullet point 
characters, in addition to the - character.
   * Support for ConTeXt and wkhtmltopdf Pandoc has been added.
   * Auto-matching characters for selected text now respects the matching 
preferences while typing without text selected.
   * Typing a single quote (') will no longer result in a second quote being 
automatically inserted after the cursor if the cursor is in the middle of a 
word.
   * Most settings have been moved to a new preferences.
   * Font size can now be increased by pressing Ctrl + = or decreased by 
pressing Ctrl + -. It can also be changed by using Ctrl and the mouse wheel.
   * When exporting to other file formats, the output file will be opened after 
export with its default application.
   * E-books created using Pandoc will also be generated with a table of 
contents.
   * When passing in a path through the command line, a new file will be 
created.
   * When typing a * character, ghostwriter would auto-insert a second * 
character in anticipation of emphasized text. The auto-inserted second * will 
be removed if a space is typed to accommodate a bullet list instead.
   * Rudimentary support for HiDPI has been added. See notes below.
   * Various performance enhancements and tweaks have been made under the hood.

It can be compared to retext https://lwn.net/Articles/686879/, but with a much 
larger look and function.
I would like to maintain it even though I have no skills in packaging, maybe in 
a team, or with a co-maintainer, I would need a particular help or a sponsor, I 
have light knowledge in Debian package. The package works at home, rebuilding 
from the source package of ubuntu with builddepends of Debian 9.
Cordially

Bug#636425: RM: paman -- RoQA; Dead upstream, no maintainer

[Felipe Sateler]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: paman -- RoQA; Dead upstream, no maintainer

On Wed, 3 Aug 2011 01:45:29 +0200 Ricardo Mones  wrote:
> Package: paman
> Version: 0.9.4-1
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
>
> CJ van den Berg  is not interested in the
> paman package anymore and would like to remove his address.
>
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.
>
> (If the person is listed as Maintainer, what we are asking is to please
> step in as a new maintainer.)
>

In all these years, nobody got interested in this package. Moreover,
upstream has not had a new release since 2007 and has moved on to
other projects.

Please remove paman from unstable.

Saludos

Bug#820231: ttf-marvosym: Consider to remove your package

[Hilmar Preuße]

On 27.03.2018 22:04, Jeremy Bicha wrote:

Hi Jeremy,

> I'm bumping the severity so that this package can be auto-removed from
> Testing, while removal from Unstable is still blocked.
> 
Thanks for the reminder!

Meanwhile there is #881704 (ROM; abandoned upstream from Gürkan Myczko)
and #884509 (reporting that ttf-marvosym still has rdeps.

So I guess this one here can be closed.

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

Bug#894212: please add dragonboard 820c support

[Vagrant Cascadian]

On 2018-03-27, Riku Voipio wrote:
> I've created a merge request to add Dragonboard 820c support
> in debian u-boot build:
>
> https://salsa.debian.org/debian/u-boot/merge_requests/1

Thanks!

Have you read up on the rests for testers:

  https://wiki.debian.org/U-boot


The only thing I'm unsure of about the pull request is why you removed
Ricardo Salveti as a tester for dragonboard410c?


Not that I've received a lot of feedback about tested versions from many
people:

  https://wiki.debian.org/U-boot/Status


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#894259: drupal7: DRUPAL-PSA-2018-001

[Salvatore Bonaccorso]

Source: drupal7
Version: 7.57-1
Severity: grave
Tags: security upstream

Hi Gunnar,

This bug is to track in Debian https://www.drupal.org/psa-2018-001 .
Sinc the assigned CVE is not yet know, we have so a Debian BTS
reference.

Regards,
Salvatore

Bug#894251: mate-terminal spams systemd journal with dbus max_match_rules_per_connection

[Alex ARNAUD]

Le 27/03/2018 à 21:15, Matt Zagrabelny a écrit :

Let me know what I can do to help solve this issue.


Could you provide us your Mate terminal configuration with the 
followings steps:

1) Install the package dconf-cli to export the configuration

2) Export the configuration to a file:
dconf dump /org/mate/terminal/ > mate-terminal.conf

3) Add the generated file to your reply

Best regards,
Alex.

Bug#894258: python-asgi-ipc FTBFS with python3-msgpack 0.5.1

[Adrian Bunk]

Source: python-asgi-ipc
Version: 1.4.2-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-asgi-ipc.html

...
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd 
/build/1st/python-asgi-ipc-1.4.2/.pybuild/cpython3_3.6_asgi-ipc/build; 
python3.6 -m unittest discover -v 
asgi_ipc (unittest.loader._FailedTest) ... ERROR
tests.test_asgi_ipc (unittest.loader._FailedTest) ... ERROR

==
ERROR: asgi_ipc (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: asgi_ipc
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/loader.py", line 462, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.6/unittest/loader.py", line 369, in 
_get_module_from_name
__import__(name)
  File 
"/build/1st/python-asgi-ipc-1.4.2/.pybuild/cpython3_3.6_asgi-ipc/build/asgi_ipc/__init__.py",
 line 2, in 
__version__ = pkg_resources.require('asgi_ipc')[0].version
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 892, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 778, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'msgpack-python' distribution was not 
found and is required by asgi-ipc


==
ERROR: tests.test_asgi_ipc (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests.test_asgi_ipc
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.6/unittest/loader.py", line 369, in 
_get_module_from_name
__import__(name)
  File 
"/build/1st/python-asgi-ipc-1.4.2/.pybuild/cpython3_3.6_asgi-ipc/build/tests/test_asgi_ipc.py",
 line 3, in 
from asgi_ipc import IPCChannelLayer
  File 
"/build/1st/python-asgi-ipc-1.4.2/.pybuild/cpython3_3.6_asgi-ipc/build/asgi_ipc/__init__.py",
 line 2, in 
__version__ = pkg_resources.require('asgi_ipc')[0].version
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 892, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 778, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'msgpack-python' distribution was not 
found and is required by asgi-ipc


--
Ran 2 tests in 0.001s

FAILED (errors=2)
E: pybuild pybuild:330: test: plugin distutils failed with: exit code=1: cd 
/build/1st/python-asgi-ipc-1.4.2/.pybuild/cpython3_3.6_asgi-ipc/build; 
python3.6 -m unittest discover -v 
dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
make: *** [debian/rules:10: build] Error 25

Bug#894257: eog fails with 'BadAccess (attempt to access private resource denied)' for 6000x4000 JPG

[js jb]

Package: eog
Version: 3.28.0-2
Severity: important

Dear Maintainer,

=
After upgrading to eog 3.28.0-2 I saw it continues to fail when opening 24MP 
(6000x4000) JPG files,
although it still works on smaller 8MP files). This used to work as late as eog 
3.26 and there is no problemopening these files with ristretto or geeqie.
Below are some of the messages from /var/log/messages for eog and a backtrace 
of eog (withoug debug
symbols as eog-dbg 3.28 is not yet available on testing):



=> tail -5 /var/log/messages
Mar 27 07:55:04 localhost kernel: [125036.108772] traps: eog[11283] trap int3 
ip:b751e7b0 sp:bff40170 error:0 in libglib-2.0.so.0.5600.0[b74d+12e000]
Mar 27 11:36:20 localhost kernel: [138311.962382] traps: eog[13174] trap int3 
ip:b751f7b0 sp:bfc51240 error:0 in libglib-2.0.so.0.5600.0[b74d1000+12e000]
Mar 27 16:22:40 localhost kernel: [155492.314670] traps: eog[16015] trap int3 
ip:b754c7b0 sp:bfe79ad0 error:0 in libglib-2.0.so.0.5600.0[b74fe000+12e000]
Mar 27 16:23:04 localhost kernel: [155516.672124] traps: eog[16027] trap int3 
ip:b74fc7b0 sp:bfe0ce30 error:0 in libglib-2.0.so.0.5600.0[b74ae000+12e000]
Mar 27 16:27:52 localhost kernel: [155804.824810] traps: eog[16121] trap int3 
ip:b74fb7b0 sp:bfb5e950 error:0 in libglib-2.0.so.0.5600.0[b74ad000+12e000]


=> export GDK_SYNCHRONIZE=1
ME:=> gdb `which eog`
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/eog...(no debugging symbols found)...done.
(gdb) b gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) r A6K01000.JPG
Starting program: /usr/bin/eog A6K01000.JPG
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb3bdeb40 (LWP 16053)]
[New Thread 0xb31ffb40 (LWP 16054)]
[New Thread 0xb27ffb40 (LWP 16055)]
[New Thread 0xb1dffb40 (LWP 16056)]
[New Thread 0xace2eb40 (LWP 16057)]

(eog:16049): Gdk-ERROR **: 16:24:09.919: The program 'eog' received an X Window 
System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 8188 error_code 10 request_code 130 (MIT-SHM) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Thread 1 "eog" received signal SIGTRAP, Trace/breakpoint trap.
0xb7d9e7b0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0xb7d9e7b0 in  () at /lib/i386-linux-gnu/libglib-2.0.so.0
#1  0xb7da0fa9 in g_log_writer_default () at 
/lib/i386-linux-gnu/libglib-2.0.so.0
#2  0xb7d9f32c in g_log_structured_array () at 
/lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xb7d9f582 in g_log_structured () at /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb7038a0c in  () at /usr/lib/i386-linux-gnu/libgdk-3.so.0
#5  0xb70462c4 in  () at /usr/lib/i386-linux-gnu/libgdk-3.so.0
#6  0xb68d3b7a in _XError () at /usr/lib/i386-linux-gnu/libX11.so.6
#7  0xb68d077b in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#8  0xb68d083f in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#9  0xb68d1866 in _XReply () at /usr/lib/i386-linux-gnu/libX11.so.6
#10 0xb68ccf7f in XSync () at /usr/lib/i386-linux-gnu/libX11.so.6
#11 0xb68cd01a in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#12 0xb68d44d3 in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#13 0xb63a2f23 in XShmAttach () at /usr/lib/i386-linux-gnu/libXext.so.6
#14 0xb6f3d2cd in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#15 0xb6f3de0f in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#16 0xb6f3deb4 in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#17 0xb6f0722b in cairo_surface_create_similar_image () at 
/usr/lib/i386-linux-gnu/libcairo.so.2
#18 0xb7001801 in gdk_cairo_set_source_pixbuf () at 
/usr/lib/i386-linux-gnu/libgdk-3.so.0
#19 0xb7f7fe80 in  () at /usr/lib/i386-linux-gnu/eog/libeog.so
#20 0xb7f827c2 in eog_scroll_view_set_image () at

Bug#894256: mailman3 wants to take away mailman.cfg from mailman3-core

[Bjoern Franke]

Package: mailman3
Version: 3.1.1-8~bpo9+1
Severity: normal

Dear Maintainer,


2 root@srv20 /etc/mailman3 # apt-get remove mailman3-core   
   :(
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package 'mailman3-core' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  linux-image-4.9.0-3-amd64 linux-image-4.9.0-4-amd64
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up mailman3 (3.1.1-8~bpo9+1) ...
dbconfig-common: writing config to /etc/dbconfig-common/mailman3.conf
dbconfig-common: flushing administrative password
ucfr: Attempt from package mailman3  to take /etc/mailman3/mailman.cfg away 
from package mailman3-core
ucfr: Aborting.
dpkg: error processing package mailman3 (--configure):
 subprocess installed post-installation script returned error exit status 4
dpkg: dependency problems prevent configuration of mailman3-full:
 mailman3-full depends on mailman3; however:
  Package mailman3 is not configured yet.

dpkg: error processing package mailman3-full (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mailman3
 mailman3-full


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 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)

Versions of packages mailman3 depends on:
ii  dbconfig-sqlite32.0.8
ii  debconf [debconf-2.0]   1.5.61
ii  logrotate   3.11.0-0.1
ii  lsb-base9.20161125
ii  python3 3.5.3-1
ii  python3-aiosmtpd1.1-3~bpo9+1
ii  python3-alembic 0.8.8-2
ii  python3-dnspython   1.15.0-1
ii  python3-falcon  1.0.0-2
ii  python3-flufl.bounce2.3-4
ii  python3-flufl.i18n  2.0.1-1~bpo9+1
ii  python3-flufl.lock  3.2-1~bpo9+1
ii  python3-lazr.config 2.1-1
ii  python3-passlib 1.7.0-2
ii  python3-psycopg22.6.2-1
ii  python3-public  0.5-1
ii  python3-pymysql 0.7.10-1
ii  python3-requests2.12.4-1
ii  python3-sqlalchemy  1.0.15+ds1-1
ii  python3-zope.component  4.3.0-1
ii  python3-zope.configuration  4.0.3-3
ii  python3-zope.event  4.2.0-1
ii  python3-zope.interface  4.3.2-1
ii  ucf 3.0036

Versions of packages mailman3 recommends:
ii  lynx2.8.9dev11-1
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1

Versions of packages mailman3 suggests:
pn  mailman3-doc  
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- debconf information:
  mailman3/config_hyperkitty:
  mailman3/pgsql/manualconf:
  mailman3/mysql/method: Unix socket
  mailman3/db/basepath: /var/lib/mailman3/data
  mailman3/db/app-user: mailman3@localhost
* mailman3/dbconfig-install: false
  mailman3/database-type:
  mailman3/purge: false
  mailman3/dbconfig-reinstall: false
  mailman3/dbconfig-upgrade: true
  mailman3/internal/skip-preseed: false
  mailman3/remote/host: localhost
  mailman3/remote/newhost:
  mailman3/dbconfig-remove: true
  mailman3/mysql/admin-user:
  mailman3/pgsql/authmethod-admin: ident
  mailman3/pgsql/changeconf: false
  mailman3/pgsql/authmethod-user: password
  mailman3/pgsql/admin-user: postgres
  mailman3/install-error: abort
  mailman3/pgsql/method: TCP/IP
  mailman3/remove-error: abort
  mailman3/passwords-do-not-match:
  mailman3/db/dbname: mailman3
  mailman3/upgrade-error: abort
  mailman3/remote/port:
  mailman3/upgrade-backup: true
  mailman3/pgsql/no-empty-passwords:
  mailman3/missing-db-package-error: abort
  mailman3/init_service_failed:
  mailman3/internal/reconfiguring: false

Bug#893024: Manual entry into UI date widget is broken

[martin f krafft]

also sprach Jeff  [2018-03-27 15:21 +1100]:
> > 2.0.2 suffers from a different, but probably related problem:
> > entering 2018-03-15 makes the date then appear as 0015-00-00.
> 
> Grrr. Yes. Sorry for being stupid. Fixed in 2.0.3.

I am sorry, but I didn't notice anyone being stupid. Did you? ;)

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"licht wird alles, was ich fasse"
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#894255: ITP: libcookie-baker-xs-perl -- Cookie::Baker::XS - boost Cookie::Baker's crush_cookie

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libcookie-baker-xs-perl
  Version : 0.09
  Upstream Author : Masahiro Nagano 
* URL : https://metacpan.org/release/Cookie-Baker-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Cookie::Baker::XS - boost Cookie::Baker's crush_cookie

Cookie::Baker::XS provides cookie string parser that implemented by XS.
Unlike Cookie::Baker, this module only provides parser and does not have a
generator function.

Bug#894252: lilypond-doc: Images in html doc use bad SansSerif font

[Don Armstrong]

Control: fixed -1 2.19-81-1~exp1

On Tue, 27 Mar 2018, Peter wrote:
> The generated (png) images in the Lilypond html doc are broken where
> Sans Serif fonts are used; See for example the chord names in the fret
> diagrams in section 2.4.1 of the notation reference or the chord name
> chart in appendix A.1.
> 
> Thanks for your consideration,

Thanks for the report; I see it in
file:///usr/share/doc/lilypond/html/Documentation/notation/chord-name-chart.html
in 2.18.2-1; it looks like it's working properly in 2.19-81-1~exp1.

This is almost certainly some missing fonts (texgyre or one of the ttf
fonts).


-- 
Don Armstrong  https://www.donarmstrong.com

Personally, I think my choice in the mostest-superlative-computer wars
has to be the HP-48 series of calculators.  They'll run almost
anything.  And if they can't, while I'll just plug a Linux box into
the serial port and load up the HP-48 VT-100 emulator.
 -- Jeff Dege, jd...@winternet.com

Bug#883529: Buildbot maintenance by PAPT

[Robin Jarry]

2018-03-26, Piotr Ożarowski:
> great, just let me know if you accept our policy and I'll hit the button

Yes, I accept the Debian Python Policy:
https://www.debian.org/doc/packaging-manuals/python-policy/

> (BTW, dh-python should be ready for builbot now, let me know if you need
> more changes)

Awesome, I'll check it ASAP.

Thanks!

-- 
Robin

Bug#884929: RM: drupal7 -- ROM; Old version; newer version not packagable for Debian

[Jeremy Bicha]

Control: tags -1 moreinfo

No remaining blockers in unstable so I'm unsetting the moreinfo tag.

Thanks,
Jeremy Bicha

Bug#820231: ttf-marvosym: Consider to remove your package

[Jeremy Bicha]

Control: severity -1 serious

I'm bumping the severity so that this package can be auto-removed from
Testing, while removal from Unstable is still blocked.

Thanks,
Jeremy Bicha

Bug#894254: osmo tray closes after start

[osmo]

Package: osmo
Version: 0.4.2-1+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
starting osmo
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
starting osmo
   * What was the outcome of this action?
tray starts and closes
   * What outcome did you expect instead?
tray starts and keep running so a close to tray is possible

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



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

Kernel: Linux 4.15.13-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages osmo depends on:
ii  libarchive13  3.2.2-3.1
ii  libc6 2.27-2
ii  libcairo2 1.15.10-2
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgringotts2 1:1.2.1-16
ii  libgspell-1-1 1.6.1-1
ii  libgtk-3-03.22.29-2
ii  libical3  3.0.1-5
ii  libnotify40.7.7-3
ii  libpango-1.0-01.42.0-1
ii  libpangocairo-1.0-0   1.42.0-1
ii  libwebkit2gtk-4.0-37  2.20.0-2
ii  libxml2   2.9.4+dfsg1-6.1
ii  xdg-utils 1.1.2-2

osmo recommends no packages.

osmo suggests no packages.

-- no debconf information

Bug#894184: Gitea was Orphaned

[Michael Lustfield]

As is standard golang practice, dependency ABIs were changed within a single
git revision without any version bump (if any version existed at all). This
situation will produce build failures from any attempt to update the package. In
fact, I believe a number of dependencies have already been auto-removed from
Debian because of build failures.


You're argument that gogs would be better is 1) based on absolutely nothing but
your own personal opinion, 2) completely and utterly irrelevant, and 3)
continues proving how little you care about the DFSG. If I had continued
pursuing gogs and stopped at the same point, gogs would be in exactly the same
situation, facing the same problems. I did not continue packaging gogs because
the owner would not accept patches/requests to fix these problems.

Of course, this wouldn't be an issue for the gogs packages you (Piccoro) have
created because you are in no way concerned about DFSG, CVEs, or
reproducibility. (I say this after having looked at the packages you created.)


As things currently sit, the gitea package and subsequent dependencies have
been orphaned. My opinion is that gitea does not belong in the debian archives.
Gogs has proven to be a substantially lesser candidate.

In order for this bug to be resolved, someone will have to adopt the package.

-- 
Michael Lustfield

Bug#881001: libevocosm: Build-Depends on libcoyotl-dev which is scheduled for removal

[Jeremy Bicha]

> the maintainer of libcoyotl has requested its removal: #881001,
> libevocosm is the only remaining user.

Both packages have the same maintainer!

Al, do you want libevocom removed from Debian too?

Thanks,
Jeremy Bicha

Bug#893332: ghostscript: Ghostscript cannot find Resource directory

[Jean-Philippe MENGUAL]

Hi,

Well, after many stupid trials and thanks to a lot of help by you and
upstream, the most useful thing I can add is:
1. I isolated the command which seems to be a problem:
gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
    -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
    -sOutputFile=out.ras \
    -sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
    -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
    -dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
    -I/usr/share/cups/fonts \
    input.pdf

Result:

D [18/Mar/2018:03:56:11 +0100] [Job 71] ./base/gsicc_manage.c:1148: 
gsicc_open_search(): Could not find default_gray.icc 
D [18/Mar/2018:03:56:11 +0100] [Job 71] | ./base/gsicc_manage.c:1799: 
gsicc_set_device_profile(): cannot find device profile
D [18/Mar/2018:03:56:11 +0100] [Job 71] Unrecoverable error: rangecheck in 
.putdeviceprops




2. As requested, I created a simplified gs document, to test results
without so much filters:

gs -sDEVICE=tiff24nc -sOutputFile=out.tif input.pdf Here I get:
default_grau.icc not found, gs says that it cannot find default_rgb.icc.
and the initial error. Now upstream seems to say it is a Debian problem
and I am out ou idea. Many thanks for further help Regards

signature_jp_2
Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe



Le 27/03/2018 à 12:32, Brian Potkin a écrit :
> On Sat 24 Mar 2018 at 19:37:37 +, Brian Potkin wrote:
>
>> tags 893332 moreinfo
>> thanks
>>
>>
>> On Sun 18 Mar 2018 at 04:55:38 +0100, Jean-Philippe MENGUAL wrote:
>>
>>> I try to print a test page from CUPS in a Samsung printer.
>>>
>>>* What exactly did you do (or not do) that was effective (or
>>>  ineffective)?
>>>
>>> See the log attached (see from line 3455), explaining what happens. I am 
>>> concerned by job 71 stuff.
>>>
>>>* What was the outcome of this action?
>>>
>>> The printing fails.
>> Thank you for the report and the logs, Jean-Philippe.
>>
>> Your upstream report has received advice to follow. How did you go on with 
>> this?
>>
>> You have also posted to debian-user
>>
>>   https://lists.debian.org/debian-user/2018/03/msg00662.html
>>
>> and advice was offered there. Is there any feedback to give?
> Jean-Philippe has continued his conversation with upstream at
>
> https://bugs.ghostscript.com/show_bug.cgi?id=695873
>
> (starting at comment 11) and added to the thread on debian-user. He has
> been advised to update us on his progress in #893332.
>
> Regards,
>
> Brian.
>

Bug#894252: lilypond-doc: Images in html doc use bad SansSerif font

[Peter]

Package: lilypond-doc
Version: 2.18.2-12
Severity: normal

Dear Maintainer,

The generated (png) images in the Lilypond html doc are broken where
Sans Serif fonts are used; See for example the chord names in the fret
diagrams in section 2.4.1 of the notation reference or the chord name
chart in appendix A.1.

Thanks for your consideration,

Peter.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 lilypond-doc depends on:
ii  dpkg  1.19.0.5
ii  install-info  6.5.0.dfsg.1-2

Versions of packages lilypond-doc recommends:
ii  lilypond-doc-html  2.18.2-12
pn  lilypond-doc-pdf   

Versions of packages lilypond-doc suggests:
ii  lilypond  2.18.2-12

-- no debconf information

Bug#894253: gdc's description contradicts default-d-compiler's description

[Peter De Wachter]

Package: gdc
Version: 4:8-20180321-1
Severity: normal

Hello,

The gdc package says:

> Depends: gdc-8 (>= 8-20180321-1~), libgphobos-dev (= 8-20180321-1)
> Description-en: D compiler (language version 2), based on the GCC backend
>  This is a dependency package providing the default D compiler.
>  Per policy, all packages that contain D sources must use this package
>  in their Build-Depends line.

The default-d-compiler package says:

> Depends: ldc (>= 1:1.8)
> Description-en: Default D compiler (metapackage)
>  This is a metapackage installing the default D compiler in Debian
>  for the respective architecture.
>  .
>  Packages building D code should depend on this.

Only one of these can be true :)

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

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

Versions of packages gdc depends on:
ii  gdc-8   8-20180321-1
ii  libgphobos-dev  8-20180321-1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#894251: mate-terminal spams systemd journal with dbus max_match_rules_per_connection

[Matt Zagrabelny]

Package: mate-terminal
Version: 1.20.0-1
Severity: normal

Greetings,

Thank you for contributing to Debian.

When watching the systemd journal via "journalctl -f", there is a line printed
to the journal for every key press in a mate-terminal. For instance:

Mar 27 14:09:52 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:53 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:53 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:54 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:54 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:54 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:54 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)
Mar 27 14:09:54 achilles dbus-daemon[1114]: [session uid=1000 pid=1114] 
Connection ":1.3831" is not allowed to add more match rules (increase limits in 
configuration file if required; max_match_rules_per_connection=5)

It doesn't matter which terminal has focus - pressing a key in any of the
mate-terminals yields a "Connect ... is not allowed to add more match rules".

I don't have issues on another system running the same version of
mate-terminal (1.20.0-1), so I don't know how reproducable this problem is.
Others seem to be having it, too:

https://github.com/mate-desktop/mate-terminal/issues/233
https://bugzilla.redhat.com/show_bug.cgi?id=1427721#c14

Using an xterm does not produce the log entries in the journal - it seems to
be isolated to mate-terminal.

Let me know what I can do to help solve this issue.

Thanks!

-m

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 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 mate-terminal depends on:
ii  gsettings-desktop-schemas  3.28.0-1
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-2
ii  libcairo-gobject2  1.15.10-2
ii  libcairo2  1.15.10-2
ii  libdconf1  0.26.1-3
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.0-4
ii  libgnutls303.5.18-1
ii  libgtk-3-0 3.22.29-2
ii  libice62:1.0.9-2
ii  libpango-1.0-0 1.42.0-1
ii  libpangocairo-1.0-01.42.0-1
ii  libpcre2-8-0   10.31-3
ii  libsm6 2:1.2.2-1+b3
ii  libvte-2.91-0  0.52.0-1
ii  libx11-6   2:1.6.5-1
ii  mate-desktop-common1.20.0-1
ii  mate-terminal-common   1.20.0-1
ii  zlib1g 1:1.2.8.dfsg-5

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#892113: needrestart: Bug in GTK3-frontend

[Thomas Liske]

Hi Andreas,


Andreas Schmidt  writes:

> Package: needrestart
> Version: 3.0-1
> Severity: normal
>
> Dear Maintainer,
>
> the new GTK-3 frontend to needrestart has two buttons:  and
> .

needrestart does not have a graphical frontend at all ;-). I think you
are using the debconf frontend which might use some Gtk3 frontend (which
is out of needrestart's scope).

> Pressing  results in a restart of the services checked in the main 
> window
> -- as expected. I assumed that with the other button I could quit the dialogue
> without restarting anything. However, hitting  gives me this message in
> the terminal:
>
> ***
> (frontend:20760): Gtk-CRITICAL **: gtk_assistant_previous_page: assertion
> 'page_node != NULL' failed
> ***
>
> The program continues to work, so this error is just a nuisance. However, With
> this error, the button is useless and should be removed or replaced. What do
> you think about the following suggestion?

There should be a OK and a Cancel button. Testing on stretch (using
needrestart -f ) it seems to work showing the following
buttons:

dialog: OK, Cancel
gnome: OK, Cancel
kde: OK, Cancel, Back (where 'Back' works like Cancel)


> After updating packages like libc6, needrestart finds lots of services that
> need a restart. There are occasions where restarting them should be delayed --
> just think of a download running in the background that would be interrupted
> for good if network-related services were stopped. In such cases it could be
> quite a tiresome task to manually deselect all listed services and press
> . It would be much easier to have a  button that quits the
> program without restarting anything. Another idea would be to provide a
> checkbox on top (and possibly an identical one at the bottom) of the list that
> turns the checkboxes of all listed services on/off. This would provide an easy
> way to activate a restart of all services, if needed. It might be dangerous,
> though, because it could lead to inadvertently killing the whole X-session if,
> say, dbus was restarted.

Needrestart tries to provide sane default so it should not kill your
X-session nor network connection unless you've changed it's
configuration or select the services explicitly.

The should be a Cancel button which should result in *no* service
restart. If the button is missing while running needrestart on sid than
this is a regression which might be triggered by changes in debconf.

When using debconf (which is the prefered UI) it is not possible to add
custom buttons or checkboxes - debconf does all the magic building the
dialog.


HTH,
Thomas


> Thank you for your consideration!
>
> Andreas
>
>
>
> -- Package-specific info:
> needrestart output:
> Your outdated processes:
> alarm-clock-app[8901], atril[8865, 8892, 8893, 8945, 8936, 8934, 8947, 4626, 
> 8894, 8895, 8943, 8897, 8946, 8932, 24870, 26930, 8864, 8898, 8896, 8933, 
> 8926, 8944], atrild[9180], audacity[7089], balsa[13182], bash[9074, 9081, 
> 9072, 9299, 9076, 9098, 9075, 9091, 9073, 9086, 9094, 9087, 9101, 6716, 9085, 
> 19128, 9078, 9089, 5984, 9071, 9080, 9088, 9166, 9100, 9099, 9077, 9093, 
> 9090, 9083, 9082, 9079, 7243, 9084, 9097], dbus-daemon[8726], 
> dbus-launch[8725], dconf-service[8759], dirmngr[21365], firefox-esr[8866], 
> gconfd-2[8918], gconf-helper[2134], geany[9145], gvfs-afc-volume[8832], 
> gvfsd[8745], gvfsd-computer[26884], gvfsd-dnssd[25296], gvfsd-fuse[8750], 
> gvfsd-metadata[10665], gvfsd-network[25244], gvfsd-trash[10748], 
> gvfs-goa-volume[8826], gvfs-gphoto2-vo[8841], gvfs-mtp-volume[8852], 
> gvfs-udisks2-vo[8810], hamster-service[19488], light-locker[8835], 
> marco[8786], mate-power-mana[8902], mate-screensave[11803], 
> mate-session[8698], mate-settings-d[8776], mate-terminal[8937], 
> mate-user-share[8899], mate-volume-con[8948], mc[7241, 19126, 9272, 6714], 
> mocp[8409, 27558], msd-locate-poin[8806], needrestart-dbu[2101, 8916], 
> oosplash[5959], pluma[8927], polkit-mate-aut[8924], pulseaudio[2026], 
> sh[8884], soffice.bin[5978], systemd[1907], vlc[8343, 10195], 
> WebKitNetworkPr[10439, 10441, 4641, 10448, 10435, 10428, 10444, 10447, 10431, 
> 10433, 10440, 10438, 10437, 26946, 10445, 10423, 10443, 10442, 24736, 10449, 
> 24886, 10430, 10446], zeitgeist-daemo[8906], zeitgeist-datah[8921], 
> zeitgeist-fts[8983]
>
> checkrestart output:
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-1-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 needrestart depends on:
> ii  binutils   2.30-5
> ii  dpkg   1.19.0.5
> ii  gettext-base   0.19.8.1-4
> ii  libintl-perl  

Bug#894250: dkms: reinstalling custom kernel package may cause dkms to lose list of modules

[Ian Abbott]

Package: dkms
Version: 2.3-3
Severity: normal

Dear Maintainer,

For a custom-built linux-image package, the package's "prerm" script (that was
output by "scripts/package/builddeb" in the Linux kernel sources) runs the
/etc/kernel/prerm.d/* scripts regardless of the package operation type, which
may result in dkms losing its list of added modules prematurely.  This is
unlike the "prerm" script in Debian's own linux-image packages, which checks
that the package operation type is "remove" before running the
/etc/kernel/prerm.d/* scripts.

In particular, the /etc/kernel/prerm.d/dkms script will remove dkms modules
completely if they are not needed by any other kernels, causing dkms to forget
its list of modules to be built when a kernel is installed.  This is a problem
when reinstalling a custom linux-image package (or upgrading to a custom linux-
image package whose version differs only in the Debian package revision number)
when that is the only Linux kernel installed, because the system is left in a
state with none of the previous dkms modules installed.

I filed a bug upstream at https://github.com/dell/dkms/issues/37 but I was
unsure at the time whether it should be classed as an upstream bug.  I
presently do not consider it to be an upstream bug, or rather it is an issue
that has already been fixed upstream in dkms 2.4 (see yuzaipiaofei's comment
https://github.com/dell/dkms/issues/37#issuecomment-348067214 on 30 Nov 2017).
That fix involved a change to the dkms "uninstall" functionality and a change
to the upstream "kernel_prerm.d_dkms" script upon which Debian's
"/etc/kernel/prerm.d/dmks" script is based.

This may be related to bug #621846, but that one is about 7 years old.

[Note: System Information is from an embedded ARM Debian GNU/Linux
system that has the custom linux-image package installed.]



-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.3-ipec+ (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dkms depends on:
ii  build-essential  12.3
ii  coreutils8.26-3
ii  dpkg-dev 1.18.24
ii  gcc  4:6.3.0-4
ii  kmod 23-2
ii  make 4.1-9.1
ii  patch2.7.5-1+b2

Versions of packages dkms recommends:
ii  fakeroot   1.21-3.1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-g  
ii  lsb-release9.20161125
ii  sudo   1.8.19p1-2.1

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

-- no debconf information

Bug#894211: xserver-xorg-video-nouveau: Screen frozen every few seconds for less than a second

[Sven Joachim]

On 2018-03-27 14:37 +0300, Stanimir Stoyanov wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.15-2
> Severity: important
>
> Dear Maintainer,
>
> After a recent update the system become unusable. Every few seconds it's 
> frozen
> for less than a second. From the dmesg I can see the timings match a loop of
> entries like
>
> [  461.313187] nouveau :01:00.0: pci: failed to adjust lnkctl speed
> [  461.381089] snd_hda_intel :01:00.1: Enabling via vga_switcheroo
> [  472.791114] snd_hda_intel :01:00.1: Disabling via vga_switcheroo
> [  473.091231] snd_hda_intel :01:00.1: Cannot lock devices!
> [  473.091470] ACPI: \_SB_.PCI0.P0P2.PEGP: failed to evaluate _DSM

What makes you think this is a bug in xserver-xorg-video-nouveau?  This
package has not seen "a recent update" (in fact, it has not been changed
for 9 months), and your Xorg.1.log shows that X does not even try to
load the nouveau driver.

Cheers,
   Sven

Bug#845297: Bug #845297: Website transition from CVS to Git

[Alex Muntada]

Hi Laura,

> 3.- Which are the next steps? (I guess attack the Perl scripts,

I'd love to help with those scripts but I'm afraid I lack the
experience of the translation team to understand what is that
needs to be done. I found the issues listed on the wiki page
WebsiteGitTransition, but I can't figure out the changes that
need to be made in the Perl scripts from those.

Thus, if someone could elaborate on the details I may provide
some code. In particular, I think it'd be best to split the
scripts from the translations in webwml repo, so they could
evolve separatedly and the scripts could be migrated to salsa
sooner.

> or find a way of facilitating translators the work to keep
> translations in sync with the "english" folder). About this,
> I have some new ideas (not sure if they are good or silly. Just
> throwing them here for the case it rings a bell for anybody):
> 
> * Maybe Gitlab CI can help to "generate a translator dashboard"
> in a simpler way than the scripts that currently create the
> pages of the type:
> https://www.debian.org/devel/website/stats/es

Gitlab Pages can be built in the CI and then published as
https://{team-name}.pages.debian.net/{whatever}.html

We build the former pkg-perl website using this feature:
https://perl-team.pages.debian.net/

You can see the build script is pretty straight forward:
https://salsa.debian.org/perl-team/perl-team.pages.debian.net/blob/master/.gitlab-ci.yml

> * I'll try to explore the integration with a Weblate instance.

I like the idea of using PO files for translating very much,
since I was member of the translations team for GNU website long
time ago. I would've loved to have something like Weblate...
Some time after I left, Yavor Doganov created GNUnited Nations,
also based on PO files, though it isn't packaged for Debian
either.

Therefore, I think moving to PO files would be worth the effort
the sooner the better. Even if that means breaking the current
workflow for a while, it sure will help getting more people into
translating Debian texts.

Hope this helps,
Alex



signature.asc
Description: PGP signature

Bug#894249: natpmp-utils: Install of natpmpc (20150609-2) fails if natpmp-utils 20110808-4+b1 is installed

[Antti Järvinen]

Package: natpmp-utils
Version: 20150609-2
Severity: normal

Dear Maintainer,

during recent update it happened that

Unpacking natpmpc (20150609-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-yQIxdv/12-natpmpc_20150609-2_i386.deb (--unpack):
 trying to overwrite '/usr/bin/natpmpc', which is also in package natpmp-utils 
20110808-4+b1

reportbug does not want to report this bug against natpmpc because I don't
have it installed but obviously it is a packaging glitch between old 
natpmp-utils and more recent natpmpc.

--
Antti Järvinen

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

Kernel: Linux 4.11.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages natpmp-utils depends on:
pn  natpmpc  

natpmp-utils recommends no packages.

natpmp-utils suggests no packages.

-- no debconf information

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Jeremy Stanley]

On 2018-03-24 00:03:12 + (+), Simon McVittie wrote:
[...]
> On Fri, 23 Mar 2018 at 20:30:17 +, Jeremy Stanley wrote:
> > This may also serve to help narrow down (via reverse dependency) the
> > list of packages which will trigger violent reactions when mixed in
> > the same context with pip 10 invocations, per
> > https://github.com/pypa/pip/issues/4805 .
> 
> Am I right in saying that there is a distutils limitation that means
> the Python equivalent of "make uninstall" isn't reliable for packages
> installed with distutils, and as a result, upstream developers want to
> deprecate distutils?

More that pip can't reliably uninstall packages previously installed
via distutils due to insufficient provided metadata. While I
personally think that it's a bad idea pip would even attempt to
uninstall (through removal of the underlying files) packages it
wasn't previously managing when it's been asked (perhaps through a
transitive dependency relationship) to upgrade them, it's
unfortunately been the case for a while now that it does that. As
far as I understand this is owing to RH-based distros using the
same tree for RPM-installed and pip-installed packages rather than
splitting the latter out to /usr/local like Debian derivatives, so
it's significantly more likely that random files get left behind if
pip can't uninstall them properly on an upgrade.

Based on previous threads on the distutils-sig ML it doesn't sound
like it's destined for general deprecation any time soon as it's
part of the build toolchain for cpython itself. However the Python
packaging ecosystem has been strongly discouraging its use outside
of packaging the interpreter for some time and the same people are
interested in seeing `setup.py install` type workflows disappear
altogether, even in distro-packaged modules.

> While deprecating libraries that have unfixable problems is a reasonable
> goal, I'm reasonably sure that installing a library with apt/dpkg and
> uninstalling it with "sudo pip uninstall" is not something we (should)
> aim to support? Or am I misunderstanding?

It's more that (and again, I'm not advocating for this pattern in
general, though sometimes it can make sense in "dirty" environments
like a throwaway chroot or ephemeral test system) when your distro
has installed Python module "A" (perhaps because it's a dependency
of an essential tool on that distro) and then you attempt to `sudo
pip install ...` some module "B" into the same context but it has a
direct or transitive dependency on "A" perhaps wanting a slightly
newer version, pip will want to uninstall the existing "A" as part
of upgrading it. The hope expressed by pip maintainers is that by
changing the current warning about its inability to uninstall "A"
(if the distro package was distutils-based) to a hard failure, they
can get users relying on that to apply pressure on their respective
distributions to change to newer packaging standards.

> (Packages that were merely built with distutils won't normally depend
> on distutils in any case, only build-depend.)

Yes, apologies, that's what I meant. It's still _something_ we can
query on to know whether a given binary package will present a
problem in the face of a `sudo pip install ...` scenario which might
try to upgrade it.

> I thought the upstream Python maintainers strongly objected to the idea
> of us installing something that claims to be Python but doesn't have
> the complete Python standard library (in the interests of having Python
> mean something predictable between OSs), but perhaps that information is
> out of date and doesn't apply to distutils any more?

My take is that "upstream Python" (who are not necessarily upstream
of the popular Python package ecosystem tools, keep in mind) would
probably rather Debian didn't exclude distutils from the stdlib for
compatibility reasons, but the preference of the maintainers of
Python packaging ecosystem tools is that distros cease using
distutils to package up independent Python modules.
-- 
Jeremy Stanley

Bug#849752: lintian: dpkg-source failed with status 2 / no such file or directory

[Hugo Lefeuvre]

Hi Niels,

I'm also hitting this lintian bug.

> Aha, I think I got it.  There is no ".orig" tarball in the result dir.

It looks like you're right:

$ lintian build-area/build-area/hashid_3.1.4-2_amd64.changes
  
 cp: cannot stat 
'/tmp/temp-lintian-lab-NVFEj9_sPr/pool/h/hashid/hashid_3.1.4-2_source/hashid_3.1.4.orig.tar.gz':
 No such file or directory
 dpkg-source: error: cp 
/tmp/temp-lintian-lab-NVFEj9_sPr/pool/h/hashid/hashid_3.1.4-2_source/hashid_3.1.4.orig.tar.gz
 to 
/tmp/temp-lintian-lab-NVFEj9_sPr/pool/h/hashid/hashid_3.1.4-2_source/hashid_3.1.4.orig.tar.gz
 subprocess returned exit status 1 
 internal error: dpkg-source -x failed with status  25 at 
/usr/share/lintian/collection/unpacked line 72. 
 warning: collect info unpacked about package hashid failed
 warning: skipping check of source package hashid
$ cp build-area/hashid_3.1.4.orig.tar.gz build-area/build-area/
$ lintian build-area/build-area/hashid_3.1.4-2_amd64.changes
 [works]

... another time

$ lintian build-area/build-area/bleachbit_2.0-2_amd64.changes
 [doesn't work, same error]
$ cp build-area/bleachbit_2.0.orig.tar.gz build-area/build-area/
$ lintian build-area/build-area/bleachbit_2.0-2_amd64.changes
 [works]

... the other way

$ lintian build-area/build-area/dwm_6.1-4_amd64.changes
 [works]
$ rm build-area/build-area/dwm_6.1.orig.tar.gz <-- Yep, the orig was present in 
the folder
$ lintian build-area/build-area/dwm_6.1-4_amd64.changes
 [doesn't work, same error]

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#887557: www.debian.org: tech-ctte membership updates

[Simon McVittie]

On Wed, 28 Mar 2018 at 01:47:03 +0900, Osamu Aoki wrote:
> >  
> > - > domain="organization">chairman 
> > + > domain="organization">chair 
> 
> Can't we use neutral term "chairperson" as a tag even though we will
> never see it.

If you're going to rename the tag (and risk breaking something else
that might be relying on it), then I think it would make more sense to
match the content (and the term in the constitution) and use
. Renaming it, but to a different gender-neutral term,
seems like the worst of both worlds to me.

smcv

Bug#880771: libdwarf/dwarfdump cross compile

[Fabian Wolff]

Control: tags -1 + fixed-upstream

On Tue, Mar 27, 2018 at 10:02:25AM -0700, David Anderson wrote:
> code/dwarfdump/configure  and code/libdwarf/configure
> now support cross building.  see code/README.

That's good to hear.

Thank you very much for the effort you put into this!

Bug#890446: bcache-tools: /dev/bcache/{by-uuid,by-label} symlinks not present after reboot

[Robie Basak]

For the record, I've been reluctant to commit this without it having
been accepted and resolved upstream.


signature.asc
Description: PGP signature

Bug#894245: src:salt: cannot install master nor minion due to tornado & zmq breakage

[Vincas Dargis]

Package: src:salt
Version: 2017.7.4+dfsg1-1
Severity: important

Dear Maintainer,

It seems that due to #893360 salt-master and salt-minion cannot be
installed.

salt-master depends on python3-zmq, meanwhile salt-common depends on 
python3-tornado.

Since tornado breaks zmq (as in bug mentioned before), it's not possible to
install nor master neither minion:

```
$ sudo aptitude install salt-master
The following NEW packages will be installed:
  python3-croniter{a} python3-crypto{a} python3-dateutil{a} python3-jinja2{a}
  python3-markupsafe{a} python3-msgpack{a} python3-psutil{a} 
python3-pygit2{a} python3-systemd{a} python3-tornado{ab} python3-tz{a}
python3-yaml{a} python3-zmq{a} salt-common{a} salt-master 
0 packages upgraded, 15 newly installed, 0 to remove and 0 not upgraded.
Need to get 4.559 kB of archives. After unpacking 29,8 MB will be used.
The following packages have unmet dependencies:
 python3-tornado : Breaks: python3-zmq (< 17) but 16.0.2-2+b1 is to be
 installed
 The following actions will resolve these dependencies:

  Keep the following packages at their current version:
  1) python3-zmq [Not Installed]
  2) salt-master [Not Installed] 
```

```
$ sudo aptitude install salt-minion
The following NEW packages will be installed:
  dctrl-tools{a} python3-croniter{a} python3-crypto{a} python3-dateutil{a}
  python3-jinja2{a} python3-markupsafe{a} python3-msgpack{a} python3-psutil{a} 
python3-systemd{a} python3-tornado{ab} python3-tz{a} python3-yaml{a}
python3-zmq{a} salt-common{a} salt-minion 
0 packages upgraded, 15 newly installed, 0 to remove and 0 not upgraded.
Need to get 4.540 kB of archives. After unpacking 29,7 MB will be used.
The following packages have unmet dependencies:
 python3-tornado : Breaks: python3-zmq (< 17) but 16.0.2-2+b1 is to be
 installed
 The following actions will resolve these dependencies:

  Keep the following packages at their current version:
  1) python3-zmq [Not Installed]
  2) salt-minion [Not Installed] 
```

Is it neccessary for salt-common to depend on tornado if both master and minion
uses zmq?



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

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

Bug#894246: ITP: python-face-recognition-models: Trained models for the python-face-recognition library

[Hugo Lefeuvre]

Package: wnpp
Severity: wishlist

* Package name: python-face-recognition-models
  Version : No versioning, use git commits + dates instead
  Upstream Author : Adam Geitgey 
* URL : https://github.com/ageitgey/face_recognition_models
* License : public domain
  Programming Lang: Python 3
  Description : Trained models for the face_recognition python library

Dependency of python-face-recognition.

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature