Lars Wirzenius writes:
> Having Debian versions of the programs differ in this from everyone
> else would create a lot of confusion, and needlessly cause everyone
> more support burden than is needed.
Isn't that the same case with the FHS?
To bring an example here from my ongoing packaging proje
Hi,
for one of my packages (astropy), I am currently in discussion with
upstream on whether the XDG rules shoule be applied [1]. I am arguing
there that for a new software, it would be better to follow this
standard.
The XDG basedir specification [2] basically defines where user specific
configur
Steve Langasek writes:
> On Sun, Sep 29, 2013 at 02:20:08PM +0200, Olе Streicher wrote:
>> Paul Wise writes:
>> > On Sun, Sep 29, 2013 at 8:08 PM, Olе Streicher wrote:
>> > You appear to be using debhelper compat level 9, which includes
>> > enabling multi-
Paul Wise writes:
> On Sun, Sep 29, 2013 at 8:08 PM, Olе Streicher wrote:
>> Uhh, you are right. I, however, still don't understand where the
>> multiarch path comes from. From the log file (on i386):
>>
>> configure: running /bin/bash ./configure [...] \
>>
Paul Wise writes:
> On Sun, Sep 29, 2013 at 7:31 PM, Olе Streicher wrote:
>> While the library is architecture specific, the pkgconfig file is not.
> Looks like it is to me, which is what lintian is complaining about:
> [...]
> libdir=${prefix}/lib/x86_64-linux-gnu
Uhh
Paul Wise writes:
> On Sun, Sep 29, 2013 at 7:18 PM, Olе Streicher wrote:
>> for one of my packages (funtools) I just got a new lintian error:
>> pkg-config-multi-arch-wrong-dir. However, I cannot see a reason why this
>> is issued. The pkgconfig file (/usr/lib/pkgconfig/fun
Hi,
for one of my packages (funtools) I just got a new lintian error:
pkg-config-multi-arch-wrong-dir. However, I cannot see a reason why this
is issued. The pkgconfig file (/usr/lib/pkgconfig/funtools.pc) is
8<
prefix=/usr
exec_prefix=${prefix}
Olivier Sallou writes:
> Indeed, many bioinformatics programs relies on external data. But I am afraid
> that if we start to add some data packages, we will open an endless open
> door BioInformatics datasets are large, and becoming huge and numerous.
> This size will be an issue for Debian mi
Hi Florian,
Florian Rothmaier writes:
> * Package name: fits
> [...]
> * License : public-domain
Some short comments:
* I would not name the (source) package "fits" since this is too short
and misleading (I would expect a generic fits handling package there,
not a java specific
Goswin von Brederlow writes:
> debian-de...@liska.ath.cx (Ole Streicher) writes:
>> I think the best way would be that debuild/dpkg-buildpackage would not
>> automatically unapply the patches (so it would leave the source in the
> It doesn't automatically unapply the patches. It only restores the
Goswin von Brederlow writes:
>>> If you need to change a file then that means that file isn't source
>>> anymore but generated. Try switching to out-of-tree builds if you have
>>> something like that.
>>
>> What is the advantage of that? From the Debian policy, I don't see a
>> need why sources sh
Goswin von Brederlow writes:
> debian-de...@liska.ath.cx (Olе Streicher) writes:
>> James McCoy writes:
>>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
Unpatching the sources *before* the build process was cleaned up makes
no sense to me at all. Could you provide a
James McCoy writes:
> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>> Unpatching the sources *before* the build process was cleaned up makes
>> no sense to me at all. Could you provide a use case for that?
> As was described in #649531:
>
> vcs clone
&
Goswin von Brederlow writes:
> What automatic reversal? There is no automatic reversal. The default
> state of source is with patches applied.
Hmm. I have overlooked this when reading bug report #649531.
The order how the steps are applied, is clearly:
1. patch the sources
2. build the package
James McCoy writes:
> On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
>> What is the rationale behind the automatic reversal of the applied
>> patches before a cleanup?
>
> Quoting from the bug I meant to refer you to (#649531) when closing the
> debuild bu
Hi,
I just discovered that debuild does not behave as I would expect from
the maintainer's guide [1]:
| Cleaning the source and rebuilding the package from your user account
| is as simple as:
| $ debuild
[...]
| You can clean the source tree as simply as:
| $ debuild clean
This gives an error
16 matches
Mail list logo
