Russ Allbery <[EMAIL PROTECTED]> writes:
> Looking at build logs on i386, the common problem for many seems to be
> variations of:
>
> dh_strip
> strip: unable to copy file
> 'debian/libwebauth-perl/usr/lib/perl5/auto/WebAuth/WebAuth.so' reason:
> Permission denied
>
> I can't duplicate this with
Package: wnpp
Severity: wishlist
Owner: Jorge Salamero Sanz <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: xcalib
Version : 0.6
Upstream Author : Stefan Döhla
* URL : http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/
* License
On Sat, 16 Jun 2007, Wesley J. Landaker wrote:
On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote:
Le vendredi 15 juin 2007 ?? 17:36 -0400, Ivan Jager a ??crit :
Yes. Any time the unit is bytes. There is even a standard for it.
I must have missed that one. Could you point us to this st
After one false start (I thought it was hung, but there was a quadratic
search in one of the checks that's now been fixed), lintian.debian.org
output has been updated to lintian 1.23.31. This should eliminate quite a
few false positives.
It's a bit behind the current archives at the moment since
Reviewing the latest lintian findings, there are a surprising number of
packages with unstripped binaries, including some that are using debhelper
and dh_strip. See:
http://lintian.debian.org/reports/Tunstripped-binary-or-object.html
Looking at build logs on i386, the common problem for many see
Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>
Package name: gbrowse
Version : 1.68
Upstream Author : Lincoln Stein & the GMOD team ([EMAIL PROTECTED])
URL : http://www.gmod.org/wiki/index.php/GBrowse
License : Same as Perl, plu
Bastian Venthur <[EMAIL PROTECTED]> writes:
> I suggest that we prepare a wikipage on wiki.debian.org with a
> friendly formulated bugreport template. After this template is
> mature enough, we can start writing wishlist bugreports on packages
> making wrong use SI prefixes (e.g. write KB but mean
On 6/18/07, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
On Mon, Jun 18, 2007 at 04:28:09PM -0400, Christian Convey wrote:
> I could create Yet Another Source Package, "myproject-common-src.deb",
> that contains *only* those files that are in common. I.e., it would
> only contain "make-functions
On Mon, Jun 18, 2007 at 04:28:09PM -0400, Christian Convey wrote:
> I could create Yet Another Source Package, "myproject-common-src.deb",
> that contains *only* those files that are in common. I.e., it would
> only contain "make-functions{1,2}.mk" and perhaps the top-level
> Makefile. Then packa
Package: wnpp
Severity: wishlist
Owner: Marc Leeman <[EMAIL PROTECTED]>
* Package name: dtc
Version : 20070523
Upstream Author : Jon Loeliger
* URL : git://www.jdl.com/software/dtc.git
* License : GPL
Programming Lang: C
Description : PowerPC kernel devi
Package: wnpp
Severity: wishlist
Owner: "Vladimír Lapáček" <[EMAIL PROTECTED]>
* Package name: libws-commons-util-java
Version : 1.0.1
Upstream Author : Jochen Wiedmann <[EMAIL PROTECTED]>
* URL : http://apache.osuosl.org/ws/commons/util/
* License : Apache Lice
Package: wnpp
Severity: wishlist
Owner: Nico Golde <[EMAIL PROTECTED]>
* Package name: libacpi
Version : 0.1
Upstream Author : Nico Golde <[EMAIL PROTECTED]>
* URL : http://www.ngolde.de/libacpi.html
* License : MIT/X
Programming Lang: C
Description : ge
On Mon, Jun 18, 2007 at 12:01:23PM +0200, Loïc Minier wrote:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
> I think this is fine; the resulting "symb
I have an odd packaging situation, and was hoping someone could tell
me the best practice for this situation...
I've been asked to take an existing project and package it for use
with APT. The project consists of many libraries and applications.
I was thinking to produce a different source pack
On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> Hi,
>
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
>
> The reason for this is that dpkg-buildpackage ca
On Thursday 14 June 2007 04:20:53 [EMAIL PROTECTED] wrote:
> Two weeks ago I've sent an email no Yvan, asking if he was still
> interested in maintaining those packages. Both have newer upstream
> versions. There is a bug with a patch for libgsasl7 that was not
> answered by Yvan. It is dated as of
On Mon, Jun 18, 2007 at 12:25:38PM -0400, Daniel Schepler wrote:
> How about instead requiring something like: the build-arch target must return
> successfully or with a status of 2 (the standard make error status
> for "target not found"), and in the latter case the build target must return
> s
On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote:
> Goswin von Brederlow wrote:
> >I would like to gather up some momentum for a policy change. Namely
> >that the build-arch/indep targets in debian/rules become required
> >instead of being optional.
> Wouldn't looking for the output
Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>
* Package name: dominoblast
Version : 0.1
Upstream Author : Chris Lord <[EMAIL PROTECTED]>
Upstream Author : Heather Packer <[EMAIL PROTECTED]>
* URL : http://chrislord.net/blog/Software/my-lost-
Re: Peter Holm 2007-06-18 <[EMAIL PROTECTED]>
> b) Why do you state an invalid adress for the maintainer, even if the
> program is in the testing branch?
That's what listed in the package.
As it looks, Adrian's packages should probably all be orphaned, the
address has been bouncing since at lea
Package: wnpp
Severity: wishlist
Owner: Loic Minier <[EMAIL PROTECTED]>
* Package name: louie
Version : 1.1
Upstream Author : Patrick K. O'Brien and contributors <[EMAIL PROTECTED]>
* URL : http://pylouie.org/
* License : BSD
Programming Lang: Python
Descrip
Package: wnpp
Severity: wishlist
Owner: Lior Kaplan <[EMAIL PROTECTED]>
* Package name: openoffice.org-ctl-he
Version : 1.0
Upstream Author : Lior Kaplan <[EMAIL PROTECTED]>
* URL :
svn://svn.debian.org/svn/debian-hebrew/pkg/openoffice.org-ctl-he
* License : Pu
On Monday 18 June 2007 04:30:55 am Goswin von Brederlow wrote:
> Hi,
>
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
>
> The reason for this is that dpkg-buildpackage can't relia
Hi,
Just received following:
[...]
Hi. This is the qmail-send program at mail.gmx.net.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
70.103.162.29_does_not_like_recipient./Remot
Goswin von Brederlow wrote:
I would like to gather up some momentum for a policy change. Namely
that the build-arch/indep targets in debian/rules become required
instead of being optional.
Wouldn't looking for the output
make: *** No rule to make target `build-arch'. Stop.
and then defaulting
Hi,
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
FWIW, I think that would be a good thing (I remember a discussion with
you on
Le lundi 18 juin 2007 à 10:08 +0100, Raphael Hertzog a écrit :
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the ne
On Wed, May 23, 2007 at 11:09:53AM +0200, Stefano Zacchiroli wrote:
> Hi DAMs,
> I'm wondering what actually happened with this, so flow of questions
> follows :)
Hi DAMs, ping again on this.
Can we have some numbers about at least how many mails have been sent in
the first WaT run, if any? Al
On Sun, Jun 17, 2007 at 03:51:15PM -0400, Joe Smith wrote:
> "Michael Vogt" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> - automatic removal of unused dependencies moved into libapt so that
>> applications like synaptic, python-apt, update-manger etc directly
>> benefit from
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
>> > The file in debian is *not* updated, that's precisely the point of this
>> > discussion. Joss wants the maintainer to update it beforehand, I let the
>> > maintainer update it after its final build
* Loïc Minier ([EMAIL PROTECTED]) [070618 12:04]:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
>
> I think this is fine; the resulting "symbols" file
* Raphael Hertzog ([EMAIL PROTECTED]) [070618 11:36]:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild once knowing that it will fail... l
On Mon, 18 Jun 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I have full control on the kind of changes that I allow in the
generated symbols file compared to the provided f
On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
> > The file in debian is *not* updated, that's precisely the point of this
> > discussion. Joss wants the maintainer to update it beforehand, I let the
> > maintainer update it after its final build but it will then be used only
> > for the next upl
On Mon, Jun 18, 2007, Reinhard Tartler wrote:
> As already said elsewhere in this thread, that's exactly the point of
> "unattended-upgrades": It detects if manual user interaction is
> required, and will not upgrade the package in this case.
There might be some manual steps involved. For exampl
On Mon, Jun 18, 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I think this is fine; the resulting "symbols" file can make strict
assumptions.
You don't expect dh_makeshl
Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:
> Michael Vogt wrote:
>> unattended-upgrades comes with a default configuration that will only
>> apply security updates (but it can be configured in any way people
>> want) and it will do some careful checking to not upgrade packages
>> that require
On Mon, Jun 18, 2007 at 10:08:36AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild onc
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
>> > The generated file is updated... and the file in the source package
>> > doesn't need to be updated so often. Additionnaly you can avoid having to
>> > rebuild once knowing that it will fail... let the build
On Mon, 18 Jun 2007, Mike Hommey wrote:
> > The generated file is updated... and the file in the source package
> > doesn't need to be updated so often. Additionnaly you can avoid having to
> > rebuild once knowing that it will fail... let the build update the
> > generated file, get the diff from
On Mon, Jun 18, 2007 at 09:50:48AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On Mon, 18 Jun 2007, Josselin Mouette wrote:
> > Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > > - we have different levels of check that can make dpkg-gensymbols fail
> > > (w
Hi,
On Mon, 18 Jun 2007, Josselin Mouette wrote:
> Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > - we have different levels of check that can make dpkg-gensymbols fail
> > (with option -c). By default level 1 is activated, it will fail
> > if some symbols disappeared. L
Hi,
I would like to gather up some momentum for a policy change. Namely
that the build-arch/indep targets in debian/rules become required
instead of being optional.
The reason for this is that dpkg-buildpackage can't reliable detect
the existance of the build-arch/indep targets and must call 'bui
Package: wnpp
Severity: wishlist
Owner: Xavier Guimard <[EMAIL PROTECTED]>
* Package name: lemonldap-ng
Version : x.y.z
Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Programming Lang: (C,
44 matches
Mail list logo
