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
Lars Wirzenius l...@liw.fi 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
Steve Langasek vor...@debian.org writes:
On Sun, Sep 29, 2013 at 02:20:08PM +0200, Olе Streicher wrote:
Paul Wise p...@debian.org 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-arch stuff:
Thank
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}
Paul Wise p...@debian.org 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/funtools.pc
Paul Wise p...@debian.org 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, you are right
Paul Wise p...@debian.org 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 [...] \
'--libdir=${prefix}/lib/i386
Olivier Sallou olivier.sal...@irisa.fr 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
Hi Florian,
Florian Rothmaier froth...@ari.uni-heidelberg.de 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
Goswin von Brederlow goswin-...@web.de 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
Goswin von Brederlow goswin-...@web.de 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
Goswin von Brederlow goswin-...@web.de writes:
debian-de...@liska.ath.cx (Olе Streicher) writes:
James McCoy vega.ja...@gmail.com 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
James McCoy vega.ja...@gmail.com 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 repository
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
James McCoy james...@debian.org 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 bug:
On one
Goswin von Brederlow goswin-...@web.de 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.
16 matches
Mail list logo
