Re: Reporting 1.2K crashes

[Nicolas Dandrimont]

* Paul Wise  [2013-07-04 13:20:38 +0800]:

> On Thu, Jul 4, 2013 at 12:48 PM, Kurt Roeckx wrote:
> 
> > I guess you could ask, but I have a feeling they would prefer to
> > work with the upstream projects.
> 
> I've sent an email to scan-ad...@coverity.com.
> 
> > clang also has an option to do that now I think, did someone try
> > to run that on the archive?
> 
> Do you know how to run that in an automated way? I would like to add
> it here and to my pbuilder hook:
> 
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
> 
> Debian's efforts on archive-wide scanning have seen better days. There
> is Mole (in qa svn repo), which does some data extraction and other
> things and is currently only used for watch file checking I think.
> There is DACA, which isn't being worked on AFAICT. There is
> debuild.me, which is actively being worked on by paultag and it uses
> the firehose data format, which is a Fedora initiated project about
> machine-readable static/etc analysis results.
> 
> http://qa.debian.org/cgi-bin/mole
> http://qa.debian.org/daca/
> http://debuild.me/
> https://github.com/fedora-static-analysis/firehose

There's a GSoC project underway, mentored by Sylvestre Ledru, to run
scan-build on all the archive. Here's the student application:

https://wiki.debian.org/SummerOfCode2013/StudentApplications/LeoCavaille

and a link to the progress reports from Léo:

http://lists.alioth.debian.org/pipermail/soc-coordination/2013-June/001544.html
http://lists.alioth.debian.org/pipermail/soc-coordination/2013-June/001600.html

Things seem to be going smoothly. IIRC Léo and Sylvestre will be at DebConf
too, so it might be the good time to do a BoF (or graft that on a QA BoF)?

Cheers,
-- 
Nicolas Dandrimont

BOFH excuse #255:
Standing room only on the bus.


signature.asc
Description: Digital signature

Re: Reporting 1.2K crashes

[Stefano Zacchiroli]

On Thu, Jul 04, 2013 at 06:48:47AM +0200, Kurt Roeckx wrote:
> clang also has an option to do that now I think, did someone try
> to run that on the archive?

Yep, Sylvestre is working on it together with Leo Cavaille as a GSoC
2013 project
https://wiki.debian.org/SummerOfCode2013/StudentApplications/LeoCavaille

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Stefano Zacchiroli]

Hi Bradley, and thanks for your comments.

On Wed, Jul 03, 2013 at 11:34:38AM -0400, Bradley M. Kuhn wrote:
> BTW, I'd suggest a rather unorthodox solution if developers are
> interested: fork this AGPLv3'd version of BDB, and begin making
> substantial improvements and changes under AGPLv3.  That way, Oracle
> isn't the sole copyright holder,

That is a pretty interesting proposal, indeed.

> and if Oracle were to take action under a clause of AGPLv3, other
> copyright holders could intervene and indicate they disagreed with
> Oracle.  If the case went to litigation, Oracle would have a tough
> time because the other copyright holders would be expert witnesses (in
> the USA sense -- not sure what the equivalent is elsewhere in the
> world) who were saying Oracle was acting unfairly and over-reading the
> license terms.  (I'd certainly be willing to be an expert witness as
> the license's co-author in such cases.)

So, I wonder, do we have any idea (due to them having already been
mentioned publicly elsewhere) about the craziest interpretation of AGPL
that the "evil guys" might come up with and, at the other end of the
spectrum, the most restrictive one? AFAIK AGPL hasn't been tested in
court, yet. But I can't help wondering what people are really scared
about here.

Is it the quine scenario (IMHO ruled out by the license text, but
obviously you never know...) that people fear to have to implement,
worrying about the fact that simply providing URLs to tarballs wouldn't
be considered enough? Or is it something else?

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Mass bug filing for shared library broken symlinks detected by piuparts

[Ondřej Surý]

Hmm,

I thought that I have fixed this in 0.11-2.

And I am unable to reproduce the bug in current unstable.

Ondrej


On Thu, Jul 4, 2013 at 8:25 AM, Andreas Beckmann  wrote:

> On 2013-07-04 03:27, Kurt Roeckx wrote:
> > On Wed, Jul 03, 2013 at 05:35:35PM +0200, Ondrej Surı wrote:
> >>> fabien boucher 
> >>> libjson0-dev : json-c
> >>> /usr/lib/x86_64-linux-gnu/libjson.so
> >>
> >> Also a false positive - this is result of json to json-c library name
> >> transition made by upstream and the symlink is kept there to allow
> programs
> >> to be compiled with -ljson.
> >
> > I see:
> > /usr/lib/i386-linux-gnu/libjson.so -> libjson-c.so
> > /usr/lib/i386-linux-gnu/libjson-c.so ->
> /lib/i386-linux-gnu/libjson-c.so.2.0.1
> >
> > And /lib/i386-linux-gnu/libjson-c.so.2.0.1 exists, so I don't see
> > why piuparts is giving a warning here.
>
> IIRC #710676. One of the links is not shipped but generated by ldconfig.
> But a -dev package does not call ldconfig, so this link is created
> non-deterministically by another package calling ldconfig ... which may
> happen shortly after the installation of libjson-dev - or two months later.
>
>
> Andreas
>
>
> --
> 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/51d51543.2080...@debian.org
>
>


-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Stefano Zacchiroli]

On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:
> 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.

I'm curious, can you elaborate on why as upstream you'd refuse to add
something like a protocol command that return a URL pointing to a
tarball containing the source code of the INN version the users are
running? At times, I'm really surprised by the upfront opposition that
AGPL could get in Free Software cycles and I'd like to understand more
your motives as an upstream.

I mean, sure, it *is* more tricky to provide such a URL for users that
will be running a *modified* version of INN. But it is exactly the same
kind of difficulties that people distributing modified copylefted
software will have to face to uphold GPL (or equivalent) terms.

AGPL is really nothing more than the adaptation of copyleft to a world
where software usage has shifted from compiled binaries people run on
their computers, to services they access over the net.  For people who
are fine with the copyleft approach (and of course not all of us are)
AGPL shouldn't be particularly shocking. In that sense, AGPL is just a
new release of GPL that closes a long outstanding bug titled "provide a
license port for the Software-as-a-Service era".

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Reporting 1.2K crashes

[Sylvestre Ledru]

On 04/07/2013 08:55, Russ Allbery wrote:
> Paul Wise  writes:
> 
>> Do you know how to run that in an automated way? I would like to add
>> it here and to my pbuilder hook:
> 
>> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
> 
> Run the normal build system commands under scan-build.  In other:
> 
> scan-build ./configure ...
> scan-build make
> 
> I haven't tried to see if just doing scan-build debian/rules build will
> work, but it might.
> 
If the packaging + upstream supports the customization of CC & CXX, it
should work.

"scan-build dpkg-buildpackage" is one of the way we are considering.

Sylvestre


-- 
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/51d525a7.90...@debian.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Russ Allbery]

Stefano Zacchiroli  writes:
> On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:

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

> I'm curious, can you elaborate on why as upstream you'd refuse to add
> something like a protocol command that return a URL pointing to a
> tarball containing the source code of the INN version the users are
> running?

Does that satisfy the license?  It doesn't look to me like it does,
because it doesn't ensure that the offer is presented to every client.
The client has to go run some command.

If that's all that's required, that's trivial -- put the URL into the
motd.* files and then LIST MOTD will return it with no further involvement
on INN's part required.  I certainly have no objection to that -- I don't
have to do anything at all as upstream.  :)  But that didn't seem to be
what the license said.

> At times, I'm really surprised by the upfront opposition that AGPL could
> get in Free Software cycles and I'd like to understand more your motives
> as an upstream.

The AGPL, for software that's already free and that isn't being abused in
the ways that the AGPL was designed to address, adds a bunch of headaches
and work for precisely zero benefit.

I understand the point for things that are heavily abused, such as cloud
services in general.  But INN is not one of those things.  Besides, it
doesn't really matter if it is: INN has always been available under a
BSD-style license.  That decision was made a long time ago, and it is what
it is; I intensely dislike random third-party software trying to force
that to change.

Berkeley DB does have a copyleft license already, but it's a very
unobjectionable one as these things go.  It's much easier to deal with
than the GPL, for instance, and is trivially satisfied by software
distributed under the BSD license.  This is not at all true of the AGPL.

-- 
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/871u7ekb7u@windlord.stanford.edu

Re: Reporting 1.2K crashes

[Paul Wise]

On Thu, Jul 4, 2013 at 2:55 PM, Russ Allbery wrote:

> Run the normal build system commands under scan-build.  In other:
>
> scan-build ./configure ...
> scan-build make

Hmm, it doesn't seem to work when upstream just uses CC=gcc in the
Makefile. For example mancala.

> I haven't tried to see if just doing scan-build debian/rules build will
> work, but it might.

Tried it on a package where the method above works and it did not work.

I expect it needs to switch to something like what you do with ccache
- add a special dir to $PATH.

-- 
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/CAKTje6GP4XUiV--puhj_U8J9gdQ+7-ArGVH-L4vJ=dzhxy6...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Michael Banck]

Hi,

On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
> On Thu, Jul 4, 2013 at 12:27 AM, Michael Banck  wrote:
> > People have pointed out upthread that Oracle does not appear to be the
> > sole copyright holder of BerkelyDB.  So unless they had copyright
> > assignments or similar on file, maybe a viable route would be to contact
> > those additional copyright holders and suggest they complain to Oracle
> > in order to get their relicensing reversed.
> >
> > This should probably be done in coordination with the wider Free
> > Software community.
> 
> >From my understanding, the other copyright holders' opinion doesn't
> really matter – even if they relicense just the parts they own the
> whole work will be distributed under stricter license (e.g. AGPLv3).
> But feel free to correct me if I am wrong.

That would only work if the Sleepycat license and the AGPLv3 are
compatible I guess, is that the case?  Otherwise, I would assume the
result not to be distributable.


Michael


-- 
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/20130704094441.gj27...@nighthawk.chemicalconnection.dyndns.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Thu, Jul 4, 2013 at 11:44 AM, Michael Banck  wrote:

> Hi,
>
> On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
> > On Thu, Jul 4, 2013 at 12:27 AM, Michael Banck 
> wrote:
> > > People have pointed out upthread that Oracle does not appear to be the
> > > sole copyright holder of BerkelyDB.  So unless they had copyright
> > > assignments or similar on file, maybe a viable route would be to
> contact
> > > those additional copyright holders and suggest they complain to Oracle
> > > in order to get their relicensing reversed.
> > >
> > > This should probably be done in coordination with the wider Free
> > > Software community.
> >
> > >From my understanding, the other copyright holders' opinion doesn't
> > really matter – even if they relicense just the parts they own the
> > whole work will be distributed under stricter license (e.g. AGPLv3).
> > But feel free to correct me if I am wrong.
>
> That would only work if the Sleepycat license and the AGPLv3 are
> compatible I guess, is that the case?  Otherwise, I would assume the
> result not to be distributable.


As far as I understand it – there are some parts in Berkeley DB source code
which is just BSD licensed (and the copyright holders are those mentioned
earlier)[1], then there are parts which were under SleepyCat license and
presumably the copyright holder for those parts is Oracle – and those were
relicensed to AGPLv3. (There are also mixed files[3].)

So, the AGPLv3 just needs to be compatible with 3-clause BSD license, which
is the case.

1. f.e. src/clib/atoi.c
2. f.e. src/clib/bsearch.c
3. f.e. src/db/db.c

O.
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Tollef Fog Heen]

]] Stefano Zacchiroli 

> On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:
> > 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.
> 
> I'm curious, can you elaborate on why as upstream you'd refuse to add
> something like a protocol command that return a URL pointing to a
> tarball containing the source code of the INN version the users are
> running?

Not all protocols are trivially extendable, and as Russ says, you have
to ensure it's seen by all clients.  I'd not be looking forward how to
bolt that onto OpenLDAP so the offer is seen by all LDAP clients (which
then have to show the offer in their UI somehow, presumably?)

[...]

> AGPL is really nothing more than the adaptation of copyleft to a world
> where software usage has shifted from compiled binaries people run on
> their computers, to services they access over the net.

I see a distinct difference between «I'm delivering mail to somebody
(and they have to provide me with an offer to the source code of their
MTA)» and «I'm putting my data into a web service where all the logic
and computation happens on the server side and I'm just seeing the UI
bits (but they have to offer me the source code to the entire
application)».  One of them is an implementation of a standard protocol,
the other is a distributed application.

-- 
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/87txkaob8l@qurzaw.varnish-software.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Michael Banck]

Hi,

On Thu, Jul 04, 2013 at 12:29:36PM +0200, Ondřej Surý wrote:
> On Thu, Jul 4, 2013 at 11:44 AM, Michael Banck  wrote:
> > On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
> > > >From my understanding, the other copyright holders' opinion doesn't
> > > really matter – even if they relicense just the parts they own the
> > > whole work will be distributed under stricter license (e.g. AGPLv3).
> > > But feel free to correct me if I am wrong.
> >
> > That would only work if the Sleepycat license and the AGPLv3 are
> > compatible I guess, is that the case?  Otherwise, I would assume the
> > result not to be distributable.
> 
> As far as I understand it – there are some parts in Berkeley DB source code
> which is just BSD licensed (and the copyright holders are those mentioned
> earlier)[1], then there are parts which were under SleepyCat license and
> presumably the copyright holder for those parts is Oracle – and those were
> relicensed to AGPLv3. (There are also mixed files[3].)
> 
> So, the AGPLv3 just needs to be compatible with 3-clause BSD license, which
> is the case.
> 
> 1. f.e. src/clib/atoi.c
> 2. f.e. src/clib/bsearch.c
> 3. f.e. src/db/db.c

Ah, the fact those other copyrights are under the BSD wasn't clear to
me, now it makes much more sense.


Thanks,

Michael


-- 
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/20130704104849.gk27...@nighthawk.chemicalconnection.dyndns.org

Re: Mass bug filing for shared library broken symlinks detected by piuparts

[Dave Steele]

On Thu, Jul 4, 2013 at 3:14 AM, Ondřej Surý  wrote:
> Hmm,
>
> I thought that I have fixed this in 0.11-2.
>
> And I am unable to reproduce the bug in current unstable.
>

libjson0-dev is no longer failing for me either. My release check of
the list did not catch the fixed package - I just checked that the
number of failed packages didn't change. I'll rerun the list before
submitting the bugs. Sorry for the error.

-- 
"Le mieux est l'ennemi du bien" - Voltaire


--
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/caohcdnbtsenfu5gep79qzo1oeyfb+gkuojah6crzzgoyl1l...@mail.gmail.com

Re: [Piuparts-devel] Mass bug filing for shared library broken symlinks detected by piuparts

[Dave Steele]

On Wed, Jul 3, 2013 at 9:04 AM, Ian Jackson
 wrote:
>> Shortly, piuparts.debian.org will be elevating the broken symlink test
>> in sid from a warning to an error status. In advance of that, bugs
>> submissions are planned against packages which are responsible for
>> such links.
>
> I don't think this is a good idea.
>
>> These are sometimes triggered because a Recommended or reverse
>> dependency package owning the symlink target file is not yet
>> installed. This type of failure mode needs to be eliminated so
>> that other symlink problems become more visible. In this case,
>> the problem can be resolved by creating a trigger for the
>> target file. See the dpkg triggers documentation[1] and example
>> on the net[2] for implementation details.
>
> I think this should be dealt with by making the diagnosis more
> sophisticated, not by introducing substantial additional complexity
> into packages.  Alternatively, you should implement an override
> facility.
>
> There is IMO nothing wrong with package X containing a symlink to a
> file present in Y, if there is some plausible explanation and the
> broken link doesn't cause harmful behaviour on the user's system.
>
> If X recommends (or even suggests) Y this probably means that there is
> such an explanation, but it seems to me that this situation might
> occur even if there is no declared relationship between X and Y (for
> example, one of the packages might contain a plugin for the other,
> implemented by dropping a symlink into an appropriate directory).
>
> Ian.
>

Ok, here is my case. In short:

- My read of the Policy says that broken shared library symlinks
represent a violation.

- The 'override facility' would be problematic. The reliability of an
automated facility would be suspect (there is a reason that there is a
piuparts 'dependency-failed-testing' state instead of an automated
means to compensate for dependency failures). A manual facility
implies inspection of every release of affected packages.

- In either case, an explanation of, for instance, link X->Y is
resolved by installing Recommended package Z doesn't IMO answer the
question of whether or not the breakage is benign. Piuparts.d.o is the
wrong place to place this responsibility.

- IMO, creating broken symlinks is a bad practice.

The piuparts broken symlink test can find significant problems in
packages. For the test to be useful, the issues it finds need to be
addressed at 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/caohcdna1kd20so58b2eyf2eabz3ug9j2jyxv4m-oydsjlu+...@mail.gmail.com

Re: abi-compliance-checker and abi-dumper to track API/ABI

[Andrey Ponomarenko]

Markus Raab wrote:

Hello!

Andrey Ponomarenko wrote:

There is a new simple way to track changes in API/ABI of system
libraries using a new ABI dumper [1] tool.

Thanks for the tipp!


However, this approach has some drawbacks. Perhaps the main drawback is
the inability to perform some compatibility checks. For example, there
is no possibility to check for changes in the values of the constants
(defines as well as const global data), since their values are inlined
at compile time, and not presented in the debug information of the
binary ELF-object.

The major issue is that these tools cannot check behavioral or semantic
incompatibility. (typically is described in the API-doc)

I suggest to package unit test of an library as extra package and then try
to upgrade the library, but not the unit tests. When you execute the unit
tests then you will get an ABI check for free. It might even include
semantic incompatibility or checks of constant/macro/enum changes, depending
how extensive the unit tests are.


Agree. But not every library has a test suite. In this case one can try 
to automagically generate tests by the api-sanity-checker [1] tool.




I implemented this for elektra and it worked quite well, see
https://gitorious.org/elektra-
initiative/libelektra/blobs/debian/debian/control
(>= ${source:Version}) does the trick in libelektra-test.


In general, there can be checked about 98% of all
compatibility rules.

Is this number from your experience?


It's just about 98% from those collected during 4 years of development 
in the rules DB (194 binary-compatibility rules and 100 
source-compatibility rules):


  abi-compliance-checker-1.99.7/modules/Rules{Bin, Src}.xml



I would expect that real-life problems are rather more subtle.

best regards
Markus




[1] https://github.com/lvc/api-sanity-checker

--
Andrey Ponomarenko, ROSA Lab.


--
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/51d5652e.6080...@rosalab.ru

Re: Berkeley DB 6.0 license change to AGPLv3

[Vincent Lefevre]

On 2013-07-04 09:23:49 +0200, Stefano Zacchiroli wrote:
> I'm curious, can you elaborate on why as upstream you'd refuse to add
> something like a protocol command that return a URL pointing to a
> tarball containing the source code of the INN version the users are
> running? At times, I'm really surprised by the upfront opposition that
> AGPL could get in Free Software cycles and I'd like to understand more
> your motives as an upstream.

What about users who patch and rebuild software locally? What should
the URL be? (Note that a "file:" URL couldn't even be sufficient,
as some software, such as Subversion, can be used remotely without
a shell access, so that there may be no way to fetch a "file:" URL
without installing a new service.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130704120833.ga32...@ioooi.vinc17.net

Re: Berkeley DB 6.0 license change to AGPLv3

[Stefano Zacchiroli]

On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote:
> What about users who patch and rebuild software locally?

That was the second paragraph of my post (that you snipped :)), i.e.:

> I mean, sure, it *is* more tricky to provide such a URL for users that
> will be running a *modified* version of INN. But it is exactly the
> same kind of difficulties that people distributing modified copylefted
> software will have to face to uphold GPL (or equivalent) terms.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[David Weinehall]

On Wed, Jul 03, 2013 at 09:17:48PM +0200, Svante Signell wrote:
> On Tue, 2013-07-02 at 15:32 -0700, John H. Robinson, IV wrote:
> > 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.
> 
> The interesting thing is not when Linus used the GPL license the first
> time, it was v2 by then. Of crucial interest is when Linus changed from
> v2 or later to v2 only. And looking at the source code, e.g. 3.9.8, a
> very lot of files are still v2+, not v2 only. That's a very big
> difference.

http://lkml.org/lkml/2006/1/25/273


Kind regards, David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20130704143629.gd26...@hirohito.acc.umu.se

Re: Current and upcoming toolchain changes for jessie

[Julien Cristau]

On Thu, Jun 13, 2013 at 14:51:43 +0200, Matthias Klose wrote:

> Am 07.05.2013 15:25, schrieb Matthias Klose:
> > The decision when to make GCC 4.8 the default for other architectures is
> > left to the Debian port maintainers.
> [...]
> > Information on porting to GCC 4.8 from previous versions of GCC can be 
> > found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html
> > 
> > It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove
> > 4.4, 4.6 and 4.7 from jessie.
> 
> GCC 4.8 is now the default on all x86 architectures, and on all ARM
> architectures (the latter confirmed by the Debian ARM porters).  I did not get
> any feedback from other port maintainers, so unless this does change and port
> maintainers get involved with toolchain maintenance, the architectures staying
> at 4.6 or 4.7 shouldn't be considered for a successful release 
> (re-)qualification.
> 
FWIW, it looks like current glib2.0 is miscompiled on sparc with
gcc-4.6, and the issue goes away with 4.8.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#714950: ITP: python-libdiscid -- Python binding for libdiscid

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 

* Package name: python-libdiscid
  Version : 0.3
  Upstream Author : Sebastian Ramacher 
* URL : http://pypi.python.org/pypi/python-libdiscid
* License : Expat
  Programming Lang: Python, Cython, C
  Description : Python binding for libdiscid

libdiscid allows to create MusicBrainz DiscIDs from audio CDs. It reads
a CD's table of contents and generates and identifier which can be used
to lookup the CD a MusicBrainz (http://musicbrainz.org). This package
provides a binding to use libdiscid from Python.

This package is a dependency of the next release of picard.
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#714956: ITP: brickutils -- Utility for organizing your collection of LEGO(R) bricks

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* Package name: brickutils
  Version : 0.1.6.1
  Upstream Author : Mario Pascucci 
* URL : http://bricksnspace.wordpress.com/brickutils/
* License : GPL2+
  Programming Lang: Python
  Description : Utility for organizing your collection of LEGO(R) bricks

The main problem that BrickUtils tries to solve is to answer the question: can
I build this model with the bricks I own?

It allows one to import LEGO(R) models in different CAD formats (LDraw and
LEGO(R) Digital Designer) and check if one can build that model with the pieces
one owns. Parts lists can be exported in various formats, including printable
HTML or bricklink XML to easily buy missing pieces at bricklink.com.


-- 
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/20130704155436.14245.77281.reportbug@hoothoot

Re: Berkeley DB 6.0 license change to AGPLv3

[Bradley M. Kuhn]

Stefano Zacchiroli wrote at 03:14 (EDT):
> So, I wonder, do we have any idea (due to them having already been
> mentioned publicly elsewhere) about the craziest interpretation of
> AGPL that the "evil guys" might come up with and, at the other end of
> the spectrum, the most restrictive one?

> AFAIK AGPL hasn't been tested in court, yet.

I continue to believe that the "tested in Court" standard is highly
overrated.  It's useful, but it's not the litmus test.

The main issue is that very little non-litigation AGPLv3 enforcement has
ever happened, AFAIK.  Status.Net did some on its codebase; I've helped
do some on Pokersource's codebase.  Other than that, I'm not aware
of any.

> But I can't help wondering what people are really scared about here.

I think folks are scared because it's an unknown.  We've lived with
inappropriate GPLv2 aggression from companies like MySQL AB (now Oracle)
for at least a decade now, so we have a good sense of the tricks and
manipulations.

I think AGPLv3 is much better in this regard because it has GPLv3's much
more forgiving Termination provision

> Is it the quine scenario (IMHO ruled out by the license text, but
> obviously you never know...) that people fear to have to implement,
> worrying about the fact that simply providing URLs to tarballs wouldn't
> be considered enough?

... however, admittedly, AGPLv3 is a stronger copyleft than GPLv3
(requiring the thing that Stefano describes), and thus it's easier to
make minor violations, and a company like Oracle might get aggressive.

But, I agree with you Stefano: these worries are speculation based on
past behavior by Oracle, more than they are certainties, which is why I
think the fork-under-AGPLv3 proposal is enough of a hedge to prevent any
serious problems.  But that's a speculative remedy on my part about the
speculative problem herein discussed. :)
-- 
   -- bkuhn


-- 
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/87ppuyguwu@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Bradley M. Kuhn]

Ondřej Surý wrote at 06:29 (EDT):
> As far as I understand it – there are some parts in Berkeley DB source
> code which is just BSD licensed (and the copyright holders are those
> mentioned earlier)[1], then there are parts which were under SleepyCat
> license and presumably the copyright holder for those parts is Oracle
> – and those were relicensed to AGPLv3. (There are also mixed
> files[3].)

It's probably a good idea for someone to carefully verify these facts.
The community shouldn't assume Oracle got all this right.

> So, the AGPLv3 just needs to be compatible with 3-clause BSD license,
> which is the case.

...which it is, of course.


David Kalnischkies wrote at 17:43 (EDT) on Wednesday:
>> So, as I see wrong bits a few times in this thread now: a) APT is
>> GPL2+ licensed and will stay that way out of no other choice as I bet
>> its more likely that hell freezes over than that we track down every
>> contributor since 1997 to ask for an agreement for a license change …

If apt is GPLv2-or-later, you don't need copyright holder permission to
move to GPLv3-or-later, which permits you to combine with AGPLv3'd works
like BDB.

>> (yes, we could switch to GPL3+ "for free", but it's not like we
>> would gain anything from it

That's a matter of debate that I was pointing toward.  It's a policy
decision, and I understand fully why it might not be a good policy
decision for Debian for many reasons, including this one:

>>  – beside generating problems for GPL2-only dependees on libapt of
>>  course)

I'm curious, are there many of these?


> On 03/07/13 16:34, Bradley M. Kuhn wrote: [...]
>>> I know that some have complained that compliance with AGPLv3 may
>>> require more work by Debian redistributors.  That is a reasonable
>>> concern, but I think the issue can be mitigated.

MJ Ray wrote at 07:00 (EDT):
> OK, how?

I'm happy to engage in this discussion in detail if Debian decides to
keep the dependency on the AGPLv3'd library.  It sounds like consensus
might be approached that dropping BDB makes the most sense anyway (in
part for technical reasons anyway), so perhaps it will make this
situation moot.


I haven't spent much time helping people make compliance easy for
AGPLv3 -- even though I have some ideas about it -- simply because it's
(sadly) not much of a real-world problem yet, because so few people use
AGPLv3.  As AGPLv3 gets more popular (which I'd love to see), I'm happy
to devote more volunteer time to this to help Debian and others DTRT.

Keep in mind that AGPLv3 is a young license.  We've spent decades
figuring out the proper ways to make GPLv2 compliance easy.  Newer
licenses need just as long to gain good best practices.  It doesn't make
the new license bad, just new.
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy


--
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/878v1mgupn@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer]

* Stefano Zacchiroli:

> I mean, sure, it *is* more tricky to provide such a URL for users that
> will be running a *modified* version of INN. But it is exactly the same
> kind of difficulties that people distributing modified copylefted
> software will have to face to uphold GPL (or equivalent) terms.

We ship package building software which produces source and binary
packages.  You just copy all of them and are compliant.

We currently do not ship a licensing server that helps users with AGPL
compliance.

My main concern with the license is that compliance is difficult even
for those who have no problem whatsoever with sharing their boring
local changes.  I'm concerned that we're heading to the Linux (kernel)
land where Android and others have made GPL compliance a farce.


-- 
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/87r4fetfx7@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

[Bradley M. Kuhn]

Ondřej Surý wrote at 00:36 (EDT):
> (d) Is it ok to switch 106 source packages and their reverse depends
> to AGPLv3?

I think that might be stated a bit more clearly: you won't be changing
the license of the upstream works; you'd be changing the license of the
dowstream whole as it appears in Debian.  If the combination is done
during building the software, the license on the source itself doesn't
necessarily change: it's just that the binary is covered by AGPLv3,
which means you have to comply with AGPLv3 with regard to the binary
and its complete, corresponding source (which now includes both BDB
and the upstream sources).

That said, this is indeed an important question to consider, even if I'd
state it differently than Ondřej does.

> 1) I think this should be made with consent of upstream authors

In the GPLv2-only and/or AGPLv3-incompatible package cases, you do
indeed need such consent.  In the other cases, you probably don't.

I'd suspect, though, that Debian didn't *add* the BDB dependency to
those packages, but they already had it upstream anyway -- which means
those AGPLv3-incompatible upstream projects are reeling from this action
by Oracle too, and they'll likely independently switch to something
other than BDB anyway, which would solve the problem for Debian without
Debian needing to do any real work other than change some package
configurations.

> 2) We need to pick the Berkeley DB version compatible with all
> packages that use the library.

I think this is roughly the same issue as (1), unless you mean a
technical rather than a licensing issue.
-- 
   -- bkuhn


--
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/87a9m2e09x@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

On Thu, Jul 4, 2013 at 6:51 PM, Bradley M. Kuhn  wrote:

> > 2) We need to pick the Berkeley DB version compatible with all
> > packages that use the library.
>
> I think this is roughly the same issue as (1), unless you mean a
> technical rather than a licensing issue.


It is a more technical issue, but based on licensing issue. We need to pick
BDB version with license which is compatible with all packages that uses it.

O.
-- 
Ondřej Surý 

Re: Berkeley DB 6.0 license change to AGPLv3

[Vincent Lefevre]

On 2013-07-04 15:00:05 +0200, Stefano Zacchiroli wrote:
> On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote:
> > What about users who patch and rebuild software locally?
> 
> That was the second paragraph of my post (that you snipped :)), i.e.:
> 
> > I mean, sure, it *is* more tricky to provide such a URL for users that
> > will be running a *modified* version of INN. But it is exactly the
> > same kind of difficulties that people distributing modified copylefted
> > software will have to face to uphold GPL (or equivalent) terms.

OK, that was unclear. I thought you meant modified by Debian (as
opposed to an unpatched upstream version).

But providing a URL for a user who has few resources (no web site...)
is more difficult than providing the source (in a non-automatic way)
when requested, if this is what you had in mind. At least something
else would need to be done in addition to just patching, rebuilding
and installing the package.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130704214047.ga5...@ioooi.vinc17.net

Re: Berkeley DB 6.0 license change to AGPLv3

[Bálint Réczey]

2013/7/4 Ondřej Surý :
>
> On Thu, Jul 4, 2013 at 6:51 PM, Bradley M. Kuhn  wrote:
>>
>> > 2) We need to pick the Berkeley DB version compatible with all
>> > packages that use the library.
>>
>> I think this is roughly the same issue as (1), unless you mean a
>> technical rather than a licensing issue.
>
>
> It is a more technical issue, but based on licensing issue. We need to pick
> BDB version with license which is compatible with all packages that uses it.
Strictly regarding the technical problem I think Ben's suggestion would work:
2013/7/2 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.

We could keep libdb-dev for the fork keeping the current license and
create a new set of
development packages like libdb6-dev for the AGPLv3 code with or
without switching to an
upstream different from Oracle.

Packages depending on more liberally licensed Berkeley DB won't switch
automatically to
the AGPLv3 this way.

Cheers,
Balint


--
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/cak0odpxntt9luw+ys8s09zd2iv5p33vy_boexdaa3svfin+...@mail.gmail.com

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

[Jakub Wilk]

* David Weinehall , 2013-07-04, 16:36:

http://lkml.org/lkml/2006/1/25/273


http://lkml.org/lkml/2006/1/30/100

--
Jakub Wilk


--
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/20130704225807.ga6...@jwilk.net

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

[John Paul Adrian Glaubitz]

On 07/05/2013 12:58 AM, Jakub Wilk wrote:

* David Weinehall , 2013-07-04, 16:36:

http://lkml.org/lkml/2006/1/25/273


http://lkml.org/lkml/2006/1/30/100


Could you be a bit more elaborate please? I don't think we should just
spam this list by just sending mails containing URLs only.

If you want to express your opinion, please say something.

Adrian

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


--
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/51d6006b.6030...@physik.fu-berlin.de

Work-needing packages report for Jul 5, 2013

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 496 (new: 8)
Total number of packages offered up for adoption: 150 (new: 1)
Total number of packages requested help for: 60 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   capi4hylafax (#714691), orphaned 3 days ago
 Description: Faxing over CAPI 2.0 device
 Installations reported by Popcon: 92

   fcrackzip (#714749), orphaned 2 days ago
 Description: password cracker for zip archives
 Installations reported by Popcon: 763

   freewnn (#714683), orphaned 3 days ago
 Description: network-extensible Japanese/Chinese/Korean input system
 Reverse Depends: freewnn-cserver freewnn-jserver freewnn-kserver
   kinput2-canna-wnn kinput2-wnn
 Installations reported by Popcon: 99

   kakasi (#714656), orphaned 3 days ago
 Description: KAnji KAna Simple Inverter
 Reverse Depends: kakasi libkakasi2 libkakasi2-dev
   libtext-kakasi-perl ruby-kakasi
 Installations reported by Popcon: 848

   kinput2 (#714684), orphaned 3 days ago
 Description: input server for X11 applications that want Japanese
   text input
 Reverse Depends: kinput2-canna kinput2-canna-wnn kinput2-wnn
 Installations reported by Popcon: 129

   wmitime (#714747), orphaned 2 days ago
 Description: clock dock app showing time and internet time
 Installations reported by Popcon: 99

   wnn6-sdk (#714685), orphaned 3 days ago
 Description: network-extensible Kana-to-Kanji conversion system
 Reverse Depends: kinput2-canna-wnn kinput2-wnn libwnn6-dev
 Installations reported by Popcon: 898

   wuzzah (#714751), orphaned 2 days ago
 Description: inobtrusively monitor your friends
 Installations reported by Popcon: 15

488 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   windows-el (#714799), offered 2 days ago
 Description: window manager for GNU Emacs
 Installations reported by Popcon: 96

149 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1249 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 75765

   asymptote (#517342), requested 1588 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4532

   athcool (#278442), requested 3173 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 57

   balsa (#642906), requested 648 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 1212

   bastille (#592137), requested 1062 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 148

   cardstories (#624100), requested 801 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 11

   chromium-browser (#583826), requested 1131 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 17732

   cups (#532097), requested 1489 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-daemon cups-dbg cups-filters
   (58 more omitted)
 Installations reported by Popcon: 122256

   debtags (#567954), requested 1249 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2434

   fbcat (#565156), requested 1268 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 156

   flightgear (#487388), requested 1839 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 577

   freeipmi (#628062), requested 770 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfre

Re: ITP: qucs -- an integrated circuit simulator with a graphical user interface

[Andreas Tille]

Hi,

On Wed, Jul 03, 2013 at 04:10:17PM +0200, Bastien ROUCARIES wrote:
> Le 3 juil. 2013 14:50, "José Luis Redrejo Rodríguez" 
> a écrit :
> >
> > I've been maintaining qucs since 2004 to 2012, so I know this package
> pretty well and I have already prepared most part of its debianization. Did
> you fill an ITP ?
> > We can arrange a qucs maintaining group if you want.
> 
> We must first package adms*. I have an itp for it since one year and
> package under mentors.
> 
> I welcome a comainting under debian science if needed.

Thanks for bringing Debian Science up - otherwise I would have done
this.  Luis, Debian Science repositories (SVN or Git as you prefer) are
writable for any DD so you can commit straight to it.  The package is
also mentioned in Debian Science task electronics - so it perfectly fits
here.  I'd strongly recommend using Debian Science Vcs for packaging
because your work will show up on the Blends sentinel even before it is
uploaded.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20130705010706.ge25...@an3as.eu

Re: boot ordering and resolvconf

[Thomas Hood]

Ian Jackson wrote:
> I think the first thing to do is recognise the underlying problem.  To
> fix this problem properly we need a coherent system design.  The two
> designs lead to different sets of fixes.
>  
> A. resolv.conf is a static file which changes only very rarely.
>
> B. resolv.conf is not static and may change due to network
> environment changes.

The only underlying problem I know of is that ntpd is broken (#683061).
Other applications work fine in mode B.  And the reason that ntpd
doesn't work properly is NOT that resolv.conf is dynamic. Ntpd doesn't
work properly because it treats any name resolution failure as
equivalent to "host does not exist" and treats "host does not exist" as
a fatal error.  So ntpd will also fail in mode A unless you manage to get
name service fully operational before ntpd starts.  Merely pointing
/etc/resolv.conf at a local nameserver does not rule out the possibility
of name service failures; it just ensures that applications can access
some nameserver once the local nameserver has started.  That's nice
but it doesn't fix ntpd. Lookups will still fail, e.g., if ntpd starts before 
the
nameserver or if the nameserver doesn't have a forwarding address yet.

Applications have to be able to deal with temporary name service failures.

The assumptions that got this thread started were made here:
Helmut Grohne wrote:
> Usually any program reads
> /etc/resolv.conf once on the first DNS lookup. So all daemons started
> before the local DNS cache will either use a different server, or fail
> DNS resolution in all cases. A minority of services (avahi-daemon,
> fetchmail, postfix, sendmail, squid, and squid3) hook into resolvconf to
> reload their daemons when /etc/resolv.conf is changed by resolvconf.
> These daemons will not be affected by this problem. Many other services
> on the other hand will.

This is an as-yet unsubstantiated claim. Libc resolver clients generally
re-read resolv.conf every time it changes. Are there known examples
of programs that fail to do so?


Ian Jackson wrote:
> Is there some reason not to use dnsmasq for this ?
>
> To do this we would have to:
>   * install dnsmasq by default
>   * teach resolvconf to update dnsmasq's config rather than
>  resolv.conf (but apparently Ubuntu have done this work)
>   * make sure that the full-on DNS servers all conflict with
> dnsmasq and listen on 127.0.0.1
>
> Policy would say:
>   * By default resolv.conf should contain only 127.0.0.1
>   * No package may update resolv.conf's nameserver settings
>   * All nameserver packages should conflict with dnsmasq (perhaps
> via a specified virtual-package) and must provide general
> nameservice on 127.0.0.1.
>   * Nameserver packages and network configuration packages should
> use resolvconf to communicate the actual nameservers, if they wish
> to do this.  (Support for this is not required by policy, but
> if support is provided this is how it should be done.)

It's worth discussing what Debian should install and run by default.
Ubuntu Server installs resolvconf by default. Ubuntu Desktop
installs resolvconf, NetworkManager and dnsmasq-base by
default: NetworkManager runs an instance of dnsmasq as a
forwarding nameserver.

But there is no need to introduce new restrictions and policy
unless, perhaps, it does turn out that large numbers of libc
resolver clients need to be modified, which so far as I know is
not the case.
-- 
Thomas Hood

Re: Updating /etc/hosts automatically / behavior of sed command

[Tad Frank]

Your issue lies in the line: sed -e "s/$REGISTERED_IP/$CURRENT_IP/g"
/etc/hosts > /etc/hosts.new
 
Take a look at the modification I made below, it should help.
 

if [ $CURRENT_IP != $REGISTERED_IP ] ; then

   echo -n "IP address has changed: creating a new /etc/hosts file"

   sed -i.old "s/$REGISTERED_IP/$CURRENT_IP/g" /etc/hosts

   echo "."

else

   echo "IP address hasn't changed: no update needed."

fi

 
Hope this helps.
 
~Tad

 

Bug#714983: ITP: python-ordereddict -- drop-in substitute for Python 2.7's new collections.OrderedDict

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-ordereddict
  Version : 1.1
  Upstream Author : Raymond Hettinger
* URL : https://pypi.python.org/pypi/ordereddict
* License : MIT
  Programming Lang: Python
  Description : drop-in substitute for Python 2.7's new 
collections.OrderedDict

 Drop-in substitute for Py2.7's new collections.OrderedDict. The recipe has
 big-oh  performance that matches regular dictionaries (amortized O(1)
 insertion/deletion/lookup and O(n) iteration/repr/copy/equality_testing).
 .
 Originally based on http://code.activestate.com/recipes/576693/


-- 
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/20130705063358.6262.3860.report...@buzig.gplhost.com