On Fri, Jun 20, 2025 at 04:07:22AM +0200, Lorenzo wrote:
Is it ok to have a package with Architecture: all that Depends: on
another one (from the same source) that is Architecture: any?
Of course.
--
WBR, wRAR
signature.asc
Description: PGP signature
Dear Debian mentors,
I am encountering issues with dh_shlibdeps when cross-compiling with a
custom sysroot. Specifically, dh_shlibdeps fails to correctly identify
some dependencies in this setup, even though I have experimented with
the `admindir` argument. While some dependencies are correctly
Hi,
Quoting Alejandro Claro Mosqueda (2025-03-26 13:53:40)
> I am encountering issues with dh_shlibdeps when cross-compiling with a custom
> sysroot. Specifically, dh_shlibdeps fails to correctly identify some
> dependencies in this setup, even though I have experimented with the
&g
On Tue, Sep 10, 2024 at 07:22:01AM +0300, Tommi Höynälänmaa wrote:
> Hello
>
> In https://wiki.debian.org/binNMU it says that declaring dependency between
> an arch: all to an arch: any package should be done by "Depends: foo (>=
> ${source:Version}), foo (<< ${source:Version}.1~)". What is the pu
Hello
In https://wiki.debian.org/binNMU it says that declaring dependency
between an arch: all to an arch: any package should be done by "Depends:
foo (>= ${source:Version}), foo (<< ${source:Version}.1~)". What is the
purpose of the latter condition?
- Tommi Höynälänmaa
--
Kotisivu /
Wookey writes:
> On 2024-05-24 16:39 +0200, David Given wrote:
>> I'm try to put together a package for a big, complex application. One of
>> its dependencies isn't in Debian yet. What do I do?
>
> Package the dependency first.
>
>> - package up the
ll packages have no users before they enter the
> archive so that's not really a problem.
Cool. I'll continue trying to make it build and come up with a full list of
unpackaged dependencies, and report back.
On 2024-05-24 16:39 +0200, David Given wrote:
> I'm try to put together a package for a big, complex application. One of
> its dependencies isn't in Debian yet. What do I do?
Package the dependency first.
> - package up the dependency and somehow get both packages sponsored
Given a écrit :
>
>> I'm try to put together a package for a big, complex application. One of
>> its dependencies isn't in Debian yet. What do I do?
>>
>> - package up the dependency and somehow get both packages sponsored at
>> the same time (how?);
&
Hi David,
Le ven. 24 mai 2024 à 17:06, David Given a écrit :
> I'm try to put together a package for a big, complex application. One of
> its dependencies isn't in Debian yet. What do I do?
>
> - package up the dependency and somehow get both packages sponsored a
On Fri, 2024-05-24 at 16:39 +0200, David Given wrote:
> I'm try to put together a package for a big, complex application. One of its
> dependencies isn't in Debian yet. What do I do?
>
> - package up the dependency and somehow get both packages sponsored at the
> same
I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?
- package up the dependency and somehow get both packages sponsored at the
same time (how?);
- package up the dependency and get it sponsored first... meaning th
On 2023-11-21 16:39 +, David James wrote:
> Dear Mentors,
>
> I would like to package the Citra emulator in the future. There are currently
> a few dependencies that need to be added as packages before Citra itself can
> be built from a tarball.
>
> A couple of these
On Tue, Nov 21, 2023 at 04:39:42PM +, David James wrote:
> A couple of these dependencies have no version upstream. Is there a
> precedent for this? Can these dependencies be packaged?
There are definitely packages like that in Debian and the usual practice
is using date-based ve
Dear Mentors,
I would like to package the Citra emulator in the future. There are currently a
few dependencies that need to be added as packages before Citra itself can be
built from a tarball.
A couple of these dependencies have no version upstream. Is there a precedent
for this? Can these
On Fri, Dec 18, 2020 at 11:47:53PM +, Jeremy Sowden wrote:
> If you haven't got this sorted yet, try the attached patch. It also
> corrects the SONAME of shasta.so. It does mean there's an RPATH in the
> executable, however.
> ...
Thanks a lot
Andreas.
--
http://fam-tille.de
On 2020-12-18, at 15:32:01 +0100, Andreas Tille wrote:
> I tried no override_dh_shlibdeps in shasta debian/rules, which has
> lead to:
>
> dpkg-shlibdeps: error: cannot find library
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so
> needed by debian/shasta/usr/bin/shasta (ELF
On Fri, Dec 18, 2020 at 04:07:50PM +0100, Andreas Tille wrote:
> On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote:
> > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> > > to:
> > >
> >
On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> > to:
> >
> > dpkg-shlibdeps: error: cannot find library
> > /usr/lib/python3/dist-pac
On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> Hi,
>
> I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> to:
>
> dpkg-shlibdeps: error: cannot find library
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed
> by debian/shasta/
Hi,
I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
to:
dpkg-shlibdeps: error: cannot find library
/usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed by
debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi:
'0201003e'; RPATH
dependency
* License : Apache-2.0
Section : python
* Vcs: https://salsa.debian.org/python-team/packages/pytest-dependency
It builds those binary packages:
python-pytest-dependency-doc - Manages dependencies of pytest test
cases (common documentation)
python3-pytest-dependency
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
Patrick Schleizer:
> I am maintaining two Debian derivatives distributions, Whonix and
> Kicksecure. (Open Source) I hope you don't mind my question.
>
> I am trying to build a custom meta package with 'Architecture: all' that
> has an architecture specific dependency:
> hardened-malloc [amd64]
A
64.
(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)
Here is a simplified example.
Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
pkg1,
pkg2,
...,
hardened-malloc [amd64],
${misc:Depends}
Description:
64.
(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)
Here is a simplified example.
Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
pkg1,
pkg2,
...,
hardened-malloc [amd64],
${misc:Depends}
Description:
Hello,
Recently I've switched from a different distribution to Debian. Within my own
projects I use sphinxcontrib-tikz[1] during document generation but this
package is currently missing in Debian, so I've been working on packaging it
as my first package. I've read most of the relevant document
Control: tags -1 help moreinfo
Hi,
I really wonder why gatb-core should be missing. According to
tracker[1] gatb-core is in testing and the build logs[2] are specifying
exactly those architectures as successfully installed that you claim
missing (in agreement with discosnp tracker page[3] admitt
Hi,
I recently created a new binary package "iraf-wcstools", which is
Arch:all, but depends on architecture dependent packages. Specifically,
it depends on "iraf", which is available only on selected
architectures (f.e. not on s390x):
Package: iraf-wcstools
Architecture: all
Depends: iraf, [...]
I forgot: the arch specific package needs a Depends on the arch:all
package, which has the wrappers.
t patches to britney for this but
>> I've also a vague memory that they prefer arches to be self-contained.
>
> This issue affects so few packages that no-one has put in the effort
> to make this (automatic migration with cross-arch dependencies) work.
> I talked about it w
memory that they prefer arches to be self-contained.
This issue affects so few packages that no-one has put in the effort
to make this (automatic migration with cross-arch dependencies) work.
I talked about it with respect to doing this for cross-compilers and
they were OK with doing this prope
On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
> Unfortunately, this is impossible: the assembler code creates a kind of
> sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
> be simply remodelled in C. In principle, one could re-implement this
> with the libunwind libr
my mistake, as I didn't run piuparts locally.
> I'm pretty sure the testing migration doesn't support
> cross-architecture dependencies, but the release team will hint things
> into testing where that is the only thing blocking migration.
If we take Multi-Arch serious, this shouldn&#
rchitecture to the chroot that piuparts was using for
testing.
I'm pretty sure the testing migration doesn't support
cross-architecture dependencies, but the release team will hint things
into testing where that is the only thing blocking migration.
> My first thought was to limit the
Hi,
I have an "arch: all" package "python3-pyraf" (source package: "pyraf"),
that has a dependency on the package "iraf", but no build dependency on
that.
"iraf" exists only on selected architectures due to some required
assembler code for each arch and problems with big endian. python3-pyraf is
Hi again,
On Mon, Dec 11, 2017 at 09:27:57AM +0100, Andreas Tille wrote:
>
> On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote:
> > === warnings summary
> > ===
> > None
> > [pytest] section in setup.cfg files is deprecated, use
Hello, I would like to package a new boinc-virtualbox metapackage, that installs
virtualbox and the extpack.
Unfortunately the upstream vbox provides a virtualbox-5.0, virtualbox-5.1 or
virtualbox-5.2 (provides virtualbox)
and the debian one provides virtualbox, and nothing more (except from
co
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
Your message dated Sat, 22 Apr 2017 06:45:21 -0700
with message-id <20170422134520.75wpsfesjgo5t...@iris.silentflame.com>
and subject line Re: Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian
package dependencies
has caused the Debian Bug report #860466,
regarding RFS: equivs/2.0.1
Control: tag -1 -moreinfo
Dear Sean,
On Thu, 20 Apr 2017 09:36:24 -0700
Sean Whitton wrote:
> I'd like to note that I'm planning to upload with dgit, so you shouldn't
> rebase after the upload. It's okay to rebase before the upload.
Understand.
I always cut the final releasing commit and appe
control: tag -1 +moreinfo
Dear Roger,
On Wed, Apr 19, 2017 at 09:10:52AM +0900, Roger Shimizu wrote:
> And I pushed my fixes to branch qa_upload2.
> (I removed the final releasing commit of branch qa_upload, and added update
> commit)
I'd like to note that I'm planning to upload with dgit, so y
nce that fixing RC and not making new RC
- Feeling of deserving the cost of brothering release team
- Feeling of avoiding troubles and keep risk minimal
etc.
Seems I need more experience so I can have the right feeling.
> Also, in case you upload a library foo2 in unstable
> that has a fo
you upload a library foo2 in unstable
that has a foo1 in testing, you are preventing fixes of reverse-dependencies
from being uploaded
in unstable (because to migrate they should be built against the old version).
so, keeping unstable into a "releasable state" is always the preferred, safer
solution.
G.
On Wed, 19 Apr 2017 07:01:56 + (UTC)
Gianfranco Costamagna wrote:
> Hello,
>
> >Secondly, testing-proposed-updates is highly inconvenient for the
> >release team. It requires manual intervention and slows everything
> >down. So we shouldn't upload to unstable unless we *expect* it to be
>
Hello,
>Secondly, testing-proposed-updates is highly inconvenient for the
>release team. It requires manual intervention and slows everything
>down. So we shouldn't upload to unstable unless we *expect* it to be
>unblocked.
also, TPU means that semi-automatic bug reports (e.g. piuparts, ftbfs
control: tag -1 +moreinfo
On Wed, Apr 19, 2017 at 09:10:52AM +0900, Roger Shimizu wrote:
> Thanks for your review!
No problem.
> I think these are all simple fix that suitable for stretch.
> The policy don't require pre-approval to upload to unstable [0].
>
> If the unblock is rejected, and som
Control: tag -1 -moreinfo
Dear Sean,
Thanks for your review!
Very helpful. And I pushed my fixes to branch qa_upload2.
(I removed the final releasing commit of branch qa_upload, and added update
commit)
Package also re-uploaded to DoM amd64 and mentors.
On Tue, 18 Apr 2017 09:37:20 -0700
Sean
control: tag -1 +moreinfo
Dear Roger,
On Mon, Apr 17, 2017 at 08:25:16PM +0900, Roger Shimizu wrote:
> I am looking for a sponsor for my package "equivs"
Thanks for working on all these improvements and fixes.
Here is a review of 9818bd99a15efbbbf37eace90480f69e682f2e8f:
- Shouldn't this targe
debian.org/pkg/equivs
* License : GPL-2+
Section : admin
It builds those binary packages:
equivs - Circumvent Debian package dependencies
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/equivs
Alt
Hi,
>Bug#839383: RFS: php-net-idna2/0.1.1-1 [ITP]
in new queue
>Bug#842157: RFS: php-db-dataobject/1.11.5-1 [ITP] -- PHP PEAR module for
>object based SQL query building
in testing :)
Will probably look at gnu-social once the new queue is cleared.
G.
Dear Team,
I've already made an earlier request for the sponsors for my packages
about two months ago, still no response. So if possible i request you to
look into the following packages. Please check the following bugs which
are dependencies to gnu-social.
Bug#839383: RFS: php-net-idna2/
* Jens Reyer , 2016-07-05, 21:24:
First off, many thanks again for that script. Unfortunately it fails in
Ubuntu (see #827770):
./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3 libfontconfig.so.1
libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.8
libncurses.so.5 libo
* 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 28.05.2016 12:30, Jakub Wilk wrote:
> * Jens Reyer , 2016-05-27, 20:17:
>> I think I have it working now in wine to automatically generate a list
>> of runtime dependencies. I based it on Jakub's suggestions, however I
>> didn't go for creating a "depende
already been
requested:
#596715 (dpkg-shlibdeps: Please allow to manually add library
dependencies via shlibdeps)
#548463 (dpkg-shlibdeps: Please provide a method to compute dependencies
for non-elf)
Greets
jre
* Jens Reyer , 2016-05-29, 17:37:
Should I put your coyright and the MIT/X11 (BSD like) license in the
script, as seen in dctypes2elf?
Yes, please do.
--
Jakub Wilk
On 05/28/2016 12:30 PM, Jakub Wilk wrote:
> * Jens Reyer , 2016-05-27, 20:17:
>> I think I have it working now in wine to automatically generate a list
>> of runtime dependencies. I based it on Jakub's suggestions, however I
>> didn't go for creating a "depende
Hi Jens!
>- first find the library file on the system (looking in some
> hardcoded directories),
I'm really sure it won't add any value to your current solution, but you might
consider asking ld or whatever the list of search paths
http://stackoverflow.com/questions/9922949/how-to-print-the-ldlin
* Jens Reyer , 2016-05-27, 20:17:
I think I have it working now in wine to automatically generate a list
of runtime dependencies. I based it on Jakub's suggestions, however I
didn't go for creating a "dependency binary".
For one I did get results this way, but unfortunat
On Sat, May 28, 2016 at 2:17 AM, Jens Reyer wrote:
> Then (instead of creating a binary linking to the required
> libraries and running dpkg-shlibdeps on this) I replicate things
> from dpkg-shlibdeps(1) to identify the library package names for
> these sonames:
I wonder if the best solution woul
create an ELF that depends on all of them, and
> then use dpkg-shlibdeps against it.
>
> You can steal the idea of how to create such ELF here:
> https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf
Thanks a lot Jakub and Gianfranco!
I think I have it working now in wine to
Hi Nico:
On 26/05/16 19:06, Nico Schlömer wrote:
> Hi everyone,
>
> Say a package installs only headers, and in one of those, a header of
> another -dev package is #included. How to depend on the package?
Have a look to the libmpfrc++-dev package.
Best wishes,
Jerome
>
> Cheers, Nico
--
Je
Hi,
>Say a package installs only headers, and in one of those, a header of another
>-dev package is #included. How to depend on the package?
I would call it libfoo-dev (arch:all) and depend (runtime) on libbar-dev.
Feel free to steal from websocketpp, a source-only library I maintain.
https:
Hi everyone,
Say a package installs only headers, and in one of those, a header of
another -dev package is #included. How to depend on the package?
Cheers,
Nico
* Jens Reyer , 2016-05-19, 16:57:
First off, I'm not sure about every single dependency if it is needed
at all.
Quick grep over the *.dll.so indeed shows that they use a bunch of
libraries you mentioned:
$ strings /usr/lib/i386-linux-gnu/wine/*.dll.so | grep '^lib.*[.]so[.]' | sort
-u | gre
Hi Jens,
>Now, assuming that we really need all of them, but that there is no way
>to automatically add them: is there any way to compute the needed
>runtime dependency for a given builddep, in order to avoid hardcoding
>this list and update it with every soname change of a depended upon
>package?
Hi,
I'm working on adding more runtime dependencies to wine (see #823991).
Wine uses the dh sequencer and all relevant binary packages have a
"Depends: ${shlibs:Depends}". This adds some runtime dependencies, but
by far not for every build-dependency -dev package.
If I try to do
* Paul Wise , 2015-12-15, 18:43:
On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:
1) Use the nocheck build profile to build and upload f-el without
running its tests. Then build and upload shut-up and undercover. Then
build and upload a full version of f-el.
2) Use the nocheck build pro
On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:
> 1) Use the nocheck build profile to build and upload f-el without
>running its tests. Then build and upload shut-up and undercover.
>Then build and upload a full version of f-el.
>
> 2) Use the nocheck build profile to build and uploa
> need.
I've dug a little deeper. It turns out the circular chain of
dependencies are not actually required to run f's unit tests. They are
only required for f.el's upstream continuous integration testing setup
(a setup not compatible with Debian CI, so far as I know). I'
Sean Whitton writes:
>
> 3) Disable running f-el's test suite at package build time, but supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> 4) Disable running undercover.el's test suite at package build time, but
> supply a
>autopkgtest so the tests will still ge
Hello,
As I mentioned there's a dependency loop in building f-el [1]. This is
a library that a lot of Emacs addons depend on. If we could get this
into the archive we would have dash-el, s-el and f-el all in Debian and
future dependency resolution would be much easier.
The problem is that f-el'
Sean Whitton writes:
>
> After:
> ,
> | EMACSFLAGS = -L /usr/share/emacs/site-lisp/dash-el \
> | -L /usr/share/emacs/site-lisp/elpa-src/noflet-*
> | test :
> | $(EMACS) --no-site-file --no-site-lisp --batch \
> | $(EMACSFLAGS) \
> | -l test/run-tests
> `
Hello,
I'm working on packaging the dependencies and build dependencies of
projectile [1], and I'm trying to ensure that the test suites of all
dependencies and build dependencies are run when the packages are built.
Unfortunately there is a dependency circle within the dependencies
ges, thus package dependencies
> must be declared between them. Is there any tool to help me with this,
> or should I create my own? I imagine something like ${misc:Depends}...
I put something together which might (after recoding in a safe manner)
bu useful to others or be considered a h
Am Montag, den 17.08.2015, 00:11 +0200 schrieb Gert Wollny:
> On 13.08.2015 18:17, Andreas Tille wrote:
> > I confirm that this at least has some effect - unfortunately not
> > the wanted
> > one sinde the
> >
> > @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@
> > @BOOST_SYSTEM_LIB@
> >
> >
On Mon, Aug 17, 2015 at 12:11:23AM +0200, Gert Wollny wrote:
>
> On 13.08.2015 18:17, Andreas Tille wrote:
> >I confirm that this at least has some effect - unfortunately not the wanted
> >one sinde the
> >
> > @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
> >
> >placeholders
On 13.08.2015 18:17, Andreas Tille wrote:
I confirm that this at least has some effect - unfortunately not the wanted
one sinde the
@BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
placeholders remain unresolved and the $(DEPS_LIBS) variable remains
empty. :_(
After digg
On Thu, Aug 13, 2015 at 03:40:21PM +0100, Simon McVittie wrote:
> On 13/08/15 15:06, Andreas Tille wrote:
> > +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@
> > @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
> > +
> > SUBDIRS = libMems
>
> Move this from /Makefile.am into /libMems/Makefile.a
On 13/08/15 15:06, Andreas Tille wrote:
> +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@
> @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
> +
> SUBDIRS = libMems
Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la
is built and the rest of the libMems_la_WHATEVER variables
e linking
> issue I reported: its dependencies are wrong.
>
> >> dpkg-shlibdeps: warning: symbol _ZN6muscle4QuitEPKcz used by
> >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in
> >> none of the libraries
> >> dpkg-shlibdeps: warning:
Hi,
I'm packaging software which consists of multiple libraries. I put
those libraries into various lib* binary packages with corresponding
lib*-dev packages. Some header files contained in the lib*-dev packages
include others in other lib*-dev packages, thus package dependencies
mu
On Sun, Aug 2, 2015 at 1:51 PM, Andreas Tille wrote:
> Is this simply a library transition issue and is somebody working in it?
Yes, the libstdc++ GCC5 ABI transition just started:
https://wiki.debian.org/GCC5
Various things will be uninstallable for a while.
--
bye,
pabs
https://wiki.debian
Hi,
I intended to build opensurgsim[1] using pbuilder (called from gbp) but I got
...
The following packages have unmet dependencies:
libstdc++6 : Breaks: libboost-date-time1.55.0 but 1.55.0+dfsg-4 is to be
installed.
Breaks: libdap17 (<= 3.14.0-2) but 3.14.0-2 is to be instal
iated
Andreas.
- Forwarded message from Andreas Tille -
Date: Fri, 17 Jul 2015 20:40:18 +0200
From: Andreas Tille
To: "Potter, Tim (Cloud Services)"
Cc: "debian-j...@lists.debian.org" , Debian Med
Packaging Team
Subject: Re: Packaging fest-swing and its dependencies
Le Tue, Jun 16, 2015 at 01:52:52PM +0200, Dominique Dumont a écrit :
>
> from the logs, tabix package is not installed.
>
> Neither samtools or samtools-test depends on tabix.
>
> Looks like ci does not install build dependencies...
Thanks Dominique, but I would have ex
On Tuesday 16 June 2015 20:11:57 Charles Plessy wrote:
> Does anybody spot what I have been missing ?
from the logs, tabix package is not installed.
Neither samtools or samtools-test depends on tabix.
Looks like ci does not install build dependencies...
Hope this helps
--
https://github.
Good evening everybody,
I am probably missing something obvious, but I have simple problem with the
samtools package, where the regression tests depend on the "tabix" package for
the "bgzip" command, and fail on ci.debian.net despite my attempt to set the
dependency properly...
$ curl
http:/
Salut,
I am currently facing a problem with two packages which need to be
updated roughly at the same time in order to work with each other, since
one is essentially the build system of the other.
The packages in question are uglifyjs and sockjs-client. Essentially,
there is an incompatible chang
On Tue, May 06, 2014 at 02:15:18PM +0200, Daniel Pocock wrote:
> Ok, I guess this can be looked at this as part of the OpenMAMA package
> update to get your packaged sponsored
>
> You have several wnpp bugs, I think the link I gave in the earlier email
> is not the one you link in the changelog, s
Your message dated Fri, 03 Jan 2014 04:26:20 +
with message-id
and subject line closing RFS: mwlib.ext/0.13.2-1 [ITP] -- external dependencies
needed by the mwlib library
has caused the Debian Bug report #719884,
regarding RFS: mwlib.ext/0.13.2-1 [ITP] -- external dependencies needed by the
rl5/DhMakePerl/Config.pm line 222.
http://manpages.debian.org/man/0/dh-make-perl
> - Or should I build the dependencies into binary packages and install
> them first?
No.
> - Or should I build everything into Debian source packages, including the
> dependencies, as if they are independen
Hi,
How to build to Debian source packages from Perl modules that have
(alien) dependencies? I.e., the dependencies are not exist yet.
- Can I specify multiple Perl modules to cpan2dsc/dh-make-perl?
- Or should I build the dependencies into binary packages and install
them first?
- Or should
* License : BSD-3
Section : python
It builds those binary packages:
python-mwlib.ext - external dependencies needed by the mwlib library
python-mwlib.ext-dbg - external dependencies needed by the mwlib library (debug
symbols)
python-mwlib.ext-doc - external dependencies needed by the mwl
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
1 - 100 of 721 matches
Mail list logo
