Re: Sources licensed under PHP License and not being PHP are not distributable

[Thomas Goirand]

On 06/26/2014 07:41 PM, Ondřej Surý wrote:
> The initial conclusion came from debian-legal, and I think it's
> futile to discuss that with ftp-masters when I already done that.
> And as you can see in the initial conversation in the bug report
> I was against the removal, but in the end they have convinced
> me that licensing anything not-being-PHP under PHP License
> is just no-goer.
> 
> O.

It all depends what you consider "not-being-PHP". To some degree,
modules in pear.php.net are part of PHP, which is why we call the
packages php-*. This is also upstream PHP (the language) view on the
mater as well.

Also, previously, it was the case that anything lower than PHP license
version 3.01 was not acceptable, but the PHP license was ok for PEAR
modules. This was already discussed at the time (I believe), or at
least, that's what I've been told by the FTP masters when uploading
(that I'm sure). I do not agree that we just go back, and change our
mind on the licensing policy, after we did all the work. This kind of
decision has to be firm, and we should hold to it. Otherwise, it's a
horrible loss of time for everyone.

Please let me know what changed, and what part of the license is not
acceptable anymore.

On 06/26/2014 07:53 PM, Ondřej Surý wrote:
> Don't shoot the messenger, I just did the dirty work.

I don't agree you're just the messenger. You've filed the RC bugs, no?

> I have discussed this with ftp-masters and release team before
> filling the bugs, arguing heavily in disagreement with ftp-master's
> REJECT FAQ - the PHP License REJECT is there since 2005.

That is simply not truth. Anything with PHP license << 3.01 has been,
but if it's >= 3.01, it has always been considered OK, at least for
pear.php.net modules. I believe there's a confusion inside the FTP
master team about this.

On 06/27/2014 02:17 AM, Matthias Urlichs wrote:
> Thus, while we're in a reasonably good position to convince Upstream
> to fix that problem, filing RC bugs and thus making PHP unuseable in
> Debian is certainly going to be regarded as typical Debian
> principles-above-all overkill but unlikely to be helpful to anybody.

Well put, but I'd have say it with stronger words.

On 06/27/2014 02:27 AM, Clint Byrum wrote:
> If anyone has a better way to safeguard those to whom we distribute
> software, please do speak up about it. I for one think our users
> choose Debian because they can be sure their rights are being looked
> after. Let's do what we can to help upstream rectify the situation,
> but lets also be honest with our users while they respond.

If we are to be honest, then we should *not* change our mind 10 years
after we've accepted some licensing. PEAR modules have been accepted
with PHP license 3.01, and we shall continue to keep them in Debian. I
have a less strong opinion about anything non-PEAR module and PHP
license though (I'm not sure about this, in all honesty), and I care
less about them anyway.

On 06/27/2014 10:43 AM, Chris Bannister wrote:
> On Thu, Jun 26, 2014 at 08:57:43PM +0200, Matthias Urlichs wrote:
>> I'd recommend that we safeguard our users against 'PHP' licensing
>> problems the same way I protect myself against a meteorite hitting
>> me on my way to work tomorrow, and for roughly the same reasons.
>
> Because there is nothing you can do?

No, because statistically, it's as if it was impossible that such a
cataclysmic event occurs.

On 07/01/2014 05:22 AM, Clint Byrum wrote:
> Unless I'm mistaken, the wording in the PHP license makes it invalid
> for anybody that isn't actually the PHP project to use without making
> a false claim that "THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT
> TEAM".

IMO, you are mistaking indeed. Anyone contributing a module to
pear.php.net PEAR channel can be considered from the "PHP development
team". That's a question of view, and we've accepted that view, so why
should we go back after we have accepted packages based on this? This is
also the view of upstream PHP (the language) and upstream PEAR module
contributors, as much as one can tell. If you do not agree, please point
to anyone who expressed otherwise.

On 07/01/2014 06:58 PM, Ondřej Surý wrote:
> JFTR the http://www.php.net/software page claims that software
> distributed from php.net, pecl.php.net and pear.php.net distributes
> software under PHP License[1].
>
> This was also claimed in some private emails between me and
> PHP folks[2].
>
> My conclusion is that the PHP folks do agree that the PHP License
> cannot be used for software outside *.php.net, but it's perfectly OK
> for stuff distributed from *.php.net.

I'm very surprised of the circonvolutions to finally have this outcome,
which we already knew about: it's been like this in Debian for YEARS.

On 07/01/2014 06:58 PM, Ondřej Surý wrote:
> If there's no wild disagreement from FTP Masters on this in couple
> of days I will just start closing bugs on packages distributed from
> *.php.net.

I agree that this is what should be done, yes.

Cheers,

Re: Sources licensed under PHP License and not being PHP are not distributable

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/07/2014 03:39 AM, Thomas Goirand wrote:

> On 07/01/2014 05:22 AM, Clint Byrum wrote:
> 
>> Unless I'm mistaken, the wording in the PHP license makes it
>> invalid for anybody that isn't actually the PHP project to use
>> without making a false claim that "THIS SOFTWARE IS PROVIDED BY THE
>> PHP DEVELOPMENT TEAM".
> 
> IMO, you are mistaking indeed. Anyone contributing a module to 
> pear.php.net PEAR channel can be considered from the "PHP development
> team". That's a question of view, and we've accepted that view, so
> why should we go back after we have accepted packages based on this?
> This is also the view of upstream PHP (the language) and upstream
> PEAR module contributors, as much as one can tell. If you do not
> agree, please point to anyone who expressed otherwise.

One question / consideration:

Even assuming that all contributions accepted into modules hosted on
pear.php.net are considered automatically "from the PHP Development
Team", and thus that the statement in the license would remain accurate,
wouldn't this mean that it wouldn't be possible to make local
modifications to a module found there and distribute them by other means
(e.g. even within one's own organization) without either making a false
statement in the license or violating the license?

If it would mean that, then wouldn't this license be considered non-free?

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTulf7AAoJEASpNY00KDJrwQAP/RpzgNpYlYULpqOyJK/uwbza
MrT+23bQ/1OLy5KaGdPYvWUGpXw2JHxJaMEBchLTVjL2c3I+mgBW9kZ/qDalwpdf
36KZxdhOJi8bHCmbd13rOYu9pZr+DFLCivt63L3xRaz4V0RnO0ijbJYvuu+VNiL9
mABrxbQNo/hDR6NnpFUiw1Ze09JnN0dbrRUhOE0uPDvESd9wusSkvh36hy63WEvi
uaP+zUiGA2rGlB5WFRV1CVJH0gsLtSJKSbvSdk5hJGs7EbZjrE63jCnaGiNohufj
X5JFuzWuD2moiLIg/3kaZ6mj8zbEtP9TR4ND01NnRrTDpC2vO8Rkc0HsmOPXgKQ5
EFBgKsAp0XWy/T+rUltUppQEHq8bX22yQYjN/b6LFA4DzBmkBpGDCIWK+Q8W+Ewq
tm0UtpK+5se7U0M6xtb0E+VpFC80KnC1bUFal0ipebR7YCXEXI9ESnjZ2IIE0nLW
BWmUD6n+3zNzDVmqn8gNCReVUAAave0rYxwvZlvFDJVAz6ZRlZpLLtUdPWOmmtAg
0C9RKSHCL4D25VgsCAm/2T5DtvBeGbDudPzzFuROuCqtnnXiDDYkGaBOQv7Ebohd
pQbXIXEqpImirEAX2fvJGpMSy+xnlZO3XaranRUYLKN64+m4gYsALuU2OR5rO4Ew
yGDyB6SltUMNJWB+rM0D
=Xij/
-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: https://lists.debian.org/53ba57fb.5070...@fastmail.fm

Debian.

[Dan Rulos]

How are you developing debian? I need to develop a new linux distro
based on debian squeeze, how can i ? Thanks. I'm 14 years old spanish
and my english is not perfect.

-- 
Saludos


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

Re: Debian.

[Neil Williams]

On Mon, 7 Jul 2014 11:23:50 +0200
Dan Rulos  wrote:

> How are you developing debian?

Adding and fixing packages - see the docs:
https://www.debian.org/devel/

> I need to develop a new linux distro
> based on debian squeeze, how can i ? 

First question is why? What do you want from a new distro and why can't
Debian Squeeze do it?

Note: you should also look at using a later release as squeeze is now
oldstable and will be dropped from the archives soon once we start the
process for Debian Jessie. Debian Wheezy 7.5 is the current stable.

Generally, you just tweak the existing distro by changing some defaults
or changing the package selection, adding some metapackages to change
what gets installed by default.

Most of the time, you don't actually need to change much.

See also https://wiki.debian.org/Derivatives

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Debian.

[Dominik George]

Hi,

I have sent a reply off-list because I do not think the question is really 
related to Debian development by itself.

As Teckids is dedicated to teaching Free Software (development) to children 
and adolescents, I saw fit here.

Just for your information that someone has taken care of the inquiry :).

-nik

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

Re: How to avoid stealth installation of systemd?

[Holger Levsen]

Hi,

On Donnerstag, 3. Juli 2014, Michael Biebl wrote:
> Agreed, we should do the switch sooner rather then later.
> Let me follow up on the actual switch in a separate thread.

this has not happened yet, shall I file bugs against the general pseudo 
package so we have some means to track this?

> We discussed that in #debian-systemd and we think we have found a pretty
> neat solution which should handle both the fresh installation and
> upgrade case. We also think that we are ready to do the switch asap for
> the reasons you have given.

I'm curious to hear your plans!


cheers,
Holger


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

possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

we would like to propose an MBF with severity wishlist to drop unused build
dependencies in a number of source packages indicated by the attached two text
files and the dd-list output.

TLDR; We searched a selection of source packages relevant to bootstrapping for
build dependencies which are never used during the package build. Fewer build
dependencies help making bootstrapping easier so we want to submit bugs for the
results we generated. The results were generated automatically by a script
using fatrace(1) and fake packages. It follows the MBF template email and a
detailed explanation of our procedures. Attached is the list of the unused
build dependencies we found and the output of dd-list. We would like you to
review the list, drop unused build dependencies or report errors.

MBF template email:

--%<---
Subject: Please consider removing the build dependencies on $foo, $bar and $baz
Severity: wishlist
Usertag: unusedbd
User: bootst...@lists.debian.org

Dear Maintainer,

the build dependencies $foo, $bar and $baz of this source package do not seem
to be needed. Neither are any of their files accessed during the build nor are
their dependencies on other binary packages required. Please consider dropping
those build dependencies to make bootstrapping Debian easier.

You can find more detail about the procedures that were used to find this
problem in the MBF announcement on debian-devel: $email
-->%---

Long version:

Our "bootstrappable Debian" GSoC student Peter Pentchev found a number of
source packages that did not make use of some of their build dependencies [1].
We thought we could automate this process so we set up a simple sbuild based
package builder. The machinery works in two passes. In the first pass, all
source packages are built normally but with fatrace(1) active. From the fatrace
output we determine all build dependencies of which no files were used during
the build.  In the second pass we go through all source packages for which
candidate droppable build dependencies where found with fatrace and test
whether those build dependencies are really droppable by replacing them with an
empty equivs package without dependencies one by one.

The first pass makes sure that the files of a specific build dependency are not
needed. This is to make sure not to produce false positives of build
dependencies which, if not installed on the build system, do not result in a
build failure but instead just in a reduction of functionality of the output
binary. The second pass makes sure that also the dependencies of a specific
build dependency are not needed. This makes sure to not produce false positives
of meta or virtual packages.

We executed the build on the amd64 snapshot 20140601T00Z of Debian Sid. A
selection of 549 source was made from the source packages that are involved in
the central strongly connected component of the bootstrapping dependency graph.
We needed to patch fatrace to be able to handle files larger than 2 GB (bug
#722901).

We ran the whole process with `sbuild --arch-all` and then again with `sbuild
--no-arch-all`. This way we can find build dependencies which can be dropped
from full package builds as well as those which can be moved to
Build-Depends-Indep. We did not use the results to also check for build
dependencies that can be removed from Build-Depends-Indep.

The source code to run the whole machinery can be found at [2].

Executing everything took two weeks and over 2000 package builds. We found 277
build dependencies could be dropped from the 549 tested source packages,
affecting 158 source packages.

We checked the impact on the bootstrap dependency graph. If all the found build
dependencies were really droppable, then the minimum (strong) dependency graph
would shrink from containing 483 source packages to 447 source packages.  More
importantly, the solution to the feedback arc set problem for making it acyclic
would shrink from 74 to 56 source packages. Thus, the generated results are
very relevant for making solving the bootstrap problem easier.

You can find the results per source package in the attachment together with the
dd-list output. The file drop-from-bd.txt lists the build dependencies that can
be dropped from Build-Depends while move-to-bdi lists the build dependencies
that can be moved from Build-Depends to Build-Depends-Indep.

Can you spot obvious mistakes in the results or in the procedure used to
generate them?

cheers, josch

[1] #749616 #749972 #751702 #751897 #752938
[2] https://github.com/josch/findunusedbd
"Adam C. Powell, IV" 
   mpi-defaults (U)

Adam Conrad 
   cyrus-sasl2 (U)
   eglibc (U)
   freetds (U)

Agustin Martin Domingo 
   linuxdoc-tools (U)

Alan Woodland 
   blcr

Alessandro Ghedini 
   curl
   valgrind

Alessio Treglia 
   gpac (U)

Alexander Wirt 
   rrdtool (U)

Andreas Barth 
   netp

Re: possible MBF: automatically detecting unused build dependencies

[Henrique de Moraes Holschuh]

On Mon, 07 Jul 2014, Johannes Schauer wrote:
> MBF template email:
> 
> --%<---
> Subject: Please consider removing the build dependencies on $foo, $bar and 
> $baz
> Severity: wishlist
> Usertag: unusedbd
> User: bootst...@lists.debian.org
> 
> Dear Maintainer,
> 
> the build dependencies $foo, $bar and $baz of this source package do not seem
> to be needed. Neither are any of their files accessed during the build nor are
> their dependencies on other binary packages required. Please consider dropping
> those build dependencies to make bootstrapping Debian easier.
> 
> You can find more detail about the procedures that were used to find this
> problem in the MBF announcement on debian-devel: $email
> -->%---

Please don't assume that the unused build dependency is always where the
defect is.  Rather, the MBF text should account for the possibility that the
unused build-dependency should have been used in the first place, but
something is broken in the build and it is being left unused.

For example: something that is uselessly build-depending on autotools-dev
might either:

1. Have an useless build-dependency

or

2. Have a bug that is causing autoreconf to either not be called in the
   first place, or to fail to refresh the auto-tooling.


While (1) is more likely, ignoring the possibility of (2) is not wise.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140707120726.ga7...@khazad-dum.debian.net

Re: possible MBF: automatically detecting unused build dependencies

[Jérémy Lal]

Le lundi 07 juillet 2014 à 09:07 -0300, Henrique de Moraes Holschuh a
écrit :
> On Mon, 07 Jul 2014, Johannes Schauer wrote:
> > MBF template email:
> > 
> > --%<---
> > Subject: Please consider removing the build dependencies on $foo, $bar and 
> > $baz
> > Severity: wishlist
> > Usertag: unusedbd
> > User: bootst...@lists.debian.org
> > 
> > Dear Maintainer,
> > 
> > the build dependencies $foo, $bar and $baz of this source package do not 
> > seem
> > to be needed. Neither are any of their files accessed during the build nor 
> > are
> > their dependencies on other binary packages required. Please consider 
> > dropping
> > those build dependencies to make bootstrapping Debian easier.
> > 
> > You can find more detail about the procedures that were used to find this
> > problem in the MBF announcement on debian-devel: $email
> > -->%---
> 
> Please don't assume that the unused build dependency is always where the
> defect is.  Rather, the MBF text should account for the possibility that the
> unused build-dependency should have been used in the first place, but
> something is broken in the build and it is being left unused.

Consider also the case when arch:all package require a build dependency
on a package that only builds on some archs, to prevent the arch:all
package being available on archs where its dependencies are not.
nodejs and node-* packages are such an example.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404735139.4416.2.camel@imac.chaumes

Re: possible MBF: automatically detecting unused build dependencies

[Julian Taylor]

On Mon, Jul 7, 2014 at 1:51 PM, Johannes Schauer  wrote:

>
> Can you spot obvious mistakes in the results or in the procedure used to
> generate them?
>

There seem to be a bunch of false positives for virtual/metapackages:

==> python-numpy_1.8.1-1.arch-all.unusedbd <==
gfortran=4:4.8.2-4
python-all-dbg=2.7.6-2
python-all-dev=2.7.6-2
python3-all-dbg=3.4.1~rc1-1
python3-all-dev=3.4.1~rc1-1

the -all packages are basically empty packages pulling in all python
versions supported, those packages are definitely used during the
build.
Removing them during an arch-any build should fail the build.
does sbuild --arch-all only build the indep part? If so that might
explain why your pass2 did not remove these, but so far I know we have
no way to declare this state in our control, we only have
Build-Depends and Build-Depends-Indep, no Build-Depends-Arch.

Similar fftw3:
==> fftw3_3.3.4-1.arch-all.unusedbd <==
gfortran=4:4.8.2-4
ghostscript=9.05~dfsg-8.1
mpi-default-dev=1.0.2+nmu1
transfig=1:3.2.5.e-3

mpi-default-dev is not used directly but its dependencies are required
for the fully featured arch any build.


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

Re: possible MBF: automatically detecting unused build dependencies

[Ondřej Surý]

Hi josch,

thank you very much for this effort, just two remarks:

1. +1 to what hmh said

2. You have missed at least one virtual package: libdb-dev is used to
depend on latest libdbX.Y-dev, so if you can remove that before MBF...

Ondrej

On Mon, Jul 7, 2014, at 13:51, Johannes Schauer wrote:
> Hi,
> 
> we would like to propose an MBF with severity wishlist to drop unused
> build
> dependencies in a number of source packages indicated by the attached two
> text
> files and the dd-list output.
> 
> TLDR; We searched a selection of source packages relevant to
> bootstrapping for
> build dependencies which are never used during the package build. Fewer
> build
> dependencies help making bootstrapping easier so we want to submit bugs
> for the
> results we generated. The results were generated automatically by a
> script
> using fatrace(1) and fake packages. It follows the MBF template email and
> a
> detailed explanation of our procedures. Attached is the list of the
> unused
> build dependencies we found and the output of dd-list. We would like you
> to
> review the list, drop unused build dependencies or report errors.
> 
> MBF template email:
> 
> --%<---
> Subject: Please consider removing the build dependencies on $foo, $bar
> and $baz
> Severity: wishlist
> Usertag: unusedbd
> User: bootst...@lists.debian.org
> 
> Dear Maintainer,
> 
> the build dependencies $foo, $bar and $baz of this source package do not
> seem
> to be needed. Neither are any of their files accessed during the build
> nor are
> their dependencies on other binary packages required. Please consider
> dropping
> those build dependencies to make bootstrapping Debian easier.
> 
> You can find more detail about the procedures that were used to find this
> problem in the MBF announcement on debian-devel: $email
> -->%---
> 
> Long version:
> 
> Our "bootstrappable Debian" GSoC student Peter Pentchev found a number of
> source packages that did not make use of some of their build dependencies
> [1].
> We thought we could automate this process so we set up a simple sbuild
> based
> package builder. The machinery works in two passes. In the first pass,
> all
> source packages are built normally but with fatrace(1) active. From the
> fatrace
> output we determine all build dependencies of which no files were used
> during
> the build.  In the second pass we go through all source packages for
> which
> candidate droppable build dependencies where found with fatrace and test
> whether those build dependencies are really droppable by replacing them
> with an
> empty equivs package without dependencies one by one.
> 
> The first pass makes sure that the files of a specific build dependency
> are not
> needed. This is to make sure not to produce false positives of build
> dependencies which, if not installed on the build system, do not result
> in a
> build failure but instead just in a reduction of functionality of the
> output
> binary. The second pass makes sure that also the dependencies of a
> specific
> build dependency are not needed. This makes sure to not produce false
> positives
> of meta or virtual packages.
> 
> We executed the build on the amd64 snapshot 20140601T00Z of Debian
> Sid. A
> selection of 549 source was made from the source packages that are
> involved in
> the central strongly connected component of the bootstrapping dependency
> graph.
> We needed to patch fatrace to be able to handle files larger than 2 GB
> (bug
> #722901).
> 
> We ran the whole process with `sbuild --arch-all` and then again with
> `sbuild
> --no-arch-all`. This way we can find build dependencies which can be
> dropped
> from full package builds as well as those which can be moved to
> Build-Depends-Indep. We did not use the results to also check for build
> dependencies that can be removed from Build-Depends-Indep.
> 
> The source code to run the whole machinery can be found at [2].
> 
> Executing everything took two weeks and over 2000 package builds. We
> found 277
> build dependencies could be dropped from the 549 tested source packages,
> affecting 158 source packages.
> 
> We checked the impact on the bootstrap dependency graph. If all the found
> build
> dependencies were really droppable, then the minimum (strong) dependency
> graph
> would shrink from containing 483 source packages to 447 source packages. 
> More
> importantly, the solution to the feedback arc set problem for making it
> acyclic
> would shrink from 74 to 56 source packages. Thus, the generated results
> are
> very relevant for making solving the bootstrap problem easier.
> 
> You can find the results per source package in the attachment together
> with the
> dd-list output. The file drop-from-bd.txt lists the build dependencies
> that can
> be dropped from Build-Depends while move-to-bdi lists the build
> dependencies
> that can 

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

sorry I attached two wrong files containing the many false positives already
noticed by some of the replies. Here the actual results.

Sorry.

cheers, josch
==> apache2_2.4.9-1.arch-all.unusedbd.real <==
libcap-dev:amd64=1:2.22-1.2

==> apparmor_2.8.0-5.arch-all.unusedbd.real <==
dejagnu=1.5-3
texlive-latex-recommended=2014.20140528-3

==> apr-util_1.5.3-2.arch-all.unusedbd.real <==
libpcre3-dev:amd64=1:8.31-5

==> apt_1.0.3.arch-all.unusedbd.real <==
automake=1:1.14.1-3

==> at-spi2-atk_2.10.2-3.arch-all.unusedbd.real <==
libglib2.0-bin=2.40.0-3

==> avahi_0.6.31-4.arch-all.unusedbd.real <==
python-all-dev=2.7.6-2

==> bc_1.06.95-8.arch-all.unusedbd.real <==
bison=2:3.0.2.dfsg-2
libreadline-dev:amd64=6.3-6

==> bison_3.0.2.dfsg-2.arch-all.unusedbd.real <==
autotools-dev=20140510.1

==> blcr_0.8.5-2.1.arch-all.unusedbd.real <==
autoconf=2.69-6
automake=1:1.14.1-3
autotools-dev=20140510.1
libtool=2.4.2-1.7

==> bluez_4.101-4.1.arch-all.unusedbd.real <==
bison=2:3.0.2.dfsg-2
gstreamer-tools=0.10.36-1.2

==> boost-defaults_1.55.0.2.arch-all.unusedbd.real <==
libboost1.55-dev:amd64=1.55.0+dfsg-1

==> ceph_0.80.1-1.arch-all.unusedbd.real <==
libboost-dev:amd64=1.55.0.2
libboost-system-dev:amd64=1.55.0.2
python-all=2.7.6-2
uuid-runtime=2.20.1-5.7

==> chicken_4.8.0.5-1.arch-all.unusedbd.real <==
texinfo=5.2.0.dfsg.1-3

==> cloog_0.18.2-1.arch-all.unusedbd.real <==
texinfo=5.2.0.dfsg.1-3

==> cpio_2.11+dfsg-2.arch-all.unusedbd.real <==
texinfo=5.2.0.dfsg.1-3

==> cunit_2.1-2.dfsg-1.arch-all.unusedbd.real <==
quilt=0.63-2

==> cups-filters_1.0.53-1.arch-all.unusedbd.real <==
sharutils=1:4.14-2

==> curl_7.37.0-1.arch-all.unusedbd.real <==
ca-certificates=20140325
openssh-server=1:6.6p1-5
python=2.7.6-2

==> db5.3_5.3.28-3.arch-all.unusedbd.real <==
gcj-native-helper=2:1.7-52

==> dbus-python_1.2.0-2.arch-all.unusedbd.real <==
xmlto=0.0.25-2

==> dbus_1.8.2-1.arch-all.unusedbd.real <==
python=2.7.6-2

==> devscripts_2.14.4.arch-all.unusedbd.real <==
libjson-perl=2.61-1
libterm-size-perl=0.207-1+b1

==> doxygen_1.8.7-1.arch-all.unusedbd.real <==
texlive-extra-utils=2014.20140528-2

==> e2fsprogs_1.42.10-1.arch-all.unusedbd.real <==
m4=1.4.17-4

==> ecj_3.9.0-2.arch-all.unusedbd.real <==
python=2.7.6-2

==> eglibc_2.18-7.arch-all.unusedbd.real <==
autoconf=2.69-6
quilt=0.63-2

==> exiv2_0.23-1.arch-all.unusedbd.real <==
autotools-dev=20140510.1
dh-linktree=0.4
libjs-jquery=1.7.2+dfsg-3

==> fastjar_0.98-5.arch-all.unusedbd.real <==
texinfo=5.2.0.dfsg.1-3

==> fftw3_3.3.4-1.arch-all.unusedbd.real <==
ghostscript=9.05~dfsg-8.1
transfig=1:3.2.5.e-3

==> findlib_1.4.1-1.arch-all.unusedbd.real <==
gawk=1:4.1.1+dfsg-1

==> flite_1.4-release-8.arch-all.unusedbd.real <==
ghostscript=9.05~dfsg-8.1

==> fontconfig_2.11.0-5.arch-all.unusedbd.real <==
gperf=3.0.4-1

==> freeglut_2.8.1-2.arch-all.unusedbd.real <==
libxt-dev:amd64=1:1.1.4-1

==> freetds_0.91-6.arch-all.unusedbd.real <==
libreadline-dev:amd64=6.3-6

==> gdb_7.6.2-1.1.arch-all.unusedbd.real <==
autoconf=2.69-6
flex=2.5.39-7
gcj-jdk=4:4.9.0-1
gobjc=4:4.8.2-4
libtool=2.4.2-1.7
procps=1:3.3.9-5

==> geoclue-2.0_2.1.8-1.arch-all.unusedbd.real <==
geoip-database=20140509-1

==> geoip_1.6.0-1.arch-all.unusedbd.real <==
zlib1g-dev:amd64=1:1.2.8.dfsg-1

==> ghostscript_9.05~dfsg-8.1.arch-all.unusedbd.real <==
freeglut3-dev:amd64=2.8.1-2

==> gnome-keyring_3.12.0-2.arch-all.unusedbd.real <==
ca-certificates=20140325
docbook-xml=4.5-7.2
libglib2.0-doc=2.40.0-3
libtasn1-3-dev=3.6-1

==> gnome-vfs_2.24.4-4.arch-all.unusedbd.real <==
libattr1-dev:amd64=1:2.4.47-1

==> gpac_0.5.0+svn5194~dfsg1-3.arch-all.unusedbd.real <==
libxmlrpc-c3-dev=1.16.33-3.2

==> gpm_1.20.4-6.1.arch-all.unusedbd.real <==
texi2html=1.82+dfsg1-3
texlive-base=2014.20140528-3

==> graphviz_2.26.3-17.arch-all.unusedbd.real <==
pdksh=49-2

==> gsl_1.16+dfsg-1.arch-all.unusedbd.real <==
libtool=2.4.2-1.7

==> gst-plugins-base0.10_0.10.36-1.1.arch-all.unusedbd.real <==
gir1.2-freedesktop=1.40.0-2
gir1.2-glib-2.0=1.40.0-2

==> gst-plugins-base1.0_1.2.4-1.arch-all.unusedbd.real <==
gir1.2-freedesktop=1.40.0-2

==> gstreamer1.0_1.2.4-1.arch-all.unusedbd.real <==
gir1.2-freedesktop=1.40.0-2
libgmp3-dev=2:6.0.0+dfsg-4

==> gtest_1.7.0-3.arch-all.unusedbd.real <==
python=2.7.6-2

==> gtk+2.0_2.24.23-1.arch-all.unusedbd.real <==
libatk1.0-doc=2.12.0-1
libcairo2-doc=1.12.16-2
libglib2.0-doc=2.40.0-3
libpango1.0-doc=1.36.3-1

==> gtk+3.0_3.12.2-1.arch-all.unusedbd.real <==
gsettings-desktop-schemas=3.8.2-2

==> gtkglext_1.2.0-3.1.arch-all.unusedbd.real <==
autotools-dev=20140510.1

==> heimdal_1.6~rc2+dfsg-6.arch-all.unusedbd.real <==
libperl4-corelibs-perl=0.003-1

==> hunspell_1.3.2-7.arch-all.unusedbd.real <==
libreadline-dev:amd64=6.3-6

==> hwloc_1.9-3.arch-all.unusedbd.real <==
autotools-dev=20140510.1
doxygen-latex=1.8.7-1
help2man=1.45.1
transfig=1:3.2.5.e-3

==> ijs_0.35-10.arch-all.unusedbd.real <==
docbook-utils=0.6.14-3
docbook=4.5-5.1
ghostscript=9.05~dfsg-8.1

==> klibc_2.0.3-1.arch-all.unusedbd.real <

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Julian Taylor (2014-07-07 14:14:20)
> There seem to be a bunch of false positives for virtual/metapackages:
> 
> ==> python-numpy_1.8.1-1.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
> python-all-dbg=2.7.6-2
> python-all-dev=2.7.6-2
> python3-all-dbg=3.4.1~rc1-1
> python3-all-dev=3.4.1~rc1-1
> 
> the -all packages are basically empty packages pulling in all python
> versions supported, those packages are definitely used during the
> build.
> Removing them during an arch-any build should fail the build.  does sbuild
> --arch-all only build the indep part?

Sorry, I attached the wrong files in my first email. I posted a follow up with
the correct results which correctly do not contain the empty packages anymore.

> If so that might explain why your pass2 did not remove these, but so far I
> know we have no way to declare this state in our control, we only have
> Build-Depends and Build-Depends-Indep, no Build-Depends-Arch.

Was Build-Depends-Arch not added with #629480?

> Similar fftw3:
> ==> fftw3_3.3.4-1.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
> ghostscript=9.05~dfsg-8.1
> mpi-default-dev=1.0.2+nmu1
> transfig=1:3.2.5.e-3
> 
> mpi-default-dev is not used directly but its dependencies are required
> for the fully featured arch any build.

Same story as above. Sorry for the confusion :(

cheers, josch


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

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Henrique de Moraes Holschuh (2014-07-07 14:07:26)
> Please don't assume that the unused build dependency is always where the
> defect is.  Rather, the MBF text should account for the possibility that the
> unused build-dependency should have been used in the first place, but
> something is broken in the build and it is being left unused.

you are correct, this should be mentioned. Here the updated text:

--%<---
Dear Maintainer,

the build dependencies $foo, $bar and $baz of this source package do not seem
to be needed. Neither are any of their files accessed during the build nor are
their dependencies on other binary packages required.

This can either mean that the build dependency is superfluous and should be
removed to make bootstrapping easier or it indicates a bug where a package
should be used but is in fact not. Please remove the build dependency from the
Build-Depends in the former case or fix the build procedure in the latter.

You can find more detail about the procedures that were used to find this
problem in the MBF announcement on debian-devel: $email

-->%---

thank you!

cheers, josch


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

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

and the updated dd-list

Sorry for not having attached the right files in my initial email :(

cheres, josch
"Adam C. Powell, IV" 
   mpi-defaults (U)

Adam Conrad 
   eglibc (U)
   freetds (U)

Alan Woodland 
   blcr

Alessandro Ghedini 
   curl
   valgrind

Alessio Treglia 
   gpac (U)

Alexander Wirt 
   rrdtool (U)

Andreas Barth 
   netpbm-free

Andreas Henriksson 
   gnome-keyring (U)
   gtk+3.0 (U)
   libarchive (U)
   libgnome-keyring (U)
   libsecret (U)
   libsoup2.4 (U)

Andreas Metzler 
   libtasn1-6 (U)

Andreas Rottmann 
   libglade2

Andres Mejia 
   gpac (U)
   libarchive (U)

Andrew Moise 
   open-iscsi (U)

Anibal Monsalve Salazar 
   cpio
   libidn (U)
   libmnl
   xfsprogs (U)

Anton Gladky 
   freeglut

APT Development Team 
   apt
   python-apt

Arnaud Fontaine 
   xcb-util (U)
   xcb-util-image (U)
   xcb-util-keysyms (U)
   xcb-util-renderutil (U)
   xcb-util-wm (U)

Arno Töll 
   apache2 (U)

Aron Xu 
   libxml2 (U)
   netcat-openbsd

Atsuhito KOHDA 
   lynx-cur

Aurelien Jarno 
   eglibc (U)
   libusb
   libusb-1.0
   qemu (U)

Bart Martens 
   gtkglext

Bastian Blank 
   parted (U)
   redhat-cluster (U)
   xen (U)

Bastien ROUCARIÈS 
   ghostscript (U)

Benjamin Drung 
   devscripts (U)

Benjamin Kaduk 
   krb5 (U)

Bernd Zeimetz 
   rrdtool (U)

Brian May 
   heimdal

Ceph Maintainers 
   ceph

Chris Halls 
   hunspell (U)

Christian Perrier 
   apt (U)

Christoph Martin 
   openssl (U)

Chuan-kai Lin 
   bison

Clint Adams 
   eglibc (U)

Colin Watson 
   parted (U)

Craig Andrews 
   geoclue-2.0 (U)

Cyril Brulebois 
   libxkbcommon (U)
   xfonts-utils (U)

Damien Raude-Morvan 
   openjdk-7 (U)

Daniel Leidert (dale) 
   libxml-parser-perl (U)
   xmlto (U)

Dave Beckett 
   redland

Davide Puricelli (evo) 
   chicken

Debian Accessibility Team 
   at-spi2-atk
   flite

Debian Apache Maintainers 
   apache2
   apr-util

Debian Berkeley DB Group 
   db5.3

Debian Bluetooth Maintainers 
   bluez

Debian Boost Team 
   boost-defaults

Debian GCC Maintainers 
   cloog
   libffi

Debian GNOME Maintainers 
   gnome-keyring (U)
   gnome-vfs (U)
   gtk+2.0
   gtk+3.0
   libglade2 (U)
   libgnome-keyring
   libsecret
   libsoup2.4
   pango1.0
   pygobject-2 (U)
   pygtk (U)

Debian GnuTLS Maintainers 
   libtasn1-6

Debian HA Maintainers 
   redhat-cluster

Debian iSCSI Maintainers 
   open-iscsi

Debian Java Maintainers 
   ecj
   zookeeper

Debian KDE Extras Team 
   exiv2

Debian Libarchive Maintainers 
   libarchive

Debian Libidn Team 
   libidn

Debian LibreOffice Maintainers 
   hunspell

Debian Multimedia Maintainers 

   gpac
   x264

Debian OCaml Maintainers 
   findlib
   ocaml

Debian OpenLDAP Maintainers 
   openldap

Debian OpenSSL Team 
   openssl

Debian Perl Group 
   libxml-parser-perl

Debian PHP Maintainers 
   php5

Debian Printing Team 
   cups-filters
   ghostscript
   ijs

Debian Python Modules Team 
   markupsafe (U)
   python-numpy

Debian QA Group 
   graphviz
   readline5

Debian QEMU Team 
   qemu

Debian Qt/KDE Maintainers 
   qca2
   qt4-x11
   qtbase-opensource-src
   qtwebkit

Debian RRDtool Team 
   rrdtool

Debian Samba Maintainers 
   tdb

Debian Science Team 
   fftw3
   mpi-defaults

Debian Tcl/Tk Packagers 
   tcltk-defaults

Debian TeX Maintainers 
   texlive-bin

Debian TeX maintainers 
   texinfo

Debian X Strike Force 
   libxkbcommon
   xcb-util
   xcb-util-image
   xcb-util-keysyms
   xcb-util-renderutil
   xcb-util-wm
   xfonts-utils
   xutils-dev

Debian Xen Team 
   xen

Debian Xiph.org Maintainers 
   libtheora

Debian XML/SGML Group 
   libxml2
   xmlto

Devscripts Devel Team 
   devscripts

Didier Raboud 
   cups-filters (U)

Dirk Eddelbuettel 
   gsl

Dmitrijs Ledkovs 
   db5.3 (U)

Dmitry Shachnev 
   qtbase-opensource-src (U)

Dmitry Smirnov 
   ceph (U)

Dominique Belhachemi 
   torque (U)

Emilio Pozuelo Monfort 
   gnome-keyring (U)
   gnome-vfs (U)
   gtk+2.0 (U)
   gtk+3.0 (U)
   libsoup2.4 (U)
   pango1.0 (U)
   pygtk (U)
   vala-0.24 (U)

Enrico Tassi 
   lua5.1 (U)
   lua5.2

Eric Dorland 
   libtasn1-6 (U)

Fabian Greffrath 
   x264 (U)

Fathi Boudra 
   exiv2 (U)
   qt4-x11 (U)
   qtbase-opensource-src (U)
   qtwebkit (U)

Felix Geyer 
   qca2 (U)

Francesco Paolo Lovergine 
   tcltk-defaults (U)

Frank Küster 
   texinfo (U)

Frank Küster 
   texlive-bin (U)

Frederik Schüler 
   redhat-cluster (U)

GD team 
   libgd2

Ghe Rivero 
   radvd

Giuseppe Iuculano 
   gtest (U)

GNU Libc Maintainers 
   eglibc

Guido Günther 
   open-iscsi (U)
   redhat-cluster (U)

Guido Trotter 
   xen (U)

Guus Sliepen 
   libdc1394-22
   libraw1394

Helmut Grohne 
   doxygen (U)

Hideki Yamane 
   net-snmp (U)

Héctor Orón Martínez 
   gdb

Ian Jackson 
   curl (U)

James McCoy 
   devscripts (U)

James Page 
   zookeeper (U)

James Page 
   ceph (U)

James Westby 
   libtasn1-6 (U)

Jan Niehusmann 
   qca2 (U)

Jason Thomas 
   tidy

Jay Berkenbilt 
   tiff

Jelmer Vernooij 
   heimdal (U)
   tdb (U)

Jeremy Bicha 
   libsecret (U)

Jochen 

Re: possible MBF: automatically detecting unused build dependencies

[Julian Taylor]

On Mon, Jul 7, 2014 at 2:23 PM, Johannes Schauer  wrote:
> Hi,
>
> Quoting Julian Taylor (2014-07-07 14:14:20)

>
>> If so that might explain why your pass2 did not remove these, but so far I
>> know we have no way to declare this state in our control, we only have
>> Build-Depends and Build-Depends-Indep, no Build-Depends-Arch.
>
> Was Build-Depends-Arch not added with #629480?
>

neat, I have been looking in the policy for the tag where it is
currently not mentioned (probably bug #727610)


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

Bug#754086: ITP: vim-ultisnips -- snippet solution for Vim

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: vim-ultisnips
  Version : 3.0
  Upstream Author : Holger Rapp 
* URL : https://github.com/SirVer/ultisnips
* License : GPL-3+
  Programming Lang: Python, Vim
  Description : snippet solution for Vim

UltiSnips provides snippet management for the Vim editor. A snippet is a short
piece of text that is either re-used often or contains a lot of redundant
text. UltiSnips allows you to insert a snippet with only a few key strokes.
Snippets are common in structured text like source code but can also be used
for general editing like, for example, inserting a signature in an email or
inserting the current date in a text file.
..
This plugin can utilize the snippets provided by the vim-snippets package.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTupatAAoJEGlMre9Rx7W2zusP/20ju9pNGV2mq/PkU5GfD1aY
tJIQ4S8BROE1aOBkqhySSV7zn+8Vj2f1tptLV0VFvRRsakYuMb+ZUXuw3jrcwEdC
rx4iaFqp/jN6sRoXe4AWriMNB+3CzMV/1Bw8uq3rPR2LEX8anDAksHiEuh4558pI
kM9R6g9ws6qMDDEexd4ec4aiscgGdf3MVPgkAWerIpJA9VOCqiavn9kxzf5r2nzu
dFzD5YjI0PSindDXYcUrxsQn0YZ9MoOBmqh2jkfTjGLQoW2hvdQ9xvZoKX4q/bSm
l47WuvH8DJNj9wL2XYMjfNPVDC7gPwaz7sL8zqdTjJU0c+ICGGD5I1i/3GvsEcFo
lOWymPCiwNoI2LGnPTWF5Q4OQxPFf8czDngHKXKb9v3ct4vFLJwtSA4/R9S1bRE2
b2k/B80/rqJUq8D6j4X0CA6habzPtO0UF4o0wMzsA63pqtppq16s612l8kHCdjtr
e7EqVuoKV7IUVsa/1wZ8Nqh7vMDCwYm61H2tRjq6RBx6wcS1mB4U6XJCmLMHjZlD
7UUC2Bw+EFYH9X0p/vun8TkrxVE162aWRJU1BJkavlxWB6A1JThApmc1wWDus4SL
4l45nYTFVxPpCo8qtmZS4vRiO7qLgjaweqSyBBzem7sYu8lUYdFw0iV7Doj2TIVo
3LaER1sy37RUsMYt4gMa
=a+lV
-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: 
https://lists.debian.org/20140707124640.31986.4937.report...@server.home.fladi.at

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Jérémy Lal (2014-07-07 14:12:19)
> Consider also the case when arch:all package require a build dependency on a
> package that only builds on some archs, to prevent the arch:all package being
> available on archs where its dependencies are not.  nodejs and node-*
> packages are such an example.

could you clarify this case? An arch:all package cannot require a build
dependency because an arch:all package is a binary package. I can also not find
any nodejs packages in the lists I posted. In fact, nodejs package have not yet
been a problem with respect to bootstrapping - probably because they are mostly
arch:all?

cheers, josch


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

Re: possible MBF: automatically detecting unused build dependencies

[Jérémy Lal]

Le lundi 07 juillet 2014 à 15:32 +0200, Johannes Schauer a écrit :
> Hi,
> 
> Quoting Jérémy Lal (2014-07-07 14:12:19)
> > Consider also the case when arch:all package require a build dependency on a
> > package that only builds on some archs, to prevent the arch:all package 
> > being
> > available on archs where its dependencies are not.  nodejs and node-*
> > packages are such an example.
> 
> could you clarify this case? An arch:all package cannot require a build
> dependency because an arch:all package is a binary package. I can also not 
> find
> any nodejs packages in the lists I posted. In fact, nodejs package have not 
> yet
> been a problem with respect to bootstrapping - probably because they are 
> mostly
> arch:all?

Yep, sorry for the confusion.

Jérémy.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404740047.4416.11.camel@imac.chaumes

Re: Sources licensed under PHP License and not being PHP are not distributable

[Paul R. Tagliamonte]

Unless its renamed AFAICT.
   T
On Jul 7, 2014 4:19 AM, "The Wanderer"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 07/07/2014 03:39 AM, Thomas Goirand wrote:
>
> > On 07/01/2014 05:22 AM, Clint Byrum wrote:
> >
> >> Unless I'm mistaken, the wording in the PHP license makes it
> >> invalid for anybody that isn't actually the PHP project to use
> >> without making a false claim that "THIS SOFTWARE IS PROVIDED BY THE
> >> PHP DEVELOPMENT TEAM".
> >
> > IMO, you are mistaking indeed. Anyone contributing a module to
> > pear.php.net PEAR channel can be considered from the "PHP development
> > team". That's a question of view, and we've accepted that view, so
> > why should we go back after we have accepted packages based on this?
> > This is also the view of upstream PHP (the language) and upstream
> > PEAR module contributors, as much as one can tell. If you do not
> > agree, please point to anyone who expressed otherwise.
>
> One question / consideration:
>
> Even assuming that all contributions accepted into modules hosted on
> pear.php.net are considered automatically "from the PHP Development
> Team", and thus that the statement in the license would remain accurate,
> wouldn't this mean that it wouldn't be possible to make local
> modifications to a module found there and distribute them by other means
> (e.g. even within one's own organization) without either making a false
> statement in the license or violating the license?
>
> If it would mean that, then wouldn't this license be considered non-free?
>
> - --
>The Wanderer
>
> Secrecy is the beginning of tyranny.
>
> A government exists to serve its citizens, not to control them.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCgAGBQJTulf7AAoJEASpNY00KDJrwQAP/RpzgNpYlYULpqOyJK/uwbza
> MrT+23bQ/1OLy5KaGdPYvWUGpXw2JHxJaMEBchLTVjL2c3I+mgBW9kZ/qDalwpdf
> 36KZxdhOJi8bHCmbd13rOYu9pZr+DFLCivt63L3xRaz4V0RnO0ijbJYvuu+VNiL9
> mABrxbQNo/hDR6NnpFUiw1Ze09JnN0dbrRUhOE0uPDvESd9wusSkvh36hy63WEvi
> uaP+zUiGA2rGlB5WFRV1CVJH0gsLtSJKSbvSdk5hJGs7EbZjrE63jCnaGiNohufj
> X5JFuzWuD2moiLIg/3kaZ6mj8zbEtP9TR4ND01NnRrTDpC2vO8Rkc0HsmOPXgKQ5
> EFBgKsAp0XWy/T+rUltUppQEHq8bX22yQYjN/b6LFA4DzBmkBpGDCIWK+Q8W+Ewq
> tm0UtpK+5se7U0M6xtb0E+VpFC80KnC1bUFal0ipebR7YCXEXI9ESnjZ2IIE0nLW
> BWmUD6n+3zNzDVmqn8gNCReVUAAave0rYxwvZlvFDJVAz6ZRlZpLLtUdPWOmmtAg
> 0C9RKSHCL4D25VgsCAm/2T5DtvBeGbDudPzzFuROuCqtnnXiDDYkGaBOQv7Ebohd
> pQbXIXEqpImirEAX2fvJGpMSy+xnlZO3XaranRUYLKN64+m4gYsALuU2OR5rO4Ew
> yGDyB6SltUMNJWB+rM0D
> =Xij/
> -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: https://lists.debian.org/53ba57fb.5070...@fastmail.fm
>
>

Bug#754104: general: Repetitive message "hub 1-0:1.0: unable to enumerate USB device on port 3"

[Marius]

Package: general
Severity: normal
Tags: d-i

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

It seems that buf occured after last system upgrade (apt-get upgrade)



-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Re: Sources licensed under PHP License and not being PHP are not distributable

[Thomas Goirand]

On 07/07/2014 04:19 PM, The Wanderer wrote:
> On 07/07/2014 03:39 AM, Thomas Goirand wrote:
> 
>> On 07/01/2014 05:22 AM, Clint Byrum wrote:
> 
>>> Unless I'm mistaken, the wording in the PHP license makes it
>>> invalid for anybody that isn't actually the PHP project to use
>>> without making a false claim that "THIS SOFTWARE IS PROVIDED BY THE
>>> PHP DEVELOPMENT TEAM".
> 
>> IMO, you are mistaking indeed. Anyone contributing a module to 
>> pear.php.net PEAR channel can be considered from the "PHP development
>> team". That's a question of view, and we've accepted that view, so
>> why should we go back after we have accepted packages based on this?
>> This is also the view of upstream PHP (the language) and upstream
>> PEAR module contributors, as much as one can tell. If you do not
>> agree, please point to anyone who expressed otherwise.
> 
> One question / consideration:
> 
> Even assuming that all contributions accepted into modules hosted on
> pear.php.net are considered automatically "from the PHP Development
> Team", and thus that the statement in the license would remain accurate,
> wouldn't this mean that it wouldn't be possible to make local
> modifications to a module found there and distribute them by other means
> (e.g. even within one's own organization) without either making a false
> statement in the license or violating the license?
> 
> If it would mean that, then wouldn't this license be considered non-free?

Unless I'm mistaking, there's no sign that the PHP license prevents
derivative work (even under a different license for your patch, if you
feel like it).

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bab9d5.8030...@debian.org

Bug#754104: marked as done (general: Repetitive message "hub 1-0:1.0: unable to enumerate USB device on port 3")

[Debian Bug Tracking System]

Your message dated Mon, 7 Jul 2014 17:16:18 +0200
with message-id <201407071716.19681.hol...@layer-acht.org>
and subject line Re: Bug#754104: general: Repetitive message "hub 1-0:1.0: 
unable to enumerate USB device on port 3"
has caused the Debian Bug report #754104,
regarding general: Repetitive message "hub 1-0:1.0: unable to enumerate USB 
device on port 3"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
754104: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754104
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal
Tags: d-i

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

It seems that buf occured after last system upgrade (apt-get upgrade)



-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

sounds like faulty hardware, maybe. 

I'm closing this bug, as the BTS is not for user support, as one example for 
that see http://lists.debian.org/debian-user/ 


cheers,
Holger


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

Bug#754104: closed by Holger Levsen (Re: Bug#754104: general: Repetitive message "hub 1-0:1.0: unable to enumerate USB device on port 3")

[Marius Malakauskas]

Hi,

I don't think that is hardware fault. I've second (boot) OS: Kali Linux
(based on Debian) and there are not some kind of messages about  "enumerate
USB device".

It seems to me that problem can exists with kernel or modules (maybe
configuration of ones). You can tell me where I can explore more about
error on system myself if you think it isn't serious bug.


On Mon, Jul 7, 2014 at 6:21 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the general package:
>
> #754104: general: Repetitive message "hub 1-0:1.0: unable to enumerate USB
> device on port 3"
>
> It has been closed by Holger Levsen .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Holger Levsen <
> hol...@layer-acht.org> by
> replying to this email.
>
>
> --
> 754104: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754104
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Holger Levsen 
> To: 754104-d...@bugs.debian.org
> Cc:
> Date: Mon, 7 Jul 2014 17:16:18 +0200
> Subject: Re: Bug#754104: general: Repetitive message "hub 1-0:1.0: unable
> to enumerate USB device on port 3"
> Hi,
>
> sounds like faulty hardware, maybe.
>
> I'm closing this bug, as the BTS is not for user support, as one example
> for
> that see http://lists.debian.org/debian-user/
>
>
> cheers,
> Holger
>
>
> -- Forwarded message --
> From: Marius 
> To: Debian Bug Tracking System 
> Cc:
> Date: Mon, 07 Jul 2014 18:11:44 +0300
> Subject: general: Repetitive message "hub 1-0:1.0: unable to enumerate USB
> device on port 3"
> Package: general
> Severity: normal
> Tags: d-i
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> It seems that buf occured after last system upgrade (apt-get upgrade)
>
>
>
> -- System Information:
> Debian Release: 7.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
>


-- 
Marius Malakauskas

Re: possible MBF: automatically detecting unused build dependencies

[Ryan Tandy]

On Mon, Jul 7, 2014 at 4:51 AM, Johannes Schauer  wrote:
> ==> openldap_2.4.39-1.arch-all.unusedbd <==
> debconf-utils=1.5.53

I think that's valid. According to debian/changelog, that B-D was
added long ago for debconf-mergetemplate, but if I'm reading correctly
it seems to be unused since switching to dh_installdebconf. A test
build with debconf-utils removed succeeded. Fixed in git, thanks!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAMXH3QCfC_4LOipR2ioRLAi=hipyiv+4ro-kzta0ieqyipb...@mail.gmail.com

Re: dpkg-source to automatically add a Testsuite field

[Antonio Terceiro]

On Sun, Jul 06, 2014 at 06:35:47PM +0200, Guillem Jover wrote:
> Hi!
> 
> Given that dpkg-dev has recognized the Testsuite field for some time,
> I don't really see a reason for dpkg-source not to automatically add
> it to the generated .dsc with an “autopkgtest” value if there is a
> debian/tests/control file around, instead of requiring maintainers
> to remember to set it manually.

Quite a few maintainers already asked me why their packages weren't
being picked up by ci.debian.net, and when I went look at it, the reason
was that they forgot to add the Testsuite field to debian/control.
Having this automated in dpkg-source is really appreciated, thank you!

> Reading the spec [S], it seems to me that the file can be empty, as it
> states “This is a file containing zero or more RFC822-style stanzas”,
> so the code cannot do any sanity check, like checking if the file
> contains one stanza with a Tests field. So it will only check for the
> file presence.
> 
>   [S] 
> 
> 
> I've queued a patch doing exactly that for dpkg 1.17.11. If there's
> any known reservations with that, please speak up.

How will it handle an existing value in that field? In the future, we
might have other forms of test suite, thus requiring different items in
the Testsuite: field.  What happens when there is already

  Testsuite: foo

and dpkg-source detects the presence of debian/tests/control? Will it
merge `autopkgtest` into the list, or will it replace the existing
value?

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

Hi Johannes,

On Mon, Jul 07, 2014 at 02:37:02PM +0200, Johannes Schauer wrote:
> Steve Langasek 
>freetds
>openldap (U)
>pam
>unixodbc

There seem to still be some false positives here.  pam is on the list
because of a build-dependency on libdb-dev, freetds and unixodbc are there
because of a build-dependency on libreadline-dev.  Both of these are
metapackages that pull in version-specific -dev packages.  So something
seems to be wrong with the detection of "empty" packages yet?

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


signature.asc
Description: Digital signature

Re: Debian.

[Scott Howard]

On Mon, Jul 7, 2014 at 5:23 AM, Dan Rulos  wrote:
> How are you developing debian? I need to develop a new linux distro
> based on debian squeeze, how can i ? Thanks. I'm 14 years old spanish
> and my english is not perfect.

That's great that you are interested and learning at a young age!
If you are interested in your own "distribution", I think it's good to
check out Debian Pure Blends [1]. They used to be called "Custom
Debian Distributions," which may be what you are looking for.
Regards,
Scott
[1] http://blends.debian.org/blends/


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

Re: systemd is here to stay, get over it now

[Josselin Mouette]

Le vendredi 04 juillet 2014 à 15:09 +0200, Stephan Seitz a écrit : 
> But if they don’t want the systemd features why should they write 
> software to replace systemd?

If they don’t need any of the systemd features, I guess they don’t need
any of its reverse dependencies either.

So why do they complain about “stealth installation” of systemd?

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404751377.14436.849.camel@dsp0698014

Re: Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[costamagnagianfra...@yahoo.it]

Hi Steffen and all,

today while talking with a backbox project administrator I discovered that 
popular tools such as openvas directly calls the amap binary.

I never talked with them, but I don't think it is feasible to ask to every 
security tool provider to patch their code for the only debian benefit.

I think I'm then changing again my opinion: the conflict field might be the 
only proper way to be sure such popular tools (not packaged in debian and some 
of them not even free) continue to work.

Is this one a good reason for a conflict?

Thanks for reading,

Gianfranco, who really don't want this kind of flame wars in such a beautiful 
project as debian.

Sent from Yahoo Mail on Android

Bug#754118: ITP: python-taskthread -- Simple thread module to repetitively perform a task on a single thread

[Ben Carrillo]

Package: wnpp
Severity: wishlist
Owner: Ben Carrillo 

* Package name: python-taskthread
  Version : 1.4
  Upstream Author : John Herndon 
* URL : http://hpcloud.com/
* License : Apache 2
  Programming Lang: Python
  Description : Simple thread module to repetitively perform a task on a 
single thread

Python thread module to repeat an predefined task on a thread mulitple
times. A TaskThread is useful when a task needs to be repeated several
times on a separate thread. Normal usage of the threading.Thread class
would call for creation of a new thread each time the same task needs to
be run. This module allows for repetitive tasks to be run multiple times
on the same thread by having the thread wait until the task needs to be
executed again.


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

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2014-07-07 18:36:50)
> There seem to still be some false positives here.  pam is on the list because
> of a build-dependency on libdb-dev, freetds and unixodbc are there because of
> a build-dependency on libreadline-dev.  Both of these are metapackages that
> pull in version-specific -dev packages.  So something seems to be wrong with
> the detection of "empty" packages yet?

Empty packages are not "detected". The first phase will find empty packages
because they do not contain any files and thus they are detected as build
dependencies of which no files were used. Since empty packages are mostly meta
packages and we do not want to include them, we replace them by a fake equivs
package without dependencies. If the build still succeeds, that means that the
meta package is indeed not needed.

Lets find out what happens here. Steps to reproduce:

$ sudo debootstrap sid debian-sid
# the pam build needs /proc mounted
$ sudo mount -o bind /proc debian-sid/proc
$ sudo chroot debian-sid
$ echo "deb-src http://ftp.us.debian.org/debian sid main" >> 
/etc/apt/sources.list
$ apt-get update
$ apt-get install build-essential equivs
$ apt-cache show libdb-dev | grep -v "^Depends:" | grep -v "^Conflicts:" | 
equivs-build -
$ dpkg -i libdb-dev_5.3.0_amd64.deb
$ apt-get build-dep pam
$ dpkg -l | grep libdb
ii  libdb-dev  5.3.0amd64 Dummy package to fulfill package dependencies
ii  libdb5.3:amd64 5.3.28-5 amd64 Berkeley v5.3 Database Libraries [runtime]
$ apt-get source --build pam
[...]
$ echo $?
0

I get the same effect when replacing pam by freetds and unixodbc and libdb-dev
by libreadline-dev.

Can you point out at which step my error is?

Thanks!

cheers, josch


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

Re: Sources licensed under PHP License and not being PHP are not distributable

[Paul Tagliamonte]

On Mon, Jul 07, 2014 at 11:16:37PM +0800, Thomas Goirand wrote:
> Unless I'm mistaking, there's no sign that the PHP license prevents
> derivative work (even under a different license for your patch, if you
> feel like it).

It's my reading that this is the case if you rename your project to not
contain PHP (if it does), which would otherwise be violation of the license.

/
|  4. Products derived from this software may not be called "PHP", nor
| may "PHP" appear in their name, without prior written permission
| from gr...@php.net.  You may indicate that your software works in
| conjunction with PHP by saying "Foo for PHP" instead of calling
| it "PHP Foo" or "phpfoo"
\

> Thomas

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


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

On Mon, Jul 07, 2014 at 08:05:06PM +0200, Johannes Schauer wrote:
> Quoting Steve Langasek (2014-07-07 18:36:50)
> > There seem to still be some false positives here.  pam is on the list 
> > because
> > of a build-dependency on libdb-dev, freetds and unixodbc are there because 
> > of
> > a build-dependency on libreadline-dev.  Both of these are metapackages that
> > pull in version-specific -dev packages.  So something seems to be wrong with
> > the detection of "empty" packages yet?

> Empty packages are not "detected". The first phase will find empty
> packages because they do not contain any files and thus they are detected
> as build dependencies of which no files were used.  Since empty packages
> are mostly meta packages and we do not want to include them, we replace
> them by a fake equivs package without dependencies.  If the build still
> succeeds, that means that the meta package is indeed not needed.

Ah.  No, it only means that the package build does not *fail* if the
build-dependency is removed.  That is not the same thing as saying that the
build-dependency is not used.

It would of course be better if packages were resilient against breakage in
their build-dependencies, instead of misbuilding with features disabled or
with wrong fallback code.  But this isn't easy to do in all build systems,
and anyway this isn't something we routinely audit about our packages; we
shouldn't regard this as a bug to be reported without a lot more discussion
of how we're going to systematically stay on top of those issues in the
future.

For your purposes, a better method would be:

 - identify those build-dependencies which are empty except for
   /usr/share/doc
 - for each such package, look at the contents of its direct dependencies
 - check the build against those contents


> Lets find out what happens here. Steps to reproduce:

> $ sudo debootstrap sid debian-sid
> # the pam build needs /proc mounted
> $ sudo mount -o bind /proc debian-sid/proc
> $ sudo chroot debian-sid
> $ echo "deb-src http://ftp.us.debian.org/debian sid main" >> 
> /etc/apt/sources.list
> $ apt-get update
> $ apt-get install build-essential equivs
> $ apt-cache show libdb-dev | grep -v "^Depends:" | grep -v "^Conflicts:" | 
> equivs-build -
> $ dpkg -i libdb-dev_5.3.0_amd64.deb
> $ apt-get build-dep pam
> $ dpkg -l | grep libdb
> ii  libdb-dev  5.3.0amd64 Dummy package to fulfill package 
> dependencies
> ii  libdb5.3:amd64 5.3.28-5 amd64 Berkeley v5.3 Database Libraries [runtime]
> $ apt-get source --build pam
> [...]
> $ echo $?
> 0

> I get the same effect when replacing pam by freetds and unixodbc and libdb-dev
> by libreadline-dev.

> Can you point out at which step my error is?

For the case of pam, I would be interested in seeing the full build log to
understand how in the world this built successfully without libdb.  That's
definitely a packaging error on my part, because without libdb,
pam_userdb.so should not build, which in turn *should* be treated as a build
failure.  But I guess I'm not accounting for individual modules in the build
output, since in general the greater risk is failing to keep this list in
sync with new upstream modules, rather than misbuilding and losing a module
from the tree.

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


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Don Armstrong]

On Mon, 07 Jul 2014, Johannes Schauer wrote:
> Empty packages are not "detected". The first phase will find empty
> packages because they do not contain any files and thus they are
> detected as build dependencies of which no files were used. Since
> empty packages are mostly meta packages and we do not want to include
> them, we replace them by a fake equivs package without dependencies.
> If the build still succeeds, that means that the meta package is
> indeed not needed.

Unfortunately, this is not necessarily the case; some builds systems
disable "optional" functionality if the required build dependency is not
present, and still let the build complete.

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

Mozart tells us what it's like to be human, Beethoven tells us what
it's like to be Beethoven, and Bach tells us what it's like to be the
universe.
 -- Douglas Adams


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

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Don Armstrong (2014-07-07 20:33:37)
> On Mon, 07 Jul 2014, Johannes Schauer wrote:
> > Empty packages are not "detected". The first phase will find empty
> > packages because they do not contain any files and thus they are
> > detected as build dependencies of which no files were used. Since
> > empty packages are mostly meta packages and we do not want to include
> > them, we replace them by a fake equivs package without dependencies.
> > If the build still succeeds, that means that the meta package is
> > indeed not needed.
> 
> Unfortunately, this is not necessarily the case; some builds systems
> disable "optional" functionality if the required build dependency is not
> present, and still let the build complete.

correct. The exact problem here is that a meta package without any actual files
depends on a package without which the build will still successfully complete.

Usually, optional build dependencies are not registered as false positives
because the first pass does a full build with all build dependencies present.
Even if a build dependency could be optional it will not register in this pass
because its files will still be used.

The problem here is that the optional build dependency is not a direct
dependency of the source package.

I cannot think of an automated way to catch dependencies of meta packages
without which the build will still succeed. This of course except if there was
an easy way to compare the build output against the original binary package.
But that's doesnt seem possible yet without reproducible builds.

cheers, josch


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

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2014-07-07 20:22:42)
> Ah.  No, it only means that the package build does not *fail* if the
> build-dependency is removed.  That is not the same thing as saying that the
> build-dependency is not used.

you are correct. I expanded more on this in my other reply to Don Armstrong.

> It would of course be better if packages were resilient against breakage in
> their build-dependencies, instead of misbuilding with features disabled or
> with wrong fallback code.  But this isn't easy to do in all build systems,
> and anyway this isn't something we routinely audit about our packages; we
> shouldn't regard this as a bug to be reported without a lot more discussion
> of how we're going to systematically stay on top of those issues in the
> future.

I agree that it should not be a bug if a package does not fail if a certain
build dependency is not installed.

Nevertheless, those "false positives" that were generated this way are still
useful to be later marked with  once build profiles are
allowed in the archive because they are obviously droppable.

About "systematically staying on top of those issues" I do not know how to
proceed. I guess for that we would first need to know how many source packages
depend on meta packages which are not completely empty (besides /usr/share/doc)
and still silently fail and continue building with reduced features.

I did not plan to run this script more often yet. I'll probably do another run
after having added a detection for meta packages as suggested by you below.

Running it more regularly might not require any big discussion because the
"problem size" might be small enough that maintaining a white list would be
enough.

> For your purposes, a better method would be:
> 
>  - identify those build-dependencies which are empty except for
>/usr/share/doc
>  - for each such package, look at the contents of its direct dependencies
>  - check the build against those contents

While this would often work it would still miss some meta packages which do
ship some more files than /usr/share/doc but are otherwise mostly important
because of the packages they depend on. Though I guess this would already
tremendously decrease the amount of false positive (however high their number
is) and I should implement that for the next time I recalculate this.

> For the case of pam, I would be interested in seeing the full build log to
> understand how in the world this built successfully without libdb.  That's
> definitely a packaging error on my part, because without libdb, pam_userdb.so
> should not build, which in turn *should* be treated as a build failure.  But
> I guess I'm not accounting for individual modules in the build output, since
> in general the greater risk is failing to keep this list in sync with new
> upstream modules, rather than misbuilding and losing a module from the tree.

Sorry, I already deleted my chroot :(

cheers, josch


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

Re: possible MBF: automatically detecting unused build dependencies

[Julien Cristau]

On Mon, Jul  7, 2014 at 11:22:42 -0700, Steve Langasek wrote:

> For the case of pam, I would be interested in seeing the full build log to
> understand how in the world this built successfully without libdb.  That's
> definitely a packaging error on my part, because without libdb,
> pam_userdb.so should not build, which in turn *should* be treated as a build
> failure.  But I guess I'm not accounting for individual modules in the build
> output, since in general the greater risk is failing to keep this list in
> sync with new upstream modules, rather than misbuilding and losing a module
> from the tree.
> 
dh_install --fail-missing would help for the case where new modules are
added and need to be accounted for in the packaging.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG

[Ben Carrillo]

Package: wnpp
Severity: wishlist
Owner: Ben Carrillo 

* Package name: python-gnupg-ng
  Version : 1.2.6
  Upstream Author : Isis Lovecruft 
* URL : https://github.com/isislovecruft/python-gnupg
* License : GPL
  Programming Lang: Python
  Description : A Python wrapper for GnuPG

A Python interface for handling interactions with GnuPG, including
keyfile generation, keyring maintenance, import and export, encryption
and decryption, sending to and recieving from keyservers, and signing
and verification.
..
This is a fork of python-gnupg (from version 0.3.2), patched to
sanitize untrusted inputs, due to the necessity of executing
subprocess.Popen([...], shell=True) in order to communicate with GnuPG.
Several speed improvements were also made based on code profiling, and
the API has been cleaned up to support an easier, more Pythonic,
interaction.


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

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

On Mon, Jul 07, 2014 at 09:46:47PM +0200, Julien Cristau wrote:
> On Mon, Jul  7, 2014 at 11:22:42 -0700, Steve Langasek wrote:

> > For the case of pam, I would be interested in seeing the full build log
> > to understand how in the world this built successfully without libdb. 
> > That's definitely a packaging error on my part, because without libdb,
> > pam_userdb.so should not build, which in turn *should* be treated as a
> > build failure.  But I guess I'm not accounting for individual modules in
> > the build output, since in general the greater risk is failing to keep
> > this list in sync with new upstream modules, rather than misbuilding and
> > losing a module from the tree.

> dh_install --fail-missing would help for the case where new modules are
> added and need to be accounted for in the packaging.

Yes, I'm aware of the available techniques here; I am just not convinced
that a 40+ line debian/libpam-modules.install, with architecture-dependent
contents, is preferable to a two-line file with a single glob in terms of
overall maintainability.

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


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:
> Quoting Steve Langasek (2014-07-07 20:22:42)
> > Ah.  No, it only means that the package build does not *fail* if the
> > build-dependency is removed.  That is not the same thing as saying that the
> > build-dependency is not used.

> you are correct. I expanded more on this in my other reply to Don Armstrong.

> > It would of course be better if packages were resilient against breakage in
> > their build-dependencies, instead of misbuilding with features disabled or
> > with wrong fallback code.  But this isn't easy to do in all build systems,
> > and anyway this isn't something we routinely audit about our packages; we
> > shouldn't regard this as a bug to be reported without a lot more discussion
> > of how we're going to systematically stay on top of those issues in the
> > future.

> I agree that it should not be a bug if a package does not fail if a certain
> build dependency is not installed.

> Nevertheless, those "false positives" that were generated this way are still
> useful to be later marked with  once build profiles are
> allowed in the archive because they are obviously droppable.

No, marking build-dependencies with build profiles should be driven by what
is needed to break build-dep loops, not by what build-deps are "droppable"
without further modification of the packages.  Excessive stage1 profile
tagging will result in unnecessary extra builds during a bootstrap.

> I did not plan to run this script more often yet. I'll probably do another
> run after having added a detection for meta packages as suggested by you
> below.

> Running it more regularly might not require any big discussion because the
> "problem size" might be small enough that maintaining a white list would be
> enough.

If you really want to systematically detect misbuilds on missing
build-dependencies, it's a much bigger problem than just detecting this for
the build-dependencies which are metapackages.

In my personal opinion, this is not worth doing.  But if you are going to do
it, be comprehensive - anything less than that is counterproductive.

> > For your purposes, a better method would be:

> >  - identify those build-dependencies which are empty except for
> >/usr/share/doc
> >  - for each such package, look at the contents of its direct dependencies
> >  - check the build against those contents

> While this would often work it would still miss some meta packages which
> do ship some more files than /usr/share/doc but are otherwise mostly
> important because of the packages they depend on.  Though I guess this
> would already tremendously decrease the amount of false positive (however
> high their number is) and I should implement that for the next time I
> recalculate this.

There certainly will be other cases that this technique won't cover, but it
won't cause any false-negatives for your purposes.  I don't know what the
numbers will look like overall, but 3 out of 4 packages listed by my name
were false-positives that can be filtered out this way, so I definitely
think it's worth a rerun before MBF.

> > For the case of pam, I would be interested in seeing the full build log to
> > understand how in the world this built successfully without libdb.  That's
> > definitely a packaging error on my part, because without libdb, 
> > pam_userdb.so
> > should not build, which in turn *should* be treated as a build failure.  But
> > I guess I'm not accounting for individual modules in the build output, since
> > in general the greater risk is failing to keep this list in sync with new
> > upstream modules, rather than misbuilding and losing a module from the tree.

> Sorry, I already deleted my chroot :(

No worries... as previously suggested this is not high on my priority list
;)

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


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Wookey]

+++ Steve Langasek [2014-07-07 15:07 -0700]:
> On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:

> > I agree that it should not be a bug if a package does not fail if a certain
> > build dependency is not installed.
> 
> > Nevertheless, those "false positives" that were generated this way are still
> > useful to be later marked with  once build profiles are
> > allowed in the archive because they are obviously droppable.
> 
> No, marking build-dependencies with build profiles should be driven by what
> is needed to break build-dep loops, not by what build-deps are "droppable"
> without further modification of the packages.  Excessive stage1 profile
> tagging will result in unnecessary extra builds during a bootstrap.

Whilst I agree that a build-dep being droppable is not necessarily
sufficient reason to mark it as a stage1 profile, I don't agree with
your reasoning.

Having a profile available does not mean that it will necessarily be
used/built. The path through the bootstrap is determined by
currently-buildable and profilable packages. Having more profiles
marked just potentially gives us more possible routes through the
dependecny graph, which (up to a point) is generally a useful thing
with a new arch as you don't always know in advance which packages
will be most trouble. The chosen route is unlikely to use all the
profiles available unless there really are only just enough to do it
at all.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140707224831.gt10...@stoneboat.aleph1.co.uk

Re: possible MBF: automatically detecting unused build dependencies

[Holger Levsen]

Hi Johannes,

On Montag, 7. Juli 2014, Johannes Schauer wrote:
> About "systematically staying on top of those issues" I do not know how to
> proceed. I guess for that we would first need to know how many source
> packages depend on meta packages which are not completely empty (besides
> /usr/share/doc) and still silently fail and continue building with reduced
> features.
> 
> I did not plan to run this script more often yet. I'll probably do another
> run after having added a detection for meta packages as suggested by you
> below.
> 
> Running it more regularly might not require any big discussion because the
> "problem size" might be small enough that maintaining a white list would be
> enough.

I'd be happy to assist you getting it to run on jenkins.d.n, which is now a 15 
core / 30gb host, which can easily get a job configured testing this every 
three months (or whenever) on half the ressources or so

Please read the existing documentation (about link etc) and ping me (best via 
(#)debian-qa) for further kickstarting help..!


cheers,
Holger


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

Re: systemd is here to stay, get over it now

[Norbert Preining]

On Mon, 07 Jul 2014, Josselin Mouette wrote:
> If they don’t need any of the systemd features, I guess they don’t need
> any of its reverse dependencies either.

Rubbish. I want network-manager, but I don't want systemd.
NM was working long time without systemd.

Don't spread wrong information.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140707231306.gj23...@auth.logic.tuwien.ac.at

Re: dpkg-source to automatically add a Testsuite field

[Guillem Jover]

Hi!

On Mon, 2014-07-07 at 13:19:41 -0300, Antonio Terceiro wrote:
> On Sun, Jul 06, 2014 at 06:35:47PM +0200, Guillem Jover wrote:
> > Reading the spec [S], it seems to me that the file can be empty, as it
> > states “This is a file containing zero or more RFC822-style stanzas”,
> > so the code cannot do any sanity check, like checking if the file
> > contains one stanza with a Tests field. So it will only check for the
> > file presence.
> > 
> >   [S] 
> > 
> > 
> > I've queued a patch doing exactly that for dpkg 1.17.11. If there's
> > any known reservations with that, please speak up.
> 
> How will it handle an existing value in that field? In the future, we
> might have other forms of test suite, thus requiring different items in
> the Testsuite: field.  What happens when there is already
> 
>   Testsuite: foo
> 
> and dpkg-source detects the presence of debian/tests/control? Will it
> merge `autopkgtest` into the list, or will it replace the existing
> value?

Ah indeed, here's the current behavior:

The field is parsed as a comma-separated list of values (as per the
spec). If the debian/tests/control file is present then the value will
be added to the list. The values will always get emitted in alphabetical
order as a comma-separated list, any dupes squashed, so that the output
is reproducible. Unknown values are emitted untouched.

If the field contains “autopkgtest”, but the debian/tests/control file
is not present, then a warning will be issued, and the value preserved,
as in “the maintainer knows better!?”. But maybe it is actually better
to warn and just trim the “autopkgtest” value?

Does this resolve your concern?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140708010614.ga31...@gaara.hadrons.org

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2014-07-08 00:07:29)
> On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:
> > Nevertheless, those "false positives" that were generated this way are
> > still useful to be later marked with  once build profiles
> > are allowed in the archive because they are obviously droppable.
> 
> No, marking build-dependencies with build profiles should be driven by what
> is needed to break build-dep loops, not by what build-deps are "droppable"
> without further modification of the packages.  Excessive stage1 profile
> tagging will result in unnecessary extra builds during a bootstrap.

Bootstrapping should not get into the way of the normal packaging. There should
be strong reasons before a disruptive patch is applied to make a package build
with fewer build dependencies. This class of cases that is found by this script
(and it could be abused to find even more by omitting the first phase) sounds
to me as if only trivial changes were needed to build the package with fewer
build dependencies. Thus in case the maintainer does not have any strong
objections, there is no harm applying them.

The downside you list "unnecessary extra builds" are easy to avoid in practice.
Botch contains algorithms to find a close to minimum set of source packages to
modify to make a dependency graph acyclic (a feedback vertex set). Even if all
source packages in the dependency graph had removable build dependencies it
would only choose a small set of them (currently 60-70 are needed) to actually
build with a stage1 profile active.

Furthermore, the only time when there is a hard requirement to remove a
dependency without alternative are self cycles which currently involve only
about 30 source packages. For all other source packages there are always
alternatives. So you will mostly not get into a situation where you absolutely
"need to break a build-dep loop" as you describe it above (aside from these 30
source packages).

> > I did not plan to run this script more often yet. I'll probably do another
> > run after having added a detection for meta packages as suggested by you
> > below.
> 
> > Running it more regularly might not require any big discussion because the
> > "problem size" might be small enough that maintaining a white list would be
> > enough.
> 
> If you really want to systematically detect misbuilds on missing
> build-dependencies, it's a much bigger problem than just detecting this for
> the build-dependencies which are metapackages.

Why? The build dependencies which are not metapackages are not listed as false
positives because they get weeded out in the first phase.

> There certainly will be other cases that this technique won't cover, but it
> won't cause any false-negatives for your purposes.  I don't know what the
> numbers will look like overall, but 3 out of 4 packages listed by my name
> were false-positives that can be filtered out this way, so I definitely think
> it's worth a rerun before MBF.

You are right. I'll see what I can do.

Thanks a lot for your input!

cheers, josch


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

Re: Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Vincent Cheng]

On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
 wrote:
>
> Hi Steffen and all,
>
> today while talking with a backbox project administrator I discovered that 
> popular tools such as openvas directly calls the amap binary.
>
> I never talked with them, but I don't think it is feasible to ask to every 
> security tool provider to patch their code for the only debian benefit.
>
> I think I'm then changing again my opinion: the conflict field might be the 
> only proper way to be sure such popular tools (not packaged in debian and 
> some of them not even free) continue to work.
>
> Is this one a good reason for a conflict?

Again, according to Policy 10.1, as well as precedent that was
established by the CTTE decision regarding the namespace collision
between ax25-node vs. nodejs, no, it isn't; your argument is no
different from that of the nodejs maintainers, arguing that
/usr/bin/node should be taken over by nodejs simply because it's
already widely used by the nodejs community.

If you feel strongly enough about this issue, I'd suggest filing a bug
against debian-policy, going through the process and gathering
consensus to change 10.1 (e.g. perhaps by weakening it to a "should"
instead of a "must", or by proposing a carefully-worded exception to
existing policy).

Regards,
Vincent


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