Re: Debian

[José Luis González González]

On Fri, 19 Apr 2024 10:09:26 +0200
José Luis González González  wrote:

> On Fri, 19 Apr 2024 09:59:57 +0200
> José Luis González González  wrote:
> 
> > On Fri, 19 Apr 2024 09:39:02 +0200
> > José Luis González González  wrote:
> > 
> > > Good day,
> > > 
> > > There's an issue with the dash package and maintainer, and mutt as well.
> > > 
> > > I even tried to reach dash maintainer privately and he is not even on
> > > the package's field (queried by dpkg), there's someone who is obviosly
> > > fake instead: Andrej Shadura 
> > > 
> > > The issues with dash so far, that I know, is the shell was bash when I
> > > switched to dash because of bash's Stallman's "Eight Megabytes And
> > > constantly Swapping *And Spying And Boycotting*", and after I enabled
> > > "fingerd" in my personal website's server and some time passed the
> > > package returned to dash, however there's at least one obvious back
> > > door, and program is going the way of bash, preventing from using the
> > > Operating system. This has happened before, thrice recently.
> > > 
> > > Additionally the files on /usr/share/doc/dash are wrong.
> > > 
> > > The main issues of mutt that I know so far is the documentation is
> > > useless for what I needed, which is using the program, and the package,
> > > that was installed, is missing from my computer, besides the maintainer
> > > being subversive as well.
> > > 
> > > If this is not solved I will cease to stop using Debian and Debian will
> > > die.
> > > 
> > > "Kinda or not"
> > 
> > The problems that I had in 2020 were life or death security problems
> > that prevented me to use my computer at all for almost one year. I even
> > lost my computer, had to buy another one in 2021 and reinstall
> > everything, with severe problems, that even involved having to go
> > several times to public library, and recording "the" DVD first disc
> > with non-free firmware adding it selectively from USB didn't work.
> > 
> > The problems in 2023 involved ceasing being able to use the computer
> > because of innumerable trojans, and having to resort to the public
> > library again because of the DVD that I had recorded with Debian 10.5
> > becoming subversive when I needed it to rescue my operating system and
> > turning as 11.5, which is not what I wanted at all. I ended up having
> > to record 11.5, install it, and even upgrade to 12.
> 
> There are similar issues with boa and dhttpd, and it seems Apache is going 
> that way.

Debian is finally unusable for me.

Re: Debian

[Steve McIntyre]

You've written a lot of text here in a few mails, replying to yourself
several times. This is not a positive pattern.

On Fri, Apr 19, 2024 at 11:58:18AM +0200, José Luis González González wrote:



>> There are similar issues with boa and dhttpd, and it seems Apache is going 
>> that way.
>
>nvi adds to the subversive ones, with bash, etc.

What on earth do you mean by "subversive" here??

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Re: Debian

[José Luis González González]

On Fri, 19 Apr 2024 10:09:26 +0200
José Luis González González  wrote:

> On Fri, 19 Apr 2024 09:59:57 +0200
> José Luis González González  wrote:
> 
> > On Fri, 19 Apr 2024 09:39:02 +0200
> > José Luis González González  wrote:
> > 
> > > Good day,
> > > 
> > > There's an issue with the dash package and maintainer, and mutt as well.
> > > 
> > > I even tried to reach dash maintainer privately and he is not even on
> > > the package's field (queried by dpkg), there's someone who is obviosly
> > > fake instead: Andrej Shadura 
> > > 
> > > The issues with dash so far, that I know, is the shell was bash when I
> > > switched to dash because of bash's Stallman's "Eight Megabytes And
> > > constantly Swapping *And Spying And Boycotting*", and after I enabled
> > > "fingerd" in my personal website's server and some time passed the
> > > package returned to dash, however there's at least one obvious back
> > > door, and program is going the way of bash, preventing from using the
> > > Operating system. This has happened before, thrice recently.
> > > 
> > > Additionally the files on /usr/share/doc/dash are wrong.
> > > 
> > > The main issues of mutt that I know so far is the documentation is
> > > useless for what I needed, which is using the program, and the package,
> > > that was installed, is missing from my computer, besides the maintainer
> > > being subversive as well.
> > > 
> > > If this is not solved I will cease to stop using Debian and Debian will
> > > die.
> > > 
> > > "Kinda or not"
> > 
> > The problems that I had in 2020 were life or death security problems
> > that prevented me to use my computer at all for almost one year. I even
> > lost my computer, had to buy another one in 2021 and reinstall
> > everything, with severe problems, that even involved having to go
> > several times to public library, and recording "the" DVD first disc
> > with non-free firmware adding it selectively from USB didn't work.
> > 
> > The problems in 2023 involved ceasing being able to use the computer
> > because of innumerable trojans, and having to resort to the public
> > library again because of the DVD that I had recorded with Debian 10.5
> > becoming subversive when I needed it to rescue my operating system and
> > turning as 11.5, which is not what I wanted at all. I ended up having
> > to record 11.5, install it, and even upgrade to 12.
> 
> There are similar issues with boa and dhttpd, and it seems Apache is going 
> that way.

nvi adds to the subversive ones, with bash, etc.

Re: Debian

[José Luis González González]

On Fri, 19 Apr 2024 09:59:57 +0200
José Luis González González  wrote:

> On Fri, 19 Apr 2024 09:39:02 +0200
> José Luis González González  wrote:
> 
> > Good day,
> > 
> > There's an issue with the dash package and maintainer, and mutt as well.
> > 
> > I even tried to reach dash maintainer privately and he is not even on
> > the package's field (queried by dpkg), there's someone who is obviosly
> > fake instead: Andrej Shadura 
> > 
> > The issues with dash so far, that I know, is the shell was bash when I
> > switched to dash because of bash's Stallman's "Eight Megabytes And
> > constantly Swapping *And Spying And Boycotting*", and after I enabled
> > "fingerd" in my personal website's server and some time passed the
> > package returned to dash, however there's at least one obvious back
> > door, and program is going the way of bash, preventing from using the
> > Operating system. This has happened before, thrice recently.
> > 
> > Additionally the files on /usr/share/doc/dash are wrong.
> > 
> > The main issues of mutt that I know so far is the documentation is
> > useless for what I needed, which is using the program, and the package,
> > that was installed, is missing from my computer, besides the maintainer
> > being subversive as well.
> > 
> > If this is not solved I will cease to stop using Debian and Debian will
> > die.
> > 
> > "Kinda or not"
> 
> The problems that I had in 2020 were life or death security problems
> that prevented me to use my computer at all for almost one year. I even
> lost my computer, had to buy another one in 2021 and reinstall
> everything, with severe problems, that even involved having to go
> several times to public library, and recording "the" DVD first disc
> with non-free firmware adding it selectively from USB didn't work.
> 
> The problems in 2023 involved ceasing being able to use the computer
> because of innumerable trojans, and having to resort to the public
> library again because of the DVD that I had recorded with Debian 10.5
> becoming subversive when I needed it to rescue my operating system and
> turning as 11.5, which is not what I wanted at all. I ended up having
> to record 11.5, install it, and even upgrade to 12.

There are similar issues with boa and dhttpd, and it seems Apache is going that 
way.

Re: [sylpheed:37255] Re: Debian 12 released with two RC bugs in Sylpheed

[Paul]

On Sun, 7 Apr 2024 15:18:57 +0200
José Luis González  wrote: 

> I found the report now. It's #1036799.

Yes, it looks like a temporary server issue. And you're sending via gmail now.
But again, what do you expect a package maintainer to do? It's upstream where
bugs get fixed.

Your subject is wrong, your two RC bugs are not RC bugs; in fact, they both
seem to be describing the same behaviour, and you are requesting that the
behaviour be different. i.e. they are feature requests.

The more I consider your complaints about the Debian maintainer, the less
they seem to hold water.

with regards

Paul

Re: Debian 12 released with two RC bugs in Sylpheed

[Sirius]

In days of yore (Sun, 07 Apr 2024), José Luis González thus quoth: 
> Hi,
> 
> Debian 12 was released with two Release Critical bugs I filed on May
> 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I
> found on stable, and remain, with Debian 12 released later on June 10th
> 2023.

So, bug #1036424 is a problem that when you reply to an email, it does not
set the From account properly, it uses the default account.

That is perhaps a usability defect, but it is not a critical impact defect
by any stretch of the imagination. Critical is usually reserved for things
like remote exploit, data corruption, or otherwise, you know, critical
issues.

The other bug, #1036388, has a little more meat on it, but still does not
meet the criteria of Critical. Looking at it on the scale of Critical,
Important, Medium and Low, I think it warrants Important if I understand
the problem description right. Which, correct me if I am wrong, is:
 - Configure Sylpheed with account A and sender u...@a.com
 - Configure Sylpheed with additional account B and sender u...@b.com
 - Account A is default, but we switch to account B for the session.
 - When a new mail for Account A is received, it is placed in Account B's
   folders.
Okay, that would be an annoying issue. But the bug was addressed. The
issue was resolved in Sylpheed 3.8.0~beta1-1. For all I know, the issue
was complex and non-trivial to backport to version 3.7.0. I am not the
package maintainer, nor the upstream developer, so I am not about to yell
at them when they actually produced the fix.

To put a perspective on this - I use mutt, with at least four separate
email accounts, all receiving email and ultimately pooling into my
mailserver. When I send email, I do need to check that I am actually
sending as the correct persona as mutt does guess who to send as, but it
does not always get it right. Has it led to me sending emails with the
wrong sender? Yep. And I apologise when it happens and move on, re-rending
with the correct sender.

I do not consider this to be a defect in mutt as mutt has never advertised
that it will get its guesses of who to send as 100% right when there are
more than one account configured as I have it set up.

Also - a question that is rhetorical and more food for thought:

How much are you paying for your Debian subscription and support per year?

-- 
Kind regards,

/S

Re: Debian 12 released with two RC bugs in Sylpheed

[José Luis González]

On Sun, 7 Apr 2024 13:26:49 +0200
José Luis González  wrote:

> The maintainer accumulates a lot of bugs for the package, doesn't take
> care about almost all, and when I filed a RC bug because the package
> became unusable to me he downgraded severity to important claiming it
> was just a Gmail issue, when it didn't seem so, even if it was
> just happening with Gmail. I wanted to point you to this bug number to
> provide records, but couldn't find it neither opened nor archived. The

I found the report now. It's #1036799.

Bug#1056222: REGRESSIONS! Re: debian-edu-artwork 2.12.3-2~deb12u1 flagged for acceptance

[Andreas Beckmann]

On Fri, 24 Nov 2023 14:35:19 + Adam D Barratt 
 wrote:



Package: debian-edu-artwork
Version: 2.12.3-2~deb12u1

Explanation: provide an Emerald theme based artwork for Debian Edu 12


This update causes some regressions (#1057815)
- it modifies a conffile (/etc/plymouth/plymouthd.conf)
- which actually causes dpkg prompting due to modified conffiles on 
upgrades from bullseye to bookworm+pu



Andreas

Re: Debian Kernel version and ABI in respect of #1040901

[Bastian Blank]

On Fri, Jul 14, 2023 at 04:17:34PM +0200, Ben Hutchings wrote:
> On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote:
> [...]
> > ## Proposed behaviour
> > 
> > This tries to make sure everything apart from experimental gets new
> > names and ABI on every upload.
> > 
> > * experimental:
> > Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
> > Keep ABI 6.1.0-0-arm64
> Why would that still be acceptable in experimental?

What do you mean?  We don't check for any ABI incompatibilities forever
in experimental builds.  And the signature check will refuse to load
modules not from the same build if lockdown is enabled.

So the ABI as listed in the image and the package just means it is
provided in the same package and can be upgraded directly.

We can also decide that we don't want to make it that explicit and do:

ABI/package name only includes upstream version (6.1.1) and multiple
Debian revisions of that will be incompable to each other on lockdown
systems, but may work (depending on symvers) on non-lockdown systems.

It does not happen often that we do multiple Debian revisions of most
upstream version anyway, so people will only feel that if they upgrade
directly from backports to a different release of the same version.

Bastian

-- 
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8

Re: Debian Kernel version and ABI in respect of #1040901

[Bastian Blank]

Hi

On Thu, Jul 13, 2023 at 11:28:31PM +0300, Adrian Bunk wrote:
> On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
> > ### NMU
> > Can be easily added back by adding "bX" or so to the ABI.
> That would be confusing, bX is naming convention for binNMUs in Debian 
> revisions.

Right.

> > ### BinNMU
> > 
> > Is impossible to support.  The version change requires changes in the
> > names of the created packages.
> >...
> It should only be impossible to make them co-installable,
> or what other reason requires a rename?

The contents are incompatible.  We can of course completely remove the
ability to load modules after a kernel upgrade and then install
everything into "linux-image-amd64".

Bastian

-- 
Deflector shields just came on, Captain.

Re: Debian Kernel version and ABI in respect of #1040901

[Ben Hutchings]

On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote:
[...]
> ## Proposed behaviour
> 
> This tries to make sure everything apart from experimental gets new
> names and ABI on every upload.
> 
> * experimental:
> Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
> Keep ABI 6.1.0-0-arm64
[...]

Why would that still be acceptable in experimental?

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



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

Re: Debian Kernel version and ABI in respect of #1040901

[Adrian Bunk]

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
>...
> ### NMU
> 
> Can be easily added back by adding "bX" or so to the ABI.

That would be confusing, bX is naming convention for binNMUs in Debian 
revisions.

> ### BinNMU
> 
> Is impossible to support.  The version change requires changes in the
> names of the created packages.
>...

It should only be impossible to make them co-installable,
or what other reason requires a rename?

cu
Adrian

Re: Fwd: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Stephan Verbücheln]

Set the clock on the affected system to a date before the key was
expired.

Example:
# faketime 2019-05-01 apt update
# faketime 2019-05-01 apt upgrade
and so on ...

Please note that 1024-bit DSA keys are no longer considered secure.
Maybe better remove the MySQL stuff and add it back later.

Regards
Stephan

PS: This is a dirty trick. Use at your own risk.


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

Re: Fwd: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Jonathan Wiltshire]

On Wed, May 17, 2023 at 06:00:40PM -0300, Alan Homobono wrote:
> ERROR: The certificate of "archive.debian.org" is not trusted.
> ERROR: The certificate of "archive.debian.org" has expired.
> 
> Any other suggestions?

Then your options include, but are not limited to:

1. Downloading it on another PC and transferring the file
2. Dropping the https (but you break the trust path)
3. Downloading the key manually using the fingerprint and apt-key
   (you take on the responsibility of verification)
4. Updating your sources to stretch anyway, and installing the
   debian-keyring package without verification (also breaks the
   trust path)

This is not a user support channel, for further help with these options
please see https://www.debian.org/support

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

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

Re: Fwd: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Alan Homobono]

Why and what time? 

Em 17/05/2023 18:46, Stephan Verbücheln escreveu: 

On Wed, 2023-05-17 at 18:00 -0300, Alan Homobono wrote: 


Any other suggestions?


Have you tried setting the clock to the past (or using faketime)?

Regards
Stephan


--

Atte., 


ALAN HOMOBONO
Analista de TI - Suporte a BD - DATACENTER
Centro de Gestão da Tecnologia da Informação - PRODAP
Macapá - Amapá - Brasil
Telefone: 55 96 98139-4597 (WhatsApp/Telegram/Signal/ICQ)

Re: Fwd: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Stephan Verbücheln]

On Wed, 2023-05-17 at 18:00 -0300, Alan Homobono wrote:
> Any other suggestions?

Have you tried setting the clock to the past (or using faketime)?

Regards
Stephan


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

Fwd: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Alan Homobono]

 Mensagem original 
Assunto: Re: Debian 8.3 Jessie KEYEXPIRED 11645052400
Data: 17/05/2023 17:46
De: Alan Homobono 
Para: Jonathan Wiltshire 

Hi Jonathan,

Unsuccessful:

# wget
https://archive.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2017.5+deb9u1_all.deb
--2023-05-17 17:03:41--
https://archive.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2017.5+deb9u1_all.deb
Resolving archive.debian.org (archive.debian.org)... 209.87.16.41,
130.89.148.13, 217.196.149.234, ...
Connecting to archive.debian.org
(archive.debian.org)|209.87.16.41|:443... connected.
ERROR: The certificate of "archive.debian.org" is not trusted.
ERROR: The certificate of "archive.debian.org" has expired.

Any other suggestions?

Thanks again,
Alan

Em 14/05/2023 14:30, Jonathan Wiltshire escreveu:


On Sat, May 13, 2023 at 12:56:45AM -0300, Alan Homobono wrote:


Trying to upgrade Debian 8.3 Jessie to Debian 10.13 Buster, I
continue
getting "KEYEXPIRED" error message after run apt-get update, even
renewing expired keys:


# wget


https://archive.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2017.5+deb9u1_all.deb

# dpkg -i debian-archive-keyring_2017.5+deb9u1_all.deb
# apt-get update


--

Atte.,

ALAN HOMOBONO
Analista de TI - Suporte a BD - DATACENTER
Centro de Gestão da Tecnologia da Informação - PRODAP
Macapá - Amapá - Brasil
Telefone: 55 96 98139-4597 (WhatsApp/Telegram/Signal/ICQ)

--
Atte.,

ALAN HOMOBONO
Analista de TI - Suporte a BD - DATACENTER
Centro de Gestão da Tecnologia da Informação - PRODAP
Macapá - Amapá - Brasil
Telefone: 55 96 98139-4597 (WhatsApp/Telegram/Signal/ICQ)

Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Jonathan Wiltshire]

On Sat, May 13, 2023 at 12:56:45AM -0300, Alan Homobono wrote:
> Trying to upgrade Debian 8.3 Jessie to Debian 10.13 Buster, I continue
> getting "KEYEXPIRED" error message after run apt-get update, even
> renewing expired keys:

# wget 
https://archive.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2017.5+deb9u1_all.deb
# dpkg -i debian-archive-keyring_2017.5+deb9u1_all.deb
# apt-get update



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

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

Re: Debian 8.3 Jessie KEYEXPIRED 11645052400

[Pierre-Elliott Bécue]

Alan Homobono  wrote on 13/05/2023 at 
05:56:45+0200:

> Trying to upgrade Debian 8.3 Jessie to Debian 10.13 Buster, I continue 
> getting "KEYEXPIRED" error message after run apt-get update, even renewing
> expired keys:
>
> # apt-key list | grep -A 1 expired
> pub   1024D/5072E1F5 2003-02-03 [expired: 2022-02-16]
> uid  MySQL Release Engineering 
> 
> --
> pub   4096R/518E17E1 2013-08-17 [expired: 2021-08-15]
> uid  Jessie Stable Release Key 
> 
> --
> pub   4096R/65FFB764 2012-05-08 [expired: 2019-05-07]
> uid  Wheezy Stable Release Key 
> 
>
>
> # apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 5072E1F5 
> ; apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 518E17E1 
> ; apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 65FFB764
> Executing: gpg --ignore-time-conflict --no-options --no-default-keyring 
> --homedir /tmp/tmp.dux8x5wGCC --no-auto-check-trustdb --trust-model always 
> --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg 
> --keyring /etc/apt/trusted.gpg.d/apt.postgresql.org.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg 
> --keyring /etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyserver 
> hkp://keyserver.ubuntu.com:80 --recv-keys 5072E1F5
> gpg: requesting key 5072E1F5 from hkp server keyserver.ubuntu.com
> gpg: key 5072E1F5: "MySQL Release Engineering 
> " not changed
> gpg: Número total processado: 1
> gpg:  não modificados: 1
> Executing: gpg --ignore-time-conflict --no-options --no-default-keyring 
> --homedir /tmp/tmp.4zdbdTUejR --no-auto-check-trustdb --trust-model always 
> --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg 
> --keyring /etc/apt/trusted.gpg.d/apt.postgresql.org.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg 
> --keyring /etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyserver 
> hkp://keyserver.ubuntu.com:80 --recv-keys 518E17E1
> gpg: requesting key 518E17E1 from hkp server keyserver.ubuntu.com
> gpg: key 518E17E1: "Jessie Stable Release Key 
> " not changed
> gpg: Número total processado: 1
> gpg:  não modificados: 1
> Executing: gpg --ignore-time-conflict --no-options --no-default-keyring 
> --homedir /tmp/tmp.SxFd1nEp2W --no-auto-check-trustdb --trust-model always 
> --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg 
> --keyring /etc/apt/trusted.gpg.d/apt.postgresql.org.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg 
> --keyring /etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring 
> /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyserver 
> hkp://keyserver.ubuntu.com:80 --recv-keys 65FFB764
> gpg: requesting key 65FFB764 from hkp server keyserver.ubuntu.com
> gpg: key 65FFB764: "Wheezy Stable Release Key 
> " not changed
> gpg: Número total processado: 1
> gpg:  não modificados: 1
>
>
> # apt-get update
> ...
> Lendo listas de pacotes... Pronto
> W: Ocorreu um erro durante a verificação da assinatura. O repositório não 
> está actualizado e serão utilizados os ficheiros 

Re: Debian 11.6 release date

[Paul Wise]

On Mon, 2022-11-14 at 00:05 +0800, meida...@foxmail.com wrote:

> I don't know much about Debian's messaging channels. It's been 2
> months since Debian 11.5 was released, and I was wondering if there
> are any plans to release Debian 11.6 in the next few days?

The Debian Release Team website documents the next point release date:

   https://release.debian.org/#release-dates

   Next point releases
   
    * stable (11.6) Not yet planned; maybe mid-late November 2022

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: debian-installer 20220917 via tpu

[Cyril Brulebois]

Hi,

Ansgar  (2022-09-20):
> Cyril Brulebois writes:
> > FTP Masters, please sync the installer from *tpu* to testing, once it's
> > available there.
> >
> >   dak copy-installer 20220917 -s bookworm-proposed-updates
> 
> Done:
> 
> +---
> | $ dak copy-installer 20220917 -s bookworm-proposed-updates
> |
> | Will copy installer version 20220917 from suite bookworm-proposed-updates to
> | testing.
> | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, 
> arm64, mips64el
> | Architectures to skip: 
> | Installer has been copied successfully.
> +---

Thanks!

That's now available on mirrors, and debian-installer was accepted into
testing from tpu (and prop-up'd to unstable automatically).

debian-cd: burn baby, burn!



Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: debian-installer 20220917 via tpu

[Ansgar]

Cyril Brulebois writes:
> FTP Masters, please sync the installer from *tpu* to testing, once it's
> available there.
>
>   dak copy-installer 20220917 -s bookworm-proposed-updates

Done:

+---
| $ dak copy-installer 20220917 -s bookworm-proposed-updates
|
| Will copy installer version 20220917 from suite bookworm-proposed-updates to
| testing.
| Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, 
arm64, mips64el
| Architectures to skip: 
| Installer has been copied successfully.
+---

Ansgar

Re: debian-archive-keyring, update for stretch, problem

[Anton Gladky]

Hi Adam,

thanks for your reply!

I have found the reason. I generated the signature using
Debian/Testing (Bookworm), but the signature should be
generated in the same environment, where it will
be used (in this case Stretch).

I regenerated signatures under stretch and everything works fine.

Best regards

Anton

Am Sa., 12. März 2022 um 22:24 Uhr schrieb Adam D. Barratt
:


>
> Hi,
>
> FWIW, I haven't touched d-a-k for a few years now, nor have I seen your
> package, so I'm largely guessing based on your provided text below.
>
> On Sat, 2022-03-12 at 21:52 +0100, Anton Gladky wrote:
> > I followed the README.maintainer. Added my key into team/members.
> > But then, when I just refresh the signature:
> >
> > make clean
> > make keyrings/debian-archive-keyring.gpg
> > gpg --armor --detach-sign keyrings/debian-archive-keyring.gpg
> >
> > The package does not build and fails with the following message:
> >
> > ===
> > gpg --no-options --no-default-keyring --no-auto-check-trustdb
> > --trustdb-name ./trustdb.gpg \
> > --keyring keyrings/team-members.gpg --verify \
> > keyrings/debian-archive-removed-keys.gpg.asc \
> > keyrings/debian-archive-removed-keys.gpg
> > gpg: Signature made Sat Mar 12 20:41:08 2022 UTC
> > gpg:using RSA key
> > BBBD45EA818AB86FF67E7285D3E17383CFA7FF06
> > gpg: BAD signature from "Anton Gladky " [unknown]
> >
> > ===
> >
> > Could you please give advice, why the lately refreshed and signed
> > debian-archive-removed-keys.gpg has a bad signature?
>
> My suspicion would be that you signed the keyring before running the
> build - although you only mention signing debian-archive-keyring.gpg -
> but had somehow not built it correctly so, after it got rebuilt by the
> makefile, your previous signature file no longer matched. (The point of
> using jetring is that the result should match.)
>
> How did you manipulate debian-archive-removed-keys.gpg? Do its contents
> align with removed-keys/index, and the signature on that?
>
> Not that it helps you directly, but I don't remember having seen such
> an error when I was building the package.
>
> Regards,
>
> Adam
>

Re: debian-archive-keyring, update for stretch, problem

[Adam D. Barratt]

Hi,

FWIW, I haven't touched d-a-k for a few years now, nor have I seen your
package, so I'm largely guessing based on your provided text below.

On Sat, 2022-03-12 at 21:52 +0100, Anton Gladky wrote:
> I followed the README.maintainer. Added my key into team/members.
> But then, when I just refresh the signature:
> 
> make clean
> make keyrings/debian-archive-keyring.gpg
> gpg --armor --detach-sign keyrings/debian-archive-keyring.gpg
> 
> The package does not build and fails with the following message:
> 
> ===
> gpg --no-options --no-default-keyring --no-auto-check-trustdb
> --trustdb-name ./trustdb.gpg \
> --keyring keyrings/team-members.gpg --verify \
> keyrings/debian-archive-removed-keys.gpg.asc \
> keyrings/debian-archive-removed-keys.gpg
> gpg: Signature made Sat Mar 12 20:41:08 2022 UTC
> gpg:using RSA key
> BBBD45EA818AB86FF67E7285D3E17383CFA7FF06
> gpg: BAD signature from "Anton Gladky " [unknown]
> 
> ===
> 
> Could you please give advice, why the lately refreshed and signed
> debian-archive-removed-keys.gpg has a bad signature?

My suspicion would be that you signed the keyring before running the
build - although you only mention signing debian-archive-keyring.gpg -
but had somehow not built it correctly so, after it got rebuilt by the
makefile, your previous signature file no longer matched. (The point of
using jetring is that the result should match.)

How did you manipulate debian-archive-removed-keys.gpg? Do its contents
align with removed-keys/index, and the signature on that?

Not that it helps you directly, but I don't remember having seen such
an error when I was building the package.

Regards,

Adam

Re: Debian 11 images for AWS m6i instances

[Steve McIntyre]

Hi Giambattista,

On Thu, Oct 14, 2021 at 10:32:50AM +0100, Giambattista Piranesi wrote:
>I've noticed there are no official Debian 11 (Bullseye) images on AWS
>compatible with m6i instances.
>
>Any chance to generate a m6-ready Debian 11 AMI?  What does it depend?

The best place to ask about this is the debian-cloud list (in CC).

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Re: Debian 10.0 works with third generation Ryzen

[Dan Ritter]

Mick Ab wrote: 
> https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1
> 
> The above article shows that Debian 10.0 works okay with a third generation
> Ryzen CPU.
> 
> I understood that there were problems with Buster using  third generation
> Ryzen.
> 
> Has this problem been overcome by installing AMD firmware ?
> 
> Also does the particular BIOS used on the motherboard help to overcome the
> problem ?

I haven't got any problems at all with a Ryzen 5 3600.

Motherboard: ASRock X570 Phantom Gaming 4

No BIOS updates of any kind. 

amd64-microcode/stable 3.20181128.1 is installed.

Everything was perfectly smooth.

Similar experiences obtained with Ryzen R1505G, Ryzen 3400G, and 
a Ryzen laptop. Built-in graphics wanted AMD graphics firmware.

-dsr-

Re: Debian Linux kernel uploads

[Ansgar]

Hi,

Hector Oron writes:
>   I would like to support Debian Linux kernel team by doing kernel
> package uploads.

Related to Linux uploads: I've added an exception to allow source-only
uploads to NEW for src:linux.  Feel free to try.

Ansgar

Re: Debian Linux kernel uploads

[Salvatore Bonaccorso]

Hi,

On Sun, Oct 20, 2019 at 02:27:21PM +0100, Ben Hutchings wrote:
> On Sun, 2019-10-20 at 13:58 +0200, Hector Oron wrote:
> > Hello,
> > 
> >   I would like to support Debian Linux kernel team by doing kernel
> > package uploads.
> > 
> >   Initially, I would like to attempt timely (weekly or bi-weekly, it
> > has not been discussed yet) updates for Debian Linux kernel package in
> > SID and see how that works.
> > 
> >   In anycase, I would like to give a heads-up to the kernel and
> > release team that I shall becoming a linux package uploader. Note,
> > this has been discussed and agreed with Ben Hutchings and he suggested
> > to inform you.
> > 
> >   I'll follow up with linux_5.2.17-2 upload real soon now.
> 
> The 5.2 series is EOL, so please don't upload that version.  Salvatore
> has already updated the sid branch to 5.3.7 and you should coordinate
> with him who will upload.

FTR, this has happened earlier today[1] and is waiting for NEW
processing.

 [1] https://lists.debian.org/debian-kernel/2019/10/msg00167.html

Salvatore

Re: Debian Linux kernel uploads

[Ben Hutchings]

On Sun, 2019-10-20 at 13:58 +0200, Hector Oron wrote:
> Hello,
> 
>   I would like to support Debian Linux kernel team by doing kernel
> package uploads.
> 
>   Initially, I would like to attempt timely (weekly or bi-weekly, it
> has not been discussed yet) updates for Debian Linux kernel package in
> SID and see how that works.
> 
>   In anycase, I would like to give a heads-up to the kernel and
> release team that I shall becoming a linux package uploader. Note,
> this has been discussed and agreed with Ben Hutchings and he suggested
> to inform you.
> 
>   I'll follow up with linux_5.2.17-2 upload real soon now.

The 5.2 series is EOL, so please don't upload that version.  Salvatore
has already updated the sid branch to 5.3.7 and you should coordinate
with him who will upload.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.




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

Re: [debian-mysql] Bug#939866: Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

[Otto Kekäläinen]

la 14. syysk. 2019 klo 16.57 Adam D. Barratt
(a...@adam-barratt.org.uk) kirjoitti:
>
> On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote:
> > To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is
> > still open for Buster and Stretch.
>
> Is there a likely ETA for when this might be resolvable?
>
> If you could prepare (preferably targeted) updates via the usual p-u
> path then we can look at releasing them via stable-updates so that
> affected users don't have to wait for the next point release.

Thanks Adam for the pre-approval/guidance on how to solve this
non-security stable update that is urgent. I will target p-u then and
prepare it soon.

Re: [debian-mysql] Bug#939866: Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

[Adam D. Barratt]

On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote:
> To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is
> still open for Buster and Stretch.

Is there a likely ETA for when this might be resolvable?

If you could prepare (preferably targeted) updates via the usual p-u
path then we can look at releasing them via stable-updates so that
affected users don't have to wait for the next point release.

Regards,

Adam

Re: debian squeeze repository

[Jonathan Wiltshire]

On Tue, Feb 19, 2019 at 06:11:27PM +, miel...@t-online.de wrote:
> 
> Ladies and gentlemen,
> 
> I tried to update a debian squeeze OS, with a
> /etc/apt/sources.list

Debian 6 "Squeeze" stopped receiving security and errata updates in 2014.
You should upgrade to a supported release as soon as possible.

For further help please contact one of the Debian user support channels
(https://www.debian.org/support)


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

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

Re: [debian-mysql] Heads up to release team about MariadB 10.3

[Emilio Pozuelo Monfort]

On 18/01/2019 10:59, Olaf van der Spek wrote:
> On Thu, Jan 17, 2019 at 3:37 PM Emilio Pozuelo Monfort  
> wrote:
>> That was with the old libdbd-mariadb-perl, and the new one (which was fine)
>> wasn't migrating due to a build-dep on the new mysql-defaults, which was 
>> blocked
>> on mariadb-10.3, blocked on libdbd-mariadb-perl... I cheated a bit and let
>> libdbd-mariadb-perl ignore that build-dep and migrate to testing ahead of
>> mysql-defaults, so now mariadb-10.3 and mysql-defaults should be happy to
>> migrate soon (once the age requirements are met).
> 
> Isn't the migration script capable of migrating all 3 at once automatically?

The problem was that the old libdbd-mariadb-perl didn't work with the new
mariadb-10.3, so without a Breaks relationship in mariadb-10.3, there was an
autopkgtests regression that was blocking the mariadb-10.3 migration. Yes, a
Breaks could have been added, but that would have caused extra delays and I
wanted to avoid that.

Emilio

Re: [debian-mysql] Heads up to release team about MariadB 10.3

[Olaf van der Spek]

On Thu, Jan 17, 2019 at 3:37 PM Emilio Pozuelo Monfort  wrote:
> That was with the old libdbd-mariadb-perl, and the new one (which was fine)
> wasn't migrating due to a build-dep on the new mysql-defaults, which was 
> blocked
> on mariadb-10.3, blocked on libdbd-mariadb-perl... I cheated a bit and let
> libdbd-mariadb-perl ignore that build-dep and migrate to testing ahead of
> mysql-defaults, so now mariadb-10.3 and mysql-defaults should be happy to
> migrate soon (once the age requirements are met).

Isn't the migration script capable of migrating all 3 at once automatically?


-- 
Olaf

Re: Debian/MIPSeb: proposal to drop mipseb port?

[Brock Wittrock]

I'm still actively using it for a couple of different devices.

Thanks,
Brock

On Sat, Jul 7, 2018 at 9:34 AM YunQiang Su  wrote:

> Hi, folks,
> due to lack of enough man power and build machines for 3 mips* port at
> the same time, I think that now it is time for us to have a talk about
> dropping mips32eb support now.
>
> mips32eb, named mips, in our namespace, is used by few people now, at
> least compare with mipsel/mips64el.
>
> The reason we keep it till now is
>1) some people are still using it.
>2) it is the only port 32bit and EB now.
>
> In fact I don't know anybody is using Debian's mips32eb port.
> If you are using it, please tell us.
>
>

Re: Debian/MIPSeb: proposal to drop mipseb port?

[John Paul Adrian Glaubitz]

Hi!

You should ask in a more public forum rather than on Debian mailing lists if 
you want to know about potential users.

Adrian

> On Jul 7, 2018, at 8:31 AM, YunQiang Su  wrote:
> 
> Hi, folks,
> due to lack of enough man power and build machines for 3 mips* port at
> the same time, I think that now it is time for us to have a talk about
> dropping mips32eb support now.
> 
> mips32eb, named mips, in our namespace, is used by few people now, at
> least compare with mipsel/mips64el.
> 
> The reason we keep it till now is
>   1) some people are still using it.
>   2) it is the only port 32bit and EB now.
> 
> In fact I don't know anybody is using Debian's mips32eb port.
> If you are using it, please tell us.

Processed: Re: [debian-mysql] Bug#868666:

[Debian Bug Tracking System]

Processing control commands:

> tags 865093 -moreinfo
Bug #865093 [release.debian.org] stretch-pu: package 
mariadb-10.1/10.1.25-0+deb9u1
Removed tag(s) moreinfo.

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

Re: Debian 9.0

[Niels Thykier]

sare...@att.net:
> There is something wrong with the Debian 9 iso's. I downloaded the Debian 9.0 
> dvd iso and put it on a flash drive. It boots ,but when I try to install it a 
> dialog pups up asking for a cd. As you know 2 gb will not fit on a CD. I 
> re-downloaded and tried to install Debian again and the same message comes up 
> asking for a CD. What is wrong?
> 

Hi,

I am sorry to hear you have issues.

Could you please post this to debian-u...@lists.debian.org and ask for
their assistance?  Alternatively the relevant language specific support
list from [1], if you prefer that

Thanks,
~Niels

[1] https://lists.debian.org/users.html

Re: d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Cyril Brulebois]

Andrew M.A. Cater  (2017-06-14):
> Seeing the post on PXE for UEFI on planet.debian.org and noting that
> you're planning another d-i release.

Please mention a direct URL, planet has a volatile content… Maybe you're
referring to this?
  http://sven.stormbind.net/blog/posts/deb_uefi_pxe_install_hpe_dl120/

> Is there any chance of putting in the symlink in d-i that will link 
> bootnetx64.efi in the same way as pxelinux as below
> 
> Also in netboot.tar.gz similarly
> 
> bootnetx64.efi -> debian-installer/amd64/bootnetx64.efi
> 
> This is exactly the way that pexlinux.0 and pxelinux.cfg are already
> linked and would be a trivial change that would allow UEFI booting
> more readily.

It seems that's a more detailed version of what you mentioned on May
27th following a release announcement. That really should be turned into
a bug report against src:debian-installer; I'm assuming you could try to
test a patch, which would likely modify build/config/x86.cfg there.

As for stretch r0, this is obviously too late, but we'll get a chance to
backport fixes from buster for point releases.


KiBi.


signature.asc
Description: Digital signature

Re: d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Andrew M.A. Cater]

On Wed, Jun 14, 2017 at 08:45:47AM +0200, Cyril Brulebois wrote:
> Holger Levsen  (2017-06-13):
> > On Tue, Jun 13, 2017 at 10:19:17AM +0200, Cyril Brulebois wrote:
> > > Known bugs in this release
> > > ==
> > [...] 
> > > See the errata[2] for details and a full list of known issues.
> > 
> > https://tracker.debian.org/pkg/debian-installer-netboot-images hasn't seen 
> > an
> > update in a while (and thus is unusuable due to kernel version skew), is it
> > on your collective radar to update the package til Saturday?
> > 
> > (Debian Edu uses that packages to support installation via PXE out of the 
> > box.)
> > 
> > Shall I file an RC bug to make the problem more visible and known?
> 
> As mentioned in the announce: We're doing another d-i upload for the
> release anyway.
> 
> Not that the latest d-i-n-i upload was a bad thing. It's just going to
> be superseded.
> 
> (Last two items on my r0 checklist:
> d-i
> d-i-n-i after d-i
> 

Seeing the post on PXE for UEFI on planet.debian.org and noting that
you're planning another d-i release.

Is there any chance of putting in the symlink in d-i that will link 
bootnetx64.efi in the same way as pxelinux as below

Also in netboot.tar.gz similarly

bootnetx64.efi -> debian-installer/amd64/bootnetx64.efi

This is exactly the way that pexlinux.0 and pxelinux.cfg are already
linked and would be a trivial change that would allow UEFI booting
more readily.

Thank you for your consideration

Andy C.


> … and Karsten has committed the d-i fixes for i2c, so we should be go to
> go for an upload; need to catch up with some more mails before that
> though.)
> 
> 
> KiBi.

Re: d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Holger Levsen]

On Wed, Jun 14, 2017 at 08:45:47AM +0200, Cyril Brulebois wrote:
> > Shall I file an RC bug to make the problem more visible and known?
> As mentioned in the announce: We're doing another d-i upload for the
> release anyway.
 
til then, having up2date debian-installer-netboot-images packages allows
people to actually test them…

> Not that the latest d-i-n-i upload was a bad thing. It's just going to
> be superseded.

sure!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Cyril Brulebois]

Holger Levsen  (2017-06-13):
> On Tue, Jun 13, 2017 at 10:19:17AM +0200, Cyril Brulebois wrote:
> > Known bugs in this release
> > ==
> [...] 
> > See the errata[2] for details and a full list of known issues.
> 
> https://tracker.debian.org/pkg/debian-installer-netboot-images hasn't seen an
> update in a while (and thus is unusuable due to kernel version skew), is it
> on your collective radar to update the package til Saturday?
> 
> (Debian Edu uses that packages to support installation via PXE out of the 
> box.)
> 
> Shall I file an RC bug to make the problem more visible and known?

As mentioned in the announce: We're doing another d-i upload for the
release anyway.

Not that the latest d-i-n-i upload was a bad thing. It's just going to
be superseded.

(Last two items on my r0 checklist:
d-i
d-i-n-i after d-i

… and Karsten has committed the d-i fixes for i2c, so we should be go to
go for an upload; need to catch up with some more mails before that
though.)


KiBi.


signature.asc
Description: Digital signature

Re: d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Jonathan Wiltshire]

On Tue, Jun 13, 2017 at 10:08:44AM +, Holger Levsen wrote:
> On Tue, Jun 13, 2017 at 10:19:17AM +0200, Cyril Brulebois wrote:
> > Known bugs in this release
> > ==
> [...] 
> > See the errata[2] for details and a full list of known issues.
> 
> https://tracker.debian.org/pkg/debian-installer-netboot-images hasn't seen an
> update in a while (and thus is unusuable due to kernel version skew), is it
> on your collective radar to update the package til Saturday?

Unblocked. (I presume I have not done a terrible thing, if there are feel
free to kill my hint before the next run.)

thanks,

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

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



signature.asc
Description: PGP signature

d-i-netboot-images package outdated (was Re: Debian Installer Stretch RC 5 release)

[Holger Levsen]

On Tue, Jun 13, 2017 at 10:19:17AM +0200, Cyril Brulebois wrote:
> Known bugs in this release
> ==
[...] 
> See the errata[2] for details and a full list of known issues.

https://tracker.debian.org/pkg/debian-installer-netboot-images hasn't seen an
update in a while (and thus is unusuable due to kernel version skew), is it
on your collective radar to update the package til Saturday?

(Debian Edu uses that packages to support installation via PXE out of the box.)

Shall I file an RC bug to make the problem more visible and known?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Ondřej Surý]

On Fri, May 12, 2017, at 17:30, Norvald H. Ryeng wrote:
> On Fri, 12 May 2017 14:09:02 +0200
> Ondřej Surý  wrote:
> 
> > On Fri, May 12, 2017, at 13:31, Norvald H. Ryeng wrote:
> > > On Fri, 12 May 2017 11:26:13 +0200
> > > Ondřej Surý  wrote:
> > >   
> > > > Dear release team and fellow MySQL/MariaDB maintainers,
> > > > 
> > > > the situation in stretch in regards to clean upgrade path from
> > > > jessie is a little bit unfortunate. It works for most cases when
> > > > something depends on default-mysql-server and pulls it as a
> > > > dependency. But in situations where mysql-server was the top
> > > > dependency, it simply uninstalls mysql-server-5.5 without any
> > > > replacement.
> > > > 
> > > > I understand the reasons why we are here, but the situation where
> > > > user needs to do:
> > > > apt-get update
> > > > # apt-get upgrade
> > > > apt-get install default-mysql-server
> > > > apt-get dist-upgrade
> > > > 
> > > > is very inconvenient for the users and I foresee this will cause
> > > > a lot of complaints, because it's quite common to run just
> > > > "mysql-server" on the server.
> > > > 
> > > > Therefore I am proposing a one time fix specifically targeted at
> > > > stretch. I would like to prepare 'mysql-transitional' package that
> > > > will create a couple of dummy/transitional packages structured
> > > > like this:
> > > > 
> > > > mysql-server depends on default-mysql-server
> > > > mysql-client depends on default-mysql-client
> > > > 
> > > > The version would be 5.5.999+mariadb, so it is always higher than
> > > > version in jessie, but always lower than version in sid, as I
> > > > don't want force epoch on mysql-5.7.  
> > > 
> > > I agree that this sounds like it will work for stretch, and it's
> > > much better than bumping epoch on mysql-5.7.
> > > 
> > > As you say, it's a one time fix, but I'm a bit concerned about what
> > > happens when those packages again are provided by MySQL. Let's think
> > > through what will happen in buster. There are three options:  
> > 
> > And all of them would be easily solved by having the
> > mariadb-server-10.X and mariadb-client-10.X Conflicts with
> > mysql-server and mysql-client.
> 
> And as long as MySQL and MariaDB are not co-installable, they should
> conflict. But below you say we must make the packages co-installable
> to have both I'm a bit confused. Can you please elaborate?

The other email in pkg-mysql clearly stated that MariaDB and MySQL
servers are diverging and if we provide *both* in stable Debian,
packages might need to make a choice. And if there's a package A that
depends[*] on mariadb-server and package B that depends[*] on
mysql-server you ideally want to be able to install both A and B on the
same system.

* depends as in verb, not Depends as in d/control statement

> > > 1) Buster contains only MariaDB. Will these packages also be in
> > > buster? If not, what happens on upgrade from stretch to buster?
> > > Will we have the same problem again?  
> > 
> > default-mysql-* will already be installed, it will pull new
> > mariadb-*-10.x packages and mysql-server/mysql-client will be removed.
> > Nothing must depend on mysql-server/mysql-client already, so those
> > will be just dangling packages ready to be removed.
> > 
> > > 2) Buster contains both MySQL and MariaDB. MariaDB is default. The
> > > mysql-server and mysql-client packages are provided by MySQL, but
> > > default-mysql-server and default-mysql-client point to MariaDB. How
> > > will the upgrade go? Some users have installed mysql-server or
> > > mysql-client explicitly, while others have installed a different
> > > package that depends on default-mysql-server or
> > > default-mysql-client.  
> > 
> > I don't think this is going to happen, but if it does, we will have to
> > make MariaDB and MySQL coinstallable with each other, because the
> > packages might depend on specific flavour.
> 
> The default is to include MySQL in buster. The release team only made a
> decision about stretch, so unless they make a new decision, MySQL will
> be in buster. Therefore, we have to handle this case.
> 
> That said, I definitely wouldn't mind making the packages
> co-installable, no matter what ends up in which version of Debian.

postgresql-* packages might be a good example how to handle this, but it
will be a lot of work, and somebody will have to write the handling
script for smooth changes from one version to other.

Cheers,
Ondrej

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 14:09:02 +0200
Ondřej Surý  wrote:

> On Fri, May 12, 2017, at 13:31, Norvald H. Ryeng wrote:
> > On Fri, 12 May 2017 11:26:13 +0200
> > Ondřej Surý  wrote:
> >   
> > > Dear release team and fellow MySQL/MariaDB maintainers,
> > > 
> > > the situation in stretch in regards to clean upgrade path from
> > > jessie is a little bit unfortunate. It works for most cases when
> > > something depends on default-mysql-server and pulls it as a
> > > dependency. But in situations where mysql-server was the top
> > > dependency, it simply uninstalls mysql-server-5.5 without any
> > > replacement.
> > > 
> > > I understand the reasons why we are here, but the situation where
> > > user needs to do:
> > > apt-get update
> > > # apt-get upgrade
> > > apt-get install default-mysql-server
> > > apt-get dist-upgrade
> > > 
> > > is very inconvenient for the users and I foresee this will cause
> > > a lot of complaints, because it's quite common to run just
> > > "mysql-server" on the server.
> > > 
> > > Therefore I am proposing a one time fix specifically targeted at
> > > stretch. I would like to prepare 'mysql-transitional' package that
> > > will create a couple of dummy/transitional packages structured
> > > like this:
> > > 
> > > mysql-server depends on default-mysql-server
> > > mysql-client depends on default-mysql-client
> > > 
> > > The version would be 5.5.999+mariadb, so it is always higher than
> > > version in jessie, but always lower than version in sid, as I
> > > don't want force epoch on mysql-5.7.  
> > 
> > I agree that this sounds like it will work for stretch, and it's
> > much better than bumping epoch on mysql-5.7.
> > 
> > As you say, it's a one time fix, but I'm a bit concerned about what
> > happens when those packages again are provided by MySQL. Let's think
> > through what will happen in buster. There are three options:  
> 
> And all of them would be easily solved by having the
> mariadb-server-10.X and mariadb-client-10.X Conflicts with
> mysql-server and mysql-client.

And as long as MySQL and MariaDB are not co-installable, they should
conflict. But below you say we must make the packages co-installable
to have both I'm a bit confused. Can you please elaborate?

> > 1) Buster contains only MariaDB. Will these packages also be in
> > buster? If not, what happens on upgrade from stretch to buster?
> > Will we have the same problem again?  
> 
> default-mysql-* will already be installed, it will pull new
> mariadb-*-10.x packages and mysql-server/mysql-client will be removed.
> Nothing must depend on mysql-server/mysql-client already, so those
> will be just dangling packages ready to be removed.
> 
> > 2) Buster contains both MySQL and MariaDB. MariaDB is default. The
> > mysql-server and mysql-client packages are provided by MySQL, but
> > default-mysql-server and default-mysql-client point to MariaDB. How
> > will the upgrade go? Some users have installed mysql-server or
> > mysql-client explicitly, while others have installed a different
> > package that depends on default-mysql-server or
> > default-mysql-client.  
> 
> I don't think this is going to happen, but if it does, we will have to
> make MariaDB and MySQL coinstallable with each other, because the
> packages might depend on specific flavour.

The default is to include MySQL in buster. The release team only made a
decision about stretch, so unless they make a new decision, MySQL will
be in buster. Therefore, we have to handle this case.

That said, I definitely wouldn't mind making the packages
co-installable, no matter what ends up in which version of Debian.

Best regards,

Norvald H. Ryeng

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 11:26:13 +0200
Ondřej Surý  wrote:

> Dear release team and fellow MySQL/MariaDB maintainers,
> 
> the situation in stretch in regards to clean upgrade path from jessie
> is a little bit unfortunate. It works for most cases when something
> depends on default-mysql-server and pulls it as a dependency. But in
> situations where mysql-server was the top dependency, it simply
> uninstalls mysql-server-5.5 without any replacement.
> 
> I understand the reasons why we are here, but the situation where user
> needs to do:
> apt-get update
> # apt-get upgrade
> apt-get install default-mysql-server
> apt-get dist-upgrade
> 
> is very inconvenient for the users and I foresee this will cause a lot
> of complaints, because it's quite common to run just "mysql-server" on
> the server.
> 
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that
> will create a couple of dummy/transitional packages structured like
> this:
> 
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
> 
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't
> want force epoch on mysql-5.7.

I agree that this will work for stretch.

You say it's a one time fix, but I'm a bit concerned about what
happens after this fix, when those packages are provided by MySQL. Let's
think through what will happen in buster. There are three options:

1) Buster contains only MariaDB. Will these packages also be in buster?

2) Buster contains both MySQL and MariaDB. MariaDB is default. The
mysql-server and mysql-clienpackages are provided by MySQL

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Otto Kekäläinen]

Hello!

2017-05-12 12:26 GMT+03:00 Ondřej Surý :
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that will
> create a couple of dummy/transitional packages structured like this:
>
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
>
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't want
> force epoch on mysql-5.7.


We did a lot of work last summer to have the default-mysql-* packages
etc but I can clearly see now the scenario where they fail to produce
a smooth upgrade experience. For users where the host is a DB server
only host, there is no package depending on default-mysql-server. And
stand-alone DB hosts are certainly no corner cases, so the suggestion
by Ondrej seems to be the right thing to do at this point.

Thanks Ondrej for working so responsibly on this! I've hade a very
busy period in March-May and it still continues.

- Otto

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Ondřej Surý]

On Fri, May 12, 2017, at 13:31, Norvald H. Ryeng wrote:
> On Fri, 12 May 2017 11:26:13 +0200
> Ondřej Surý  wrote:
> 
> > Dear release team and fellow MySQL/MariaDB maintainers,
> > 
> > the situation in stretch in regards to clean upgrade path from jessie
> > is a little bit unfortunate. It works for most cases when something
> > depends on default-mysql-server and pulls it as a dependency. But in
> > situations where mysql-server was the top dependency, it simply
> > uninstalls mysql-server-5.5 without any replacement.
> > 
> > I understand the reasons why we are here, but the situation where user
> > needs to do:
> > apt-get update
> > # apt-get upgrade
> > apt-get install default-mysql-server
> > apt-get dist-upgrade
> > 
> > is very inconvenient for the users and I foresee this will cause a lot
> > of complaints, because it's quite common to run just "mysql-server" on
> > the server.
> > 
> > Therefore I am proposing a one time fix specifically targeted at
> > stretch. I would like to prepare 'mysql-transitional' package that
> > will create a couple of dummy/transitional packages structured like
> > this:
> > 
> > mysql-server depends on default-mysql-server
> > mysql-client depends on default-mysql-client
> > 
> > The version would be 5.5.999+mariadb, so it is always higher than
> > version in jessie, but always lower than version in sid, as I don't
> > want force epoch on mysql-5.7.
> 
> I agree that this sounds like it will work for stretch, and it's much
> better than bumping epoch on mysql-5.7.
> 
> As you say, it's a one time fix, but I'm a bit concerned about what
> happens when those packages again are provided by MySQL. Let's think
> through what will happen in buster. There are three options:

And all of them would be easily solved by having the mariadb-server-10.X
and mariadb-client-10.X Conflicts with mysql-server and mysql-client.

> 1) Buster contains only MariaDB. Will these packages also be in buster?
> If not, what happens on upgrade from stretch to buster? Will we have
> the same problem again?

default-mysql-* will already be installed, it will pull new
mariadb-*-10.x packages and mysql-server/mysql-client will be removed.
Nothing must depend on mysql-server/mysql-client already, so those will
be just dangling packages ready to be removed.

> 2) Buster contains both MySQL and MariaDB. MariaDB is default. The
> mysql-server and mysql-client packages are provided by MySQL, but
> default-mysql-server and default-mysql-client point to MariaDB. How
> will the upgrade go? Some users have installed mysql-server or
> mysql-client explicitly, while others have installed a different
> package that depends on default-mysql-server or default-mysql-client.

I don't think this is going to happen, but if it does, we will have to
make MariaDB and MySQL coinstallable with each other, because the
packages might depend on specific flavour.

> 3) Buster contains both MySQL and MariaDB. MySQL is default. The
> mysql-server and mysql-client packages are provided by MySQL, and the
> default-mysql-server and default-mysql-client packages point to MySQL.
> I assume the dist-upgrade will move users back to MySQL, but will there
> be other problems?

Same as 2).

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 11:26:13 +0200
Ondřej Surý  wrote:

> Dear release team and fellow MySQL/MariaDB maintainers,
> 
> the situation in stretch in regards to clean upgrade path from jessie
> is a little bit unfortunate. It works for most cases when something
> depends on default-mysql-server and pulls it as a dependency. But in
> situations where mysql-server was the top dependency, it simply
> uninstalls mysql-server-5.5 without any replacement.
> 
> I understand the reasons why we are here, but the situation where user
> needs to do:
> apt-get update
> # apt-get upgrade
> apt-get install default-mysql-server
> apt-get dist-upgrade
> 
> is very inconvenient for the users and I foresee this will cause a lot
> of complaints, because it's quite common to run just "mysql-server" on
> the server.
> 
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that
> will create a couple of dummy/transitional packages structured like
> this:
> 
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
> 
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't
> want force epoch on mysql-5.7.

I agree that this sounds like it will work for stretch, and it's much
better than bumping epoch on mysql-5.7.

As you say, it's a one time fix, but I'm a bit concerned about what
happens when those packages again are provided by MySQL. Let's think
through what will happen in buster. There are three options:

1) Buster contains only MariaDB. Will these packages also be in buster?
If not, what happens on upgrade from stretch to buster? Will we have
the same problem again?

2) Buster contains both MySQL and MariaDB. MariaDB is default. The
mysql-server and mysql-client packages are provided by MySQL, but
default-mysql-server and default-mysql-client point to MariaDB. How
will the upgrade go? Some users have installed mysql-server or
mysql-client explicitly, while others have installed a different
package that depends on default-mysql-server or default-mysql-client.

3) Buster contains both MySQL and MariaDB. MySQL is default. The
mysql-server and mysql-client packages are provided by MySQL, and the
default-mysql-server and default-mysql-client packages point to MySQL.
I assume the dist-upgrade will move users back to MySQL, but will there
be other problems?

We should think through these scenarios so that we're sure we're not
creating bigger problems for ourselves in the future.

Best regards,

Norvald H. Ryeng

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Robie Basak]

Hi Ondřej,

Thank you for working on this.

On Fri, May 12, 2017 at 11:26:13AM +0200, Ondřej Surý wrote:
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that will
> create a couple of dummy/transitional packages structured like this:
> 
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
> 
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't want
> force epoch on mysql-5.7.

FTR, this sounds fine to me from the perspective of continuing to
maintain src:mysql-5.7 in sid.

Robie


signature.asc
Description: PGP signature

Processed (with 2 errors): Re: [debian-mysql] Bug#855163: Missing mariadb-plugin-tokudb binary package on amd64

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 release.debian.org
Bug #855163 [src:mariadb-10.1] Missing mariadb-plugin-tokudb binary package on 
amd64
Bug reassigned from package 'src:mariadb-10.1' to 'release.debian.org'.
No longer marked as found in versions mariadb-10.1/10.1.21-5.
Ignoring request to alter fixed versions of bug #855163 to the same values 
previously set
> user release.debian@packages.debian.org
Unknown command or malformed arguments to command.

> usertags -1 binnmu
Unknown command or malformed arguments to command.

> severity -1 normal
Bug #855163 [release.debian.org] Missing mariadb-plugin-tokudb binary package 
on amd64
Severity set to 'normal' from 'serious'
> retitle -1 nmu: mariadb-10.1_10.1.21-5
Bug #855163 [release.debian.org] Missing mariadb-plugin-tokudb binary package 
on amd64
Changed Bug title to 'nmu: mariadb-10.1_10.1.21-5' from 'Missing 
mariadb-plugin-tokudb binary package on amd64'.

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

Re: [debian-www] Please add mips64el to stretch and add pages for buster

[Paul Wise]

On Mon, Feb 6, 2017 at 5:45 AM, Niels Thykier wrote:

> Here are two updated patches.

Committed.

Removed some trailing whitespace and moved your name to Patch-by.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [debian-www] Please add mips64el to stretch and add pages for buster

[Niels Thykier]

Emilio Pozuelo Monfort:
> On 05/02/17 20:47, Niels Thykier wrote:
>> Hi,
>>
>> I have made two patches for:
>>  * Adding mips64el as a release architecture for stretch
> 
> powerpc needs to be commented out.
> 
> Cheers,
> Emilio
> 
>

Indeed, thanks for catching that.

Here are two updated patches.

Thanks,
~Niels

>From b798fead55a2c20a1850700e7f3f845d0de46bb2 Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sun, 5 Feb 2017 18:33:24 +
Subject: [PATCH 1/2] release.data: Add mips64el and remove powerpc

Signed-off-by: Niels Thykier 
---
 english/releases/stretch/release.data | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/english/releases/stretch/release.data b/english/releases/stretch/release.data
index b38609155..cbdd31256 100644
--- a/english/releases/stretch/release.data
+++ b/english/releases/stretch/release.data
@@ -5,7 +5,7 @@
 	amd64,
 	i386,
 	armel,
-	powerpc,
+#	powerpc,
 	armhf,
 #	sparc,
 #	'kfreebsd-amd64',
@@ -25,6 +25,7 @@
 	arm64,
 	ppc64el,
 #	ppc64,
+	mips64el,
 );
 
 # list of languages install manual is translated to
-- 
2.11.0

>From dc7d73ec9f7089d1768b034bf091e1fca22218b8 Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sun, 5 Feb 2017 18:48:51 +
Subject: [PATCH 2/2] Add releases/buster to the website

There are forward links in the releases/stretch websites that activate
when stretch is marked as the stable release.

Signed-off-by: Niels Thykier 
---
 english/releases/Makefile  |   2 +-
 english/releases/buster/Makefile   |  21 +++
 english/releases/buster/credits.wml|  13 ++
 english/releases/buster/debian-installer/Makefile  |  13 ++
 english/releases/buster/debian-installer/index.wml | 191 +
 english/releases/buster/errata.wml |  74 
 english/releases/buster/index.wml  |  92 ++
 english/releases/buster/installmanual.wml  |  44 +
 english/releases/buster/release.data   |  89 ++
 english/releases/buster/releasenotes.wml   |  41 +
 english/releases/buster/reportingbugs.wml  |  49 ++
 english/template/debian/release_info.wml   |   4 +
 12 files changed, 632 insertions(+), 1 deletion(-)
 create mode 100644 english/releases/buster/Makefile
 create mode 100644 english/releases/buster/credits.wml
 create mode 100644 english/releases/buster/debian-installer/Makefile
 create mode 100644 english/releases/buster/debian-installer/index.wml
 create mode 100644 english/releases/buster/errata.wml
 create mode 100644 english/releases/buster/index.wml
 create mode 100644 english/releases/buster/installmanual.wml
 create mode 100644 english/releases/buster/release.data
 create mode 100644 english/releases/buster/releasenotes.wml
 create mode 100644 english/releases/buster/reportingbugs.wml

diff --git a/english/releases/Makefile b/english/releases/Makefile
index 1fb554361..cf022077f 100644
--- a/english/releases/Makefile
+++ b/english/releases/Makefile
@@ -3,7 +3,7 @@
 
 WMLBASE=..
 CUR_DIR=releases
-SUBS=hamm slink potato woody sarge etch lenny squeeze wheezy jessie stretch sid
+SUBS=hamm slink potato woody sarge etch lenny squeeze wheezy jessie stretch buster sid
 
 include $(WMLBASE)/Make.lang
 
diff --git a/english/releases/buster/Makefile b/english/releases/buster/Makefile
new file mode 100644
index 0..744ff3b4d
--- /dev/null
+++ b/english/releases/buster/Makefile
@@ -0,0 +1,21 @@
+# If this makefile is not generic enough to support a translation,
+# please contact debian-www.
+
+WMLBASE=../..
+CUR_DIR=releases/buster
+SUBS=debian-installer
+
+include $(WMLBASE)/Make.lang
+
+index.$(LANGUAGE).html: index.wml $(TEMPLDIR)/release.wml \
+  $(ENGLISHDIR)/releases/buster/release.data $(TEMPLDIR)/release_info.wml
+
+releasenotes.$(LANGUAGE).html: releasenotes.wml $(TEMPLDIR)/release.wml \
+  $(ENGLISHDIR)/releases/buster/release.data $(TEMPLDIR)/release_info.wml \
+  $(ENGLISHDIR)/releases/arches.data \
+  $(wildcard $(HTMLDIR)/*/release-notes*)
+
+installmanual.$(LANGUAGE).html: installmanual.wml $(TEMPLDIR)/release.wml \
+  $(ENGLISHDIR)/releases/buster/release.data $(TEMPLDIR)/release_info.wml \
+  $(ENGLISHDIR)/releases/arches.data \
+  $(wildcard $(HTMLDIR)/*/install*)
diff --git a/english/releases/buster/credits.wml b/english/releases/buster/credits.wml
new file mode 100644
index 0..aca17b4ac
--- /dev/null
+++ b/english/releases/buster/credits.wml
@@ -0,0 +1,13 @@
+#use wml::debian::template title="Debian 10 -- Credits (or Blame)" BARETITLE=true
+
+Release management
+
+This release of Debian was managed by Emilio Pozuelo Monfort and
+Niels Thykier, with the assistance of Adam D. Barratt, Cyril
+Brulebois, Julien Cristau, Mehdi Dogguy, Philipp Kern, Ivo De Decker
+and Jonathan Wiltshire.
+
+The rest of Debian
+
+The developers and everyone else
+who contributed.
diff --git 

Re: [debian-www] Please add mips64el to stretch and add pages for buster

[Emilio Pozuelo Monfort]

On 05/02/17 20:47, Niels Thykier wrote:
> Hi,
> 
> I have made two patches for:
>  * Adding mips64el as a release architecture for stretch

powerpc needs to be commented out.

Cheers,
Emilio

>  * Adding pages for buster under www.d.o/releases/buster
>(also adds a version for stretch to fix a minor visual
> glitch in some pages)
> 
> Please review and commit these patches. :)
> 
> Thanks,
> ~Niels
> 

Re: Debian-8.6

[Konstantin Khomoutov]

On Sun, 15 Jan 2017 22:05:53 + (UTC)
 wrote:

> Why is Firefox 45 esr so buggy and freezes up in Debian 8.6 ? No add
> ons or extensions are installed. Iceweazel was bad, but the outdated
> Firefox makes Debian unusable when using the internet. Debian kde and
> gnome notify me when updates are ready, why not cinnamon or xfce.
> Even after I install gnome-packagekit there is still no notification
> of updates. This is very annoying when I want to use cinnamon and two
> days later discover that there are over a 100 updates waiting to be
> installed and I have to install something that should have been
> installed by default.

Please use up-to-date firefox packages from http://mozilla.debian.net.

In either case, such questions are unfit for the debian-release mailing
list; please use debian-users next time.

Re: Debian 8.7 and Tomcat 8.5 support

[Niels Thykier]

dpawluk:
> Hello,
> I would like to ask, if Debian 8.7 release supports Apache 8.5.x?
> 

Hi,

Debian 8.7 will /not/ have Apache Tomcat 8.5, but it is available from
jessie-backports (which has 8.5.9-1~bpo8+1 at the moment).

Thanks,
~Niels

Re: [debian-mysql] getting mysql-5.6 out of stretch

[Emilio Pozuelo Monfort]

On 27/10/16 11:33, Otto Kekäläinen wrote:
> Hello!
> 
> We have not filed a mass bug report against packages regarding
> transitioning to default-mysql-*. Would you like to file it?
> I made a Lintian rule that is now in use, but a mass bug filing would
> speed things up.

Yes, but please send a notice with a dd-list to debian-devel@ first.

Thanks,
Emilio

Re: [debian-mysql] getting mysql-5.6 out of stretch

[Alexander Wirt]

On Thu, 27 Oct 2016, Otto Kekäläinen wrote:

> Hello!
> 
> We have not filed a mass bug report against packages regarding
> transitioning to default-mysql-*. Would you like to file it?
> I made a Lintian rule that is now in use, but a mass bug filing would
> speed things up.
Isn't that a little bit late in the release process? 

It also was for openssl.

Alex

Re: [debian-mysql] getting mysql-5.6 out of stretch

[Otto Kekäläinen]

Hello!

We have not filed a mass bug report against packages regarding
transitioning to default-mysql-*. Would you like to file it?
I made a Lintian rule that is now in use, but a mass bug filing would
speed things up.

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

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

Re: Debian Archive Signing Key

[Jp.vanzyl]

Sent from my Samsung Galaxy smartphone.
 Original message From: "Jp.vanzyl"  
Date: 18/09/2016  21:07  (GMT+02:00) To: Jvz22 , Jvz4773 
, Jvz4773 , Jvz22 
 Subject: Debian Archive Signing Key 




Sent from my Samsung Galaxy smartphone.

Re: [debian-mysql] Introducing default-mysql-* metapackages

[Rene Engelhard]

Hi,

On Tue, Aug 16, 2016 at 11:36:15AM +0300, Otto Kekäläinen wrote:
> Yes, this scheme is very flexible and in cases like   
> > mysql-connector-c++ the package can depend explicitly on the MySQL  
>   > package and not the default package.

OK.

> > Or we keep a working version with MariaDB, but then again there's other
> > packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)...
> 
> I think mysql-workbench works just fine with MariaDB, it only
> complains about the version string not being what it assumes as it
> thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch
> mysql-workbench to do proper version string comparison.

Sure, but TTBOMK it wants Connector/C >= 1.1.7 which then in turn needs
libmysqlclient-dev 5.7. That was the point.

I also think it should be able to _connect_ to a MariaDB then...

Regards,

Rene

Re: [debian-mysql] Introducing default-mysql-* metapackages

[Otto Kekäläinen]

Hello!

2016-08-16 7:44 GMT+03:00 Rene Engelhard :
> On Sun, Jul 10, 2016 at 05:22:22PM +0300, Otto Kekäläinen wrote:
>> Hello maintainers of packages that depend in MySQL/MariaDB!
>
> Not everyone is required to read -devel. Mailing them where they read
> it (and be it Cc'ing them) would be better.
>
> I am subscribed to -devel but still missed this mail (though I knew there
> was something ongoing)

That is why we'll send a mail about this to debian-devel-announce soon
to get more visibility.

>> BEFORE: Build-Depends: libmysqlclient-dev
>> AFTER: Build-Depends: default-libmysqlclient-dev
>>
>> BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends:
>> mariadb-server | virtual-mysql-server
>> AFTER: Depends: default-mysql-server | virtual-mysql-server
>>
>> BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends:
>> mariadb-client | virtual-mariadb-client
>> AFTER: Depends: default-mysql-client | default-mysql-client
>  
> ITYM virtual-mysql-client :)

Yes, sorry for the typo.

>> If a maintainer knows that his/her package only works with one
>> variant, then the package can depend directly on that package and not
>> use the default-mysql-* (matches one) or virtual-mysql-* (matches any)
>> schemes. Please get in touch if this applies to you. At the moment
>> there should be no such packages, but in the future cases like this
>> can arise when MySQL and MariaDB develop diverging feature sets.
>
> Well, I know of packages needing MySQL 5.7 and/or failing to build against
> MariaDB for other reasons. e.g. mysql-connector-c++. Upstream is Oracle,
> so they obviously won't care about MariaDB..

Yes, this scheme is very flexible and in cases like
mysql-connector-c++ the package can depend explicitly on the MySQL
package and not the default package. The same applies also for some
packages that use features available in MariaDB but not available in
MySQL.

>> Packages built against default-mysqlclient-dev and link using
>> "-lmysqlclient" will end up with a shared library dependency on either
>> libmysqlclient.so.X or libmariadbclient.so.X depending on the default
>> defined by the release team at build time. These will be provided by
>> the libmysqlclient18 (soon to be libmysqlclient20) and
>> libmariadbclient18 packages, which will be co-installable. Packages
>> which require particular functionality available from only one of the
>> forks may Build-Depend directly on libmysqlclient-dev or
>> libmariadbclient-dev and then link using "-lmysqlclient" or
>> "-lmariadbclient" respectively. Again, please get in touch if this
>> applies to you.
>
> See above.
>
> So this one could still use libmysqlclient-dev?

Yes

> Or we keep a working version with MariaDB, but then again there's other
> packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)...

I think mysql-workbench works just fine with MariaDB, it only
complains about the version string not being what it assumes as it
thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch
mysql-workbench to do proper version string comparison.

>> The default-mysql-* metapackages will be uploaded to Experimental soon
>> and to Unstable once we are confident there are no regressions. Once
>> they are available in Unstable, we will announce this on
>
> I have seen those accepted in unstable this morning so.. :)

Yes, it was uploaded 12 hours ago. I didn't have time to announce it
just yet. Stay tuned :)

Re: [Debian-ports-devel] [d...@debian.org: GCC 6 defaults change, including icu 57 and boost 1.61 transitions]

[John Paul Adrian Glaubitz]

On 08/03/2016 10:54 PM, Aurelien Jarno wrote:
> FYI as it will also have to to be done on the debian-ports architectures.
> Note that the upload of gcc-defaults defaulting to gcc-6 just happened.

I think this is really a bit of a short notice, but I will have to bite
the bullet and fix all the fallout manually then -.-.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Debian-med-packaging] migration exception for mhap

[Jonathan Wiltshire]

On 2016-07-23 23:14, Afif Elghraoui wrote:

على السبت 23 تـمـوز 2016 ‫06:56، كتب Jonathan Wiltshire:

On 2016-07-23 09:22, Afif Elghraoui wrote:

The latest upstream release of the mhap package adds a new dependency
on
libssw-java, which is not available for i386. The testing excuses 
page

for mhap currently says:

8 days old (needed 5 days)
mhap/i386 unsatisfiable Depends: libssw-java

May we have this package unblocked for migration?


No; you can't have a package in testing with unsatisfiable 
dependencies.

Either make libssw-java available on i386 or fix your dependencies.



mhap is arch:all. libssw-java contains Java bindings for its C library
and is not supported on i386. The dependencies are not broken. I hope
this is a clear enough explanation.


Yes, I know all that, but your dependencies are still broken. Your 
package is uninstallable on any architecture other than amd64.


For performance reasons britney only tests installability on amd64 and 
i386 (hence the message), otherwise the list would be much longer.


A package cannot migrate if it is not installable on the test 
architectures.



--
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

Re: [Debian-med-packaging] migration exception for mhap

[Afif Elghraoui]

على السبت 23 تـمـوز 2016 ‫06:56، كتب Jonathan Wiltshire:
> On 2016-07-23 09:22, Afif Elghraoui wrote:
>> The latest upstream release of the mhap package adds a new dependency 
>> on
>> libssw-java, which is not available for i386. The testing excuses page
>> for mhap currently says:
>>
>> 8 days old (needed 5 days)
>> mhap/i386 unsatisfiable Depends: libssw-java
>>
>> May we have this package unblocked for migration?
> 
> No; you can't have a package in testing with unsatisfiable dependencies. 
> Either make libssw-java available on i386 or fix your dependencies.
> 

mhap is arch:all. libssw-java contains Java bindings for its C library
and is not supported on i386. The dependencies are not broken. I hope
this is a clear enough explanation.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Clint Byrum]

Excerpts from Otto Kekäläinen's message of 2016-07-03 12:46:29 +0100:
> > 3. libmysqlclient.so.18
> 
> Here theres's no concensus yet within the pkg-mysql-maint team on this one.
> 

And IMO, there won't be one until MariaDB accepts that they've created a
forked library that is API-incompatible with libmysqlclient.

> I suggest we extend the mysql-defaults source package to provide a
> real default-mysqlclient-dev metapackage, which other packages can
> build depend on, using versions if needed (just as default-jdk does).
> 
> Current mariadb-10.0 source package does not ship any
> libmariadbclient18 nor libmariadbclient-dev packages at all, as
> previously it was seen as against the policy (but mariadb-5.5 in
> Debian did). I suggest we start producing them now again to make a
> libmysqlclient.so(.18) available from mariadb-10.0.
> 
> Having two libmysqlclient.so.18 files from two different packages is a
> controversial topic. They are not identical so it is ugly to use the
> same name. This is however a necessity dictated by the need to provide
> a drop-in-replacement that can be used directly without going into
> every single clienting program and editing the C headers and soname
> calls.
> 

It's _extremely_ ugly to use this name. MariaDB needs to stop shipping a
library that claims to be libmysqlclient, but is not.

This notion of a drop-in replacement is just a bait-and-switch tactic
(even if it isn't meant to be one). By allowing somebody to build
against a new API without changing their build scripts, it's just
allowing them to accidentally use that new API and then unknowingly be
dependent on symbols only available in the forked library. There's a
different between ABI equality, and ABI compatibility, and IMO, the
former is more important for Debian.

> It should be noted that the Debian packages shipped directly from
> mariadb.org have provided the libmysqlclient.so file since forever and
> there has not been problems and the drop-in-replacement function has
> been fullfilled as expected. All packages that used to depend on
> Oracle MySQL client library have continued to function with the
> MariaDB equivalent when mariadb.org repositories are activated.
> 

There have not been problems that users reported to MariaDB, because
the issue is extremely subtle and subversive. Those users would only
ever know that there was a problem if they wanted to distribute their
code and had another user try to build on libmysqlclient. For the
average MariaDB user, that's not such a big deal, as they may not be
distributing their code. For Debian, we're distributing all of it, and
we have a duty to give users reliable software. We don't want to build
against libmariadbclient-dev-compat and then the software just doesn't
work with libmysqlclient.so.18 from MySQL.

> It should also be noted that the soname version number 18 has been
> used in Oracle MySQL for a long time without bumping it despite
> changes in the API. The API changes have also gone undocumented all
> the time as the libmysqlclient18 package does not have .symbols file.
> Oracle has finally bumped the soname version to 20 in MySQL 5.7. The
> number 19 is not used anywhere, but was left as something that can be
> resorted to in 5.6, in case somebody would complain too much that 5.5
> and 5.6 API differ but have same version number. No one has, so for
> all practical purposes, the current situation is OK.
> 

The past was horrible, and MySQL obviously did weird things and our
packages were not sufficient to police this properly. But that doesn't
change the fact that MariaDB has hijacked the mysqlcient soname.

> The solution I suggest works nicely in the scope of
> libmysqlclient18/libmariadbclient18 and is resilent for scenarios
> where libmysqlclient20 is introduced or where even more client
> libraries are available (mainly libmariadb2), but I won't go into the
> details of those now, as I think here is enough information to decide
> on whether or not it is OK to provide libmysqlclient.so from a
> libmariadbclient18 package. This would also mean we introduce the
> default-libmysqlclient-dev pmetaackage which depends on either
> libmariadbclient-dev or libmysqlclient-dev package.
> 
> Please comment and advice on how to proceed with packaging to satisfy
> with the switchable defaults requirement.
>

IMO, it's only OK for MariaDB to provide libmysqlclient.so if it is 100%
equivalent to MySQL's libmysqlclient.so. If there are extra API calls,
and extra symbols, it's not the same, and it won't produce a compatible
program linked to libmysqlclient.so.18.

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Andreas Beckmann]

On 2016-07-06 09:54, Otto Kekäläinen wrote:
> 2016-07-05 19:52 GMT+03:00 Robie Basak :
>> PROPOSAL B
> 
> The whole pkg-mysql-maint team is behind the proposal Robie now wrote
> about. We have been discussing actively and engineering it during the
> last two days. It was also one of the topics discussed at the
> MariaDB/MySQL Bof at DebConf yesterday and we agreed about it. Only
> minor implementation details are left to decide on, like what command
> to use to make the links multiarch.

Nice! Can you summarize what what the new real/virtual packages will be
called and what packages are supposed to put into their
Depends/Build-Depends? (General packages that can work with any vendor
as well as packages specific to a single vendor.)

I see that the new unified repository is on alioth for mysql-5.7 and
mysql-defaults. I've now updated my repo at
git+ssh://git.debian.org/git/users/anbe/tmp/mysql.git
with a proposed integration of mysql-5.6, too.
There are also branches for dropping the mysql-common package from both
mysql-5.6 and mysql-5.7 once mysql-defaults is uploaded.

> If you want to have a say, please do so now before we finalize the
> solution we currently believe is the best one.
> 
> I expect to upload this new scheme to experimental in a few days for a
> larger audience to test and verify.


Andreas

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Otto Kekäläinen]

2016-07-05 19:52 GMT+03:00 Robie Basak :
> PROPOSAL B

The whole pkg-mysql-maint team is behind the proposal Robie now wrote
about. We have been discussing actively and engineering it during the
last two days. It was also one of the topics discussed at the
MariaDB/MySQL Bof at DebConf yesterday and we agreed about it. Only
minor implementation details are left to decide on, like what command
to use to make the links multiarch.

If you want to have a say, please do so now before we finalize the
solution we currently believe is the best one.

I expect to upload this new scheme to experimental in a few days for a
larger audience to test and verify.

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Robie Basak]

On Tue, Jul 05, 2016 at 11:41:15AM +0200, Jonathan Wiltshire wrote:
> > I suggest we extend the mysql-defaults source package to provide a
> > real default-mysqlclient-dev metapackage, which other packages can
> > build depend on, using versions if needed (just as default-jdk does).
> 
> Yes.
> 
> > Current mariadb-10.0 source package does not ship any
> > libmariadbclient18 nor libmariadbclient-dev packages at all, as
> > previously it was seen as against the policy (but mariadb-5.5 in
> > Debian did). I suggest we start producing them now again to make a
> > libmysqlclient.so(.18) available from mariadb-10.0.
> > 
> > Having two libmysqlclient.so.18 files from two different packages is a
> > controversial topic. They are not identical so it is ugly to use the
> > same name. This is however a necessity dictated by the need to provide
> > a drop-in-replacement that can be used directly without going into
> > every single clienting program and editing the C headers and soname
> > calls.
> 
> We discussed this in the release team and concluded that having two
> libmysqlclient.so.18 files in two packages is likely to run into problems
> later if/when they diverge, so there is no point delaying that pain.
> Especially as they are not identical even now.

Sorry, I'm not clear on the sense of your statement. By this, are you
agreeing to do it now, or saying that we shouldn't do it?

> I wonder if pkgconfig can be any help here? That involves a one-time change
> to client packages if they don't already use pkgconfig but doesn't have to
> be repeated if the default switches.

I experimented down another route. In my proposal, I keep the
libmysqlclient for MySQL only, and use libmariadbclient for the MariaDB
upstream. So:

PROPOSAL B

pkg:libmysqlclient18 ships libmysqlclient.so.18
pkg:libmysqlclient-dev ships libmysqlclient.so

(no change so far).

Then:

pkg:libmariadbclient18 is created to ship libmariadbclient.so.18
pkg:libmariadbclient-dev is created to ship libmariadbclient.so

These are new additions to src:mariadb-10.0. We have to patch a little
to switch from MariaDB from building libmysqlclient to use
libmariadbclient instead.

pkg:libmariadbclient-dev must conflict with pkg:libmysqlclient-dev
because they ship the same header files, but this affects builds only,
and not (normal) runtime.

Then:

pkg:libmariadbclient-dev-compat is created to ship a symlink:
libmysqlclient.so -> libmariadbclient.so. This must conflict with
pkg:libmysqlclient-dev, but again we're affecting builds only, and not
normal runtime.

pkg:default-libmysqlclient-dev is created to depend on
pkg:libmariadbclient-dev-compat.

What this gets us:

 1) Maintainers can build against whichever one they prefer, and/or the
 release team is in a position to be able to mandate a default as
 required.

 2) Users can build against either, and continue to use either. There is
 no system wide choice being forced here.

 3) No confusion between MySQL and MariaDB. "libmysqlclient.so.18" is
 always MySQL and "libmariadbclient.so.18" is always MariaDB.

 4) Maintainers need only change their build dependencies. Upstreams
 that try to link using "-lmysqlclient" will continue to work.

END OF PROPOSAL


I tested this and it appears to work.
https://git.launchpad.net/~racb/ubuntu/+source/mariadb-10.0/log/ is my
MariaDB test modification (PoC with amd64 hardcoded). I created a
fake "equivs" libmysqlclient-dev that depends only on
libmariadbclient-dev-compat, and dropped the necessary conflicts, for
testing purposes. cacti-spine (a simple consumer of libmysqlclient) then
successfully linked against libmariadbclient.so.18 and depended on
pkg:libmariadbclient18 with no further modification.

If we want to test more packages, it's sufficient to just rebuild them
with my test build dependencies available.

Some commentary on my justifications above:

1) I believe this is the core of what the release team requested in
terms of MySQL and MariaDB. I appreciate of course that whatever hackery
we do to make this happen is something the release team should weigh in
on also.

3) I really don't want to go down the route of "libmysqlclient.so.18"
actually being MariaDB. It may be ABI-compatible now, but what about the
future? MySQL 5.7 already bumps to libmysqlclient.so.20, for example. If
and until MariaDB ships an ABI-compatible libmysqlclient.so.20, are we
going to ship both, one from each upstream? What if MariaDB's one turns
out not to be ABI compatible? I think down this path lies madness.
sonames give us a method to avoid this conflict by using different
names. We should use this if we can.

Feedback on this approach appreciated.

Robie

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[peter green]

2016-07-02 17:53 GMT+03:00 Otto Kekäläinen:
>  This is modeled after how default-jdk or default-mta works.

Actually default-jdk is a real metapackage, while default-mta is a
pure virtual package. I am not sure which way to pick here now.

https://packages.debian.org/jessie/default-mta
https://packages.debian.org/jessie/default-jdk
   

It depends on what behaviour you want on dist-upgrade.

A real package will stick arround, so if you switch the default then a 
dist-upgrade will pull in the new default. On the other hand a virtual 
package is never installed as such, so existing systems will keep their 
existing implementation.

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Otto Kekäläinen]

2016-07-02 17:53 GMT+03:00 Otto Kekäläinen :
> This is modeled after how default-jdk or default-mta works.

Actually default-jdk is a real metapackage, while default-mta is a
pure virtual package. I am not sure which way to pick here now.

https://packages.debian.org/jessie/default-mta
https://packages.debian.org/jessie/default-jdk

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Otto Kekäläinen]

Hello!

What does the release team think of introducing new purely virtual
packages named default-mysq-*, which are provided only by mariadb-*
packages?
This is modeled after how default-jdk or default-mta works.

In code if would look like this:
https://github.com/ottok/mariadb-10.0/commit/e162c743fcd59273ba948e19b71cb5ed5638f0f5

I am at DebConf. Grab me by the sleeve when you see me. I'd like to
have external input/advice on this and a in-person discussion about
the scenarios and deployment path would feel helpful to me.

- Otto

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Emilio Pozuelo Monfort]

On 24/06/16 20:05, Robie Basak wrote:
> On Fri, Jun 24, 2016 at 07:53:56PM +0200, Julien Cristau wrote:
>> Please don't use virtual-foo for non-virtual packages, that way lies
>> madness and confusion and despair :)
> 
> OK, but does anyone have any objection to the principle of my
> suggestion, even if we must use a different name?

You could do something like that. Or something like what we do with default-mta
and mail-transport-agent.

Cheers,
Emilio

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Robie Basak]

On Fri, Jun 24, 2016 at 07:53:56PM +0200, Julien Cristau wrote:
> Please don't use virtual-foo for non-virtual packages, that way lies
> madness and confusion and despair :)

OK, but does anyone have any objection to the principle of my
suggestion, even if we must use a different name?

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Julien Cristau]

On Fri, Jun 24, 2016 at 14:55:34 +0100, Robie Basak wrote:

> On Wed, Jun 01, 2016 at 07:03:42PM +0200, Andreas Beckmann wrote:
> > I prepared a prototype for a separate mysql-common package (and
> > default-* packages) at
> > git://git.debian.org/git/users/anbe/tmp/mysql-defaults.git
> > but so far nobody had time to review it.
> 
> A thought from Norvald. Do we really need more metapackages? What if we
> converted the existing virtual-mysql-{server-client} virtual packages
> into metapackages generated from src:mysql-defaults instead?
> 
> Then these would depend on "mariadb-server | mysql-server" etc. Existing
> packages would drop their preferred alternative and depend on
> "virtual-mysql-server" only. src:mysql-defaults would then have full
> control of the "default" just by swapping the alternatives.
> 
> The benefit would be fewer meta/virtual -packages. Is there any use case
> that is not covered by this?

Please don't use virtual-foo for non-virtual packages, that way lies
madness and confusion and despair :)

Cheers,
Julien


signature.asc
Description: PGP signature

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Robie Basak]

On Wed, Jun 01, 2016 at 07:03:42PM +0200, Andreas Beckmann wrote:
> I prepared a prototype for a separate mysql-common package (and
> default-* packages) at
> git://git.debian.org/git/users/anbe/tmp/mysql-defaults.git
> but so far nobody had time to review it.

A thought from Norvald. Do we really need more metapackages? What if we
converted the existing virtual-mysql-{server-client} virtual packages
into metapackages generated from src:mysql-defaults instead?

Then these would depend on "mariadb-server | mysql-server" etc. Existing
packages would drop their preferred alternative and depend on
"virtual-mysql-server" only. src:mysql-defaults would then have full
control of the "default" just by swapping the alternatives.

The benefit would be fewer meta/virtual -packages. Is there any use case
that is not covered by this?


signature.asc
Description: PGP signature

Re: Debian Jessie - Incorrect permissions on /bin directory

[Emilio Pozuelo Monfort]

On 02/03/16 12:46, Yves-Alexis Perez wrote:
> On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
>> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
>>
>> Yves-Alexis Perez  (2016-02-03):
>>>
>>> On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:

 I didn't check the whole archive, but doing so might be interesting.
>>> I did a quick check on a local mirror (which might be incomplete), and
>>> found
>>> three packages with errors:
>>>
>>> dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
>>> drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
>>> dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
>>> drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
>>> dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
>>> bin/$
>>> drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
>>>
>>> Note that lintian complains a lot about them:
>>>
>>> lintian sed_4.2.2-4+b1_amd64.deb
>>> W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
>>> Binary-only - copying to XS-Binary-only"
>>> W: sed: latest-debian-changelog-entry-without-new-date
>>> E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
>>> W: sed: description-synopsis-starts-with-article
>>> W: sed: non-standard-dir-perm bin/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip
>>> usr/share/doc/sed/changelog.Debian.gz
>>> W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
>>> W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
>>> W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
>>> (or pipe to a file/program)
>>> W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
>>>
>>> It looks like an umask problem at package build time. Right now it doesn't
>>> seem to have obvious security issues (like world writable /bin) but I'm
>>> not
>>> too sure there are not other stuff hidden.
>>>
>>> I guess it'd make sense to do an archive-wide lintian run to look for that
>>> kind of mistakes, and then ask for stable binNMUs of the relevant
>>> packages.
>> It seems to me that lintian looks at testing/unstable (at least looking
>> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
>> so I'm not sure this would help for stable.
>>>
>>>
>>> What do you think?
>> I think debian-release@ needs to be in the loop, doing so.
>>
> Hey,
> 
> so as far as I can tell there was no reaction from -release (although I can
> understand noone's really sure what to do here). Is it at least possible to
> schedule binNMUs in stable for those affected packages so future installs
> don't end up with bad permissions like these?

Would it make sense to start autorejecting packages that have this tag?

Emilio

Re: Debian Jessie - Incorrect permissions on /bin directory

[Jakub Wilk]

* Yves-Alexis Perez , 2016-03-02, 12:46:
I did a quick check on a local mirror (which might be incomplete), 
and found three packages with errors:


dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
bin/$
drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/

[...]
It looks like an umask problem at package build time. Right now it 
doesn't seem to have obvious security issues (like world writable 
/bin) but I'm not too sure there are not other stuff hidden.


I guess it'd make sense to do an archive-wide lintian run to look for 
that kind of mistakes, and then ask for stable binNMUs of the 
relevant packages.
It seems to me that lintian looks at testing/unstable (at least 
looking at 
https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6), so 
I'm not sure this would help for stable.


Yup, lintian.d.o only checks unstable. For sed, this is #774347, which 
is already fixed there.


so as far as I can tell there was no reaction from -release (although I 
can understand noone's really sure what to do here). Is it at least 
possible to schedule binNMUs in stable for those affected packages so 
future installs don't end up with bad permissions like these?


I believe sbuild uses umask 002, so binNMUs probably won't help. In 
fact, the stable version of sed was already built on buildds.


--
Jakub Wilk

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
> 
> Yves-Alexis Perez  (2016-02-03):
> > 
> > On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> > > 
> > > I didn't check the whole archive, but doing so might be interesting.
> > I did a quick check on a local mirror (which might be incomplete), and
> > found
> > three packages with errors:
> > 
> > dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
> > drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
> > dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
> > drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
> > dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
> > bin/$
> > drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
> > 
> > Note that lintian complains a lot about them:
> > 
> > lintian sed_4.2.2-4+b1_amd64.deb
> > W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
> > Binary-only - copying to XS-Binary-only"
> > W: sed: latest-debian-changelog-entry-without-new-date
> > E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
> > W: sed: description-synopsis-starts-with-article
> > W: sed: non-standard-dir-perm bin/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip
> > usr/share/doc/sed/changelog.Debian.gz
> > W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
> > W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
> > W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
> > (or pipe to a file/program)
> > W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
> > 
> > It looks like an umask problem at package build time. Right now it doesn't
> > seem to have obvious security issues (like world writable /bin) but I'm
> > not
> > too sure there are not other stuff hidden.
> > 
> > I guess it'd make sense to do an archive-wide lintian run to look for that
> > kind of mistakes, and then ask for stable binNMUs of the relevant
> > packages.
> It seems to me that lintian looks at testing/unstable (at least looking
> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
> so I'm not sure this would help for stable.
> > 
> > 
> > What do you think?
> I think debian-release@ needs to be in the loop, doing so.
> 
Hey,

so as far as I can tell there was no reaction from -release (although I can
understand noone's really sure what to do here). Is it at least possible to
schedule binNMUs in stable for those affected packages so future installs
don't end up with bad permissions like these?

Regards,
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Cyril Brulebois]

[Context: packages shipping /bin with “funny” permissions, seen in stable.]

Yves-Alexis Perez  (2016-02-03):
> On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> > I didn't check the whole archive, but doing so might be interesting.
> 
> I did a quick check on a local mirror (which might be incomplete), and found
> three packages with errors:
> 
> dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
> drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
> dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
> drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
> dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep bin/$
> drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
> 
> Note that lintian complains a lot about them:
> 
> lintian sed_4.2.2-4+b1_amd64.deb
> W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key 
> Binary-only - copying to XS-Binary-only"
> W: sed: latest-debian-changelog-entry-without-new-date
> E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
> W: sed: description-synopsis-starts-with-article
> W: sed: non-standard-dir-perm bin/ 0775 != 0755
> W: sed: package-contains-timestamped-gzip 
> usr/share/doc/sed/changelog.Debian.gz
> W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
> W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
> W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
> W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all (or 
> pipe to a file/program)
> W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
> 
> It looks like an umask problem at package build time. Right now it doesn't
> seem to have obvious security issues (like world writable /bin) but I'm not
> too sure there are not other stuff hidden.
> 
> I guess it'd make sense to do an archive-wide lintian run to look for that
> kind of mistakes, and then ask for stable binNMUs of the relevant packages.

It seems to me that lintian looks at testing/unstable (at least looking
at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
so I'm not sure this would help for stable.
> 
> What do you think?

I think debian-release@ needs to be in the loop, doing so.

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Michael Banck]

Hi,

jumping in here, cause I think this one is really uncalled for:

On Wed, Jan 27, 2016 at 08:30:09PM +, Steven Chamberlain wrote:
> And apart from sponsoring Debian packaging work, Oracle seems
> conspicuously missing from:
> http://debconf16.debconf.org/sponsors.html

So is about everybody else like Google, HP, Canonical - the fundraising
for DebConf16 is ongoing.

> http://debconf15.debconf.org/

Oracle sponsored DebConf15 (as MySQL) at the silver level:

http://debconf15.debconf.org/sponsors.xhtml
http://debconf15.debconf.org/images/sponsors/silver/mysql.png

> https://www.debian.org/mirror/sponsors
> https://www.freexian.com/en/services/debian-lts.html

I hope you see the irony in MariaDB being completely absent from all of
the above.


Michael

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

[Steven Chamberlain]

Norvald H. Ryeng wrote:
> >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.
> 
> I don't recognize those words, and it's not in the style I usually express
> myself. Are you paraphrasing?

Sorry, that was Robie Basak being quoted.

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

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

[Norvald H. Ryeng]

On Wed, 27 Jan 2016 21:30:09 +0100, Steven Chamberlain  
 wrote:



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 don't want to link discussions of financial sponsorship with the fact  
that MySQL is in Debian or with the activities in the Debian MySQL  
maintainer team. Let us please keep those separate. If you want to discuss  
sponsorship, please let's do so in a completely different thread and on  
its own merits.


That said, I want to correct a small factual error:

MySQL was a silver sponsor of DebConf15 and is listed as such. I attended  
the conference and had a great time. In fact, I was the only member of the  
Debian MySQL maintainer team to attend.



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.


I don't recognize those words, and it's not in the style I usually express  
myself. Are you paraphrasing?



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.


I'm not management, but no, we're not expecting special treatment. We're  
asking to know what the requirements that apply to all packages in the  
archive are. Changing security policies/practices is not done easily, and  
our users expect stability and predictability in this area. If Debian  
wants our policies/practice to change, presenting the requirements is the  
first step.


My job is to gather those requirements and present the complete story to  
management so that they can make a decision. If I have to go back to  
management again and again and ask for change because I uncover new  
requirements, I haven't done my job.


But we got some great news yesterday: the security team is working on at  
set of guidelines. I'm glad they do, and I look forward to a chance at  
finally resolving this. I'm optimistic.


Regards,

Norvald H. Ryeng

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.

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: [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

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

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

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

[Holger Levsen]

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.)

> 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…
 
> 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.


cheers,
Holger


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

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

[Pedretti Fabio]

> * Summary of options and selection status
>
> My original request for a decision proposed one of the following
> options, which I think we all agree are the only options available:
>
> 1) We carry and ship both, which I believe is the preference of the
> Debian MySQL Maintainers team by default since we do not agree to any
> other option. We have representatives from both sides who are working
> together and putting in the work to make this work technically.
>
> 2a) We carry both in unstable, but only MySQL in testing.
>
> 2b) We carry both in unstable, but only MariaDB in testing.
>
> 3a) We drop MariaDB completely, keeping only MySQL in unstable and
> testing.
>
> 3b) We drop MySQL completely, keeping only MariaDB in unstable and
> testing.

Another possible alternative (no idea how feasible it is, however) is
1) + having mariadb as a default provider for mysql-server.

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

[Lars Tangvald]

- Original Message -
From: spam...@debian.org
To: ste...@pyro.eu.org
Cc: robie.ba...@ubuntu.com, t...@security.debian.org, 
debian-release@lists.debian.org, pkg-mysql-ma...@lists.alioth.debian.org
Sent: Tuesday, January 26, 2016 8:15:26 AM GMT +01:00 Amsterdam / Berlin / Bern 
/ Rome / Stockholm / Vienna
Subject: Re: [debian-mysql] [Summary] Request for release team decision on 
MySQL and MariaDB
...
>> I was wondering why after the 2016-01-19 announcement, there is still no
>> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
>> just patched today.  Debian is typically much faster than this at
>> getting out patches.  Is it to do with complexity, available manpower,
>> or other things?

...
>Regarding the speed of patching: MySQL is massive. It takes several
>hours to build and fully test on a good quality machine. Because the
>patched version came out before the CVE's and CPU's attached to it, some
>of this was already done. But a final set of binaries must be prepared,
>tested, and uploaded. I think it is understandable that this might take
>more than 5 days. But it should be completed soon.

Hi,

I only have a comment on this specific question, as I only work on the 
technical side:
One of the criticisms by the security team has been that Oracle hasn't done 
anything to prepare the security updates. We've agreed that it makes sense for 
us to do this, and for the 2016-01-19 we've been working on preparing the 
patch, but it's been slow going because of unfamiliarity with the security 
patching process. We can definitely do this significantly faster, it's just the 
handover process for this update that's taking time.

--
Lars

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

[Otto Kekäläinen]

Hello!

As the principal maintainer of MariaDB server packaging in Debian I
should probably also chip in here.

First of all I'd like to thank Robie for the summary. Robie is correct
in pointing out that the release and security team's arguments are
somewhat based on disgust for Oracle and less on technical merits of
MySQL packages in Debian.

It is not very nice of Oracle to keep the CVE details hidden even to
the extent that they don't give out the details on a pkg-mysql-maint
mailing list when asked, not even when the questions were regarding
several months old CVEs that Oracle has had fixed in their releases
for some time, and disclosure could not generate much harm anymore.
Not nice indeed, but however not against the Debian policy, as
commenters in this thread rightfully point out. Has any other project
ever been kicked out from Debian due to too much security by
obscurity?

Oracle also has other things freedom and openness loving debianists
don't like, for example non-public bug tracker, non-public source code
development repository, no external committers, all development
discussions are done in in-house meetings and outside participation
via mailing lists or irc is practically impossible, online
documentation is no longer available on a free license, even man pages
have been removed from project source code etc. MariaDB is a much
nicer choice in this regard. Oracle MySQL basically does code dumping
instead of real free and open source software. But so does many other
companies too and their software is included in Debian. DFSG does not
forbid the code dumping style as long as the code dump is actually
released using a real free/open license.

Also the comparisons to OpenOffice vs LibreOffice, Hudson vs Jenkins
etc are not fair. For Oracle the MySQL project has a special role and
they keep developing it, so it is not a good argument to bluntly
punish Oracle MySQL for mismanagement in other projects.

The release and security teams should present, as Robie points out,
concrete and actionable lists on things that are wrong, and the
"wrongness" should preferably be based on Debian policy or something
else predictable and not on newly invented rules.

Presenting ethical arguments is OK if they are based on Debian core
documents. I am of course not against using ethics in the decision
making process, but the people who put a lot of time and effort in
MySQL packaging in Debian need fair treatment, and more objective
technical arguments are therefore preferred.

Presenting technical arguments should be based on a comparison of e.g.
https://tracker.debian.org/pkg/mysql-5.5
https://tracker.debian.org/pkg/mysql-5.6
https://tracker.debian.org/pkg/mariadb-5.5
https://tracker.debian.org/pkg/mariadb-10.0

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.

- 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]

- 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.

 - 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.

[1] 
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812812
[3] git log --since='2015-01-01' --oneline | wc -l
[4] git log --since='2015-01-01' | grep Author | sort -u | cut -c -20
| sort -u | wc -l


Then a few words about the decision:

2016-01-26 0:14 GMT+02:00 Robie Basak :
> My original request for a decision proposed one of the following
> options, which I think we all agree are the only options available:
>
> 1) We carry and ship 

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

[Otto Kekäläinen]

Hello!

2016-01-26 2:48 GMT+02:00 Steven Chamberlain :
> I was wondering why after the 2016-01-19 announcement, there is still no
> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
> just patched today.  Debian is typically much faster than this at
> getting out patches.  Is it to do with complexity, available manpower,
> or other things?

Technically I could have uploaded MariaDB 10.0.23 earlier, but I
cannot convince the stable release team or security team to upload it
to Jessie before it has officially been announced as a security update
with CVE identifiers and all.

I Ubuntu there is the Micro Release Exception, so in could have got
5.5.47 uploaded to Ubuntu 14.04 even without explicit security update
motivation. In fact I did prepare the upload and file
https://bugs.launchpad.net/ubuntu/+source/mariadb-5.5/+bug/1524704 on
December 10th, but as it as not a known security update at that time
nobody got interested enough to upload it.. Maybe tomorrow somebody
will as Ubuntu announced the MySQL security notice today, and Ubuntu
people usually accept my security updates in 1-2 days.