ivyplusplus 1.38-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the ivyplusplus source package
in Debian's testing distribution has changed.

  Previous version: 1.32-1
  Current version:  1.38-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

libpdfbox-graphics2d-java 0.34-2 MIGRATED to testing

[Debian testing watch]

FYI: The status of the libpdfbox-graphics2d-java source package
in Debian's testing distribution has changed.

  Previous version: (not in testing)
  Current version:  0.34-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

libapache-poi-java 4.0.1-3 MIGRATED to testing

[Debian testing watch]

FYI: The status of the libapache-poi-java source package
in Debian's testing distribution has changed.

  Previous version: 4.0.1-2
  Current version:  4.0.1-3

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

kdgcommons-java: status change on tests.reproducible-builds.org/debian

[Reproducible Builds folks]

Dear maintainer,

The reproducibility status of the package kdgcommons-java changed during the
continuous testing.
See the following notes for more details:

2022-02-19 06:44 
https://tests.reproducible-builds.org/debian/unstable/amd64/kdgcommons-java 
changed from reproducible -> FTBFS

Feel free to reply to this email if you have questions regarding
this automatic notification.

-- 
The Reproducible Builds folks

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1006140: New version can't load old databases

[Markus Koschany]

Am Samstag, dem 19.02.2022 um 23:13 +0100 schrieb Jochen Sprickerhof:
> * Markus Koschany  [2022-02-19 22:38]:
> > Ok. Did you file an upstream bug report already?
> 
> I did not yet. Upstream bundles the old binary version so I don't think 
> I can convince them to do a quick migration.
> But I will open a bug to get it fixed there.
> 
> > The old version of H2 is already present in Ubuntu or Debian stable. You
> > could
> > either ask users to execute all those commands manually (README.Debian,
> > Debian.NEWS) or there could be some kind of pre/post hook script that does
> > all
> > that automatically.
> 
> Asking users to install packages from other releases does not sound 
> convincing. We can't use the pre/post maintainer scripts as the database 
> files could be stored anywhere on disk (default is in $HOME but could 
> even be on a thumb drive). So we can only hook into the jameica 
> executable. I don't think doing this before the Ubuntu jammy freeze is 
> feasible.

I believe there is a misunderstanding somewhere. We don't need to ask users to
install anything. They simply upgrade from an older version to a newer one.
There must be some sort of logic for the database storage. It is possible to
move a file to a different location but your program will always look in the
same place. If your database isn't there, then a good script would ask where it
is, you enter the new location and the program proceeds. 

> > For a quick solution you could upload 1.4.197 again based on the version in
> > Bullseye
> 
> Thanks, I will do that, i.e. I will upload 2.1.210+really1.4.197-1 = 
> 1.4.197-4+deb11u1 as proposed in my initial bug report.
> 
> > but this doesn't really solve the problem.
> 
> Can you explain what you mean here?


You only fix your single use case. You keep an unsupported and buggy version of
the H2 database in Debian and this is not how we usually solve problems in
Debian. 


> > As I said we don't need multiple H2 versions in Debian.
> 
> Can you give reasons why you think so? As I stated multiple times I 
> don't see a way not to have multiple versions available in one release 
> to support the migration.

You don't need multiple version of H2 in Bookworm. We ship 1.4.197 in Bullseye
and 2.x in Bookworm, that's it. When users upgrade from Bullseye to Bookworm,
they either have to perform some manual migration steps, or the package takes
care of them automatically. That's how it works for every package in Debian. We
also don't ship multiple Tomcat or Jetty, MariaDB or PostgreSQL versions in
stable releases because we support only one of them for their life cycle. This
is because of security and maintenance reasons, otherwise we would have
multiple versions of every piece of Java software in Debian and we could stop
using system libraries and instead bundle everything together in fat jars. At
one point you have to upgrade to a newer H2 database, that's a fact and it
should happen before we freeze for Bookworm.

> > You should only do that if you are willing to
> > support an officially unsupported piece of software for the next Debian 12
> > LTS
> > cycle until the year 2028. And that means taking care of all other libh2-
> > java
> > dependencies too, dealing with people who request an upgrade to 2.x because
> > their use case depends on it, etc. And you and the rest of the users should
> > be
> > fine with the disabled H2 console and all the other bugs in that version.
> 
> That would be fine with me.

Ok, that's your choice but please add yourself to the list of Uploaders and
keep an eye on all H2 bug reports from now on because I won't. ;>




signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi Jochen,

Am Samstag, dem 19.02.2022 um 21:21 +0100 schrieb Jochen Sprickerhof:
> Hi Markus,
> 
> thanks for your quick reply.
> 
> * Markus Koschany  [2022-02-19 21:01]:
> > That means only hibiscus/jameica require our attention. I would try to
> > remove
> > the obsolete connection setting mentioned in #1005838.
> 
> Tried that already, did not solve the problem.


Ok. Did you file an upstream bug report already?

> 
> > You could also try to
> > dump the SQL database with the current version in stable and then try to
> > re-
> > import the SQL tables with H2 in unstable. That should actually work
> > because
> > the SQL syntax will not have changed. (See also the Upgrading paragraph
> > here
> > https://h2database.com/html/migration-to-v2.html)
> 
> That would be the plan, yes. But for that we would need to provide both 
> versions to our users, thus I propose to upload the new version as a new 
> source and binary package.
> 
> Also the SQL syntax did change.
[...]
> Can you explain how you want to implement this re-import feature then?


I don't think the SQL syntax itself did change. SQL is a separate language and
different SQL databases must be compatible in this regard. MySQL, MariaDB,
hsqldb, H2, they all should be able to read and write SQL. If H2 changed some
H2 specific commands, then all we have to do is to execute a command for the
old H2 database to dump the old database and then use another command to re-
import the database into H2 2.x. 

The old version of H2 is already present in Ubuntu or Debian stable. You could
either ask users to execute all those commands manually (README.Debian,
Debian.NEWS) or there could be some kind of pre/post hook script that does all
that automatically. 

I would try to solve that problem on the package level though, and ask upstream
to come up with a migration plan because sticking with 1.4.x forever is not a
great plan.

> I would really appreciate a quick solution here so users of the next 
> Ubuntu version would not be locked out of their homebanking system.
> 
> I'm happy to help with uploading new versions and NEW is rather empty 
> currently so I don't see the point in not doing a proper transition 
> here.

For a quick solution you could upload 1.4.197 again based on the version in
Bullseye but this doesn't really solve the problem. As I said we don't need
multiple H2 versions in Debian. You should only do that if you are willing to
support an officially unsupported piece of software for the next Debian 12 LTS
cycle until the year 2028. And that means taking care of all other libh2-java
dependencies too, dealing with people who request an upgrade to 2.x because
their use case depends on it, etc. And you and the rest of the users should be
fine with the disabled H2 console and all the other bugs in that version. 



signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Hi Markus,

thanks for your quick reply.

* Markus Koschany  [2022-02-19 21:01]:

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838.


Tried that already, did not solve the problem.


You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


That would be the plan, yes. But for that we would need to provide both 
versions to our users, thus I propose to upload the new version as a new 
source and binary package.


Also the SQL syntax did change.


I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here:

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable.

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.


Can you explain how you want to implement this re-import feature then?

I would really appreciate a quick solution here so users of the next 
Ubuntu version would not be locked out of their homebanking system.


I'm happy to help with uploading new versions and NEW is rather empty 
currently so I don't see the point in not doing a proper transition 
here.


Cheers Jochen


signature.asc
Description: PGP signature
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1003894: fixed in h2database 2.1.210-1

[Markus Koschany]

Control: fixed -1 1.4.197-4+deb10u1
Control: fixed -1 1.4.197-4+deb11u1


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Processed: Re: Bug#1003894: fixed in h2database 2.1.210-1

[Debian Bug Tracking System]

Processing control commands:

> fixed -1 1.4.197-4+deb10u1
Bug #1003894 {Done: Markus Koschany } [src:h2database] 
h2database: CVE-2021-42392
Marked as fixed in versions h2database/1.4.197-4+deb10u1.
> fixed -1 1.4.197-4+deb11u1
Bug #1003894 {Done: Markus Koschany } [src:h2database] 
h2database: CVE-2021-42392
Marked as fixed in versions h2database/1.4.197-4+deb11u1.

-- 
1003894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003894
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi,

Am Samstag, dem 19.02.2022 um 18:52 +0100 schrieb Jochen Sprickerhof:
> Package: libh2-java
> Version: 2.1.210-1
> Severity: important
> X-Debbugs-Cc: jspri...@debian.org, Markus Koschany 
> Control: -1 affects mediathekview jameica hibiscus
> 
> Hi,
> 
> the new version of libh2-java uses a new SQL syntax and file format and
> is not able to read old data or work with the old syntax:
> 
> https://h2database.com/html/migration-to-v2.html
> 
> This renders all it's users, i.e. mediathekview and jameica/hibiscus,
> unusable.

I had rebuilt all reverse-dependencies of libh2-java and they still can be
built from source. Unfortunately there are runtime problems as you have rightly
pointed out. Actually only mediathekview and jamaica/hibiscus are really
affected. Mediathekview downloads a large json file from the internet (the
filmlist) and then it is converted into a h2 database. Normally it should be
fine to remove the old database and then mediathekview would create a new
database again. Persistent settings are saved in xml files anyway. However I
just noticed at least one SQLException when this happens and the conversion
appears to take forever. Probably solvable but...

the latest version of Mediathekview uses a SQLite database now, because
upstream likes changing dependencies, thus upgrading to the lastest upstream
release would solve the problem.

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838. You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


> 
> Given that there is no online conversion available, the H2MigrationTool
> actually contains jars of the different version, I would propose to
> upload the v2 version with a new source and binary package name and
> upload the v1 version to unstable again with a +really version number:
> 
> 2.1.210+really1.4.197-1
> 
> based on the git tag debian/1.4.197-4+deb11u1.
> 
> Given that this affects all linked programs and that v2 already
> transitioned to testing as well as the next Ubuntu version (which will
> stop importing from Debian soon) I would like to get this fixed fast.
> 
> I'm planning to upload the +really version tomorrow unless someone
> disagrees.

I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

 I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here: 

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable. 

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.

Regards,

Markus



signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Processed: affects 1006140

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 1006140 mediathekview jameica hibiscus
Bug #1006140 [libh2-java] New version can't load old databases
Added indication that 1006140 affects mediathekview, jameica, and hibiscus
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1006140: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006140
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Package: libh2-java
Version: 2.1.210-1
Severity: important
X-Debbugs-Cc: jspri...@debian.org, Markus Koschany 
Control: -1 affects mediathekview jameica hibiscus

Hi,

the new version of libh2-java uses a new SQL syntax and file format and
is not able to read old data or work with the old syntax:

https://h2database.com/html/migration-to-v2.html

This renders all it's users, i.e. mediathekview and jameica/hibiscus,
unusable.

Given that there is no online conversion available, the H2MigrationTool
actually contains jars of the different version, I would propose to
upload the v2 version with a new source and binary package name and
upload the v1 version to unstable again with a +really version number:

2.1.210+really1.4.197-1

based on the git tag debian/1.4.197-4+deb11u1.

Given that this affects all linked programs and that v2 already
transitioned to testing as well as the next Ubuntu version (which will
stop importing from Debian soon) I would like to get this fixed fast.

I'm planning to upload the +really version tomorrow unless someone
disagrees.

Cheers Jochen

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

libh2-java depends on no packages.

libh2-java recommends no packages.

Versions of packages libh2-java suggests:
pn  libjts-java  
pn  liblucene8-java  
ii  libslf4j-java1.7.32-1

-- no debconf information

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.