Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Paul Wise]

On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:

> I'm Stewart and I work for Percona. One of the things I'm currently
> working on is ensuring all our free and open source software projects
> are packaged for all the major linux distributions - including my
> beloved Debian.

Since you are part of upstream, please review our upstream guide and
the links in the external advice section:

http://wiki.debian.org/UpstreamGuide

> We're wanting to have Percona XtraBackup be part of Debian.

Excellent.

> There is an open bug for Percona XtraBackup packaging:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824

Since you intend to package it, you should retitle this bug to intent
to package and set yourself as the owner of it:

http://www.debian.org/devel/wnpp/#l3
http://www.debian.org/Bugs/server-control#retitle
http://www.debian.org/Bugs/server-control#owner

> We are going to make "upload release to Debian" be part of our release
> process We want to be an active and involved upstream.

Great.

> I've put up source tarball and packaging for unstable up at:
> http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/

I'm unable to unpack the source package:

$ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
dpkg-source: warning: extracting unsigned source package
(percona-xtrabackup_2.1.3-610-1.dsc)
dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
has size 39459 instead of expected 141074103

You may want to run some commands from the source tree after a build:

http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

Also, I encourage you to sign your Debian packages and also your
upstream tarballs using OpenPGP keys. Here are some best practices for
OpenPGP:

https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

> Why is the tarball so big and why did it require an internet connection?
> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
> of InnoDB)

An alternative to including the MySQL InnoDB code might be to
build-depend on mysql-source-5.5, unpack and patch it during the build
process and add Built-Using: mysql-5.5 (= $version) to the resulting
binary package.

> 1) We have a transitional package called 'xtrabackup' that was (prior to
>2.0) the package name was in our own APT repositories. Does it make
>sense to keep this in the Debian packaging?

Seems reasonable to include it if you really want to. There seem to be
more folks using percona-xtrabackup than xtrabackup though:

$ GET http://popcon.debian.org/unknown/by_inst | grep -i xtrab
1590  percona-xtrabackup   150368232 0
(Not in sid)
2170  xtrabackup98 529 064
(Not in sid)
23575 percona-xtrabackup-test3 0 2 1 0
(Not in sid)
31597 percona-xtrabackup-dbg 2 0 2 0 0
(Not in sid)
74903 szn-mysql-xtrabackup   1 0 1 0 0
(Not in sid)

> 2) We have trademarks. We've tried to come up with a trademark policy
>that makes everybody happy (well, as happy as you can be when you're
>dealing with trademark law).
>It's at:
>http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
>We believe this should satisfy any requirements of Linux
>distributions, but if there's any concerns, don't hesitate to ask.

I'd suggest mailing debian-legal about this question but based on the
trademark policy it appears that Debian would have to rename percona
if we wanted to add a security patch in stable?

You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark':

http://faif.us/cast/2013/may/07/0x3C/

> 3) Supported architectures. We see x86-64, x86 and very, very rarely,
>SPARC. I'd say that both people running XtraBackup on a non-x86
>architecture are happy, but I'm pretty sure there's not even that
>many. While XtraBackup may compile (or even run) on other
>architectures, it currently makes approximately zero business sense
>for us to spend any time on it - although we're happy to take
>patches.
>
>Given this, how much "works and passes tests on all archs" is
>required to have packages accepted?

There is no requirement to work on all arches but regressions in
architecture support are release-critical. You need to have a good
test suite so that binary packages are not produced on architectures
where the software doesn't work. I expect you will want to make it
work on ARM since arm64 is coming soon and may become a popular
architecture for servers.

http://wiki.debian.org/Arm64Port

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6H82YgdU83HKsm=S=m=njnkqy3_egp3eu_fpbbjdaz...@mail.gmail.com

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Vincent Bernat]

 ❦  2 juillet 2013 09:20 CEST, Paul Wise  :

>> Why is the tarball so big and why did it require an internet connection?
>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>> of InnoDB)
>
> An alternative to including the MySQL InnoDB code might be to
> build-depend on mysql-source-5.5, unpack and patch it during the build
> process and add Built-Using: mysql-5.5 (= $version) to the resulting
> binary package.

The problem is that it should Build-Depends on Percona MySQL which is
not yet available in Debian. I think the first step would be to provide
Percona MySQL packages. Currently, it seems that there is no easy way to
provide packages as alternative to MySQL but maybe work has already
started with MariaDB.
-- 
/* Fuck me gently with a chainsaw... */
2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c


pgp7SkyyGHPCE.pgp
Description: PGP signature

Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

Hi,

Florian Weimer has correctly pointed out that Oracle has decided to change
the BDB 6.0 license to AGPLv3 (
https://oss.oracle.com/pipermail/bdb/2013-June/56.html). This hasn't
been reflected in release tarball (probably by mistake), but since the
AGPLv3 is not very friendly to downstream projects, we (as the Debian
project) need to take a decision.

My opinion is that this Oracle move just sent the Berkeley DB to oblivion,
and Berkeley DB will be less and less used (or replaced by something else).

What we can do right now (more can apply):
[ ] Keep db5.3 for jessie
[ ] Keep db5.3 for jessie+
[ ] Keep db5.3 forever
[ ] Suck it and relicense the downstream software as appropriate
[ ] Block db6.0 and higher from entering Debian
[ ] Remove Berkeley DB support from jessie+
[ ] Remove Berkeley DB support from jessie++
[ ] Replace Berkeley DB with free alternative [*]
[ ] Somebody writes a BDB-compatible wrapper around the free alternative(s)

As far as I am aware the most prominent users[1][2][3] of Berkeley DB are
moving away from the library anyway, so this might not be a big deal after
all.

1. openldap has mdb
2. cyrus-imapd has skiplist
3. subversion has moved to fsfs long time ago

I am attaching list of affected software generated by:

dak rm -Rn -s unstable db-defaults db5.1 db5.3 > db-depends
< db-depends grep : | grep -Ev "^($| |#|Dependency problem found.|Will
remove the following packages from unstable:|Maintainer:)" | sed -e
"s/\\[.*\\]//" | cut -f 1 -d: | sort -u > package.list
# chroot to unstable system
 affected.list

* - f.e. kyotocabinet is GPL with FOSS and Linking exception (
http://ftp-master.metadata.debian.org/changelogs/main/k/kyotocabinet/unstable_copyright
)

kyotocabinet is a sister of tokyocabinet:
http://tokyocabinet.sourceforge.net/benchmark.pdf
or
http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/

Ondrej
--
Ondřej Surý 


affected.list
Description: Binary data

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Clint Byrum]

Excerpts from Paul Wise's message of 2013-07-02 00:20:36 -0700:
> On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:
> 
> > I'm Stewart and I work for Percona. One of the things I'm currently
> > working on is ensuring all our free and open source software projects
> > are packaged for all the major linux distributions - including my
> > beloved Debian.
> 
> Since you are part of upstream, please review our upstream guide and
> the links in the external advice section:
> 
> http://wiki.debian.org/UpstreamGuide
> 
> > We're wanting to have Percona XtraBackup be part of Debian.
> 
> Excellent.
> 
> > There is an open bug for Percona XtraBackup packaging:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824
> 
> Since you intend to package it, you should retitle this bug to intent
> to package and set yourself as the owner of it:
> 
> http://www.debian.org/devel/wnpp/#l3
> http://www.debian.org/Bugs/server-control#retitle
> http://www.debian.org/Bugs/server-control#owner
> 
> > We are going to make "upload release to Debian" be part of our release
> > process We want to be an active and involved upstream.
> 
> Great.
> 
> > I've put up source tarball and packaging for unstable up at:
> > http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/
> 
> I'm unable to unpack the source package:
> 
> $ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
> dpkg-source: warning: extracting unsigned source package
> (percona-xtrabackup_2.1.3-610-1.dsc)
> dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
> has size 39459 instead of expected 141074103
> 
> You may want to run some commands from the source tree after a build:
> 
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
> 
> Also, I encourage you to sign your Debian packages and also your
> upstream tarballs using OpenPGP keys. Here are some best practices for
> OpenPGP:
> 
> https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
> 
> > Why is the tarball so big and why did it require an internet connection?
> > Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
> > of InnoDB)
> 
> An alternative to including the MySQL InnoDB code might be to
> build-depend on mysql-source-5.5, unpack and patch it during the build
> process and add Built-Using: mysql-5.5 (= $version) to the resulting
> binary package.
> 

I believe that one problem with this will be that the patched InnoDB code
that is used is from an older version, and porting the patch forward does
not add any value for xtrabackup, but would require significant resources.

Just an FYI, I have been working with Stewart on this and I feel this
is the way to go, even though it is not as clean as building against
mysql-source-5.5.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1372751471-sup-1...@fewbar.com

Bug#714731: ITP: vmkit -- Common substrate for Virtual Machine development

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru 

* Package name: vmkit
  Version : 0.32
* URL : http://vmkit.llvm.org/
* License : University of Illinois/NCSA
  Programming Lang: C++ & Java
  Description : Common substrate for Virtual Machine development

 The goal of VMKit is to create a body of code useful for creating and
 experimenting with virtual machines. The code will emphasize modularity,
 clarity, correctness, and portability in no particular order but all taking
 precedence over execution speed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130702091642.18038.69208.report...@deicaza.inria.fr

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Stewart Smith]

Paul Wise  writes:
> On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:
>
>> I'm Stewart and I work for Percona. One of the things I'm currently
>> working on is ensuring all our free and open source software projects
>> are packaged for all the major linux distributions - including my
>> beloved Debian.
>
> Since you are part of upstream, please review our upstream guide and
> the links in the external advice section:
>
> http://wiki.debian.org/UpstreamGuide

Thanks for the pointer. It appears that we're pretty good on most things
mentioned there and some things we've got plans to address.

>> There is an open bug for Percona XtraBackup packaging:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824
>
> Since you intend to package it, you should retitle this bug to intent
> to package and set yourself as the owner of it:
>
> http://www.debian.org/devel/wnpp/#l3
> http://www.debian.org/Bugs/server-control#retitle
> http://www.debian.org/Bugs/server-control#owner

Done.

>> I've put up source tarball and packaging for unstable up at:
>> http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/
>
> I'm unable to unpack the source package:
>
> $ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
> dpkg-source: warning: extracting unsigned source package
> (percona-xtrabackup_2.1.3-610-1.dsc)
> dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
> has size 39459 instead of expected 141074103

I'll investigate this first thing in the morning (it's getting late),
although it looks as though the tar.gz didn't fully download (yes, it's
really 135MB)

> You may want to run some commands from the source tree after a build:
>
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

I think there's some good ideas here that we can add to our CI
infrastructure. I don't think there's anything that would be considered
a blocker though.

> Also, I encourage you to sign your Debian packages and also your
> upstream tarballs using OpenPGP keys. Here are some best practices for
> OpenPGP:
>
> https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

Yep, we typically do this. We use a key for the company rather than our
individual ones for our current repositories. Is this an acceptable
approach for packages going into Debian? Or should we just have the few
individuals sign it if they're involved?

>> Why is the tarball so big and why did it require an internet connection?
>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>> of InnoDB)
>
> An alternative to including the MySQL InnoDB code might be to
> build-depend on mysql-source-5.5, unpack and patch it during the build
> process and add Built-Using: mysql-5.5 (= $version) to the resulting
> binary package.

We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
MySQL and Percona Server (which isn't yet packaged) and we'd also have
to patch it.

Our short/medium term plan is to do away with having multiple server
source trees and binaries. We instead plan to just make a modified MySQL
branch where we just include the needed (modified) source. In an ideal
world the needed code would be buildable as a library and we'd get the
needed patches upstream. It is not an ideal world however :(


>> 1) We have a transitional package called 'xtrabackup' that was (prior to
>>2.0) the package name was in our own APT repositories. Does it make
>>sense to keep this in the Debian packaging?
>
> Seems reasonable to include it if you really want to. There seem to be
> more folks using percona-xtrabackup than xtrabackup though:

I'm not really attached either way... It appears that it may not be
worth having it. I'll defer to the experts on this one.

>> 2) We have trademarks. We've tried to come up with a trademark policy
>>that makes everybody happy (well, as happy as you can be when you're
>>dealing with trademark law).
>>It's at:
>>http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
>>We believe this should satisfy any requirements of Linux
>>distributions, but if there's any concerns, don't hesitate to ask.
>
> I'd suggest mailing debian-legal about this question but based on the
> trademark policy it appears that Debian would have to rename percona
> if we wanted to add a security patch in stable?

I'll bring it up there. We would see that as simply a patch that's
needed for that version to be included in that Os and thus not an issue.

> You may want to listen to this FOSDEM talk entitled 'How to Share a 
> Trademark':
>
> http://faif.us/cast/2013/may/07/0x3C/

I'll have a look. We tried to think of linux distros and Debian when we
were forming the trademark policy. We'll see what Debian-legal says :)

>> 3) Supported architectures. We see x86-64, x86 and very, very rarely,
>>SPARC. I'd say that both people running XtraBackup on a non-x86
>>architecture are happy, but I'm pretty sure there's not even that

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Paul Wise]

On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote:

> I'll investigate this first thing in the morning (it's getting late),
> although it looks as though the tar.gz didn't fully download (yes, it's
> really 135MB)

Looks like your tarball is named incorrectly (tar.gz instead of
orig.tar.gz) and your website returns a HTTP 302 code (redirect) and
some HTML for the orig.tar.gz URL rather than a 404.

> I think there's some good ideas here that we can add to our CI
> infrastructure. I don't think there's anything that would be considered
> a blocker though.

Indeed.

> Yep, we typically do this. We use a key for the company rather than our
> individual ones for our current repositories. Is this an acceptable
> approach for packages going into Debian? Or should we just have the few
> individuals sign it if they're involved?

It is a reasonable approach for upstream tarballs. Uploads to Debian
need to be signed by one of the keys in the developer keyring or a
subkey of one of those keys.

> We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
> MySQL and Percona Server (which isn't yet packaged) and we'd also have
> to patch it.
>
> Our short/medium term plan is to do away with having multiple server
> source trees and binaries. We instead plan to just make a modified MySQL
> branch where we just include the needed (modified) source. In an ideal
> world the needed code would be buildable as a library and we'd get the
> needed patches upstream. It is not an ideal world however :(

I see, maybe you have chosen the way of least pain.

> I'm not really attached either way... It appears that it may not be
> worth having it. I'll defer to the experts on this one.

Maybe ask your userbase if they need it?

> I'll bring it up there. We would see that as simply a patch that's
> needed for that version to be included in that Os and thus not an issue.

The danger is if that approach to interpretation if the policy were to change.

> It's certainly something we may be interested at looking at... I guess
> we'll see what the buildds say :)
>
> We do have a test suite. It does (of course) depend on having server
> binaries around to run backup and restore with. Our CI infrastructure
> currently uses just binary tarballs of various server versions, but this
> probably isn't ideal for Debain so we'll have to come up with another
> solution. One thing to consider is that (like MySQL) running the test
> suite takes a non-trivial amount of time.

Please do enable the test suite for Debian builds and run them with
the binaries built during the build process.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6f0cn0zryqmdrlzhiqobh2cabzjdzqcww1xdd0e9zh...@mail.gmail.com

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Stewart Smith]

Vincent Bernat  writes:
>  ❦  2 juillet 2013 09:20 CEST, Paul Wise  :
>
>>> Why is the tarball so big and why did it require an internet connection?
>>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>>> of InnoDB)
>>
>> An alternative to including the MySQL InnoDB code might be to
>> build-depend on mysql-source-5.5, unpack and patch it during the build
>> process and add Built-Using: mysql-5.5 (= $version) to the resulting
>> binary package.
>
> The problem is that it should Build-Depends on Percona MySQL which is
> not yet available in Debian. I think the first step would be to provide
> Percona MySQL packages. Currently, it seems that there is no easy way to
> provide packages as alternative to MySQL but maybe work has already
> started with MariaDB.

It would need to build-depend on specific MySQL and Percona Server
versions (which end up being on-disk compatible with various MariaDB
versions).

We're working on getting Percona Server ready to be included too, but
we'd be going for the current Percona Server versions not the ones we
patch heavily to then build XtraBackup with.

But, the main problem is that we need to patch the InnoDB source to build
XtraBackup and the patch isn't trivial to port to the latest versions
(and there's usually no benefit in doing so).

It's better to think of XtraBackup patching and including the parts of
InnoDB it needs and for reasons that are largely historical it's
multiple binaries for multiple versions of InnoDB.

Our short/medium term goal is to stop doing this and actually just have
one set of InnoDB code from the most recent MySQL/Percona Server version
and one XtraBackup binary that works on all server versions.

In an ideal world there'd be some library we could link against and have
the patches be accepted upstream.. but we're not in an ideal world. This
would make it more like something like xfsprogs which does end up
including some of the same code as the kernel (although we patch InnoDB
while xfsprogs seems to be about at the point where that isn't
necessary).

So while we do understand how it'd be great to build against the source
in mysql-source-5.5, it's just not really feasible to do so and maintain
quality and maintainability. We're hoping that our short/medium term of
just including the patched InnoDB bits we need in our source tree to
mostly solve the problem.

I hope this helps clarify.

-- 
Stewart Smith


pgpocLz_8VZAP.pgp
Description: PGP signature

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

[Stewart Smith]

Paul Wise  writes:
> On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote:
>
>> I'll investigate this first thing in the morning (it's getting late),
>> although it looks as though the tar.gz didn't fully download (yes, it's
>> really 135MB)
>
> Looks like your tarball is named incorrectly (tar.gz instead of
> orig.tar.gz) and your website returns a HTTP 302 code (redirect) and
> some HTML for the orig.tar.gz URL rather than a 404.

I'll ensure our process includes putting the tarball up named
correctly. The tarball in that directory should be the right one when
named correctly though (unless I brain-farted and got it wrong :)

>> Yep, we typically do this. We use a key for the company rather than our
>> individual ones for our current repositories. Is this an acceptable
>> approach for packages going into Debian? Or should we just have the few
>> individuals sign it if they're involved?
>
> It is a reasonable approach for upstream tarballs. Uploads to Debian
> need to be signed by one of the keys in the developer keyring or a
> subkey of one of those keys.

My guess is the reasonable thing to do is ensure that a few of us have
keys in the keyring then so that there's some redundancy (after all, we
have to let people take vacation :)

>> We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
>> MySQL and Percona Server (which isn't yet packaged) and we'd also have
>> to patch it.
>>
>> Our short/medium term plan is to do away with having multiple server
>> source trees and binaries. We instead plan to just make a modified MySQL
>> branch where we just include the needed (modified) source. In an ideal
>> world the needed code would be buildable as a library and we'd get the
>> needed patches upstream. It is not an ideal world however :(
>
> I see, maybe you have chosen the way of least pain.

We try to :)

>> I'm not really attached either way... It appears that it may not be
>> worth having it. I'll defer to the experts on this one.
>
> Maybe ask your userbase if they need it?

I'll reach out through our support org. I suspect we'd be fine
without it.

>> I'll bring it up there. We would see that as simply a patch that's
>> needed for that version to be included in that Os and thus not an issue.
>
> The danger is if that approach to interpretation if the policy were to
> change.

Okay. I'll bring it up on debian-devel and see if we need changes (it
just means I probably get to talk trademark law more... which is
generally something I try to avoid :)

>> It's certainly something we may be interested at looking at... I guess
>> we'll see what the buildds say :)
>>
>> We do have a test suite. It does (of course) depend on having server
>> binaries around to run backup and restore with. Our CI infrastructure
>> currently uses just binary tarballs of various server versions, but this
>> probably isn't ideal for Debain so we'll have to come up with another
>> solution. One thing to consider is that (like MySQL) running the test
>> suite takes a non-trivial amount of time.
>
> Please do enable the test suite for Debian builds and run them with
> the binaries built during the build process.

The problem we'll have to solve is running against MySQL (and Percona
Server) versions... and I'm not sure the best way to wrangle that (we
probably have to fix a bug or two in the test suite to ensure it works
against an installed binary - we currently download binary tarballs and
run against them).


-- 
Stewart Smith


pgpftxrCZEIR9.pgp
Description: PGP signature

Re: boot ordering and resolvconf

[Thomas Hood]

Tollef Fog Heen wrote:
> I think changing /etc/resolv.conf automatically is broken at all.

What's the malfunction?

> We should have a generated /run/resolv.conf that's overridden by the
> settings in /etc/resolv.conf (if it exists).  This allows you to have a
> consistent set of domains searched for matching hosts even when roaming
> to other networks.  It also allows me to express the preference «I want
> to use localhost as a nameserver, always» without resorting to chattr to
> prevent dhclient, NetworkManager and other tools from auto-updating the
> resolv.conf file.

Those features are available in resolvconf.

Let's consider your idea. I like the aspect that /etc/resolv.conf
remains a static file and doesn't have to be symlinked to a generated
resolv.conf.

However, your idea requires that the glibc resolver be enhanced.
And once it is enhanced the logic is cast in binary stone:
/etc/resolv.conf always overrides /run/resolv.conf, period. With
resolvconf the logic is under the control of the administrator.
If the admin puts a static file at /etc/resolv.conf then resolv.conf
is static.  If the admin puts a symlink at /etc/resolv.conf then the
target of that symlink is used.

With the resolvconf approach the resolver configuration is readable
in one file which has the familiar semantics, resolv.conf(5). If there
are two files then questions arise about how the one overrides the
other. If /run/resolv.conf contains nameserver options and so does
/etc/resolv.conf, then are both addresses tried, or just the latter, or
what? Also, you will need a third file, also static, to provide defaults
which get overridden by /run/resolv.conf. This will need to be
documented.

If it's the case that the mere existence of a file at /etc/resolv.conf
causes /run/resolv.conf to be completely ignored then there is not
so great a difference between your idea and resolvconf.  With
resolvconf, the absence of a symlink at /etc/resolv.conf is what
causes the dynamic resolv.conf to be ignored.

What is missing from your idea so far is functionality to handle
multiple sources of nameserver information. What if the machine
runs both dhclient and a VPN client, or both ifup and pppd?  In the
past each of these sorts of programs updated /etc/resolv.conf
and (sometimes) restored the file to the preceding state on exit
which left the file in an incorrect state if programs were stopped
in other than LIFO order.

Some packages make use of resolvconf hook scripts, a mechanism
whereby they get notified when the resolver configuration changes.
You could think about whether or not you want to implement that
too, and how.

Cheers,
- -
Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d2c629.30...@gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Paul Tagliamonte]

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
> Florian Weimer has correctly pointed out that Oracle has decided to change the
> BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
> 56.html). This hasn't been reflected in release tarball (probably by
> mistake), but since the AGPLv3 is not very friendly to downstream projects, we
> (as the Debian project) need to take a decision.

What? Wait, What? What?[1]

The AGPL is a DFSG free FSF approved and OSI approved free software
license? We made a decision, it's *free software* and fit for main.

> My opinion is that this Oracle move just sent the Berkeley DB to oblivion, and
> Berkeley DB will be less and less used (or replaced by something else).

Sure. Software comes and goes. Why not let it happen, who cares, it's
still free software.

> What we can do right now (more can apply):
> [ ] Keep db5.3 for jessie
> [ ] Keep db5.3 for jessie+
> [ ] Keep db5.3 forever
> [ ] Suck it and relicense the downstream software as appropriate
> [ ] Block db6.0 and higher from entering Debian
> [ ] Remove Berkeley DB support from jessie+
> [ ] Remove Berkeley DB support from jessie++
> [ ] Replace Berkeley DB with free alternative [*]
> [ ] Somebody writes a BDB-compatible wrapper around the free alternative(s)
  [ ] Do nothing because it's free software

> dak rm -Rn -s unstable db-defaults db5.1 db5.3 > db-depends

Again, why do you plan on removing free software from main due to a
change in license?

Cheers,
  Paul


[1]: 
http://1.bp.blogspot.com/-GfEnd4xeEJs/UOxBvCCdgGI/BSU/PgL41SlEQ98/s1600/huh-what.gif

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Paul Tagliamonte]

On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
> Again, why do you plan on removing free software from main due to a
> change in license?

As algernon points out, it makes slightly more sense when you remember
that the AGPLv3 is not compatable with the GPLv2

I'm still against removing it from the archive.

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 3:15 PM, Paul Tagliamonte  wrote:

> On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
> > Florian Weimer has correctly pointed out that Oracle has decided to
> change the
> > BDB 6.0 license to AGPLv3 (
> https://oss.oracle.com/pipermail/bdb/2013-June/
> > 56.html). This hasn't been reflected in release tarball (probably by
> > mistake), but since the AGPLv3 is not very friendly to downstream
> projects, we
> > (as the Debian project) need to take a decision.
>
> What? Wait, What? What?[1]
>
> The AGPL is a DFSG free FSF approved and OSI approved free software
> license? We made a decision, it's *free software* and fit for main.


apt-get is licensed GPLv2 and thus incompatible with AGPLv3.
cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
subversion has Apache 2.0 license and thus incompatible with AGPLv3.

...do I have to even continue...?


> > My opinion is that this Oracle move just sent the Berkeley DB to
> oblivion, and
> > Berkeley DB will be less and less used (or replaced by something else).
>
> Sure. Software comes and goes. Why not let it happen, who cares, it's
> still free software.


I guess the maintainers of r-depends _care_!


>  > What we can do right now (more can apply):
> > [ ] Keep db5.3 for jessie
> > [ ] Keep db5.3 for jessie+
> > [ ] Keep db5.3 forever
> > [ ] Suck it and relicense the downstream software as appropriate
> > [ ] Block db6.0 and higher from entering Debian
> > [ ] Remove Berkeley DB support from jessie+
> > [ ] Remove Berkeley DB support from jessie++
> > [ ] Replace Berkeley DB with free alternative [*]
> > [ ] Somebody writes a BDB-compatible wrapper around the free
> alternative(s)
>   [ ] Do nothing because it's free software
>
> > dak rm -Rn -s unstable db-defaults db5.1 db5.3 > db-depends
>
> Again, why do you plan on removing free software from main due to a
> change in license?


I am not removing anything, have you read my email? This command was merely
used to generate list of r-depends of Berkeley DB.

But we cannot maintain db5.3 (or db5.1) forever if upstream declares it
dead.

O.
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Ben Hutchings]

On Tue, 2013-07-02 at 09:35 -0400, Paul Tagliamonte wrote:
> On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
> > Again, why do you plan on removing free software from main due to a
> > change in license?
> 
> As algernon points out, it makes slightly more sense when you remember
> that the AGPLv3 is not compatable with the GPLv2
> 
> I'm still against removing it from the archive.

But the new version should not build the default libdb-dev, as that is
likely to result in unintended GPLv2/v3 combinations that cannot be
distributed.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Re: Berkeley DB 6.0 license change to AGPLv3

[Tollef Fog Heen]

]] Paul Tagliamonte 

> On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
> > Florian Weimer has correctly pointed out that Oracle has decided to change 
> > the
> > BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
> > 56.html). This hasn't been reflected in release tarball (probably by
> > mistake), but since the AGPLv3 is not very friendly to downstream projects, 
> > we
> > (as the Debian project) need to take a decision.
> 
> What? Wait, What? What?[1]
> 
> The AGPL is a DFSG free FSF approved and OSI approved free software
> license? We made a decision, it's *free software* and fit for main.

An AGPL licenced libdb isn't particularly useful for us, though.  It'd
mean distributing a fair amount of software including exim, postfix,
squid, webalizer, dovecot and many other servers under the AGPL, which
would mean patching them so you could download the source code through
them.

AGPL is a sometimes usable licence for webapps.  It's completely
unusable for a library like libdb.

I think we should just keep libdb5.3 until a suitable replacement shows
up.

> Again, why do you plan on removing free software from main due to a
> change in license?

I don't think he's suggested removing it?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4fh9j2w@xoog.err.no

Re: Berkeley DB 6.0 license change to AGPLv3

[Ben Hutchings]

On Tue, 2013-07-02 at 09:44 +0200, Ondřej Surý wrote:
> Hi,
> 
> Florian Weimer has correctly pointed out that Oracle has decided to
> change the BDB 6.0 license to AGPLv3
> (https://oss.oracle.com/pipermail/bdb/2013-June/56.html). This
> hasn't been reflected in release tarball (probably by mistake), but
> since the AGPLv3 is not very friendly to downstream projects, we (as
> the Debian project) need to take a decision.
>
> My opinion is that this Oracle move just sent the Berkeley DB to
> oblivion, and Berkeley DB will be less and less used (or replaced by
> something else).

If the relicensing is real and not another misconfiguration of the
build/release system (like with MySQL docs), this sounds like a
shakedown for proprietary users of Berkeley DB.  GPLv2-licensed users
are collateral damage.

> What we can do right now (more can apply):
[...]
> [ ] Keep db5.3 forever

Well, indefinitely.  But I somewhat expect some BSD developers to try
maintaining a fork of it, as they're very unlikely to be happy with
AGPLv3.

> [ ] Suck it and relicense the downstream software as appropriate
[...]

GPLv3 is compatible with almost all common licences except GPLv2 (though
that might not be true with the additional conditions of AGPLv3).  If
anyone has made a decision to use GPLv2-only then I wouldn't expect them
to relicense for this.  Therefore a BSD-licensed libdb is still needed.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 3:39 PM, Tollef Fog Heen  wrote:

> I think we should just keep libdb5.3 until a suitable replacement shows
> up.


The OpenLDAP lightningdb might be a viable option: http://symas.com/mdb/

O.
-- 
Ondřej Surý 

Re: boot ordering and resolvconf

[Tollef Fog Heen]

]] Thomas Hood 

> Tollef Fog Heen wrote:
> > I think changing /etc/resolv.conf automatically is broken at all.
> 
> What's the malfunction?

Automatic processes overwrite explicit admin setups.

> > We should have a generated /run/resolv.conf that's overridden by the
> > settings in /etc/resolv.conf (if it exists).  This allows you to have a
> > consistent set of domains searched for matching hosts even when roaming
> > to other networks.  It also allows me to express the preference «I want
> > to use localhost as a nameserver, always» without resorting to chattr to
> > prevent dhclient, NetworkManager and other tools from auto-updating the
> > resolv.conf file.
> 
> Those features are available in resolvconf.
>
> Let's consider your idea. I like the aspect that /etc/resolv.conf
> remains a static file and doesn't have to be symlinked to a generated
> resolv.conf.
> 
> However, your idea requires that the glibc resolver be enhanced.
> And once it is enhanced the logic is cast in binary stone:
> /etc/resolv.conf always overrides /run/resolv.conf, period. With
> resolvconf the logic is under the control of the administrator.
> If the admin puts a static file at /etc/resolv.conf then resolv.conf
> is static.  If the admin puts a symlink at /etc/resolv.conf then the
> target of that symlink is used.

It seems resolvconf wants to get its name servers from
/etc/network/interfaces?  If so, that won't work particularly well with
NetworkManager, unless I'm mistaken.  Also, I don't think updating files
in /etc at runtime is a sensible idea, it should be possible to run with
/ read-only if you want to.

> With the resolvconf approach the resolver configuration is readable
> in one file which has the familiar semantics, resolv.conf(5).

I find resolvconf's behaviour confusing enough that I generally purge it
from all my machines.  It is, to me, an abstraction layer that seems to
randomly overwrite my settings.  Having it write to /run and having apps
fall back to settings there if there's no setting in /etc/resolv.conf
would ease that confusion, I think.

> If there are two files then questions arise about how the one
> overrides the other. If /run/resolv.conf contains nameserver options
> and so does /etc/resolv.conf, then are both addresses tried, or just
> the latter, or what?

I specified that: settings are overridden, the file in /run is not
masked.  Whether you want to append the nameserver list or override the
one from /run should probably be specified.  I'd say override, since
appending can easily lead to security breaches.

> Also, you will need a third file, also static, to provide defaults
> which get overridden by /run/resolv.conf. This will need to be
> documented.

You don't need a third file the defaults are «an empty file», just like
today.

[...]

> What is missing from your idea so far is functionality to handle
> multiple sources of nameserver information. What if the machine
> runs both dhclient and a VPN client, or both ifup and pppd?  In the
> past each of these sorts of programs updated /etc/resolv.conf
> and (sometimes) restored the file to the preceding state on exit
> which left the file in an incorrect state if programs were stopped
> in other than LIFO order.

In that case, feel free to provide a framework for packages to
coordinate updates to /run/resolv.conf and have stacking and
whatnot. (They could write to /run/resolv.conf.d/$num_$basename and
resolvconf or a similar tool could build a /run/resolv.conf from that.)

> Some packages make use of resolvconf hook scripts, a mechanism
> whereby they get notified when the resolver configuration changes.
> You could think about whether or not you want to implement that
> too, and how.

I think any packages needing such hooks should just be fixed, since
they're buggy.  Adding a lot of infrastructure to work around bugginess
is, IMO, not a good idea.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwq59i3f@xoog.err.no

Re: Berkeley DB 6.0 license change to AGPLv3

[Dan Shearer]

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:

> Florian Weimer has correctly pointed out that Oracle has decided to change
> the BDB 6.0 license to AGPLv3 (
> https://oss.oracle.com/pipermail/bdb/2013-June/56.html).
   :
> we (as the Debian project) need to take a decision.
   :

(because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
and there is code under these licenses which depends on BDB. There is
also code which depends on BDB that is compatible with the AGPLv3
legally, but whose deployment would then be restricted in ways the users
would not be expecting.)

> As far as I am aware the most prominent users of Berkeley DB are
> moving away from the library anyway ...

There are actually very few true alternatives to BDB. While there are
many KVP (key value pair) stores [1] not many are transactional, allow
multi-version concurrency control [2] and support multi-threaded and
multi-process access. BDB is all of the above, and in addition the BDB
API has become very widely used over nearly 30 years. And of course the
BSD license allowed BDB to be embedded in a huge amount of software - 
like the BSD networking stack, it turns up just about everywhere.

So there are three things to think about in a replacement:

1. Is the licensing as suitable as the BSD license has been, and is 
the primary maintainer likely to do what Oracle just did to BDB?

2. Are the features at least as good as BDB, and is the API close enough
to make replacement reasonably easy?

3. BDB is very old code. When replacing it can we also adopt modern
approaches more suited to modern hardware and use cases?

I've looked at all of the KVP options I am aware of and consulted people
who specialise in the space and can only see one that fits each of these
well. MDB from the OpenLDAP project, http://symas.com/mdb/ .

As to point 1, the rights holders of MDB need to make a public
statement, but I have asked them in private and in any case the OpenLDAP
history speaks for itself.

As to point 2, MDB provides a superset of the KVP-specific features of
BDB, and the API is similar to BDB but somewhat simpler.

As to point 3, MDB is a from-scratch implementation in the modern world.
MDB object code is a tiny fraction of BDB, and by adopting a
memory-mapped architecture and dispensing with caching and locking it
relies on modern operating system features rather than trying to
implement them internally. This means greatly increased performance and
very much smaller windows for corruption to occur. MDB has very clean
support for concurrency compared to BDB, which makes it much more
suitable for modern applications. 

There is an technical discussion of MDB here:
http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance
data has been published, one simple test that has a minimum of
imaginable bias is to compare the SQLite3 API that comes with Oracle BDB
with the SQLite3 ported to MDB. The other obvious speed test (that has
had reproducible data published) is with OpenLDAP, which has pluggable
back ends including both BDB and MDB.

I'll be delighted if someone can suggest something that is even more
suitable than MDB, but so far I haven't seen it.

Looking at the Debian archive, packages with BDB dependencies are as
follows (MDB integration has been marked where it exists, currently
about 10% of the packages.):

389-ds-base
animals
apr-util
apt
bind9
bitcoin
bmf
bogofilter
boxbackup
cairo-dock-plug-ins
canl-c++
cfengine2
cfengine3LMDB support published
chise-base
c-icap
citadel
claws-mail
clisp
cyrus-imapd-2.4
cyrus-sasl2 LMDB support published
db-defaults
dnshistory
dovecot
drac
dsniff
evolution-data-server
evolution-exchange
exim4
fsvs
ggcov
glusterfs
gridengine
guile-db
heimdal LMDB supported
hotkeys
hpsockd
inn2
iproute
iproute2
isync
jabberd2
libetpan
libnss-db
libpam-abl
libpam-ccreds
libpinyin
libqxt
librcc
lucene2
mailavenger
memcachedb  LMDB support published
mit-scheme
mmorph
moc
netatalk
nmh
nordugrid-arc
nss-updatedb
nvi
onak
open-cobol
opendkimLMDB supported
openldapLMDB supported
pam
pavuk
perdition
perl
php5
poedit
postfix LMDB support published
prayer
python2.7   LMDB supported
python3.2   LMDB supported
python3.3   LMDB supported
python-bsddb3
radiusd-livingston
redland
reprepro
resiprocate
rhmessaging
rpm
ruby-bdbLMDB supported
sendmail
skksearch
skktools
sks
spamprobe
squid
squid3
squidguard
subversion
syrep
tcpstat
torrus
trustedqsl
vacation
webalizer
webdruid
wvstreams
xastir
xemacs21
zeroc-ice


HtH,

--
Dan Shearer
d...@shearer.org



[1] KVP: Key value pair 

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

Thanks Dan for this comprehensive email.

I'll take ITP bug for libmdb (#694757) under pkg-db umbrella, as it will
affect Berkeley DB, so it makes sense to have it there.

People are most welcome to join the team, as I am the only active person in
the team.

O.


On Tue, Jul 2, 2013 at 4:38 PM, Dan Shearer  wrote:

> On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:
>
> > Florian Weimer has correctly pointed out that Oracle has decided to
> change
> > the BDB 6.0 license to AGPLv3 (
> > https://oss.oracle.com/pipermail/bdb/2013-June/56.html).
>:
> > we (as the Debian project) need to take a decision.
>:
>
> (because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
> and there is code under these licenses which depends on BDB. There is
> also code which depends on BDB that is compatible with the AGPLv3
> legally, but whose deployment would then be restricted in ways the users
> would not be expecting.)
>
> > As far as I am aware the most prominent users of Berkeley DB are
> > moving away from the library anyway ...
>
> There are actually very few true alternatives to BDB. While there are
> many KVP (key value pair) stores [1] not many are transactional, allow
> multi-version concurrency control [2] and support multi-threaded and
> multi-process access. BDB is all of the above, and in addition the BDB
> API has become very widely used over nearly 30 years. And of course the
> BSD license allowed BDB to be embedded in a huge amount of software -
> like the BSD networking stack, it turns up just about everywhere.
>
> So there are three things to think about in a replacement:
>
> 1. Is the licensing as suitable as the BSD license has been, and is
> the primary maintainer likely to do what Oracle just did to BDB?
>
> 2. Are the features at least as good as BDB, and is the API close enough
> to make replacement reasonably easy?
>
> 3. BDB is very old code. When replacing it can we also adopt modern
> approaches more suited to modern hardware and use cases?
>
> I've looked at all of the KVP options I am aware of and consulted people
> who specialise in the space and can only see one that fits each of these
> well. MDB from the OpenLDAP project, http://symas.com/mdb/ .
>
> As to point 1, the rights holders of MDB need to make a public
> statement, but I have asked them in private and in any case the OpenLDAP
> history speaks for itself.
>
> As to point 2, MDB provides a superset of the KVP-specific features of
> BDB, and the API is similar to BDB but somewhat simpler.
>
> As to point 3, MDB is a from-scratch implementation in the modern world.
> MDB object code is a tiny fraction of BDB, and by adopting a
> memory-mapped architecture and dispensing with caching and locking it
> relies on modern operating system features rather than trying to
> implement them internally. This means greatly increased performance and
> very much smaller windows for corruption to occur. MDB has very clean
> support for concurrency compared to BDB, which makes it much more
> suitable for modern applications.
>
> There is an technical discussion of MDB here:
> http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance
> data has been published, one simple test that has a minimum of
> imaginable bias is to compare the SQLite3 API that comes with Oracle BDB
> with the SQLite3 ported to MDB. The other obvious speed test (that has
> had reproducible data published) is with OpenLDAP, which has pluggable
> back ends including both BDB and MDB.
>
> I'll be delighted if someone can suggest something that is even more
> suitable than MDB, but so far I haven't seen it.
>
> Looking at the Debian archive, packages with BDB dependencies are as
> follows (MDB integration has been marked where it exists, currently
> about 10% of the packages.):
>
> 389-ds-base
> animals
> apr-util
> apt
> bind9
> bitcoin
> bmf
> bogofilter
> boxbackup
> cairo-dock-plug-ins
> canl-c++
> cfengine2
> cfengine3LMDB support published
> chise-base
> c-icap
> citadel
> claws-mail
> clisp
> cyrus-imapd-2.4
> cyrus-sasl2 LMDB support published
> db-defaults
> dnshistory
> dovecot
> drac
> dsniff
> evolution-data-server
> evolution-exchange
> exim4
> fsvs
> ggcov
> glusterfs
> gridengine
> guile-db
> heimdal LMDB supported
> hotkeys
> hpsockd
> inn2
> iproute
> iproute2
> isync
> jabberd2
> libetpan
> libnss-db
> libpam-abl
> libpam-ccreds
> libpinyin
> libqxt
> librcc
> lucene2
> mailavenger
> memcachedb  LMDB support published
> mit-scheme
> mmorph
> moc
> netatalk
> nmh
> nordugrid-arc
> nss-updatedb
> nvi
> onak
> open-cobol
> opendkimLMDB supported
> openldapLMDB supported
> pam
> pavuk
> perdition
> perl
> php5
> poedit
> postfix 

Re: Berkeley DB 6.0 license change to AGPLv3

[Clint Adams]

On Tue, Jul 02, 2013 at 03:36:57PM +0200, Ondřej Surý wrote:
> apt-get is licensed GPLv2 and thus incompatible with AGPLv3.

No, apt is GPL-2+.

> cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
> OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
> subversion has Apache 2.0 license and thus incompatible with AGPLv3.

I think you are misunderstanding the AGPL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702145732.ga15...@scru.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

(Written on my phone).

I have worked with original information from Florian's follow-up to transition 
bug. Sorry for not checking apt license myself. Anyway... effectivelly 
relicensing apt to GPL-3 might not be a problem for apt (and all its rev-deps), 
but it is a still problem for all other software under other licenses.

Changing BSD-style license (with open the source clause) to (A)GPL-3 for a 
widely used library is a problem. There's no misunderstanding here.

Also it would cultivate the debate here if you have presented your arguments 
(e.g. explain why I might be mistaken) instead of presenting just the ad 
hominem arguments. Thanks.

Ondřej Surý

> On 2. 7. 2013, at 16:57, Clint Adams  wrote:
> 
>> On Tue, Jul 02, 2013 at 03:36:57PM +0200, Ondřej Surý wrote:
>> apt-get is licensed GPLv2 and thus incompatible with AGPLv3.
> 
> No, apt is GPL-2+.
> 
>> cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
>> OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
>> subversion has Apache 2.0 license and thus incompatible with AGPLv3.
> 
> I think you are misunderstanding the AGPL.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130702145732.ga15...@scru.org
> 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/c8c9196b-b771-4d0e-bf9f-07474910b...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Clint Adams]

On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
> Also it would cultivate the debate here if you have presented your arguments 
> (e.g. explain why I might be mistaken) instead of presenting just the ad 
> hominem arguments. Thanks.

I am not a lawyer, though I work for lawyers.  It would be
irresponsible for me to present such arguments.

I can suggest, however, that you can either read the license text
or contact licens...@fsf.org before spreading more FUD.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702153039.ga16...@scru.org

Bug#714762: ITP: libwww-dict-leo-org-perl -- interface module to dict.leo.org online dictionary

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libwww-dict-leo-org-perl
  Version : 1.35
  Upstream Author : Thomas Linden 
* URL : https://metacpan.org/release/WWW-Dict-Leo-Org/
* License : GPL-1+
  Programming Lang: Perl
  Description : interface module to dict.leo.org online dictionary

WWW::Dict::Leo::Org is a module which connects to the website dict.leo.org
and translates the given term. It returns an array of hashes. Each hash
contains a left side and a right side of the result entry.

The package also provides the `leo' commandline interface to the
German/English/French dictionary on http://dict.leo.org/. It supports almost
all features which the website supports.

Results will be printed to the terminal. By default the search term will be
highlighted. To get faster results, `leo' is able to cache queries.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702155419.ga18...@jadzia.comodo.priv.at

Re: Berkeley DB 6.0 license change to AGPLv3

[Joey Hess]

Tollef Fog Heen wrote:
> An AGPL licenced libdb isn't particularly useful for us, though.  It'd
> mean distributing a fair amount of software including exim, postfix,
> squid, webalizer, dovecot and many other servers under the AGPL, which
> would mean patching them so you could download the source code through
> them.

Notwithstanding any other provision of this License, if you modify the
  Program, your modified version must prominently offer all users
  interacting with it remotely through a computer network (if your version
  supports such interaction) an opportunity to receive the Corresponding
  Source of your version by providing access to the Corresponding Source
  from a network server at no charge, through some standard or customary
  means of facilitating copying of software.

It's probably a stretch to claim that users interact with exim, postfix and
dovecot over the network. In any case, the AGPL does not require that the
program be a quine; it'd certainly be acceptable for a comment to be output
over SMTP (for example) with an URL to download the source.

> I think we should just keep libdb5.3 until a suitable replacement shows
> up.

I assume this is going to be dealt with upstream in each affected peice of
software. The only risk seems to be if an upstream upgrades without being
aware of the license change.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Russ Allbery]

Joey Hess  writes:

> Notwithstanding any other provision of this License, if you modify the
>   Program, your modified version must prominently offer all users
>   interacting with it remotely through a computer network (if your version
>   supports such interaction) an opportunity to receive the Corresponding
>   Source of your version by providing access to the Corresponding Source
>   from a network server at no charge, through some standard or customary
>   means of facilitating copying of software.

> It's probably a stretch to claim that users interact with exim, postfix
> and dovecot over the network.

It would be useful to have some clarification of exactly what Oracle means
by that.  (The FSF's opinion isn't horribly useful given that they're not
the copyright holders, even if they're the original authors of the
license.)

> In any case, the AGPL does not require that the program be a quine; it'd
> certainly be acceptable for a comment to be output over SMTP (for
> example) with an URL to download the source.

As an upstream for INN, I think doing such a thing would be completely
absurd, and would rather just drop Berkeley DB support entirely and make
everyone switch to a different overview method than do anything of the
sort.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvvxj5rq@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 5:30 PM, Clint Adams  wrote:

> On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
> > Also it would cultivate the debate here if you have presented your
> arguments (e.g. explain why I might be mistaken) instead of presenting just
> the ad hominem arguments. Thanks.
>
> I am not a lawyer, though I work for lawyers.  It would be
> irresponsible for me to present such arguments.
>

While flushing all said with 'you misunderstand AGPL' is a responsible
thing to do.


> I can suggest, however, that you can either read the license text
> or contact licens...@fsf.org before spreading more FUD.
>

I don't believe I have spread any FUD.

1. AGPLv3 is incompatible with GPLv2-only (
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
2. AGPLv3 is incompatible with Apache 2.0 license (
http://www.apache.org/licenses/GPL-compatibility.html)
3. AGPLv3 is more restrictive thus distributing the derivate works must be
licensed under AGPLv3 (e.g. GPL is hereditary) (f.e.
http://www.gnu.org/licenses/lgpl-java.html)

So a move from SleepyCat license to GPL based one is in fact problematic
and cannot be done lightly (and without upstream software author consent).

Ondrej
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 6:20 PM, Ondřej Surý  wrote:

> On Tue, Jul 2, 2013 at 5:30 PM, Clint Adams  wrote:
>
>> On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
>> > Also it would cultivate the debate here if you have presented your
>> arguments (e.g. explain why I might be mistaken) instead of presenting just
>> the ad hominem arguments. Thanks.
>>
>> I am not a lawyer, though I work for lawyers.  It would be
>> irresponsible for me to present such arguments.
>>
>
> While flushing all said with 'you misunderstand AGPL' is a responsible
> thing to do.
>
>
>> I can suggest, however, that you can either read the license text
>> or contact licens...@fsf.org before spreading more FUD.
>>
>
> I don't believe I have spread any FUD.
>
> 1. AGPLv3 is incompatible with GPLv2-only (
> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
> 2. AGPLv3 is incompatible with Apache 2.0 license (
> http://www.apache.org/licenses/GPL-compatibility.html)
>  3. AGPLv3 is more restrictive thus distributing the derivate works must
> be licensed under AGPLv3 (e.g. GPL is hereditary) (f.e.
> http://www.gnu.org/licenses/lgpl-java.html)
>
> So a move from SleepyCat license to GPL based one is in fact problematic
> and cannot be done lightly (and without upstream software author consent).
>

Just to clarify – I am not in any way opposed to the hereditary properties
of (A)GPL. The evil thing is the relicensing at the point where people
depend on you, and not the license itself.

O.
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer]

* Paul Tagliamonte:

> On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
>> Florian Weimer has correctly pointed out that Oracle has decided to change 
>> the
>> BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
>> 56.html). This hasn't been reflected in release tarball (probably by
>> mistake), but since the AGPLv3 is not very friendly to downstream projects, 
>> we
>> (as the Debian project) need to take a decision.
>
> What? Wait, What? What?[1]
>
> The AGPL is a DFSG free FSF approved and OSI approved free software
> license? We made a decision, it's *free software* and fit for main.

The problems start when random, network-enabled, but non-web stuff
switches over to the AGPL *without* implementing the Quine required by
the license (which is somewhat difficult to do for a library, but at
least there could be a "give me a tarball" interface).  That makes it
difficult to perform local changes and stay in compliance with the
license because you have to build the source code distribution
mechanism from scratch and design a process that ensures the sources
and running binaries match at all times.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obak5310@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

[Russ Allbery]

Ondřej Surý  writes:

> Just to clarify – I am not in any way opposed to the hereditary
> properties of (A)GPL. The evil thing is the relicensing at the point
> where people depend on you, and not the license itself.

I don't believe the AGPL was ever intended to be used for libraries.
Quite a bit of the license is very difficult to interpret as applied to a
library.  (For example, does that mean that every application using the
library has to provide a URL to download the source of the *library*?  Is
the user interacting with the library directly over the network?)

I think this one is all on Oracle.  They're using a license that was never
intended for a basic infrastructure library, quite possibly in an attempt
to make it obnoxious and excessively onerous to use the open source
version, or to create a situation where nearly all users of their library
are violating some technical term of the license (or at least are close
enough that a lawsuit wouldn't be immediately thrown out) and therefore
can be shaken down for cash if Oracle feels like it.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y59oj4ld@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

[Nick Andrik]

2013/7/2 Russ Allbery :
> I don't believe the AGPL was ever intended to be used for libraries.
> Quite a bit of the license is very difficult to interpret as applied to a
> library.  (For example, does that mean that every application using the
> library has to provide a URL to download the source of the *library*?  Is
> the user interacting with the library directly over the network?)
>
> I think this one is all on Oracle.  They're using a license that was never
> intended for a basic infrastructure library, quite possibly in an attempt
> to make it obnoxious and excessively onerous to use the open source
> version, or to create a situation where nearly all users of their library
> are violating some technical term of the license (or at least are close
> enough that a lawsuit wouldn't be immediately thrown out) and therefore
> can be shaken down for cash if Oracle feels like it.

Since AGPLv3 is really similar to GPLv3 but mostly oriented for
webapplications, would it make sense to contact Oracle with the
concerns raised in this thread and ask for clarification and possible
consideration to change to license to GPLv3 instead?

There could be some possibility that the choice of AGPL over GPL was
not well considered by their part with all the issues that raises.

On the other hand, with Oracle one can never be sure, but at least
contacting them will make the problem more widely apparent and their
ittentions more clear.

--
=Do-
N.AND


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANn5kOuWyfPjtyPa-Gqdis9Pv1ub73fW=6353zufwbg1fgx...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Dmitrijs Ledkovs]

On 2 July 2013 17:58, Nick Andrik  wrote:
> 2013/7/2 Russ Allbery :
>> I don't believe the AGPL was ever intended to be used for libraries.
>> Quite a bit of the license is very difficult to interpret as applied to a
>> library.  (For example, does that mean that every application using the
>> library has to provide a URL to download the source of the *library*?  Is
>> the user interacting with the library directly over the network?)
>>
>> I think this one is all on Oracle.  They're using a license that was never
>> intended for a basic infrastructure library, quite possibly in an attempt
>> to make it obnoxious and excessively onerous to use the open source
>> version, or to create a situation where nearly all users of their library
>> are violating some technical term of the license (or at least are close
>> enough that a lawsuit wouldn't be immediately thrown out) and therefore
>> can be shaken down for cash if Oracle feels like it.
>
> Since AGPLv3 is really similar to GPLv3 but mostly oriented for
> webapplications, would it make sense to contact Oracle with the
> concerns raised in this thread and ask for clarification and possible
> consideration to change to license to GPLv3 instead?
>
> There could be some possibility that the choice of AGPL over GPL was
> not well considered by their part with all the issues that raises.
>
> On the other hand, with Oracle one can never be sure, but at least
> contacting them will make the problem more widely apparent and their
> ittentions more clear.
>

Looking at db5.3 copyright file, I see copyright holders:
INRIA, France Telecom
The President and Fellows of Harvard University
The Regents of the University of California
Oracle

So is the whole code base re-licensed? or only the changes that Orcale
is making here-after?

Regards,

Dmitrijs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluiok18hp34xbvp+t9gq+p9n3yrzgee7o1+icruv4pk...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 6:58 PM, Nick Andrik  wrote:

> 2013/7/2 Russ Allbery :
> > I don't believe the AGPL was ever intended to be used for libraries.
> > Quite a bit of the license is very difficult to interpret as applied to a
> > library.  (For example, does that mean that every application using the
> > library has to provide a URL to download the source of the *library*?  Is
> > the user interacting with the library directly over the network?)
> >
> > I think this one is all on Oracle.  They're using a license that was
> never
> > intended for a basic infrastructure library, quite possibly in an attempt
> > to make it obnoxious and excessively onerous to use the open source
> > version, or to create a situation where nearly all users of their library
> > are violating some technical term of the license (or at least are close
> > enough that a lawsuit wouldn't be immediately thrown out) and therefore
> > can be shaken down for cash if Oracle feels like it.
>
> Since AGPLv3 is really similar to GPLv3 but mostly oriented for
> webapplications, would it make sense to contact Oracle with the
> concerns raised in this thread and ask for clarification and possible
> consideration to change to license to GPLv3 instead?
>

That would help just a little bit. GPLv3 library is still incompatible with
f.e. Apache 2.0 licensed program.

So this would still need to be handled in case-by-case manner working
closely with upstream developers.

There could be some possibility that the choice of AGPL over GPL was
> not well considered by their part with all the issues that raises.
>
> On the other hand, with Oracle one can never be sure, but at least
> contacting them will make the problem more widely apparent and their
> ittentions more clear.
>

I already wrote to the Oracle developer I am in close contact with about
the mismatch of the license in distribution tarball and I will pursue this
further when he responds.

Ondrej
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Julien Cristau]

On Tue, Jul  2, 2013 at 18:58:34 +0200, Nick Andrik wrote:

> Since AGPLv3 is really similar to GPLv3 but mostly oriented for
> webapplications, would it make sense to contact Oracle with the
> concerns raised in this thread and ask for clarification and possible
> consideration to change to license to GPLv3 instead?
> 
GPLv3 would be just as bad.  Changing a library from BSD to GPL is
something you just don't do.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Andrey Rahmatullin]

On Tue, Jul 02, 2013 at 06:58:34PM +0200, Nick Andrik wrote:
> Since AGPLv3 is really similar to GPLv3 but mostly oriented for
> webapplications, would it make sense to contact Oracle with the
> concerns raised in this thread and ask for clarification and possible
> consideration to change to license to GPLv3 instead?
> 
> There could be some possibility that the choice of AGPL over GPL was
> not well considered by their part with all the issues that raises.

Or, considering the same arguments, to LGPL3+.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 7:03 PM, Richard Fontana  wrote:

> On Tue, Jul 02, 2013 at 06:20:48PM +0200, Ondřej Surý wrote:
> > I don't believe I have spread any FUD.
> >
> [...]
> > 2. AGPLv3 is incompatible with Apache 2.0 license (
> http://www.apache.org/
> > licenses/GPL-compatibility.html)
>
> Only in the same sense that GPL or LGPL (any version) is incompatible
> with any noncopyleft license in the copyleft-to-permissive
> direction. The Apache License 2.0 is compatible with AGPLv3 in the
> other direction.
>

Yeah, but we are talking about a library here, so it's the wrong direction
case here.  But right, I should have been more clear here.

O.
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Francesco Poli]

On Tue, 02 Jul 2013 18:40:11 +0200 Florian Weimer wrote:

> * Paul Tagliamonte:
> 
> > On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
> >> Florian Weimer has correctly pointed out that Oracle has decided to change 
> >> the
> >> BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
> >> 56.html). This hasn't been reflected in release tarball (probably by
> >> mistake), but since the AGPLv3 is not very friendly to downstream 
> >> projects, we
> >> (as the Debian project) need to take a decision.
> >
> > What? Wait, What? What?[1]
> >
> > The AGPL is a DFSG free FSF approved and OSI approved free software
> > license? We made a decision, it's *free software* and fit for main.

For the record, I personally disagree with the FTP masters' decision to
accept works licensed under the terms of the GNU AfferoGPL v3 into
main:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#28
But that's my own opinion, of course.

> 
> The problems start when random, network-enabled, but non-web stuff
> switches over to the AGPL *without* implementing the Quine required by
> the license (which is somewhat difficult to do for a library, but at
> least there could be a "give me a tarball" interface).  That makes it
> difficult to perform local changes and stay in compliance with the
> license because you have to build the source code distribution
> mechanism from scratch and design a process that ensures the sources
> and running binaries match at all times.

This is indeed one of the issues of the GNU AfferoGPL v3.
There are other issues, as well.
My own analysis is here:
https://lists.debian.org/debian-legal/2007/11/msg00233.html

If those issues don't make people consider AfferoGPLv3-licensed works
as non-free, I think this license should at least be considered as
problematic.

Especially when a fairly widely used *library* switches from a
*permissive non-copyleft* license to a *highly restrictive* one (such
as the GNU AfferoGPL v3), I think the change should *not* be neglected
or taken lightly...


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpGpH87sNz4m.pgp
Description: PGP signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Jean-Christophe Dubacq]

Le 02/07/2013 16:35, Ondřej Surý a écrit :
> Thanks Dan for this comprehensive email.
> 
> I'll take ITP bug for libmdb (#694757) under pkg-db umbrella, as it will
> affect Berkeley DB, so it makes sense to have it there.
> 
> People are most welcome to join the team, as I am the only active person
> in the team.
> 
> O.

I happen to already have a private version of liblmdb packaged. As far
as I know, I met the following problems:

 * The library has no SONAME
 * I used a git (unreleased) version ; no tarballs of the source code
were made
 * the executables were statically linked.

I would be happy to continue the work on this library, albeit as a
sponsoree or something (I am not a DD nor a DM).

The git tree was not made public, but I can provide all of my work.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Howard Chu]

Dan Shearer wrote:

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:


Florian Weimer has correctly pointed out that Oracle has decided to change
the BDB 6.0 license to AGPLv3 (
https://oss.oracle.com/pipermail/bdb/2013-June/56.html).

:

we (as the Debian project) need to take a decision.

:

(because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
and there is code under these licenses which depends on BDB. There is
also code which depends on BDB that is compatible with the AGPLv3
legally, but whose deployment would then be restricted in ways the users
would not be expecting.)


As far as I am aware the most prominent users of Berkeley DB are
moving away from the library anyway ...


There are actually very few true alternatives to BDB. While there are
many KVP (key value pair) stores [1] not many are transactional, allow
multi-version concurrency control [2] and support multi-threaded and
multi-process access. BDB is all of the above, and in addition the BDB
API has become very widely used over nearly 30 years. And of course the
BSD license allowed BDB to be embedded in a huge amount of software -
like the BSD networking stack, it turns up just about everywhere.

So there are three things to think about in a replacement:

1. Is the licensing as suitable as the BSD license has been, and is
the primary maintainer likely to do what Oracle just did to BDB?

2. Are the features at least as good as BDB, and is the API close enough
to make replacement reasonably easy?

3. BDB is very old code. When replacing it can we also adopt modern
approaches more suited to modern hardware and use cases?

I've looked at all of the KVP options I am aware of and consulted people
who specialise in the space and can only see one that fits each of these
well. MDB from the OpenLDAP project, http://symas.com/mdb/ .

As to point 1, the rights holders of MDB need to make a public
statement, but I have asked them in private and in any case the OpenLDAP
history speaks for itself.


Just to be very clear about this, from the perspectives of both me
personally and the OpenLDAP Project.

Personally, I am a very strong supporter of GPL/copyleft. Having been a
gcc maintainer in the gcc 1.x-2.x days, and contributing to gmake,
screen, texinfo, and a variety of other FSF projects, it's been in my
blood for nearly 30 years. (Indeed, I have one of the oldest
GPL-licensed projects around, with a source revision history spanning
back 25+ years http://sourceforge.net/projects/arc/)

Another personal view I hold strongly is that a project's license
shouldn't change unless it isn't working for the users, or the users
approve of a change to cater for some anticipated need.

The OpenLDAP Project's license is BSD-flavored and was established
before I joined. As Chief Architect of the Project I see no reason to
change this. It has served the Project well with no user complaints. The
LMDB code was written for and is part of OpenLDAP, and we consciously chose to 
have it covered by the OpenLDAP license. Dan asks, in effect, "will the LMDB 
maintainers do with the OpenLDAP license what Oracle just did with the BDB 
license?"


The first thing is, nobody has privileged ownership of OpenLDAP code
because the Project does not require copyright assignment. It is not
possible for anyone to build a business model selling secret code
versions while preventing anyone else from building the same business
model through a license such as the AGPL.

Secondly, the OpenLDAP Project is not interested in any kind of
relicensing for any portion of our code, even given that it would not
put anyone in a privileged position. We can't predict the future, but we
have not seen anything indicating it might be needed. We know that there
are other projects which rely on OpenLDAP code being BSD-ish and we
respect that dependency.

There is another party involved who have funded a lot of OpenLDAP over
the years, Symas Corporation. I'm CTO of Symas, and I can tell you I am
quite pleased that even though the company is a good OSS citizen, there
is nothing that could happen in the company which would put Symas in the
position of power that Oracle has over BDB. So Symas' involvement is not
relevant to calculating the risk of a relicensing happening.

In short: OpenLDAP has no intention of relicensing and would not without
consultation with the community, and we have no intention of requiring
copyright assignment to us or anyone else.


As to point 2, MDB provides a superset of the KVP-specific features of
BDB, and the API is similar to BDB but somewhat simpler.


We deliberately modeled the LMDB API after BDB's transactional API because it 
made it easier for us to build an OpenLDAP slapd backend based on our existing 
BDB backend code. Feedback from other projects shows that our approach has 
helped others migrate easily as well.



As to point 3, MDB is a from-scratch implementation in the modern world.
MDB object code is a tiny fraction of BD

Re: Berkeley DB 6.0 license change to AGPLv3

[Richard Fontana]

On Tue, Jul 02, 2013 at 06:20:48PM +0200, Ondřej Surý wrote:
> I don't believe I have spread any FUD.
> 
[...]
> 2. AGPLv3 is incompatible with Apache 2.0 license (http://www.apache.org/
> licenses/GPL-compatibility.html)

Only in the same sense that GPL or LGPL (any version) is incompatible
with any noncopyleft license in the copyleft-to-permissive
direction. The Apache License 2.0 is compatible with AGPLv3 in the
other direction.

- RF


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702170356.ga16...@redhat.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Bernhard R. Link]

* Paul Tagliamonte  [130702 15:15]:
> Again, why do you plan on removing free software from main due to a
> change in license?

Licenses matter. Just because something it acceptable for Debian
main does not mean it is a good idea to have something licensed under
a specific license. So removing stuff if their license changes can
make sense in many situations.

And doubly so for AGPL. (I'll never understand why people consider it
free software, I'd not even allow the term freeware for it).

Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702175730.ga3...@client.brlink.eu

Re: boot ordering and resolvconf

[Don Armstrong]

On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
> Automatic processes overwrite explicit admin setups.

If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
"somewhere else". If it's not a symlink, then it shouldn't be
overridden.
 
> It seems resolvconf wants to get its name servers from
> /etc/network/interfaces?

Resolvconf can get its nameservers from anywhere that calls

echo 'namserver information'|resolvconf -a interface.program;

> Also, I don't think updating files in /etc at runtime is a sensible
> idea, it should be possible to run with / read-only if you want to.

Yes, which is exactly why resolvconf doesn't update /etc during normal
operation.
 
> I specified that: settings are overridden, the file in /run is not
> masked. Whether you want to append the nameserver list or override the
> one from /run should probably be specified. I'd say override, since
> appending can easily lead to security breaches.

The only difference here between using resolvconf and this setup is that
instead of having the configuration be specified in the /etc/resolv.conf
file or symlink, it's specified in the resolver.
 
> In that case, feel free to provide a framework for packages to
> coordinate updates to /run/resolv.conf and have stacking and whatnot.
> (They could write to /run/resolv.conf.d/$num_$basename and resolvconf
> or a similar tool could build a /run/resolv.conf from that.)

This is already what resolvconf does. It has information on interface
primacy (/etc/resolvconf/interface order), knows how many nameservers it
is useful to have in /etc/resolv.conf.

-- 
Don Armstrong  http://www.donarmstrong.com

This message brought to you by weapons of mass destruction related
program activities, and the letter G.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702182805.ga12...@teltox.donarmstrong.com

Re: boot ordering and resolvconf

[Howard Chu]

Don Armstrong wrote:

On Tue, 02 Jul 2013, Tollef Fog Heen wrote:

Automatic processes overwrite explicit admin setups.


If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
"somewhere else". If it's not a symlink, then it shouldn't be
overridden.


That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this fact.

I'm a bit surprised that this conversation still needs to happen today. It was 
a constant annoyance when I was using Ubuntu. (I finally switched to Arch back 
in January this year.)


Networkmanager seems to have been the root of most of my complaints; its 
authors seem to believe that their code knows better than a machine's sysadmin 
how the machine should be operated.


https://mail.gnome.org/archives/networkmanager-list/2008-September/msg00189.html

The sensible thing to do is let something like dnsmasq do all resolver 
management. I first proposed this change ~5 years ago


https://mail.gnome.org/archives/networkmanager-list/2008-September/msg00042.html

It's a topic that comes up perennially.

https://mail.gnome.org/archives/networkmanager-list/2009-April/msg00157.html

https://mail.gnome.org/archives/networkmanager-list/2011-January/msg00020.html

https://mail.gnome.org/archives/networkmanager-list/2012-April/msg00072.html

Providing solutions for other tools, e.g. dhclient or pppd is pretty trivial 
too.

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q2/003009.html

We're well into the 2nd decade of the 21st century. These problems shouldn't 
exist any more.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d32c30.1030...@symas.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer]

* Julien Cristau:

> On Tue, Jul  2, 2013 at 18:58:34 +0200, Nick Andrik wrote:
>
>> Since AGPLv3 is really similar to GPLv3 but mostly oriented for
>> webapplications, would it make sense to contact Oracle with the
>> concerns raised in this thread and ask for clarification and possible
>> consideration to change to license to GPLv3 instead?

> GPLv3 would be just as bad.  Changing a library from BSD to GPL is
> something you just don't do.

Previous versions of Berkeley DB have been released under the
Sleepycat license, which is actually a copyleft license.  It doesn't
conflict with further restrictions (which weakens it somewhat), but it
requires that "freely redistributable" source code is given to *all*
recipients of the binaries, which is in a way stronger than the GPLv3
(although copyleft extends in different directions, so it's hard to
two licenses as if there was just a single scale).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4fg3fhy@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer]

* Howard Chu:

> We can provide plenty more documentation on LMDB performance and
> reliability if desired.

Can you cope with incompletely written pages (e.g., only the first 512
bytes of a page is written) or write reordering between fsyncs?

Berkeley DB doesn't deal with torn writes, either, but it can deal
with write reordering.  The latter is what makes the checkpoints so
expensive, but I don't think there's a way around that.  You can
spread out the writes (PostgreSQL tries to do that, but it is not
entirely successful because of kernel API limitations), but then you
risk doing additional writes which are not strictly required for
durability.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwq43es5@mid.deneb.enyo.de

Re: boot ordering and resolvconf

[Steve Langasek]

On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:
> Don Armstrong wrote:
> >On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
> >>Automatic processes overwrite explicit admin setups.

> >If /etc/resolv.conf is a symlink to somewhere else, then it's
> >appropriate for automatic processes to override it by writing to
> >"somewhere else". If it's not a symlink, then it shouldn't be
> >overridden.

> That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this
> fact.

I'm not sure why you group Ubuntu and NetworkManager together here.  Ubuntu
has been using dnsmasq and resolvconf on the desktop (and resolvconf alone
on the server) since the 12.04 release specifically to provide a coherent
architecture and get away from NM's past bad behavior of changing files in
/etc out from under the admin.

  http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

*By default*, all Ubuntu systems running a newer release will have
/etc/resolv.conf as a symlink to /run to ensure the system behaves sensibly
(correct DNS server settings with or without dnsmasq running; honoring DNS
server settings configured in /etc/network/interfaces; and so on).  But if
this symlink is really bothering you, you can make /etc/resolv.conf a real
file and resolvconf won't mess with it any further.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Plan to release a gplv3 compliant debian-based release

[Svante Signell]

Hi,

I've been thinking about this for some time now. There is a need for a
gplv3+-compliant Debian-based distribution! Meaning that gplv2 only code
will not be included! For kernels, kFreeBSD and Hurd will remain, and
Linux will be several years back of course. Anybody has an idea on how
old Linux kernel will remain? Comments, ideas, any takers? Criticism I
assume will be plenty. Maybe even FSF might help here.

Have a nice day:)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1372796680.9275.8.camel@PackardBell-PC

Re: Berkeley DB 6.0 license change to AGPLv3

[Howard Chu]

Florian Weimer wrote:

* Howard Chu:


We can provide plenty more documentation on LMDB performance and
reliability if desired.


Can you cope with incompletely written pages (e.g., only the first 512
bytes of a page is written) or write reordering between fsyncs?

Berkeley DB doesn't deal with torn writes, either, but it can deal
with write reordering.  The latter is what makes the checkpoints so
expensive, but I don't think there's a way around that.  You can
spread out the writes (PostgreSQL tries to do that, but it is not
entirely successful because of kernel API limitations), but then you
risk doing additional writes which are not strictly required for
durability.


We require that fsync() (actually fdatasync()) doesn't lie. Data pages can be 
written in any order, as long as all outstanding data pages are actually 
written by the time fsync returns. Given this constraint, you can pull the 
power on a drive and the DB will still be fine.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d3377a.7020...@symas.com

Re: Plan to release a gplv3 compliant debian-based release

[Ben Hutchings]

On Tue, Jul 02, 2013 at 10:24:40PM +0200, Svante Signell wrote:
> Hi,
> 
> I've been thinking about this for some time now. There is a need for a
> gplv3+-compliant Debian-based distribution! Meaning that gplv2 only code
> will not be included! For kernels, kFreeBSD and Hurd will remain, and
> Linux will be several years back of course. Anybody has an idea on how
> old Linux kernel will remain? Comments, ideas, any takers? Criticism I
> assume will be plenty. Maybe even FSF might help here.
> 
> Have a nice day:)

You're slipping.  Your trolling used to be way more subtle.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702202906.gw4...@decadent.org.uk

Re: Plan to release a gplv3 compliant debian-based release

[Samuel Thibault]

Svante Signell, le Tue 02 Jul 2013 22:24:40 +0200, a écrit :
> I've been thinking about this for some time now. There is a need for a
> gplv3+-compliant Debian-based distribution!

I don't see why there should be such a need.  By Debian's standards
GPLv2 is GFDL-compliant.

Samuek


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702202946.GU5721@type

Re: Berkeley DB 6.0 license change to AGPLv3

[Julien Cristau]

On Tue, Jul  2, 2013 at 21:53:45 +0200, Florian Weimer wrote:

> Previous versions of Berkeley DB have been released under the
> Sleepycat license, which is actually a copyleft license.

Right, my bad.  I forgot about that oddity.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Plan to release a gplv3 compliant debian-based release

[Samuel Thibault]

Samuel Thibault, le Tue 02 Jul 2013 22:29:46 +0200, a écrit :
> Svante Signell, le Tue 02 Jul 2013 22:24:40 +0200, a écrit :
> > I've been thinking about this for some time now. There is a need for a
> > gplv3+-compliant Debian-based distribution!
> 
> I don't see why there should be such a need.  By Debian's standards
> GPLv2 is GFDL-compliant.

Eerf, I shouldn't use acronyms. I mean dfsg, of course...

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702203200.GV5721@type

Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer]

* Howard Chu:

> We require that fsync() (actually fdatasync()) doesn't lie. Data pages
> can be written in any order, as long as all outstanding data pages are
> actually written by the time fsync returns. Given this constraint, you
> can pull the power on a drive and the DB will still be fine.

And you do an fsync() as part of every transaction commit?  Doesn't
this force quite a bit of non-sequential writes?  (Page 0 or 1, plus
all the pages written to during the transaction.)

It's curious that this results in competitive write performance.
(WAL-based systems only need one sequential write during transaction
commit.)  Perhaps spreading out the writes at commit is worth all the
seeking and the potentially redudant writes because it avoids
write-induced stalls at checkpoints (or compaction events or whatever
databases do to look good in benchmarks but fall over in practice :-).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo6k1yyk@mid.deneb.enyo.de

Re: Plan to release a gplv3 compliant debian-based release

[Svante Signell]

On Tue, 2013-07-02 at 21:29 +0100, Ben Hutchings wrote:
> On Tue, Jul 02, 2013 at 10:24:40PM +0200, Svante Signell wrote:
> > Hi,
> > 
> > I've been thinking about this for some time now. There is a need for a
> > gplv3+-compliant Debian-based distribution! Meaning that gplv2 only code
> > will not be included! For kernels, kFreeBSD and Hurd will remain, and
> > Linux will be several years back of course. Anybody has an idea on how
> > old Linux kernel will remain? Comments, ideas, any takers? Criticism I
> > assume will be plenty. Maybe even FSF might help here.
> > 
> > Have a nice day:)
> 
> You're slipping.  Your trolling used to be way more subtle.

Sorry Ben, I'm serious about this. GPLv2 is evil wrt progress, and I
still would like to know how many years Linux would back until the first
V2 only statement. Of course you cannot answer this question, but maybe
somebody else. Add to that, a very large number of authors are probably
willing to release their code v2+ (or v3+), not v2 only.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1372798874.9275.15.camel@PackardBell-PC

Re: Plan to release a gplv3 compliant debian-based release

[Russ Allbery]

Svante Signell  writes:

> Sorry Ben, I'm serious about this. GPLv2 is evil wrt progress, and I
> still would like to know how many years Linux would back until the first
> V2 only statement. Of course you cannot answer this question, but maybe
> somebody else.

It's not just Linux, and the only way you're taking Git away from me is if
you pry it out of my cold, dead hands.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9m4fz0f@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

[Howard Chu]

Florian Weimer wrote:

* Howard Chu:


We require that fsync() (actually fdatasync()) doesn't lie. Data pages
can be written in any order, as long as all outstanding data pages are
actually written by the time fsync returns. Given this constraint, you
can pull the power on a drive and the DB will still be fine.


And you do an fsync() as part of every transaction commit?  Doesn't
this force quite a bit of non-sequential writes?  (Page 0 or 1, plus
all the pages written to during the transaction.)


Yes, but in fact we send writes to the OS in sorted order (ascending page 
number). Net result is that performance on an HDD is better than random seek 
time because there are no head direction reversals in the middle of a commit. 
(Assuming the underlying I/O scheduler doesn't get in the way. Usually we use 
the noop scheduler.) Also we allocate and reuse pages in linear order, so very 
frequently our writes are purely sequential. A trace of disk activity on 
writes would be reminiscent of an old style typewriter - gradual progress from 
0/1 upward followed by a carriage return.



It's curious that this results in competitive write performance.
(WAL-based systems only need one sequential write during transaction
commit.)  Perhaps spreading out the writes at commit is worth all the
seeking and the potentially redudant writes because it avoids
write-induced stalls at checkpoints (or compaction events or whatever
databases do to look good in benchmarks but fall over in practice :-).


LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of source, 
there's nowhere to hide any tricks anyway.)


This is as apples-to-apples real world as it gets, since the BDB backends in 
OpenLDAP have been around for over a decade and tuned to the Nth degree.


http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance

We've spent years fighting with bad behaviors in DBs. We have none of them in 
LMDB.


http://www.anchor.com.au/blog/2013/05/second-strike-with-lightning/

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d3427a.50...@symas.com

Re: [Popcon-developers] Encrypted popcon submissions

[Bill Allombert]

On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote:
> Dear Debian people,
> 
> I upload popularity-contest 1.58 which add support for encrypted submissions.
> For this release it is not activated by default. 
> Please help test this feature by adding
> ENCRYPT="yes"
> to /etc/popularity-contest.conf to activate it.
> 
> Once this feature has seen proper testing, we will activate it by default.

Well, 1.58 is now is testing and I still received only an handful of encrypted
report. I know you can do better!

(Unless there some major bug in the script which cause encrypted reported not
to be reported, bu nobody reported problems either)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702212712.GA5230@yellowpig

Re: boot ordering and resolvconf

[Howard Chu]

Steve Langasek wrote:

On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:

Don Armstrong wrote:

On Tue, 02 Jul 2013, Tollef Fog Heen wrote:

Automatic processes overwrite explicit admin setups.



If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
"somewhere else". If it's not a symlink, then it shouldn't be
overridden.



That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this
fact.


I'm not sure why you group Ubuntu and NetworkManager together here.  Ubuntu
has been using dnsmasq and resolvconf on the desktop (and resolvconf alone
on the server) since the 12.04 release specifically to provide a coherent
architecture and get away from NM's past bad behavior of changing files in
/etc out from under the admin.

   http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

*By default*, all Ubuntu systems running a newer release will have
/etc/resolv.conf as a symlink to /run to ensure the system behaves sensibly
(correct DNS server settings with or without dnsmasq running; honoring DNS
server settings configured in /etc/network/interfaces; and so on).  But if
this symlink is really bothering you, you can make /etc/resolv.conf a real
file and resolvconf won't mess with it any further.

That sounds nice, but my old laptop running 12.04 is still getting its 
/etc/resolv.conf overwritten by networkmanager, I just took a look and the 
timestamp on it is from a few hours ago.


Anyway, having just now read the launchpad blueprint, I'm sorry I missed this 
discussion when I was at that UDS. resolvconf is an unnecessary layer here, 
dnsmasq handles all of the interface-specific knowledge already. Patching 
dhclient's interface scripts to talk to dnsmasq over DBUS is trivial (see link 
in my previous email) and anything else that wants to touch it can be fixed 
easily as well.


virtmanager's use of dnsmasq is a non-issue since it binds its instances to 
its specific virtual networks already. They all just need to know to forward 
to the main dnsmasq on 127.0.0.1 when handling their clients' requests.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d34b3d@symas.com

Bug#714799: RFA: windows-el -- window manager for GNU Emacs

[Hubert Chathi]

Package: wnpp
Severity: normal

I no longer use this package, so I am requesting an adopter for it.

I've just made an upload to fix all open bugs.

The package description is:
 windows.el allows you to switch between window configurations in emacs,
 providing behaviour similar to virtual desktops that is common in several
 window managers.  In addition, you can save window configurations to a file
 and restore them at a later time.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gh8lj7w@uhoreg.ca

Bug#714800: ITP: libcerf -- C implementation of the complex error function

[Eugen Wintersberger]

Package: wnpp
Severity: wishlist
Owner: Eugen Wintersberger 

* Package name: libcerf
  Version : 1.1.0
  Upstream Author : Joachim Wuttke 
* URL : http://apps.jcns.fz-juelich.de/doku/sc/libcerf
* License : MIT/X
  Programming Lang: C
  Description : C implementation of the complex error function

This is the home page of libcerf, a self-contained numeric library that provides
an efficient and accurate implementation of complex error functions, along with
Dawson, Faddeeva, and Voigt functions.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013070833.9570.2542.reportbug@amun

Re: Plan to release a gplv3 compliant debian-based release

[John H. Robinson, IV]

Svante Signell wrote:
> 
> I've been thinking about this for some time now. There is a need for a
> gplv3+-compliant Debian-based distribution! Meaning that gplv2 only code
> will not be included! For kernels, kFreeBSD and Hurd will remain, and
> Linux will be several years back of course. Anybody has an idea on how
> old Linux kernel will remain? Comments, ideas, any takers? Criticism I
> assume will be plenty. Maybe even FSF might help here.

Good luck with the Linux kernel...

commit 625a8e113925b0bf958e7a4a05b91663908530a1
Author: linus1 
Date:   Sat Sep 5 11:00:00 1992 -0800

[PATCH] Linux-0.97.3 (September 5, 1992)

Hey, we switched to the GPL several months ago, but only now do we
include the license text itself.  Apparently everybody expected
everybody else to just know what the GPL was..


Exactly when the switch over took place is left as an exercise for
reader.  Since it was over a decade ago, I seriously doubt anyone would
use anything that ancient as a basis for a modern kernel.

-- 

John H. Robinson, IV  jaq...@sbih.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702223159.ga2...@ucsd.edu

Re: Plan to release a gplv3 compliant debian-based release

[Marco d'Itri]

On Jul 02, Ben Hutchings  wrote:

> You're slipping.  Your trolling used to be way more subtle.
I do not think that Svante has ever been trolling.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#714805: ITP: golang-mux-dev -- URL router and dispatcher

[Daniel Mizyrycki]

Package: wnpp
Version: N/A; reported 2013-07-02
Severity: wishlist
Owner: Daniel Mizyrycki 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : golang-mux-dev
Version : 0.0~git20130701-1
Upstream Author : Rodrigo Moraes 
* URL : http://github.com/gorilla/mux
* License : Expat
Programming Lang : Go
Description : URL router and dispatcher

 gorilla/mux is a powerful URL router and dispatcher go library.
 This package is meant only for building go binary packages that need
 the capability and should not be used directly for go development.
 .
 This package contains the source.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d35cf1.9080...@glidelink.net

Re: boot ordering and resolvconf

[Tollef Fog Heen]

]] Don Armstrong 

> On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
> > Automatic processes overwrite explicit admin setups.
> 
> If /etc/resolv.conf is a symlink to somewhere else, then it's
> appropriate for automatic processes to override it by writing to
> "somewhere else". If it's not a symlink, then it shouldn't be
> overridden.

Does that mean it's an RC bug for any non-manual process to overwrite
it?  I'd be happy to file bugs.

> > It seems resolvconf wants to get its name servers from
> > /etc/network/interfaces?
> 
> Resolvconf can get its nameservers from anywhere that calls
> 
> echo 'namserver information'|resolvconf -a interface.program;

If I do that by hand, that information will never ever be overwritten by
dhclient, NM, openvpn or tools, and it persists through reboots?

> > Also, I don't think updating files in /etc at runtime is a sensible
> > idea, it should be possible to run with / read-only if you want to.
> 
> Yes, which is exactly why resolvconf doesn't update /etc during normal
> operation.

Ok, good, that's different from the behaviour I've seen in the past, but
if that's fixd, that's great.

> > I specified that: settings are overridden, the file in /run is not
> > masked. Whether you want to append the nameserver list or override the
> > one from /run should probably be specified. I'd say override, since
> > appending can easily lead to security breaches.
> 
> The only difference here between using resolvconf and this setup is that
> instead of having the configuration be specified in the /etc/resolv.conf
> file or symlink, it's specified in the resolver.

Not sure what you eman by «resolver»?  (To me, that's the C code inside
glibc that does the actual lookup, which doesn't really fit what you're
describing.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m27gh87bmk@rahvafeir.err.no

Re: Plan to release a gplv3 compliant debian-based release

[Craig Small]

On Wed, Jul 03, 2013 at 01:16:04AM +0200, Marco d'Itri wrote:
> On Jul 02, Ben Hutchings  wrote:
> 
> > You're slipping.  Your trolling used to be way more subtle.
> I do not think that Svante has ever been trolling.
My initial thought was WTF but Ben's email seem to make it all clear.
Are you saying the initial email was serious, really?

It's a completely bad idea. BSD is fine, but GPL2 is not?

 - Craig
-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130703014218.gf7...@enc.com.au

Bug#714813: ITP: pear-doctrine-channel -- Doctrine PEAR channel

[David Prévot]

Package: wnpp
Severity: wishlist
Owner: David Prévot 

* Package name: pear-doctrine-channel
  Version : 0~20130702-1
* URL : http://pear.doctrine-project.org/
* License : public-domain
  Programming Lang: XML
  Description : Doctrine PEAR channel

 Description: Doctrine PEAR channel
 This is the PEAR channel registry entry for doctrine.
 PEAR is a framework and distribution system for reusable PHP components. A
 PEAR channel is a website that provides package for download and a few
 extra meta-information for files.


This is needed to package doctrine with pkg-php-tools.

Following the current pkg-php-tools conventions, this package should
have been named pear-doctrine-project-channel, while doctrine is the
actual alias in use.


signature.asc
Description: Digital signature

Re: boot ordering and resolvconf

[Bob Proulx]

Tollef Fog Heen wrote:
> ]] Don Armstrong 
> > Tollef Fog Heen wrote:
> > > It seems resolvconf wants to get its name servers from
> > > /etc/network/interfaces?
> > 
> > Resolvconf can get its nameservers from anywhere that calls
> > 
> > echo 'namserver information'|resolvconf -a interface.program;
> 
> If I do that by hand, that information will never ever be overwritten by
> dhclient, NM, openvpn or tools, and it persists through reboots?

Now that we have so many mobile devices the network may come and go
dynamically.  Therefore we need a dynamic method to update
nameservers.  When a network is activated it would call the above to
configure the nameservers found for that network interface.  When the
network interface is deactivated then those nameservers will need to
be removed.  Having them fixed statically would defeat the purpose.

And also there is the need to change nameservers when VPNs are
established.  A vpn comes online will often mean that the nameservers
from that vpn need to be used to access private names on that network.

I miss the old days when we could simply edit the files in /etc once
and be done with it.  That is still the way I do things on servers.
But on servers I don't install resolvconf.  However on mobile devices
that roam from network to network resolvconf rocks!

Bob


signature.asc
Description: Digital signature

Re: Candidates for removal from testing (2013-06-30)

[James Cloos]

Humble suggestion:

Sort the bug list (sort -k2 would be great) to make it easier to read
through the list and to find packages which might interest one.

It is a very useful report; a sort by package name would make it better.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m338rwnt2x@carbon.jhcloos.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Tue, Jul 2, 2013 at 7:11 PM, Andrey Rahmatullin  wrote:

> On Tue, Jul 02, 2013 at 06:58:34PM +0200, Nick Andrik wrote:
> > Since AGPLv3 is really similar to GPLv3 but mostly oriented for
> > webapplications, would it make sense to contact Oracle with the
> > concerns raised in this thread and ask for clarification and possible
> > consideration to change to license to GPLv3 instead?
> >
> > There could be some possibility that the choice of AGPL over GPL was
> > not well considered by their part with all the issues that raises.
>
> Or, considering the same arguments, to LGPL3+.
>

They already had a stronger license (SleepyCat is a two-clause BSD with
strong copyleft paragraph added), so it doesn't make any sense to relicense
to LGPLv3+.

O.
-- 
Ondřej Surý 

Bug#714818: ITP: quiterss -- RSS/Atom news feeds reader

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: quiterss
Version: 0.13.1
Upstream Author: QuiteRSS Team 
URL: https://code.google.com/p/quite-rss/
License: GPL-3+
Description: RSS/Atom news feeds reader
 QuiteRSS is "fast and comfortable to user" cross-platform RSS/Atom
 news feeds reader written on Qt/C++.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201307031623.29583.only...@debian.org

Re: boot ordering and resolvconf

[Tollef Fog Heen]

]] Bob Proulx 

> Tollef Fog Heen wrote:
> > ]] Don Armstrong 
> > > Tollef Fog Heen wrote:
> > > > It seems resolvconf wants to get its name servers from
> > > > /etc/network/interfaces?
> > > 
> > > Resolvconf can get its nameservers from anywhere that calls
> > > 
> > > echo 'namserver information'|resolvconf -a interface.program;
> > 
> > If I do that by hand, that information will never ever be overwritten by
> > dhclient, NM, openvpn or tools, and it persists through reboots?
> 
> Now that we have so many mobile devices the network may come and go
> dynamically.  Therefore we need a dynamic method to update
> nameservers.  When a network is activated it would call the above to
> configure the nameservers found for that network interface.  When the
> network interface is deactivated then those nameservers will need to
> be removed.  Having them fixed statically would defeat the purpose.

No, in my setup it should not do that without admin intervention.  Doing
that means it's likely to cause security-related problems.  I use DNSSEC
and don't want to trust random resolvers, I want to trust the one that
I've set up myself and that I know verifies signatures and that lives on
::1.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2zju45evz@rahvafeir.err.no

Re: boot ordering and resolvconf

[Paul Wise]

On Wed, Jul 3, 2013 at 2:36 PM, Tollef Fog Heen wrote:

> No, in my setup it should not do that without admin intervention.  Doing
> that means it's likely to cause security-related problems.  I use DNSSEC
> and don't want to trust random resolvers, I want to trust the one that
> I've set up myself and that I know verifies signatures and that lives on
> ::1.

What do you do when you are on a network that blocks DNS lookups that
don't go via the DNS servers for that network? Or for networks that do
that until you visit a web page and press a button on a form?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6ggmjtgsuj6ecyvm-m7+hxrdvlr2fqsfyq9sxrplnk...@mail.gmail.com

Bug#714820: ITP: ntopng -- High-Speed Web-based Traffic Analysis and Flow Collection Tool

[Ludovico Cavedon]

Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon 

* Package name: ntopng
  Version : 1.0
  Upstream Author : Luca Deri 
* URL : http://www.ntop.org/products/ntop/
* License : GPL-3
  Programming Lang: C++
  Description : High-Speed Web-based Traffic Analysis and Flow Collection 
Tool

ntopng is the next generation version of the original ntop, a network
traffic probe that shows the network usage, similar to what the popular
top Unix command does. ntop is based on libpcap and it has been written
in a portable way in order to virtually run on every Unix platform,
MacOSX and on Win32 as well.

ntopng users can use a a web browser to navigate through ntop (that acts
as a web server) traffic information and get a dump of the network
status. In the latter case, ntop can be seen as a simple RMON-like agent
with an embedded web interface. The use of:

- a web interface.
- limited configuration and administration via the web interface.
- reduced CPU and memory usage (they vary according to network size and
traffic).

What ntopng can do:
- Sort network traffic according to many protocols
- Show network traffic and IPv4/v6 active hosts
- Store on disk persistent traffic statistics in RRD format
- Geolocate hosts
- Discover application protocols by leveraging on nDPI, ntop’s DPI
  framework
- Characterise HTTP traffic by leveraging on characterisation services
  provided by block.si. ntopng comes with a demo characterisation key,
  but if you need a permanent one, please mail i...@block.si
- Show IP traffic distribution among the various protocols
- Analyse IP traffic and sort it according to the source/destination
- Display IP Traffic Subnet matrix (who’s talking to who?)
- Report IP protocol usage sorted by protocol type
- Act as a NetFlow/sFlow collector for flows generated by routers (e.g.
  Cisco and Juniper) or switches (e.g. Foundry Networks) when used
  together with nProbe
- Produce HTML5/AJAX network traffic statistics


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130703064524.11727.6689.report...@palladio.lastline.com

Bug#714821: ITP: ruby-nmatrix -- fast numerical linear algebra library for Ruby

[Cédric Boutillier]

Package: wnpp
Severity: wishlist
Owner: "Cédric Boutillier" 

* Package name: ruby-nmatrix
  Version : 0.0.4
  Upstream Author : Ruby Science Foundation
* URL : https://github.com/SciRuby/nmatrix
* License : BSD-2-clause
  Programming Lang: C, C++, Ruby
  Description : Fast Numerical Linear Algebra Library for Ruby

NMatrix is a fast numerical linear algebra library for Ruby, with dense
and sparse matrices. It is part of the SciRuby project
http://sciruby.com/.
The software is still in alpha state and will be packaged in
experimental for the moment.
It will be maintained under the umbrella of the Ruby Extras team.

Cheers,

Cédric



signature.asc
Description: Digital signature