Bug#899224: pbuilder: cannot pass -g in --debbuildopts

[Sven Joachim]

Package: pbuilder
Version: 0.229.2

It does not seem to be possible to perform a build with passing -g (aka
--build=source,all) to dpkg-buildpackage via -debbuild-opts.  When I did
that, the build failed at the end, because pbuilder expected the wrong
.changes file:

,
|$ pdebuild -- --debbuildopts -g
| [...]
| dpkg-deb: building package 'ncurses-base' in 
'../ncurses-base_6.1+20180210-4_all.deb'.
| dpkg-deb: building package 'ncurses-doc' in 
'../ncurses-doc_6.1+20180210-4_all.deb'.
| dpkg-deb: building package 'ncurses-term' in 
'../ncurses-term_6.1+20180210-4_all.deb'.
|  dpkg-genbuildinfo --build=source,all
|  dpkg-genchanges --build=source,all >../ncurses_6.1+20180210-4_all.changes
| dpkg-genchanges: info: not including original source code in upload
|  dpkg-source -i --after-build ncurses-6.1+20180210
| dpkg-buildpackage: info: binary and diff upload (original source NOT included)
| I: copying local configuration
| E: Missing changes file: 
/var/cache/pbuilder/build/2003/build/ncurses_6.1+20180210-4_i386.changes
`

And specifying --binary-indep does not work either, because
dpkg-buildpackage then barfs:

,
| $ pdebuild -- --binary-indep --debbuildopts -g
| I: Copying back the cached apt archive contents
| I: Building the package
| I: Running cd /build/ncurses-6.1+20180210/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc -i -uc -us -A -g
| dpkg-buildpackage: error: cannot combine -A and -g
| 
| Use --help for program usage information.
| I: copying local configuration
| E: Failed autobuilding of package
`


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

Kernel: Linux 4.17.0-rc6-nouveau (SMP w/2 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 pbuilder depends on:
ii  cdebootstrap   0.7.7+b1
ii  debconf [debconf-2.0]  1.5.66
ii  debootstrap1.0.99
ii  dpkg-dev   1.19.1

Versions of packages pbuilder recommends:
ii  devscripts  2.18.2
ii  eatmydata   105-6
ii  fakeroot1.22-2
ii  iproute24.16.0-4
ii  net-tools   1.60+git20161116.90da8a0-2
ii  sudo1.8.23-1

Versions of packages pbuilder suggests:
pn  cowdancer   
pn  gdebi-core  

-- debconf information:
* pbuilder/rewrite: false
* pbuilder/mirrorsite: http://ftp.de.debian.org/debian/
  pbuilder/nomirror:

Bug#899223: sparkleshare: fails to start without any error message

[Tollef Fog Heen]

Package: sparkleshare
Version: 2.0.1-1
Severity: grave

After the recent update, sparkleshare fails to start without any kind of
useful error message on multiple machines.

First, it hits a mono bug that's triggered by the new libncurses, which
can either be worked around with «TERM=xterm sparkleshare start» or
patched by
https://github.com/mono/mono/commit/2c1f45f3791f274855e0f5fd2fb0af71c9a756f7
(thanks to Jo Shields for that link).

It then runs like:
$ TERM=dumb sparkleshare start
06.47.09 Environment | SparkleShare 2.0.1
06.47.09 Environment | Git LFS 
06.47.09 Environment | Git 2.17.0
06.47.09 Environment | GNOME (Unix 4.16.0.1)
06.47.09 Cmd |  | gvfs-set-attribute "/home/tfheen/SparkleShare" 
metadata::custom-icon-name org.sparkleshare.SparkleShare

and then just exits.  strace does not really shed any light on what's
going on.

I'm happy to help out with debugging this issue if you can't reproduce
it.

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

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

Versions of packages sparkleshare depends on:
ii  git 1:2.17.0-1
ii  gnome-icon-theme3.12.0-3
ii  gvfs1.36.1-1
ii  libappindicator3-0.1-cil12.10.0+git20151221-5
ii  libgdk3.0-cil   2.99.3-2+b1
ii  libgio3.0-cil   2.99.3-2+b1
ii  libglib3.0-cil  2.99.3-2+b1
ii  libgtk3.0-cil   2.99.3-2+b1
ii  libjs-jquery3.2.1-1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  libnotify3.0-cil3.0.3-3
ii  libpango3.0-cil 2.99.3-2+b1
ii  libwebkit2-sharp-4.0-cil2.10.9+git20160917-1.1
ii  mono-runtime4.6.2.7+dfsg-1

Versions of packages sparkleshare recommends:
ii  python   2.7.15~rc1-1
ii  python-nautilus  1.1-6

sparkleshare suggests no packages.

-- no debconf information

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

Bug#899222: mono-runtime: breaks with new ncurses terminfo files

[Tollef Fog Heen]

Package: mono-runtime
Version: 4.6.2.7+dfsg-1
Severity: important

ncurses 6 introduced a new file format, which causes mono to become
pretty unhappy when trying to parse those files.  A current example is
sparkleshare:

$ mono /usr/lib/x86_64-linux-gnu/sparkleshare/SparkleShare.exe
exception inside UnhandledException handler: The type initializer for 
'System.Console' threw an exception.

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type 
initializer for 'System.Console' threw an exception. ---> 
System.TypeInitializationException: The type initializer for 
'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic number 
is wrong: 542
  at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& 
position) [0x0002b] in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.TermInfoReader..ctor (System.String term, System.String filename) 
[0x00065] in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.TermInfoDriver..ctor (System.String term) [0x00058] in 
<8f2c484307284b51944a1a13a14c0266>:0 
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x0] 
in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.ConsoleDriver..cctor () [0x00062] in 
<8f2c484307284b51944a1a13a14c0266>:0 
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding, 
System.Text.Encoding outputEncoding) [0xa] in 
<8f2c484307284b51944a1a13a14c0266>:0 
  at System.Console..cctor () [0x000a8] in <8f2c484307284b51944a1a13a14c0266>:0 
   --- End of inner exception stack trace ---
  at Sparkles.Logger.LogInfo (System.String type, System.String message, 
System.Exception exception) [0x0009d] in <1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Logger.LogInfo (System.String type, System.String message) 
[0x1] in <1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Command.Start () [0x00097] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Command.StartAndReadStandardOutput () [0x1] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at (wrapper remoting-invoke-with-check) 
Sparkles.Command:StartAndReadStandardOutput ()
  at Sparkles.InstallationInfo.get_OperatingSystem () [0x00049] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Logger.WriteCrashReport (System.Exception e) [0x8] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at SparkleShare.SparkleShare.OnUnhandledException (System.Object sender, 
System.UnhandledExceptionEventArgs exception_args) [0xd] in 
<6d9908bd36a64477b98c6146bd1b2e76>:0 

https://github.com/mono/mono/commit/2c1f45f3791f274855e0f5fd2fb0af71c9a756f7
is an upstream commit that I've been told fixes this.

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

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

Versions of packages mono-runtime depends on:
ii  libc6  2.27-3
ii  mono-runtime-sgen  4.6.2.7+dfsg-1

mono-runtime recommends no packages.

mono-runtime suggests no packages.

-- no debconf information

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

Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

[Niels Thykier]

Control: tags -1 moreinfo

Sam Hartman:
>> "Niels" == Niels Thykier  writes:
> control: tags -1 -moreinfo
> 
> (I hope this supplies the info you need; obviously retag if you have
> more questions.)
> 

It did; but it gave me a new question. :) Just remove it again, when you
answer.  I have been using a BTS filter to keep the debhelper bug list
(more) manageable - See [1] vs [2] for comparison (which filters out
about 25% of the open bugs).

> 
> Niels> Hi Sam,
> 
> Niels> Thanks for the bug report.
> 
> Niels> It sounds like you rather want krb5-kdc not to start on
> Niels> initial installation.
> 
> That's not what I want at all.
> 
> I want to try and start it, but I don't want a failure to start to be
> considered an error that causes package installation to fail.
> [...]
> 
> 
> --Sam
> 


As I understood your original mail, it sounded like we expect the
service to fail because the user has not configured it yet.  I think I
am missing the point of having it start automatically if it will not
work out of the box.
  Can you elaborate on what makes you want it to start automatically?


Note that debhelper's tooling for init scripts vs. systemd has the
asymmetry that the systemd tooling ignores all failures basically.  As I
understood the systemd maintainers who wrote the original systemd
tooling, they were of the mind that failing installation because a
service fails to start was not desirable.
  But unlike sysvinit, systemd makes it easy for the administrator to
tell which services have issues - so I am a bit hesitant to make these
symmetric in general.

Thanks,
~Niels

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debhelper

[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?exclude=tags%3Awontfix;exclude=tags%3Apending;exclude=tags%3Amoreinfo;exclude=tags%3Ahelp;src=debhelper

Bug#896687: statx now works inside aarch64 nspawn container

[张 敬强]

I reboot the host machine and found that statx now works.
The bug may be in libseccomp, but I'm not sure.

Thanks

Bug#896445: cutesdr FTBFS with Qt 5.10

[Juhani Numminen]

Control: tags -1 fixed-upstream

On Sat, 21 Apr 2018 10:44:13 +0300 Adrian Bunk  wrote:
> Source: cutesdr
> Version: 1.13.42-2
> ...

> gui/plotter.cpp:681:59: error: no matching function for call to 
> 'QPainter::drawStaticText(int, int, const QString)'

> /usr/include/x86_64-linux-gnu/qt5/QtGui/qpainter.h:870:13: note:   no known 
> conversion for argument 3 from 'const QString' to 'const QStaticText&'

The release history at the project's download page says that the upstream 
version
1.20 should compile with Qt 5.10.
https://sourceforge.net/projects/cutesdr/files/

Regards,
Juhani

Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages

[Nicholas D Steeves]

P.P.S. I can start with one of debian-el, devscripts-el, or
dpkg-dev-el as a proof of concept, and it will also be easier to just
iterate over the *.els once these exceptions have been dealt with.  I
assume that they ought to remain grouped together and become
elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with
repositories on salsa named debian-el, devscripts-el, and dpkg-dev-el.


signature.asc
Description: PGP signature

Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages

[Nicholas D Steeves]

Package: emacs-goodies-el
Version: 36.3+nmu1
Severity: normal

Dear Peter,

Thank you for maintaining emacs-goodies-el; It has proven to be
invaluable for a variety of tasks.  Sean Whitton and I have recently
been discussing the challenge of breaking up emacs-goodies.el into
many elpafied packages.  I am filing this bug so there will be a site
to coordinates efforts to this end.  Is it something you're already
working on, or something you wouldn't object to having the Debian
Emacsen team help out with?  How important is git history to you?
While it is possible to script pruning and rewriting history for each
new repository (consisting of the .el, documentation, patches,
changelog, and copyright) this will be a lot of work!

I'd also like to break up the process into a series of steps, so that
other people can resume progress if the effort stalls, and possibly
also break it up into no more than four sections (count of *.els / 4),
so that the labour of any manual steps can be divided between multiple
people.  Finally, if there are any bugs in the script, doing it in
multiple steps will provide checkpoints and a way to gauge progress.

Please feel free to define this sequence, or ping me if I haven't
submitted one by the first of June.


Kind regards,
Nicholas

P.S. Do you know a way to automate the triaging of ~100 bugs against
goodies, and to reassign them to their respective (future) elpafied
packages?

Bug#655754: emacs-goodies-el: `diminished-minor-modes' setting doesn't "just work" (with fix)

[Nicholas D Steeves]

Hi Samuel,

On Fri, Jan 13, 2012 at 03:59:11PM -0500, Samuel Bronson wrote:
> Package: emacs-goodies-el
> Version: 35.2
> Severity: normal
> 
> So, I noticed that the `diminished-minor-modes' setting is really
> finicky at the moment; at first, I thought this was just because of a
> missing ":require 'diminish" in the defcustom, but I found (as you say
> in your comments) that things are a bit trickier than that.
> 
> Thankfully, I also found that things aren't nearly as tricky as you
> seemed to suppose, and came up with fix below, which does not require
> any foreknowledge of what minor modes are defined where.  I think it
> does add an O(n^2) cost to any command that ends up loading elisp
> somehow, but it looks like that's probably not really a problem unless
> you use a *lot* of diminished minor modes.
> 
> Maybe you should send this (combined with 50_diminish-defcustom.diff)
> upstream?

[...]

> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages emacs-goodies-el depends on:
> ii  bash  3.2-4  The GNU Bourne Again SHell
> ii  dpkg  1.16.1.2   Debian package management system
> ii  emacs23-lucid [emacsen]   23.3+1-4   The GNU Emacs editor
> ii  install-info  4.13a.dfsg.1-4 Manage installed documentation 
> in 
> 
> Versions of packages emacs-goodies-el recommends:
> ii  dict  1.10.11.dfsg-2 Dictionary Client
> ii  perl-doc  5.14.2-6   Perl documentation
> ii  wget  1.11.4-4   retrieves files from the web
> 
> emacs-goodies-el suggests no packages.

I just wanted to check in with you and ask if `diminished-minor-modes`
works for you in stretch and/or current sid.

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#813226: tzdata config script ignores /etc/timezone on non-interactive configuration

[Raymond Rakesh Chetty]

Why isn't debconf the single source of truth for tzdata configuration? If
you used debconf then people wouldn't rely on implementation details to
correctly configure their systems. Abstract configuration from
implementation (i.e. separate timezone from is the file a link?, where is
it located?, which file needs the right information?)

https://stackoverflow.com/a/2069366 would be the top vote and everybody
would have (or soon obtain) a good (some) understanding of debconf.

All people need to know is what question is going to get asked, or needs
answering (debconf-show + some documentation). Isn't that how debian is
supposed to work? https://wiki.debian.org/debconf

The original timezone configuration would get assigned with:

$ echo "tzdata tzdata/Areas select Asia" | sudo debconf-set-selections

$ echo "tzdata tzdata/Zones/Asia select Tokyo" | sudo debconf-set-selection

$ dpkg-reconfigure -fnoninteractive tzdata

-- 
Best,
Raymond Chetty

raymond.che...@berkeley.edu

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

Bug#594632: emacs-goodies: please include highlight-parentheses.el (gpl)

[Nicholas D Steeves]

Hi Jonas and Peter,

On Mon, Aug 30, 2010 at 10:08:01AM -0400, Peter S Galbraith wrote:
> Jonas Stein  wrote:
> 
> > Package: emacs-goodies-el
> > Version: 34.1
> > Severity: wishlist
> > File: emacs-goodies
> > 
> > gpl'ed code can be found here.
> > it works fine here with v.23
> > http://nschum.de/src/emacs/highlight-parentheses/
> 
> Nice!
> I wondered how we could use yet another parenthesis highlighter, but
> this is a novel idea!

This looks similar to elpa-rainbow-delimiters, which is available in
stretch and later.  Does that package provide the functionality wished
for in this bug, and can this bug be closed?

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing

[Clint Adams]

On Sun, May 20, 2018 at 04:38:36PM -0700, John MacFarlane wrote:
> I don't understand this error.  InvalidYaml *is* a constructor for the
> type ParseException in Data.Yaml (yaml package).  So it's not clear why
> the compiler would complain about it being used as a "constructor-like
> thing."

on armel:

GHCi, version 8.2.2: http://www.haskell.org/ghc/  :? for help
Prelude> :m Data.Yaml
Prelude Data.Yaml> :i ParseException
data ParseException
  = NonScalarKey
  | UnknownAlias {_anchorName :: Text.Libyaml.AnchorName}
  | UnexpectedEvent {_received :: Maybe Text.Libyaml.Event,
 _expected :: Maybe Text.Libyaml.Event}
  | InvalidYaml (Maybe YamlException)
  | AesonException String
  | OtherParseException GHC.Exception.SomeException
  | NonStringKeyAlias Text.Libyaml.AnchorName Value
  | CyclicIncludes
-- Defined in `yaml-0.8.29:Data.Yaml.Internal'
instance Show ParseException
  -- Defined in `yaml-0.8.29:Data.Yaml.Internal'

> What version of ghc is being used to compile?

8.2.2

> What version of the Haskell yaml package is being used?

0.8.29

Bug#898088: Bug#899080 closed by Ben Hutchings <b...@decadent.org.uk> (Bug#898088: fixed in libbsd 0.8.7-1.1)

[Ben Caradoc-Davies]

Thanks, Ben. Confirmed fixed in libbsd/0.8.7-1.1.

I installed libbsd0_0.8.7-1.1_amd64.deb on a buster VM and it no longer 
hangs after lightdm credentials are entered (the xfce4-session hang 
reported in #899080):

http://ftp.debian.org/debian/pool/main/libb/libbsd/libbsd0_0.8.7-1.1_amd64.deb

Kind regards,

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

Bug#899220: Generating PNG graphs raises NotImplementedError

[Luke W Faraone]

Package: wotsap
Version: 0.7-5
Severity: normal


```
$ wget https://pgp.cs.uu.nl/archive/wot-0.2/latest.wot -O .wotsapdb
$ wotsap -o foo.png 0C14A470 D4311E58
[… normal trust path output omitted…]


Traceback (most recent call last):
  File "/usr/bin/wotsap", line 1903, in 
wotsapmain(sys.argv)
  File "/usr/bin/wotsap", line 1852, in wotsapmain
wot.initfont(fontfile, ttffile, ttfsize)
  File "/usr/bin/wotsap", line 1488, in initfont
init_pil_get_logo()
  File "/usr/bin/wotsap", line 232, in init_pil_get_logo
Image.fromstring('P', (175,15), string.join(logostr, ""))
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2342, in fromstring
"Please call frombytes() instead.")
NotImplementedError: fromstring() has been removed. Please call frombytes() 
instead.
```

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

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

Versions of packages wotsap depends on:
ii  fonts-freefont-ttf  20120503-7
ii  python  2.7.15~rc1-1
ii  python-pil  5.1.0-1

wotsap recommends no packages.

Versions of packages wotsap suggests:
ii  gnupg  2.2.5-1
ii  wget   1.19.5-1

-- no debconf information

Bug#899219: gcc-8: __builtin_ms_va_list missing on arm64

[Michael Gilbert]

package: src:gcc-8
severity: normal
version: 8.1.0-3

Wine now relies on this [0], but it seems to be missing in gcc on
arm64.  It is supported in newer versions of clang on arm64.

Best wishes,
Mike

[0]https://buildd.debian.org/status/fetch.php?pkg=wine-development=arm64=3.8-1=1526746237=0

Bug#899218: RFP: mbdyn -- MBDyn is the first and possibly the only free general purpose Multibody Dynamics analysis software

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: mbdyn
  Version : 1.7.3
  Upstream Author : Pierangelo Masarati pierangelo.masar...@polimi.it
* URL : http://www.mbdyn.org/
* License : GPL-2.1
  Programming Lang: C++, Fortran
  Description : MBDyn is the first and possibly the only free general 
purpose Multibody Dynamics analysis software

MBDyn features the integrated multidisciplinary simulation of multibody, 
multiphysics systems, including nonlinear mechanics of rigid and flexible 
bodies (geometrically exact & composite-ready beam and shell finite elements, 
component mode synthesis elements, lumped elements) subjected to kinematic 
constraints, along with smart materials, electric networks, active control, 
hydraulic networks, and essential fixed-wing and rotorcraft aerodynamics.

MBDyn simulates the behavior of heterogeneous mechanical, aeroservoelastic 
systems based on first principles equations.

MBDyn can be easily coupled to external solvers for co-simulation of 
multiphysics problems, e.g. Computational Fluid Dynamics (CFD), terradynamics, 
block-diagram solvers like Scicos, Scicoslab and Simulink, using a simple C, 
C++ or Python peer-side API.

MBDyn is being actively developed and used in the aerospace (aircraft, 
helicopters, tiltrotors, spacecraft), wind energy (wind turbines), automotive 
(cars, trucks) and mechatronic fields (industrial robots, parallel robots, 
micro aerial vehicles (MAV)) for the analysis and simulation of the dynamics of 
complex systems.

Run-time loading of user-defined modules is leveraged to let users extend the 
feature library (elements, drives, constitutive laws, and more).

On GNU/Linux, real-time execution is supported under RTAI, the Real-Time 
Application Interface, and POSIX tight scheduling.

Bug#896666: qemu-system-x86: page allocation failure: 4.16.0-0.bpo.1-amd64

[Russell Mosemann]

Package: src:linux
Version: 4.16.5-1~bpo9+1
Severity: important
 
May 20 18:32:12 vhost004 kernel: qemu-system-x86: page allocation failure: 
order:4, mode:0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO)
, nodemask=(null)
May 20 18:32:12 vhost004 kernel: qemu-system-x86 cpuset=emulator 
mems_allowed=0-1
May 20 18:32:12 vhost004 kernel: CPU: 10 PID: 29820 Comm: qemu-system-x86 
Tainted: G  I  4.16.0-0.bpo.1-amd64 #1 Debian
4.16.5-1~bpo9+1
May 20 18:32:12 vhost004 kernel: Hardware name: HP ProLiant DL380 G6, BIOS P62 
08/16/2015
May 20 18:32:12 vhost004 kernel: Call Trace:
May 20 18:32:12 vhost004 kernel:  dump_stack+0x5c/0x85
May 20 18:32:12 vhost004 kernel:  warn_alloc+0xfc/0x180
May 20 18:32:12 vhost004 kernel:  __alloc_pages_slowpath+0xded/0xe00
May 20 18:32:12 vhost004 kernel:  ? _cond_resched+0x16/0x40
May 20 18:32:12 vhost004 kernel:  __alloc_pages_nodemask+0x212/0x250
May 20 18:32:12 vhost004 kernel:  kmalloc_order+0x14/0x40
May 20 18:32:12 vhost004 kernel:  kmalloc_order_trace+0x1d/0xa0
May 20 18:32:12 vhost004 kernel:  kvm_dev_ioctl+0xb4/0x680 [kvm]
May 20 18:32:12 vhost004 kernel:  do_vfs_ioctl+0xa2/0x620
May 20 18:32:12 vhost004 kernel:  SyS_ioctl+0x74/0x80
May 20 18:32:12 vhost004 kernel:  do_syscall_64+0x6c/0x130
May 20 18:32:12 vhost004 kernel:  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
May 20 18:32:12 vhost004 kernel: RIP: 0033:0x7f163b7cbdd7
May 20 18:32:12 vhost004 kernel: RSP: 002b:7ffee35cae58 EFLAGS: 0246 
ORIG_RAX: 0010
May 20 18:32:12 vhost004 kernel: RAX: ffda RBX: ae01 
RCX: 7f163b7cbdd7
May 20 18:32:12 vhost004 kernel: RDX:  RSI: ae01 
RDI: 000b
May 20 18:32:12 vhost004 kernel: RBP:  R08: 562d0b6949b8 
R09: 0050
May 20 18:32:12 vhost004 kernel: R10: 0020 R11: 0246 
R12: 562d0c561d90
May 20 18:32:12 vhost004 kernel: R13: 0002 R14: 0120 
R15: 
May 20 18:32:12 vhost004 kernel: Mem-Info:
May 20 18:32:12 vhost004 kernel: active_anon:9865 inactive_anon:14694 
isolated_anon:0
  active_file:26970 inactive_file:1019144 
isolated_file:0
  unevictable:16675 dirty:62303 writeback:0 
unstable:0
  slab_reclaimable:60734 
slab_unreclaimable:442497
  mapped:25836 shmem:10091 pagetables:5260 
bounce:0
  free:73539 free_pcp:0 free_cma:0
May 20 18:32:12 vhost004 kernel: Node 0 active_anon:28100kB 
inactive_anon:40024kB active_file:86204kB inactive_file:2055208kB 
unevictable:4604kB isolated(anon):0kB isolated(file):0kB mapped:48596kB 
dirty:44972kB writeback:0kB shmem:6676kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 20 18:32:12 vhost004 kernel: Node 1 active_anon:11360kB 
inactive_anon:18752kB active_file:21676kB inactive_file:2021368kB 
unevictable:62096kB isolated(anon):0kB isolated(file):0kB mapped:54748kB 
dirty:204240kB writeback:0kB shmem:33688kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 16384kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 20 18:32:12 vhost004 kernel: Node 0 DMA free:15892kB min:20kB low:32kB 
high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 20 18:32:12 vhost004 kernel: lowmem_reserve[]: 0 3486 30139 30139 30139
May 20 18:32:12 vhost004 kernel: Node 0 DMA32 free:121468kB min:5204kB 
low:8772kB high:12340kB active_anon:26580kB inactive_anon:38016kB 
active_file:84268kB inactive_file:2002788kB unevictable:1600kB 
writepending:43408kB present:3643520kB managed:3577952kB mlocked:1600kB 
kernel_stack:3020kB pagetables:9176kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB

May 20 18:32:12 vhost004 kernel: lowmem_reserve[]: 0 0 26653 26653 26653
May 20 18:32:12 vhost004 kernel: Node 0 Normal free:41792kB min:39784kB 
low:67076kB high:94368kB active_anon:1548kB inactive_anon:2008kB 
active_file:1992kB inactive_file:52128kB unevictable:3004kB writepending:1564kB 
present:27787264kB managed:27292884kB mlocked:3004kB kernel_stack:1592kB 
pagetables:400kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
May 20 18:32:12 vhost004 kernel: lowmem_reserve[]: 0 0 0 0 0
May 20 18:32:12 vhost004 kernel: Node 1 Normal free:115004kB min:45096kB 
low:76032kB high:106968kB active_anon:11488kB inactive_anon:18528kB 
active_file:21732kB inactive_file:2021684kB unevictable:62096kB 
writepending:204240kB present:31457276kB managed:30943772kB mlocked:62096kB 
kernel_stack:4748kB pagetables:11464kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 20 18:32:12 vhost004 kernel: lowmem_reserve[]: 0 0 0 0 0
May 20 18:32:12 vhost004 kernel: Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB 

Bug#899217: The conf.d directory is not empty yet

[積丹尼 Dan Jacobson]

Package: php7.0-cli
Version: 7.0.29-1

Here the order the files is removed is wrong.

The conf.d directory is not empty yet.

By the time the command is finished, it is empty, but it is already too late.


# aptitude purge ~nphp7.0~i
The following packages will be REMOVED:
  php7.0-cli{p} (php7.0-cliP<- php-cli)  php7.0-common{p}  php7.0-json{p} 
(php7.0-jsonP<- php-json)
  php7.0-opcache{p}  php7.0-readline{p}

Removing php7.0-cli (7.0.29-1) ...
Removing php7.0-readline (7.0.29-1) ...
Removing php7.0-json (7.0.29-1) ...
Removing php7.0-opcache (7.0.29-1) ...
Removing php7.0-common (7.0.29-1) ...
Processing triggers for man-db (2.8.3-2) ...
(Reading database ... 196179 files and directories currently installed.)
Purging configuration files for php7.0-readline (7.0.29-1) ...
Purging configuration files for php7.0-opcache (7.0.29-1) ...
Purging configuration files for php7.0-cli (7.0.29-1) ...
dpkg: warning: while removing php7.0-cli, directory '/etc/php/7.0/cli/conf.d' 
not empty so not removed
Purging configuration files for php7.0-json (7.0.29-1) ...
Purging configuration files for php7.0-common (7.0.29-1) ...
dpkg: warning: while removing php7.0-common, directory '/etc/php/7.0' not empty 
so not removed
Current status: 0 (+0) broken, 232 (-5) upgradable, 10137 (+0) new.
# find /etc/php/7.0 -ls
   313927  4 drwxr-xr-x   3 root root 4096 May 21 08:25 
/etc/php/7.0
   313944  4 drwxr-xr-x   3 root root 4096 May 21 08:25 
/etc/php/7.0/cli
   313945  4 drwxr-xr-x   2 root root 4096 May 21 08:25 
/etc/php/7.0/cli/conf.d

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Alexis Murzeau]

unmerge 899124
thanks

Hi,

I'm maintaining streamlink which use a custom rtd sphinx theme which use
fonts-font-awesome v4.

I'm unmerging this bug from xxx because there is a major incompatibility
changes in font-awesome 5.
The font file got split in solid, regular and brands fonts, and thus
there is no drop in replacement for the old fontawesome-webfont.xxx.

Many packages use hard-coded path to the old fonts
(fontawesome-webfont.xxx) because they reference them from their .css theme.

According to [1], there are 26 probably affected source packages.

Some packages embed font-awesome directly instead of symlinking to
fonts-font-awesome, which might be a solution for most affected
packages, albeit duplicating the font (which is a bit against the
purpose of this package).

Having a separate package for fonts-font-awesome could let maintainers
use font-awesome 4 until upstream changes for font-awesome 5.
This package would be probably have little change over time as upstream
does not intend to update the v4 branch anymore [4].

This would provide a solution avoiding simply duplicating old
fontawesome-webfont v4 files in packages that use them.

As a side note, depending on the font usage by packages, using
fa-solid-900 as fontawesome-webfont can fix most basic glyphs, but
that's not an ideal solution, mixing v4 css and js with v5 font.

[1] Here is an analysis of font-awesome usage across sid packages from [3]:
Packages embedding a copy of font-awesome:
- boinc 7.10.2+dfsg-1: embedded copy of 4.6.3
- cockpit 168-1: embedded copy of 4.2.0
- controlsfx 8.40.14-1: embedded copy of 4.7.0
- copyq 3.1.2-1: embedded copy of 4.7.0
- coz-profiler 0.1.0-2: embedded copy of 4.7
- crmsh 3.0.1-4: embedded copy of 4.0.3
- fontawesomefx 8.9-1: embedded copy of 4.4.1
- golang-github-smartystreets-goconvey 1.6.1-3: embedded copy of 4.5
- hugo 0.40.3-1: embedded copy of 4.4.1
- jekyll 3.1.6+dfsg-3: embedded copy of 4.4.0
- mitmproxy 3.0.3-1: embedded copy of 4.2.0 and 4.0.3 (first mitmproxy
itself and the later for onboardingapp plugin)
- mongodb 1:3.4.14-3: embedded copy in base64
- nghttp2 1.32.0-1: embedded copy of 4.2.0
- opennebula 4.12.3+dfsg-3.1: embedded copy of 4.3.0
- pgbadger 9.2-1: embedded copy of 3.2
- publican 4.3.2-2: embedded copy of 4.2.0
- python-mne 0.15.2+dfsg-2: embedded copy of 4.7.0
- python-openstackdocstheme 1.18.1-3: embedded copy of 4.7.0
- python-xstatic-font-awesome 4.7.0.0-4: embedded copy of 4.7
- rclone 1.41-1: embedded copy of 4.6.3
- spdylay 1.3.2-2.1: embedded copy of 4.0.2
- sympa 6.2.32~dfsg-1: embedded copy of 4.3.0
- wims 1:4.15b~dfsg1-11: embedded copy of 4.7.0
- zeal / 1:0.4.0-2: embedded copy

Packages symlinking to fonts-font-awesome files:
- cantata 2.3.0.ds1-1: symlink to fonts
- djangorestframework 3.8.2-1: symlink to fonts
- glewlwyd 1.3.1-1: embedded copy of 4.7 replaced with symlink to fonts
in override_dh_install-indep
- grafana 2.6.0+dfsg-3: symlink to fonts and css
- grr 3.1.0.2+dfsg-5: symlink to fonts
- hyperkitty 1.1.4-4: symlink to fonts
- julia 0.4.7-7: symlink to fonts
- lightbeam 1.3.1+dfsg-1: symlink to fonts and css
- mkdocs-bootstrap 0.1.1-3: symlink to fonts
- mkdocs-bootswatch 0.4.0-3: symlink to fonts
- netdata 1.10.0+dfsg-1: symlink to fonts and css
- ntopng 3.2+dfsg1-1: symlink to fonts, css, less, scss
- oca-core 11.0.20180420-1: symlink to fonts
- phabricator 0~git20180509-2: symlink to fonts
- plasma-applet-redshift-control 1.0.18-2: symlink to fonts
- prewikka 4.1.5-2: symlink to fonts and css
- python-qtawesome 0.4.4+ds1-1: symlink to fonts
- r-cran-rmarkdown 1.9+dfsg-2: symlink to fonts and css
- r-cran-shiny 1.0.5+dfsg-4: symlink to fonts and css
- ruby-font-awesome-rails 4.7.0.2-1: symlink to fonts
- rustc 1.25.0+dfsg1-2: symlink to fonts and css
- sphinx-rtd-theme 0.2.4-1: symlink to fonts
- streamlink 0.12.1+dfsg-1: symlink to fonts
- tulip 4.8.0dfsg-2: symlink to fonts
- ublock-origin 1.13.8+dfsg-1: symlink to fonts
- webdeveloper 1.2.13-1: symlink to fonts

[2] https://github.com/rtfd/sphinx_rtd_theme/issues/266
[3] https://codesearch.debian.net/search?q=fontawesome-webfont
[4]
https://github.com/FortAwesome/Font-Awesome#where-did-font-awesome-4-or-3-go
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#896449: dewalls FTBFS with qbs 1.11.0+dfsg-1

[Wookey]

On 2018-05-19 11:24 +0300, Juhani Numminen wrote:

> I'm just guessing here, but perhaps “qbs-build” just needs some prefix in 
> front of it,
> similar to https://bugreports.qt.io/browse/QTCREATORBUG-20024?

Yes. that was right. In fact I'd already documented this change with
v1.11 on the wiki page: https://wiki.debian.org/Qbs, but had forgotten
about it. Updated now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing

[John MacFarlane]

I don't understand this error.  InvalidYaml *is* a constructor for the
type ParseException in Data.Yaml (yaml package).  So it's not clear why
the compiler would complain about it being used as a "constructor-like
thing."

What version of ghc is being used to compile?

What version of the Haskell yaml package is being used?

Emilio Pozuelo Monfort  writes:

> Source: pandoc
> Version: 2.2-1
> Severity: serious
>
> pandoc fails to build on armel and armhf:
>
> [117 of 131] Compiling Text.Pandoc.Readers.Markdown ( 
> src/Text/Pandoc/Readers/Markdown.hs, 
> dist-ghc/build/Text/Pandoc/Readers/Markdown.o )
>
> src/Text/Pandoc/Readers/Markdown.hs:275:20: error:
> * Identifier `InvalidYaml' used as a constructor-like thing
> * In the pattern:
> InvalidYaml (Just YamlParseException {yamlProblem = problem,
>   yamlContext = _ctxt,
>   yamlProblemMark = YamlMark 
> {yamlLine = yline,
>   
> yamlColumn = ycol}})
>   In a case alternative:
>   InvalidYaml (Just YamlParseException {yamlProblem = problem,
> yamlContext = _ctxt,
> yamlProblemMark = YamlMark 
> {yamlLine = yline,
> 
> yamlColumn = ycol}})
> -> logMessage
>  $ CouldNotParseYamlMetadata
>  problem
>  (setSourceLine
> (setSourceColumn pos (sourceColumn pos + ycol))
> (sourceLine pos + 1 + yline))
>   In a stmt of a 'do' block:
> case err' of
>   InvalidYaml (Just YamlParseException {yamlProblem = problem,
> yamlContext = _ctxt,
> yamlProblemMark = YamlMark 
> {yamlLine = yline,
> 
> yamlColumn = ycol}})
> -> logMessage
>  $ CouldNotParseYamlMetadata
>  problem
>  (setSourceLine
> (setSourceColumn pos (sourceColumn pos + ycol))
> (sourceLine pos + 1 + yline))
>   _ -> logMessage $ CouldNotParseYamlMetadata (show err') pos
> |
> 275 |InvalidYaml (Just YamlParseException{
> |^...
>
>
> Full logs at https://buildd.debian.org/status/package.php?p=pandoc=sid
>
> Emilio
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), 
> (500, 'unstable-debug'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#891611: jessie-pu: package subversion/1.8.10-6+deb8u6

[James McCoy]

On Mon, Feb 26, 2018 at 10:12:15PM -0500, James McCoy wrote:
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This upload would fix crashes that are seen when using subversion's Perl
> bindings.  In particular, git-svn has been a common victim since its
> memory usage patterns tend to cause the right conditions.
> 
> I've verified this against the originally reported issue[0] and
> Salvatore Bonaccorso, who prodded me to prepare the upload, has verified
> it against their problematic repository.

Uploaded, per the workflow changes described in
<1523909491.2872.15.ca...@adam-barratt.org.uk>.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#899216: kicad: assert failure in bitmap2component

[David Tomaschik]

Package: kicad
Version: 5.0.0~rc1+dfsg1+20180318-3
Severity: important

Dear Maintainer,

bitmap2component crashes with an assert failure on loading.  I suspect this is
another wxWidgets versioning issue, but since it's occuring in 5.0.0~rc1, this
seems independent of the issue described in #895801.  (Apologies if, in fact,
this is a duplicate of that or another bug.)

ASSERT INFO:
../src/gtk/dc.cpp(276): assert "cr" failed in wxPaintDCImpl(): using wxPaintDC 
without being in a native paint event

BACKTRACE:
[1] wxNativeDCFactory::CreatePaintDC(wxPaintDC*, wxWindow*)
[2] wxPaintDC::wxPaintDC(wxWindow*)
[3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
[4] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[5] wxEvtHandler::TryHereOnly(wxEvent&)
[6] wxEvtHandler::ProcessEventLocally(wxEvent&)
[7] wxEvtHandler::ProcessEvent(wxEvent&)
[8] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[10] wxWindow::GTKSendPaintEvents(_cairo*)
[11] g_closure_invoke
[12] g_signal_emit_valist
[13] g_signal_emit
[14] gtk_container_propagate_draw
[15] gtk_container_propagate_draw
[16] gtk_container_propagate_draw
[17] g_closure_invoke
[18] g_signal_emit_valist
[19] g_signal_emit
[20] gtk_container_propagate_draw
[21] gtk_container_propagate_draw
[22] gtk_main_do_event
[23] g_closure_invoke
[24] g_signal_emit_valist
[25] g_signal_emit
[26] g_main_context_dispatch
[27] g_main_loop_run
[28] gtk_main
[29] wxGUIEventLoop::DoRun()
[30] wxEventLoopBase::Run()
[31] wxAppConsoleBase::MainLoop()
[32] wxEntry(int&, wchar_t**)
[33] __libc_start_main
[34] _start

This renders bitmap2component completely unusable.

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

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

Versions of packages kicad depends on:
ii  libc6   2.27-3
ii  libcairo2   1.15.10-3
ii  libcurl37.58.0-2
ii  libgcc1 1:8.1.0-3
ii  libgl1  1.0.0+git20180308-2
ii  libglew2.0  2.0.0-5
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18.1.0-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-1
ii  libssl1.1   1.1.0h-2
ii  libstdc++6  8.1.0-3
ii  libwxbase3.0-0v53.0.4+dfsg-3
ii  libwxgtk3.0-gtk3-0v53.0.4+dfsg-3
ii  python  2.7.15~rc1-1
ii  python-wxgtk3.0 3.0.2.0+dfsg-7

Versions of packages kicad recommends:
pn  kicad-demos  
ii  kicad-libraries  5.0.0~rc1+dfsg1+20180318-3
ii  xsltproc 1.1.29-5

Versions of packages kicad suggests:
ii  extra-xdg-menus1.0-4
pn  kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-do  
ii  kicad-packages3d   5.0.0~rc1+20180318-1

-- no debconf information

Bug#899215: kicad: eeschema is sluggish

[David Tomaschik]

Package: kicad
Version: 5.0.0~rc1+dfsg1+20180318-3
Severity: important

Dear Maintainer,

When loading eeschema in the 5.0.0-rc1 version from experimental, the schematic
editor is very sluggish.  There is a thread about this on the kicad forums here:

https://forum.kicad.info/t/debian-kicad-5-0-0-rc2-dev-eeschema-sluggish/10464

It appears to be related to USE_WX_GRAPHICS_CONTEXT, but that seems necessary to
use with wxwidgets linked with Gtk3.  I don't know what workarounds are
possible.


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

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

Versions of packages kicad depends on:
ii  libc6   2.27-3
ii  libcairo2   1.15.10-3
ii  libcurl37.58.0-2
ii  libgcc1 1:8.1.0-3
ii  libgl1  1.0.0+git20180308-2
ii  libglew2.0  2.0.0-5
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18.1.0-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-1
ii  libssl1.1   1.1.0h-2
ii  libstdc++6  8.1.0-3
ii  libwxbase3.0-0v53.0.4+dfsg-3
ii  libwxgtk3.0-gtk3-0v53.0.4+dfsg-3
ii  python  2.7.15~rc1-1
ii  python-wxgtk3.0 3.0.2.0+dfsg-7

Versions of packages kicad recommends:
pn  kicad-demos  
ii  kicad-libraries  5.0.0~rc1+dfsg1+20180318-3
ii  xsltproc 1.1.29-5

Versions of packages kicad suggests:
ii  extra-xdg-menus1.0-4
pn  kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-do  
ii  kicad-packages3d   5.0.0~rc1+20180318-1

-- no debconf information

Bug#899118: flash-kernel: add missing arm64 boards

[Heinrich Schuchardt]

On 05/20/2018 09:15 PM, Karsten Merker wrote:
> On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote:
> 
>> Package: flash-kernel
>> Version: 3.94
>> Severity: normal
>> Tags: patch
>>
>> Add 60 missing database entries for arm64 boards
>> supported both by U-Boot and by Linux:
>>
>> Amlogic Meson GXL (S905X) P212 Development Board
>> BananaPi-M64
>> Freescale Layerscape 2080a QDS Board
>> Freescale Layerscape 2080a RDB Board
>> FriendlyARM NanoPi A64
>> FriendlyARM NanoPi NEO 2
>> FriendlyARM NanoPi NEO Plus2
>> GeekBox
>> HiKey Development Board
>> HiSilicon Poplar Development Board
>> Khadas VIM
>> Libre Computer Board ALL-H3-CC H5
>> Libre Technology CC
>> LS1012A Freedom Board
>> LS1012A QDS Board
>> LS1012A RDB Board
>> LS1043A RDB Board
>> LS1046A RDB Board
>> LS1088A QDS Board
>> LS1088A RDB Board
>> Marvell Armada 3720 Development Board DB-88F3720-DDR3
>> Marvell Armada 7040 DB board
>> NVIDIA Tegra210 P2371 (P2530/P2595) reference design
>> NVIDIA Tegra210 P2571 reference design
>> Olimex A64-Olinuxino
>> OrangePi Win/Win Plus
>> OrangePi Zero Plus2
>> Pine64
>> Renesas Draak board based on r8a77995
>> Renesas Eagle board based on r8a77970
>> Renesas H3ULCB board based on r8a7795 ES2.0+
>> Renesas M3ULCB board based on r8a7796
>> Renesas Salvator-X board based on r8a7795 ES2.0+
>> Renesas Salvator-X board based on r8a7796
>> Renesas Salvator-X board based on r8a77965
>> Rockchip PX5 EVB
>> Rockchip RK3328 EVB
>> SoCFPGA Stratix 10 SoCDK
>> UniPhier LD11 Global Board (REF_LD11_GP)
>> UniPhier LD11 Reference Board
>> UniPhier LD20 Global Board (REF_LD20_GP)
>> UniPhier LD20 Reference Board
>> UniPhier PXs3 Reference Board
>> Xunlong Orange Pi PC 2
>> Xunlong Orange Pi Prime
>> ZynqMP ZC1232 RevA
>> ZynqMP ZC1254 RevA
>> ZynqMP ZC1275 RevA
>> ZynqMP zc1751-xm015-dc1 RevA
>> ZynqMP zc1751-xm016-dc2 RevA
>> ZynqMP zc1751-xm017-dc3 RevA
>> ZynqMP zc1751-xm018-dc4
>> ZynqMP zc1751-xm019-dc5 RevA
>> ZynqMP ZCU100 RevC
>> ZynqMP ZCU102 Rev1.0
>> ZynqMP ZCU102 RevA
>> ZynqMP ZCU102 RevB
>> ZynqMP ZCU104 RevA
>> ZynqMP ZCU106 RevA
>> ZynqMP ZCU111 RevA
> 
> Hello,
> 
> many thanks for the patch.  Just to make sure that we don't run
> into problems later on: do all these boards really use u-boot's
> config_distro_bootcmd.h and thereby work properly with
> bootscr.uboot-generic?
> 
> When looking at the defconfigs for several of these systems, I
> see e.g. CONFIG_BOOTARGS settings that don't really match what I
> would expect for systems using config_distro_bootcmd.h.
> Three random examples:
> 
> - r8a77995_draak_defconfig:
>   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
> nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
> 
> - ls1088ardb_sdcard_qspi_defconfig:
>   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
> hugepagesz=2m hugepages=256"
> 
> - hikey_defconfig:
>   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
> 
> Regards,
> Karsten
> 

Thanks for reviewing.

For a board to be able to benefit from flash-kernel U-Boot must:

- be capable to load and execute boot.scr
- provide the booti command
- allow the definition of the following environment variables:
  - devtype, devnum, partition
  - fdtfile
  - kernel_addr_r
  - fdt_addr_r
  - ramdisk_addr_r

In your examples above I could not find any evidence that U-Boot cannot
be configured and built to fulfill these requirements.

For instance build

make r8a77995_draak_defconfig
make menuconfig
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTARGS="console=ttySC0,115200"
CONFIG_ENV_IS_IN_MMC=y (this is a default value)
make -j6

Setup missing environment variables interactively and save them to MMC
and you can rely on flash-kernel for booting.

ls1088ardb_sdcard_qspi_defconfig and hikey_defconfig select
CONFIG_DISTRO_DEFAULTS=y. CONFIG_BOOTARGS has to be reconfigured.

This patch is only about providing flash-kernel for the boards. It is
not about providing U-Boot configured to match flash-kernel's requirements.

I think that even for boards for which we do not provide U-Boot as a
Debian package we should allow the usage of flash-kernel without setting
up a local override for the machine database (/etc/flash-kernel/db).

Best regards

Heinrich

Bug#899214: lintian: Update links to emacsen-team's website

[Sean Whitton]

Package: lintian
Version: 2.5.87
Severity: minor
Tags: patch

Hello,

Moved alioth->Debian wiki.  Thanks.

-- 
Sean Whitton
>From cd49a64414327aa91b0f20c46d30d29a4fa89780 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 20 May 2018 15:47:09 -0700
Subject: [PATCH] Update references to emacsen-team's website

---
 checks/elpa.desc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/checks/elpa.desc b/checks/elpa.desc
index 22c0a78c8..b1e376e30 100644
--- a/checks/elpa.desc
+++ b/checks/elpa.desc
@@ -4,7 +4,7 @@ Abbrev: elpa
 Type: binary
 Needs-Info: unpacked
 Info: This script checks if the packages comply with various aspects of the
- pkg-emacsen team's policy.
+ emacsen team's policy.
 
 Tag: emacsen-common-without-dh-elpa
 Severity: normal
@@ -20,4 +20,4 @@ Info: The package uses the emacsen-common infrastructure but the
  .
  In addition, a package built with dh-elpa integrates with the GNU
  Emacs package manager, for a better user experience.
-Ref: dh_elpa(1), dh-make-elpa(1), https://pkg-emacsen.alioth.debian.org/
+Ref: dh_elpa(1), dh-make-elpa(1), https://wiki.debian.org/DebianEmacsen/elpa-hello
-- 
2.14.2

Bug#898205: Consecutive builds may fail

[Nicholas D Steeves]

Hi Chris,

On Tue, May 08, 2018 at 06:51:17PM +0100, Chris Lamb wrote:
> Nicholas,
> 
> > Continuing from #883218.  Strictly speaking I think this might be a
> > §4.9 "clean (required)" Policy violation and should be priority
> > "serious", but I'd like to keep it as "important" until
> 
> I fear looking up the exact Policy reference, writing this mail and
> additionally providing a justification to why you chose a particular
> level seems a little add odds time and energy-wise for a one-line fix
> to a package, no? :)

Haha, yes, for the general case absolutely!  This was before the
virtual "ftbfs" bug priority, and I believe that the extra work is
similar to the old "one must manually look up every mispelt word in a
physical dictionary to learn how to spell it, rather than learning how
to rely on a spellcheck gadget or on others".  So yeah, important for
DD application candidacy ;-)

Also I appreciate you took the time to find this issue and feel bad
that I misunderstood where your were encountering the error, and
especially that I had missed what turned out to be a serious policy
violation!

Still waiting to yasnippet-snippets to merge Elpy's snippets, and for
a new Elpy release.  Even if neither of these occurs, I'll request
sponsorship for an upload on the first of June, in order to close this
bug.

Take care!
Nicholas


signature.asc
Description: PGP signature

Bug#899213: compiz: sistematically places new windows below existing ones

[boffi]

Package: compiz-plugins
Version: 1:0.9.13.1+18.04.20180302-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   I activated the "Place Windows" plugin

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

   n/a

   * What was the outcome of this action?

   irrispective of the algorithm chosen, the plugin insists on placing new
   windows BELOW existing windows (not always but most of the times)

   * What outcome did you expect instead?

   every WM I used (and that comprised compiz+place_windows, until recently)
   placed new windows above existing windows, because when a user
   instantiates a new window, either using a shortcut and the "Commands"
   plugin, a desktop launcher or a system menu, said user 99.3% wants to
   use the new window immediately

That said, I'm trying to use compiz standalone (no DE) with the support of
a dock/panel (either tint2 or cairo-dock).

I'd like to help fixing this problem giving you any further additional info.

Thank you in advance, gb
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages compiz-plugins depends on:
ii  compiz-core   1:0.9.13.1+18.04.20180302-1
ii  compiz-plugins-default1:0.9.13.1+18.04.20180302-1
ii  libc6 2.27-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.8-2
ii  libdecoration01:0.9.13.1+18.04.20180302-1
ii  libfribidi0   0.19.7-2
ii  libgcc1   1:8.1.0-3
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libgl11.0.0+git20180308-2
ii  libglib2.0-0  2.56.1-2
ii  libglibmm-2.4-1v5 2.56.0-2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libice6   2:1.0.9-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libnotify40.7.7-3
ii  libpango-1.0-01.42.1-1
ii  libpangocairo-1.0-0   1.42.1-1
ii  librsvg2-22.40.20-2
ii  libsigc++-2.0-0v5 2.10.0-2
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-5
ii  libstdc++68.1.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb1   1.13-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-1
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-6.1+b1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-5

compiz-plugins recommends no packages.

compiz-plugins suggests no packages.

-- no debconf information

Bug#899212: Exclusively use Python 3 deps and configure the use of python3 by default

[Nicholas D Steeves]

Package: elpy
Version: 1.20.0-1
Severity: normal

This bug tracks the long/medium-term goal to installing only Python 3
dependencies for Elpy.  Steps of the transition:

1. Configure dh-elpa to `setq elpy-rpc-python-command "python3"`
   - Needed to run self-tests using the Python 3 variants of dependencies.
2. Debug failures, and work with upstream, forwarding patches whenever possible.
3. Add a Debian-specific patch to do #1 automatically in the installed package.
   - At present this must be manually configured, or virtualenvs must be used
4. Finally, drop Python 2 dependencies. Definitely drop them from Build-Depends.
   || retain them as Recommends or Suggests for elpa-elpy?

Please comment, especially on what you'd like to see for #4!

Regards,
Nicholas

Bug#899203: dput-ng: Ignores ~/.ssh/config for SFTP uploads

[Mattia Rizzolo]

On Sun, May 20, 2018 at 09:20:23PM +0200, Axel Beckert wrote:
> Nevertheless, dput-ng tries to resolve the given hostname directly
> instead of honouring what is written in ~/.ssh/config and of course
> fails with that:

IIRC that's a limitation of the library used by dput-ng, paramiko.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#899211: linux-cpupower: linuxcpupower unable to call hardware to tell current frequency

[shirish शिरीष]

Package: linux-cpupower
Version: 4.16.5-1
Severity: normal

Dear Maintainer,

I was running -

$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 800 MHz - 3.30 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3.30 GHz.
  The governor "performance" may decide which speed to use
  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.21 GHz (asserted by call to kernel)
  boost state support:
Supported: yes
Active: yes

Now as can be seen it says 'current CPU frequency: Unable to call
hardware' but when it is set to performance, then it should tell what
frequency it is using now.

Some info. of the current machine -

$ lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   158
Model name:  Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
Stepping:9
CPU MHz: 3300.217
CPU max MHz: 3300.
CPU min MHz: 800.
BogoMIPS:6000.00
Virtualization:  VT-x
L1d cache:   32K
L1i cache:   32K
L2 cache:256K
L3 cache:6144K
NUMA node0 CPU(s):   0-3
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq
pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16
xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer
aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault
invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap
clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves ibpb ibrs stibp
dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp


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

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

Versions of packages linux-cpupower depends on:
ii  libc6 2.27-3
ii  libcpupower1  4.16.5-1
ii  libpci3   1:3.5.2-1

linux-cpupower recommends no packages.

linux-cpupower suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Brian May]

Dmitry Shachnev  writes:

> One more question: why do we need mkdocs-bootswatch? It currently is not
> used by anything in sid, and I would like to avoid doing useless work.

Previously it was required by mkdocs. Are you saying this is no longer
the case? If so, please remove it.

Thanks
-- 
Brian May 

Bug#899210: atool: arepack creates empty archives if -v option is used

[Reimar Döffinger]

Package: atool
Version: 0.39.0-6
Severity: normal

Dear Maintainer,

Running a command like
arepack -v test.zip test.7z
results in an empty test.7z file regardless of what
test.zip contained.
Using the -S command shows the problem, it adds the
-v option to unzip:
unzip -d Unpack-6655 -v test.zip
Unfortunately, -v for unzip does not just mean
"be verbose", it means "print a verbose list
and don't extract".
This is rather unfortunate, as if one is not
very careful and double-checks the output this
might result in loss of data.

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

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

Versions of packages atool depends on:
ii  perl  5.26.2-4

Versions of packages atool recommends:
ii  bash-completion  1:2.8-1
ii  binutils 2.30-20
ii  bzip21.0.6-8.1
ii  file 1:5.33-2
pn  lbzip2 | pbzip2  
ii  unzip6.0-21
ii  zip  3.0-11+b1

Versions of packages atool suggests:
pn  arc  
pn  arj  
ii  cpio 2.12+dfsg-6
pn  lzip 
pn  lzop 
pn  nomarch  
ii  p7zip-full   16.02+dfsg-6
pn  rar  
ii  rpm  4.14.1+dfsg1-2
pn  unace
pn  unalz
ii  unrar1:5.5.8-1
ii  xz-utils [lzma]  5.2.2-1.3

-- no debconf information

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Brian May]

Dmitry Shachnev  writes:

> There are bundled copies of bootstrap-3.3.7.min.{js,css}.
>
> Bootstrap source is large so I don’t want to include it in missing-sources/.
> Instead I would just repack the tarball without all the bundled stuff.
>
> Will you mind if I do that? Also can I switch from git-dpm to gbp using
> the DPMT workflow (https://wiki.debian.org/Python/GitPackagingPQ)?

Please go ahead on both. Conversion to gbp should be easy too, no
patches to unapply.
-- 
Brian May 

Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

[Sam Hartman]

> "Niels" == Niels Thykier  writes:
control: tags -1 -moreinfo

(I hope this supplies the info you need; obviously retag if you have
more questions.)


Niels> Hi Sam,

Niels> Thanks for the bug report.

Niels> It sounds like you rather want krb5-kdc not to start on
Niels> initial installation.

That's not what I want at all.

I want to try and start it, but I don't want a failure to start to be
considered an error that causes package installation to fail.
This ended up being effectively what happened with the  sysvinit script,
but systemd is much more pro-active at noticing unit start errors.


--Sam

Bug#899209: postgresql-10: FTBFS with perl 5.27: command failed: "psql" [...]

[Dominic Hargreaves]

Source: postgresql-10
Version: 10.4-2
Severity: important
User: debian-p...@lists.debia.org
Usertags: perl-5.28-transition hh2018

In the process of test-building packages against the next version of
perl (5.27.11, to be released as 5.28.0) we found the following failure
in postgreql-10:

2018-05-17 20:01:44.556 UTC [22629] pg_regress ERROR:  
2018-05-17 20:01:44.556 UTC [22629] pg_regress CONTEXT:  while running Perl 
initialization
2018-05-17 20:01:44.556 UTC [22629] pg_regress STATEMENT:  CREATE EXTENSION IF 
NOT EXISTS "plperl"

The complete log, should it be of interest, is at

http://perl.debian.net/rebuild-logs/perl-5.27/postgresql-10_10.4-2/postgresql-10_10.4-2+b1_amd64-2018-05-17T19:50:35Z.build

This bug will become RC nearer the time of the perl 5.28 transition
which is yet to be scheduled.

Note that perl 5.27 is not currently available, even in experimental, just
yet, but we thought that an early heads up would be useful.

If you need to test on perl 5.27, please have a look at
 for a test repository and don't hesitate to
get in touch if you need more information.

Cheers,
Dominic.

Bug#898436: O: trac-subtickets -- sub-ticket feature for Trac tickets

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/applications/trac-subtickets

Bug#891354: O: trac-spamfilter -- Spam-prevention plugin for Trac

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/debian/trac-spamfilter

Bug#898435: O: trac-mastertickets -- adds inter-ticket dependencies to Trac

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/applications/trac-mastertickets

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Antonio Terceiro]

Control: reopen -1

On Sun, May 20, 2018 at 10:32:38PM +0530, Vasudev Kamath wrote:
> Antonio Terceiro  writes:
> > 2) revert the changes in fonts-font-awesome in unstable, upload the
> > new release to experimental, and give people a few months to adapt.
> 
> I'm okay with this solution. I've currently fixed the broken links and
> uploaded the fixes. If you would like more time to adapt to the version
> 5 of font, I can request its removal from unstable and re-upload old
> version to unstable and then upload this new version to experimental.

There is no such thing as requesting removal. you need to upload it with
a higher version number, but with the old contents. Something like
5.0.10+really4.7.0-1.

Or maybe not. I will try if I can work things out with the new version,
so expect a few patches.

For now I'm reopening this bug (which was not really fixed by your -3
upload), and let's see what I can get.


signature.asc
Description: PGP signature

Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing

[Emilio Pozuelo Monfort]

Source: pandoc
Version: 2.2-1
Severity: serious

pandoc fails to build on armel and armhf:

[117 of 131] Compiling Text.Pandoc.Readers.Markdown ( 
src/Text/Pandoc/Readers/Markdown.hs, 
dist-ghc/build/Text/Pandoc/Readers/Markdown.o )

src/Text/Pandoc/Readers/Markdown.hs:275:20: error:
* Identifier `InvalidYaml' used as a constructor-like thing
* In the pattern:
InvalidYaml (Just YamlParseException {yamlProblem = problem,
  yamlContext = _ctxt,
  yamlProblemMark = YamlMark 
{yamlLine = yline,
  
yamlColumn = ycol}})
  In a case alternative:
  InvalidYaml (Just YamlParseException {yamlProblem = problem,
yamlContext = _ctxt,
yamlProblemMark = YamlMark 
{yamlLine = yline,

yamlColumn = ycol}})
-> logMessage
 $ CouldNotParseYamlMetadata
 problem
 (setSourceLine
(setSourceColumn pos (sourceColumn pos + ycol))
(sourceLine pos + 1 + yline))
  In a stmt of a 'do' block:
case err' of
  InvalidYaml (Just YamlParseException {yamlProblem = problem,
yamlContext = _ctxt,
yamlProblemMark = YamlMark 
{yamlLine = yline,

yamlColumn = ycol}})
-> logMessage
 $ CouldNotParseYamlMetadata
 problem
 (setSourceLine
(setSourceColumn pos (sourceColumn pos + ycol))
(sourceLine pos + 1 + yline))
  _ -> logMessage $ CouldNotParseYamlMetadata (show err') pos
|
275 |InvalidYaml (Just YamlParseException{
|^...


Full logs at https://buildd.debian.org/status/package.php?p=pandoc=sid

Emilio

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

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

Bug#894152: O: trac-codecomments -- code comments and review plugin for Trac

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/applications/trac-codecomments

Bug#892414: O: trac-bitten -- continuous integration plugin for Trac

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/applications/trac-bitten

Bug#892412: O: rabbitvcs -- Easy version control

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/applications/rabbitvcs

Bug#894148: O: python-pyld -- implementation of the JSON-LD API

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/modules/python-pyld

Bug#882870: O: python-odoorpc -- pilot Odoo servers through RPC

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/modules/python-odoorpc

Bug#882857: O: python-mplexporter -- general matplotlib exporter

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/modules/python-mplexporter

Bug#892607: O: node-nwmatcher -- CSS3-compliant JavaScript selector engine

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/js-team/node-nwmatcher

Bug#892605: O: node-entities -- Encode and decode XML/HTML entities with ease

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/js-team/node-entities

Bug#899093: flash-kernel: update Pine64+

[Vagrant Cascadian]

Control: tags 899093 +pending

On 2018-05-18, Heinrich Schuchardt wrote:
> Current U-Boot prepends 'allwinner/' to fdtfile.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  db/all.db | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/db/all.db b/db/all.db
> index 97eff67..635fe27 100644
> --- a/db/all.db
> +++ b/db/all.db
> @@ -1249,7 +1249,7 @@ Required-Packages: u-boot-tools
>  
>  Machine: Pine64+
>  Kernel-Flavors: arm64
> -DTB-Id: sun50i-a64-pine64-plus.dtb
> +DTB-Id: allwinner/sun50i-a64-pine64-plus.dtb
>  Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
> -- 
> 2.17.0

Thanks for the patch!

Committed to git.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#892604: O: node-cssstyle -- CSSStyleDeclaration Object Model implementation

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/js-team/node-cssstyle

Bug#894736: Checker config files allow arbitrary code execution scenarios

[Salvatore Bonaccorso]

Control: retitle -1 vim-syntastic: CVE-2018-11319: Checker config files allow 
arbitrary code execution scenarios

Hi

This issue was assigned CVE-2018-11319.

Regards,
Salvatore

Bug#838633: O: dia-shapes -- Diagram editor

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/debian/dia-shapes

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Chris Lamb]

Hi Niels,

> Does this still trigger if people install it into
> "/usr/include/$MA_DIR/util.h"? 

Ah, of course, that's probably why the original implementation was
like that. :)

Fixed here:

  
https://salsa.debian.org/lintian/lintian/commit/13414ae9a8a366a732bb38c54714bc5f04c25fb5

  
Regards,

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

Bug#899207: dist: some script fail syntax checks

[Dominic Hargreaves]

Package: dist
Version: 1:3.5-36.0001-3

As reported upstream 
several of the Perl scripts shipped in this package fail syntax checks.
Additionally, the Depends on libperl4-corelibs-perl, also needed for
several of the scripts, has been removed.

I will include fixes for these isuses in the (delayed) NMU I'm planning
to upload shortly.

Thanks,
Dominic.

Bug#898304: Please Depend on libcurl3 | libcurl4

[積丹尼 Dan Jacobson]

Hmmm, maybe they forgot to make the omni-package yet,
# aptitude search ~nlibcurl4 | wc -l
5
# aptitude search ~nlibcurl4$ | wc -l
0
# aptitude search ~nlibcurl3$ | wc -l
1

Bug#828919: O: omnievents -- omniORB event service

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/debian/omnievents

Bug#884739: O: python-restless -- lightweight REST miniframework for Python

[W. Martin Borgert]

The git repo is currently here:
https://salsa.debian.org/python-team/modules/python-restless

Bug#899118: known good example request

[Vagrant Cascadian]

On 2018-05-20, Geert Stappers wrote:
> On Sun, May 20, 2018 at 09:15:38PM +0200, Karsten Merker wrote:
>> 
>> When looking at the defconfigs for several of these systems, I
>> see e.g. CONFIG_BOOTARGS settings that don't really match what I
>> would expect for systems using config_distro_bootcmd.h.
>> Three random examples:
>> 
>> - r8a77995_draak_defconfig:
>>   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
>> nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
>> 
>> - ls1088ardb_sdcard_qspi_defconfig:
>>   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
>> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 
>> default_hugepagesz=2m hugepagesz=2m hugepages=256"
>> 
>> - hikey_defconfig:
>>   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
>> 
>
> Euh, an example of a "known good"   CONFIG_BOOTARGS

Unfortunately, it's much easier to identify "likely bad" CONFIG_BOOTARGS
than it is to identify "known good".

Anything that hard-codes root= is likely to interfere with booting from
an arbitrary root device, which is one of the things the distro_bootcmd
specification allows.


This is part of why I have uneasy feelings about globally enabling large
batches of boards, instead of selectively enabling individual boards
that have been tested and known to work with a particular flash-kernel +
u-boot + kernel configuration.


If you want to enable arbitrary boards without any testing, it would be
much simpler to do that programmatically, rather than maintaining all.db
in flash-kernel; parse all the .dtb files in the installed linux-image-*
packages, and compare against /proc/device-tree/model ... might not be
particularily fast... but certainly doable. Could use dpkg triggers or a
kernel postinst hook or something, and update the database on
installation of relevent packages.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#898304: Please Depend on libcurl3 | libcurl4

[Stefan Fritsch]

On Thursday, 10 May 2018 00:21:44 CEST 積丹尼 Dan Jacobson wrote:
> Package: apache2-bin
> Version: 2.4.33-3
> 
> Please Depend on libcurl3 | libcurl4,
> else we cannot upgrade our system.

The dependency is generated automatically depending on which version of 
libcurl is used during compilation. And libcurl4 is not in unstable. I don't 
think there is anything I can do.

Bug#897516: Decreasing fail-under parameter helps passing the test

[Andreas Tille]

Control: tags -1 help,upstream
Control: forwarded -1 https://github.com/brodie/cram/issues/32

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Niels Thykier]

Chris Lamb:
> tags 899192 + pending
> thanks
> 
> Russ,
> 
>>  E: libmutter-2-dev: header-has-overly-generic-name 
>> usr/include/mutter/meta/util.h
>>
>> I think this should only trigger on usr/include/util.h specifically, not
>> if the file is in any subdirectory.  Generic header names are only a
>> problem at the top level of the include hierarchy.
> 
> But of course. Almost confused why you thought an explanation was needed ;)
> 
> Fixed in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/7cc105cbf3b46ff248faa74d56a86ba6f3af912e
> 
>   data/files/generic-header-files| 2 +-
>   debian/changelog   | 4 
>   t/tests/files-header-has-overly-generic-name/debian/debian/install | 1 +
>   3 files changed, 6 insertions(+), 1 deletion(-)
> 
> 
> Regards,
> 

Does this still trigger if people install it into
"/usr/include/$MA_DIR/util.h"?  Asking because a number of -dev packages
have begun to use /usr/include/$MA_DIR (in some cases even enabling them
to become M-A: same).

Thanks,
~Niels

Bug#897266: systemd: journalctl assertion failure

[Michael Biebl]

Am 20.05.2018 um 08:59 schrieb Marc Lehmann:
> Sorry for the late reply, I got a bit swamped with work.
> 
> On Sat, May 05, 2018 at 12:13:35PM +0200, Michael Biebl  
> wrote:
>> What does journalctl --verify say about this particular file?
> 
> AFAICR, it complained about file corruption for that file.

We'd need a more detailed error message, but I guess this is moot now.

>> Could you create a /var/log/journal-broken directory and move the broken
>> journal files away into this directory one by one and test which of the
>> files is triggering the abort?
> 
> I could when I originally read your reply, but since I was busy at the
> time and thought I read somewhere that systemd would leave corrupted
> journal files alone, I moved my investigation to later. When I looked for
> it now, it was gone.

Hm, too bad. Not sure what to do about this bug report now that we no
longer have the offending journal file. I'm tempted to close it and
reopen again, in case you run into it again and we can further debug this.

Old journal files are removed when you hit certain limits. The default
retention policy is size based. As long as you have a certain amount of
free space, old journal files are kept. If those limits are exceeded,
the oldest journal files are removed first.

> What I found interesting, though, is that jorunalctl --verify reports file
> corruptiopn for a lot of files in /var/log/journal, although I didn't have
> a crash (all files are newer than 14 days, and the machine has an uptime
> of 40 days and even systemd-journald is running uninterrupted).

That seems very strange. The only case where I personally ran into
journal file corruption is when I had to power cycle the machine.
But you said that journald ran uninterrupted for 40 days.
Would it be possible that this is a hardware or file system issue?

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



signature.asc
Description: OpenPGP digital signature

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

[Holger Schröder]

Am 20.05.2018 um 16:30 schrieb Ben Hutchings:

On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote:

Any news to fix this behavior?


Greetings...

The bug causing (at least some) problems with starting GUIs is #898088;
that's not a kernel bug.

Ben.


The Patch from #898088 for me not helps, same problem (J1900 bay trail).


Holger...

Bug#899118: known good example request

[Geert Stappers]

On Sun, May 20, 2018 at 09:15:38PM +0200, Karsten Merker wrote:
> 
> When looking at the defconfigs for several of these systems, I
> see e.g. CONFIG_BOOTARGS settings that don't really match what I
> would expect for systems using config_distro_bootcmd.h.
> Three random examples:
> 
> - r8a77995_draak_defconfig:
>   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
> nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
> 
> - ls1088ardb_sdcard_qspi_defconfig:
>   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
> hugepagesz=2m hugepages=256"
> 
> - hikey_defconfig:
>   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
> 

Euh, an example of a "known good"   CONFIG_BOOTARGS

 

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#899206: RFS: streamlink/0.12.1+dfsg-1~bpo9+1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors and backports developers,

I am looking for a sponsor for my package "streamlink" into Debian
stretch-backports repository.

 * Package name: streamlink
   Version : 0.12.1+dfsg-1~bpo9+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documenta
  streamlink - CLI for extracting video streams from various websites to
a video

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.12.1+dfsg-1~bpo9+1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the last upload:
streamlink (0.12.1+dfsg-1~bpo9+1) stretch-backports; urgency=low

  * Rebuild for stretch-backports.
  * Recommends all supported players (suggested by #898351)

 -- Alexis Murzeau   Sat, 19 May 2018 18:34:11 +0200

streamlink (0.12.1+dfsg-1) unstable; urgency=low

  * Recommends vlc as default player
  * Test manpage and docs installation
  * New upstream version 0.12.1+dfsg
  * Bump standard version to 4.1.4, no change required
  * Remove X-Python3-Version not needed anymore

 -- Alexis Murzeau   Thu, 10 May 2018 00:45:54 +0200


Differences from testing package (0.12.0+dfsg-1):
  * Recommends all supported players (suggested by #898351)
  * Use debhelper 10 as 11 is not available.
  * pycountry: add patch to support stable provided version (1.8)
  * d/control: require pycountry <= 1.15


Regards,
--
 Alexis Murzeau
 PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#899205: python-cogent: Test suite fails with latest matplotlib

[Andreas Tille]

Package: python-cogent
Severity: serious
Justification: FTBFS
User: debian...@lists.debian.org

The package fails to build with latest matplotlib which became
obvious in the CI report[1].  It fails as well when building the
package.

The issue is reported upstream.[2]

Kind regards,

  Andreas.

[1] https://ci.debian.net/packages/p/python-cogent/testing/amd64/
[2] https://github.com/pycogent/pycogent/issues/112


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

Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core)
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 python-cogent depends on:
ii  libc6  2.24-11+deb9u1
ii  python 2.7.13-2
pn  python-matplotlib  
pn  python-numpy   
pn  python-numpy-abi9  

Versions of packages python-cogent recommends:
pn  blast2
pn  bwa   
pn  cd-hit
pn  clearcut  
pn  dialign   
pn  muscle

Versions of packages python-cogent suggests:
pn  cdbfasta   
pn  clustalw   
pn  fasttree   
pn  infernal   
pn  mafft  
pn  mothur 
pn  parsinsert 
pn  python-cogent-doc  
pn  raxml  
pn  rdp-classifier 
pn  rtax   

Bug#899204: gnome-logs: Segmentation fault in gl_journal_update_latest_timestamp

[John Scott]

Package: gnome-logs
Version: 3.28.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When GNOME Logs is started by a user unable to read system logs
(like in #866171), clicking any of the tabs in the pane on the
left will cause a segmentation fault. This happens regardless
of if X11/Wayland is used.

Just before crashing, it emits a warning:

(gnome-logs:8896): WARNING **: 15:12:43.616: Error retrieving the sender 
timestamps: Cannot assign requested address

Also, I can't reproduce this on 3.22.1-2 in Stretch.

I've included a backtrace as well.

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

Kernel: Linux 4.16.0-1-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 gnome-logs depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  gsettings-desktop-schemas3.28.0-1
ii  libc62.27-3
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  libpango-1.0-0   1.42.0-1
ii  libsystemd0  238-4

gnome-logs recommends no packages.

gnome-logs suggests no packages.

- -- no debconf information

*** /home/john/gnome-logs.txt
#0  0x55564371 in gl_journal_update_latest_timestamp 
(journal=0x55aab420 [GlJournal]) at src/gl-journal.c:97
#1  0x55564371 in gl_journal_get_boot_time (journal=0x55aab420 
[GlJournal], boot_match=0x0) at src/gl-journal.c:126
#2  0x55565b69 in gl_journal_model_get_boot_time (model=, boot_match=) at src/gl-journal-model.c:1079
#3  0xff90 in gl_event_view_list_get_boot_time 
(view=view@entry=0x55a88220 [GlEventViewList], boot_match=)
at src/gl-eventviewlist.c:392
#4  0x55567b61 in on_category_list_changed (list=, 
pspec=, user_data=)
at src/gl-window.c:246
#8  0x769d2e0f in  (instance=instance@entry=0x55a8a320, 
signal_id=, detail=) at 
../../../../gobject/gsignal.c:3447
#5  0x769b6f6d in g_closure_invoke (closure=0x55b64110, 
return_value=0x0, n_param_values=2, param_values=0x7fffc950, 
invocation_hint=0x7fffc8d0) at ../../../../gobject/gclosure.c:804
#6  0x769c9d3e in signal_emit_unlocked_R 
(node=node@entry=0x55789940, detail=detail@entry=1491, 
instance=instance@entry=0x55a8a320, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffc950)
at ../../../../gobject/gsignal.c:3635
#7  0x769d23f5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffcb20) at ../../../../gobject/gsignal.c:3391
#9  0x769bb424 in g_object_dispatch_properties_changed 
(object=0x55a8a320 [GlCategoryList], n_pspecs=, 
pspecs=) at ../../../../gobject/gobject.c:1082
#10 0x769bd969 in g_object_notify_by_spec_internal 
(pspec=0x559f0140 [GParamEnum], object=0x55a8a320 [GlCategoryList])
at ../../../../gobject/gobject.c:1175
#11 0x769bd969 in g_object_notify_by_pspec (object=0x55a8a320 
[GlCategoryList], pspec=pspec@entry=0x559f0140 [GParamEnum])
at ../../../../gobject/gobject.c:1285
#12 0xcf21 in on_gl_category_list_row_selected 
(listbox=0x55a8a320 [GlCategoryList], row=0x55a87990 [GtkListBoxRow], 
user_data=) at src/gl-categorylist.c:143
#16 0x769d2e0f in  (instance=instance@entry=0x55a8a320, signal_id=, detail=detail@entry=0) at ../../../../gobject/gsignal.c:3447
#13 0x769b6f6d in g_closure_invoke (closure=0x558869c0, 
return_value=0x0, n_param_values=2, param_values=0x7fffce60, 
invocation_hint=0x7fffcde0) at ../../../../gobject/gclosure.c:804
#14 0x769c9d3e in signal_emit_unlocked_R 
(node=node@entry=0x559145c0, detail=detail@entry=0, 
instance=instance@entry=0x55a8a320, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffce60)
at ../../../../gobject/gsignal.c:3635
#15 0x769d23f5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd030) at ../../../../gobject/gsignal.c:3391
#17 0x77358aba in gtk_list_box_select_row_internal (box=0x55a8a320 
[GlCategoryList], row=0x55a87990 [GtkListBoxRow])
at ../../../../gtk/gtklistbox.c:1658
#18 0x7735c6b2 in gtk_list_box_select_and_activate_full 
(box=0x55a8a320 [GlCategoryList], row=0x55a87990 [GtkListBoxRow], 
grab_focus=1) at ../../../../gtk/gtklistbox.c:1807
#19 0x7735c7a0 in gtk_list_box_select_and_activate_full (grab_focus=1, 
row=, box=0x55a8a320 

Bug#669214: libjpedal-jbig2-java: diff for NMU version 20100117-1.1

[Adrian Bunk]

Control: tags 669214 + pending

Dear maintainer,

I've prepared an NMU for libjpedal-jbig2-java (versioned as 20100117-1.1)
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

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

diff -Nru libjpedal-jbig2-java-20100117/debian/changelog libjpedal-jbig2-java-20100117/debian/changelog
--- libjpedal-jbig2-java-20100117/debian/changelog	2018-05-20 22:27:25.0 +0300
+++ libjpedal-jbig2-java-20100117/debian/changelog	2018-05-20 22:22:27.0 +0300
@@ -1,3 +1,14 @@
+libjpedal-jbig2-java (20100117-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Apply changes from Jari Aalto:
+- Update to packaging format "3.0 quilt".
+- Update to Standards-Version to 3.9.3 and debhelper to 9.
+- Change obsolete depends default-jdk-builddep to default-jdk
+  (Closes: #669214),
+
+ -- Adrian Bunk   Sun, 20 May 2018 22:22:27 +0300
+
 libjpedal-jbig2-java (20100117-1) unstable; urgency=low
 
   * Initial release (Closes: #565670).
diff -Nru libjpedal-jbig2-java-20100117/debian/compat libjpedal-jbig2-java-20100117/debian/compat
--- libjpedal-jbig2-java-20100117/debian/compat	2018-05-20 22:27:25.0 +0300
+++ libjpedal-jbig2-java-20100117/debian/compat	2018-05-20 22:20:29.0 +0300
@@ -1 +1 @@
-7
+9
diff -Nru libjpedal-jbig2-java-20100117/debian/control libjpedal-jbig2-java-20100117/debian/control
--- libjpedal-jbig2-java-20100117/debian/control	2018-05-20 22:27:25.0 +0300
+++ libjpedal-jbig2-java-20100117/debian/control	2018-05-20 22:20:29.0 +0300
@@ -2,8 +2,8 @@
 Section: java
 Priority: extra
 Maintainer: Steffen Moeller 
-Build-Depends: debhelper (>= 7), cdbs, default-jdk-builddep
-Standards-Version: 3.8.3
+Build-Depends: debhelper (>= 9), cdbs, default-jdk
+Standards-Version: 3.9.3
 Homepage: http://www.jpedal.org/support_JBIG.php
 
 Package: libjpedal-jbig2-java
diff -Nru libjpedal-jbig2-java-20100117/debian/source/format libjpedal-jbig2-java-20100117/debian/source/format
--- libjpedal-jbig2-java-20100117/debian/source/format	1970-01-01 02:00:00.0 +0200
+++ libjpedal-jbig2-java-20100117/debian/source/format	2018-05-20 22:20:29.0 +0300
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#899144: [oxygen-icon-theme] Please include scalable version

[Bastien ROUCARIES]

On Sun, May 20, 2018 at 12:03 AM, Pino Toscano  wrote:
> In data sabato 19 maggio 2018 22:41:16 CEST, Bastien ROUCARIES ha scritto:
>> On Sat, May 19, 2018 at 9:55 PM, Pino Toscano  wrote:
>> > tag 899144 + moreinfo
>> > thanks
>> >
>> > In data sabato 19 maggio 2018 21:42:15 CEST, Bastien ROUCARIÈS ha scritto:
>> >> Some package packages scalable version (svg) of this theme. Could be 
>> >> possible
>> >> to get scalable version here in order to create symbolic link and reduce 
>> >> code
>> >> duplication
>> >
>> > You generally should not rely on a specific icon theme, so what exactly
>> > needs such symlinks, and why?
>>
>> A js package use it (mocha). For now I use 22x22 png but it is ugly I
>> will prefer to use the svg one. Oxygen is also used by a few other js
>> package.
>
> This still does not tell me what exactly mocha and the other js packages
> are doing with oxygen icons. Please explain in detail what is the actual
> situation, otherwise it is hard for us to implement a solution (and
> maintain it) for a problem we have no idea about.

It will create a web page with some images taken from this theme. Pass
icons is ok-apply for example.

In need scalable in order to reduce "code" duplication in hte archive

Bastien

> --
> Pino Toscano

Bug#899203: dput-ng: Ignores ~/.ssh/config for SFTP uploads

[Axel Beckert]

Package: dput-ng
Version: 1.19

I have the following entry in my ~/.ssh/config to work around networks
where SSH and FTP ports are blocked (i.e. those, where only HTTP and
HTTPS ports are open):

Host ftp-master_via_somehost
Hostname ssh.upload.debian.org
ProxyJump somehost.example.com:443

I also have the following content in
/etc/dput.d/profiles/ssh-upload_via_somehost.json:

{
"fqdn": "ftp-master_via_somehost",
"incoming": "/srv/upload.debian.org/UploadQueue/",
"login": "*",
"meta": "debian",
"method": "sftp"
}

Nevertheless, dput-ng tries to resolve the given hostname directly
instead of honouring what is written in ~/.ssh/config and of course
fails with that:

$ dput ssh-upload_via_somehost 
/var/cache/pbuilder/result//lynx_2.8.9dev19-1_amd64.changes
Uploading lynx using sftp to ssh-upload_via_somehost (host: 
ftp-master_via_somehost; directory: /srv/upload.debian.org/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Logging into host ftp-master_via_somehost as abe
SFTP error uploading to ftp-master_via_somehost: gaierror(-2, 'Name or service 
not known')

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

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

Versions of packages dput-ng depends on:
ii  python3   3.6.5-3
ii  python3-dput  1.19

Versions of packages dput-ng recommends:
ii  bash-completion  1:2.8-1

Versions of packages dput-ng suggests:
pn  python3-twitter  

-- no debconf information

Bug#899118: flash-kernel: add missing arm64 boards

[Karsten Merker]

On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote:

> Package: flash-kernel
> Version: 3.94
> Severity: normal
> Tags: patch
> 
> Add 60 missing database entries for arm64 boards
> supported both by U-Boot and by Linux:
> 
> Amlogic Meson GXL (S905X) P212 Development Board
> BananaPi-M64
> Freescale Layerscape 2080a QDS Board
> Freescale Layerscape 2080a RDB Board
> FriendlyARM NanoPi A64
> FriendlyARM NanoPi NEO 2
> FriendlyARM NanoPi NEO Plus2
> GeekBox
> HiKey Development Board
> HiSilicon Poplar Development Board
> Khadas VIM
> Libre Computer Board ALL-H3-CC H5
> Libre Technology CC
> LS1012A Freedom Board
> LS1012A QDS Board
> LS1012A RDB Board
> LS1043A RDB Board
> LS1046A RDB Board
> LS1088A QDS Board
> LS1088A RDB Board
> Marvell Armada 3720 Development Board DB-88F3720-DDR3
> Marvell Armada 7040 DB board
> NVIDIA Tegra210 P2371 (P2530/P2595) reference design
> NVIDIA Tegra210 P2571 reference design
> Olimex A64-Olinuxino
> OrangePi Win/Win Plus
> OrangePi Zero Plus2
> Pine64
> Renesas Draak board based on r8a77995
> Renesas Eagle board based on r8a77970
> Renesas H3ULCB board based on r8a7795 ES2.0+
> Renesas M3ULCB board based on r8a7796
> Renesas Salvator-X board based on r8a7795 ES2.0+
> Renesas Salvator-X board based on r8a7796
> Renesas Salvator-X board based on r8a77965
> Rockchip PX5 EVB
> Rockchip RK3328 EVB
> SoCFPGA Stratix 10 SoCDK
> UniPhier LD11 Global Board (REF_LD11_GP)
> UniPhier LD11 Reference Board
> UniPhier LD20 Global Board (REF_LD20_GP)
> UniPhier LD20 Reference Board
> UniPhier PXs3 Reference Board
> Xunlong Orange Pi PC 2
> Xunlong Orange Pi Prime
> ZynqMP ZC1232 RevA
> ZynqMP ZC1254 RevA
> ZynqMP ZC1275 RevA
> ZynqMP zc1751-xm015-dc1 RevA
> ZynqMP zc1751-xm016-dc2 RevA
> ZynqMP zc1751-xm017-dc3 RevA
> ZynqMP zc1751-xm018-dc4
> ZynqMP zc1751-xm019-dc5 RevA
> ZynqMP ZCU100 RevC
> ZynqMP ZCU102 Rev1.0
> ZynqMP ZCU102 RevA
> ZynqMP ZCU102 RevB
> ZynqMP ZCU104 RevA
> ZynqMP ZCU106 RevA
> ZynqMP ZCU111 RevA

Hello,

many thanks for the patch.  Just to make sure that we don't run
into problems later on: do all these boards really use u-boot's
config_distro_bootcmd.h and thereby work properly with
bootscr.uboot-generic?

When looking at the defconfigs for several of these systems, I
see e.g. CONFIG_BOOTARGS settings that don't really match what I
would expect for systems using config_distro_bootcmd.h.
Three random examples:

- r8a77995_draak_defconfig:
  CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"

- ls1088ardb_sdcard_qspi_defconfig:
  CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
hugepagesz=2m hugepages=256"

- hikey_defconfig:
  CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#888171: ruby-riot: FTBFS on ruby2.5: expected "\"hope\"", not "hope"

[Juhani Numminen]

Control: forwarded -1 https://github.com/thumblemonks/riot/pull/54

On Tue, 23 Jan 2018 18:42:51 + "Chris West (Faux)"  wrote:
> Source: ruby-riot
> Version: 0.12.7-1
> Severity: important
> User: debian-r...@lists.debian.org
> Usertags: ruby2.5
> 
> Dear Maintainer,
> 
> This package fails to build against ruby2.5. Soon, there will
> be a transition to ruby2.5, and this package will FTBFS in sid.

The failure was also seen in Fedora[0], then forwarded upstream[1]
and is now also visible in upstream's Travis CI[2].

[0] https://bugzilla.redhat.com/1556401
[1] https://github.com/thumblemonks/riot/pull/54
[2] https://travis-ci.org/thumblemonks/riot/builds/358557113


Cheers,
Juhani

Bug#828218: Software::License Debian patches will be removed

[Dominique Dumont]

On vendredi 18 mai 2018 13:58:50 CEST you wrote:
>  I'll close it and create a new module
> (Software::LicenseUtils::More) that provide the Debian specific extensions.

Here's the first stab:

http://search.cpan.org/~ddumont/Software-LicenseMoreUtils-0.001/

or 

http://github.com/dod38fr/Software-LicenseMoreUtils

Feedback, ideas and patches are welcome

All the best

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Dmitry Shachnev]

On Sun, May 20, 2018 at 09:08:45PM +1000, Brian May wrote:
> Please feel free to go ahead. The only reason I didn't make this part of
> the DPMT is I was told this package (and similarly) mkdocs-bootswatch
> aren't Python packages and as a result don't meet the requirements for
> DPMT.

One more question: why do we need mkdocs-bootswatch? It currently is not
used by anything in sid, and I would like to avoid doing useless work.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#899202: llvm: Please enable the AVR backend

[Nicolas Braud-Santoni]

Package: llvm
Version: 1:6.0-41~exp5
Severity: wishlist
Control: tag -1 + buster sid

Hi,

Currently packaged versions of LLVM in testing and upwards are >= 4.0.0,
which introduced a new backend for the AVR architecture.

Please consider shipping it  :)


Best,

  nicoo


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

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

Versions of packages llvm depends on:
ii  llvm-6.0  1:6.0.1~+rc1-1~exp2
ii  llvm-runtime  1:6.0-41~exp5

llvm recommends no packages.

llvm suggests no packages.

-- no debconf information

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Russ Allbery]

Chris Lamb  writes:
> Russ,

>>  E: libmutter-2-dev: header-has-overly-generic-name 
>> usr/include/mutter/meta/util.h
>> 
>> I think this should only trigger on usr/include/util.h specifically, not
>> if the file is in any subdirectory.  Generic header names are only a
>> problem at the top level of the include hierarchy.

> But of course. Almost confused why you thought an explanation was needed ;)

You're right -- that was obvious.  Sorry!  :)  I should have just made a
patch instead.

-- 
Russ Allbery (r...@debian.org)   

Bug#899201: linux-image-4.16.0-1-amd64: Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'nvidia_stack_cache'

[Nicola Orrù]

Package: src:linux
Version: 4.16.5-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   Upgrade to kernel 4.16 via apt-get dist-upgrade

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

   added "slab_common.usercopy_fallback=Y" to grub kernel boot options
as suggested in a Manjaro forum with a similar issue, to no avail.

   * What was the outcome of this action?

   No difference

   * What outcome did you expect instead?

   dmesg kernel error to disappear - I am not sure of the long term
effects of the error. The module causing the issue is proprietary, but
it wasn't triggered on previous kernels.

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


-- Package-specific info:
** Version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64
root=UUID=5f909561-5300-4d92-b306-da826e04b195 ro quiet vga=0x034d
slab_common.usercopy_fallback=Y
usbhid.quirks=0x1B1C:0x1B36:0x0x2408

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[4.773106] EDAC amd64: ECC disabled in the BIOS or no ECC
capability, module will not load.
Either enable ECC checking or force module loading by
setting 'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[4.776615] snd_hda_codec_realtek hdaudioC1D0: autoconfig for
ALC1220: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
[4.776618] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[4.776620] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1
(0x1b/0x0/0x0/0x0/0x0)
[4.776621] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[4.776622] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x1e/0x0
[4.776623] snd_hda_codec_realtek hdaudioC1D0:inputs:
[4.776629] snd_hda_codec_realtek hdaudioC1D0:  Front Mic=0x19
[4.776630] snd_hda_codec_realtek hdaudioC1D0:  Rear Mic=0x18
[4.776632] snd_hda_codec_realtek hdaudioC1D0:  Line=0x1a
[4.790687] input: HD-Audio Generic Front Mic as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input11
[4.790741] input: HD-Audio Generic Rear Mic as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input12
[4.790772] input: HD-Audio Generic Line as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input13
[4.790814] input: HD-Audio Generic Line Out Front as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input14
[4.790861] input: HD-Audio Generic Line Out Surround as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input15
[4.790903] input: HD-Audio Generic Line Out CLFE as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input16
[4.791009] input: HD-Audio Generic Front Headphone as
/devices/pci:00/:00:08.1/:2a:00.3/sound/card1/input17
[4.827293] random: alsactl: uninitialized urandom read (4 bytes read)
[4.828083] random: crng init done
[5.403179] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
[5.533575] lp: driver loaded but no devices found
[5.538585] ppdev: user-space parallel port driver
[5.564031] nvidia-modeset: Loading NVIDIA Kernel Mode Setting
Driver for UNIX platforms  390.48  Wed Mar 21 23:48:34 PDT 2018
[5.570513] EXT4-fs (sdb3): mounted filesystem with ordered data
mode. Opts: (null)
[5.590641] [drm] [nvidia-drm] [GPU ID 0x2800] Loading driver
[5.590643] [drm] Initialized nvidia-drm 0.0.0 20160202 for
:28:00.0 on minor 0
[5.592564] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:03.1/:28:00.1/sound/card0/input18
[5.592611] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:03.1/:28:00.1/sound/card0/input19
[5.592653] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:03.1/:28:00.1/sound/card0/input20
[5.592702] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:03.1/:28:00.1/sound/card0/input21
[5.671501] audit: type=1400 audit(1526836359.720:2):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="libreoffice-xpdfimport" pid=1502 comm="apparmor_parser"
[5.671583] audit: type=1400 audit(1526836359.720:3):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="libreoffice-senddoc" pid=1500 comm="apparmor_parser"
[5.671842] audit: type=1400 audit(1526836359.720:4):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="libreoffice-oopslash" pid=1499 comm="apparmor_parser"
[5.672555] audit: type=1400 audit(1526836359.724:5):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/man" pid=1498 comm="apparmor_parser"
[5.672556] 

Bug#897537: tudu: FTBFS: ./configure: 394: ./configure: rmtest.c: not found

[Sven Joachim]

Control: reassign -1 acr 1.6.1-1

On 2018-05-15 14:42 +0200, meskio wrote:

> Quoting Sven Joachim (2018-05-06 21:50:57)
>> It seems to me this is a bug in acr 1.6.1-1.  The configure script
>> generated by it is clearly broken, and the same tudu version built
>> successfully with acr 1.2-1 back in June 2017.  Maybe the acr
>> maintainer can find out what went wrong here.
>
> I submited the bug upstream:
> https://github.com/radare/acr/issues/15
>
> I'll try to fix it myself.

Thanks, I can confirm that tudu builds with acr 1.6.2-1.  Reassigning
the bug to your package, will close it in a minute.

Cheers,
   Sven

Bug#899200: afterstep FTCBFS: does not pass --host to sub ./configure

[Helmut Grohne]

Source: afterstep
Version: 2.2.12-11.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

afterstep fails to cross build from source, because the subprojects
configured from the main ./configure are configured without --host. I.e.
the upstream build system fails to propagate --host. I hope that the
attached patch fixes the problem, but I was unable to test it, because
afterstep does not provide an easy way to build from source. Maybe you
can also make it build from source by default?

Helmut
--- afterstep-2.2.12.orig/autoconf/configure.in
+++ afterstep-2.2.12/autoconf/configure.in
@@ -314,6 +314,8 @@
 export FROM_AFTERSTEP_CONFIGURE
 
 _def_lib_conf_opts=" \
+	--build=${build_alias} \
+	--host=${host_alias} \
 	--prefix=${prefix} \
 	--exec-prefix=${exec_prefix} \
 	--bindir=${bindir} \

Bug#897516: Decreasing fail-under parameter helps passing the test

[Adrian Bunk]

Control: severity -1 serious

On Sun, May 20, 2018 at 01:56:57PM +0200, Andreas Tille wrote:
> Control: severity -1 important
>...

0.7-2 did FTBFS on the buildd, raising severity again:
https://buildd.debian.org/status/package.php?p=cram

> Kind regards
> 
>Andreas.
>...

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#899199: mark csh Multi-Arch: foreign

[Helmut Grohne]

Package: csh
Version: 20110502-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:ncbi-tools6

Like other shells (e.g. dash and bash), csh should likely be marked
Multi-Arch: foreign. The primary use is to execute it. If that turns out
to be wrong, we can still use Multi-Arch: allowed, but having it
(implicitly) marked Multi-Arch: no breaks e.g. cross building of
ncbi-tools6. That's not useful.

Helmut
diff --minimal -Nru csh-20110502/debian/changelog csh-20110502/debian/changelog
--- csh-20110502/debian/changelog   2017-08-28 11:46:44.0 +0200
+++ csh-20110502/debian/changelog   2018-05-20 19:01:10.0 +0200
@@ -1,3 +1,10 @@
+csh (20110502-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark csh Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 20 May 2018 19:01:10 +0200
+
 csh (20110502-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru csh-20110502/debian/control csh-20110502/debian/control
--- csh-20110502/debian/control 2017-08-28 11:24:24.0 +0200
+++ csh-20110502/debian/control 2018-05-20 19:01:08.0 +0200
@@ -7,6 +7,7 @@
 
 Package: csh
 Architecture: any
+Multi-Arch: foreign
 Provides: c-shell
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Shell with C-like syntax

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Vasudev Kamath]

Hi Antonio,

Antonio Terceiro  writes:

> Package: fonts-font-awesome
> Version: 5.0.10-1
> Severity: grave
>
> Font-Awesome version completely changed everything, and any web
> applications that use it are now broken unless they go through some
> manual intervention.
>
> https://fontawesome.com/how-to-use/upgrading-from-4
>
> As a maintainer of multiple packages that use Font-Awesome, it would
> have been nice to receive a heads up and be given some time to adapt.
> But instead, now everything is broken and every single web appliction
> package that uses Font-Awesome needs to be changed to cope with the
> changes.

Apologies for the problems created by this upload. I was not aware of
technical efforts involved due to this upgrade as I myself do not use
this font and maintainer only because of some historical reasons.

>
> I'm not sure how to move forward now. IMO either
>
> 1) revert the changes in fonts-font-awesome, and package the new release
> under a new name (e.g.  fonts-font-awesome-5)

Though it might temporarily be a solution I think in long run it will be
burden as font-awesome till 4 will be not maintained.

>
> or
>
> 2) revert the changes in fonts-font-awesome in unstable, upload the
> new release to experimental, and give people a few months to adapt.

I'm okay with this solution. I've currently fixed the broken links and
uploaded the fixes. If you would like more time to adapt to the version
5 of font, I can request its removal from unstable and re-upload old
version to unstable and then upload this new version to experimental.

Let me know if this works for you.

Cheers,
Vasudev

--

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Chris Lamb]

tags 899192 + pending
thanks

Russ,

>  E: libmutter-2-dev: header-has-overly-generic-name 
> usr/include/mutter/meta/util.h
> 
> I think this should only trigger on usr/include/util.h specifically, not
> if the file is in any subdirectory.  Generic header names are only a
> problem at the top level of the include hierarchy.

But of course. Almost confused why you thought an explanation was needed ;)

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/7cc105cbf3b46ff248faa74d56a86ba6f3af912e

  data/files/generic-header-files| 2 +-
  debian/changelog   | 4 
  t/tests/files-header-has-overly-generic-name/debian/debian/install | 1 +
  3 files changed, 6 insertions(+), 1 deletion(-)


Regards,

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

Bug#899198: openhpi FTCBFS: various configure.ac issues

[Helmut Grohne]

Source: openhpi
Version: 3.6.1-3.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 899152

openhpi fails to cross build from source for a number of reasons. The
first issue is that it determines sizeof int as "" during cross
compilation. configure.ac as a separate code path for cross compilation
and that code path is broken as it fails calling AC_CHECK_SIZEOF.

Then it fails finding libraries with pkg-config as it uses the build
architecture pkg-config rather than the host one. Using
PKG_PROG_PKG_CONFIG mostly fixes that. Except that configure.ac also
sets PKG_CONFIG_PATH in a few cases and that breaks pkg-config's cross
wrapper.

Finally the cross build fails the same way as a native build: #899152.

The attached patch fixes the cross issues mentioned above. Please
consider applying it.

Helmut
From: Helmut Grohne 
Subject: fix cross compilation

The OH_SET_SIZES macro relies on the usual autoconf sizeof cache variables
during cross compilation, but it never ensure that they are initialized.

pkg-config must be called with $ac_tool_prefix and PKG_PROG_PKG_CONFIG takes
care of that. Setting PKG_CONFIG_PATH breaks the pkg-config-cross-wrapper.
Don't do that.

Index: openhpi-3.6.1/acinclude.m4
===
--- openhpi-3.6.1.orig/acinclude.m4
+++ openhpi-3.6.1/acinclude.m4
@@ -22,30 +22,39 @@
 
 if test "x$cross_compiling" != "xno"; then
 if test "x$OH_SIZEOF_UCHAR" = x; then
+	AC_CHECK_SIZEOF([unsigned char])
 OH_SIZEOF_UCHAR=$ac_cv_sizeof_uchar
 fi
 if test "x$OH_SIZEOF_USHORT" = x; then
+	AC_CHECK_SIZEOF([unsigned short])
 OH_SIZEOF_USHORT=$ac_cv_sizeof_ushort
 fi
 if test "x$OH_SIZEOF_UINT" = x; then
+	AC_CHECK_SIZEOF([unsigned int])
 OH_SIZEOF_UINT=$ac_cv_sizeof_uint
 fi
 if test "x$OH_SIZEOF_CHAR" = x; then
+	AC_CHECK_SIZEOF([char])
 OH_SIZEOF_CHAR=$ac_cv_sizeof_char
 fi
 if test "x$OH_SIZEOF_SHORT" = x; then
+	AC_CHECK_SIZEOF([short])
 OH_SIZEOF_SHORT=$ac_cv_sizeof_short
 fi
 if test "x$OH_SIZEOF_INT" = x; then
+	AC_CHECK_SIZEOF([int])
 OH_SIZEOF_INT=$ac_cv_sizeof_int
 fi
 if test "x$OH_SIZEOF_LLONG" = x; then
+	AC_CHECK_SIZEOF([long long])
 OH_SIZEOF_LLONG=$ac_cv_sizeof_longlong
 fi
 if test "x$OH_SIZEOF_FLOAT" = x; then
+	AC_CHECK_SIZEOF([float])
 OH_SIZEOF_FLOAT=$ac_cv_sizeof_float
 fi
 if test "x$OH_SIZEOF_DOUBLE" = x; then
+	AC_CHECK_SIZEOF([double])
 OH_SIZEOF_DOUBLE=$ac_cv_sizeof_double
 fi
 else
Index: openhpi-3.6.1/configure.ac
===
--- openhpi-3.6.1.orig/configure.ac
+++ openhpi-3.6.1/configure.ac
@@ -85,9 +85,9 @@
 
 dnl Check for GLIB
 
-AC_CHECK_PROG([found_pkg_config],[pkg-config],[yes])
+PKG_PROG_PKG_CONFIG
 
-if test "x$found_pkg_config" != "xyes"; then
+if test "x$PKG_CONFIG" = "x"; then
 OH_CHECK_FAIL(pkg-config,pkg-config)
 fi
 PKG_CFG_SETPATH
@@ -103,7 +103,7 @@
 GTHREAD=gthread-2.0
 GMODULE=gmodule-2.0
 
-if pkg-config --atleast-version $GLIB_REQUIRED_VERSION $GLIB; then
+if $PKG_CONFIG --atleast-version $GLIB_REQUIRED_VERSION $GLIB; then
:
 else
AC_MSG_ERROR([
@@ -111,15 +111,15 @@
 *** GLIB is always available from ftp://ftp.gtk.org/.])
 fi
 
-exact_version=`pkg-config --modversion $GLIB`;
-GLIB_CFLAGS=`pkg-config --cflags $GLIB`
-GLIB_LIBS=`pkg-config --libs $GLIB`
-GLIB_ONLY_CFLAGS=`pkg-config --cflags $GLIB`
-GLIB_ONLY_LIBS=`pkg-config --libs $GLIB`
-GMODULE_ONLY_CFLAGS=`pkg-config --cflags $GMODULE`
-GMODULE_ONLY_LIBS=`pkg-config --libs $GMODULE`
-GTHREAD_CFLAGS=`pkg-config --cflags $GTHREAD`
-GTHREAD_LIBS=`pkg-config --libs $GTHREAD`
+exact_version=`$PKG_CONFIG --modversion $GLIB`;
+GLIB_CFLAGS=`$PKG_CONFIG --cflags $GLIB`
+GLIB_LIBS=`$PKG_CONFIG --libs $GLIB`
+GLIB_ONLY_CFLAGS=`$PKG_CONFIG --cflags $GLIB`
+GLIB_ONLY_LIBS=`$PKG_CONFIG --libs $GLIB`
+GMODULE_ONLY_CFLAGS=`$PKG_CONFIG --cflags $GMODULE`
+GMODULE_ONLY_LIBS=`$PKG_CONFIG --libs $GMODULE`
+GTHREAD_CFLAGS=`$PKG_CONFIG --cflags $GTHREAD`
+GTHREAD_LIBS=`$PKG_CONFIG --libs $GTHREAD`
 
 
 # On some versions of Solaris the pkg-config file for gthread-2.0 contains a
@@ -258,12 +258,12 @@
 dnl We really need to make ipmi enablement be contigent on OpenIPMI
 dnl
 
-if PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig pkg-config --atleast-version 1.4.20 OpenIPMI; then
+if $PKG_CONFIG --atleast-version 1.4.20 OpenIPMI; then
 have_openipmi=yes
 AC_CHECK_LIB([OpenIPMI], [ipmi_smi_setup_con], [have_openipmi=yes])
-OPENIPMI_CFLAGS=`PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig pkg-config --cflags OpenIPMI`
+OPENIPMI_CFLAGS=`$PKG_CONFIG --cflags OpenIPMI`
 AC_SUBST(OPENIPMI_CFLAGS)
-

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Dmitry Shachnev]

Hi Brian!

On Sun, May 20, 2018 at 09:08:45PM +1000, Brian May wrote:
> Please feel free to go ahead. The only reason I didn't make this part of
> the DPMT is I was told this package (and similarly) mkdocs-bootswatch
> aren't Python packages and as a result don't meet the requirements for
> DPMT.
>
> The source is on salsa. As a Debian developer, I believe you should have
> push access - let me know if you don't.
>
> I already tried to update both these packages, but IIRC got stuck trying
> to get lintian happy. I have pushed my changes to salsa.

There are bundled copies of bootstrap-3.3.7.min.{js,css}.

Bootstrap source is large so I don’t want to include it in missing-sources/.
Instead I would just repack the tarball without all the bundled stuff.

Will you mind if I do that? Also can I switch from git-dpm to gbp using
the DPMT workflow (https://wiki.debian.org/Python/GitPackagingPQ)?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#899129: error: 'char16_t' does not name a type; did you mean 'wchar_t'? (Was: Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2)

[Adrian Bunk]

Control: tags -1 - help moreinfo

On Sun, May 20, 2018 at 09:05:48AM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi,
> 
> the build log of prime-phylo[1] has:
> 
> ...
> cd /build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime && 
> /usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE -Dprime_phylo_EXPORTS 
> -I/build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
> -I/build/prime-phylo-1.0.11/src/cxx/libraries/prime 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/  
> lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx -I/usr/include/libxml2 
> -I/build/prime-phylo-1.0.11/src/cxx/libraries 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
> -I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
> -fdebug-prefix-map=/build/prime-phylo-1.0.11=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
> Wreorder -Wall -fexceptions -g -fPIC   -std=gnu++98 -o 
> CMakeFiles/prime-phylo.dir/TreeInputOutput.cc.o -c 
> /build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.cc
> In file included from /usr/include/unicode/utypes.h:38:0,
>  from /usr/include/unicode/ucnv_err.h:88,
>  from /usr/include/unicode/ucnv.h:52,
>  from /usr/include/libxml2/libxml/encoding.h:31,
>  from /usr/include/libxml2/libxml/parser.h:810,
>  from /usr/include/libxml2/libxml/globals.h:18,
>  from /usr/include/libxml2/libxml/threads.h:35,
>  from /usr/include/libxml2/libxml/xmlmemory.h:218,
>  from /usr/include/libxml2/libxml/tree.h:1307,
>  from 
> /build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.hh:9,
>  from 
> /build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.cc:1:
> /usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a 
> type; did you mean 'wchar_t'?
>  typedef char16_t UChar;
>  ^~~~
>  wchar_t
> In file included from /usr/include/unicode/utypes.h:39:0,
>  from /usr/include/unicode/ucnv_err.h:88,
>  from /usr/include/unicode/ucnv.h:52,
>  from /usr/include/libxml2/libxml/encoding.h:31,
>  from /usr/include/libxml2/libxml/parser.h:810,
>  from /usr/include/libxml2/libxml/globals.h:18,
>  from /usr/include/libxml2/libxml/threads.h:35,
>  from /usr/inclmake[3]: Entering directory 
> '/build/prime-phylo-1.0.11/obj-x86_64-linux-gnu'
> ...
> 
> and similar things.  Any idea how to fix this?

Remove fix-gcc-6.patch, instead of it add
  export DEB_CXXFLAGS_MAINT_APPEND = -fpermissive
to debian/rules.

> Kind regards
> 
>Andreas.
>...

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#894713: stretch-pu: apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

Hi,

On Sunday, 13 May 2018 19:15:22 CEST Stefan Fritsch wrote:
> On Tuesday, 3 April 2018 14:07:33 CEST Stefan Fritsch wrote:
> > I would like to do an upgrade of apache2 in stretch that upgrades the
> > complete mod_http2 and mod_proxy_http2 modules from the versions from
> > 2.4.25 to the versions from 2.4.33.
> > 
> > The reason is that the fix for CVE-2018-1302 [1] is difficult to
> > backport because it concerns a complex life-time issue of data
> > structures, the relevant code has changed greatly between 2.4.25 and
> > 2.4.33, and I am not familiar with the internals of mod_http2.  There
> > are other random segfaults [2] and other bugs [3] in stretch's mod_http2
> > that are reportedly fixed by newer mod_http2. Therefore, upgrading the
> > whole thing seems like the best solution to me. Do you agree with this
> > approach?
> 
> I have now prepared updated packages. The changelog diff is:


There is one complication: It turns out that in newer versions of apache2, 
mod_http2 does no longer support being used with mpm_prefork but only with 
mpm_worker and mpm_event. If loaded together with mpm_prefork, mod_http2 will 
log a message and refuse to serve HTTP/2, but HTTP/1.x continues to work.

As I don't see any other way to fix the open issues, I would still like to go 
ahead. But I will prepare a new package/diff with a NEWS.Debian entry that 
informs about this change.

Cheers,
Stefan

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Russ Allbery]

Simon McVittie  writes:

> The new check for header-has-overly-generic-name seems too sensitive:

>> E: libmutter-2-dev: header-has-overly-generic-name 
>> usr/include/mutter/meta/util.h

> This one is canonically included as  while compiling with
> `pkg-config --cflags libmutter-2`, which is just as well-namespaced as
> any other header. (Mutter headers are  for historical reasons:
> it's a descendant of the GNOME 2 window manager, Metacity.)

I think this should only trigger on usr/include/util.h specifically, not
if the file is in any subdirectory.  Generic header names are only a
problem at the top level of the include hierarchy.

-- 
Russ Allbery (r...@debian.org)   

Bug#899197: bolt FTBFS: bolt-enum-types.c:5:10: fatal error: bolt-enums.h: No such file or directory

[Helmut Grohne]

Source: bolt
Version: 0.3-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

bolt fails to build from source on unstable:

| dpkg-buildpackage: info: source package bolt
| dpkg-buildpackage: info: source version 0.3-3
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Jeremy Bicha 
|  dpkg-source --before-build bolt-0.3
| dpkg-buildpackage: info: host architecture amd64
|  fakeroot debian/rules clean
| dh clean
|dh_clean
|  debian/rules build
| dh build
|dh_update_autotools_config
|dh_autoreconf
|debian/rules override_dh_auto_configure
| make[1]: Entering directory '/<>'
| dh_auto_configure -- \
|   --libexecdir=/usr/lib/bolt \
|   -Dprivileged-group=sudo
|   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu 
--libexecdir=lib/x86_64-linux-gnu --libexecdir=/usr/lib/bolt 
-Dprivileged-group=sudo
| The Meson build system
| Version: 0.46.1
| Source dir: /<>
| Build dir: /<>/obj-x86_64-linux-gnu
| Build type: native build
| Project name: bolt
| Native C compiler: cc (gcc 7.3.0 "cc (Debian 7.3.0-19) 7.3.0")
| Appending CFLAGS from environment: '-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security'
| Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,-z,now -Wl,-z,defs 
-Wl,--as-needed'
| Appending CPPFLAGS from environment: '-Wdate-time -D_FORTIFY_SOURCE=2'
| Build machine cpu family: x86_64
| Build machine cpu: x86_64
| Compiler for C supports arguments -fstack-protector-strong: YES
| Compiler for C supports arguments -Waggregate-return: YES
| Compiler for C supports arguments -Wunused: YES
| Compiler for C supports arguments -Warray-bounds: YES
| Compiler for C supports arguments -Wcast-align: YES
| Compiler for C supports arguments -Wclobbered: YES
| Compiler for C supports arguments -Wdeclaration-after-statement: YES
| Compiler for C supports arguments -Wempty-body: YES
| Compiler for C supports arguments -Wformat=2: YES
| Compiler for C supports arguments -Wformat-nonliteral: YES
| Compiler for C supports arguments -Wformat-security: YES
| Compiler for C supports arguments -Wformat-signedness: YES
| Compiler for C supports arguments -Wignored-qualifiers: YES
| Compiler for C supports arguments -Wimplicit-function-declaration: YES
| Compiler for C supports arguments -Winit-self: YES
| Compiler for C supports arguments -Wmissing-declarations: YES
| Compiler for C supports arguments -Wmissing-format-attribute: YES
| Compiler for C supports arguments -Wmissing-include-dirs: YES
| Compiler for C supports arguments -Wmissing-noreturn: YES
| Compiler for C supports arguments -Wmissing-parameter-type: YES
| Compiler for C supports arguments -Wmissing-prototypes: YES
| Compiler for C supports arguments -Wnested-externs: YES
| Compiler for C supports arguments -Wno-discarded-qualifiers 
-Wdiscarded-qualifiers: YES
| Compiler for C supports arguments -Wno-missing-field-initializers 
-Wmissing-field-initializers: YES
| Compiler for C supports arguments -Wno-strict-aliasing -Wstrict-aliasing: YES
| Compiler for C supports arguments -Wno-suggest-attribute=format 
-Wsuggest-attribute=format: YES
| Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: 
YES
| Compiler for C supports arguments -Wold-style-definition: YES
| Compiler for C supports arguments -Woverride-init: YES
| Compiler for C supports arguments -Wpointer-arith: YES
| Compiler for C supports arguments -Wredundant-decls: YES
| Compiler for C supports arguments -Wreturn-type: YES
| Compiler for C supports arguments -Wshadow: YES
| Compiler for C supports arguments -Wsign-compare: YES
| Compiler for C supports arguments -Wstrict-aliasing: YES
| Compiler for C supports arguments -Wstrict-prototypes: YES
| Compiler for C supports arguments -Wtype-limits: YES
| Compiler for C supports arguments -Wundef: YES
| Compiler for C supports arguments -Wuninitialized: YES
| Compiler for C supports arguments -Wunused-but-set-variable: YES
| Compiler for C supports arguments -Wwrite-strings: YES
| Found pkg-config: /usr/bin/pkg-config (0.29)
| Native dependency glib-2.0 found: YES 2.56.1
| Native dependency gio-2.0 found: YES 2.56.1
| Native dependency libudev found: YES 238
| Native dependency gio-unix-2.0 found: YES 2.56.1
| Native dependency udev found: YES 238
| Native dependency polkit-gobject-1 found: YES 0.105
| Native dependency systemd found: YES 238
| Native dependency libsystemd found: YES 238
| Program git found: NO
| Program a2x found: YES (/usr/bin/a2x)
| Checking for function "explicit_bzero": YES
| Checking for function "getrandom": YES
| Configuring config.h using configuration
| Native dependency glib-2.0 found: YES 2.56.1
| Configuring org.freedesktop.bolt.service using configuration
| Configuring org.freedesktop.bolt.rules using configuration

Bug#898501: Broken symlinks

[Vasudev Kamath]

Hi all,

First of all sorry for mess I created. I made a silly mistake of not
updating the links file properly before upload. I'm rectifying it now
and will upload the fixed version ASAP.

Second I noted that from the bug report by Antonio that the usage
patterns have changed a lot between 4 and 5. Since I myself do not use
the font and maintain it only because of some historic reason I was not
aware of this. If you think I need to give people some time to adapt
then I can request for removal of current version from unstable and
upload old working version to unstable, and upload this new version to
experimental.

Please let me know what suits better for you. Once again apologies for
the problem created.

PS: If any one is interested in taking care of the font I'm more than
happy to hand over the mantle of maintainer, as I myself don't use this
font I might not be able to make justice for it.

Cheers,

Vasudev

--

Bug#899183: sub...@bugs.debian.org

[Markus Koschany]

Control: retitle -1 libpdfbox2-java:


Hello,

Am 20.05.2018 um 14:23 schrieb Martin Kittel:
> Package: libpdfbox2-java
> Version: 2.0.9-1
> Severity: important
> 
> Dear Maintainer,
> 
> I get the exception below when running my Java program using
> libpdfbox2-java. I tried running the program with different
> JREs (down to 1.7) but the error persists. I guess the problem is
> that libpdfbox2-java is compiled using Java 9. Java 9 seems to
> introduce a change that breaks things even when running with
> older JREs:
> 
> 'because in JDK9 ByteBuffer.flip() returns a ByteBuffer... It
>  used to return a Buffer in JDK8.'
> (see https://github.com/plasma-umass/doppio/issues/497 also
> for suggestions on how to fix this at build time)

thanks for the report. Unfortunately there is not much what we can do
here. I think it would be impractical to fix all packages by casting
ByteBuffer.flip to Buffer. By default we compile to source/target 1.7
but I can force -release 9 for libpdfbox2-java to make it clear that we
don't support older JREs in Buster. In fact we will release with OpenJDK
11 as the default JRE. If it works with an older runtime it is always a
bonus but isn't really supported by us.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#898231: RFS: budgie-extras/0.5.0-1

[Herbert Fortes]

Hi,

Em 08-05-2018 20:25, foss.freedom escreveu:

Package: sponsorship-requests
Severity: normal

   Dear mentors,

   I am looking for a sponsor for my package "budgie-extras"

  * Package name: budgie-extras
Version : 0.5.0-1
Upstream Author : Ubuntu Budgie Developers
  * URL : https://github.com/ubuntubudgie/budgie-extras
  * License : GPL-3+
Section : misc

   It builds those binary packages:



I did the upload.

[...]  

   May I request that this package be added to my debian maintainers
list of packages I'm allowed to look after (dak
fossfree...@ubuntu.com) ?


I can see that.

I will learn on how to give you a DM permission to budgie-extras.

Thanks for the package.



Regards,
Herbert

Bug#899196: RFS: fonts-myanmar/1.0-1 [ITP] -- please help me for upstream fonts pack

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors, maintainer, developer

  I am looking for a sponsor for my package "fonts-myanmar"

Its font pack for Myanmar aka Burma

* Package name: fonts-myanmar
  Version : 1.0-1
  Upstream Author : kokoye2007 
* URL : https://salsa.debian.org/kokoye2007-guest/fonts-myanmar
* License : gpl2
  Section : fonts

  It builds those binary packages:

 fonts-myanmar - ttf myanmar fonts:
 fonts-myanmar-angoun - myanmar fonts: angoun;
 fonts-myanmar-ayar - ttf myanmar fonts: ayar;
 fonts-myanmar-chatu - myanmar fonts: chatu;
 fonts-myanmar-chatulight - myanmar fonts: chatulight;
 fonts-myanmar-gantgaw - myanmar fonts: gantgaw;
 fonts-myanmar-khyay - myanmar fonts: khyay;
 fonts-myanmar-kuttar - myanmar fonts: kuttar;
 fonts-myanmar-mon - myanmar fonts: MON3 Anonta 1 ;
 fonts-myanmar-myanmar3 - ttf myanmar fonts: Myanmar3;
 fonts-myanmar-myanmarcensus - ttf myanmar fonts: MyanmarCensus;
 fonts-myanmar-myanmarsanspro - myanmar fonts: Myanmar Sans Pro;
 fonts-myanmar-namkhome - myanmar fonts: Namkhone;
 fonts-myanmar-nayone - myanmar fonts: nayone;
 fonts-myanmar-njaun - myanmar fonts: njaun;
 fonts-myanmar-pauklay - myanmar fonts: pauklay;
 fonts-myanmar-phetsot - myanmar fonts: phetsot;
 fonts-myanmar-phiksel - myanmar fonts: phiksel;
 fonts-myanmar-phikselsmooth - myanmar fonts: phikselsmooth;
 fonts-myanmar-ponenyet - myanmar fonts: ponenyet;
 fonts-myanmar-pyidaungsu - ttf myanmar fonts: Pyidaungsu;
 fonts-myanmar-sabae - myanmar fonts: sabae;
 fonts-myanmar-sagar - myanmar fonts: sagar;
 fonts-myanmar-sanpya - myanmar fonts: sanpya;
 fonts-myanmar-squarelight - myanmar fonts: squarelight;
 fonts-myanmar-tagu - myanmar fonts: tagu;
 fonts-myanmar-thuriya - myanmar fonts: thuriya;
 fonts-myanmar-unicode - ttf myanmar unicode fonts
 fonts-myanmar-waso - myanmar fonts: waso;
 fonts-myanmar-yinmar - myanmar fonts: yinmar;
 fonts-myanmar-zawgyi - ttf myanmar fonts: ZawgyiOne2008;

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

  https://mentors.debian.net/package/fonts-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_1.0-1.dsc

  More information about hello can be obtained from

  Changes since the last upload:
https://mentors.debian.net/package/fonts-myanmar

and

now using ubuntu ppa is kokoye2007

https://launchpad.net/ttf-burmese-fonts

https://launchpad.net/~kokoye2007/+archive/ubuntu/ppa/+files/fonts-myanmar_1.0-1_1.0-1ubuntu1.diff.gz



-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#899195: RFA: pidgin-encryption -- pidgin plugin that provides transparent encryption

[Leo Antunes]

Package: wnpp
Severity: normal

I request an adopter for the pidgin-encryption package. Package seems
abandoned upstream (last release 2010), has more well maintained
alternatives (pidgin-otr) and has a low pop-con score (currently ~600).

If no takers show up, I'll probably request removal in the not so
distant future.

The package description is:
 Provides transparent encryption to all protocols supported by Pidgin.
 Can be activated on a per user basis or even automatically detected.
 Uses a private/public key system based on Mozilla's NSS.

Bug#899194: python3-fusepy: Module renaming

[Andreas Schwarz]

Package: python3-fusepy
Version: 2.0.4-1
Severity: important

Dear Maintainer,

I just stumbled across a problem with module naming.

Outside Debian, the module "fusepy" is called fuse.py
https://pypi.org/project/fusepy/
https://github.com/terencehonles/fusepy/

However, this creates a name conflict with the module "fuse"
https://github.com/libfuse/python-fuse
which was resolved in the package by renaming fuse.py to fusepy.py, but this 
could result in scripts importing the wrong
module.

Such renaming should definitly be done upstream to be consistent with other 
distributions and especially PyPI.

This issue was introduced on 2017-02-02 with commit 
86cc02b7a9e32f33719979206fac22b11edc1d74

kind regards
Andreas Schwarz

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

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

Versions of packages python3-fusepy depends on:
ii  libfuse2  2.9.7-1
ii  python3   3.6.5-3

python3-fusepy recommends no packages.

python3-fusepy suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#898088: libbsd: diff for NMU version 0.8.7-1.1

[Ben Hutchings]

Control: tags 898088 + patch
Control: tags 898088 + pending

I made an NMU applying the OpenBSD patch for this issue.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.
diff -Nru libbsd-0.8.7/debian/changelog libbsd-0.8.7/debian/changelog
--- libbsd-0.8.7/debian/changelog	2018-01-13 17:32:01.0 +0100
+++ libbsd-0.8.7/debian/changelog	2018-05-20 16:45:30.0 +0200
@@ -1,3 +1,11 @@
+libbsd (0.8.7-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch Linux getrandom() usage to non-blocking mode, continuing to use
+fallback mechanims if unsuccessful. Closes: #898088
+
+ -- Ben Hutchings   Sun, 20 May 2018 16:45:30 +0200
+
 libbsd (0.8.7-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libbsd-0.8.7/debian/patches/series libbsd-0.8.7/debian/patches/series
--- libbsd-0.8.7/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libbsd-0.8.7/debian/patches/series	2018-05-20 16:43:25.0 +0200
@@ -0,0 +1 @@
+switch-linux-getrandom-usage-to-non-blocking-mode.patch
diff -Nru libbsd-0.8.7/debian/patches/switch-linux-getrandom-usage-to-non-blocking-mode.patch libbsd-0.8.7/debian/patches/switch-linux-getrandom-usage-to-non-blocking-mode.patch
--- libbsd-0.8.7/debian/patches/switch-linux-getrandom-usage-to-non-blocking-mode.patch	1970-01-01 01:00:00.0 +0100
+++ libbsd-0.8.7/debian/patches/switch-linux-getrandom-usage-to-non-blocking-mode.patch	2018-05-20 16:45:09.0 +0200
@@ -0,0 +1,54 @@
+From: b...@openbsd.org
+Date: Sat, 29 Apr 2017 18:43:31 +
+Subject: Switch Linux getrandom() usage to non-blocking mode, continuing to use fallback mechanims if unsuccessful.
+Origin: https://github.com/openbsd/src/commit/edb2eeb7da8494998d0073f8aaeb8478cee5e00b
+Bug-Debian: https://bugs.debian.org/898088
+
+The design of Linux getrandom is broken.  It has an
+uninitialized phase coupled with blocking behaviour, which
+is unacceptable from within a library at boot time without
+possible recovery.
+ok deraadt@ jsing@
+
+[Ben Hutchings: Adjusted filename, and dropped the RCS ID change]
+---
+--- a/src/getentropy_linux.c
 b/src/getentropy_linux.c
+@@ -97,13 +97,16 @@ getentropy(void *buf, size_t len)
+ 
+ #ifdef SYS_getrandom
+ 	/*
+-	 * Try descriptor-less getrandom()
++	 * Try descriptor-less getrandom(), in non-blocking mode.
++	 *
++	 * The design of Linux getrandom is broken.  It has an
++	 * uninitialized phase coupled with blocking behaviour, which
++	 * is unacceptable from within a library at boot time without
++	 * possible recovery. See http://bugs.python.org/issue26839#msg267745
+ 	 */
+ 	ret = getentropy_getrandom(buf, len);
+ 	if (ret != -1)
+ 		return (ret);
+-	if (errno != ENOSYS)
+-		return (-1);
+ #endif
+ 
+ 	/*
+@@ -157,7 +160,7 @@ getentropy(void *buf, size_t len)
+ 	 * - Do the best under the circumstances
+ 	 *
+ 	 * This code path exists to bring light to the issue that Linux
+-	 * does not provide a failsafe API for entropy collection.
++	 * still does not provide a failsafe API for entropy collection.
+ 	 *
+ 	 * We hope this demonstrates that Linux should either retain their
+ 	 * sysctl ABI, or consider providing a new failsafe API which
+@@ -200,7 +203,7 @@ getentropy_getrandom(void *buf, size_t l
+ 	if (len > 256)
+ 		return (-1);
+ 	do {
+-		ret = syscall(SYS_getrandom, buf, len, 0);
++		ret = syscall(SYS_getrandom, buf, len, GRND_NONBLOCK);
+ 	} while (ret == -1 && errno == EINTR);
+ 
+ 	if (ret != (int)len)


signature.asc
Description: PGP signature

Bug#899193: RFS: vagrant-hostmanager/1.8.8-1 [ITP #898996]

[Kienan Stewart]

Package: sponsorship-requests
Severity: wishlist

Dear menotrs,

I am looking for a sponsor for my package "vagrant-hostmanager":

 * Package name: vagrant-hostmanager
 * Version : 1.8.8-1
 * Upstream AUthor : Shawn Dahlen, Seth Reeser
 * URL : https://github.com/devopsgroup-io/vagrant-hostmanager
 * License : MPL-2.0
 * Section : ruby

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

https://mentors.debian.net/package/vagrant-hostmanager

Thanks,
Kienan

Bug#899192: lintian: header-has-overly-generic-name false positives on names merely containing util.h

[Simon McVittie]

Package: lintian
Version: 2.5.87
Severity: normal

The new check for header-has-overly-generic-name seems too sensitive:

> E: libmutter-2-dev: header-has-overly-generic-name 
> usr/include/mutter/meta/util.h

This one is canonically included as  while compiling with
`pkg-config --cflags libmutter-2`, which is just as well-namespaced as
any other header. (Mutter headers are  for historical reasons:
it's a descendant of the GNOME 2 window manager, Metacity.)

> E: libmutter-2-dev: header-has-overly-generic-name 
> usr/include/mutter/clutter-2/cally/cally-util.h
> E: libmutter-2-dev: header-has-overly-generic-name 
> usr/include/mutter/clutter-2/clutter/deprecated/clutter-util.h

Those are definitely not a problem - they can be accused of many things,
but insufficient namespacing is not among them :-)

Please drop the certainty for this tag, or make the regex tighter.

smcv

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

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

Versions of packages lintian depends on:
ii  binutils   2.30-20
ii  bzip2  1.0.6-8.1
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.33-2
ii  gettext0.19.8.1-6+b1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl0.99-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.69+repack-1
ii  man-db 2.8.3-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-5
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-20
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#899137: blhc: Reports missing flags on non-compile lines

[Simon Ruderich]

On Sat, May 19, 2018 at 07:57:26PM +0200, Kurt Roeckx wrote:
> Package: blhc
> Version: 0.07+20170817+gita232d32-0.1
>
> https://qa.debian.org/bls/packages/o/openssl.html currently
> reports among other things:
> dpkg-buildflags-missing CPPFLAGS 3 (of 1664), CFLAGS 1 (of 1662), LDFLAGS 2 
> (of 298) missing (amd64)
>
> When I download that file
> (https://buildd.debian.org/status/fetch.php?pkg=openssl=amd64=1.1.0h-3=1526644885=0),
> and run it myself, I get:
> CPPFLAGS missing (-D_FORTIFY_SOURCE=2): 0150 - 2e 4f 04 0c 0f d4 7c 07-11 
> 8a 14 ae ca cc b4 53   .O|S
> LDFLAGS missing (-Wl,-z,relro): 0150 - 2e 4f 04 0c 0f d4 7c 07-11 8a 14 
> ae ca cc b4 53   .O|S
> CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security): 0350 - 12 82 f0 da b8 82 57 4b-71 6a e1 8d 6e 
> ce cc 69   ..WKqj..n..i
> LDFLAGS missing (-Wl,-z,relro): 0350 - 12 82 f0 da b8 82 57 4b-71 6a e1 
> 8d 6e ce cc 69   ..WKqj..n..i
>
> Those are some debug output of the test suite, clearly nothing is
> being compiled on those lines.

Hello Kurt,

Thanks for the bug report. Fixed in 95af905 ("Don't treat
hexdumps which contain "cc" as compiler lines", 2018-05-20) [1].

The blhc maintainer seems to be busy so it may take a while to
get this into Debian. If you (or any other DD) have some time,
you could package the latest Git version which contains multiple
fixes and closes a few Debian bugs.

Regards
Simon

[1] 
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=95af90589fc9239baedfb30560fb69eff2c669d7
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature