On Thu, May 8, 2014 at 2:43 PM, Paul Wise wrote:
> You may have missed the maintainer's take on this:
>
> /usr/share/doc/doxygen/README.jquery
> http://sources.debian.net/src/doxygen/1.8.6-2/debian/README.jquery
Woops, I confused doxygen with docbook2x. The situation sounds similar though.
--
b
On Thu, May 8, 2014 at 2:01 PM, Daniel Baumann wrote:
> did i miss anything?
You may have missed the maintainer's take on this:
/usr/share/doc/doxygen/README.jquery
http://sources.debian.net/src/doxygen/1.8.6-2/debian/README.jquery
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSC
src:lxc contains documentation (*.sgml only) and build-depends on
docbook2x, no jquery is needed or installed as build-depends. the
resulting bin:lxc-dev then contains a *compressed* jquery.js put there
by docbook2x. lintian detects this and warns about it (W:
embedded-javascript-library).
i think
Vincent Bernat writes:
> When I get some time to work on my packages and I see this:
>
> http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube
Yes, it's disheartening to see such files in a source distribution from
upstream. Fortunately the solut
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij
* Package name: golang-etcd
Version : 0.2.0~rc1
Upstream Author : CoreOS Inc.
* URL : http://github.com/coreos/go-etcd
* License : Apache v2
Programming Lang: Go
Description : Go client for etcd
C
❦ 8 mai 2014 01:11 +0200, Jérémy Lal :
>> This is to be compared with the time spent by the maintainer to deal
>> with this problem by adding files or removing files from the source
>> package without affecting the resulting binary package. This may keep
>> some contributors away from Debian.
>
Le jeudi 08 mai 2014 à 00:57 +0200, Vincent Bernat a écrit :
> ❦ 7 mai 2014 17:41 CEST, The Wanderer :
>
> > Specifically, it violates my (pre-this-thread) expectation of what it is
> > that I get from 'apt-get source'. Prior to reading this thread, it would
> > never have occurred to me to thi
❦ 7 mai 2014 17:41 CEST, The Wanderer :
> Specifically, it violates my (pre-this-thread) expectation of what it is
> that I get from 'apt-get source'. Prior to reading this thread, it would
> never have occurred to me to think that something obtained that way
> might not be actually part of the
Excerpts from Philipp Kern's message of 2014-05-07 15:00:43 -0700:
> On Wed, May 07, 2014 at 12:57:41PM +0100, Ian Jackson wrote:
> > Philipp Kern writes ("Re: Ghostscript licensing changed to AGPL"):
> > > Does that mean that people calling one of these from a script or a web
> > > service (e.g. i
> Yes. But this isn't as bad as you think, because the source
> availability requirement exists only if you modify the AGPL'd
> software.
I don't think that this is the case. Firstly, because it leaves a
practical loophole in the AGPL:
-Person A takes some software under the AGPL.
-Person A priv
On Wed, 7 May 2014 15:56:06 +0200 Bálint Réczey wrote:
> 2014-05-07 14:37 GMT+02:00 Thorsten Glaser :
> > On Wed, 7 May 2014, Ian Jackson wrote:
> >
> >> Yes. But this isn't as bad as you think, because the source
> >> availability requirement exists only if you modify the AGPL'd
> >> software.
>
On Wed, 7 May 2014 00:05:51 +0200 Philipp Kern wrote:
> On Tue, May 06, 2014 at 11:05:11AM +0200, Jonas Smedegaard wrote:
> > Ghostscript have changed its license from GPL-3+ to AGPL-3+ since
> > version 9.07.
I am really disappointed and worried by this license switch... :-(
Even though the
On Wed, May 07, 2014 at 12:57:41PM +0100, Ian Jackson wrote:
> Philipp Kern writes ("Re: Ghostscript licensing changed to AGPL"):
> > Does that mean that people calling one of these from a script or a web
> > service (e.g. invoices using texlive-bin) will need to adhere to the
> > AGPL as well?
> Y
On Wed, May 07, 2014 at 10:48:46PM +0200, Jean-Christophe Dubacq wrote:
> texlive-bin uses the software (gs), As you, yourself, said, the
> difference between the AGPL and the GPL is that the AGPL protects the
> user, not only the people that download the software. This means that by
> some interpr
previously on this list Matthias Urlichs contributed:
> Hi,
>
> Kevin Chadwick:
> > > * last but not least: if you do have a tangible reason for your post, i.e.
> > > one of your packages doesn't work with the way systemd is packaged,
> > > kindly tell us which package that is and what you're
Hi Ben,
tl;dr: It was indeed blacklisted by a leftover config file from the
fglrx-driver package.
Am 2014-05-06 01:46, schrieb Ben Hutchings:
Why radeon is not loaded at boot anymore is a mystery to me. All other
modules from /etc/modules (symlinked
as /etc/modules-load.d/modules.conf) are ac
On 07/05/2014 18:59, Bas Wijnen wrote:
>
>>> * texlive-bin (texlive-binaries)
>>
>> Actually with this one is worst, since the LPPL is not compatible with
>> the GPL, lets not even talk about GPLv3 or AGPLv3 :-/
>
> If it's incompatible with the GPL and the way they distributed it was
> accept
Hi Jordi,
thanks for the informative report, it seems to have been an awesome sprint!
On Freitag, 2. Mai 2014, Jordi Mallach wrote:
> Besides this, quite a few more topics were discussed, like trying to make
> our experimental packages always installable...
if you think it would be useful, I'd b
Hey there,
I found you guys on Google while researching for SEO companies!
We created an infographic titled “What Makes the Perfect Blog Post?” that would
be great for an SEO audience. Here’s the link:
http://blogpros.com/blog/2014/05/makes-perfect-blog-post-infographic
What do you think of it?
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libautobox-junctions-perl
Version : 0.001
Upstream Author : Chris Weyl
* URL : https://metacpan.org/release/autobox-Junctio
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-server
Version : 2014.05
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL, LGPL, AGPL
Programming Lang: Python
Desc
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-dispatcher
Version : 2014.05
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL, LGPL
Programming Lang: Python
Descri
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lavapdu
Version : 0.0.3
Upstream Author : Matthew Hart
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL
Programming Lang: Python
Description : LAVA PDU client
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-coordinator
Version : 0.1.5
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-tool
Version : 0.10
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : LGPL
Programming Lang: Python
Description : co
On Wed, May 07, 2014 at 05:18:36PM +1000, Ben Finney wrote:
> the problem is for the package maintainer to assert that *is* the
> corresponding source for a particular work.
>
> We should not, IMO, accept such an assertion without an independently
> verifiable guarantee that can be automated for e
On 2014-05-06 Dimitri John Ledkov wrote:
> On 5 May 2014 18:53, Andreas Metzler wrote:
> > Didier 'OdyX' Raboud wrote:
> >> Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit :
> >>> Personally I'd add a (build-)depends on the relicensed gmp in the next
> >>> gnutls28 upload. That way package
On Tue, May 06, 2014 at 06:44:16PM -0700, Jose Luis Rivas wrote:
> I saw it and I fail to see what exactly they want to achieve with this
> change since AGPLv3 is for web apps.
I license almost all my work as AGPL, because I like that clause. The idea of
the GPL is to make sure that all end users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/07/2014 11:06 AM, Wouter Verhelst wrote:
> I submit that in the case of minified javascript libraries that are
> *already available* in Debian, and that are symlinked (in the way as
> described before) but ship in a source tarball as convenien
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone? Matthias, perhaps?
Greetings,
On 06/05/14 20:05, Luis Alejandro Martínez Faneyth wrote:
> Hi everyone,
>
> I'm a little worried about bug #702005 and the lack of attention
> it's getting.
>
> This bug is marked as resolved, and indeed it ha
Op woensdag 7 mei 2014 23:18:00 schreef Ben Finney:
> Wouter Verhelst writes:
> > The point is, I'm having a hard time buying the argument that if the
> > minified javascript was unmodified, and if the non-minified javascript
> > library is in the archive (or a version of said javascript library
>
Hi,
2014-05-07 14:37 GMT+02:00 Thorsten Glaser :
> On Wed, 7 May 2014, Ian Jackson wrote:
>
>> Yes. But this isn't as bad as you think, because the source
>> availability requirement exists only if you modify the AGPL'd
>> software.
>
> Which you may want to do, in order to patch a security issue
Wouter Verhelst writes:
> Op woensdag 7 mei 2014 12:19:31 schreef Philip Hands:
...
>> we could perhaps give public variables a
>> version number, or only allow questions with such a version number as
>> part of their name be manipulated from elsewhere.
>
> I don't think debconf needs to care abo
Wouter Verhelst writes:
> The point is, I'm having a hard time buying the argument that if the
> minified javascript was unmodified, and if the non-minified javascript
> library is in the archive (or a version of said javascript library
> which will function in exactly the same way), that the min
On 7 May 2014 01:19, Charles Plessy wrote:
> Hi Matthias,
>
> your answer exemplifies very well what I mean with “pressed by the machine”…
>
> I will reply on one point only.
>
> Le Wed, May 07, 2014 at 01:46:32AM +0200, Matthias Klose a écrit :
>> Am 06.05.2014 03:05, schrieb Charles Plessy:
>> >
]] Wouter Verhelst
> You *could* have a script do db_set to change the defaults
> and then run the postinst script (through dpkg-reconfigure), but that
> would run against the spirit of 10.7.4 IMO.
That won't help, since dpkg-reconfigure will run the config script that
should grab data from t
On Wed, 7 May 2014, Ian Jackson wrote:
> Yes. But this isn't as bad as you think, because the source
> availability requirement exists only if you modify the AGPL'd
> software.
Which you may want to do, in order to patch a security issue
you just found, locally, before filing it upstream.
Or be
Op woensdag 7 mei 2014 12:19:31 schreef Philip Hands:
> Wouter Verhelst writes:
>
>
> > One way this could work is by adding a SETOTHER message (name could
> > probably be better), which asks debconf to change a value for a given
> > debconf question in another package ONLY if the answer to
Ian Jackson writes ("Re: Ghostscript licensing changed to AGPL"):
> Philipp Kern writes ("Re: Ghostscript licensing changed to AGPL"):
> > Does that mean that people calling one of these from a script or a web
> > service (e.g. invoices using texlive-bin) will need to adhere to the
> > AGPL as well
Philipp Kern writes ("Re: Ghostscript licensing changed to AGPL"):
> Does that mean that people calling one of these from a script or a web
> service (e.g. invoices using texlive-bin) will need to adhere to the
> AGPL as well?
Yes. But this isn't as bad as you think, because the source
availabili
Wouter Verhelst writes:
...
> One way this could work is by adding a SETOTHER message (name could
> probably be better), which asks debconf to change a value for a given
> debconf question in another package ONLY if the answer to this question
> was never explicitly set to a particular value by
Op woensdag 7 mei 2014 12:59:57 schreef Jonas Smedegaard:
> Hi Wouter,
>
> Quoting Wouter Verhelst (2014-05-07 11:34:23)
>
> > What you seem to want is a unified and standardized way for one
> > package to provide an API for changing things about how the package
> > will function, to other packag
Op woensdag 7 mei 2014 20:14:50 schreef Ben Finney:
> Wouter Verhelst writes:
> > Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte:
> > > If you were to 'update' the image, how would you do it? What things
> > > would you need? Include that. Think about what you'd need when
you
> > > fork
Neil Williams writes:
> Ben Finney wrote:
> > Wouter Verhelst writes:
> > > If a dependency and a symlink exists, however, it's clear that the
> > > maintainer meant to say "source is over there".
>
> As I've tried to show above, "over there" is not helpful. "over there"
> can go away, can be u
Hi Wouter,
Quoting Wouter Verhelst (2014-05-07 11:34:23)
> What you seem to want is a unified and standardized way for one
> package to provide an API for changing things about how the package
> will function, to other packages.
Correct.
> While a worthwhile effort, I don't think this is what
On Wed, 07 May 2014 20:14:50 +1000
Ben Finney wrote:
> Wouter Verhelst writes:
>
> > Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte:
> > > If you were to 'update' the image, how would you do it? What
> > > things would you need? Include that. Think about what you'd need
> > > when you
Wouter Verhelst writes:
> Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte:
> > If you were to 'update' the image, how would you do it? What things
> > would you need? Include that. Think about what you'd need when you
> > fork the project.
>
> Does that mean I should include "wget"?
I'm
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez
* Package name: neopi
Version : 0.1
Upstream Author : Ben Hagen
* URL : https://github.com/Neohapsis/NeoPI
* License : GPL-3
Programming Lang: Python
Description : web shell code detection
On Fri, Apr 25, 2014 at 11:07:53AM +0100, Neil Williams wrote:
> No. The requirement is that the source is part of the source package.
[citation needed]
The only requirement I know of is that the source is part of *a*
source package, not necessarily the same one.
(consider "Built-Using")
--
Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte:
> If you were to 'update' the image, how would you do it? What things
> would you need? Include that. Think about what you'd need when you fork
> the project.
Does that mean I should include "wget"?
Most minified externally-produced javascr
Hi Jonas,
[re-sending, since my first attempt did not make the list]
Op vrijdag 18 april 2014 12:43:40 schreef Jonas Smedegaard:
> Thanks, but (again) I am sorry if it was not clear: The *question* is
> about *debconf* irregardless of the *example* involving other details.
>
> Here's another exa
Wouter Verhelst writes:
> [W]hile I agree that this is a problem for things like precompiled
> Windows binaries, I'm not so sure when it regards convenience copies
> of minified javascript libraries. After all, there are many other
> packages whose upstream source ships with convenience copies of
Hi Charles,
Op zaterdag 26 april 2014 14:29:44 schreef Charles Plessy:
> Le Fri, Apr 25, 2014 at 10:11:58PM -0700, Steve Langasek a écrit :
> > On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
> > > Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a écrit :
> > > > On Sat, Apr 26
Hi Julien,
thanks for pushing these transitions! Last med-fichier upload was
just to fix autopkgtest, so I think if you let it go, it should not hurt.
Thanks
Anton
2014-05-07 8:46 GMT+02:00 Julien Cristau :
> Hi,
>
> the mpich transition (along with the scalapack, blacs-mpi and superlu
> tran
54 matches
Mail list logo
