Bug#960339: ITP: adios2 -- Adaptable IO system for simulations

[Kyle Edwards]

On 1/24/23 09:33, Drew Parsons wrote:

affects 960339 src:fenics-dolfinx
thanks

VTX support in dolfinx requires adios2


I worked on this a few years ago but never finished, check out 
https://gitlab.kitware.com/debian/adios2 to see the progress I made.


Kyle

Bug#1024641: Aptly does not support zstd compression

[Kyle Edwards]

On 11/22/22 12:12, Sébastien Delafond wrote:

This was fixed in 1.4.0+ds1-7, as per #1010465[fn:1]. Are you actually
saying this version, currently in sid, doesn't properly support zstd for
you? If so, how does it fail?


Now I see what happened. I tried to do this in Ubuntu 22.04, which 
failed due to being stuck at 1.4.0+ds1-6. I came to Sid to check the 
version, saw 1.4.0, and assumed the feature was still not present. It 
had not occurred to me that the feature might have been backported to 
1.4.0+ds1-7.


Either upgrading to Ubuntu 22.10 or manually backporting 1.4.0+ds1-7 to 
Ubuntu 22.04 should be sufficient for my needs. Thanks.



As for packaging 1.5.x, please see #1022720[fn:2].


Thanks for the info.

Kyle

Bug#1024641: Aptly does not support zstd compression

[Kyle Edwards]

Package: aptly
Version: 1.4.0+ds1-7

Aptly 1.4.0 does not support the zstd compression found in Ubuntu 22.04 
packages. Please upgrade Aptly to 1.5.0 to support the new zstd compression.

Bug#973392: cmake-data is not Multi-Arch: foreign

[Kyle Edwards]

Package: cmake-data
Version: 3.18.4-1
Severity: minor

The same cmake-data package can be used by cmake on any architecture. 
However, it is not marked it as "Multi-Arch: foreign", which makes it 
impossible to install a foreign-arch CMake on a multi-arch system (for 
example, installing i386 CMake on amd64).

Bug#973227: dh-cmake: FTBFS: AttributeError: 'Changelog' object has no attribute 'get_version'

[Kyle Edwards]

Thanks. Looks like I was accidentally using an undocumented method from 
python3-debian that got renamed. I have a working and fix and will ask 
my sponsor to upload it.

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

On 9/15/20 11:00 AM, Drew Parsons wrote:
Mind you, reading your README reminds me I probably want dh 
--buildsystem=cmake anyway, rather than dh --with cmake.


dh doesn't document its --buildsystem option properly. The dh man page 
documents --with but not --buildsystem (which gets mentioned only in 
an example). But that's not dh-cmake's fault!


You'll need both `--buildsystem=cmake` and one of `dh-sequence-cmake` 
(modern, preferable) or `--with cmake` (old, deprecated). 
`--buildsystem=cmake` is provided by Debhelper proper, and existed long 
before dh-cmake, while `--with cmake` and `dh-sequence-cmake` are 
provided by dh-cmake. They have different purposes. 
`--buildsystem=cmake` controls the configuration step, while 
`dh-sequence-cmake` controls the installation step.


Kyle

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

On 9/15/20 10:41 AM, Drew Parsons wrote:

Maybe it's a packaging and documentation bug?

There is no README file provided by the dh-cmake package, and no man 
page for /usr/bin/dh_cmake_install 


OK, yeah, this is definitely a documentation bug. The README is here:

https://gitlab.kitware.com/debian/dh-cmake/-/blob/master/README.md

I'll look at adding the README to the package, though I'd definitely 
like to get man pages written at some point.


Kyle

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

Hi Drew,

Thanks for trying dh-cmake.

On 9/15/20 9:54 AM, Drew Parsons wrote:

dh-cmake has been configured to fail if debian/dh-cmake.compat does
not exist.
You can also require `dh-cmake-compat (=1)` in your `Build-Depends` as a 
modern alternative. (You can even take out `dh-cmake`, since 
`dh-cmake-compat` implicitly depends on this.) I don't think the README 
even mentions the `dh-cmake.compat` file anymore.

I think it would work better if dh_cmake assumed version 1, unless
a different version is provided in debian/dh-cmake.compat.
I think requiring `dh-cmake-compat (=1)` is sufficiently lightweight, 
but if lots of people complain I may end up doing this.

i.e. dh --with cmake should just work (as dh_make version 1), without
having to provide an explicit debian/dh-cmake.compat


Please note that the `--with` argument is also outdated, the modern 
approach is to require `dh-sequence-cmake` in your `Build-Depends`.


Please let me know what you think.

Kyle

Bug#963615: ITP: jakarta-annotation-api -- Annotations for common semantic concepts in the Java SE and Jakarta EE platforms

[Kyle Edwards]

On Thu, 2020-06-25 at 22:19 +0200, Emmanuel Bourg wrote:
> I'm not sure to understand what bothers you. In this case the final
> version will be nearly identical. The JakartaEE APIs consist
> basically
> in the JavaEE versions that have been stable and in use for years
> with
> the base package renamed from 'javax' to 'jakarta'. I don't expect
> much
> surprise in the final version.

Speaking as one of the CMake developers, we sometimes make breaking
changes during our RC cycles, and don't freeze the interface until the
official .0 release. There's a reason our RCs don't typically go into
production distros, and there is the possibility that JakartaEE could
do the same thing.

However, the "experimental" repo does take RC packages. Perhaps
experimental would be a better place for this?

Kyle

Bug#960710: RFS: adios2/2.6.0-1 [ITP] -- ADIOS2 Adaptable IO system for simulations

[Kyle Edwards]

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

Dear mentors,

I am looking for a sponsor for my package "adios2":

 * Package name: adios2
   Version : 2.6.0-1
   Upstream Author : UT-BATTELLE, LLC
 * URL : https://github.com/ornladios/ADIOS2
 * License : Apache
 * Vcs : https://gitlab.kitware.com/debian/adios2
   Section : libs

It builds those binary packages:

  adios2-scripts - ADIOS2 Adaptable IO system for simulations - scripts
  adios2-serial-bin - ADIOS2 Adaptable IO system for simulations -
binary tools (serial)
  libadios2-serial-core - ADIOS2 Adaptable IO system for simulations -
core libraries (serial)
  libadios2-serial-core-dev - ADIOS2 Adaptable IO system for
simulations - core development files (serial)
  libadios2-serial-c - ADIOS2 Adaptable IO system for simulations - C
binding libraries (serial)
  libadios2-serial-c-dev - ADIOS2 Adaptable IO system for simulations -
C binding development files (serial)
  libadios2-serial-c++11 - ADIOS2 Adaptable IO system for simulations -
C++11 binding libraries (serial)
  libadios2-serial-c++11-dev - ADIOS2 Adaptable IO system for
simulations - C++11 binding development files (serial)
  libadios2-serial-fortran - ADIOS2 Adaptable IO system for simulations
- Fortran binding libraries (serial)
  libadios2-serial-fortran-dev - ADIOS2 Adaptable IO system for
simulations - Fortran binding development files (serial)
  python3-adios2-serial - ADIOS2 Adaptable IO system for simulations -
Python bindings (serial)
  adios2-openmpi-bin - ADIOS2 Adaptable IO system for simulations -
binary tools (OpenMPI)
  libadios2-openmpi-core - ADIOS2 Adaptable IO system for simulations -
core libraries (OpenMPI)
  libadios2-openmpi-core-dev - ADIOS2 Adaptable IO system for
simulations - core development files (OpenMPI)
  libadios2-openmpi-c - ADIOS2 Adaptable IO system for simulations - C
binding libraries (OpenMPI)
  libadios2-openmpi-c-dev - ADIOS2 Adaptable IO system for simulations
- C binding development files (OpenMPI)
  libadios2-openmpi-c++11 - ADIOS2 Adaptable IO system for simulations
- C++11 binding libraries (OpenMPI)
  libadios2-openmpi-c++11-dev - ADIOS2 Adaptable IO system for
simulations - C++11 binding development files (OpenMPI)
  libadios2-openmpi-fortran - ADIOS2 Adaptable IO system for
simulations - Fortran binding libraries (OpenMPI)
  libadios2-openmpi-fortran-dev - ADIOS2 Adaptable IO system for
simulations - Fortran binding development files (OpenMPI)
  python3-adios2-openmpi - ADIOS2 Adaptable IO system for simulations -
Python bindings (OpenMPI)

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

  https://gitlab.kitware.com/debian/adios2

Regards,

--
  Kyle Edwards

Bug#960609: Cannot install dh-python from Sid

[Kyle Edwards]

On Thu, 2020-05-14 at 17:14 +0200, Matthias Klose wrote:
> most likely a broken mirror.

Thanks for the insight. Whom should I contact to get this fixed?

Bug#960609: Cannot install dh-python from Sid

[Kyle Edwards]

Package: python3-all
Severity: serious

When attempting to install python3-all:

$ apt-get update
$ apt-get install dh-python

I get the following error:

The following packages have unmet dependencies:
 python3-all : Depends: python3-distutils (>= 3.8.2-1~) but it is not
installable
E: Unable to correct problems, you have held broken packages.

Bug#960462: RFS: libevpath/4.6.0-1 [ITP] -- Event transport middleware

[Kyle Edwards]

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

Dear mentors,

I am looking for a sponsor for my package "libevpath":

 * Package name: libevpath
   Version : 4.6.0-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/evpath
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libevpath
   Section : libs

It builds those binary packages:

  libevpath-dev - Event transport middleware - development files
  libevpath - Event transport middleware
  libevpath-enet - Event transport middleware - ENet transport module
  libevpath-libfabric - Event transport middleware - libfabric
transport module
  libevpath-ibverbs - Event transport middleware - ibverbs transport
module

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

  https://gitlab.kitware.com/debian/libevpath

Regards,

--
  Kyle Edwards

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Tue, 2020-05-12 at 14:35 +0300, Peter Pentchev wrote:
> Just a suggestion (somebody else already offered to sponsor the
> package):

Strange... I see the email in the debian-devel archives, but I never
received it. I wonder if it went to my spam folder. Thanks for the
heads up.

> could you take a look at Rules-Requires-Root in Policy 4.9.2
> and see if you couldn't set it in the Source control section?

Updated d/control with `Rules-Requires-Root: no`.

> Also, recent versions of debhelper introduced automatic handling of
> "--with something" if the dh-* package "Provides: dh-sequence-
> something"
> so that any packages that use it may build-depend (or B-D-I) on
> dh-sequence-something and debhelper will automatically assume "--with
> something", further simplifying the rules file.

Updated d/control to provide `dh-sequence-*`, and updated docs and
examples to suggest the modern approach.

Thanks!

Kyle

Bug#960339: ITP: adios2 -- ADIOS2 Adaptable IO system for simulations

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: adios2
  Version : 2.6.0
  Upstream Author : Oak Ridge National Laboratory
* URL : https://github.com/ornladios/ADIOS2
* License : Apache
  Programming Lang: C++
  Description : ADIOS2 Adaptable IO system for simulations

The Adaptable IO System (ADIOS) provides a simple, flexible way for
scientists to describe the data in their code that may need to be
written, read, or processed outside of the running simulation. By
providing an external to the code XML file describing the various
elements, their types, and how you wish to process them this run, the
routines in the host code (either Fortran or C) can transparently
change how they process the data.

Kyle

Bug#960337: ITP: libevpath -- Event transport middleware

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: libevpath
  Version : 4.6.0
  Upstream Author : Georgia Tech Research Corporation
* URL : https://github.com/GTkorvo/evpath
* License : BSD-3-clause
  Programming Lang: C
  Description : Event transport middleware

EVpath is an event transport middleware layer designed to allow for the
easy implementation of overlay networks, with active data processing,
routing and management at all points in the overlay.

Kyle

Bug#960336: RFS: gtkorvo-libenet/1.3.15-1 [ITP] -- Georgia Tech fork of libenet

[Kyle Edwards]

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

Dear mentors,

I am looking for a sponsor for my package "gtkorvo-libenet":

 * Package name: gtkorvo-libenet
   Version : 1.3.15-1
   Upstream Author : Lee Salzman
 * URL : https://github.com/GTkorvo/enet
 * License : other
 * Vcs : https://gitlab.kitware.com/debian/gtkorvo-libenet
   Section : libs

It builds those binary packages:

  gtkorvo-libenet-dev - Georgia Tech fork of libenet -
development files
  gtkorvo-libenet7 - Georgia Tech fork of libenet
  gtkorvo-libenet-doc - Georgia Tech fork of libenet -
documentation

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

  https://gitlab.kitware.com/debian/gtkorvo-libenet

Regards,

--
  Kyle Edwards

Bug#960320: ITP: gtkorvo-libenet -- Georgia Tech fork of libenet

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: gtkorvo-libenet
  Version : 1.3.15
  Upstream Author : Lee Salzman
* URL : https://github.com/GTkorvo/enet
* License : other
  Programming Lang: C
  Description : Georgia Tech fork of libenet

This is the Georgia Tech fork of libenet, which changes libenet in
several ways:

1. It builds with a CMake buildsystem and exports CMake package config
files in addition to pkgconfig files
2. It add a new function, enet_host_get_sock_fd(), to allow access to
the internal file descriptor
3. It supports dynamic sizing of the internal peer array
4. It changes the protocol to support 24-bit peer IDs

Kyle

Bug#960312: RFS: libffs/1.7.0-1 [ITP] -- Data communication library

[Kyle Edwards]

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

Dear mentors,

I am looking for a sponsor for my package "libffs":

 * Package name: libffs
   Version : 1.7.0-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/ffs
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libffs
   Section : libs

It builds those binary packages:

  libffs-dev - Data communication library -
development files
  libffs - Data communication library

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

  https://gitlab.kitware.com/debian/libffs

Regards,

--
  Kyle Edwards

Bug#960297:

[Kyle Edwards]

Oops - forgot to update the license. Should be BSD-3-clause.

Kyle

Bug#960297: ITP: ffs - Data communication library

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: libffs
  Version : 1.7
  Upstream Author : Georgia Tech Research Corporation
* URL : https://github.com/GTkorvo/ffs
* License : Artistic or GPL-1+
  Programming Lang: C
  Description : Data communication library

FFS is a middleware library for data communication, including
representation, processing and marshaling that preserves the
performance of traditional approaches while relaxing the requirement of
a priori knowledge and providing complex run-time flexibility.

Kyle

Bug#960059: RFS: libdill/2.4.2-1 [ITP] -- Just-in-time code generation library

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libdill":

 * Package name: libdill
   Version : 2.4.2-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/dill
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libdill
   Section : libs

It builds those binary packages:

  libdill-dev - Just-in-time code generation library -
development files
  libdill - Just-in-time code generation library

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

  https://gitlab.kitware.com/debian/libdill

Regards,

--
  Kyle Edwards

Bug#960055: ITP: libdill - Just-in-time code generation library

[Kyle Edwards]

Package: wnpp
Severity: wishlist
Owner: Kyle Edwards 

* Package name: libatl
  Version : 2.4.2
  Upstream Author : Georgia Tech Research Corporation
* URL : https://github.com/GTkorvo/dill
* License : BSD-3-clause
  Programming Lang: C
  Description : Just-in-time code generation library

DILL provides instruction-level code generation, register allocation
and simple optimizations for generating executable code directly into
memory regions for immediate use.

Kyle

Bug#960049: RFS: libatl/2.2.2-1 [ITP] -- Binary representation of lists of name/value pairs

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libatl":

 * Package name: libatl
   Version : 2.2.2-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/atl
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libatl
   Section : devel

It builds those binary packages:

  libatl-dev - Binary representation of lists of name/value pairs -
development files
  libatl - Binary representation of lists of name/value pairs
  libatl-bin - Binary representation of lists of name/value pairs -
command-line utilities

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

  https://gitlab.kitware.com/debian/libatl

Regards,

--
  Kyle Edwards

Bug#960034: ITP: libatl -- Binary representation of lists of name/value pairs

[Kyle Edwards]

Package: wnpp
Severity: wishlist
Owner: Kyle Edwards 

* Package name: libatl
  Version : 2.2.2
  Upstream Author : Georgia Tech Research Corporation
* URL : https://github.com/GTkorvo/atl
* License : BSD 3-clause
  Programming Lang: C
  Description : Binary representation of lists of name/value pairs

Libatl provides a library for the creation and manipulation of lists of
name/value pairs using an efficient binary representation.

Kyle

Bug#960027: ITP: dh-cmake -- Debhelper programs for CMake projects

[Kyle Edwards]

Package: wnpp
Severity: wishlist
Owner: Kyle Edwards 

* Package name    : dh-cmake
  Version         : 0.4
  Upstream Author : Kyle Edwards 
* URL             : https://gitlab.kitware.com/debian/dh-cmake
* License         : BSD 3-clause
  Programming Lang: Python
  Description     : Debhelper programs for CMake projects

dh-cmake provides a set of Debhelper utilities for building packages
that use advanced features of the CMake buildsystem, such as component
installation, CTest dashboard testing, and CPack dependency metadata.

Kyle

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Thu, 2020-05-07 at 20:47 +0800, Paul Wise wrote:
> On Thu, 2020-05-07 at 08:44 -0400, Kyle Edwards wrote:
> 
> > 
> > * Putting different CMake install components into different binary
> > packages (for example, putting the "Libraries" component into
> > libexample and the "Development" component into libexample-dev),
> > which
> > is easier than listing individual files
> Seems like this would be useful in debhelper itself.
> 
> > 
> > * Running the CMake project's test suite inside the build process
> > and
> > submitting the results to CDash (this is more useful for continuous
> > integration than production builds)
> Possibly this too.
> 
> > 
> > * Extracting CPack component metadata from the project and
> > incorporating that into the binary packages (for example, knowing
> > that
> > the "Development" component depends on the "Libraries" component
> > allows
> > libexample-dev to automatically depend on libexample)
> This too.

Arguably, yes. However, there is precedent for splitting off highly-
specialized Debhelper functionality into separate packages - see dh-
python and javahelper for example.

On top of that, since I am one of the upstream CMake developers, and
have put lots of CMake expertise into this project (we even made
changes to CMake itself to accommodate the CPack functionality), I
would prefer to maintain it myself rather than integrate it directly
into Debhelper.

Just my $.02 :)

Kyle

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Wed, 2020-05-06 at 23:49 +, Paul Wise wrote:
> How is this different to the existing cmake support in debhelper?
> 
> $ dpkg -L debhelper libdebhelper-perl  | grep -i cmake
> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm

The CMake buildsystem support in Debhelper is merely for *building* a
CMake project. This project augments that with additional
functionality, such as:

* Putting different CMake install components into different binary
packages (for example, putting the "Libraries" component into
libexample and the "Development" component into libexample-dev), which
is easier than listing individual files
* Running the CMake project's test suite inside the build process and
submitting the results to CDash (this is more useful for continuous
integration than production builds)
* Extracting CPack component metadata from the project and
incorporating that into the binary packages (for example, knowing that
the "Development" component depends on the "Libraries" component allows
libexample-dev to automatically depend on libexample)

See the project's readme for more details.

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-cmake":

 * Package name: dh-cmake
   Version : 0.4
   Upstream Author : Kyle Edwards 
 * URL : https://gitlab.kitware.com/debian/dh-cmake
 * License : BSD-3
 * Vcs : https://gitlab.kitware.com/debian/dh-cmake.git
   Section : devel

It builds those binary packages:

  dh-cmake - Debhelper programs for CMake projects

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

  https://gitlab.kitware.com/debian/dh-cmake

Regards,

--
  Kyle Edwards

Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]

[Kyle Edwards]

On Tue, 2019-08-06 at 21:05 +0200, Jonas Smedegaard wrote:
> Quoting Holger Wansing (2019-08-06 20:30:56)
> > 
> > [Adding debian-devel for a bigger audience]
> > 
> > 
> > Hi,
> > 
> > Holger Wansing  wrote:
> > > 
> > > Control: retitle -1 Replace grave accents/single quotes by
> > >  in gpl.xml
> > > 
> > > Samuel Thibault  wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > Changwoo Ryu, le jeu. 30 mai 2019 22:22:05 +0900, a ecrit:
> > > > > 
> > > > > In en/appendix/gpl.xml, ordinary double quotes (") and grave 
> > > > > accent character (`) are used for left single/double quotes.
> > > > > But 
> > > > > they are not correctly rendered in pdf.
> > > > > 
> > > > > See the English PDF at 
> > > > > https://www.debian.org/releases/stable/amd64/install.pdf.en. 
> > > > > Opening double quotes are rendered as right double quotes.
> > > > > And 
> > > > > grave accents are rendered just as grave accents, not a left 
> > > > > single quotes.
> > > > AIUI we should just replace "" and `' in the xml file with 
> > > > .
> > I was about to commit these changes, however it came to my mind if 
> > such changes to the GPL are allowed?
> > 
> > At least the English variant of the GPL is 'official' and is not to
> > be 
> > changed, so what about changing the quoting signs into  
> >  entities?
> Some very narrow interpretation of "not to be changed" disallow
> making 
> the text into a PDF at all, as it is not bit-by-bit identical.
> 
> GNU GPL-1, GPL-2, and GPL-3 however all permit "verbatim copies"
> which I 
> can only interpret as permitting changes to punctuation and
> whitespace.

IANAL. In my opinion, replacing punctuation with equivalent markup to
render correctly while still keeping the original wording is within the
spirit of GPL.

I think the best thing to do would be to contact the FSF and ask for
clarification. I'm sure they'd be happy to answer this.

Kyle

Bug#927891: CastXML 0.2 Update

[Kyle Edwards]

Package: castxml
Version: 0.1+git20180702-3
Severity: wishlist

CastXML upstream here. We recently released version 0.2 of CastXML (
https://github.com/CastXML/CastXML/releases/tag/v0.2.0 ), and I was
wondering if you guys could upgrade the Debian package. Thanks in
advance!

Kyle

Bug#902513:

[Kyle Edwards]

How soon can we expect to see 1.11 in unstable?

Bug#902185:

[Kyle Edwards]

On 06/26/2018 04:45 PM, Christopher Obbard wrote:

A reinstall of Debian on my main PC seemed to fix it.


I was able to fix it by booting into a recovery shell and running:

$ apt-get install systemd

which updates systemd to the latest version. I then ran

$ apt-get install

to finish reconfiguring udev.

YMMV.


My laptop boots to the WM but with no keyboard/mouse.


This is because udev is failing to start. A text-based recovery console 
will still work, and udev will work properly again once systemd is fully 
upgraded.



This is a grave bug.


Agreed.

Bug#902185: (no subject)

[Kyle Edwards]

This bug broke my Sid instance, I had to use a recovery shell to 
manually upgrade systemd because udev wouldn't start. This is a 
system-breaking bug.

Bug#896644: (no subject)

[Kyle Edwards]

This is happening to me too.

Bug#896002: debhelper: add support for CPack-style installs in CMake

[Kyle Edwards]

Package: debhelper
Version: 11.2.1
Severity: wishlist

CMake provides a mechanism for installing separate "components" into
separate installation directories - for example, headers, libraries, and
executables can all go into different installation prefixes. This is how
CPack generates separate .debs for these components in its .deb
generator. It would be nice if there was a way for Debhelper to take
advantage of this same mechanism so that binary packages can simply list
their respective CMake install components instead of listing files and
directories in debian/*.install.

I have implemented a rough sketch of this functionality as a Python
script, which you can find at
https://gitlab.kitware.com/debian/dh-cmake, but I would rather get this
into Debhelper proper if we can. I would write it myself, but I don't
know very much about Perl, and I'm not sure how I would write tests for
this new functionality.

Here is a detailed specification of how it should work:

Debian::Debhelper::Buildsystem::cmake should override the install
method. First it should call the parent method (to do the standard make
install/ninja install), and then look for files called
debian/.cpack-components (or debian/cpack-components for
the "main" package.) Each line in this file should be the name of a
CPack component which should be installed into the binary package. For
each of these components, the cmake buildsystem should run the following
command:

$ cd  && DESTDIR=/debian/ \
  cmake -DCOMPONENT= -P cmake_install.cmake

cmake_install.cmake is a file generated by CMake itself in the build
directory. It is used internally for make install/ninja install, and by
CPack for creating packages, but it can also be used by external
packaging software, such as Debhelper.

With this functionality, there should be no need to create
debian/*.install files, as the cpack-components functionality takes care
of all the installation.

Here is an example CMakeLists.txt file which demonstrates the component
functionality:

CMakeLists.txt
--
cmake_minimum_required(VERSION 3.5)
project(mypkg C)

include(GNUInstallDirs)

add_library(mypkg SHARED mypkg.c)
set_property(TARGET mypkg PROPERTY PUBLIC_HEADER mypkg.h)
target_include_directories(mypkg
  PUBLIC $
)

install(TARGETS mypkg
  LIBRARY
# CMAKE_INSTALL_LIBDIR is declared by GNUInstallDirs
DESTINATION "${CMAKE_INSTALL_LIBDIR}"
COMPONENT Libraries
  PUBLIC_HEADER
# Ditto for CMAKE_INSTALL_INCLUDEDIR
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
COMPONENT Development
)
--
end CMakeLists.txt

In the install() command, you can see that the target's LIBRARY is part
of the Libraries component, and its PUBLIC_HEADER is part of the
Development component. A CMake project can have as many install
components as you like, and they can have arbitrary names. For example,
a CMake project which produces multiple libraries could have components
called lib1-Libraries, lib1-Development, lib2-Libraries, and
lib2-Development. Components can also be grouped into component groups,
so lib1-Libraries and lib2-Libraries could be part of the Libraries
group.

Running DESTDIR=... cmake -DCOMPONENT=Development -P cmake_install.cmake
will only install the header files into DESTDIR. Likewise for
"Libraries" and the shared library. Then, the Debian packaging can have
the following files:

debian/libmypkg.cpack-components

Libraries

end debian/libmypkg.cpack-components

debian/libmypkg-dev.cpack-components

Development

end debian/libmypkg-dev.cpack-components

And everything will be installed into the proper binary package, even
though there are no debian/*.install files, because cmake_install.cmake
took care of all the installation.

Thank you for considering implementing this feature. Should you choose
to implement it, I would be happy to answer any CMake-related questions
you have which would help you.

Kyle

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

Kernel: Linux 4.15.0-2-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 debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf17
ii  dh-strip-nondeterminism  0.041-1
ii  dpkg 1.19.0.5
ii  dpkg-dev 1.19.0.5
ii  file 1:5.32-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.3-2
ii  perl 5.26.1-6
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  
pn  dwz  

-- no 

Bug#895044: [debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

[Kyle Edwards]

On 04/07/2018 01:30 AM, Niels Thykier wrote:

Thanks. :)

I am glad it worked. :)


My VTK package is currently building with cmake+ninja in sid, and 
leaving cmake+makefile in the dust. I love it. Thank you so much!



Mmm, the reason why make does not fail is that we have a crude (but
functional) way to tell if a makefile target exists.  But we do not have
that for ninja and honestly, I have no idea how we would make it either.

If you have an idea, I would be happy to look at implementing it.



There are a couple options I can think of:

1. $ ninja -n test - this does a dry run. If the "test" target exists 
then it succeeds (regardless of whether or not the real target would 
have succeeded), otherwise it fails. Simple and elegant.
2. You could also manually parse build.ninja and its included files. 
Admittedly not as simple, but Ninja is intended to be machine-readable 
and fast, so it might not be as bad as parsing a Makefile.
2a. Alternatively, start by simply grepping build.ninja for "^build[ 
\t]+test:" or something similar. It might not include every corner case, 
but it would be a good start (more than we have right now), and I don't 
think it would yield any false positives. CMake takes a similar approach 
in trying to find #defines in header files - see 
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L1291 
for an example.


Kyle

Bug#895044: [debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

[Kyle Edwards]

On 04/06/2018 04:15 PM, Niels Thykier wrote:

Control: tags -1 +patch

Kyle Edwards:

Package: debhelper
Version: 11.1.6
Severity: wishlist

Dear Maintainer,

Large projects which use CMake, such as VTK, take a long time to build
with the Makefile generator, and see significant build time improvements
when being built with the Ninja generator instead. Please consider
adding support for using the Ninja generator with CMake. Perhaps
something like:

$ dh --buildsystem=cmakeninja

I realize this may be tricky given how the buildsystems are implemented
in debhelper. I don't know much about Perl, but if it supports multiple
inheritance, would it be possible to make a class like "cmakebase" and
then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
then "makefile" and "ninja" respectively?


[...]

Ok, I have written a sample patch series (attached) that should make
debhelper support cmake with the ninja backend.

The chosen syntax is:

   dh  --buildsystem=cmake+ninja

A review and some testing would be appreciated.

Thanks,
~Niels



Just tested it, and I like it.

One thing I did notice is that if your project doesn't have tests, you 
have to turn on nocheck when switching to cmake+ninja, because the ninja 
buildsystem fails if no "test" target exists (the makefile buildsystem 
seems to silently ignore the failure.) I don't think this is a 
deal-breaker, but it is something to keep in mind when switching to 
ninja. Perhaps this could be filed as a separate bug.


Thank you for the quick response! I hope to see this in debhelper soon.

Kyle

Bug#895044: debhelper: add support for Ninja with CMake

[Kyle Edwards]

On 04/06/2018 10:18 AM, Niels Thykier wrote:

On Fri, 06 Apr 2018 10:08:24 -0400 Kyle Edwards
<kyle.edwa...@kitware.com> wrote:

Package: debhelper
Version: 11.1.6
Severity: wishlist

Dear Maintainer,

Large projects which use CMake, such as VTK, take a long time to build
with the Makefile generator, and see significant build time improvements
when being built with the Ninja generator instead. Please consider
adding support for using the Ninja generator with CMake. Perhaps
something like:

$ dh --buildsystem=cmakeninja

I realize this may be tricky given how the buildsystems are implemented
in debhelper. I don't know much about Perl, but if it supports multiple
inheritance, would it be possible to make a class like "cmakebase" and
then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
then "makefile" and "ninja" respectively?

[...]


Hi Kyle,

Thanks for the suggestion.


How will debhelper know whether cmake will generate a ninja.build and
not a Makefile?  Is that something debhelper decides 100% (via the -G)
parameter?  Or does the project specify a default in CMakeLists.txt and
debhelper should respect that or ...?

If debhelper decides it: How likely is it that a random CMake project
today will work with ninja instead of make?

Thanks,
~Niels


CMake developer here (I work at Kitware). The intention of CMake is to 
generate whatever buildsystem the developer feels most productive with, 
rather than what the project wants. By default, CMake generates 
Makefiles on Unix unless you give it a -G parameter. There's not a 
supported way to set the generator from within CMakeLists.txt, so yes, 
debhelper would be making that decision with -G. But even in a 
hypothetical scenario where a project is setting the generator from 
inside CMakeLists.txt (perhaps through some sort of unsupported hack), 
current debhelper wouldn't be able to handle that, because it's 
expecting a Makefile. If we added "cmakeninja", these hypothetical 
projects which are setting the generator to Ninja could be packaged with 
cmakeninja.


Ninja has been supported by CMake for a while, and most projects tend to 
handle it pretty well. That said, some projects are known to not work 
with Ninja. For those, they can continue to use the classic "cmake" 
buildsystem, which would still generate makefiles, and then projects 
that work with Ninja could use "cmakeninja" if they so desire. This 
change wouldn't impact existing projects unless they explicitly use 
"cmakeninja", because the "cmakeninja" check would come after the 
"cmake" check, which would succeed upon finding CMakeLists.txt.


Kyle

Bug#895044: debhelper: add support for Ninja with CMake

[Kyle Edwards]

Package: debhelper
Version: 11.1.6
Severity: wishlist

Dear Maintainer,

Large projects which use CMake, such as VTK, take a long time to build
with the Makefile generator, and see significant build time improvements
when being built with the Ninja generator instead. Please consider
adding support for using the Ninja generator with CMake. Perhaps
something like:

$ dh --buildsystem=cmakeninja

I realize this may be tricky given how the buildsystems are implemented
in debhelper. I don't know much about Perl, but if it supports multiple
inheritance, would it be possible to make a class like "cmakebase" and
then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
then "makefile" and "ninja" respectively?


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

Kernel: Linux 4.15.0-2-amd64 (SMP w/1 CPU core)
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 debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf17
ii  dh-strip-nondeterminism  0.040-1
ii  dpkg 1.19.0.5
ii  dpkg-dev 1.19.0.5
ii  file 1:5.32-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.2-1
ii  perl 5.26.1-5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  
pn  dwz  

-- no debconf information

Bug#894165: libadios-bin: adios_config -v returns an empty string

[Kyle Edwards]

Package: libadios-bin
Version: 1.13.0-2
Severity: normal

Dear Maintainer,

While attempting to build VTK on Debian, it failed to find libadios due
to a problem with adios_config: it does not return a version string.
Looking through the adios_config script, I see:

v) echo "$VERSIONSTRING"; exit 0;;

But it doesn't look like this value gets set anywhere in the file.
Please fix this so that software that checks the adios version can find
it.


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

Kernel: Linux 4.15.0-2-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 libadios-bin depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-2
ii  libglib2.0-0 2.56.0-4
ii  libhdf5-100  1.10.0-patch1+docs-4
ii  libhdf5-openmpi-100  1.10.0-patch1+docs-4
ii  libibverbs1  17.1-1
ii  libnetcdf13  1:4.6.1-1
ii  libopenmpi2  2.1.1-8
ii  libsz2   1.0.2-1
ii  python   2.7.14-4
ii  python2.72.7.14-7
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libadios-bin recommends:
ii  libadios-dev  1.13.0-2

libadios-bin suggests no packages.

-- no debconf information

Bug#893921: libharu: add support for free-form triangle shading objects

[Kyle Edwards]

We have not submitted this patch to any other distros, and none that we 
know of have included it (I don't see it in Ubuntu or RedHat.) Would it 
be acceptable for us to create a "For Debian" branch on our Gitlab 
libharu repository so you can pull from that?



On 03/23/2018 03:41 PM, Johan Van de Wauw wrote:

Pull request with discussion here:
https://github.com/libharu/libharu/pull/157

Has this been implemented by other distro's?

If kitware can support VTK, perhaps they can invest some time in 
proposing a new release with some of the other pull requests? I think 
this is a better way forward for the community than having maintainers 
of different distro's having to add patches to support features.


On Fri, Mar 23, 2018 at 8:19 PM, Kyle Edwards 
<kyle.edwa...@kitware.com <mailto:kyle.edwa...@kitware.com>> wrote:


Source: libharu
Severity: wishlist
Tags: patch

Dear Maintainer,

I am working on an official Kitware-supported Debian/Ubuntu
package for
the upcoming VTK 9. We are using a custom shading feature developed
in-house for libharu. We have submitted our changes upstream, but the
project has been abandoned and the patch will most likely never be
accepted. Please backport the included patch so that we can bring
VTK 9
to Debian. Thank you for your support.


***
patches/0001-Add-support-for-free-form-triangle-Shading-objects.patch
From 9e8ba2f5453552909e52fde5ec30856004a616d0 Mon Sep 17 00:00:00 2001
From: "David C. Lonie" <david.lo...@kitware.com
<mailto:david.lo...@kitware.com>>
Date: Wed, 10 May 2017 11:07:28 -0400
Subject: [PATCH] Add support for free-form triangle Shading objects.

---
 include/hpdf.h           |  24 -
 include/hpdf_error.h     |   3 +
 include/hpdf_objects.h   |   2 +
 include/hpdf_pages.h     |   5 +
 include/hpdf_types.h     |  14 +++
 src/CMakeLists.txt       |   1 +
 src/hpdf_page_operator.c |  31 +++
 src/hpdf_pages.c         |  55 ++-
 src/hpdf_shading.c       | 231
+++
 9 files changed, 362 insertions(+), 4 deletions(-)
 create mode 100644 src/hpdf_shading.c

diff --git a/include/hpdf.h b/include/hpdf.h
index e369f67..40e3c41 100644
--- a/include/hpdf.h
+++ b/include/hpdf.h
@@ -77,6 +77,7 @@ typedef HPDF_HANDLE   HPDF_Dict;
 typedef HPDF_HANDLE   HPDF_EmbeddedFile;
 typedef HPDF_HANDLE   HPDF_OutputIntent;
 typedef HPDF_HANDLE   HPDF_Xref;
+typedef HPDF_HANDLE   HPDF_Shading;

 #else

@@ -1171,6 +1172,11 @@ HPDF_EXPORT(HPDF_STATUS)
 HPDF_Page_SetExtGState  (HPDF_Page        page,
                          HPDF_ExtGState   ext_gstate);

+/* sh */
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Page_SetShading  (HPDF_Page    page,
+                       HPDF_Shading shading);
+

 /*--- Special graphic state operator
--*/

@@ -1450,7 +1456,23 @@ HPDF_Page_SetCMYKStroke  (HPDF_Page page,

 /*--- Shading patterns
---*/

-/* sh --not implemented yet */
+/* Notes for docs:
+ * - ShadingType must be HPDF_SHADING_FREE_FORM_TRIANGLE_MESH
(the only
+ *   defined option...)
+ * - colorSpace must be HPDF_CS_DEVICE_RGB for now.
+ */
+HPDF_EXPORT(HPDF_Shading)
+HPDF_Shading_New  (HPDF_Doc         pdf,
+                   HPDF_ShadingType type,
+                   HPDF_ColorSpace  colorSpace,
+                   HPDF_REAL xMin, HPDF_REAL xMax,
+                   HPDF_REAL yMin, HPDF_REAL yMax);
+
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Shading_AddVertexRGB(HPDF_Shading shading,
+                         
HPDF_Shading_FreeFormTriangleMeshEdgeFlag edgeFlag,
+                          HPDF_REAL x, HPDF_REAL y,
+                          HPDF_UINT8 r, HPDF_UINT8 g, HPDF_UINT8 b);

 /*--- In-line images
-*/

diff --git a/include/hpdf_error.h b/include/hpdf_error.h
index b04e2cd..ef4fa61 100644
--- a/include/hpdf_error.h
+++ b/include/hpdf_error.h
@@ -145,6 +145,9 @@ extern "C" {
 #define HPDF_INVALID_U3D_DATA                     0x1083
 #define HPDF_NAME_CANNOT_GET_NAMES                0x1084
 #define HPDF_INVALID_ICC_COMPONENT_NUM            0x1085
+/*                                                0x1086 */
+/*                                                0x1087 */
+#define HPDF_INVALID_SHADING_TYPE                 0x1088

 
/*---*/

diff --git a/include/hpdf_objects.h b/include/hpdf_objects.h
index 525adda..b16de02 100644
--- a/include/hpdf_objects.h
+++ b/include/hpdf_objects.h
@@ -61,6 +61,7 @@ extern "C" {

Bug#893921: libharu: add support for free-form triangle shading objects

[Kyle Edwards]

Source: libharu
Severity: wishlist
Tags: patch

Dear Maintainer,

I am working on an official Kitware-supported Debian/Ubuntu package for
the upcoming VTK 9. We are using a custom shading feature developed
in-house for libharu. We have submitted our changes upstream, but the
project has been abandoned and the patch will most likely never be
accepted. Please backport the included patch so that we can bring VTK 9
to Debian. Thank you for your support.


*** patches/0001-Add-support-for-free-form-triangle-Shading-objects.patch
>From 9e8ba2f5453552909e52fde5ec30856004a616d0 Mon Sep 17 00:00:00 2001
From: "David C. Lonie" 
Date: Wed, 10 May 2017 11:07:28 -0400
Subject: [PATCH] Add support for free-form triangle Shading objects.

---
 include/hpdf.h   |  24 -
 include/hpdf_error.h |   3 +
 include/hpdf_objects.h   |   2 +
 include/hpdf_pages.h |   5 +
 include/hpdf_types.h |  14 +++
 src/CMakeLists.txt   |   1 +
 src/hpdf_page_operator.c |  31 +++
 src/hpdf_pages.c |  55 ++-
 src/hpdf_shading.c   | 231 +++
 9 files changed, 362 insertions(+), 4 deletions(-)
 create mode 100644 src/hpdf_shading.c

diff --git a/include/hpdf.h b/include/hpdf.h
index e369f67..40e3c41 100644
--- a/include/hpdf.h
+++ b/include/hpdf.h
@@ -77,6 +77,7 @@ typedef HPDF_HANDLE   HPDF_Dict;
 typedef HPDF_HANDLE   HPDF_EmbeddedFile;
 typedef HPDF_HANDLE   HPDF_OutputIntent;
 typedef HPDF_HANDLE   HPDF_Xref;
+typedef HPDF_HANDLE   HPDF_Shading;
 
 #else
 
@@ -1171,6 +1172,11 @@ HPDF_EXPORT(HPDF_STATUS)
 HPDF_Page_SetExtGState  (HPDF_Pagepage,
  HPDF_ExtGState   ext_gstate);
 
+/* sh */
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Page_SetShading  (HPDF_Pagepage,
+   HPDF_Shading shading);
+
 
 /*--- Special graphic state operator --*/
 
@@ -1450,7 +1456,23 @@ HPDF_Page_SetCMYKStroke  (HPDF_Page  page,
 
 /*--- Shading patterns ---*/
 
-/* sh --not implemented yet */
+/* Notes for docs:
+ * - ShadingType must be HPDF_SHADING_FREE_FORM_TRIANGLE_MESH (the only
+ *   defined option...)
+ * - colorSpace must be HPDF_CS_DEVICE_RGB for now.
+ */
+HPDF_EXPORT(HPDF_Shading)
+HPDF_Shading_New  (HPDF_Doc pdf,
+   HPDF_ShadingType type,
+   HPDF_ColorSpace  colorSpace,
+   HPDF_REAL xMin, HPDF_REAL xMax,
+   HPDF_REAL yMin, HPDF_REAL yMax);
+
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Shading_AddVertexRGB(HPDF_Shading shading,
+  HPDF_Shading_FreeFormTriangleMeshEdgeFlag edgeFlag,
+  HPDF_REAL x, HPDF_REAL y,
+  HPDF_UINT8 r, HPDF_UINT8 g, HPDF_UINT8 b);
 
 /*--- In-line images -*/
 
diff --git a/include/hpdf_error.h b/include/hpdf_error.h
index b04e2cd..ef4fa61 100644
--- a/include/hpdf_error.h
+++ b/include/hpdf_error.h
@@ -145,6 +145,9 @@ extern "C" {
 #define HPDF_INVALID_U3D_DATA 0x1083
 #define HPDF_NAME_CANNOT_GET_NAMES0x1084
 #define HPDF_INVALID_ICC_COMPONENT_NUM0x1085
+/*0x1086 */
+/*0x1087 */
+#define HPDF_INVALID_SHADING_TYPE 0x1088
 
 /*---*/
 
diff --git a/include/hpdf_objects.h b/include/hpdf_objects.h
index 525adda..b16de02 100644
--- a/include/hpdf_objects.h
+++ b/include/hpdf_objects.h
@@ -61,6 +61,7 @@ extern "C" {
 #define  HPDF_OSUBCLASS_EXT_GSTATE_R  0x0B00  /* read only object */
 #define  HPDF_OSUBCLASS_NAMEDICT  0x0C00
 #define  HPDF_OSUBCLASS_NAMETREE  0x0D00
+#define  HPDF_OSUBCLASS_SHADING   0x0E00
 
 
 
@@ -595,6 +596,7 @@ typedef HPDF_Array HPDF_Destination;
 typedef HPDF_Dict  HPDF_U3D;
 typedef HPDF_Dict  HPDF_OutputIntent;
 typedef HPDF_Dict  HPDF_JavaScript;
+typedef HPDF_Dict  HPDF_Shading;
 
 #ifdef __cplusplus
 }
diff --git a/include/hpdf_pages.h b/include/hpdf_pages.h
index 44b816c..60b1d84 100644
--- a/include/hpdf_pages.h
+++ b/include/hpdf_pages.h
@@ -55,6 +55,7 @@ typedef struct _HPDF_PageAttr_Rec {
 HPDF_Dict  fonts;
 HPDF_Dict  xobjects;
 HPDF_Dict  ext_gstates;
+HPDF_Dict  shadings;
 HPDF_GStategstate;
 HPDF_Point str_pos;
 HPDF_Point cur_pos;
@@ -101,6 +102,10 @@ const char*
 HPDF_Page_GetExtGStateName  (HPDF_Page   page,
  HPDF_ExtGState  gstate);
 
+const char*
+HPDF_Page_GetShadingName  (HPDF_Pagepage,
+   HPDF_Shading shading);
+
 
 HPDF_Box
 HPDF_Page_GetMediaBox  (HPDF_Pagepage);
diff --git a/include/hpdf_types.h b/include/hpdf_types.h
index 8b3e0a8..a2e2157 100644
--- a/include/hpdf_types.h

Bug#893869: libgl2ps1.4: please pull latest version for VTK support

[Kyle Edwards]

Package: libgl2ps1.4
Version: 1.4.0+dfsg1-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

New versions of VTK use new features from upstream GL2PS:

- 2b7018cc - Add support for text alignment in PDF documents.
- f3417eb9 - Stabilize depth sort to ensure consistent results.

As part of my effort to package the upcoming VTK 9 into Debian, we will need
the latest version of GL2PS with these features. Please pull the latest
upstream, thank you.


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

Kernel: Linux 4.15.0-1-amd64 (SMP w/1 CPU core)
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 libgl2ps1.4 depends on:
ii  libc6   2.27-2
ii  libgl1  1.0.0-2

libgl2ps1.4 recommends no packages.

libgl2ps1.4 suggests no packages.

-- no debconf information