Hi,
Quoting Johannes Schauer (2014-07-07 13:51:00)
we would like to propose an MBF with severity wishlist to drop unused build
dependencies in a number of source packages
I fixed many of the previous false positives of build dependencies on meta
packages (not the file contents of the package
On Mon, 28 Jul 2014 11:34:24 +0200, Johannes Schauer wrote:
I attached the updated list of droppable build dependencies and build
dependencies that can be moved to Build-Depends-Indep together with dd-list
output.
== libxml-parser-perl_2.41-1.arch-all.unusedbd ==
sharutils=1:4.14-2
Already
Hi,
Quoting gregor herrmann (2014-07-28 11:45:14)
== libxml-parser-perl_2.41-1.arch-all.unusedbd ==
sharutils=1:4.14-2
Already fixed in 2.41-2.
thanks!
I assume you're planning to do a new run before actually filing the
bugs?
I cannot do a new run before September because I'm moving
Hi,
I cannot believe I attached the wrong list once again. My sincere apologies to
fill up your inboxes like that :(
Attached are the right files and dd-list
Quoting Johannes Schauer (2014-07-28 11:34:24)
bison, ca-certificates, default-jdk, doxygen-latex, g++-4.8-multilib,
gcc-multilib,
On Monday, July 28, 2014 12:07:58 Johannes Schauer wrote:
Hi,
Quoting gregor herrmann (2014-07-28 11:45:14)
== libxml-parser-perl_2.41-1.arch-all.unusedbd ==
sharutils=1:4.14-2
Already fixed in 2.41-2.
thanks!
I assume you're planning to do a new run before actually filing
On Monday, July 28, 2014 08:54:29 Scott Kitterman wrote:
On Monday, July 28, 2014 12:07:58 Johannes Schauer wrote:
Hi,
Quoting gregor herrmann (2014-07-28 11:45:14)
== libxml-parser-perl_2.41-1.arch-all.unusedbd ==
sharutils=1:4.14-2
Already fixed in 2.41-2.
thanks!
On Mon, 28 Jul 2014 12:07:58 +0200, Johannes Schauer wrote:
Quoting gregor herrmann (2014-07-28 11:45:14)
== libxml-parser-perl_2.41-1.arch-all.unusedbd ==
sharutils=1:4.14-2
Already fixed in 2.41-2.
thanks!
Thanks to you for providing the lists :)
I assume you're planning to do a
Hi,
Quoting Scott Kitterman (2014-07-28 14:54:29)
It is quite common for people to fix things based on the initial discussion
about an impending MBF, so I think it would be less than impolite to not
acknowledge that by filing bugs on obsolete data.
The two packages that I show up for are
* Johannes Schauer j.scha...@email.de, 2014-07-09, 16:50:
== llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real ==
automake=1:1.14.1-3
autotools-dev=20140510.1
diffstat=1.58-1
doxygen=1.8.7-1
flex=2.5.39-7
lcov=1.10-1
libtool=2.4.2-1.7
patchutils=0.3.3-1
procps=1:3.3.9-5
sharutils=1:4.14-2
Hi,
Quoting Jakub Wilk (2014-07-10 12:45:36)
* Johannes Schauer j.scha...@email.de, 2014-07-09, 16:50:
should build dependencies which the source package only requires after
setting some DEB_BUILD_OPTIONS go into Build-Depends?
Probably not, unless it's one of the optioned blessed by Policy
Hi,
Quoting Steve Langasek (2014-07-09 00:32:18)
But it absolutely does have this effect if we add bootstrap-specific metadata
unnecessarily, because:
- it introduces a syntax incompatibility with older versions of the package
tools
we are currently trying to get a minimal change to
op 07-07-14 14:20, Johannes Schauer schreef:
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
== llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real ==
automake=1:1.14.1-3
Hi,
Quoting Maarten Lankhorst (2014-07-09 15:48:33)
== llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real ==
automake=1:1.14.1-3
autotools-dev=20140510.1
diffstat=1.58-1
doxygen=1.8.7-1
flex=2.5.39-7
lcov=1.10-1
libtool=2.4.2-1.7
patchutils=0.3.3-1
procps=1:3.3.9-5
sharutils=1:4.14-2
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.
It would of course be better if packages were resilient against
On Tue, Jul 08, 2014 at 09:43:02AM +0200, Johannes Schauer wrote:
Do you think I should fill bugs for all non-empty packages that were
already found? Or do you think there is another high chance of false
positives for that kind of packages too?
The only other likely sources of false positives
On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
Kurt Roeckx k...@roeckx.be
libtool
== libtool_2.4.2-1.7.arch-all.unusedbd ==
gfortran=4:4.8.2-4
gfortran Depends on gfortran-4.8, and that is being used.
openssl (U)
== openssl_1.0.1g-4.arch-all.unusedbd ==
m4=1.4.17-4
On Tue, Jul 08, 2014 at 06:22:49AM +0200, Johannes Schauer wrote:
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
Hi,
Quoting Kurt Roeckx (2014-07-09 00:36:37)
On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
Kurt Roeckx k...@roeckx.be
libtool
== libtool_2.4.2-1.7.arch-all.unusedbd ==
gfortran=4:4.8.2-4
gfortran Depends on gfortran-4.8, and that is being used.
indeed this is
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
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:
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,
On Mon, Jul 7, 2014 at 1:51 PM, Johannes Schauer j.scha...@email.de 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 ==
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,
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
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
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
and the updated dd-list
Sorry for not having attached the right files in my initial email :(
cheres, josch
Adam C. Powell, IV hazel...@debian.org
mpi-defaults (U)
Adam Conrad adcon...@0c3.net
eglibc (U)
freetds (U)
Alan Woodland awoodl...@debian.org
blcr
Alessandro Ghedini
On Mon, Jul 7, 2014 at 2:23 PM, Johannes Schauer j.scha...@email.de 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
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
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
On Mon, Jul 7, 2014 at 4:51 AM, Johannes Schauer j.scha...@email.de 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
Hi Johannes,
On Mon, Jul 07, 2014 at 02:37:02PM +0200, Johannes Schauer wrote:
Steve Langasek vor...@debian.org
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
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
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 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
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
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
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
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
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
+++ 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
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)
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 !profile.stage1 once build profiles
are allowed in the archive
43 matches
Mail list logo
