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 ar
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 plan
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
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 bef
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, gcj
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
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
A
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
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 t
Hi,
Quoting Jakub Wilk (2014-07-10 12:45:36)
> * Johannes Schauer , 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 §4.9.1.
>
* Johannes Schauer , 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
tcl=8.6.0+8
texinfo=5.2
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
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 Kurt Roeckx (2014-07-09 00:36:37)
> On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> > Kurt Roeckx
> >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 the
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 w
On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> Kurt Roeckx
>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
>From th
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 positiv
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
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
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
+++ 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
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.
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
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
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
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.
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
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-
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
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
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
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
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
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
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
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
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
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 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
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-
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 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
42 matches
Mail list logo
