Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog:
> Hi,
>
> On Mon, 23 Nov 2009, Benjamin Drung wrote:
> > When a new upstream version is released, I have to check all patches
if
> > they were accepted by upstream or not. I have to check each patch if
I
> > can drop it. It would make
Raphael Hertzog writes:
> Hi,
>
> On Sat, 21 Nov 2009, Mike Hommey wrote:
>> The modifications are implied, but it means that the source format is
>> already this "heavy modification", on a similarly heavy modification
>> scale. Additionally, if someone wants to sepearte the patches into
>> feat
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer be accepted into the archive, but get rejected immediately.
> This should help to
Mike Hommey writes:
> On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
>> Because you want the patch to be clearly identified and to carry its
>> meta-information. Or because maybe you're applying 2 separate patches in
>> the same NMU upload.
>
> "Fixing cosmetic issues or changin
Processing commands for cont...@bugs.debian.org:
> reassign 557431 wnpp
Bug #557431 [general] general: there is no package to install all POSIX
utilities at once
Bug reassigned from package 'general' to 'wnpp'.
> retitle 557431 RFP: posix-utils
Bug #557431 [wnpp] general: there is no package to i
Mike Hommey writes:
> On Sun, Nov 22, 2009 at 11:30:45AM +0100, Raphael Hertzog wrote:
>> On Sun, 22 Nov 2009, Mike Hommey wrote:
>> > On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
>> > > Because you want the patch to be clearly identified and to carry its
>> > > meta-informati
Benjamin Drung writes:
> Hi,
>
> When a new upstream version is released, I have to check all patches if
> they were accepted by upstream or not. I have to check each patch if I
> can drop it. It would make packaging new releases easier if there were
> an optional Applied-Upstream field. Every pa
Hi! :)
* Raphael Hertzog [2009-11-22 10:48:14 CET]:
> > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
> > (native), which kind of suggests 3.0 (quilt) is being forced down.
> > That's maybe not what you are thinking, but it's how it feels.
>
> Well, the combina
On Mon, 23 Nov 2009, Goswin von Brederlow wrote:
> > Well, they can drop the patch in debian/patches, and add it to
> > the end of debian/patches/series. If quilt is installed, it should
> > work as dpkg-source will use quilt applied to know
> > whether patches needs to be applied. If quilt is not
Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
> Benjamin Drung writes:
>
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packagi
On Mon, Nov 23, 2009 at 09:18:37AM +0100, Goswin von Brederlow wrote:
> Benjamin Drung writes:
>
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packag
Gerfried Fuchs writes:
> Hi! :)
>
> * Raphael Hertzog [2009-11-22 10:48:14 CET]:
>> > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
>> > (native), which kind of suggests 3.0 (quilt) is being forced down.
>> > That's maybe not what you are thinking, but it's how i
On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> me).
Yay for reuploading the full tarball for each revision! I'd rather you
keep using 1.0 instead of doi
* Goswin von Brederlow [2009-11-23 09:48:36 CET]:
> Why do you think that? I can split patches any which way and edit the
> debian/patches/series to match all completly without quilt.
How so? I don't find anything in man dpkg or dpkg-source that would
help with that.
> It only becomes simpler w
On Mon, Nov 23, 2009 at 09:30:00AM +0100, Raphael Hertzog wrote:
> On Mon, 23 Nov 2009, Goswin von Brederlow wrote:
> > > Well, they can drop the patch in debian/patches, and add it to
> > > the end of debian/patches/series. If quilt is installed, it should
> > > work as dpkg-source will use quilt
* Raphael Hertzog [2009-11-23 09:50:15 CET]:
> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> > Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> > me).
>
> Yay for reuploading the full tarball for e
On Mon, Nov 23, 2009 at 10:10:51AM +0100, Gerfried Fuchs wrote:
> * Raphael Hertzog [2009-11-23 09:50:15 CET]:
> > On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> > > Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> > > The way quilt is implied in 3.0 (quilt) doesn't seem to
Hi
I tried to prepare and NMU to fix an RC bug #553111, which is
postinst-must-call-ldconfig.
I found that adding missing call to dh_makeshlibs does not fix the issue,
because package installs a private shared library to /usr/lib/libxxx.so,
and dh_makeshlibs does not add call to ldconfig to po
On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:
> Hi
>
> I tried to prepare and NMU to fix an RC bug #553111, which is
> postinst-must-call-ldconfig.
>
> I found that adding missing call to dh_makeshlibs does not fix the issue,
> because package installs a private shared l
> On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:
> > Hi
> >
> > I tried to prepare and NMU to fix an RC bug #553111, which is
> > postinst-must-call-ldconfig.
> >
> > I found that adding missing call to dh_makeshlibs does not fix the
> > issue, because package installs a priva
Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
écrit :
> > > I found that adding missing call to dh_makeshlibs does not fix the
> > > issue, because package installs a private shared library to
> > > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to ldconfig to
> > > pos
On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote:
> Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
> écrit :
> > > > I found that adding missing call to dh_makeshlibs does not fix the
> > > > issue, because package installs a private shared library to
> > > > /usr
> On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote:
> > Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
> >
> > écrit :
> > > > > I found that adding missing call to dh_makeshlibs does not fix
> > > > > the issue, because package installs a private shared library to
Le Sun, Nov 22, 2009 at 09:31:59PM +0300, Nikita V. Youshchenko a écrit :
>
> I've just met an uninstallable package with 3-week-old RC bug, caused by
> soname change of one of dependences. This bug could be fixed by a simple
> rebuild - I've checked if package builds against today's sid - yes i
Le lundi 23 novembre 2009 à 14:39 +0300, Nikita V. Youshchenko a
écrit :
> I've also seen cases when upstream build system puts some code in
> a 'private shared library' which is installed into $prefix/lib, but is
> never intended to use outside of current package (and has absolutely
> unstable
> Dear Nikita,
>
> it is difficult to judge since you did not give the package name.
> Nevertheless, the combination of RC bug left unfixed and signs of
> obsolescence (package-uses-deprecated-debhelper-compat-version) suggests
> that the maintainer might be MIA. If nobody wants to maintain this
>
> > How to handle that case, if not putting private library as-is to
> > /usr/lib ?
> >
> > Move it to /usr/lib/packagename, and use rpath on binaries? debian
> > tries to avoid rpath AFAIK ...
>
> Just because we hunt down stupid rpath cases doesn’t mean there aren’t
> valid uses for it. And this
Benjamin Drung writes:
> Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
>> Benjamin Drung writes:
>>
>> > Hi,
>> >
>> > When a new upstream version is released, I have to check all patches if
>> > they were accepted by upstream or not. I have to check each patch if I
>> >
Gerfried Fuchs writes:
> * Goswin von Brederlow [2009-11-23 09:48:36 CET]:
>> Why do you think that? I can split patches any which way and edit the
>> debian/patches/series to match all completly without quilt.
>
> How so? I don't find anything in man dpkg or dpkg-source that would
> help with
Package: wnpp
Severity: wishlist
Owner: Ezra Reeves
* Package name: pep8simulator
Version : 8.1.1
Upstream Author : J. Stanley Warford
* URL : http://code.google.com/p/pep8-1/
* License : GPL
Programming Lang: C++
Description : Pep/8 assembler and sim
Christophe Trophime writes:
> The license states that "Modifications to this software may be copyrighted by
> their authors
> and need not follow the licensing terms described here, provided that
> the new terms are clearly indicated on the first page of each file where
> they apply.". Does it m
> I've noticed that for DELAYED/XX uploads, the lintian rejects are
> triggered not when the package hits DELAYED/XX, but rather when the
> package eventually hits the archive. The annoyance of this is that the
> uploader losts "focus" on the specific fix.
> Any chance/plan to fix this so that li
I took my time reading DEP3 (http://dep.debian.net/deps/dep3/) and
notice they introduce an new "RFC-2822-like" format. This time they
introduce an ambiguous rules where either the Description or the
Subject field and contain verbatim data (which one is uncertain to me,
the text implies one of them
On 2009-11-23, Joerg Jaspert wrote:
> So for that, yes, you want to think about the dput solution. Which would
> have the nice added benefit to actually save people form uploading and
> wasting bandwidth and time.
Everybody should pipe his uploads through lintian. That's nothing that
should be i
"Nikita V. Youshchenko" writes:
> How to handle that case, if not putting private library as-is to /usr/lib ?
> Move it to /usr/lib/packagename, and use rpath on binaries?
Yes.
> debian tries to avoid rpath AFAIK ...
Debian tries to avoid RPATH used in ways that might break multilib or
overri
Youhei SASAKI wrote:
> Package: wnpp
> Owner: Youhei SASAKI
> Severity: wishlist
>
> * Package name: rail
> Version : 1.2.6
> Upstream Author : Mitsunobu Shimada
> * URL or Web page : http://ring.riken.jp/archives/elisp/rail/
> * License : GPL
> Description : Replac
On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote:
> since a few weeks the Debian archive accepts source package using the new
> formats "3.0 (quilt)" and "3.0 (native)".
I tried "3.0 (quilt)" with several packages today and none worked
properly, so several large packages will be stu
Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
écrit :
> Moving package-private shared libraries outside of /usr/lib is some amount
> of additional work that maintainer has to do.
Yes. This is one of the reasons why there are maintainers instead of
robots.
> If it is not a req
On Mon, 23 Nov 2009, Bastian Blank wrote:
> I tried "3.0 (quilt)" with several packages today and none worked
> properly, so several large packages will be stuck with "3.0 (native)".
1.0 is not going away even if we change the default.
> Bugs as of today.
Won't comment here. I have already comme
Hello,
On pirmadienis 23 Lapkritis 2009 23:35:28 Russ Allbery wrote:
> Debian tries to avoid RPATH used in ways that might break multilib or
> override local administrator settings, which means we want to avoid RPATH
> pointing to /usr/lib or to build directories and the like. But RPATH is
> th
X-Debbugs-CC: debian-devel@lists.debian.org
package: wnpp
Description:
LP Tools allow you to work with Launchpad without ever having to deal
with the web interface. The review-list tool can list reviews, and
review-notifier provides a desktop notifier about reviews that can be
done.
.
milesto
On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote:
> Am I doing something wrong?
>
> sys11:/home/brian/tree/heimdal# lintian heimdal_1.2.e1.dfsg.1-5_i386.changes
> warning: lintian's authors do not recommend running it with root privileges!
> internal error: command failed with error code
On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> For each patch:
> - apply patch
> - dpkg-buildpackage -S
> - rename debian/patches/debian-changes- into something else
>and edit its headers
> - fix debian/patches/series
>
> Note: this works only if quilt is not installed (
On Tue, 24 Nov 2009, Brian May wrote:
> Next problem:
>
> [...]
> dpkg-source -b heimdal-1.3.1.dfsg.1
> dpkg-source: info: using source format `3.0 (quilt)'
> dpkg-source: warning: patches have not been applied, applying them now (use
> --no-preparation to override)
> dpkg-source: info: applying
On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote:
> In the end, I decided to trust nothing and to verify if the first
> patch can be applied or not. If it can be applied, we assume that the
> patches have not been applied and we apply them all (unless
> --no-preparation is given). If quilt
Part of my usual workflow with the 1.0 format is to do an interdiff on
the .diff.gz from the previous version to the one I intend to upload,
to check that the changes correspond to what my vcs says they are. Now
that the changes are in a tarball, are there any recommended tools to
do that compariso
On Tue, Nov 24, 2009 at 01:53:34AM +0100, Carsten Hey wrote:
> On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> > For each patch:
> > - ...
> >
> > Note: this works only if quilt is not installed (or if you ensure
> > dpkg-source is called with --without-quilt which you currently
Le Tue, Nov 24, 2009 at 12:32:40AM +0100, Raphael Hertzog a écrit :
>
> > Or you start and propose a different format that can be mostly like 3.0
> > (quilt) for the result (multiple tars) but without the implicit quilt
> > constraints.
>
> Not me, no. And people should have requested that 1-2 ye
Hi!
On Mon, 2009-11-23 at 17:28:39 -0800, Rodrigo Gallardo wrote:
> Part of my usual workflow with the 1.0 format is to do an interdiff on
> the .diff.gz from the previous version to the one I intend to upload,
> to check that the changes correspond to what my vcs says they are. Now
> that the cha
Charles Plessy wrote:
> Maybe it is because you never wanted to listen to people who were
> interested to have the debian directory in a tar.gz, without a patch
> system on top of it?
>
> I answered to your feedback request, realised that you were not going to
> change
> your mind about format ‘3
Raphael Hertzog wrote:
> That's just wrong. I do it without problems by using the .quiltrc
> snippet from /usr/share/doc/quilt/README.source.
Hmm, that is verging on "beware of the leopard" non-obviousness. I mean,
you just argued in another mail that such a README.source would soon not
be necessa
On Tue, Nov 24, 2009 at 02:02:02AM +0100, Raphael Hertzog wrote:
> On Tue, 24 Nov 2009, Brian May wrote:
> > Next problem:
> >
> > [...]
> > dpkg-source -b heimdal-1.3.1.dfsg.1
> > dpkg-source: info: using source format `3.0 (quilt)'
> > dpkg-source: warning: patches have not been applied, applyi
On So, 22 Nov 2009, Steve Langasek wrote:
> > and as far as I see:
> > clean: unpatch
>
> Well, the latter is wrong - this breaks if you're patching the build system.
Ah, good to know, but well, my poiint is that this is a bit a PITA
if the system changes again and again. But that has nothing to
On Tue, Nov 24, 2009 at 02:30:59PM +1100, Brian May wrote:
> Ok, I did the following:
Disregard those results, I screwed up and forgot to cd into the new
working directory after I moved the old one. So it looked OK but
wasn't.
Retry. Hmmm. So far it looks better...
--
Brian May
--
To UNSUBSC
#include
* Josselin Mouette [Tue, Nov 24 2009, 12:00:34AM]:
> Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
> écrit :
> > Moving package-private shared libraries outside of /usr/lib is some amount
> > of additional work that maintainer has to do.
>
> Yes. This is one of the r
On Mon, Nov 23 2009, Joey Hess wrote:
> Perhaps Raphael in turn was sensing that I didn't have a deep knowledge
> of git -- I had only used it for a month or so at the time. And in fact,
> we now know a much better way to do a git based format. I have been
> considering working on it again, after
Gerfried Fuchs writes:
> * Raphael Hertzog [2009-11-23 09:50:15 CET]:
>> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
>> > Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
>> > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
>> > me).
>>
>> Yay for r
Joey Hess writes:
> Raphael Hertzog wrote:
>> That's just wrong. I do it without problems by using the .quiltrc
>> snippet from /usr/share/doc/quilt/README.source.
>
> Hmm, that is verging on "beware of the leopard" non-obviousness. I mean,
> you just argued in another mail that such a README.sou
Bastian Blank writes:
> On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote:
>> since a few weeks the Debian archive accepts source package using the new
>> formats "3.0 (quilt)" and "3.0 (native)".
>
> I tried "3.0 (quilt)" with several packages today and none worked
> properly, so s
On Tue, 24 Nov 2009, Robert Collins wrote:
> On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote:
> > In the end, I decided to trust nothing and to verify if the first
> > patch can be applied or not. If it can be applied, we assume that the
> > patches have not been applied and we apply them
On Mon, 23 Nov 2009, Joey Hess wrote:
> > I understand that you do not want to throw away your work on this patch
> > management system, but by making it optional, I think that you will actually
> > increase your chances of success…
>
> I think that's very wise.
It is optional already. Just don't
On Tue, Nov 24, 2009 at 03:43:42AM +0100, Guillem Jover wrote:
> Hi!
>
> On Mon, 2009-11-23 at 17:28:39 -0800, Rodrigo Gallardo wrote:
> > Part of my usual workflow with the 1.0 format is to do an interdiff on
> > the .diff.gz from the previous version to the one I intend to upload,
> > to check t
On Tue, 24 Nov 2009, Goswin von Brederlow wrote:
> > Bugs as of today.
> > * Packages with different patch systems like linux-2.6. In this case
> > dpkg-source ignores failures to register a patch and produces
> > sources without the changes. (#557618)
>
> As discussed on IRC this is a matter
63 matches
Mail list logo
