Re: dbconfig-common: near future change in dependency stack

[Paul Gevers]

Hi all,

On 06-12-15 14:23, Paul Gevers wrote:
> For those of you that backport their packages via the Debian backports
> archive, I will provide a backport of dbconfig-common once version 2.0.0
> reaches testing.

This has happened. dbconfig-common, dbconfig- and
dbconfig-no-thanks are now in sid, testing and jessie-backports.

For those package maintainers that have packages depending on
dbconfig-common, now is a good time to remove the dependency on
dbconfig-common and add the appropriate dbconfig- |
dbconfig-no-thanks dependency instead.

Paul



signature.asc
Description: OpenPGP digital signature

Re: dbconfig-common: near future change in dependency stack

[Paul Gevers]

Hi Frederic-Emmanuel,

On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote:
> I am the maintainer of tango-db which use dbconfig-common and a mysql 
> database.
> It seems that there is currently a discussion about he support of mysql and 
> mariadb for Debian 9

Can you please point me to the relevant discussion?

> Do you know if dbconfig-common will integrate a way to switch from mysql to 
> mariadb in the near futur.
> something whcih can help do the migration database from mysql to mariadb.

Actually, I don't think that is in scope of dbconfig-common. I would
rather expect that MariaDB would provide that functionality. It is
required for more packages and situations than just those supported by
dbconfig-common.

> Also, I have the feeling that the new dbconfig-no-thanks is too coarse.
> It mean no database of any kind supported by dbconfig-common could be install 
> on this machine.

There must be a misunderstanding here (and I would like to learn where
it comes from). dbconfig-no-thanks does NOTHING to get in the way of any
database. The ONLY thing that it does it prevent dbconfig-common from
managing the database for the package that depends on the
dbconfig-common framework. As the description reads now:
"""
If a package relies on the dbconfig-common framework for database setup
and maintenance, installing dbconfig-no-thanks instead of one of
dbconfig's database-specific packages will block this function. It is
intended for cases where the system administrator desires or requires
full control of the database or where dbconfig-common makes bad choices,
and typically leaves the depending packages non-functional until
manually configured.
"""

dbconfig-no-thanks only conflicts with all dbconfig- packages so
it doesn't block anything else.

> But I would like to express, no mysql on my computer, but I could allow 
> postgresql for other packages.
> Is it possible to have this use case and how should we instrument our package 
> for this?

I am not sure what exactly you want, but you CAN'T use the
dbconfig-common framework to prevent installation of MySQL, it is not
intended for that. With dbconfig-no-thanks installed ANY package that
relies on the dbconfig-common framework will not configure its database.
Without installing dbconfig-no-thanks, you can still (as has always been
the case) opt-out of dbconfig-common support per package, but this
requires either preseeding or responding to the corresponding debconf
question.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#813186: ITP: ruby-sentry-raven -- client interface for the Sentry error logger

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-sentry-raven
  Version : 0.15.3
  Upstream Author : Sentry
* URL : https://github.com/getsentry/raven-ruby
* License : Apache-2.0
  Programming Lang: Ruby
  Description : client interface for the Sentry error logger

RE:dbconfig-common: near future change in dependency stack

[PICCA Frederic-Emmanuel]

Hello

thanks a lot for your work on dbconfig-common.

I am the maintainer of tango-db which use dbconfig-common and a mysql database.
It seems that there is currently a discussion about he support of mysql and 
mariadb for Debian 9

Do you know if dbconfig-common will integrate a way to switch from mysql to 
mariadb in the near futur.
something whcih can help do the migration database from mysql to mariadb.

Also, I have the feeling that the new dbconfig-no-thanks is too coarse.
It mean no database of any kind supported by dbconfig-common could be install 
on this machine.

But I would like to express, no mysql on my computer, but I could allow 
postgresql for other packages.
Is it possible to have this use case and how should we instrument our package 
for this?

once again thanks for your work


Frederic

RE:dbconfig-common: near future change in dependency stack

[PICCA Frederic-Emmanuel]

Hello Paul

> Can you please point me to the relevant discussion?

I speak about this [1]

> Actually, I don't think that is in scope of dbconfig-common. I would
> rather expect that MariaDB would provide that functionality. It is
> required for more packages and situations than just those supported by
> dbconfig-common.

I understand.

> There must be a misunderstanding here (and I would like to learn where
> it comes from). dbconfig-no-thanks does NOTHING to get in the way of any
> database. The ONLY thing that it does it prevent dbconfig-common from
> managing the database for the package that depends on the
> dbconfig-common framework. As the description reads now:
> """

ok thanks for the clarification, now I understand better what this no-thanks 
package is meant for.

> If a package relies on the dbconfig-common framework for database setup
> and maintenance, installing dbconfig-no-thanks instead of one of
> dbconfig's database-specific packages will block this function. It is
> intended for cases where the system administrator desires or requires
> full control of the database or where dbconfig-common makes bad choices,
> and typically leaves the depending packages non-functional until
> manually configured.
> """

If the no-thanks package is installed, what could be expected from the package 
maintainer in order to deal with the system administrator database mis 
configuration.
We just need to let the package un-configure in order to explain that the 
database is wrongly configure.
Do we have something in dbconfig-common whcih could say, here ok I do not 
manage the database but with this sysadmin database configuration, the package 
is not working.

> I am not sure what exactly you want, but you CAN'T use the
> dbconfig-common framework to prevent installation of MySQL, it is not
> intended for that. With dbconfig-no-thanks installed ANY package that
> relies on the dbconfig-common framework will not configure its database.
> Without installing dbconfig-no-thanks, you can still (as has always been
> the case) opt-out of dbconfig-common support per package, but this
> requires either preseeding or responding to the corresponding debconf
> question.

ok, it is clearer

Frederic


[1] 
https://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008605.html

Re: dbconfig-common: near future change in dependency stack

[The Wanderer]

On 2016-01-30 at 04:51, Paul Gevers wrote:

> Hi Frederic-Emmanuel,
> 
> On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote:

>> Do you know if dbconfig-common will integrate a way to switch from
>> mysql to mariadb in the near futur. something whcih can help do the
>> migration database from mysql to mariadb.
> 
> Actually, I don't think that is in scope of dbconfig-common. I would
> rather expect that MariaDB would provide that functionality. It is
> required for more packages and situations than just those supported
> by dbconfig-common.

Are there even cases where this is necessary?

Within the last year, I encountered an unacceptable - but intentional -
change in the MySQL client interface, so I removed the MySQL packages
and installed the MariaDB ones.

My existing database was picked up and used without issues; the
transition was, on that level, pretty much seamless as far as I recall.
I might have needed to re-apply some configuration tweaks in different
config files, but nothing more than that.

This seems to imply that either migration is not required, or MariaDB
already performs the needed migration transparently. (Or else that I'm
forgetting some part of the transition process, which is not
impossible.)

I can imagine that there could be cases where migration would be
required, but I'm not aware of any, and it didn't even occur to me to
expect that I might need to do any in my own case. I expected that the
two would be seamlessly compatible on the database level, and that
expectation seems to have been borne out.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#813198: ITP: python-aodhclient -- OpenStack Alarming as a Service - Python & cli client

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-aodhclient
  Version : 0.1.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/python-aodhclient
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Alarming as a Service - Python & cli client

 Aodh provides alarming for OpenStack. The alarming component of Aodh, first
 delivered in the Havana version, allows you to set alarms based on threshold
 evaluation for a collection of samples. An alarm can be set on a single meter,
 or on a combination. For example, you may want to trigger an alarm when the
 memory consumption reaches 70% on a given instance if the instance has been up
 for more than 10 min.   
 .
 This package provides the client Python module and CLI.

Re: dbconfig-common: near future change in dependency stack

[Paul Gevers]

Hi,

On 30-01-16 12:30, PICCA Frederic-Emmanuel wrote:
>> If a package relies on the dbconfig-common framework for database setup
>> and maintenance, installing dbconfig-no-thanks instead of one of
>> dbconfig's database-specific packages will block this function. It is
>> intended for cases where the system administrator desires or requires
>> full control of the database or where dbconfig-common makes bad choices,
>> and typically leaves the depending packages non-functional until
>> manually configured.
>> """
> 
> If the no-thanks package is installed, what could be expected from
> the package maintainer in order to deal with the system administrator
> database mis configuration.

If the administrator installs dbconfig-no-thanks, he must accept that
the database for the package is not configured. By the way, this has
always been the case, but until now only via the debconf questions.
There are too many use cases where the admin wants to handle the
database creation and population differently, so a package should not
abort on that. Ironically, quite some package even (wrongly and in my
opinion unnecessarily) ignore the exit status of dbconfig-common just
for that reason.

If a package really, really, really must have the proper database during
installation, I would say you can only have that if you use a local file
type database like sqlite. MySQL/MariaDB/PostgreSQL are too often
running on a remote server where you have absolutely no guarantee that
you can perform the required actions. If you have such a (local file
type) case I guess it may makes sense to not alternatively depend on
dbconfig-no-thanks, such that you will always pull in the right
dbconfig- package. However, this will get in the way of the
administrator when she want to install another package that uses
dbconfig-common but doesn't want the dbconfig-common help.

> We just need to let the package un-configure in order to explain that
> the database is wrongly configure.

I don't think so, and I have the feeling (due to previous discussions
and several bug reports) that a lot of developers and system admins
disagree with you here. They want Debian to install the package, and
handle the database in a different way. If the package would remain
unconfigured, that disturbs other installs in an unpleasant way.

> Do we have something in dbconfig-common whcih could say, here ok I do
> not manage the database but with this sysadmin database
> configuration, the package is not working.

I don't think dbconfig-common can do that. If dbconfig-common goes out
of the way, either because dbconfig-no-thanks is installed or because of
a debconf answer, the admin should expect that the package doesn't work,
because he told "us" to not preform the required actions. I truly
believe that packages that require a working database connection should
not run havoc, neither during install, nor during automatic startup,
when the required database connection and content is not available.

Paul



signature.asc
Description: OpenPGP digital signature

Downscaling responsibilities

[Enrico Zini]

Hello,

it has been clear to me for a while that I am unable to stay on top of
my Debian responsibilities. I feel like my usual pattern of things in
debian has gone like this:
 
 1. I see a problem, I have an idea how to solve it, I make a prototype
for it, I deploy it, look after it until I see that it actually
solves the problem, I'm happy.
 2. I get stuck looking after it forever.
 3. Goto 1.

I consider this unsustainable, because I feel like everything I do is
just adding to the pile of things that will haunt me forever.
As a consequence, for some years I have been actively avoiding starting
new fun things, for fear of getting stuck with even more things that I
am responsible for. Debtags, for example, is one of the first things I
tried to do in Debian and I'm still stuck being the primary (or sole?)
person responsible for it after more than 10 years.

I tried looking for more contributors, but I feel like it increases my
responsibilities even more, because I felt like I ended up with BOTH the
responsibility of looking after things AND the responsibility of
tutoring and motivating new people.

I tried to fix this by looking for people to take high level ownership
of my projects[1], but nothing really happened.

I have now decided to hit the reset button and end this situation. I'm
going to orphan most of my packages, and radically scale down the
complexity of the web services I'm stuck maintaining.

I'm writing this mail so that you'll know what is happening when you see
my name disappearing from packages like debtags, apt-xapian-index,
polygen and so on, and when you see features disappearing from
debtags.debian.net, nm.debian.org, contributors.debian.org and
sso.debian.org.


Enrico

[1] http://enricozini.org/2014/debian/on-responsibilities/
-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: dbconfig-common: near future change in dependency stack

[Clint Byrum]

Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800:
> On 2016-01-30 at 04:51, Paul Gevers wrote:
> 
> > Hi Frederic-Emmanuel,
> > 
> > On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote:
> 
> >> Do you know if dbconfig-common will integrate a way to switch from
> >> mysql to mariadb in the near futur. something whcih can help do the
> >> migration database from mysql to mariadb.
> > 
> > Actually, I don't think that is in scope of dbconfig-common. I would
> > rather expect that MariaDB would provide that functionality. It is
> > required for more packages and situations than just those supported
> > by dbconfig-common.
> 
> Are there even cases where this is necessary?
> 
> Within the last year, I encountered an unacceptable - but intentional -
> change in the MySQL client interface, so I removed the MySQL packages
> and installed the MariaDB ones.
> 

Which client interface would that be? libmysqlclient18 is still provided
by mysql, even if you install MariaDB.

> My existing database was picked up and used without issues; the
> transition was, on that level, pretty much seamless as far as I recall.
> I might have needed to re-apply some configuration tweaks in different
> config files, but nothing more than that.
> 

This is a one-way trip as of MariaDB 10. MariaDB 5.5 was compatible with
MySQL 5.5 and allowed using the same on-disk files. But MySQL may not
know how to read all of the files produced by MariaDB 10+. So I would
not count on this working again in the future. They're truly forks, and
you will need to backup/restore to make this work.

> This seems to imply that either migration is not required, or MariaDB
> already performs the needed migration transparently. (Or else that I'm
> forgetting some part of the transition process, which is not
> impossible.)
> 
> I can imagine that there could be cases where migration would be
> required, but I'm not aware of any, and it didn't even occur to me to
> expect that I might need to do any in my own case. I expected that the
> two would be seamlessly compatible on the database level, and that
> expectation seems to have been borne out.
> 

Yeah, that would be nice, but the reality is, code is only flowing
_away_ from MySQL at this point. MariaDB's changes don't go back into
MySQL. So the forks will just get further and further apart.

Re: Downscaling responsibilities

[Chris Boot]

On 30/01/16 13:22, Enrico Zini wrote:
> Hello,
> 
> it has been clear to me for a while that I am unable to stay on top of
> my Debian responsibilities.

Hi Enrico,

First of all, I'm sure I won't be the only person to want to thank you
for all that you have done for Debian (and beyond) so far. It's people
like you who have inspired me to join this community. I totally
understand that you want to scale back on how much you're responsible for.

> I have now decided to hit the reset button and end this situation. I'm
> going to orphan most of my packages, and radically scale down the
> complexity of the web services I'm stuck maintaining.
> 
> I'm writing this mail so that you'll know what is happening when you see
> my name disappearing from packages like debtags, apt-xapian-index,
> polygen and so on, and when you see features disappearing from
> debtags.debian.net, nm.debian.org, contributors.debian.org and
> sso.debian.org.

I guess the bit I don't follow is removing features from various
services, but carrying on maintaining them.

I realise that with packages one can RFA or totally Orphan them and make
it obvious to other parties that a new maintainer is required. It feels
like perhaps that's lacking for some of the Debian infrastructure services.

While I don't feel I can realistically volunteer to maintain any of the
things you are trying to orphan, I also had no real idea that this was
on the cards. I'm sure I'm not the only one.

Do we need a WNP{Services} to improve the visibility of this kind of thing?

Cheers,
Chris

-- 
Chris Boot
bo...@debian.org
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE 



signature.asc
Description: OpenPGP digital signature

Re: Downscaling responsibilities

[Ian Jackson]

Enrico Zini writes ("Downscaling responsibilities"):
> [stuff]

I just wanted to say thanks for all the work you have put in.

And also to tell you that it is totally OK to not want to end up here:

>  2. I get stuck looking after it forever.

So it is totally OK for you to to do this:

> I have now decided to hit the reset button and end this situation. I'm
> going to orphan most of my packages, and radically scale down the
> complexity of the web services I'm stuck maintaining.

You forebrain knows this, of course, but I hope that saying so will
help your hindbrain realise it too.

Best regards,
Ian.

Re: Downscaling responsibilities

[Enrico Zini]

On Sat, Jan 30, 2016 at 03:20:48PM +, Chris Boot wrote:

> I guess the bit I don't follow is removing features from various
> services, but carrying on maintaining them.

Chopping some overengineering out of debtags.debian.net is something I
could actually have fun with. I also hope that by freeing myself from
some commitments, I can have fun with some of my todo list items on
nm.d.o and contributors.d.o.

I still would like not to be alone with the responsibility for them.
The offer on http://enricozini.org/2014/debian/on-responsibilities/
still stands.


> I realise that with packages one can RFA or totally Orphan them and make
> it obvious to other parties that a new maintainer is required. It feels
> like perhaps that's lacking for some of the Debian infrastructure services.
> 
> While I don't feel I can realistically volunteer to maintain any of the
> things you are trying to orphan, I also had no real idea that this was
> on the cards. I'm sure I'm not the only one.
> 
> Do we need a WNP{Services} to improve the visibility of this kind of thing?

I think we need something like that. For each web service, we could use
at least a list of maintainers and a (private) address that goes to the
maintainers, which can be used for things like contact information on
html  tags, page footers, cron emails, and error notifications
from the site[1].


[1] https://docs.djangoproject.com/en/1.9/ref/settings/#admins

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Downscaling responsibilities

[Enrico Zini]

On Sat, Jan 30, 2016 at 05:02:10PM +, Ian Jackson wrote:
> Enrico Zini writes ("Downscaling responsibilities"):
> > I have now decided to hit the reset button and end this situation. I'm
> > going to orphan most of my packages, and radically scale down the
> > complexity of the web services I'm stuck maintaining.
> You forebrain knows this, of course, but I hope that saying so will
> help your hindbrain realise it too.

You mail moved and encouraged me, because I feel like I got acceptance
in my need for freedom and still a sense of belonging.

Thank you <3


Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

The state of cross building

[Helmut Grohne]

Hi,

Let me give a status update on how well cross building works in
unstable.

Toolchain
-

We have cross compilers and crossbuild-essential-* packages in unstable
for quite a while now. (Thanks to Matthias Klose.) These tend to work
well. Recently, sbuild saw significant improvements wrt. cross building
such that now one can simply "sbuild --build=arch1 --host=arch2 ..." and
have a reasonable expectation that it works. (Thanks to Johannes
Schauer.) Also pkg-config now ships the symlinks to a working cross
wrapper. (Thanks to Tollef Fog Heen.) Many more things have happened and
the gist is that much of the toolchain just works now! :)

Cross building the Debian archive
-

Debian unstable has about 22000 source packages. Out of those, about 5000
source packages can satisfy their Build-Depends in a cross build
setting. For failing packages, detailed diagnostics can be found at
http://bootstrap.debian.net/cross_all.html. (Thanks to Johannes Schauer.)

Out of those 5000 source packages, I selected 3000 popular (as in
popcon) source packages and built them using debomatic (build arch =
amd64, host arch = ppc64el). (Thanks to Luca Falavigna.) About 1000
builds were successful (which doesn't imply that the resulting packages
actually work.) We can conclude that about 4% of Debian can be cross
built today.

You can find the build logs at:
http://subdivi.de/~helmut/debomatic-logs/

Processing the logs
---

I've hacked up a script that guesses failure reasons by scanning the
logs with some regular expressions. Common issues are:

 * (>800) Using the build architecture compiler or linker.
 * (>150) Bug #812136 in dh_auto_build for cmake 
 * (>130) configure fails due to missing values in config.site

Bug reports
---

I would appreciate help with inspecting these build logs. To avoid
duplicating work, I added a bug column to the log index and intend to
update it when given a notice. Given the number of build failures, I
believe that a mass bug filing would be counterproductive and ask that
bugs reports are only filed when accompanied with a patch or a detailed
analysis.

Please follow up to debian-cr...@lists.debian.org or stop by at
#debian-bootstrap on irc.oftc.net if you have any questions regarding
this effort.

Helmut

Re: Downscaling responsibilities

[Russ Allbery]

Enrico Zini  writes:

> it has been clear to me for a while that I am unable to stay on top of
> my Debian responsibilities. I feel like my usual pattern of things in
> debian has gone like this:
>  
>  1. I see a problem, I have an idea how to solve it, I make a prototype
> for it, I deploy it, look after it until I see that it actually
> solves the problem, I'm happy.
>  2. I get stuck looking after it forever.
>  3. Goto 1.

I hear this so much, and I've been there in various ways in the past.

> I consider this unsustainable, because I feel like everything I do is
> just adding to the pile of things that will haunt me forever.  As a
> consequence, for some years I have been actively avoiding starting new
> fun things, for fear of getting stuck with even more things that I am
> responsible for.

Yes.  This also sounds so very familiar.  Also, the maintenance work on
things that you believe should continue but that you are not currently
passionate about is enervating.  Even without the fear of being stuck with
more maintenance, I find that it can start draining away my energy for
starting something that needs a big surge of energy to get over the
initial barrier.  By the time I'm done with "chores," I can no longer feel
like doing all the various things that I was previously excited about.

(Not, btw, a Debian-specific problem.  I've run into this at various jobs
as well.)

I got pushed into doing a somewhat similar reset over the past year
because of a ton of non-Debian things I needed to focus on, and speaking
from the other side of having done so, it was very freeing.  It turns out
that the important things find new maintainers, you can finally shed the
low-level background guilt for the unimportant things, and it's so much
easier to tell the difference and to let go of unimportant but pet
projects with the additional perspective.

I was somewhat afraid it would begin a slide away from caring about
Debian, but it's been invigorating instead.  It provides a great
opportunity to get some space and think hard about what you most enjoy
working on, and the freedom to refocus on those things.

-- 
Russ Allbery (r...@debian.org)   

Re: dbconfig-common: near future change in dependency stack

[The Wanderer]

On 2016-01-30 at 08:49, Clint Byrum wrote:

> Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800:
> 
>> On 2016-01-30 at 04:51, Paul Gevers wrote:

>>> Actually, I don't think that is in scope of dbconfig-common. I
>>> would rather expect that MariaDB would provide that
>>> functionality. It is required for more packages and situations
>>> than just those supported by dbconfig-common.
>> 
>> Are there even cases where this is necessary?
>> 
>> Within the last year, I encountered an unacceptable - but
>> intentional - change in the MySQL client interface, so I removed
>> the MySQL packages and installed the MariaDB ones.
> 
> Which client interface would that be? libmysqlclient18 is still
> provided by mysql, even if you install MariaDB.

The one invoked with the command 'mysql'.

The underlying library is still the same (though as far as I can see,
the dependency chain from mariadb-client-core-10.0 to libmysqlclient18
only exists because libdbd-mysql-perl depends on the latter, so I'm not
convinced that ), but the client itself behaves differently.

The specific UI change which drove me away from "pure" MySQL was the
change in line-editing library, away from readline, so that my habitual
"jump around the line while editing the query" practices would no longer
function - and, as far as I recall, there was no suitable replacement. I
dug around for a while looking for a way to turn the readline behaviors
back on, started digging into the process of building my own packages
which revert to the old behavior, then discovered that MariaDB had not
followed that change and decided to just migrate instead.

>> My existing database was picked up and used without issues; the 
>> transition was, on that level, pretty much seamless as far as I
>> recall. I might have needed to re-apply some configuration tweaks
>> in different config files, but nothing more than that.
> 
> This is a one-way trip as of MariaDB 10. MariaDB 5.5 was compatible
> with MySQL 5.5 and allowed using the same on-disk files. But MySQL
> may not know how to read all of the files produced by MariaDB 10+. So
> I would not count on this working again in the future. They're truly
> forks, and you will need to backup/restore to make this work.

This is valuable to know for future reference, though I'm not sure I'm
ever likely to need or want to migrate in that direction between the
two; I was only still on MySQL rather than MariaDB out of inertia.

Since the topic at hand was specifically migrating from MySQL to
MariaDB, however, rather than bidirectional migration between the two,
my question stands: are there cases where migration from MySQL to
MariaDB needs to be done explicitly per-database?

>> This seems to imply that either migration is not required, or
>> MariaDB already performs the needed migration transparently. (Or
>> else that I'm forgetting some part of the transition process, which
>> is not impossible.)
>> 
>> I can imagine that there could be cases where migration would be 
>> required, but I'm not aware of any, and it didn't even occur to me
>> to expect that I might need to do any in my own case. I expected
>> that the two would be seamlessly compatible on the database level,
>> and that expectation seems to have been borne out.
> 
> Yeah, that would be nice, but the reality is, code is only flowing 
> _away_ from MySQL at this point. MariaDB's changes don't go back
> into MySQL. So the forks will just get further and further apart.

That's more or less what I'd expect. It still seems possible that the
"downstream" fork would retain input compatibility with the "upstream"
parent, but certainly that's not guaranteed.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: The state of cross building

[Bastien ROUCARIES]

On Sat, Jan 30, 2016 at 8:08 PM, Helmut Grohne  wrote:
> Hi,
>
> Let me give a status update on how well cross building works in
> unstable.
>
> Toolchain
> -
>
> We have cross compilers and crossbuild-essential-* packages in unstable
> for quite a while now. (Thanks to Matthias Klose.) These tend to work
> well. Recently, sbuild saw significant improvements wrt. cross building
> such that now one can simply "sbuild --build=arch1 --host=arch2 ..." and
> have a reasonable expectation that it works. (Thanks to Johannes
> Schauer.) Also pkg-config now ships the symlinks to a working cross
> wrapper. (Thanks to Tollef Fog Heen.) Many more things have happened and
> the gist is that much of the toolchain just works now! :)
>
> Cross building the Debian archive
> -
>
> Debian unstable has about 22000 source packages. Out of those, about 5000
> source packages can satisfy their Build-Depends in a cross build
> setting. For failing packages, detailed diagnostics can be found at
> http://bootstrap.debian.net/cross_all.html. (Thanks to Johannes Schauer.)
>
> Out of those 5000 source packages, I selected 3000 popular (as in
> popcon) source packages and built them using debomatic (build arch =
> amd64, host arch = ppc64el). (Thanks to Luca Falavigna.) About 1000
> builds were successful (which doesn't imply that the resulting packages
> actually work.) We can conclude that about 4% of Debian can be cross
> built today.
>
> You can find the build logs at:
> http://subdivi.de/~helmut/debomatic-logs/
>
> Processing the logs
> ---
>
> I've hacked up a script that guesses failure reasons by scanning the
> logs with some regular expressions. Common issues are:
>
>  * (>800) Using the build architecture compiler or linker.
>  * (>150) Bug #812136 in dh_auto_build for cmake
>  * (>130) configure fails due to missing values in config.site
>
> Bug reports
> ---
>
> I would appreciate help with inspecting these build logs. To avoid
> duplicating work, I added a bug column to the log index and intend to
> update it when given a notice. Given the number of build failures, I
> believe that a mass bug filing would be counterproductive and ask that
> bugs reports are only filed when accompanied with a patch or a detailed
> analysis.
>
> Please follow up to debian-cr...@lists.debian.org or stop by at
> #debian-bootstrap on irc.oftc.net if you have any questions regarding
> this effort.
>
> Helmut
>
Hi,

Could you document on wiki how can we begin as a package manager. For
instance I could not achieve to parse
http://bootstrap.debian.net/cross_all/imagemagick.html

Bastien

bugs in bootstrap.debian.net (was: Re: The state of cross building)

[Johannes Schauer]

Hi,

Quoting Bastien ROUCARIES (2016-01-31 00:49:14)
> Could you document on wiki how can we begin as a package manager. For
> instance I could not achieve to parse
> http://bootstrap.debian.net/cross_all/imagemagick.html

I apologize. Since I wrote the software it is hard for me to put myself into
the shoes of someone who is not familiar with the matter. I would very much
welcome if any questions about the text or tables or tips of how to improve the
presentation could be directed to me so that I can fix the website.

Thank you!

cheers, josch


signature.asc
Description: signature

Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

[Andreas Tille]

Hi,

over time I have seen several changes in the values we should put in to
Vcs-* fields.  The latest one is s/http:/https:/.  While using config
model editor helps a lot to follow those changes we will probably see
more and more packages inside the archive that never changed but start
accumulating more and more lintian issues about wrong Vcs fields.

I wonder whether we are doing the right thing by specifying full URLs in
debian/control files.  I know that the assumption that packages are
maintained on Alioth is not fully true but if it would we could use

   Vcs-Type: {Git|Svn|...}
   Vcs-Path: /

The values Vcs-{Git|Svn|...} and Vcs-Browser could be perfectly
calculated from the above values and the calculation algorithm could be
adapted to any change that might be decided upon.  That way a control
file would stay valid (as long as the package does not move around and
thus touched anyway).

To solve the issue that this would not work for packages maintained
outside Debian infrastructure we could add

   Vcs-Debian: {yes|no}

or alternatively

   Vcs-Host: debian.org

or something like this.  If these are set Vcs-Type + Vcs-Path become
valid.

What do you think?

Kind regards

  Andreas.


-- 
http://fam-tille.de

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

[Geert Stappers]

On Sun, Jan 31, 2016 at 08:23:11AM +0100, Andreas Tille wrote:
> Hi,
> 
> over time I have seen several changes in the values we should put in to
> Vcs-* fields.  The latest one is s/http:/https:/.  While using config
> model editor helps a lot to follow those changes we will probably see
> more and more packages inside the archive that never changed but start
> accumulating more and more lintian issues about wrong Vcs fields.
> 
> I wonder whether we are doing the right thing by specifying full URLs in
> debian/control files.  I know that the assumption that packages are
> maintained on Alioth is not fully true but if it would we could use
> 
>Vcs-Type: {Git|Svn|...}
>Vcs-Path: /
> 
> The values Vcs-{Git|Svn|...} and Vcs-Browser could be perfectly
> calculated from the above values and the calculation algorithm could be
> adapted to any change that might be decided upon.  That way a control
> file would stay valid (as long as the package does not move around and
> thus touched anyway).
> 
> To solve the issue that this would not work for packages maintained
> outside Debian infrastructure we could add
> 
>Vcs-Debian: {yes|no}
> 
> or alternatively
> 
>Vcs-Host: debian.org
> 
> or something like this.  If these are set Vcs-Type + Vcs-Path become
> valid.
> 
> What do you think?

Yes, it makes sense
to have a both Vcs-{Git|Svn|...} and a separate Vcs-Browser field.

Keep the possibility to copy-and-paste an VCS-URL for "manual checkout"

Keep a working Vcs-Brower URL. Because:
 * site admin is allowed to configure prefered "HTTP VCS Viewer"
 * user/humans/developers have a URL that can be used without extra adding / 
fiddling.

So no need to put extra code in `debcheckout` that does magic/voodoo
with headers like 'Vcs-Debian' and 'Vcs-Host'.


Groeten
Geert Stappers
-- 
The packaging system is not for distribution, but for collaboration.
(Quoting Martin Michylmaier, FOSDEM 2016-01-30, quoting Ian Murdock, 2004)


signature.asc
Description: Digital signature