Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2016-01-26 at 15:28 -0800, Tianon Gravi wrote:
> Due to some kind of mistake in my amd64 build environment (details being
> tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
> only one that got the intended man page update, but this causes
> co-installability issues (as detailed in #812566).  Getting a binNMU of
> amd64 in the meantime would be great so that at least the packages line
> up properly while we figure out what happened. :(
> 
> nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
> environment"

Scheduled, on all architectures as discussed.

Regards,

Adam

Processed: Re: Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #812821 [release.debian.org] nmu: pam_1.1.8-3.1+deb8u1
Added tag(s) confirmed.

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

Bug#812925: nmu: glib2.0_2.42.1-1

[Tianon Gravi]

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

The latest batch of Jessie updates included libpcre3, which is embedded 
statically in libglib2.0-dev's "libglib-2.0.a", which I believe warrants a 
rebuild (to get the updated library built-in). :)

nmu glib2.0_2.42.1-1 . ALL . -m "Rebuild static .a files against newer libpcre3"

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

Processed: Re: Bug#812881: wheezy-pu: package gummi/0.6.3-1.2+deb7u2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #812881 [release.debian.org] wheezy-pu: package gummi/0.6.3-1.2+deb7u2
Added tag(s) confirmed.

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

Bug#812881: wheezy-pu: package gummi/0.6.3-1.2+deb7u2

[Daniel Stender]

On 27.01.2016 23:26, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2016-01-27 at 15:49 +0100, Daniel Stender wrote:
>> The new package fixes #812577 [0]: the patch no-predictable-tmpfiles.patch
>> including in 0.6.3-1.2+deb7u1 fixed CVE-2015-7758 successfully, but has the
>> flaw that temporary include paths for images etc. in the tex documents
>> couldn't be used, but must be absolute (because a workfile [.tex.swp] in the
>> project path is missing).
>>
>> In the meanwhile upstream released a fix for CVE-2015-7758 which elegantly
>> uses a XDG cache dir for the temprary files to solve the problem [1].
> 
> Does this also affect the Jessie package?
> 
> [...]
>> Please see the attached diff for changes between deb7u1 and deb7u2. I've 
>> build
>> against Oldstable with Sbuild [2]. 0.6.3-1.2+deb7u1 is currently pending 
>> [3], I would
>> guess it just could be replaced in the pending state?
> 
> Yes. In this context, "pending" means "in {,o-}p-u, waiting to form part
> of a point release" so updated revisions aren't an issue (although, in
> fairness, the old revision is then no longer actually in p-u; its
> contents are in practice though).
> 
> Regards,
> 
> Adam

Hi Adam,

thanks for the quick reply.

Yes, that bug also affects the Jessie package. I'll create a deb8u2 soon.

O.k., good. Thus I'll upload then now.

Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#812881: wheezy-pu: package gummi/0.6.3-1.2+deb7u2

[Daniel Stender]

On 27.01.2016 23:37, Daniel Stender wrote:
> Hi Adam,
> 
> thanks for the quick reply.
> 
> Yes, that bug also affects the Jessie package. I'll create a deb8u2 soon.
> 
> O.k., good. Thus I'll upload then now.
> 
> Daniel

In: gummi_0.6.3-1.2+deb7u2_amd64.changes ACCEPTED into 
oldstable-proposed-updates->oldstable-new

Best,
Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#811219: transition: netcdf

[Sebastiaan Couwenberg]

On 22-01-16 10:42, Sebastiaan Couwenberg wrote:
> On 21-01-16 20:17, Sebastiaan Couwenberg wrote:
>> On 21-01-16 11:20, Emilio Pozuelo Monfort wrote:
>>> On 17/01/16 00:32, Bas Couwenberg wrote:
 NetCDF 4.4.0 final has been released and bumps the SOVERSION to 11
 accounting for the removed symbols in RC4. Fortunately we only have to
 transition netcdf, and not also the C++ & Fortran packages. Only a few
 packages FTBFS:

 minc (2.2.00-6) FTBFS, this is the same issue as the for the previous
 netcdf transition (#793885), which has been fixed in libminc, but not minc.

 python-scientific (2.9.4-3) FTBFS due to an old issue too (#799195).

 mmtk (2.7.9-1) FTBFS due to #798665, and requires python-scientific.

 These packages are sid-only already, so shouldn't be much of an issue
 for this transition.
>>>
>>> I was waiting for the python3 transition, which is now done. So go ahead.
>>
>> Thanks. I've just uploaded netcdf (1:4.4.0-1) to unstable.
> 
> netcdf-cxx, netcdf-cxx-legacy, netcdf-fortran & netcdf4-python have
> already been rebuilt with netcdf (1:4.4.0-1) on the release architectures.
> 
> The transition tracker does still need to be updated to also mark the
> packages still depending on the netcdf (1:4.1.3-7.2) from the previous
> transitions. Using the attached ben configuration (or the one in the
> initial bugreport) will also include gerris, kst, minc & mmtk in the
> tracker.
> 
> minc & mmtk both FTBFS and are sid-only as noted before.
> 
> gerris links to netcdf but the resulting packages don't depend on any
> netcdf packages.
> 
> kst doesn't detect the new netcdf libraries any more, and disables the
> netcdf plugin because of that.

It seems that leftovers from the previous transition are preventing
testing migration again.

I guess we can't remove the old netcdf (1:4.1.3-7.2) packages because
some un- or badly maintained packages still depend on them.

The hints for the previous transition got the netcdf packages migrated
to testing, but it did prevent migration of a subsequent
(non-transition) update because of the same missing binaries issues.

Can we fix this once and for all, or do we have to rely on hints to
migrate netcdf packages every time?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#812881: wheezy-pu: package gummi/0.6.3-1.2+deb7u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2016-01-27 at 15:49 +0100, Daniel Stender wrote:
> The new package fixes #812577 [0]: the patch no-predictable-tmpfiles.patch
> including in 0.6.3-1.2+deb7u1 fixed CVE-2015-7758 successfully, but has the
> flaw that temporary include paths for images etc. in the tex documents
> couldn't be used, but must be absolute (because a workfile [.tex.swp] in the
> project path is missing).
> 
> In the meanwhile upstream released a fix for CVE-2015-7758 which elegantly
> uses a XDG cache dir for the temprary files to solve the problem [1].

Does this also affect the Jessie package?

[...]
> Please see the attached diff for changes between deb7u1 and deb7u2. I've build
> against Oldstable with Sbuild [2]. 0.6.3-1.2+deb7u1 is currently pending [3], 
> I would
> guess it just could be replaced in the pending state?

Yes. In this context, "pending" means "in {,o-}p-u, waiting to form part
of a point release" so updated revisions aren't an issue (although, in
fairness, the old revision is then no longer actually in p-u; its
contents are in practice though).

Regards,

Adam

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Clint Byrum]

Excerpts from Steven Chamberlain's message of 2016-01-27 12:30:09 -0800:
> I'll try to make this my last intervention in this thread.  Because
> it's not my decision, or area of responsibility, and I likely won't be
> one of the people having to do the work when a decision is made, but...
> 

I appreciate your words very much Steven.

> Clint Byrum wrote:
> > most of these CVE's would remain fully undisclosed and unfixed in both
> > MySQL and MariaDB if the MySQL engineering team or customers had not
> > found them.
> 
> Sorry, this is not compelling.  As long as Oracle sells MySQL to
> enterprise, it *must* do these things, and release source code to
> satisfy legal obligations of what is a GPL codebase.  It is really only
> doing the bare minimum in that regard.  It was also a condition of
> Oracle's acquisition of MySQL AB:
> 
> "As part of the negotiations with the European Commission, Oracle
> committed that MySQL server will continue until at least 2015 to use the
> dual-licensing strategy long used by MySQL AB, with proprietary and GPL
> versions available"
> according to 
> https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions
> 
> Oracle may still drop MySQL support like a hat due to market conditions,
> regardless of whether Debian has already shipped it by then.
> 

The code dump is definitely a condition, but it turns out that's also
prevented an actual fork of their work from forming. MariaDB does pull
things in, but it's forked so far now that there's still enough compelling
reason to run Oracle's code-dumped version that people choose to do it
every day.

> And apart from sponsoring Debian packaging work, Oracle seems
> conspicuously missing from:
> http://debconf16.debconf.org/sponsors.html
> http://debconf15.debconf.org/
> https://www.debian.org/mirror/sponsors
> https://www.freexian.com/en/services/debian-lts.html
> 

I think this unfairly characterizes them as free riders when the point
we've been trying to make is that they're not free riding, but just
choosing to contribute with engineering time.

> Clint Byrum wrote:
> > [...] if it were written down somewhere as an actual policy. [...]
> 
> Norvald H. Ryeng wrote:
> > Tell us exactly what you want, in detail. If you don't then I don't
> > think your position is reasonable.
> 
> Robie Basak wrote:
> > So please: the security team needs to engage directly with Oracle by
> > responding to Norvald's email and enumerating exactly what is wrong.
> 
> I don't see that Debian has to do that, at all.  Other upstream projects
> seem to 'just get it', so Oracle management is really expecting special
> treatment.  IMHO I respond to bad dealings with a company by shopping
> elsewhere, not helping them improve their business practices.
> 

Of course Debian doesn't have to do it. However, here you have a
corporate citizen who _wants_ to contribute, and they're being told to
buzz off. When asking why, they're getting derisive "if you have to ask
you'll never know" type of treatment.

Just because we don't like them, doesn't mean we can kick them out of
our club.

> This is perhaps more significant than a mere decision over what goes
> into the next release.  I see a really fantastic, rare opportunity for
> Debian to take a moral stand against Oracle for shameful mistreatment
> of free software to date.  rock on \m/
> 

So basically "they're bad people by my own conjecture, so let's stick
it to them". I am sorry, but I thought Debian would welcome those who
follow our rules.

> Niels Thykier wrote:
> > I appreciate that the release team failed on action item several
> > months back and have not been very proactive in the communication.
> > And I am sorry that it has (and probably will) inconvenience you and
> > MySQL upstream.
> 
> I do have personal sympathy for Debian contributors who became entwined,
> by their career choices, with the business preferences of Oracle and
> Canonical.  And the team of MySQL developers who must work under
> Oracle's non-disclosure policies.  But I don't think it should get in
> the way of doing whatever seems right for Debian's users and by its
> own principles.
> 

This is a very broad statement, and I suggest you add _specifics_ to
any accusations that somehow having MySQL in the archive is bad for
Debian's principles. Which principles are not being upheld? The users
are getting well maintained Free software. The fact that it's being
done a way that we all think is silly (and make no mistake, I think it
is one of the silliest things I've ever seen in open source software)
isn't a valid reason to reject it. It just feels good to say.

If you want to kick them out, by all means, do it. But have an actual
reason please.

Next IRC meeting

[Jonathan Wiltshire]

The next release team IRC meeting will be held:

oftc/#debian-release 2016-02-24 19:00UTC

Agenda on titanpad.

Minutes of previous:
http://meetbot.debian.net/debian-release/2016/debian-release.2016-01-27-18.59.html

(owing to an administrative error, there are no topic sections in the 
minutes)


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: giflib_4.1.6-11+deb8u1_mips.changes
  ACCEPT

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: giflib_4.1.6-10+deb7u1_mips.changes
  ACCEPT

Bug#812887: transition: iptables

[Arturo Borrero Gonzalez]

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

Dear release team,

iptables 1.6.0 has been released and we plan to include it in debian.

The libxtables binary package name has been changed from libxtables10 to
libxtables11. However, this change seems to affect very few packages (if any).

Since an upload to experimental was done, a transition was set up [0].
Following the instructions [1] for transition, I've build-tested all
reverse build-deps of iptables and they seem to build simply fine:

 * xtables-addons: no problems
 * connman: no problems
 * west-chamer: no problems

So, I ask for a transition slot to upload iptables 1.6.0 to unstable.

[0] https://release.debian.org/transitions/html/auto-iptables.html
[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Ben file:

title = "iptables";
is_affected = .build-depends ~ "iptables-dev" | .build-depends ~ "libxtables10" 
| .build-depends ~ "libxtables11";
is_good = .build-depends ~ "libxtables11";
is_bad = .build-depends ~ "libxtables10";

Bug#812887: transition: iptables

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 27/01/16 16:58, Arturo Borrero Gonzalez wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> iptables 1.6.0 has been released and we plan to include it in debian.
> 
> The libxtables binary package name has been changed from libxtables10 to
> libxtables11. However, this change seems to affect very few packages (if any).
> 
> Since an upload to experimental was done, a transition was set up [0].
> Following the instructions [1] for transition, I've build-tested all
> reverse build-deps of iptables and they seem to build simply fine:
> 
>  * xtables-addons: no problems
>  * connman: no problems
>  * west-chamer: no problems
> 
> So, I ask for a transition slot to upload iptables 1.6.0 to unstable.

You can go ahead.

Cheers,
Emilio

Processed: Re: Bug#812887: transition: iptables

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #812887 [release.debian.org] transition: iptables
Added tag(s) confirmed.

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

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Tianon Gravi]

On 26 January 2016 at 22:05, Adam D. Barratt  wrote:
> Is it just the manpage that's the issue? i.e. do the packages published
> as part of the point release include the actual security fix?

Yeah, it's just the manpage that's the issue.  Still using #812566 to
track down the _exact_ details, but the patch applied (and I verified
via the buildd log that it was indeed applied) changed both the source
and the man page source XML for the vuln -- as it turns out, there is
a static copy of the man page that also needed to be patched, but if
some set of conditions is met (likely some extra package being
installed at build time), the man page is instead generated from the
XML (as it really ought to be IMO).  This building-manpages-from-XML
happened for amd64 on my machine (since I figured I probably can't
source-only upload to pu's NEW), which is what caused the discrepancy.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Robie Basak]

Hi Niels,

Thank you for your considered response.

On Tue, Jan 26, 2016 at 11:50:08PM +, Niels Thykier wrote:
> I do not feel the listed options accurately reflect the issues /
> concerns in play.  As *I see it*, these are the options:
> 
>   1) Default to MySQL with MariaDB also available /!\
> 
>   2) Default to MariaDB with MySQL also available
> 
>   3) Only MySQL available, MariaDB removed from testing /!\
> 
>   4) Only MariaDB available, MySQL removed from testing.
> 
>   5) Further discussion / delayed decision

I'm fine with a decision that chooses from one of these instead. One
question though. What does "default" mean? Right now there is no
default. If you ask for mysql-server you get that, and likewise for
mariadb-server. Maintainers of dependent packages choose which one they
prefer (something like Depends: mysql-server-5.6 |
virtual-mysql-server). So if the release team were to decide to change
the "default", what would that mean technically, and what requirements
would be placed on dependent package maintainers?

> The options marked with /!\ are de facto *no-go* for me if/given the
> security team is unwilling to provide security support for MySQL[2].

I agree, but I'm focusing on the "if/given" part of your statement here.
I appreciate that you pointed it out explicitly. I see a couple of
issues here:

1) I was pleased to hear from the Debian security team that we may be
able to make some progress on the security disclosure issue soon. If
this happens and the matter gets resolved, then presumably your /!\
options will no longer be a no-go?

2) My understanding of the situation, given Otto's recent enquiries
about CVEs, is that the underlying problem will not go away for Debian
if MySQL is removed from testing, since MariaDB will still be affected.
So the security team would presumably have to publish the same caveat
for MariaDB in the release notes. Therefore by your logic MariaDB would
have to be *no-go* as well. Clearly we can't drop both, so I think we
will better serve Debian by taking the opportunity we have to resolve
the situation by getting Oracle to give Debian what it needs, for the
sake of both MySQL and MariaDB.

So I ask that you stick with the status quo for now. If however the
security disclosure is not resolved after giving Oracle a reasonable
opportunity, then I will have no reason to object further.

>  * This is a transition I want early rather than rushed earlier.
>- It can trivially end up taking 6 months of calender time before it
>  is complete.  This is uncomfortably close to the transition
>  deadline

I fully appreciate the difficulty in timing we have here. From the dates
in my summary I hope you can understand why I feel that this matter has
been blocked on you, and not the maintainers, for quite a few months
now. So it doesn't seem right that MySQL gets dropped or disadvantaged
because of this.

Thanks,

Robie


signature.asc
Description: Digital signature

Re: Fixing the armhf linker path

[Aurelien Jarno]

On 2015-12-16 23:37, Emilio Pozuelo Monfort wrote:
> On 16/12/15 23:30, Aurelien Jarno wrote:
> > At the beginning of the armhf port the hard-float dynamic linker has
> > been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it
> > has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have
> > changed it in Debian, and added a patch to the glibc [2] to temporarily
> > support both paths, until all the packages have been rebuilt with the
> > new path.
> >   
> > However we failed to do it for Wheezy. We also failed to do it for
> > Jessie. So let's do it for Stretch, so that we can drop the glibc
> > patches in Buster, and ensure binary compatibility with other
> > distributions.
> > 
> > For that we first need to binNMU the packages which have not been
> > rebuilt since the dynamic linker change in unstable (see the list at
> > the end of the mail). Then we can have a look at getting all of them 
> > migrated to testing.
> > 
> > Any comments or objections?
> 
> No problem for me, but let's wait for the rebuilds at least until after the 
> Perl
> transition.

I have scheduled the binNMUs sometimes ago, and upgraded a few bugs to
RC when the build failed. I have also asked for packages removal for
really buggy and unmaintained packages (thanks to the ftpmasters for the
quick removals). We now have a much better situation:


stretch
---
masqmail_0.2.30-1 (sid version buggy)
mutextrace_0.1-1 (sid version buggy)
stun_0.96.dfsg-6 (sid version buggy)
teem_1.11.0~svn5226-1 (sid version buggy)

sid
---
argus-client_2.0.6.fixes.1-3 (FTBFS #800260)
apf_0.8.4-1 (FTBFS #803889)
bing_1.1.3-2 (FTBFS #800300)
cone_0.89-1 (FTBFS #804334)
cuba_3.0+2024-2 (FTBFS #791516)
icebreaker_1.21-11 (FTBFS  #800281)
icmpush_2.2-6 (FTBFS #800282)
ipkungfu_0.6.1-6 (bd-uninstallable #733693)
isakmpd_20041012-7.2 (FTBFS #749354)
kcc_2.3-12 (FTBFS #800251)
libprinterconf_0.5-12 (FTBFS #808622)
nget_0.27.1-11 (FTBFS #746885)
sslscan_1.8.2-2 (FTBFS #804616)
wmpinboard_1.0-11 (FTBFS #800193)


The 4 remaining packages in stretch have the wrong linker path, but the
fixed version in sid can't migrate as the packages have RC bugs. I guess
we should binNMU them in stretch.

Most of the packages in sid should probably be removed from the archive.
I don't plan to do any NMU there as it would show I have some interest
in the packages, which I don't. It's probably better to wait a bit more
to make sure nobody has any interest and ask for their removal in a few
months. Anyway they aren't really a problem from the libc point of view,
as they won't be released with stretch.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Kernel version for stretch

[Ben Hutchings]

I'm currently maintaining the Linux 3.2 longterm branch and will do so
until May 2018 (end of wheezy LTS).  I will also be taking over
maintenance of the 3.16 longterm branch soon, and assuming there is a
jessie LTS I will do so until April 2020.

For stretch, I would very much like to choose a kernel version for
stretch that gets longterm maintenance by Greg Kroah-Hartman.  That
lasts 2 years from release, after which someone else (maybe me) can
take over.  I do not want to maintain 3 kernel longterm branches at a
time, and there is consensus among the stable maintainers that it is
undesirable to have more than one longterm branch started per year.

Greg's new policy is to pick the first Linus release in each year for
longterm maintenance.  The longterm branch for 2016 is based on Linux
4.4, released at the end of week 1 (10th January).  By the time stretch
is released, 4.4 will be quite old (the same problem squeeze and wheezy
had, requiring many driver backports).

Based on the current 9 week upstream release cycle, the longterm branch
for 2017 will presumably be based on Linux 4.10, released at the end of
week 3 (22nd January 2017).  That's well after the planned stretch
freeze date so I don't see how it can be included.

Can you suggest any way to resolve this?

(By the way, I haven't seen the stretch freeze dates announced
anywhere; I only found them on a wiki page.  A new "Bits from the
release team" seems to be overdue.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


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

Bug#812894: Acknowledgement (nmu: lush and tulip, oprofile, tarantool)

[Matthias Klose]

please wait with this until 2.26-2 is in the archive, and then use this version.

Bug#812894: nmu: lush and tulip, oprofile, tarantool

[Matthias Klose]

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

please binNMU lush and tulip, oprofile, tarantool using binutils 2.26.

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Robie Basak]

Hi Otto,

I agree entirely with the principles you presented, and thank you for
making them.

You also made some technical arguments (and I appreciate that they are
technical and thus valuable and actionable), which I would like to
rebut.

On Wed, Jan 27, 2016 at 12:45:59AM +0200, Otto Kekäläinen wrote:
> - Quality: mysql-5.6 has 135 open bugs despite never being part of a
> Debian release and thus having exposure to the big Debian user masses.
> Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
> which of 5 were filed by myself as TODO items with priority wishlist,
> and it actually ships in Jessie for big audience.

Many bugs were mass transferred from src:mysql-5.5, predate any recent
work, and haven't had any recent activity. On the other hand, MariaDB
being a relatively new package would be expected to have far fewer of
this class of bugs. I have prioritised fixing bigger issues first, over
going through the ancient bugs.

So I think this is an accurate reflection of how well MySQL was
maintained in the past, but not how it is maintained now.

> - Quality: mysql-5.6 ships the same version number
> libmysqlclient.so.18 as 5.5 but the ABI is different and according to
> investigations by Robie Basak going back September 2014 [1] the
> upgrade might break something, and while it is now partially remedied,
> the ABI bump has never been done, the symbols file to track this all
> is missing from the packaging, and there is a Lintian override to keep
> Lintian quiet about the lack of a symbols file [2]

I think this is an excellent example of how well MySQL is maintained and
how well upstream are working with us to sort things out. I was diligent
in finding the problem and then upstream got involved. Upstream did all
the investigatory work to figure out how this impacts Debian, worked
with Debian on deciding what we should do about it, and have now fixed
this and the symbols exported in 5.7 properly. If MySQL gets to stay, I
expect to have 5.7 in Debian soon. The lintian override is ancient,
inherited and I'm happy to remove it.

I tend to focus my efforts on the future, doing the extra thing now to
solve the problem forever. This does mean that it appears poorer in the
short term. I think this should translate to "diligently
well-maintained", not "badly maintained".

> - Quality: mysql-5.6 only runs ~600 tests as part of their Debian
> build, while MariaDB has 4000+ tests, making MySQL test coverage much
> smaller than the MariaDB one, thus catching less issues on many of the
> Debian platforms as Oracle MySQL probalby don't test those at all
> in-house.

This was a deliberate decision to speed up maintenance velocity. I
worked with Oracle to figure out which tests were likely to be useful
from a package maintenance perpsective, and which weren't. We documented
this in debian/README.maintainer. The number of tests run doesn't really
help quantify usefulness. If the release team disagrees with this
principle, I'd be happy to reverse it.

>  - Activity: Since the beginning of 2015 mysql-5.6 packaging master
> branch in Debian unstable has had 118 commits by 12 authors, while the
> mariadb-10.0 master branch in Debian has had in the same time 231
> commits by 14 authors (authors don't include patch submissions and
> translators). I would claim MariaDB is more actively maintained. Note
> that uploads are done by Robie and me for mysql-5.6 and mariadb-10.0,
> who both are DMs. The team does not have any really active DDs at the
> moment, which is a problem for both packages.

I've been working on what I feel are the big issues first, which take
considerable thought and care but don't result in many commits of lines
of code changed. Right now my focus is on 5.7 and also the "flags issue"
that also affects MariaDB. So I don't think it's fair to use a commit
number statistic to determine maintenance activity.

Robie


signature.asc
Description: Digital signature

Processed: unblock 650601 with 810181

[Debian Bug Tracking System]

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

> unblock 650601 with 810181
Bug #650601 [release.debian.org] transition: libpng 1.6
650601 was blocked by: 662437 809870 809860 809959 662473 810209 810195 810165 
809880 809896 662411 810179 662554 662492 809905 810166 810183 649546 809938 
809889 809869 810202 809956 809958 810194 662523 809872 662556 809949 810191 
809911 809908 810173 662444 809953 809952 809879 809907 662421 636998 809913 
811370 649557 742560 810169 809909 809957 649971 809943 809882 810203 809865 
648129 809951 810192 809863 649552 810185 649798 810170 810182 809945 810174 
810205 810197 809868 662416 741901 810167 742569 809937 810186 742559 638812 
809946 809887 809859 809962 809940 810204 635945 809939 809871 809954 809904 
809935 650563 662443 662550 810196 809933 809910 809961 809936 741894 741891 
809960 809942 810171 648131 810193 662314 810200 810176 650489 662273 810201 
636004 662465 810188 810180 809948 810207 809833 810178 662407 810095 810206 
809866 809861 635704 648126 809885 810190 809891 641892 809955 809898 810189 
810177 809835 809883 809884 662381 809941 650581 809864 809862 662334 662476 
810001 635946 809867 810172 809886 809895 662522 662566 809890 809874 809873 
809899 809893 809906 809897 809950 650484 809892 809894 662530 641889 809881 
743391 809944 642265 650567 810168 650483 650571 809921 810175 810187 809836 
810208 809934 809888 649547 809947 810181 742655 809878
650601 was blocking: 649556 649973
Removed blocking bug(s) of 650601: 810181
> # does not block the transition
> thanks
Stopping processing here.

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

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Niels Thykier]

Robie Basak:
> Hi Niels,
> 
> Thank you for your considered response.
> 
> On Tue, Jan 26, 2016 at 11:50:08PM +, Niels Thykier wrote:
>> I do not feel the listed options accurately reflect the issues /
>> concerns in play.  As *I see it*, these are the options:
>>
>>   1) Default to MySQL with MariaDB also available /!\
>>
>>   2) Default to MariaDB with MySQL also available
>>
>>   3) Only MySQL available, MariaDB removed from testing /!\
>>
>>   4) Only MariaDB available, MySQL removed from testing.
>>
>>   5) Further discussion / delayed decision
> 
> I'm fine with a decision that chooses from one of these instead. One
> question though. What does "default" mean? Right now there is no
> default. If you ask for mysql-server you get that, and likewise for
> mariadb-server. Maintainers of dependent packages choose which one they
> prefer (something like Depends: mysql-server-5.6 |
> virtual-mysql-server). So if the release team were to decide to change
> the "default", what would that mean technically, and what requirements
> would be placed on dependent package maintainers?
> 

 * No package may (unconditionally) require the presence of the
   non-default option
 * No package may pull the "non-default" choice in the absence of an
   active choice from the user to install the non-default choice.

Anyway, this is possibly "too short", but it should give the general
direction.

>> The options marked with /!\ are de facto *no-go* for me if/given the
>> security team is unwilling to provide security support for MySQL[2].
> 
> I agree, but I'm focusing on the "if/given" part of your statement here.
> I appreciate that you pointed it out explicitly. I see a couple of
> issues here:
> 
> 1) I was pleased to hear from the Debian security team that we may be
> able to make some progress on the security disclosure issue soon. If
> this happens and the matter gets resolved, then presumably your /!\
> options will no longer be a no-go?
> 

If the security team was to publish it, Oracle was to implement and the
security was to accept Oracle's implementation in due time...

However, I personally find this very unlikely given:

 * The security team has (in my eyes) basically veto'ed on security
   support on MySQL.

 * Oracle has a very unfortunate track record in this area.

 * There will be a phase after the Oracle implemented their revised
   policy, where the security team will want to evaluate it.
   - In practise, it will probably take a couple of iterations to get
 right.

> 2) My understanding of the situation, given Otto's recent enquiries
> about CVEs, is that the underlying problem will not go away for Debian
> if MySQL is removed from testing, since MariaDB will still be affected.
> So the security team would presumably have to publish the same caveat
> for MariaDB in the release notes. Therefore by your logic MariaDB would
> have to be *no-go* as well. Clearly we can't drop both, so I think we
> will better serve Debian by taking the opportunity we have to resolve
> the situation by getting Oracle to give Debian what it needs, for the
> sake of both MySQL and MariaDB.
> 

It is unfortunate that Oracle's policy will cause issues for security
patches for MariaDB as well.  However:

 * I do *not* see a "veto" against security support on MariaDB.

 * I *do* see one against MySQL, which made for my *no-go* mark.

> So I ask that you stick with the status quo for now. If however the
> security disclosure is not resolved after giving Oracle a reasonable
> opportunity, then I will have no reason to object further.
> 

Unfortunately, we have tried this for several months now and basically
we have not progressed on this issue.  While 5) *is* an option, I am not
convinced the situation will change for the better.

>>  * This is a transition I want early rather than rushed earlier.
>>- It can trivially end up taking 6 months of calender time before it
>>  is complete.  This is uncomfortably close to the transition
>>  deadline
> 
> I fully appreciate the difficulty in timing we have here. From the dates
> in my summary I hope you can understand why I feel that this matter has
> been blocked on you, and not the maintainers, for quite a few months
> now. So it doesn't seem right that MySQL gets dropped or disadvantaged
> because of this.
> 
> Thanks,
> 
> Robie
> 

I appreciate that the release team failed on action item several months
back and have not been very proactive in the communication.  And I am
sorry that it has (and probably will) inconvenience you and MySQL upstream.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Clint Byrum]

Excerpts from Holger Levsen's message of 2016-01-26 02:45:32 -0800:
> Hi,
> 
> On Dienstag, 26. Januar 2016, Clint Byrum wrote:
> > However, I have confidence that our friends in the MySQL engineering
> > team can frame the loss of the last foothold for MySQL in Linux distros
> > as a direct path toward _less_ money for Oracle.
> 
> why do you think so? I mean, doesn't less Mysql mean more OracleDB, thus 
> *more* money for Oracle? ;)
> 
> (I'm not saying that's the case either, I was merely explaining why I'm 
> surprised abour your confidence.)
> 

I'm not so confident it will be _enough_ money to change the security
policy. However, I am confident that a decision has already been made
to support Debian and Ubuntu continuing to ship MySQL. There is direct
evidence of it in the form of Oracle engineers directly contributing to
the packaging effort.

I won't speculate too much on why they believe this, but I imagine one
reason is simple: If Ubuntu and Debian don't have them, it will make
them harder to find, and might push people to select PostgreSQL, or
"anything else that isn't in the distro" when making choices.

> > So if we can just be
> > patient with them, and actually facilitate their participation in this
> > grand community of Debian, it's possible that a compromise can be found.
> 
> Oracle bought Sun in 2010, so personally I don't see how we should be more 
> patient, especially because… the following aint anything new nor special…
>  

Have you ever seen how slowly things change in large corporations?

I know it's hard to believe this, but even _Debian_ moves slowly
sometimes.

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013196.html

That is the first we talked about removing MySQL for these problems.
Oracle responded directly and has remained engaged since then. That they
haven't changed everything is largely a function of us not being
extremely focused in what we're asking for.

> > Meanwhile, I'd like to challenge someone to point to the exact requirement
> > from any official source affiliated with Debian as to what constitutes
> > an acceptable level of disclosure for a package to remain in the archive.
> 
> sigh.
> 
> go to https://security-tracker.debian.org/tracker/source-package/mysql-5.5 
> and 
> count occurances of the string "Unspecified vulnerability", if you do this 
> with iceweasel it will not even tell you the exact number of matches, just 
> "over 100".
> 
> Now go to 
> https://security-tracker.debian.org/tracker/source-package/mysql-5.6 
> and do the same. The count is at 66 here, but the counter only started 2015.
> 
> So, once again: the exact requirement to be considered is: publish specific 
> information about specific vulnerabilities. Provide meaningful patches for 
> each specific issue.
> 
> Don't release updates with 23 or 42 fixes bundled together with basically no 
> explainations whatsoever.
> 
> And/but this is nothing new and it's very very tiring having to explain this, 
> again and again and still in 2016. It's not like we havent discussed this in 
> 2014, 2013, 2012 and probably also 2011 and 2010.
> 

Holger, I very much value your opinions, and I _hope_ for the same things
from any open source software project. However, you wouldn't have to
explain it if it were written down somewhere as an actual policy. If it
is, please point us to that, so we can point Oracle to it, and provide
them with an ultimatum.

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Steven Chamberlain]

I'll try to make this my last intervention in this thread.  Because
it's not my decision, or area of responsibility, and I likely won't be
one of the people having to do the work when a decision is made, but...

Clint Byrum wrote:
> most of these CVE's would remain fully undisclosed and unfixed in both
> MySQL and MariaDB if the MySQL engineering team or customers had not
> found them.

Sorry, this is not compelling.  As long as Oracle sells MySQL to
enterprise, it *must* do these things, and release source code to
satisfy legal obligations of what is a GPL codebase.  It is really only
doing the bare minimum in that regard.  It was also a condition of
Oracle's acquisition of MySQL AB:

"As part of the negotiations with the European Commission, Oracle
committed that MySQL server will continue until at least 2015 to use the
dual-licensing strategy long used by MySQL AB, with proprietary and GPL
versions available"
according to https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions

Oracle may still drop MySQL support like a hat due to market conditions,
regardless of whether Debian has already shipped it by then.

And apart from sponsoring Debian packaging work, Oracle seems
conspicuously missing from:
http://debconf16.debconf.org/sponsors.html
http://debconf15.debconf.org/
https://www.debian.org/mirror/sponsors
https://www.freexian.com/en/services/debian-lts.html

Clint Byrum wrote:
> [...] if it were written down somewhere as an actual policy. [...]

Norvald H. Ryeng wrote:
> Tell us exactly what you want, in detail. If you don't then I don't
> think your position is reasonable.

Robie Basak wrote:
> So please: the security team needs to engage directly with Oracle by
> responding to Norvald's email and enumerating exactly what is wrong.

I don't see that Debian has to do that, at all.  Other upstream projects
seem to 'just get it', so Oracle management is really expecting special
treatment.  IMHO I respond to bad dealings with a company by shopping
elsewhere, not helping them improve their business practices.

This is perhaps more significant than a mere decision over what goes
into the next release.  I see a really fantastic, rare opportunity for
Debian to take a moral stand against Oracle for shameful mistreatment
of free software to date.  rock on \m/

Niels Thykier wrote:
> I appreciate that the release team failed on action item several
> months back and have not been very proactive in the communication.
> And I am sorry that it has (and probably will) inconvenience you and
> MySQL upstream.

I do have personal sympathy for Debian contributors who became entwined,
by their career choices, with the business preferences of Oracle and
Canonical.  And the team of MySQL developers who must work under
Oracle's non-disclosure policies.  But I don't think it should get in
the way of doing whatever seems right for Debian's users and by its
own principles.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#812894: Acknowledgement (nmu: lush and tulip, oprofile, tarantool)

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On 2016-01-27 17:25, Matthias Klose wrote:
please wait with this until 2.26-2 is in the archive, and then use this 
version.


Please poke this bug when that happens.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Processed: Re: Bug#812894: Acknowledgement (nmu: lush and tulip, oprofile, tarantool)

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #812894 [release.debian.org] nmu: lush and tulip, oprofile, tarantool
Added tag(s) moreinfo.

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

Bug#812894: Acknowledgement (nmu: lush and tulip, oprofile, tarantool)

[Matthias Klose]

Control: tag -1 - moreinfo

On 27.01.2016 22:41, Jonathan Wiltshire wrote:

Control: tag -1 moreinfo

On 2016-01-27 17:25, Matthias Klose wrote:

please wait with this until 2.26-2 is in the archive, and then use this version.


Please poke this bug when that happens.


was already in the archive.

Processed: Re: Bug#812894: Acknowledgement (nmu: lush and tulip, oprofile, tarantool)

[Debian Bug Tracking System]

Processing control commands:

> tag -1 - moreinfo
Bug #812894 [release.debian.org] nmu: lush and tulip, oprofile, tarantool
Removed tag(s) moreinfo.

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

Bug#812961: jessie-pu: package php-net-ldap2/2.0.12-1+deb8u1

[Prach Pongpanich]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi,

  
Please accept the fixes for php5/5.6.17+dfsg-0+deb8u1 upgrade break 
php-net-ldap2 in jessie (#812892).

Source debdiff attached.

Regards,
Prach
diff -Nru php-net-ldap2-2.0.12/debian/changelog php-net-ldap2-2.0.12/debian/changelog
--- php-net-ldap2-2.0.12/debian/changelog	2013-07-18 22:31:10.0 +0700
+++ php-net-ldap2-2.0.12/debian/changelog	2016-01-27 13:07:14.0 +0700
@@ -1,3 +1,9 @@
+php-net-ldap2 (2.0.12-1+deb8u1) jessie; urgency=medium
+
+  * Add Fix_Fatal_error_with_PEAR_1.10.0.patch (Closes: #812788)
+
+ -- Prach Pongpanich   Wed, 27 Jan 2016 13:05:48 +0700
+
 php-net-ldap2 (2.0.12-1) unstable; urgency=low
 
   [ Prach Pongpanich ]
diff -Nru php-net-ldap2-2.0.12/debian/gbp.conf php-net-ldap2-2.0.12/debian/gbp.conf
--- php-net-ldap2-2.0.12/debian/gbp.conf	2013-07-18 22:31:10.0 +0700
+++ php-net-ldap2-2.0.12/debian/gbp.conf	2016-01-27 10:02:20.0 +0700
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = upstream-sid
-debian-branch = debian-sid
+debian-branch = debian/jessie
 pristine-tar = True
 
 [git-buildpackage]
diff -Nru php-net-ldap2-2.0.12/debian/patches/Fix_Fatal_error_with_PEAR_1.10.0.patch php-net-ldap2-2.0.12/debian/patches/Fix_Fatal_error_with_PEAR_1.10.0.patch
--- php-net-ldap2-2.0.12/debian/patches/Fix_Fatal_error_with_PEAR_1.10.0.patch	1970-01-01 07:00:00.0 +0700
+++ php-net-ldap2-2.0.12/debian/patches/Fix_Fatal_error_with_PEAR_1.10.0.patch	2016-01-27 11:24:30.0 +0700
@@ -0,0 +1,55 @@
+From df99b63de9b2459b5e0cd94bd26f38f3010f992e Mon Sep 17 00:00:00 2001
+From: Christian Weiske 
+Date: Mon, 26 Oct 2015 22:55:20 +0100
+Subject: [PATCH] Fix #20969: Fatal error with PEAR 1.10.0 / constructor
+ visiblity
+
+PEAR's constructor is public, so the constructor of PEAR-extending classes
+also needs to be public
+
+See http://pear.php.net/bugs/20969
+---
+ Net_LDAP2-2.0.12/Net/LDAP2/Entry.php   | 2 +-
+ Net_LDAP2-2.0.12/Net/LDAP2/RootDSE.php | 2 +-
+ Net_LDAP2-2.0.12/Net/LDAP2/Schema.php  | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/Net_LDAP2-2.0.12/Net/LDAP2/Entry.php b/Net_LDAP2-2.0.12/Net/LDAP2/Entry.php
+index aedb3f6..9b9d67c 100644
+--- a/Net_LDAP2-2.0.12/Net/LDAP2/Entry.php
 b/Net_LDAP2-2.0.12/Net/LDAP2/Entry.php
+@@ -146,7 +146,7 @@ class Net_LDAP2_Entry extends PEAR
+ * @access protected
+ * @return none
+ */
+-protected function __construct(&$ldap, $entry = null)
++public function __construct(&$ldap, $entry = null)
+ {
+ $this->PEAR('Net_LDAP2_Error');
+ 
+diff --git a/Net_LDAP2-2.0.12/Net/LDAP2/RootDSE.php b/Net_LDAP2-2.0.12/Net/LDAP2/RootDSE.php
+index dd30eef..0693d95 100644
+--- a/Net_LDAP2-2.0.12/Net/LDAP2/RootDSE.php
 b/Net_LDAP2-2.0.12/Net/LDAP2/RootDSE.php
+@@ -41,7 +41,7 @@ class Net_LDAP2_RootDSE extends PEAR
+ *
+ * @param Net_LDAP2_Entry &$entry Net_LDAP2_Entry object of the RootDSE
+ */
+-protected function __construct(&$entry)
++public function __construct(&$entry)
+ {
+ $this->_entry = $entry;
+ }
+diff --git a/Net_LDAP2-2.0.12/Net/LDAP2/Schema.php b/Net_LDAP2-2.0.12/Net/LDAP2/Schema.php
+index ecc3b69..c5e298a 100644
+--- a/Net_LDAP2-2.0.12/Net/LDAP2/Schema.php
 b/Net_LDAP2-2.0.12/Net/LDAP2/Schema.php
+@@ -109,7 +109,7 @@ class Net_LDAP2_Schema extends PEAR
+ *
+ * @access protected
+ */
+-protected function __construct()
++public function __construct()
+ {
+ $this->PEAR('Net_LDAP2_Error'); // default error class
+ }
diff -Nru php-net-ldap2-2.0.12/debian/patches/series php-net-ldap2-2.0.12/debian/patches/series
--- php-net-ldap2-2.0.12/debian/patches/series	1970-01-01 07:00:00.0 +0700
+++ php-net-ldap2-2.0.12/debian/patches/series	2016-01-27 10:04:15.0 +0700
@@ -0,0 +1 @@
+Fix_Fatal_error_with_PEAR_1.10.0.patch


signature.asc
Description: PGP signature

Bug#810568: transition: openexr

[Matteo F. Vescovi]

Hi Emilio!

On 2016-01-27 at 11:25 (CET), Emilio Pozuelo Monfort wrote:
> Do rdeps build fine against the new versions of the libraries?

Now I can say "Yes, they do" ;-)

The only missing piece is aqsis, which can be NMUed easily if its
maintainer doesn't reply to our request for an updated revision using
the patch applied in ArchLinux (that fixes the problem with OpenEXR
2.x) in time for the transition start.
I've already tested it both in unstable[1] (built against actual
ilmbase/openexr packages in unstable/sid) and experimental[2] (built
against these brand new ilmbase/openexr 2.2.0).

So, do you think it can be a good time now to start this long-awaited
transition?

Thanks in advance.

Cheers.

[1] http://debomatic-amd64.debian.net/distribution#unstable/aqsis/1.8.2-2.1/
[2] http://debomatic-i386.debian.net/distribution#experimental/aqsis/1.8.2-2.1/

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Norvald H. Ryeng]

On Tue, 26 Jan 2016 23:45:59 +0100, Otto Kekäläinen  wrote:


Examples of technical arguments I'd prefer to use instead of general
disgust of Oracle arguments:

- Quality: mysql-5.6 has 135 open bugs despite never being part of a
Debian release and thus having exposure to the big Debian user masses.
Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
which of 5 were filed by myself as TODO items with priority wishlist,
and it actually ships in Jessie for big audience.


I see 113 bugs in src:mysql-5.6 [1], but, OK, it's the same ballpark. Most  
of those are bugs filed against older MySQL versions. If you instead look  
at mysql-server-5.6 [2], you'll get a more accurate number: 12. Could the  
list be cleaned of old, irrelevant bug reports from MySQL 4.1, 5.0 and 5.1  
packaging? Yes, absolutely. But they're not really bothering us in the  
daily work, so other tasks have been prioritized.



- Quality: mysql-5.6 ships the same version number
libmysqlclient.so.18 as 5.5 but the ABI is different and according to
investigations by Robie Basak going back September 2014 [1] the
upgrade might break something, and while it is now partially remedied,
the ABI bump has never been done,


The major version is the same because they were supposed to be compatible.  
However, a small bug squeezed through in a little used feature, and that  
is why they're not fully compatible, and that's what stopped us from  
upgrading to 5.6 in jessie. It was analyzed thoroughly by upstream, and  
the risk of breaking anything is very small. Still, we erred on the safe  
side and didn't upgrade to 5.6 in jessie.


The major number 19 has been reserved for fixing this (which is why MySQL  
5.7 bumps to libmysqlclient.so.20), but it was decided that the downside  
of bumping the version number is greater than the benefits. Basically,  
you'll have to recompile all applications instead of a few that break  
(none of which are in Debian). It's been coordinated with upstream, and  
Debian is free to bump the version number to 19 if wanted.



the symbols file to track this all
is missing from the packaging, and there is a Lintian override to keep
Lintian quiet about the lack of a symbols file [2]


The problem with adding a symbol file is that the library exports more  
symbols than it should, so there's a lot of noise that looks like ABI  
incompatibility, while it isn't if you're looking at the symbols that are  
actually used by clients. The list of exported symbols can be restricted  
in 5.6, but that is definitely something that calls for a major number  
bump, which is why it hasn't been done.


Libmysqlclient in MariaDB has the same problem. There are build options  
that will restrict the list of exported symbols. If you use those, you'll  
get a library that exports a much smaller list of symbols, but without  
bumping the major version of the library, so again you're stuck with  
compatibility issues.


MySQL upstream did a library cleanup in 5.7 which fixed this, so in 5.7  
packaging we can add a symbols file. If we bump the 5.6 library to version  
19, we can do it in 5.6 too.



- Quality: mysql-5.6 only runs ~600 tests as part of their Debian
build, while MariaDB has 4000+ tests, making MySQL test coverage much
smaller than the MariaDB one, thus catching less issues on many of the
Debian platforms as Oracle MySQL probalby don't test those at all
in-house.


It was decided at the packaging sprint in London in December 2014 that the  
test runs should be reduced in order to reduce build time in Debian. Also,  
some timing sensitive tests are skipped to avoid spurious failures on VMs.  
This was done after consulting the upstream QA team, and the selected set  
of tests is believed to be enough to uncover bugs that may be introduced  
in packaging. A larger set of tests can be run by setting  
DEB_BUILD_OPTIONS to "fulltest", which will run more or less the same  
tests that are run per push upstream (still not the entire test suite).


Upstream would of course not mind if the full test suite with thousands of  
test was run after each build, but it would take many, many hours.


Regards,

Norvald H. Ryeng

[1]  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mysql-5.6;ordering=normal;archive=0;repeatmerged=0#_0_6_0

[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mysql-server-5.6

Bug#812881: wheezy-pu: package gummi/0.6.3-1.2+deb7u2

[Daniel Stender]

/aham/.cache/gummi/.relative-import-test.tex.synctex.gz.
Transcript written on /home/aham/.cache/gummi/.relative-import-test.tex.log.


Please see the attached diff for changes between deb7u1 and deb7u2. I've build
against Oldstable with Sbuild [2]. 0.6.3-1.2+deb7u1 is currently pending [3], I 
would
guess it just could be replaced in the pending state?

Thanks,
DS

[0] https://bugs.debian.org/812577 (gummi: relative import paths couldn't be 
used)

[1] https://github.com/alexandervdm/gummi/commit/4ad6486

[2] 
http://www.danielstender.com/buildlogs/gummi_0.6.3-1.2+deb7u2_amd64-20160127-1502.build

[3] https://bugs.debian.org/806724 (wheezy-pu: package gummi/0.6.3-1.2+deb7u1)

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

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

- -- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWqNkOAAoJEBXgmvTfUYLIIpQQAKhttjBceHJYmPtd9Pb0QErL
lGWlg2kbwKZcPv/HI9Aq+pRBLp2u3P2KrG0vkxsFXePx+mXlg2BKukLeJJP7N5w1
aJyne6op//UqqdEOPENLeUH/tUAtfvOWdrN8okI96idrRl6kHVTJmXhyTdyEC9S+
pVET6hPLjCsmBnkQrdD7BfEO/MWQlGPNwTCX6DBJr0IOEdHLkM4yIDgP0PZeXtjJ
00jh47uItCx8nLvp/jwEWA2pWnAqLqYyENHDgMrJIpgAlcp76GFP4tgmEZFqhNQk
7xH+EK3GLGADp1TjNiAXAkR729qaMj52KuEtbL0dAF31afKt1vsKWewChrU8CsXv
EmZsiHPBSDIKAp1TaEAB3ASrbpnCTYZohgNIDHO5sD/KNno+QAklMseUjx+iC7sZ
qnuSITkpxdR5arUhd8n1I0vdYP+qg5sjNkf7bGPvwyjbJPLdfS88lSYMMC+rq4uZ
DxrwrNih9tU5OjfN2b0Rk/yGWOCAUtf+/Rv6CraZGJ7MaYXr4giyobsJVr53okNs
STAvMnklgLMrcoNjM+syC97lWNwp48/WNNGselBLNdQcuU4FZWG4MO7SMnQww50O
MZpXoMBUOAw6fioo2YnlL2OzD//ixx0LxibBcVMDcdwRVBO3Bh+JSuQAaFlHRsPF
GFCP1ylVWavDy9xFNfbS
=iom3
-END PGP SIGNATURE-
diff -Nru gummi-0.6.3/debian/changelog gummi-0.6.3/debian/changelog
--- gummi-0.6.3/debian/changelog	2015-11-30 14:07:51.0 +0100
+++ gummi-0.6.3/debian/changelog	2016-01-27 15:01:56.0 +0100
@@ -1,3 +1,9 @@
+gummi (0.6.3-1.2+deb7u2) oldstable; urgency=medium
+
+  * no-predictable-tmpfiles.patch: use upstream fix (Closes: #812577).
+
+ -- Daniel Stender <deb...@danielstender.com>  Wed, 27 Jan 2016 15:00:39 +0100
+
 gummi (0.6.3-1.2+deb7u1) oldstable; urgency=medium
 
   * Added no-predictable-tmpfiles.patch, fix of CVE 2015-7758 (Closes: #756432).
diff -Nru gummi-0.6.3/debian/patches/no-predictable-tmpfiles.patch gummi-0.6.3/debian/patches/no-predictable-tmpfiles.patch
--- gummi-0.6.3/debian/patches/no-predictable-tmpfiles.patch	2015-11-30 14:06:23.0 +0100
+++ gummi-0.6.3/debian/patches/no-predictable-tmpfiles.patch	2016-01-27 14:59:39.0 +0100
@@ -1,39 +1,33 @@
-Description: don't generate predictable tmpfile names if filename is given
- Quick fix for CVE-2015-7758 (#756432).
-Author: Daniel Stender <deb...@danielstender.com>
+Description: Use XDG cache dir for tmp files rather than TMPDIR.
+ Fix of CVE-2015-7758 (#756432).
+Origin: https://github.com/alexandervdm/gummi/commit/4ad6486
 Bug: https://bugs.debian.org/756432
-Forwarded: https://github.com/alexandervdm/gummi/issues/20
-Last-Update: 2015-11-29
+Last-Update: 2016-01-27
+
+--- a/src/constants.h
 b/src/constants.h
+@@ -59,7 +59,7 @@
+ #define C_CMDSEP "&&"
+ #define C_TEXSEC ""
+ #else
+-#define C_TMPDIR g_get_tmp_dir()
++#define C_TMPDIR g_build_path(G_DIR_SEPARATOR_S, g_get_user_cache_dir(), "gummi", NULL)
+ #define C_CMDSEP ";"
+ #define C_TEXSEC "env openout_any=a"
+ #endif
 
 --- a/src/editor.c
 +++ b/src/editor.c
-@@ -204,10 +204,9 @@
- gchar* base = g_path_get_basename (filename);
- gchar* dir = g_path_get_dirname (filename);
- ec->filename = g_strdup (filename);
--ec->basename = g_strdup_printf ("%s%c.%s", dir, G_DIR_SEPARATOR, base);
--ec->workfile = g_strdup_printf ("%s.swp", ec->basename);
--ec->pdffile =  g_strdup_printf ("%s%c.%s.pdf", C_TMPDIR,
--   G_DIR_SEPARATOR, base);
-+ec->basename = g_strdup (ec->fdname);
-+ec->workfile = g_strdup (ec->fdname);
-+ec->pdffile =  g_strdup_printf ("%s.pdf", ec->fdname);
- g_free (base);
- g_free (dir);
- } else {
-@@ -237,12 +236,9 @@
- if (ec->filename) {
- gchar* dirname = g_path_get_dirname (ec->filename);
- gchar* basename = g_path_get_basename (ec->filename);
--auxfile = g_strdup_printf ("%s%c.%s.aux", C_TMPDIR,
--G_DIR_SEPARATOR, basename);
--logfile = g_strdup_printf ("%s%c.%s.log", C_TMPDIR,
--G_DIR_SEPARATOR, base