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

2014-07-07 Thread 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 c

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

2014-07-07 Thread 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

Debian.

2014-07-07 Thread 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? Contac

Re: Debian.

2014-07-07 Thread 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

Re: Debian.

2014-07-07 Thread 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 inqu

Re: How to avoid stealth installation of systemd?

2014-07-07 Thread 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? >

possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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...@lis

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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-

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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: > H

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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~r

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 > somethin

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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-Depend

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

2014-07-07 Thread 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 L

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 > > availabl

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

2014-07-07 Thread 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 i

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

2014-07-07 Thread 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 s

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

2014-07-07 Thread 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 fa

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

2014-07-07 Thread 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

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

2014-07-07 Thread 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 mor

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 switchi

Re: dpkg-source to automatically add a Testsuite field

2014-07-07 Thread 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/

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 b

Re: Debian.

2014-07-07 Thread 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

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

2014-07-07 Thread 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 co

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

2014-07-07 Thread 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

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

2014-07-07 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 repetiti

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 v

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

2014-07-07 Thread 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 co

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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-

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 d

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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.

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 A

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

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

2014-07-07 Thread 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

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 definite

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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.

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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 t

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

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

2014-07-07 Thread 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. No

Re: dpkg-source to automatically add a Testsuite field

2014-07-07 Thread 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 ca

Re: possible MBF: automatically detecting unused build dependencies

2014-07-07 Thread 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

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

2014-07-07 Thread 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 feasibl