Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Wed, Oct 19, 2016 at 08:20:25AM +1100, Dmitry Smirnov wrote:
> On Monday, 17 October 2016 3:33:29 PM AEDT Rene Engelhard wrote:
> >  - mysql-connector-c++s upstream is Oracle, so they obviously do not care
> >about MariaDB and (can) just require MySQL
> >  - mysql-workbench (also Oracle I think) in newer versions apparently needs
> > mysql-connector-c++ >= 1.1.7
> >  - mysql-connector-c++ starting from 1.1.5 (IIRC) needs MySQL >= 5.6 to
> > build (and doesn't build with MariaDB) and mysql-connector-c++ 1.1.7 needs
> > even MySQL >= 5.7
> 
> Sadly it is true that Oracle couldn't care less about mysql-workbench 
> compatibility with anything but MySQL 5.7... New versions of mysql-workbench 

I am not surprised.

> FTBFS with mysql-5.6 and with mariadb. mysql-workbench is stuck at v6.3.4 
> because upstream refuses to recognise/resolve FTBFS in newer versions that 
> upstream build against MySQL 5.7.

Ah, that might explain why you didn't even approach me that you need something
newer than 1.1.3 :)

> >(Interestingly, the mysql-workbench "maintainer" didn't do *any* action
> > or offer to help to fix https://bugs.debian.org/836731, which is why sid
> > is stuck with 1.1.3)
> 
>  * mysql-workbench maintainer is not even mentioned in #836731 let alone he 
> is not a maintainer of "mysql-connector-c++"...

Yeah, but as said I wondered why you didn't even ask for 1.1.7 going out
of experimental and deducted inactivity...

>  * mysql-workbench maintainer have no shortage of excuses for his inactivity: 
> among other issues that affect his performance there are new job, illness 
> (from which he did not recover yet) and sudden death of a family member in an 
> accident...

Ugh.

Regards,

Rene

Bug#841265: transition: cfitsio

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

The cfitsio library changed its ABI in the latest release version.
The new version, including the package rename from libcfitsio4 to
libcfitsio5 is available in experimental. It has been built successfully
on all official architecture and most ports architectures.

The transition involves 37 packages, you can find the list on the
transition tracker in the auto-cfitsio entry. I have been able to
successfully rebuild all of them on amd64, so I don't expect any
issue.

Thanks for considering.


Ben file:

title = "cfitsio";
is_affected = .depends ~ "libcfitsio4" | .depends ~ "libcfitsio5";
is_good = .depends ~ "libcfitsio5";
is_bad = .depends ~ "libcfitsio4";


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

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

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Dmitry Smirnov]

On Monday, 17 October 2016 3:33:29 PM AEDT Rene Engelhard wrote:
>  - mysql-connector-c++s upstream is Oracle, so they obviously do not care
>about MariaDB and (can) just require MySQL
>  - mysql-workbench (also Oracle I think) in newer versions apparently needs
> mysql-connector-c++ >= 1.1.7
>  - mysql-connector-c++ starting from 1.1.5 (IIRC) needs MySQL >= 5.6 to
> build (and doesn't build with MariaDB) and mysql-connector-c++ 1.1.7 needs
> even MySQL >= 5.7

Sadly it is true that Oracle couldn't care less about mysql-workbench 
compatibility with anything but MySQL 5.7... New versions of mysql-workbench 
FTBFS with mysql-5.6 and with mariadb. mysql-workbench is stuck at v6.3.4 
because upstream refuses to recognise/resolve FTBFS in newer versions that 
upstream build against MySQL 5.7.


>(Interestingly, the mysql-workbench "maintainer" didn't do *any* action
> or offer to help to fix https://bugs.debian.org/836731, which is why sid
> is stuck with 1.1.3)

 * mysql-workbench maintainer is not even mentioned in #836731 let alone he 
is not a maintainer of "mysql-connector-c++"...

 * #836731 was silently merged with related #835185 at which mysql-workbench 
maintainer looked but unfortunately couldn't find anything with his limited 
knowledge of C++. He then tagged bug #835185 "help".

 * mysql-workbench maintainer have no shortage of excuses for his inactivity: 
among other issues that affect his performance there are new job, illness 
(from which he did not recover yet) and sudden death of a family member in an 
accident...

 * mysql-workbench maintainer is unable to deal with complex C++ issues on 
his own and upstream is not helpful (or at least ignores comments about 
compatibility raised in their bug tracker). mysql-workbench maintainer wishes 
he could be more useful but there is only little he can do... :(

-- 
Best wishes,
 Dmitry Smirnov.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill


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

Bug#839869: transition: poppler 0.48.0

[Pino Toscano]

In data lunedì 17 ottobre 2016 21:11:00 CEST, Emilio Pozuelo Monfort ha scritto:
> On 08/10/16 20:34, Pino Toscano wrote:
> > In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto:
> >> Hi,
> >>
> >> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote:
> >>> This transition impacts the existing poppler libraries in the following 
> >>> ways:
> >>> - libpoppler61 → libpoppler64
> >> [...]
> >>>   boomaga
> >>>   calligra
> >>>   cups-filters
> >>>   emacs-pdf-tools
> >>>   gambas3
> >>>   gdal
> >>>   gdcm
> >>>   inkscape
> >>>   ipe-tools
> >>>   pdf2djvu
> >>>   pdf2htmlex
> >>>   popplerkit.framework
> >>>   texlive-bin
> >>>   texworks
> >>>   xpdf
> >>
> >> I believe there's stuff missing there for whatever reason. E.g. libreoffice
> >> (via libreoffice-pdfimport, 
> >> https://packages.debian.org/sid/libreoffice-pdfimport).
> >>
> >> Was in your last transition bugs afaicr, so I wonder what went wrong this 
> >> time ;)
> > 
> > Oh right, sorry, it was indeed missing.  In the above list there is also:
> > 
> >   libreoffice
> >   openscenegraph
> >   openscenegraph-3.4
> 
> I see the new poppler is now in experimental. Do the rdeps build against the 
> new
> version?

I could test everything but LibreOffice: no failures.

Rene, could you please give LO + poppler/experimental a try? Thanks!

-- 
Pino Toscano

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

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Dmitry Smirnov]

Hi Rene,

On Monday, 17 October 2016 9:01:24 PM AEDT Rene Engelhard wrote:
> This means I'll orphan mysql-connector-c++ (well, remove myself from
> Uploaders:, which makes it having no Uploader at all). Dmitry, if you
> want/need it for mysql-connector-c++ feel free to add yourself and upload
> 1.1.7 to whatever you want and it actually works.

(Eventually) I'll see what I can do but at the moment I have no capacity to 
take care of mysql-connector-c++... Is there a public repository for its 
packaging anywhere?

Newer versions of MySQL Workbench FTBFS with mysql-connector-c++ in 
"experimental" but that's upstream problem which I'm unable to fix...

Thanks for looking after mysql-connector-c++ all those years.

-- 
All the best,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#841203: nmu: flex_2.6.1-1

[Gianfranco Costamagna]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu flex_2.6.1-1 . ANY . unstable . -m "rebuild with default fPIC flag  (cfr: 
#837658)"


please add an additional build dependency on gcc6_6.2.0-7 to be sure it picks up
the flags, thanks!

G.

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Tue, Oct 18, 2016 at 01:17:27PM +0300, Otto Kekäläinen wrote:
> 2016-10-18 11:38 GMT+03:00 Rene Engelhard :
> > Simple: Because LO uses the C++ bindings and not the C bindings? If you
> > mean why I don't build mysql-connector-c++ against mariadb, see my initial
> > mail. Newer versions of it do not build with it. (the version in sid is
> > ooold.)
> 
> MariaDB Connector C is for C++ also. I am not an expert on the topic,
> but I assume you could just try it directly and see if it builds or if
> it complains about some missinng API call or not?

Obviously not, mysql-connector-c++ is a C++ API with classes and namespaces
etc (and Lo uses sql:: all over the place). You maybe can explain
how something with a C API can be a standalone replacement? One doesn't even
need to try to know this wouldn't work :)

Regards,

Rene

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Otto Kekäläinen]

2016-10-18 11:38 GMT+03:00 Rene Engelhard :
> Simple: Because LO uses the C++ bindings and not the C bindings? If you
> mean why I don't build mysql-connector-c++ against mariadb, see my initial
> mail. Newer versions of it do not build with it. (the version in sid is
> ooold.)

MariaDB Connector C is for C++ also. I am not an expert on the topic,
but I assume you could just try it directly and see if it builds or if
it complains about some missinng API call or not?

See
* https://mariadb.com/kb/en/mariadb/mariadb-connector-c/
* https://packages.debian.org/sid/libmariadb-dev
* https://packages.debian.org/sid/libmariadb-dev-compat
* https://packages.debian.org/stretch/libmariadbclient-dev
* https://packages.debian.org/stretch/libmariadbclient-dev-compat

Xen in stretch - 4.7 or 4.8 ?

[Ian Jackson]

Hi.  I was wanting an initial opinion from the Release Team, about the
Xen packages.  Currently they are in bad shape in stretch and I intend
to fix them ASAP.

The question is whether I should move to Xen 4.7, or Xen 4.8.  Xen 4.8
is currently at RC2 and seems in pretty good shape.  I think it's more
probable than not that we'll have Xen 4.8.0 by the Debian freeze date,
but this is by no means certain.  If 4.8.0 arrives after the Debian
freeze, then at the Debian freeze stretch will contain a late RC.  The
only things going into the upstream 4.8 branch after then will be
fairly important bugfixes which we would probably want to take for
stretch.

The biggest improvements in 4.8 compared to 4.7 are improvements to
ARM support, including AIUI fairly important overhauls.  There are
also changes to support the new PVH2 guest mode, which Xen upstream
are intending to ultimately replace PV with.  There are also more
minor features, and some bugfixes which upstream won't backport.

Upstream support ends as follows:

End of bugfix supportEnd of security support

  Xen 4.6 [1] Apr 2017   Oct 2018
  Xen 4.7 Dec 2018   Jun 2019
  Xen 4.8 May/Jun 2019 [2]   Nov/Dec 2019 [2]

[1] Currently in stretch, in bad shape, we shouldn't release with
this.

[2] Xen 4.8 support dates are not formally promised yet and will
depend on the Xen 4.8.0 release date.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Otto Kekäläinen]

Hello!

2016-10-17 22:01 GMT+03:00 Rene Engelhard :
> This means I'll orphan mysql-connector-c++ (well, remove myself from 
> Uploaders:,
> which makes it having no Uploader at all). Dmitry, if you want/need it
> for mysql-connector-c++ feel free to add yourself and upload 1.1.7 to whatever
> you want and it actually works.
>
> For LO, I disabled libreoffice-mysql-connector.

I didn't find a package called mysql-connector-c++, is it already removed?

I only found this:
https://packages.debian.org/stretch/libreoffice-mysql-connector

The package seems to contain mysqlc.uno.so - this is unique to
LibreOffice? I didn't quite understand why you cannot build against
libariadbclient-dev or using the mariadb-connector-c?

- Otto

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Tue, Oct 18, 2016 at 11:28:32AM +0300, Otto Kekäläinen wrote:
> 2016-10-17 22:01 GMT+03:00 Rene Engelhard :
> > This means I'll orphan mysql-connector-c++ (well, remove myself from 
> > Uploaders:,
> > which makes it having no Uploader at all). Dmitry, if you want/need it
> > for mysql-connector-c++ feel free to add yourself and upload 1.1.7 to 
> > whatever
> > you want and it actually works.
> >
> > For LO, I disabled libreoffice-mysql-connector.
> 
> I didn't find a package called mysql-connector-c++, is it already removed?

The source package is mysql-connector-c++.
https://packages.qa.debian.org/m/mysql-connector-c%2B%2B.html

> I only found this:
> https://packages.debian.org/stretch/libreoffice-mysql-connector
> 
> The package seems to contain mysqlc.uno.so - this is unique to
> LibreOffice?

Yees, that's the LO component. And you see that it depends on libmysqlcppconn7v5

> I didn't quite understand why you cannot build against
> libariadbclient-dev or using the mariadb-connector-c?

Simple: Because LO uses the C++ bindings and not the C bindings? If you
mean why I don't build mysql-connector-c++ against mariadb, see my initial
mail. Newer versions of it do not build with it. (the version in sid is
ooold.)

Regards,

Rene