adequate now reports incompatible-licenses - need help to verify and file bugs

[Andreas Beckmann]

Hi,

I just noticed in my local piuparts instance that adequate now issues 
incompatible-licenses tags, too. Nice feature, Jakub! :-)

Since I'm not too familiar with these issues, i'd like to see that 
someone with more experience in that area verifies these problems and 
files the corresponding RC bugs.

For sid I've seen so far:

  ice34-services: incompatible-licenses /usr/bin/icegridadmin GPLv2+ 
(libreadline.so.5) + OpenSSL (libssl.so.1.0.0)
  
  libcitygml0:amd64: incompatible-licenses 
/usr/lib/x86_64-linux-gnu/libcitygml.so.0.0.0 GPLv2 (libpoppler.so.19) + 
OpenSSL (libssl.so.1.0.0)

  ccbuild: incompatible-licenses /usr/bin/ccbuild GPLv3+ 
(libgnutls-openssl.so.27) + OpenSSL (libcrypto.so.1.0.0)

  coop-computing-tools: incompatible-licenses /usr/bin/chirp GPLv3+ 
(libreadline.so.6) + OpenSSL (libssl.so.1.0.0)

  osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+ 
(libgnutls.so.26) + GPLv2 (libpoppler.so.19)
  osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+ 
(libgnutls.so.26) + GPLv2 (libpoppler.so.19)
  osgearth: incompatible-licenses /usr/bin/osgearth_version LGPLv3+ 
(libgnutls.so.26) + GPLv2 (libpoppler.so.19)
  osgearth: incompatible-licenses /usr/bin/osgearth_viewer LGPLv3+ 
(libgnutls.so.26) + GPLv2 (libpoppler.so.19)

  tellico: incompatible-licenses /usr/bin/tellico GPLv2 (libpoppler.so.19) + 
LGPLv3+ (libgnutls.so.26)


@Holger: this requires adequate 0.7 - is that running on the slave?
If yes, please reschedule above logs - and maybe create a report for it.


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/51dd0bd7.9080...@debian.org

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

[Andrey Ponomarenko]

Paul Wise wrote:

I'm subscribed, no need to CC me.

On Tue, Jul 9, 2013 at 7:07 PM, Dmitrijs Ledkovs wrote:


One of the "library descriptors" that a-c-c supports is a list of
includes/directories.
Thus for $most packages just installing -dev package and pointing
a-c-c at the list of:
dpkg -L $pkg-dev | grep include lib
should do the right thing (more or less)

How would I feed that to a-c-c?


There is a simple Perl script to do that:

my $Package = $ARGV[0];

open(INFO, "dpkg -L $Package |");

my (@Libs, @Headers) = ();

while()
{
chomp($_);
if(/\/lib(|64)\// and /\.so(\Z|\W)/) {
push(@Libs, $_);
}
if(/\/include\// and $_ ne "/usr/include") {
push(@Headers, $_);
}
}

my $Version = `dpkg -s $Package|grep Version`;
chomp($Version);
$Version=~s/\AVersion:\s*//g;

print "

$Version



".join("\n", @Headers)."



".join("\n", @Libs)."

";


Run this script as:

perl script.pl package-dev

For example, it prints the following for libgrip-dev:


0.3.5-0ubuntu1~12.04.1



/usr/include/libgrip
/usr/include/libgrip/grip.h
/usr/include/libgrip/gripinputdevice.h
/usr/include/libgrip/gripgesturemanager.h



/usr/lib/libgrip.so





But I haven't gotten far enough to have this working automagically as
dep8 tests.

DEP-8 tests are per-package, I want something that would work for
every package that includes a library+headers.



--
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/51dd1689.8070...@rosalab.ru

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

[Paul Wise]

On Wed, Jul 10, 2013 at 4:08 PM, Andrey Ponomarenko wrote:

> There is a simple Perl script to do that:

Thanks, what about including this capability in a-c-c itself?

> my $Version = `dpkg -s $Package|grep Version`;
> chomp($Version);
> $Version=~s/\AVersion:\s*//g;

This would be better:

dpkg-query -W -f='${Version}' $Package

-- 
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/CAKTje6G1YemXb+tNYEUi_vZu-HSpRXQc98o=e5eX5=xt-p4...@mail.gmail.com

Re: adequate now reports incompatible-licenses - need help to verify and file bugs

[Holger Levsen]

Hi Andreas,

On Mittwoch, 10. Juli 2013, Andreas Beckmann wrote:
> I just noticed in my local piuparts instance that adequate now issues
> incompatible-licenses tags, too. Nice feature, Jakub! :-)

indeed!
 
> @Holger: this requires adequate 0.7 - is that running on the slave?

nope, there is only 0.6 in stable-backports, so... Jakub, can you please 
update 0.7 to bpo?! TIA! :)


cheers,
Holger


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

License for the Raspberry PI

[Tobias.Harzen]

Dear Ladies and Gentlemen,

I'm a master-student of the "Hochschule Bonn-Rhein-Sieg" and I'm working at a 
project with the DLR (Deutsches Zentrum für Luft- und Raumfahrt). In the 
project I want to develop a datalogger-system with the Raspberry PI. The 
Raspberry PI works with the software Raspbian and there is installed your 
operating system Debian. My question is: Do I need a license for the software 
to develop in a company?

With kind regards,

Tobias Harzen

Re: License for the Raspberry PI

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013-07-10 10:39, tobias.har...@dlr.de wrote:
> The Raspberry PI works with the software Raspbian and there is
> installed your operating system Debian. My question is: Do I need a
> license for the software to develop in a company?

No but if you change components in the actual distribution you have to
comply with the license of the component you changed.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJR3ShqAAoJEJbdSEaj0jV7WmcH+QHtJxXUa+UHrbiXBeMXvOOk
kTEXbSZ+7JOb6XptfePdFf27xitG+gRXR0zrFi7r8OTbc/pTqbdc6aZO648Al54h
FK74w+85kiZlwxgjFEo0Du92S7cvR4IX2mhtN6ju5PNp875haIXMjZrfexp+8O87
PzP9zM4m6jQeL4B8vHL2fhcfXnWqZ34458JOvTrulxJLryPchOqIlPf69iyrs1SV
jZ/zZODDH9lUxGUYweQjzL4pst3776KiH3bCRpZWFPa2qF760Hcdvk1ztiOsYN4h
xuNgbxRnjlqccDHiW5D9LP9+ZIam2Y09X8Uchmqmnv+Ea7FEVLpDwEwk0Q4SY9Y=
=9Kdy
-END PGP SIGNATURE-


-- 
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/51dd286a.3060...@bsnet.se

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

[Dmitrijs Ledkovs]

On 10 July 2013 09:20, Paul Wise  wrote:
> On Wed, Jul 10, 2013 at 4:08 PM, Andrey Ponomarenko wrote:
>
>> There is a simple Perl script to do that:
>
> Thanks, what about including this capability in a-c-c itself?
>

I'd take a patch to dh-acc ;-)

>> my $Version = `dpkg -s $Package|grep Version`;
>> chomp($Version);
>> $Version=~s/\AVersion:\s*//g;
>
> This would be better:
>
> dpkg-query -W -f='${Version}' $Package
>
> --
> 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/CAKTje6G1YemXb+tNYEUi_vZu-HSpRXQc98o=e5eX5=xt-p4...@mail.gmail.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/canbhluivgsonazfs-97pfrjkgnz-bqrw5x7kcrcoyogrpbx...@mail.gmail.com

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

[Paul Wise]

On Wed, Jul 10, 2013 at 6:30 PM, Dmitrijs Ledkovs wrote:

> I'd take a patch to dh-acc ;-)

Including it in dh-acc isn't interesting since that is a per-package
thing (AFAICT). For instance if the release team wanted to do an
archive-wide ABI check and automatically block libraries based on that
information, using dh-acc for that isn't going to work.

PS: no need to CC me.

-- 
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/caktje6gyru9n2nmcpmu7u5gtfkk8c0hu9mykp9+213bfgsx...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Stefano Zacchiroli]

On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
> No, there is a really important difference. With GPL you only have to be
> careful when you give binaries to anyone, that you also give the source.
> This is a bit of a hassle, but worst case means that you cannot help
> others with the software changes you have done (bad enough but worth the
> hassle to have the source) if you miss some of the sources. But if the
> sources may contain any passwords or other internal data you cannot/do
> not want to share, so will likely the binary so that is no difference.

On this level, the analogy GPL/AGPL still seems correct to me.

A software distributed under AGPL will likely come with mechanisms
already in place to point to its source code --- that might not be the
case today yet, due to the scarce popularity of AGPL, but that's a
separate matter.  That means that you can easily run unmodified version
of an AGPL'd program, for any purpose, without particular restrictions.

If you modify the software you might get in trouble but, according to my
personal ethics, that's the trouble you should have. However, please
note that as long as you run the software only for yourself, you don't
have any problem. You might encounter problems only in the case you've
modified the software, you want *others* to use it over the net, and you
don't provide the source code that include your modifications.

That shift is coherent with the shift in the most common deployment
pattern for software: handing software copies in the past, using remote
services over the net nowadays.

(Anyway, here we're getting quite off-topic...)

-- 
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: adequate now reports incompatible-licenses - need help to verify and file bugs

[Sune Vuorela]

On 2013-07-10, Andreas Beckmann  wrote:
>   osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+ 
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
>   osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+ 
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
>   osgearth: incompatible-licenses /usr/bin/osgearth_version LGPLv3+ 
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
>   osgearth: incompatible-licenses /usr/bin/osgearth_viewer LGPLv3+ 
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
>
>   tellico: incompatible-licenses /usr/bin/tellico GPLv2 (libpoppler.so.19) + 
> LGPLv3+ (libgnutls.so.26)

No need to file these. Poppler is going GPLv2+3 once next upstream lands
in debian.

/Sune


-- 
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/slrnktqj4m.j8.nos...@sshway.ssh.pusling.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Scott Kitterman]

On Wednesday, July 10, 2013 01:06:47 PM Stefano Zacchiroli wrote:
> On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
> > No, there is a really important difference. With GPL you only have to be
> > careful when you give binaries to anyone, that you also give the source.
> > This is a bit of a hassle, but worst case means that you cannot help
> > others with the software changes you have done (bad enough but worth the
> > hassle to have the source) if you miss some of the sources. But if the
> > sources may contain any passwords or other internal data you cannot/do
> > not want to share, so will likely the binary so that is no difference.
> 
> On this level, the analogy GPL/AGPL still seems correct to me.
> 
> A software distributed under AGPL will likely come with mechanisms
> already in place to point to its source code --- that might not be the
> case today yet, due to the scarce popularity of AGPL, but that's a
> separate matter.  That means that you can easily run unmodified version
> of an AGPL'd program, for any purpose, without particular restrictions.
> 
> If you modify the software you might get in trouble but, according to my
> personal ethics, that's the trouble you should have. However, please
> note that as long as you run the software only for yourself, you don't
> have any problem. You might encounter problems only in the case you've
> modified the software, you want *others* to use it over the net, and you
> don't provide the source code that include your modifications.
> 
> That shift is coherent with the shift in the most common deployment
> pattern for software: handing software copies in the past, using remote
> services over the net nowadays.
> 
> (Anyway, here we're getting quite off-topic...)

Sorry, I can't quite let this pass.  I just went and looked at the AGPL v3 
again and one implication of the license is that you can't locally fix a 
security issue without immediate disclosure.  This doesn't fit my personal 
ethics at all and at least IMO makes it pretty unsuitable as a license for any 
network facing service.

Scott K

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

Re: Berkeley DB 6.0 license change to AGPLv3

[Adam Borowski]

On Wed, Jul 10, 2013 at 08:18:12AM -0400, Scott Kitterman wrote:
> Sorry, I can't quite let this pass.  I just went and looked at the AGPL v3 
> again and one implication of the license is that you can't locally fix a 
> security issue without immediate disclosure.  This doesn't fit my personal 
> ethics at all and at least IMO makes it pretty unsuitable as a license for 
> any 
> network facing service.

You can!

There is just one caveat: you must make sure to never, ever, distribute that
piece of software, because once you do, you permanently lose your right to
use it without obnoxious and potentially crippling restrictions.

That's section 9 of AGPL v3.

So we have non-redistributable software in the main archive.  The
alternative you are allowed to ("accepting the license") can't be
considered free, as it outright violates FSF's freedom 0 (The freedom
to run the program, for any purpose) and DFSG 6 (No discrimination
against fields of endeavor).  AGPLed code can't be used for pretty
much anything that's neither a web service nor restricted solely to
a single computer.

As already mentioned in so many places, interesting banned uses include
reusing any part of the code in:
* a POP3/IMAP server
* an IRC bot that doesn't spam every user with legal messages
* a SMS/etc service
* a kiosk
* a wifi-connected lift control (don't laugh, I've seen one at Google)

Per section 13, any derived software that "supports remote interaction
through a computer network" must present a prominent offer to every user,
no matter if that's feasible or possible.  And this applies even if you
lift just several lines of code, even ancillary.  For example, two of my
personal projects include autoconfage that detects the way of spawning
ptys, copied from GNU screen, without using any part of screen proper.
Even such a minor code reuse is effectively banned by the AGPL -- both
of those projects include networking, and only one can reasonably present
an URL to its users.

The official FTPmaster response came in #495721, and it doesn't even
mention this issue, only three minor points (cost of running a webserver
with sources, private use, contaminating reverse dependencies).
Thus, could someone please explain, are there any arguments that
forbidding reuse with any protocols that don't support sending bulk
ancillary text would be free?  What I can see are debian-legal threads
considering AGPL to be non-free, and, in other places like the FTPmasters
response, avoiding this issue.

That it's uncomfortable doesn't make it any less valid.  The archive
carries a non-free section just for cases like this.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130710135003.ga5...@angband.pl

Debian policy for web apps still references /doc as accessible

[Thomas Goirand]

Hi,

Not sure who/where I should send this, or how I can update the policy
manual myself, but this document:
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl

still references /doc as being accessible (point 3 of chapter 11.5),
even though this feature has been removed for security reasons.

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/51dd69b5.6060...@debian.org

Re: [Popcon-developers] Encrypted popcon submissions

[Bill Allombert]

On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote:
> 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!

Indeed, I receive much more encrypted report now.

A bug I like to fix before enabling encryption by default is #714917:
gpg is creating a directory /root/gnupg with various files which are
essentially useless since popcon do not perform any signature checks.

I do not know how to fix this bug short of creating a dummy GPGHOME
directory with useless files.
Any help welcome!

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/20130710141402.GA18996@yellowpig

Re: Debian policy for web apps still references /doc as accessible

[Thijs Kinkhorst]

On Wed, July 10, 2013 16:03, Thomas Goirand wrote:
> Not sure who/where I should send this, or how I can update the policy
> manual myself,

I think you're looking for http://wiki.debian.org/Teams/Policy, which
describes the points of contact and the change process of Debian Policy.


Cheers,
Thijs


-- 
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/be8a61086411dd1aaf09074b19706a8a.squir...@aphrodite.kinkhorst.nl

Re: Debian policy for web apps still references /doc as accessible

[Holger Levsen]

Hi Thomas,

On Mittwoch, 10. Juli 2013, Thomas Goirand wrote:
> Not sure who/where I should send this, or how I can update the policy
> manual myself, but this document:

please file a bug against the debian-policy package.


cheers,
Holger


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

Re: License for the Raspberry PI

[Wouter Verhelst]

On 10-07-13 11:24, Martin Bagge / brother wrote:
> On 2013-07-10 10:39, tobias.har...@dlr.de wrote:
>> The Raspberry PI works with the software Raspbian and there is
>> installed your operating system Debian. My question is: Do I need a
>> license for the software to develop in a company?
> 
> No but if you change components in the actual distribution you have to
> comply with the license of the component you changed.

To clarify: yes, there is a license and yes, you do need to comply with
it. However, none of the Debian components have licenses that require
you to pay for use or modification of the software, or forbid you to use
it for any purpose you see fit (exception: if you have enabled the
non-free repository, which is not part of Debian proper, the license may
forbid you to use the software for some particular purpose).

The exact license for each package, with the requirements that you need
to comply with, can be found in the file /usr/share/doc//copyright.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51dd75f3.1050...@debian.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Bastian Blank]

On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> There is just one caveat: you must make sure to never, ever, distribute that
> piece of software, because once you do, you permanently lose your right to
> use it without obnoxious and potentially crippling restrictions.

Not right. You have to allow _access_ to it via a computer network.

> That's section 9 of AGPL v3.

Please read section 9 of GPL v3, it is identical.

> Per section 13, any derived software that "supports remote interaction
> through a computer network" must present a prominent offer to every user,
> no matter if that's feasible or possible.

You miss a vital part of this sentence: "(if your version supports such
interaction)". Please quote complete sentences if you try to proof
something.

> The official FTPmaster response came in #495721, and it doesn't even
> mention this issue, only three minor points (cost of running a webserver
> with sources, private use, contaminating reverse dependencies).

GPL also contaminates its reverse dependencies. So what? Okay, in this
case you actually have to do something for it.

> Thus, could someone please explain, are there any arguments that
> forbidding reuse with any protocols that don't support sending bulk
> ancillary text would be free?

Okay, you did not read it.

Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4


-- 
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/20130710150320.gb8...@mail.waldi.eu.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Scott Kitterman]

On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
> On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> > There is just one caveat: you must make sure to never, ever, distribute
> > that piece of software, because once you do, you permanently lose your
> > right to use it without obnoxious and potentially crippling restrictions.
> 
> Not right. You have to allow _access_ to it via a computer network.
> 
> > That's section 9 of AGPL v3.
> 
> Please read section 9 of GPL v3, it is identical.
> 
> > Per section 13, any derived software that "supports remote interaction
> > through a computer network" must present a prominent offer to every user,
> > no matter if that's feasible or possible.
> 
> You miss a vital part of this sentence: "(if your version supports such
> interaction)". Please quote complete sentences if you try to proof
> something.
> 
> > The official FTPmaster response came in #495721, and it doesn't even
> > mention this issue, only three minor points (cost of running a webserver
> > with sources, private use, contaminating reverse dependencies).
> 
> GPL also contaminates its reverse dependencies. So what? Okay, in this
> case you actually have to do something for it.

It's precisely the forced distribution of modifications that makes it 
unsuitable for any use that is any way security sensitive.  If you take a 
GPLv3 web server (as an example) and it is built by your distributor against 
the AGPL libdb version, the combined work is effectively AGPL, which means if 
you use a local security fix on your web server, you've violated the terms 
under which you've received the code.  Totally unsuitable.  It doesn't matter 
if libdb supports network interaction or not.

Scott K


-- 
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/4241872.WOu7pss5Jc@scott-latitude-e6320

Bug#715684: ITP: libconfig-ini-reader-ordered-perl -- .ini-file parser that returns sections in order

[gregor herrmann]

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

* Package name: libconfig-ini-reader-ordered-perl
  Version : 0.011
  Upstream Author : Hans Dieter Pearcey 
* URL : https://metacpan.org/release/Config-INI-Reader-Ordered/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : .ini-file parser that returns sections in order

Config::INI::Reader::Ordered is a subclass of Config::INI::Reader which
preserves section order. See Config::INI::Reader (in the libconfig-ini-perl
package) for all documentation.


-- 
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/20130710152822.ga15...@jadzia.comodo.priv.at

Re: License for the Raspberry PI

[Jonas Smedegaard]

Quoting Wouter Verhelst (2013-07-10 16:55:47)
> On 10-07-13 11:24, Martin Bagge / brother wrote:
> > On 2013-07-10 10:39, tobias.har...@dlr.de wrote:
> >> The Raspberry PI works with the software Raspbian and there is 
> >> installed your operating system Debian. My question is: Do I need a 
> >> license for the software to develop in a company?
> > 
> > No but if you change components in the actual distribution you have 
> > to comply with the license of the component you changed.
> 
> To clarify: yes, there is a license and yes, you do need to comply 
> with it. However, none of the Debian components have licenses that 
> require you to pay for use or modification of the software, or forbid 
> you to use it for any purpose you see fit (exception: if you have 
> enabled the non-free repository, which is not part of Debian proper, 
> the license may forbid you to use the software for some particular 
> purpose).
> 
> The exact license for each package, with the requirements that you 
> need to comply with, can be found in the file 
> /usr/share/doc//copyright.

...and to clarify further: Debian is *not* the same as Raspbian.

You need to ask those who created and distributed the system that you 
used.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#715792: ITP: libdevel-overrideglobalrequire-perl -- module to safely override CORE::GLOBAL::require

[gregor herrmann]

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

* Package name: libdevel-overrideglobalrequire-perl
  Version : 0.001
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Devel-OverrideGlobalRequire/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to safely override CORE::GLOBAL::require

Devel::OverrideGlobalRequire overrides CORE::GLOBAL::require with a code
reference in a way that plays nice with any existing overloading and ensures
the right calling package is in scope.


-- 
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/20130710154800.ga2...@jadzia.comodo.priv.at

Re: Berkeley DB 6.0 license change to AGPLv3

[Adam Borowski]

On Wed, Jul 10, 2013 at 05:03:20PM +0200, Bastian Blank wrote:
> On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> > There is just one caveat: you must make sure to never, ever, distribute that
> > piece of software, because once you do, you permanently lose your right to
> > use it without obnoxious and potentially crippling restrictions.
> 
> Not right. You have to allow _access_ to it via a computer network.

Which you can do without distributing the code, thus accepting the license
is not required.  You can _run_ the code you received, just not distribute
it to third parties.

> > That's section 9 of AGPL v3.
> 
> Please read section 9 of GPL v3, it is identical.

Yes, you can run code under regular GPL without accepting is as well; which
is a moot point as the GPL contains no use restrictions.

> > Per section 13, any derived software that "supports remote interaction
> > through a computer network" must present a prominent offer to every user,
> > no matter if that's feasible or possible.
> 
> You miss a vital part of this sentence: "(if your version supports such
> interaction)".

An IMAP server does support remote interaction through a computer network.

> Please quote complete sentences if you try to proof something.

I did, replacing the word "such" with the definition it refers to, mentioned
before the text I quoted.

> > The official FTPmaster response came in #495721, and it doesn't even
> > mention this issue, only three minor points (cost of running a webserver
> > with sources, private use, contaminating reverse dependencies).
> 
> GPL also contaminates its reverse dependencies. So what? Okay, in this
> case you actually have to do something for it.

Any license without a linking exception contaminates parts that rely on it,
and so does copying fragments of code.  You include a single function under
a BSD license?  You need to fulfill its requirements, ie keep the notices,
forever, as long as you keep including that function.  That's why this is
not a relevant argument against AGPL  But none of the above three points
are what I'm talking about here.

> > Thus, could someone please explain, are there any arguments that
> > forbidding reuse with any protocols that don't support sending bulk
> > ancillary text would be free?
> 
> Okay, you did not read it.

What?

Please point me to any other license in main that has an _use_ restriction. 
You often have to jump through hops as for what kind of modifications remain
distributable, but no DFSG-free license restricts:
* local modifications
* use


-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130710155647.ga7...@angband.pl

Bug#715794: ITP: libclass-refresh-perl -- module for refreshing classes during runtime

[gregor herrmann]

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

* Package name: libclass-refresh-perl
  Version : 0.05
  Upstream Author : Jesse Luehrs 
* URL : https://metacpan.org/release/Class-Refresh/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for refreshing classes during runtime

Class::Refresh allows you to reload your application classes on the fly, so
that the code/test cycle becomes a lot easier.

During development, it is fairly common to cycle between writing code and
testing that code. Generally the testing happens within the test suite, but
frequently it is more convenient to test things by hand when tracking down a
bug, or when doing some exploratory coding. In many situations, however, this
becomes inconvenient - for instance, in a REPL, or in a stateful web
application, restarting from the beginning after every code change can get
pretty tedious.


-- 
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/20130710162226.ga2...@jadzia.comodo.priv.at

Bug#715798: ITP: libreply-perl -- lightweight extensible Perl REPL

[gregor herrmann]

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

* Package name: libreply-perl
  Version : 0.26
  Upstream Author : Jesse Luehrs 
* URL : https://metacpan.org/release/Reply/
* License : Expat
  Programming Lang: Perl
  Description : lightweight extensible Perl REPL

Reply ("read, eval, print, loop, yay!") is a lightweight, extensible REPL for
Perl. It is plugin-based (see Reply::Plugin), and through plugins supports
many advanced features such as coloring and pretty printing, readline
support, and pluggable commands.

NOTE: This is an early release, and implementation details of this module are
still very much in flux. Feedback is welcome!


-- 
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/20130710163506.ga28...@jadzia.comodo.priv.at

Re: Berkeley DB 6.0 license change to AGPLv3

[Clint Byrum]

Excerpts from Scott Kitterman's message of 2013-07-10 08:28:54 -0700:
> On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
> > On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> > > There is just one caveat: you must make sure to never, ever, distribute
> > > that piece of software, because once you do, you permanently lose your
> > > right to use it without obnoxious and potentially crippling restrictions.
> > 
> > Not right. You have to allow _access_ to it via a computer network.
> > 
> > > That's section 9 of AGPL v3.
> > 
> > Please read section 9 of GPL v3, it is identical.
> > 
> > > Per section 13, any derived software that "supports remote interaction
> > > through a computer network" must present a prominent offer to every user,
> > > no matter if that's feasible or possible.
> > 
> > You miss a vital part of this sentence: "(if your version supports such
> > interaction)". Please quote complete sentences if you try to proof
> > something.
> > 
> > > The official FTPmaster response came in #495721, and it doesn't even
> > > mention this issue, only three minor points (cost of running a webserver
> > > with sources, private use, contaminating reverse dependencies).
> > 
> > GPL also contaminates its reverse dependencies. So what? Okay, in this
> > case you actually have to do something for it.
> 
> It's precisely the forced distribution of modifications that makes it 
> unsuitable for any use that is any way security sensitive.  If you take a 
> GPLv3 web server (as an example) and it is built by your distributor against 
> the AGPL libdb version, the combined work is effectively AGPL, which means if 
> you use a local security fix on your web server, you've violated the terms 
> under which you've received the code.  Totally unsuitable.  It doesn't matter 
> if libdb supports network interaction or not.
> 

Clause 13 again:

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

First off, I think the AGPL is far too vague and fails at its goals of
assuring user freedom when interacting with software over the net. If the
goal was to make sure web apps like MediaGoblin and Wordpress weren't
turned into big commercial services without giving the code back to
the users, then specific clauses would have made a lot more sense. The
vagueness of the "interacting with it remotely through a computer network"
part is particulary frustrating and has led to the AGPL being a tool
for legal bludgeoning.

Given the scenario Scott brings up above, AGPL for a webserver would be
a disaster. Thus, any plumbing/libraries/etc. are really bad candidates
for AGPL. This rather subtle imbalance is why MongoDB being AGPL leads to
10gen being able to "shake down" commercial entities who use MongoDB. They
may have thought they were getting Free software, but suddenly they have
to start considering whether or not they have to provide the source for
whatever version of MongoDB they might be running. Legally one could make
an argument that their proprietary webapp is just acting as a proxy for
the users to interact with MongoDB.

I'm not saying that argument is right, and I am not a lawyer, but I do
know that lawyers hate vagueness for this exact reason.

I do think AGPL complies with all of the clauses of the DFSG. There is
very little difference in an AGPLv3 licensed library as a GPLv3 licensed
library. Before linking, one must always check the library license. If
we do let BDB 6.0 into Debian with its new AGPL license, it is on the
BDB maintainer(s) to file RC bugs in the reverse dependencies to help
maintainers avoid accidentally shipping AGPL licensed binaries that are
not in compliance with 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/1373472124-sup-4...@fewbar.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Scott Kitterman]

On Wednesday, July 10, 2013 09:20:37 AM Clint Byrum wrote:
> Excerpts from Scott Kitterman's message of 2013-07-10 08:28:54 -0700:
> > On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
> > > On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> > > > There is just one caveat: you must make sure to never, ever,
> > > > distribute
> > > > that piece of software, because once you do, you permanently lose your
> > > > right to use it without obnoxious and potentially crippling
> > > > restrictions.
> > > 
> > > Not right. You have to allow _access_ to it via a computer network.
> > > 
> > > > That's section 9 of AGPL v3.
> > > 
> > > Please read section 9 of GPL v3, it is identical.
> > > 
> > > > Per section 13, any derived software that "supports remote interaction
> > > > through a computer network" must present a prominent offer to every
> > > > user,
> > > > no matter if that's feasible or possible.
> > > 
> > > You miss a vital part of this sentence: "(if your version supports such
> > > interaction)". Please quote complete sentences if you try to proof
> > > something.
> > > 
> > > > The official FTPmaster response came in #495721, and it doesn't even
> > > > mention this issue, only three minor points (cost of running a
> > > > webserver
> > > > with sources, private use, contaminating reverse dependencies).
> > > 
> > > GPL also contaminates its reverse dependencies. So what? Okay, in this
> > > case you actually have to do something for it.
> > 
> > It's precisely the forced distribution of modifications that makes it
> > unsuitable for any use that is any way security sensitive.  If you take a
> > GPLv3 web server (as an example) and it is built by your distributor
> > against the AGPL libdb version, the combined work is effectively AGPL,
> > which means if you use a local security fix on your web server, you've
> > violated the terms under which you've received the code.  Totally
> > unsuitable.  It doesn't matter if libdb supports network interaction or
> > not.
> 
> Clause 13 again:
> 
> "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."
> 
> First off, I think the AGPL is far too vague and fails at its goals of
> assuring user freedom when interacting with software over the net. If the
> goal was to make sure web apps like MediaGoblin and Wordpress weren't
> turned into big commercial services without giving the code back to
> the users, then specific clauses would have made a lot more sense. The
> vagueness of the "interacting with it remotely through a computer network"
> part is particulary frustrating and has led to the AGPL being a tool
> for legal bludgeoning.
> 
> Given the scenario Scott brings up above, AGPL for a webserver would be
> a disaster. Thus, any plumbing/libraries/etc. are really bad candidates
> for AGPL. This rather subtle imbalance is why MongoDB being AGPL leads to
> 10gen being able to "shake down" commercial entities who use MongoDB. They
> may have thought they were getting Free software, but suddenly they have
> to start considering whether or not they have to provide the source for
> whatever version of MongoDB they might be running. Legally one could make
> an argument that their proprietary webapp is just acting as a proxy for
> the users to interact with MongoDB.
> 
> I'm not saying that argument is right, and I am not a lawyer, but I do
> know that lawyers hate vagueness for this exact reason.
> 
> I do think AGPL complies with all of the clauses of the DFSG. There is
> very little difference in an AGPLv3 licensed library as a GPLv3 licensed
> library. Before linking, one must always check the library license. If
> we do let BDB 6.0 into Debian with its new AGPL license, it is on the
> BDB maintainer(s) to file RC bugs in the reverse dependencies to help
> maintainers avoid accidentally shipping AGPL licensed binaries that are
> not in compliance with the AGPL.

I'm already talking with upstreams to make sure mdb is supported for packages 
I maintain.  I'm certainly not planning on effectively making anything AGPL.

Scott K


-- 
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/3786443.229gZ0kdxN@scott-latitude-e6320

Re: Debian policy for web apps still references /doc as accessible

[Thomas Goirand]

On 07/10/2013 10:45 PM, Holger Levsen wrote:
> please file a bug against the debian-policy package.

Done, thanks!

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/51dd98f8.2030...@debian.org

Bug#715805: ITP: libdata-dumper-gui-perl -- GUI for Data::Dumper

[gregor herrmann]

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

* Package name: libdata-dumper-gui-perl
  Version : 0.003
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Data-Dumper-GUI/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : GUI for Data::Dumper

Data::Dumper::GUI is a little like Data::Dumper, but as well as printing out
a dump of the variables it is passed, it also shows them in a pretty GUI with
a tree view, allowing you to expand and collapse nodes, etc.

It has special secret sauce support for Moose objects. (And for Moo objects
too, if you make sure Moose is loaded before dumping them.)


-- 
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/20130710173121.ga5...@jadzia.comodo.priv.at

Re: Berkeley DB 6.0 license change to AGPLv3

[Russ Allbery]

Clint Byrum  writes:

> I do think AGPL complies with all of the clauses of the DFSG. There is
> very little difference in an AGPLv3 licensed library as a GPLv3 licensed
> library.

I agree from a licensing standpoint.

I think that, from a security standpoint, an AGPLv3 license on a library
puts any software that links with that library in an extremely awkward and
surprising security situation due to the prohibition on locally patching
security vulnerabilities without disclosure.  Personally, I would decline
to package any such software for Debian for that reason.  That's the sort
of surprise that I'm not interested in springing on my users.  Those kind
of license terms are very awkward in an enterprise environment.

For example, I would consider such software undeployable at Stanford.
We're a very free-software-friendly place, but there's no way that I would
give up the right to patch security vulnerabilities whenever and however I
want without immediately disclosing the fix.  I have frequently deployed
escrowed security fixes on publicly-accessible test/dev systems for
testing purposes, and in fact consider my ability to do that a necessary
prerequisite for being able to properly support the Debian packaging.

-- 
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/87ppuql0ll@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

[Bernhard R. Link]

* Stefano Zacchiroli  [130710 13:07]:
> On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
> > No, there is a really important difference. With GPL you only have to be
> > careful when you give binaries to anyone, that you also give the source.
> > This is a bit of a hassle, but worst case means that you cannot help
> > others with the software changes you have done (bad enough but worth the
> > hassle to have the source) if you miss some of the sources. But if the
> > sources may contain any passwords or other internal data you cannot/do
> > not want to share, so will likely the binary so that is no difference.
>
> On this level, the analogy GPL/AGPL still seems correct to me.

For me GPL is like police patroling in the streets and AGPL is like
policy getting the right to visit my bedroom at evening to look under
the bed for monsters at their discretion.

> A software distributed under AGPL will likely come with mechanisms
> already in place to point to its source code --- that might not be the
> case today yet, due to the scarce popularity of AGPL, but that's a
> separate matter.  That means that you can easily run unmodified version
> of an AGPL'd program, for any purpose, without particular restrictions.

I hope will all agree that the unmodified case does not matter at all.

> If you modify the software you might get in trouble but, according to my
> personal ethics, that's the trouble you should have.

I accept that I am not allowed to modify some software. But I refuse to
call such software free.

> However, please
> note that as long as you run the software only for yourself, you don't
> have any problem.

This is not the 1990ties anymore. Not allowing net access is quite an
big contraint. Some better definitions might reduce the problem here.

But given the way section is formulated I see nothing that would
make an exception for something only used by me and everyone else
interacting with it only by getting a loging prompt and a failure
message when they do not provide my username and password.

> You might encounter problems only in the case you've
> modified the software, you want *others* to use it over the net, and you
> don't provide the source code that include your modifications.

So if I patch a IRC client for my personal use to also show me some
other information (as I do not want too many open windows) and that
client contains AGPL code, does that fall under section 13 (assuming
it supports CTCP)? Have I lost the right to patch my programs locally
in a quick and dirty way embedding hostnames and passwords and logic
to access some private services in it without implementing a fake-irc
server for that information or some general message passing mechanism?

Even if defining the undefined "interacting" to need more interaction,
let's look at some website provided by some of the "all-in-one" thing.
Assume it has some content mangement part, partly showing public
information, partly only accessible by me (or if "I" in this example
was a company by my employees). And also a blog with comments (as
I think it will hard to define "interacting" so narrowly that it
will not contain that). Now if I want the private part to show me
some information from some other source, I am again forced to have
split things 'cleanly' on my systems with AGPL.

> That shift is coherent with the shift in the most common deployment
> [...]

Not every solution can be shifted. If some fly does not allow me
to sleep by its noise, I will either kill it or open an window and
throw it out. But if I had a cat and that would be too loud, neighter
would be a solution (perhaps the second if I lived at ground
floor). And if you have a baby, ...

There can be no freedom without restricting them to actually have them
in the one way or the other. But for such a restriction to be justified,
it needs both to be effective in protecting another freedom and not
cause greater harm than it brings.

In every way I see that you could make the definitions, AGPL will fail
at the one or the other:

Assume a AGPL program being modified or a program using AGPL libraries
to be interacting only via answering HTTP Requests and returning all
it's source code when "/source.tar.gz" is requested and giving proper
notice of this and the license and so on.

Either the AGPL permits such a program (or any AGPL program transformed
into such a program) to be run bound to a private IP or localhost
and all user interaction via a reverse proxy or loadbalancer that
returns 403 for "/source.tar.gz" or it forbids it.

In the first case the added restrictions are totally useless, especially
against the big "software as a service" players that it claims to
target, as those will likely have some loadbalancer doing some filtering
anyway.

In the second case it the restrictions to my freedom are so severe, that
I cannot see how it can do more harm than good. What worth has the
source to all the software in the world and the right to modify it, if
I lose t

Re: Berkeley DB 6.0 license change to AGPLv3

[Holger Levsen]

Hi,

On Mittwoch, 10. Juli 2013, Russ Allbery wrote:
> Clint Byrum  writes:
> > I do think AGPL complies with all of the clauses of the DFSG. There is
> > very little difference in an AGPLv3 licensed library as a GPLv3 licensed
> > library.
> 
> I agree from a licensing standpoint.
> 
> I think that, from a security standpoint, an AGPLv3 license on a library
> puts any software that links with that library in an extremely awkward and
> surprising security situation due to the prohibition on locally patching
> security vulnerabilities without disclosure. [...]
> Those kind of license terms are very awkward [...]

ouch :(

Thanks for "waking me up", Russ. :-)


cheers,
Holger


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

Re: [Popcon-developers] Encrypted popcon submissions

[Daniel Leidert]

Am Mittwoch, den 10.07.2013, 16:14 +0200 schrieb Bill Allombert:
> On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote:
> > 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!
> 
> Indeed, I receive much more encrypted report now.
> 
> A bug I like to fix before enabling encryption by default is #714917:
> gpg is creating a directory /root/gnupg with various files which are
> essentially useless since popcon do not perform any signature checks.
> 
> I do not know how to fix this bug short of creating a dummy GPGHOME
> directory with useless files.
> Any help welcome!

You don't need to create this directory. One can easily use
--homedir=/dev/null. However the most fitting answer depends on what you
want to do. Can you quote the commands please?

Regards, Daniel

Regards, Daniel


-- 
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/1373492162.7721.3.ca...@haktar.debian.wgdd.de

Bug#716662: ITP: ruby-serverspec -- RSpec tests for your servers configured by Puppet, Chef or anything else

[KURASHIKI Satoru]

Package: wnpp
Severity: wishlist
Owner: KURASHIKI Satoru 

* Package name: ruby-serverspec
  Version : 0.6.28
  Upstream Author : Gosuke Miyashita
* URL : http://serverspec.org/
* License : MIT
  Programming Lang: Ruby
  Description : RSpec tests for your servers configured by Puppet, Chef or 
anything else

With serverspec, you can write RSpec tests for checking your servers are 
configured correctly.

Serverspec tests your servers' actual state through SSH access, so you don't 
need to install
any agent softwares on your servers and can use any configuration management 
tools, Puppet,
Chef, CFEngine and so on.


-- 
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/20130711031131.16204.19431.report...@build.yoikaze.org

Re: Berkeley DB 6.0 license change to AGPLv3

[Scott Kitterman]

On Saturday, July 06, 2013 01:52:59 PM Howard Chu wrote:
> Florian Weimer wrote:
> > * Howard Chu:
> >> LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
> >> source, there's nowhere to hide any tricks anyway.)
> > 
> > Okay, I found a snag: the 511 bytes limit on the key size.  Berkeley
> > DB's disk format does not impose a limit on key or value size (at
> > least for B-trees).  For some applications, this will introduce new
> > error conditions, and working around this limitation requires
> > reworking the database schema.
> 
> True. There's a bit of leeway here, we can raise the key size to ~1/2 the
> page size if necessary. But ultimately, we don't support keys that don't
> fit in a single page and there are no plans to add such support. If we see
> enough apps that can't live with this, we may revisit the situation.

I did go back and look at the plans for mdb integration in Postfix, since it's 
my MTA of choice.  It does seem that there are some barriers to adoption:

http://www.postfix.com/LMDB_README.html

Are there any plans to address these issues?

Scott K


-- 
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/2322910.gezk5TMbzA@scott-latitude-e6320

Bug#716665: ITP: ktp-contact-runner -- Provides a KRunner plugin to interact with kde-telepathy contacts

[Diane Trout]

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

--- Please fill out the fields below. ---

Package name   : ktp-contact-runner
Version: 0.6.2
Upstream Author: Dan Vratil 
URL: 
https://projects.kde.org/projects/extragear/network/telepathy/ktp-contact-runner

License: LGPL 2.1
Description: KDE Telepathy Contact KRunner plugin

KDE Telepathy is a highly modular software package that is already in debian, 
this is just an additional component.

This package provides a KRunner plugin which allows you to execute actions
like start a text chat or start an audio/video call with your Telepathy
IM contacts.

Diane Trout


-- 
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/1570737.a8VeMrOuAv@myrada