Bug#1078740: ITP: qatzip -- Compression Library accelerated by Intel® QuickAssist Technology

[Colin Ian King]

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com

* Package name: qatzip
  Version : 1.2.0
  Upstream Contact: xinghong.c...@intel.com
* URL : https://github.com/intel/QATzip
* License : BSD
  Programming Lang: C
  Description : Compression Library accelerated by Intel® QuickAssist 
Technology

Intel QuickAssist Technology (Intel QAT) provides hardware acceleration
for offloading security, authentication and compression services from the
CPU, thus significantly increasing the performance and efficiency of
standard platform solutions.

Its services include symmetric encryption and authentication,
asymmetric encryption, digital signatures, RSA, DH and ECC, and
lossless data compression.
This package provides user space libraries that allow access to
Intel QuickAssist devices and expose the Intel QuickAssist APIs.

This package is part of the Intel QAT family of user space libraries
and compliments the QAT related qatlib and ipp-crypto packages.

See also: See also: https://wiki.debian.org/QAT

I intend to maintain this much like other Intel related Debian packages
that I maintain, such as tracking recent releases, checking the code
for any security issues and programming issues using static analysis
tools and contributing to the upstream project with any fixes I make
during as I support this package.

Sincerely,
 
Colin Ian King

Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-08-15

[Phil Wyett]

Dear all DDs,

Below is the link to the page of currently "confirmed" being in good order
packages that are awaiting a DD review and possible upload. If DDs could
spare the time to pick up a package or two and finish off the package mentor
process it would be greatly appreciated.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests

Please check that another DD is not already involved in the package.

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--








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

Bug#1078744: ITP: qatengine -- Intel® QuickAssist Technology OpenSSL* Engine

[Colin Ian King]

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 
X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com

* Package name: qatengine
  Version : 1.6.1
  Upstream Contact: Yogaraj Alamenda 
* URL : https://github.com/intel/QAT_Engine
* License : BSD-3-Clause, GPL-2, GPL-3, MIT
  Programming Lang: C
  Description : Intel® QuickAssist Technology OpenSSL* Engine

The QAT_Engine offers two separate internal entities by which acceleration
can be performed. It supports the ability to accelerate from the stand
OpenSSL* to basic Intel instruction set, to either Hardware acceleration
path (via the qat_hw path) or via the optimized SW path (qat_sw lib).

This package is part of the Intel QAT family of user space libraries
and compliments the QAT related qatlib and ipp-crypto packages.

See also: See also: https://wiki.debian.org/QAT

I intend to maintain this much like other Intel related Debian packages
that I maintain, such as tracking recent releases, checking the code
for any security issues and programming issues using static analysis
tools and contributing to the upstream project with any fixes I make
as I support this package.

Sincerely,

Colin Ian King

Re: lintian.debian.org off ?

[Nicolas Peugnet]

On 08/08/2024 8:40 PM, Bastien Roucariès wrote:

Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :

Hi all,

Pierre-Elliott Bécue  on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen  wrote on 27/09/2023 at 06:35:07+0200:


Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA
and Lintian maintainers) if this option is fine with everyone.


I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?


Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a
Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.


I sent the following email in reply to Bug#1042428 but I didn't see it
was archived, so I repost it here:


As I just recently started making Debian packages, I clicked multiple times on links 
to  that led me to a dead end, for instance from 
mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal 
output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is 
not a good option, because as I understand it, they only were intended to show 
the extended explanation for each tag. Having the list of all the affected 
packages in this page it not helpful, and it makes the pages very slow to load 
(and to produce).

So instead I thought that it would be quite easy to generate a static website 
that would be very fast to generate once, and then to serve and load. So I made 
my own implementation that generates a website that could be directly uploaded 
to lintian.debian.org, as it follows strictly the previous URL structure (I 
also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

   

For instance the link above translates to:

   

And here are the sources:

   

It is not meant to replace the corresponding UDD link, in fact I added a link 
to it in the page of each tag, to see all the affected packages. But I think it 
is better to first arrive on a very fast to load page that simply explains the 
tag, and then be able to follow a link to see the list of affected packages.


What will be wonderfull is to retrieve number of package affected and do a svg 
graph along time... Using a static script

nicolas did you contact the the infrasture team ?


Not yet, I wanted to request feedback on my proposal beforehand.
I just added debian-ad...@lists.debian.org in CC, I hope it was the 
right thing to do.



Please telle me what you think about it and if you think it can be uploaded to 
lintian.debian.org?


In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: .
So, do you think it could be used to make the lintian.debian.org website
back up?

P.S. I'm not subscribed to this list, so please CC me.

Regards

--
Nicolas Peugnet

Re: Intent to MBF: move from fuse to fuse3

[Stephen Kitt]

Hi,

On Tue, 13 Aug 2024 20:02:48 +0200, Chris Hofstaedtler 
wrote:
> fuse (2.x) is long obsolete, yet we still have a long tail of packages
> (Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
> IMO we should get packages off fuse.
> 
> Below is my proposed MBF wording, and a dd-list.
> 
> Chris
> 
> ---
> 
> Subject: SOURCE: move from fuse to fuse3
> 
> Source: SOURCE
> Version: VERSION
> Severity: normal
> 
> Dear Maintainer,
> 
> your package currently (Build-)Depends on fuse - that is
> fuse 2.x. A newer version of fuse, fuse3, is available
> since at least buster.
> 
> fuse (2.x) and fuse3 are not co-installable. On a typical
> Debian Desktop install, fuse3 is installed, and fuse 2.x
> cannot be installed.
> 
> This effect can be observed in the popcon graphs:
> https://qa.debian.org/popcon.php?package=fuse
> https://qa.debian.org/popcon.php?package=fuse3
> 
> Please migrate your package to fuse3, so our users can
> actually use it, and we can remove fuse 2.x in forky.

There are two separate concerns here: the fuse binary package used to provide
fusermount etc., and the library used by FUSE programs.

fuse and fuse3 are not co-installable, but that only affects fusermount and
co. libfuse2 and libfuse3 are co-installable.

This means that packages build-depending on libfuse-dev can produce binary
packages usable with fuse3; see for example loggedfs’s debian/control:

[…]
Build-Depends:
 debhelper-compat (= 13),
 libeasyloggingpp-dev,
 libfuse-dev,
 libpcre2-dev,
 libxml2-dev,
[…]
Depends: fuse (<< 3) | fuse3 (>= 3.10.1-3), ${misc:Depends}, ${shlibs:Depends}


I have a number of libfuse2-based packages running with fuse3, everything
works fine.

This doesn’t mean that the MBF isn’t warranted — migrating off of fuse would
be a good thing. There is some work involved however; see
https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 for details
(perhaps the MBF message could include that).
https://bugs.debian.org/918984 and
https://bugs.debian.org/927291 are also relevant (although as mentioned
above, the latter isn’t a concern in practice).

Regards,

Stephen


pgpxC6zCt4q25.pgp
Description: OpenPGP digital signature

Accepting DEP14?

[Andreas Tille]

Hi,

considering that it makes sense to settle with DEP14[1] first before we
can decide about DEP18 I wonder what is finally needed to accept DEP14.
I think its cruxial to make git-buildpackage supporting DEP14 per
default[3] but I'm somehow sensing some hen-egg problem here what to do
first.  If DEP14 might be accepted the motivation to fix bug #829444
would be probably way higher.

Just a personal note: All repositories where I'm uploader (>1000) are
following git-buildpackage default layout and thus not compatible with
the DEP.  So accepting DEP14 would mean a lot of work for me (at least
testing the suggested scripting solutions[4] carefully) and for my
personal workflow I'm not really keen on pushing DEP14.  However,
wearing my DPL hat with the clear intention to streamline common
workflows, I'd be happy if we would move forward here.

Are there any blockers to accept this DEP which I might have missed?

Kind regards
Andreas.

[1] https://dep-team.pages.debian.net/deps/dep14/
[2] https://salsa.debian.org/dep-team/deps/-/merge_requests/8
[3] https://bugs.debian.org/829444
[4] https://lists.debian.org/debian-devel/2020/09/msg00168.html
https://lists.debian.org/debian-devel/2020/09/msg00172.html

-- 
https://fam-tille.de

Python2 idiosyncrasies in Python3 scripts

[Jerome BENOIT]

Hi,

is there a reliable way to isolate Python2 idiosyncrasies in Python3 scripts ?

I guess that I am looking for Python scripts what checkbashisms(1) is for shell 
scripts.

Cheers,
Jerone

Re: Python2 idiosyncrasies in Python3 scripts

[Andrey Rakhmatullin]

On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote:
> is there a reliable way to isolate Python2 idiosyncrasies in Python3 scripts ?

Do you mean code that still works in Python 3 but can be simplified?
Lots of linters do this in whole or in part, though I don't have
suggestions for something that does *only* this. You can also look at
pyupgrade.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python2 idiosyncrasies in Python3 scripts

[Alexandre Detiste]

mypy will cry at py2+py3 if it doesn't understand the py2 half of
hybridized code

pyfkakes alike

but there's a lot of things to grep for:

- sys.error
- except ImportError -C 3
- __unicode__
- unicode(
- most "from __future__" ... except "annotations"
- class (object):  ---> "(object)" part can go.



In debian/rules:

The PYBUILD_python2 rules should be dropped and the "_python3" suffix
can be dropped.


In debian/control:

Boilerplate like  "This is the Python3 version of the library". This is
mostly non-sensical now. The tools that generate d/control could be trimmed
too.

Debian Code Search can help for both.


Greetings


Le jeu. 15 août 2024, 12:57, Andrey Rakhmatullin  a écrit :

> On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote:
> > is there a reliable way to isolate Python2 idiosyncrasies in Python3
> scripts ?
>
> Do you mean code that still works in Python 3 but can be simplified?
> Lots of linters do this in whole or in part, though I don't have
> suggestions for something that does *only* this. You can also look at
> pyupgrade.
>
> --
> WBR, wRAR
>

Re: Python2 idiosyncrasies in Python3 scripts

[Jerome BENOIT]

Hello Andrey, thanks for your reply.

On 15/08/2024 12:56, Andrey Rakhmatullin wrote:

On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote:

is there a reliable way to isolate Python2 idiosyncrasies in Python3 scripts ?


Do you mean code that still works in Python 3 but can be simplified?
Lots of linters do this in whole or in part, though I don't have
suggestions for something that does *only* this. You can also look at
pyupgrade.




I look to check if a bunch of Python[2] scripts can run with Python3 as-is or 
with minor changes.
The involve scripts are very basic.

Cheers,
Jerome

Re: Python2 idiosyncrasies in Python3 scripts

[Andrey Rakhmatullin]

On Thu, Aug 15, 2024 at 01:11:23PM +0200, Jerome BENOIT wrote:
> > > is there a reliable way to isolate Python2 idiosyncrasies in Python3 
> > > scripts ?
> > 
> > Do you mean code that still works in Python 3 but can be simplified?
> > Lots of linters do this in whole or in part, though I don't have
> > suggestions for something that does *only* this. You can also look at
> > pyupgrade.
> > 
> 
> 
> I look to check if a bunch of Python[2] scripts can run with Python3 as-is or 
> with minor changes.
> The involve scripts are very basic.

Try modernize or any linter.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python2 idiosyncrasies in Python3 scripts

[Bastian Venthur]

On 15.08.24 12:11, Jerome BENOIT wrote:

Hi,

is there a reliable way to isolate Python2 idiosyncrasies in Python3 
scripts ?


I guess that I am looking for Python scripts what checkbashisms(1) is 
for shell scripts.


I have good experience with 2to3 
(https://docs.python.org/3/library/2to3.html).



Hope that helps,

Bastian

--
Dr. Bastian Venthur https://venthur.de
Debian Developer venthur at debian org

The end of 32-bit PostgreSQL support in Debian

[Christoph Berg]

Hi debian-devel,

it has probably been a decade since I've last seen a PostgreSQL
installation in the wild on a 32-bit machine. PostgreSQL itself works
fine there, but more and more extensions are not compatible anymore,
either deliberately, or (more common) because of subtle bugs in printf
patterns, double precision values not fitting in a PG Datum, or other
porting problems. Each time this happens, someone has to go digging
what's wrong this time, while in reality, there are likely no users at
all for this PG extension on 32-bit architectures.

Hence, we would like to stop building PG extensions on 32-bit
architectures. The server packages will still build, but extension
packages will be restricted to 64-bit architectures. (If the server
starts to break as well, we could strip down the PG packages to
provide libpq5.deb and friends only.)

I haven't yet decided whether to extend that to PG applications, but
this would likely be the preferred fix for anything 32-bit related in
case of problems.

apt.postgresql.org has already stopped building 32-bit packages for
all releases past past buster, and in the years since then, I've only
received a single question about that. (Which wasn't a user but the
pgbackrest upstream trying to test their software against 32-bit, so
with the same problem.)

On pgsql-pkg-debian I proposed this plan:

* Remove buster-pgdg from apt.pg.o (buster-lts was EOLed last month)

* Remove i386 from sid-pgdg (packages are still preserved on
  apt-archive.postgresql.org)

* Upload postgresql-17 to Debian unstable, with all architectures
  supported [*] (once rc1 is there)

* When re-uploading all extensions to Debian to transition them from
  16 to 17, disable extensions on 32-bit archs. Adding this should do
  the trick:

  Build-Depends: architecture-is-64-bit ,

  That way, people could still build extension packages manually if
  they really wanted (dpkg-buildpackage -Ppkg.postgresql.32-bit).

* Remove postgresql-16 from unstable

Comments?

Christoph

[*] On a side note, 32-bit powerpc did actually start to break:
https://buildd.debian.org/status/logs.php?pkg=postgresql-17&ver=17%7Ebeta2-1&arch=powerpc
I told the package to ignore the regression test results there with
the next postgresql-common upload:
https://salsa.debian.org/postgresql/postgresql-common/-/commit/593fa32fa0c6d2a963a7b3b514d1d6a2423ef534


signature.asc
Description: PGP signature

Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[Michael Stone]

The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that failed the network was not
configured. This meant having to boot into single user mode for diagnostics
because systemd hung forever waiting for the network.


This change was noted in NEWS.

I would suggest hooking your config into something that uses the
network-online.target target, with a timeout like network-manager and
networkd do, so that the boot process doesn't hang. If it's a simple
unit, it's enough to add RuntimeMaxSec= to it, so that it's killed if
it doesn't work within the configured timeout.


It's just so depressing that this is how debian works now. We used to 
try to not break things, now the answer is "you should have read the 
NEWS, and known that unrelated packages were going to break, and 
reconfigured standard debian network tools to add non-default 
timeouts". All because the aesthetic preference for not having the same 
binary appear in two different paths is a higher priority than

keeping systems working.

Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[G. Branden Robinson]

At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > This change was noted in NEWS.
> > 
> > I would suggest hooking your config into something that uses the
> > network-online.target target, with a timeout like network-manager
> > and networkd do, so that the boot process doesn't hang. If it's a
> > simple unit, it's enough to add RuntimeMaxSec= to it, so that it's
> > killed if it doesn't work within the configured timeout.
> 
> It's just so depressing that this is how debian works now. We used to
> try to not break things, now the answer is "you should have read the
> NEWS, and known that unrelated packages were going to break, and
> reconfigured standard debian network tools to add non-default
> timeouts". All because the aesthetic preference for not having the
> same binary appear in two different paths is a higher priority than
> keeping systems working.

"Move fast and break as much stuff as possible, or Debian will be doomed
to irrelevance.  I'll be SABDFL someday!"

The creed of the _impactful_ developer.

Regards,
Branden


signature.asc
Description: PGP signature

Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[Nilesh Patra]

On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > This change was noted in NEWS.
> > > 
> > > I would suggest hooking your config into something that uses the
> > > network-online.target target, with a timeout like network-manager
> > > and networkd do, so that the boot process doesn't hang. If it's a
> > > simple unit, it's enough to add RuntimeMaxSec= to it, so that it's
> > > killed if it doesn't work within the configured timeout.
> > 
> > It's just so depressing that this is how debian works now. We used to
> > try to not break things, now the answer is "you should have read the
> > NEWS, and known that unrelated packages were going to break, and
> > reconfigured standard debian network tools to add non-default
> > timeouts". All because the aesthetic preference for not having the
> > same binary appear in two different paths is a higher priority than
> > keeping systems working.
> 
> "Move fast and break as much stuff as possible, or Debian will be doomed
> to irrelevance.  I'll be SABDFL someday!"
> 
> The creed of the _impactful_ developer.

It looks like a pretty pointless change - breaks several scripts for example.
It was/is common to assume /sbin/ip to be present and usable.
Michael's bug report does make sense to me. Such a change is even causing
systems to not bootup.

Best,
Nilesh


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Otto Kekäläinen]

Yes to finalizing DEP-14 soon, but first I think we need to complete the
technical work to have git-buildpackage use DEP-14 branch names by default.
I tried implementing it but turned out a bit too involved..


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
Use DEP14 branch layout by default
= master -> debian/latest
= upstream -> upstream/latest

Any hands available to help with this?

Re: Accepting DEP14?

[Emmanuel Arias]

On Thu, Aug 15, 2024 at 01:43:40PM -0700, Otto Kekäläinen wrote:
> Yes to finalizing DEP-14 soon, but first I think we need to complete the
> technical work to have git-buildpackage use DEP-14 branch names by default.
> I tried implementing it but turned out a bit too involved..
>
Hi! I use git-buildpackage for my Debian work. But I think is not
necessary have git-buildpackage compatible with DEP-14 before, is it?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
> Use DEP14 branch layout by default
> = master -> debian/latest
> = upstream -> upstream/latest
> 
> Any hands available to help with this?

-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 
 ⠈⠳⣄


signature.asc
Description: PGP signature

Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[Colin Watson]

On Thu, Aug 15, 2024 at 11:14:41PM +0530, Nilesh Patra wrote:
> On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> > At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > It's just so depressing that this is how debian works now. We used to
> > > try to not break things, now the answer is "you should have read the
> > > NEWS, and known that unrelated packages were going to break, and
> > > reconfigured standard debian network tools to add non-default
> > > timeouts". All because the aesthetic preference for not having the
> > > same binary appear in two different paths is a higher priority than
> > > keeping systems working.
> > 
> > "Move fast and break as much stuff as possible, or Debian will be doomed
> > to irrelevance.  I'll be SABDFL someday!"
> > 
> > The creed of the _impactful_ developer.
> 
> It looks like a pretty pointless change - breaks several scripts for example.
> It was/is common to assume /sbin/ip to be present and usable.
> Michael's bug report does make sense to me. Such a change is even causing
> systems to not bootup.

On 2024-07-14 (five days before the iproute2 change was made), there was
this conversation on #debian-devel:

  19:14  Is there a reason why iproute2 ships a symlink
  from /sbin/ip to /bin/ip? I've looked into the packaging repo and it
  seems to predate the git log.
  ...
  19:52  petn-randall:
  https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has
  a pretty non-trivial list of things that would need fixed before
  removing that (and of course some false positives)

I realize it wasn't petn-randall who made this change, but it seems a
big coincidence that the symlink was dropped a few days after this IRC
conversation; and yet it seems nobody bothered to do the most basic due
diligence that I pointed out here, which is kind of sad.  (I fixed
wireless-tools after this change caused an RC bug there.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1078788: ITP: sphinx-removed-in -- Sphinx extension recognizes *removed[-in] directives

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: sphinx-removed-in
  Version : 0.2.3
  Upstream Contact: Alexander Todorov 
* URL : https://github.com/MrSenko/sphinx-removed-in
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx extension recognizes *removed[-in] directives

 This Sphinx extension recognizes the .. versionremoved:: and
 .. removed-in:: directives. These are missing from Sphinx'es core markup.

This package is a dependency for python-sphobjinv ITP #1078565
https://bugs.debian.org/1078565

The maintenance of the package will happen within the DPT.

Bug#1078789: ITP: ocaml-ohex -- OCaml library for hexadecimal encoding and decoding

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-ohex
  Version : 0.2.0
  Upstream Contact: Hannes Mehnert
* URL : https://opam.ocaml.org/packages/ohex/
* License : BSD-2-clause
  Programming Lang: OCaml
  Description : OCaml library for hexadecimal encoding and decoding

 ohex is an OCaml library to encode and decode hexadecimal byte
 sequences.

This package is a new dependency of ocaml-ca-certs. It will be
maintained in the OCaml team.