On Fri, Dec 6, 2019 at 11:12 PM Rebecca N. Palmer wrote:
> However, before entering the chroot, it tries to run debian/rules clean
> *outside* the chroot; in some cases the clean step needs some of the
> build dependencies, so this can fail.
There is the --use-pdebuild-internal option t
git-pbuilder builds in a chroot, containing build-essential and the
build dependencies. (One reason for doing this is to have _only_ those
packages available, and not anything else you happen to have installed,
as a check that the declared build dependencies do include everything
needed
ted with 2
Usually when I build the build process installs any missing packages in
the list of build dependencies, but it is not doing that here.
Here is my .gbb.conf:
[DEFAULT]
builder = git-pbuilder
cleaner = fakeroot debian/rules clean
pristine-tar = True
[buildpackage]
export-dir = ../build-area/
tarball-dir = ..
[import-orig]
dch = False
Hello,
>instead. From this, I take that I have to use "export QT_SELECT = 5" in
>d/rules; but what are then my required build dependencies? Just
>qtchooser? Or do I need to install any qt5 development package as well?
I think qtbase5-dev is the minimum dependency you need
ake that I have to use "export QT_SELECT = 5" in
d/rules; but what are then my required build dependencies? Just
qtchooser? Or do I need to install any qt5 development package as well?
Best regards
Ole
* Ole Streicher , 2016-07-05, 21:26:
Dependency installability problem for dpuser on i386:
dpuser build-depends on:
- i386:libvtk6-dev
i386:libvtk6-dev depends on:
- i386:python-vtk6 (= 6.3.0+dfsg1-1)
i386:python-vtk6 depends on:
- i386:python-twisted
i386:python-twisted depends on:
- i386:pytho
Hi,
I am trying to get my package "dpuser" compiled. While this works nicely
on my local pbuilder with up-to-date packages, it fails on the buildds:
https://buildd.debian.org/status/package.php?p=dpuser
f.e. for i386:
---8<-
Dependency installabil
On Sat, 22 Sep 2012 18:18:06 -0400, Michael Gilbert
wrote:
> I think it would be more appropriate to just close the bug with a
> message indicating that the package should be built on a system with
> multiarch enabled; where the wine-bin dependency would be satisfied
> via wine-bin:i386. Lucas's
On Sat, Sep 22, 2012 at 3:53 PM, Stephen Kitt wrote:
> Dear mentors,
>
> I maintain the wine-gecko package (wine-gecko-1.4), which is in an
> interesting situation because its build-dependencies can't be satisfied on all
> architectures, but it builds an "Architecture
Dear mentors,
I maintain the wine-gecko package (wine-gecko-1.4), which is in an
interesting situation because its build-dependencies can't be satisfied on all
architectures, but it builds an "Architecture: all" package. Something
similar was discussed in March, and as I un
Hi David,
> Try to build your package in a clean chroot: you'll probably won't have that
> message anymore.
Thank you. I created a clean chroot, and the python warning disappeared indeed.
Best wishes,
Guido
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of
On Thu, 20 Oct 2011 20:43:35 +0200, Guido van Steen wrote:
> Dear list,
>
> I maintain a package called fizsh. Fizsh only depends on zsh.
>
> [..]
>
> If I build the package with "dpkg-buildpackage -rfakeroot -uc -us" I
> get the following warning:
>
> "dh_pysupport: This program is deprecated,
Sorry for being a bit unclear.
Instead of:
> It is not completely clear to me why get this warning. Why do I do NOT
> need Python to build the package? Is python needed for debhelper? In
> that case should python not be included as a build-depend as well?
I meant:
> It is not completely clear t
Hi,
Le 13/10/11 15:26, Reinhard Tartler a écrit :
> One solution would be to throw all sources into a big source package and
> build everything from that.
Looks like the sane solution to me.
Another would be to, on the contrary, split the source packages, if
possible, to completely break the lo
On Thu, Oct 13, 2011 at 15:26, Reinhard Tartler wrote:
> In my tests, it *seems* that apt indeed prefers a real package over a
> virtual package. I'm aware of the following drawbacks:
It does, but you are better of handling this as an internal detail
- because it is easier/faster to try non-virtu
depends on libbar-dev
- bar (source package) builds:
- libbar-dev, libbar0, bar
- and build depends on libfoo-dev
Obviously, there are circular build dependencies, which means that
neither package can be built without the other one.
One solution would be to throw all sources into a
On 05/16/2011 01:07 AM, Matt Kraai wrote:
> Hi,
>
> I'm trying to create a new package of The Unarchiver.
Hi, Matt
I am working on this new package as well. I asked the upstream author
Dag Ågren, about packaging it into Debian.
> When I build it
> in unstable, it generates the following warn
Hi Paul,
Paul Wise wrote:
> On Mon, May 16, 2011 at 1:07 AM, Matt Kraai wrote:
>
> > I'm trying to create a new package of The Unarchiver.
>
> Thanks!
>
> How are you building it? I took a look and gave up when I saw it has
> no makefiles, only an Xcode project and the GNUStep pbxbuild (that
>
On Mon, May 16, 2011 at 1:07 AM, Matt Kraai wrote:
> I'm trying to create a new package of The Unarchiver.
Thanks!
How are you building it? I took a look and gave up when I saw it has
no makefiles, only an Xcode project and the GNUStep pbxbuild (that
translates Xcode stuff to Makefiles) tool is
Hi,
I'm trying to create a new package of The Unarchiver. When I build it
in unstable, it generates the following warning and the resulting
executables hang when run:
/usr/bin/ld: warning: libobjc.so.2, needed by
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgnustep-base.so, may
conf
Osamu Aoki wrote:
> Hi,
>
> On Sun, May 16, 2010 at 09:43:22PM +0300, George Danchev wrote:
> ...
>> Ahem, I see, mistakes happen, thus clean chroots (and note to myself: clean
>> apt caches;-) are to be used for such tweaking. In fact, other packages'
>> {B
Am Sonntag, den 16.05.2010, 19:19 +0100 schrieb Tony Houghton:
> George Danchev wrote:
[..]
> > Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder
> > --login
> > test says dice wrt build-dependencies drag:
[..]
> Looks like you're right. I unins
Hi,
On Sun, May 16, 2010 at 09:43:22PM +0300, George Danchev wrote:
...
> Ahem, I see, mistakes happen, thus clean chroots (and note to myself: clean
> apt caches;-) are to be used for such tweaking. In fact, other packages'
> {Build-}dependencies change over time, it is pretty co
o don't depend on the (la)tex packages that xmlto
> > > does, and they take a long time to install.
> >
> > Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder
> > --login test says dice wrt build-dependencies drag:
> >
> > #
in the xmlto case, so don't expect big wins
> >>> here ;-)
> >>
> >> AFAICT the above trio don't depend on the (la)tex packages that xmlto
> >> does, and they take a long time to install.
> >
> >Well, xmlto does not pull any latex packages AFA
tall.
>
> Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder
> --login
> test says dice wrt build-dependencies drag:
>
> # apt-get install xmlto
> Need to get 468kB/3592kB of archives.
> After this operation, 20.6MB of additional disk space will be
o don't depend on the (la)tex packages that xmlto
does, and they take a long time to install.
Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder --login
test says dice wrt build-dependencies drag:
# apt-get install xmlto
Need to get 468kB/3592kB of archives.
After
bits to be pulled as compared
> > > to those pulled in the xmlto case, so don't expect big wins here ;-)
> >
> > AFAICT the above trio don't depend on the (la)tex packages that xmlto
> > does, and they take a long time to install.
>
> Well, xmlto does not
lled in the xmlto case, so don't expect big wins here ;-)
>
> AFAICT the above trio don't depend on the (la)tex packages that xmlto
> does, and they take a long time to install.
Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder --login
test says dice wrt
On Sun, 16 May 2010 19:38:59 +0300
George Danchev wrote:
> Also, it seems to me that build-depending on xsltproc && docbook-xsl &&
> docbook-xml would not extremely trim the bits to be pulled as compared to
> those pulled in the xmlto case, so don't expect big wins here ;-)
AFAICT the above tr
Jakub Wilk writes:
Hi,
> * Tony Houghton , 2010-05-16, 16:06:
> >>override_dh_auto_build:
> >>xsltproc --nonet \
> >>
> >> --param make.year.ranges 1 \
> >> --param make.single.year.ranges 1 \
> >>
* Tony Houghton , 2010-05-16, 16:06:
override_dh_auto_build:
xsltproc --nonet \
--param make.year.ranges 1 \
--param make.single.year.ranges 1 \
--param man.charmap.use.subset 0 \
-o debi
On Sun, 16 May 2010 21:44:42 +0900
Osamu Aoki wrote:
>override_dh_auto_build:
>xsltproc --nonet \
> --param make.year.ranges 1 \
> --param make.single.year.ranges 1 \
> --param man.charmap.use.subset 0 \
>
* Osamu Aoki , 2010-05-16, 21:44:
Originally I used xsltproc to generate roxterm's man pages, as per
the example in the New Maintainers' Guide, but when I moved the man
pages upstream I got a bug report because the location of
docbook.xsl isn't consistent across OSs
Just use
http://docbook.s
* Tony Houghton , 2010-05-16, 12:57:
Originally I used xsltproc to generate roxterm's man pages, as per
the example in the New Maintainers' Guide, but when I moved the man
pages upstream I got a bug report because the location of docbook.xsl
isn't consistent across OSs
Just use
http://docboo
On Sun, May 16, 2010 at 12:57:39PM +0100, Tony Houghton wrote:
> On Fri, 14 May 2010 17:07:11 +0200
> Jakub Wilk wrote:
>
> > * Tony Houghton , 2010-05-14, 15:41:
> > >Originally I used xsltproc to generate roxterm's man pages, as per
> > >the example in the New Maintainers' Guide, but when I mov
On Fri, 14 May 2010 17:07:11 +0200
Jakub Wilk wrote:
> * Tony Houghton , 2010-05-14, 15:41:
> >Originally I used xsltproc to generate roxterm's man pages, as per
> >the example in the New Maintainers' Guide, but when I moved the man
> >pages upstream I got a bug report because the location of
> >
* Tony Houghton , 2010-05-14, 15:41:
Originally I used xsltproc to generate roxterm's man pages, as per the
example in the New Maintainers' Guide, but when I moved the man pages
upstream I got a bug report because the location of docbook.xsl isn't
consistent across OSs
Just use
http://docbook.
Originally I used xsltproc to generate roxterm's man pages, as per the
example in the New Maintainers' Guide, but when I moved the man pages
upstream I got a bug report because the location of docbook.xsl isn't
consistent across OSs so I started using xmlto instead.
The trouble with xmlto is it pu
> I'd suggest to remove them and just include plain HTML, so people
> don't have to install Xorg and a desktop system to view them; since
> there are console HTML readers but not console CHM readers.
>
If you want to convert them, archmage converts CHM to HTML pretty well
in my experience. You co
On Sun, Oct 26, 2008 at 11:24 PM, Jose Luis Blanco
<[EMAIL PROTECTED]> wrote:
> 2) chm (MS' compressed html format) help files: Is it preferred to include
> only
> HTML help files in foo-doc packages? I find CHM files quite useful for
> example,
> for searching, but I don't know if there's any p
Hi Jose Luis!
El dom, 26-10-2008 a las 15:24 +0100, Jose Luis Blanco escribió:
> This software for the detection of invariant keypoints is being made
> available for individual research use only. Any commercial use or any
> redistribution of this software requires a license from the University
>
On the software patent issue:
Ruben, Charles: Thank you very much for the quick answers.
OK, I think I will leave those sources out of the Debian package and look
for more "open" alternatives...
About autopano-sift, now I see it's actually in debian-multimedia, not
Debian. I was wrong because I r
Le Sun, Oct 26, 2008 at 03:24:22PM +0100, Jose Luis Blanco a écrit :
>
> This software for the detection of invariant keypoints is being made
> available for individual research use only. Any commercial use or any
> redistribution of this software requires a license from the Universit
Dear mentors,
I hope someone can help me with a few doubts:
1) buildd: I have found problems in the compilation of my (first) package in
buildd (http://buildd.debian.org/pkg.cgi?pkg=mrpt). Some fixes only imply
changes in the debian/ directory, others are changes in the upstream files.
How can I
On amd64 (and other 64 bit arches?) we're seeing something simular:
bt_nice_size.c: In function 'bt_nice_size':
bt_nice_size.c:34: warning: format '%llu' expects type 'long long unsigned
int', but argument 4 has type 'u_int64_t'
bt_nice_size.c:34: warning: format '%llu' expects type 'long long uns
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> Yes, name it libapr-dev. If something really can use either one
> of the 2, I don't see why you should make a transition so hard
> and go and name it libapr0-dev.
>
> So I suggest you rename libapr0-dev to libapr-dev and make it
> provide libapr0-dev for n
Asheesh Laroia <[EMAIL PROTECTED]> wrote:
> >But if I have to remove the "apr1 | apr0" sutff, then a new version of
> >mod-bt (and every other apache2 module) will be neccessary when the switch
> >to 2.2 happens.
> In theory you could just switch the order of apr1 | apr0. But I agree
> that this
On Sun, Jul 09, 2006 at 11:37:58AM -0700, Tyler MacDonald wrote:
> Bastian Blank <[EMAIL PROTECTED]> wrote:
> > On Sun, Jul 09, 2006 at 10:10:37AM -0700, Tyler MacDonald wrote:
> > > > apache2-prefork-dev depends on libapr0-dev which conflicts with
> > > > libapr1-dev.
> > > But that should be fi
On Sun, 9 Jul 2006, Tyler MacDonald wrote:
But if I have to remove the "apr1 | apr0" sutff, then a new version of
mod-bt (and every other apache2 module) will be neccessary when the switch
to 2.2 happens.
In theory you could just switch the order of apr1 | apr0. But I agree
that this is less
Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 09, 2006 at 10:10:37AM -0700, Tyler MacDonald wrote:
> > > apache2-prefork-dev depends on libapr0-dev which conflicts with
> > > libapr1-dev.
> > But that should be fine, since I depend on libapr1-dev *or*
> > libapr0-dev, shouldn't it? pbu
On Sun, Jul 09, 2006 at 10:10:37AM -0700, Tyler MacDonald wrote:
> > apache2-prefork-dev depends on libapr0-dev which conflicts with
> > libapr1-dev.
> But that should be fine, since I depend on libapr1-dev *or*
> libapr0-dev, shouldn't it? pbuilder handles it without a problem...
No. The au
Bastian Blank <[EMAIL PROTECTED]> wrote:
> Package: mod-bt
> Version: 0.0.18+p4.1178-1
> Severity: serious
>
> There was an error while trying to autobuild your package:
>
> > Automatic build of mod-bt_0.0.18+p4.1178-1 on lxdebian.bfinv.de by
> > sbuil
Nikolai Lusan <[EMAIL PROTECTED]> writes:
> Hi all,
[cut]
Hi.
> I get the feeling that this should be easy to deal with by compiling the
> library packages and installing them so that debhelper can find things
> in the right place, I am just a little unsure on how to do this.
I'm not a mentor.
Nikolai Lusan <[EMAIL PROTECTED]> writes:
> Hi all,
>
> I am relatively new to building my own packages (previously I have been
> able to just alter sources from the main debian archives to suit my
> needs when I needed something customised) and I am having a couple of
> "issues".
>
> I am stuck
Hi all,
I am relatively new to building my own packages (previously I have been
able to just alter sources from the main debian archives to suit my
needs when I needed something customised) and I am having a couple of
"issues".
I am stuck in a situation where I am having to build specific point
В Чтв, 01/09/2005 в 17:31 +0200, Frank Küster пишет:
> The question is how you call pbuilder. I always call it on dsc files,
> and then it just unpacks the chroot and builds the package. You
> probably use debuild - well, then you're on your own. If you unpack a
> source package on your system
On Thu, Sep 01, 2005 at 04:50:08PM +0200, Frank Küster wrote:
[...]
> No, the official build tool is sbuilder (and not exactly the version
> that is released somewhere, IIRC).
Do you have more info about what has been changed to the released
sbuild package?
Not that it would be particulary import
Le Jeudi 1 Septembre 2005 17:41, Jeroen van Wolffelaar a écrit :
> So instead, go up one dir, do "dpkg-source -b mldonkey-2.5.28" to build the
> .dsc without running clean, and then run "pbuilder mldonkey_2.5.28-2.dsc"
Yep.
I personnaly did it with this package and it worked without problems..
Ro
t to run the clean rule, although I
know that isn't always as easy as it sounds. But it's nice to be able to
use pdebuild without having the build dependencies installed outside the
chroot.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Alexander:
You don't show the initial commands that you use to start the build. I
usually sit in a directory where there are the *.dsc, the *.orig.tar.gz
and the *.diff.gz files. Then I invoke:
pbuilder build fityk_0.5.1-1.dsc
That starts by unpacking the chroot, then moving the source to
On Thu, Sep 01, 2005 at 06:17:01PM +0300, Alexander A. Vlasov wrote:
> Inside an unpacked source tree;
> I call ~/bin/mydebuild, which is simple shell script:
> #!/bin/sh
> pdebuild --configfile ~/.pbuilderrc \
> --buildsourceroot fakeroot \
> --pbuilderroot sudo \
> $*
>
>
sbuild, not pbuilder) would be to use the .dsc file. If you
> call it from within an unpacked source tree, I would guess that it first
> does a "dpkg-buildpackage -S" (or equivalent) first, which might fail if
> the build dependencies aren't met. I'm not 100% sure abo
"Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote:
> В Чтв, 01/09/2005 в 16:50 +0200, Frank Küster пишет:
>> "Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote:
>>
>> > Hello.
>> >
>> > I have to build a lot of packages for personal use by myself and I
>> > expirienced a very strange problem with pbui
В Чтв, 01/09/2005 в 16:50 +0200, Frank Küster пишет:
> "Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote:
>
> > Hello.
> >
> > I have to build a lot of packages for personal use by myself and I
> > expirienced a very strange problem with pbuilder:
> >
> > Some packages requires some unusual things t
? The way the build machines would do it (AFAIK,
they use sbuild, not pbuilder) would be to use the .dsc file. If you
call it from within an unpacked source tree, I would guess that it first
does a "dpkg-buildpackage -S" (or equivalent) first, which might fail if
the build dependencies a
"Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I have to build a lot of packages for personal use by myself and I
> expirienced a very strange problem with pbuilder:
>
> Some packages requires some unusual things to build, for example, dpatch
> or ocaml. Those tools are included in
Hello.
I have to build a lot of packages for personal use by myself and I
expirienced a very strange problem with pbuilder:
Some packages requires some unusual things to build, for example, dpatch
or ocaml. Those tools are included in build-dep in control file, but
actually pbuilder does some stu
On Fri, 2004-12-24 at 09:23 -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 24 Dec 2004, Tilman Koschnick wrote:
> > | Built successfully
> > |
> > | NOTE: The package could have used binaries from the following packages
> > | (access time changed) without a source dependency:
> > | python-de
On Fri, 24 Dec 2004, Tilman Koschnick wrote:
> | Built successfully
> |
> | NOTE: The package could have used binaries from the following packages
> | (access time changed) without a source dependency:
> | python-dev: /usr/bin/python
> | xlibs-dev: /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libX11
Hi,
the build logs for the gpsd package contain the following notice:
| Built successfully
|
| NOTE: The package could have used binaries from the following packages
| (access time changed) without a source dependency:
| python-dev: /usr/bin/python
| xlibs-dev: /usr/X11R6/lib/libICE.so /usr/X
Neil Roeth wrote:
> IIRC, I initially set up pbuilder with woody, then upgraded it to sid.
Unstable breaks often in various ways. Last week, the sysvinit-Postinst
prevented chroots to be created/upgraded...
Cheers
T.
pgpmlwcNMoo3P.pgp
Description: PGP signature
On Jul 3, Frank Küster ([EMAIL PROTECTED]) wrote:
> > Building your packages with pbuilder (and testing those) will catch most
> > of your
> > obmissions.
>
> I'll try that - last time I tried, some weeks ago, it seemed unstable
> was un-installable.
IIRC, I initially set up pbuilder with
rary
>>>> in the Dependencies of my binary package, I need the respective
>>>> libfoo-dev in Build-Dependencies?
>>> More or less, yes.
>
>> What would be a case of "less"?
>
> -dev packages without version-number in the package name, like
>
Neil Roeth wrote:
> IIRC, I initially set up pbuilder with woody, then upgraded it to sid.
Unstable breaks often in various ways. Last week, the sysvinit-Postinst
prevented chroots to be created/upgraded...
Cheers
T.
pgp0.pgp
Description: PGP signature
On Jul 3, Frank Küster ([EMAIL PROTECTED]) wrote:
> > Building your packages with pbuilder (and testing those) will catch most of your
> > obmissions.
>
> I'll try that - last time I tried, some weeks ago, it seemed unstable
> was un-installable.
IIRC, I initially set up pbuilder with woody
rary
>>>> in the Dependencies of my binary package, I need the respective
>>>> libfoo-dev in Build-Dependencies?
>>> More or less, yes.
>
>> What would be a case of "less"?
>
> -dev packages without version-number in the package name, like
>
,
>>> I need the respective libfoo-dev in Build-Dependencies?
>> More or less, yes.
>What would be a case of "less"?
Aside from obvious cases where libfoo123c102 has libfoo-dev, I have the
impression
that sometimes a more complicated pattern is called for (IIRC libc needed to
On Thu, Jul 03, 2003 at 09:45:23AM +0200, Frank Küster wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> schrieb:
>> Frank Küster wrote:
>>> But what about libraries? Can I just assume that for every library
>>> in the Dependencies of my binary package, I need the r
,
>>> I need the respective libfoo-dev in Build-Dependencies?
>> More or less, yes.
>What would be a case of "less"?
Aside from obvious cases where libfoo123c102 has libfoo-dev, I have the impression
that sometimes a more complicated pattern is called for (IIRC libc needed to
On Thu, Jul 03, 2003 at 09:45:23AM +0200, Frank Küster wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> schrieb:
>> Frank Küster wrote:
>>> But what about libraries? Can I just assume that for every library
>>> in the Dependencies of my binary package, I need the r
libgl1. And how do I figure out the correct
>> Build-dependencies:-line? Are there any tools?
> This is created by the shlib file of the package that provides the
> xlibmesa3-Library. libgl1 is to be a virtual package for packages implementing
> opengl (or whatever it's officially
Michel Dänzer <[EMAIL PROTECTED]> schrieb:
> BTW, xlibmesa3 is old; if you aren't running sid, you should use
> something like pbuilder with a sid chroot to build packages for upload.
> That will also help verify that the build dependencies are correct.
Yes, of course. I'
libgl1. And how do I figure out the correct
>> Build-dependencies:-line? Are there any tools?
> This is created by the shlib file of the package that provides the
> xlibmesa3-Library. libgl1 is to be a virtual package for packages implementing
> opengl (or whatever it's officially cal
Michel Dänzer <[EMAIL PROTECTED]> schrieb:
> BTW, xlibmesa3 is old; if you aren't running sid, you should use
> something like pbuilder with a sid chroot to build packages for upload.
> That will also help verify that the build dependencies are correct.
Yes, of course. I'
Hi.
Frank Küster wrote:
> dh_shlibdeps nicely sorts out the libraries that a binary package
> depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
> seems to be no package named libgl1. And how do I figure out the correct
> Build-dependencies:-line? Are th
Provides .
> And how do I figure out the correct Build-dependencies:-line? Are there
> any tools?
>
> Of course if I use some utilities not in build-essential, I have to know
> that myself and put them there. But what about libraries? Can I just
> assume that for every library
Hi.
Frank Küster wrote:
> dh_shlibdeps nicely sorts out the libraries that a binary package
> depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
> seems to be no package named libgl1. And how do I figure out the correct
> Build-dependencies:-line? Are th
Provides .
> And how do I figure out the correct Build-dependencies:-line? Are there
> any tools?
>
> Of course if I use some utilities not in build-essential, I have to know
> that myself and put them there. But what about libraries? Can I just
> assume that for every library
Hi, Frank!
* Frank Küster <[EMAIL PROTECTED]> [2003-07-02 20:53]:
> dh_shlibdeps nicely sorts out the libraries that a binary package
> depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
> seems to be no package named libgl1. And how do I figur
Hi,
dh_shlibdeps nicely sorts out the libraries that a binary package
depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
seems to be no package named libgl1. And how do I figure out the correct
Build-dependencies:-line? Are there any tools?
Of course if I use some
Hi, Frank!
* Frank Küster <[EMAIL PROTECTED]> [2003-07-02 20:53]:
> dh_shlibdeps nicely sorts out the libraries that a binary package
> depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
> seems to be no package named libgl1. And how do I figur
Hi,
dh_shlibdeps nicely sorts out the libraries that a binary package
depends on. Quite nicely, since I get "xlibmesa3 | libgl1", but there
seems to be no package named libgl1. And how do I figure out the correct
Build-dependencies:-line? Are there any tools?
Of course if I use some
y version of each depend.
To some extent, yes. I usually start with completely unversioned build
dependencies on just the library -dev and helper packages, and if someone
actually uses a version of a depended-on package that doesn't work, I add
it later on (Although this sounds like Microsoft s
y version of each depend.
To some extent, yes. I usually start with completely unversioned build
dependencies on just the library -dev and helper packages, and if someone
actually uses a version of a depended-on package that doesn't work, I add
it later on (Although this sounds like Microsoft s
Mark Howard <[EMAIL PROTECTED]> writes:
Simon was faster, so i dont look at your package. :)
> to create the build dependencies, I just followed the instructions in
> the new maintainer's guide:
Another way is to use pbuilder (or a selfmade chroot).
First you go and look what
hi,
to create the build dependencies, I just followed the instructions in
the new maintainer's guide:
strace -f -o /tmp/log ./configure
# or make instead of ./configure, if the package don't use autoconf
for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.*
open\(\"([^\"]*
Mark Howard <[EMAIL PROTECTED]> writes:
Simon was faster, so i dont look at your package. :)
> to create the build dependencies, I just followed the instructions in
> the new maintainer's guide:
Another way is to use pbuilder (or a selfmade chroot).
First you go and look what
hi,
to create the build dependencies, I just followed the instructions in
the new maintainer's guide:
strace -f -o /tmp/log ./configure
# or make instead of ./configure, if the package don't use autoconf
for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.*
open\(\"(
On Fri, Oct 12, 2001 at 12:41:55AM +0200, Ralf Treinen wrote:
> BTW, the upstream author tried to compile his program with gcc 3.01
> and did not succeed. I am not enough of an expert in C programming
> to solve a problem that he cannot solve. However, if anyone likes
> to help me on this I will b
1 - 100 of 124 matches
Mail list logo
