On Thu, Apr 06, 2023 at 05:01:07PM +0200, Paul Gevers wrote:
> Hi Peter,
>
> On 06-04-2023 15:37, Peter Pentchev wrote:
> > I feel like I cannot ask for an unblock from the release
> > managers since the sparc64 buildd started failing on this package
> > at some point i
Hi Peter,
On 06-04-2023 15:37, Peter Pentchev wrote:
I feel like I cannot ask for an unblock from the release
managers since the sparc64 buildd started failing on this package
at some point in February:
sparc64 is not a release architecture. sparc64 will not be better or
worse if something
.of course this should have been libzstd-1.5.4+dfsg2-5
> however, I feel like I cannot ask for an unblock from the release
> managers since the sparc64 buildd started failing on this package
> at some point in February:
>
> https://buildd.debian.org/status/logs.php?pkg=libzstd&arch
buildd started failing on this package
at some point in February:
https://buildd.debian.org/status/logs.php?pkg=libzstd&arch=sparc64
Now, the -1, -2, and -4 failures I can explain: there were some
problems in the upstream test suite that were fixed in -3 and -5.
However, -3 and -5 should really
On Thu, 2022-09-01 at 08:45 -0500, Steven Robbins wrote:
> OK, so let's call it "bin nmu", then. And add the "+bN" version
> suffix.
As others said, binNMUs exist, but not for arch:all packages. Debian
doesn't yet have sourceful no-change rebuilds, so you have to manually
do a sourceful no-chang
On Thu, Sep 01, 2022 at 08:45:06AM -0500, Steven Robbins wrote:
> > > Specficially: in the case of a NEW binary upload, could a manual request
> > > be
> > > implemented (pick a different name if "give back" is not suitable) such
> > > that it
Paul Said:
> On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:
> > Specficially: in the case of a NEW binary upload, could a manual request
> > be
> > implemented (pick a different name if "give back" is not suitable) such
> > that it is thrown away an
y upload, could a manual request be
> implemented (pick a different name if "give back" is not suitable) such that
> it
> is thrown away and replaced by a buildd build?
That's called a binNMU and it was already explained in this thread that it
already happens and th
On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:
> Specficially: in the case of a NEW binary upload, could a manual request be
> implemented (pick a different name if "give back" is not suitable) such that
> it
> is thrown away and replaced by a buildd build?
Th
On Tuesday, August 23, 2022 6:56:32 P.M. CDT Nilesh Patra wrote:
> On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
> >The binary upload cannot transition to testing -- a buildd binary build is
> >required. So far as I know -- assuming [1] is still up-to-date, this mean
ough NEW,
>> which in turn means a binary upload.
>>
>> The binary upload cannot transition to testing -- a buildd binary build is
>> required. So far as I know -- assuming [1] is still up-to-date, this means a
>> nuisance upload just bumping the debian revision from
On Wed, Aug 24, 2022 at 10:06:55PM +0200, Paul Gevers wrote:
> > The patch for dropping NEW binaries has been in dak for two years but
> > its configuration options were never enabled by ftp-master so far.
> > Dinstall::ThrowAwayNewBinarySuites
> > Dinstall::ThrowAwayNewBinaryComponents
> I would b
On Thu, Aug 25, 2022 at 07:13:52PM +0800, Paul Wise wrote:
> On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:
> > In testing and on release architectures, I'm only aware [1] of one that
> > can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
> > one builds its arch:all bin
4&suite=sid
There is also the Not-For-Us state, I think that is set manually by
porters or buildd admins, but this seems rarely done, one example:
https://buildd.debian.org/status/architecture.php?a=mipsel&suite=sid
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Hi all
On 25-08-2022 02:43, Paul Wise wrote:
I don't think Build-Architecture header is done yet?
Neither do I.
Although since we
build all arch:all packages on amd64 machines now I don't think this is
needed for throwing away NEW binaries?
In testing and on release architectures, I'm only
On 2022-08-25 08:43:58 +0800, Paul Wise wrote:
> On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote:
>
> > I run
> >
> > $ drt-tools process-excuses
> >
> > once a day (except during VAC or when I am not in front of a box with my
> > Debian keys). That schedules binNMUs for all packages
res.
A control file header build-architecture: YXY should do it.
- It's a suite option, not active for all at once.
- Should have all buildd machines under dsa control
Lintian based rejects is done long ago.
I don't think Build-Architecture header is done yet? Although sin
On 2022-08-24 22:06:55 +0200, Paul Gevers wrote:
> Hi,
>
> On 24-08-2022 02:05, Paul Wise wrote:
> > The release team automatically do binNMUs for packages that need a
> > rebuild to transition to testing and are able to be binNMUed
>
> Maybe my fellow Release Team members have automated this loc
Hi,
On 24-08-2022 02:05, Paul Wise wrote:
The release team automatically do binNMUs for packages that need a
rebuild to transition to testing and are able to be binNMUed
Maybe my fellow Release Team members have automated this locally, but
I'm not aware of shared tools (or even cron jobs) tha
Am Wed, Aug 24, 2022 at 12:09:20AM + schrieb Holger Levsen:
>
> it's rather easy to do too, though maybe there should be something in
> src:devscripts
> implementing something along these lines:
Sure its easy and may be everybody (including me) has written some local
scripts. The fact that
[My earlier mail went blank, not sure what's up with K-9]
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
>The binary upload cannot transition to testing -- a buildd binary build is
>required. So far as I know -- assuming [1] is still up-to-date, this means a
>nuisan
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
>The binary upload cannot transition to testing -- a buildd binary build is
>required. So far as I know -- assuming [1] is still up-to-date, this means a
>nuisance upload just bumping the debian revision from -1 to -2. Is t
nnot transition to testing -- a buildd binary build is
> required. So far as I know -- assuming [1] is still up-to-date, this means a
> nuisance upload just bumping the debian revision from -1 to -2. Is this
> still
> the recommended practice?
yes.
it's rather easy to do t
On Tue, 2022-08-23 at 16:59 -0500, Steven Robbins wrote:
> The binary upload cannot transition to testing -- a buildd binary build is
> required. So far as I know -- assuming [1] is still up-to-date, this means a
> nuisance upload just bumping the debian revision from -1 to -2.
Commonly, I update a package that provides a shared library. Due to the
package naming convention, a new SOVERSION necessitates a trip through NEW,
which in turn means a binary upload.
The binary upload cannot transition to testing -- a buildd binary build is
required. So far as I know
Hi,
After the recent spate of rebuilds for the new glibc, I had a couple packages
fail in their respective post-build test suite. For one package, the buildd
failure went away after a rebuild. The second package, libminc, however
failed on the buildd as recently as yesterday.
https
Quoting Scott Talbert (2022-06-15 22:30:13)
> Is it possible to instruct the buildds to use a build profile when performing
> an official build (e.g., using nocheck to break a dependency loop)? If so,
> how?
No, it is not. Main reason is probably that nobody has found the time to
implement it yet
Hi,
Is it possible to instruct the buildds to use a build profile when
performing an official build (e.g., using nocheck to break a dependency
loop)? If so, how?
Thanks,
Scott
PICCA Frederic-Emmanuel
writes:
>> That is mostly upstream's job -- ICD packagers should just verify that the
>> package still runs "Hello World" on their hardware, i.e. the ICD
>> integration works, and then we assume that it works.
>
> ok, so in that case it would be nice to provide a computer
> That is mostly upstream's job -- ICD packagers should just verify that the
> package still runs "Hello World" on their hardware, i.e. the ICD
> integration works, and then we assume that it works.
ok, so in that case it would be nice to provide a computer with a GPU as
porterbox to test this he
Hi,
On Tue, Nov 19, 2019 at 02:48:48PM +, PICCA Frederic-Emmanuel wrote:
> It would be nice also to be able to test the OpenCL icd implementations and
> work with real hardware.
That is mostly upstream's job -- ICD packagers should just verify that the
package still runs "Hello World" on th
It would be nice also to be able to test the OpenCL icd implementations and
work with real hardware.
Hi,
On Tue, Nov 19, 2019 at 09:21:16AM -0500, Sam Hartman wrote:
> I'm hoping there's no need for a GPU on a buildd.
> That would mean that the software required an active GPU to *build*,
> which seems problematic on a number of fronts.
As far as I've understood, t
On 19.11.19 05:59, Mo Zhou wrote:
> Given that there are also a number of packages in debian with OpenCL
> enabled, I'm wondering wether a shared buildd/CI/porterbox with GPU[2]
> could be helpful?
I would also be interested in this.
s to let us know how our money is helping Debian. See
>> https://wiki.debian.org/Teams/DPL/AskingForMoney for initial
>> instructions on such requests. That links to a reimbursements
>> page with the formal process.
PICCA> What about AMD sponsoring Debian via provi
ks to a reimbursements page with the formal process.
What about AMD sponsoring Debian via providing GPU to the Debian community,
whcih should be added to the buildd or in a porterbox ?
Frederic
> "Mo" == Mo Zhou writes:
Mo> Hi folks, Just a bold thought.
Mo> Two Debian developers intended to package basic libraries of the
Mo> AMD ROCm (freesoftware-licensed) [1], but both of them don't
Mo> have access to such hardware.
Debian has from time to time funded hardware
r a shared buildd/CI/porterbox with GPU[2]
could be helpful?
Disclaimer: I have zero experience about AMD GPU, and I don't know how
good the free driver is.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943556#20
[2] I mean AMD GPU running with free driver. None of nvidia's business here.
On Wed, 02 Jan 2019 at 12:53:32 -0800, Joseph Herlant wrote:
> With one of my package (cmph), when I added debci tests, locally
> running autopkgtests using --run-autopkgtests in gbh that uses sbuild
sbuild --run-autopkgtests is a sbuild feature, not a debci or autopkgtest
feature. It does not nec
Hi Nicholas,
On Wed, Jan 2, 2019 at 2:11 PM Nicholas D Steeves wrote:
> Have you tried an LXC autopkgtest instance? I've noticed that
> sometimes packages whose tests pass 100% of the time with a schroot
> (buildd profile) will fail on debci, and the only way I've been able
t; Joseph
>
Have you tried an LXC autopkgtest instance? I've noticed that
sometimes packages whose tests pass 100% of the time with a schroot
(buildd profile) will fail on debci, and the only way I've been able
to reproduce the failure is with an LXC autopkgtest.
I will confess
Hi guys,
With one of my package (cmph), when I added debci tests, locally
running autopkgtests using --run-autopkgtests in gbh that uses sbuild,
I have no problem but when it runs on debci, it seems to miss packages
(gcc at fist, now stdlibs, etc) or my local schroot has too many. I
recreate my sc
d using
> hot needles? Anyways, I'm interested in how this is done…"this" meaning
> the imaging/deployment part. Not the setup/configuration of a buildd itself.
>
The machines are not re-imaged. The build chroots are regenerated, with
something more or less
done…"this" meaning
the imaging/deployment part. Not the setup/configuration of a buildd itself.
Thanks!
Daniel
signature.asc
Description: OpenPGP digital signature
On Sun, Jan 01, 2017 at 05:40:44PM +0100, Guillem Jover wrote:
> The only correct "solution" I see while keeping the current mess, would
> be to declare binNMU versions a globally shared resource across all
> architectures (in and out of archive!), trigger them globally for all
> architectures (or
[ Had this half-drafted, but had not found the time to finish it up
until now. ]
Hi!
On Mon, 2016-11-14 at 13:52:18 +, Ian Jackson wrote:
> Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
> misleading timestamps in binnmus"):
> > Instead, f
Hi!
On Mon, 2016-12-19 at 13:12:32 +0100, Johannes Schauer wrote:
> Quoting Mattia Rizzolo (2016-12-18 11:38:24)
> > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> > > As Arno hinted at, it's to have reliable builds. A transient inability
> > > to install the first arm of an alter
On Mon, Dec 19, 2016 at 01:12:32PM +0100, Johannes Schauer wrote:
> Hi,
>
> Quoting Mattia Rizzolo (2016-12-18 11:38:24)
> > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> > > As Arno hinted at, it's to have reliable builds. A transient inability
> > > to install the first arm of
On Mon, Dec 19, 2016 at 09:13:25AM +0100, Daniel Pocock wrote:
> Provides: libssl1.0-dev
>
> in the control file and would that ensure it works without tweaks?
It might, but the proper way to fix it is:
Build-Depends: libssl1.0-dev (>= 1.0.0) | libssl-dev (<< 1.1)
i.e., put what's in unstable f
On 2016-12-19 12:12, Johannes Schauer wrote:
Imagine you even directly build-depend on a virtual package. There is
currently
no way to somehow "reliably" always pick the same real provider of that
virtual
package.
I'm not sure how that isn't exactly what you're doing by depending on
"provide
Hi,
Quoting Mattia Rizzolo (2016-12-18 11:38:24)
> On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> > As Arno hinted at, it's to have reliable builds. A transient inability
> > to install the first arm of an alternation should caused a dep-wait
> > state, not building with the alter
Hi,
Quoting James McCoy (2016-12-18 16:04:47)
> On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote:
> > Hi,
> >
> > 2016-12-18 14:14 GMT+01:00 James McCoy :
> >
> > Well, sbuild's man page documents that the aptitude resolver will check
> > alternatives. If it doesn't in practic
ectly builds it for sid with libssl1.0-dev from openssl1.0[2]
>>
>> In the buildd[3] report, it says that libssl-dev is uninstallable on
>> every platform, it doesn't appear to try libssl1.0-dev
>>
>> Is buildd sensitive to the order of the dependencies when multipl
Allow the use of alternatives in Build-Depends,
Build-Depends-Arch and Build-Depends-Indep. This is the
default for the aptitude dependency resolver.
so there shouldn't be a need to use --resolve-alternatives with
--build-dep-resolver=aptitude.
The python-tornado backport
Hi,
2016-12-18 14:14 GMT+01:00 James McCoy :
> Well, sbuild's man page documents that the aptitude resolver will check
> alternatives. If it doesn't in practice, that sounds like a bug.
>
you need to run sbuild with "--resolve-alternatives" or add same option in
sbuildrc. Imho bug in manpage.
-
On Dec 18, 2016 05:38, "Mattia Rizzolo" wrote:
On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> Now, backports are a different story because they use a different
> resolver which will pull in alternates.
afaik sbuild strips the alternatives while parsing the .dsc (or
d/control or w
ight:
https://buildd.debian.org/status/package.php?p=python-tornado&suite=jessie-backports
https://anonscm.debian.org/cgit/python-modules/packages/python-tornado.git/tree/debian/control#n24
python-tornado build-depends on missing:
- python3:arm64 (>= 3.5)
So jessie-backports buildd have this &
On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> As Arno hinted at, it's to have reliable builds. A transient inability
> to install the first arm of an alternation should caused a dep-wait
> state, not building with the alternate Build-Depends.
which is kinda bullshit, as a differe
On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> Now, backports are a different story because they use a different
> resolver which will pull in alternates.
That's great to hear. Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
t; > >
> > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ...
> > >
> > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
> > >
> > > In the buildd[3] report, it says that libs
1.0.0), ...
> >
> > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
> >
> > In the buildd[3] report, it says that libssl-dev is uninstallable on
> > every platform, it doesn't appear to try libssl1.0-dev
> >
> > Is buildd s
On 12/17/2016 04:49 PM, Daniel Pocock wrote:
> In my reSIProcate control[1] file, I included the following:
>
> Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ...
>
> pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
>
&g
Daniel Pocock writes:
> In my reSIProcate control[1] file, I included the following:
>
>
> Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ...
>
>
> pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
>
> In the b
In my reSIProcate control[1] file, I included the following:
Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ...
pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
In the buildd[3] report, it says that libssl-dev is uninstallable
On Thu, Dec 01, 2016 at 04:51:39PM +0100, Johannes Schauer wrote:
> Hi,
>
> Quoting Wouter Verhelst (2016-12-01 16:24:16)
> > On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > > But maybe to talk about this option: what would speak against changing the
> > > "nmu" command of wa
Hi,
Quoting Wouter Verhelst (2016-12-01 16:24:16)
> On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > But maybe to talk about this option: what would speak against changing the
> > "nmu" command of wanna-build to also add an option that allows setting a
> > timestamp, or even l
Hi,
(Sorry for piping in so late to the party here)
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> But maybe to talk about this option: what would speak against changing the
> "nmu" command of wanna-build to also add an option that allows setting a
> timestamp, or even let wa
Hi,
Quoting Holger Levsen (2016-11-14 18:25:34)
> To me it seems a binNMU should change SOURCE_DATE_EPOCH, as debian/changelog
> gets modified by changelog.$arch, so it's actually a different source which
> is being build.
debian/changelog doesn't get modified by changelog.$arch. The latter is
ge
Hi,
On Mon, 14 Nov 2016, Johannes Schauer wrote:
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
>
> I found Guillem's suggestion the most sensible and as far as I understand the
> matter also the easiest to implement:
>
> Quoting Guillem
Ian Jackson wrote:
[...]
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve looking
> in the archive to see what the previous binnmu timestamp was.
[...]
The reference point would be the last source change accor
Hi,
thanks for having this discussion!
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-11-14 17:33:55)
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
>
> I found Guillem's suggestion the most s
Hi,
Quoting Ian Jackson (2016-11-14 17:33:55)
> Unless the timestamp is of the binnmu request, plumbing to try to get
> the same timestamp will be difficult.
>
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> I want to understand why passing the same timestamp to all
> architectures is an inferior solution to your proposal.
This is a sensible question. Thanks for helpin
Hi,
Quoting Ian Jackson (2016-11-14 14:52:18)
>I don't think it is possible to make the binnmu timestamp the same
>across architectures. For example, a package might be rebuilt only
>on some architectures. I don't think we want to change that. In
>particular, even if we were pre
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> Instead, file conflicts might be created from files with
> content that depends on SOURCE_DATE_EPOCH.
tl;dr:
Analysis. Revised proposal:
Introduce BUILD_DATE_
Hi,
Quoting Ximin Luo (2016-11-10 18:13:00)
> Holger Levsen wrote:
> > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> > > binNMU to a package.
> > >
> > > Any other ideas?
> > set SOURCE_DATE_EPOC
(resending again to the correct addresses; I could never get used to debbugs CC
behaviour.)
Ximin Luo:
> Ansgar Burchardt wrote:
>> The date from the last sourceful upload should probably still be used
>> for any date/time information included in generated files to ensure
>> they are identical on
On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> binNMU to a package.
>
> Any other ideas?
set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
entry?
--
cheers,
Holger
signat
Hi,
Quoting Emilio Pozuelo Monfort (2016-11-10 07:04:55)
> On 10/11/16 10:00, Ansgar Burchardt wrote:
> > The date from the last sourceful upload should probably still be used
> > for any date/time information included in generated files to ensure
> > they are identical on all architectures (or at
On Mon, Oct 17, 2016 at 03:10:57AM +0100, Ben Hutchings wrote:
> On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote:
> [...]
> > You should fix your package so that it works on the lowest supported
> > hardware of each port.
>
> Right.
>
> > Autobuilding is only a small part of the problem, yo
On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote:
[...]
> You should fix your package so that it works on the lowest supported
> hardware of each port.
Right.
> Autobuilding is only a small part of the problem, your package would
> also not run on many computers that Debian does support.
>
X -msse4.2 -DUSE_SSE4_2 -msse4.1 -DUSE_SSE4_1 -msse3 -DUSE_SSE3
-msse2 -DUSE_SSE2
> My questions:
>
> * should we suspect the health state of that amd64 buildd
>machine «binet»?
> * what should I do next? do a binary-only amd64 upload or
>request (and how) for a rebu
rouble allocating where the source of problem is.
>
> Cosmic ray?
>
> My questions:
>
> * should we suspect the health state of that amd64 buildd
>machine «binet»?
I'd bet first on a real SIGILL.
This can come from two sources:
* using an instruction specific to a pa
md64[3] and the
result is quite healthy.
So I have trouble allocating where the source of problem is.
Cosmic ray?
My questions:
* should we suspect the health state of that amd64 buildd
machine «binet»?
* what should I do next? do a binary-only amd64 upload or
request (and how) for a reb
On 30/07/2015 15:56, Nikolaus Rath wrote:
On Jul 30 2015, Raphael Hertzog wrote:
On Thu, 30 Jul 2015, Johannes Schauer wrote:
there are (unfortunately) a number of situations I encountered when sbuild
would just hang or just fail without any sensible error message. In my case,
the most common
Signed-off-by: Thorsten Glaser
---
library.php | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/library.php b/library.php
index a5a0d8e..43e2c45 100644
--- a/library.php
+++ b/library.php
@@ -1432,7 +1432,7 @@ function html_footer_text($raw=false) {
echo "
Page generated on
/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found
>> in none of the libraries
>> dpkg-shlibdeps: warning: symbol omp_get_wtime used by
>> debian/libhealpix-cxx0/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found
>> in none of the libraries
>> ...
&g
On Tue, Jun 10, 2014 at 06:01:19PM +0200, Jakub Wilk wrote:
> * Vincent Danjean , 2014-06-10, 16:27:
> >>In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing
> >>OpenMP symbols. See, for example, this excerpt from
> >>https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=
On Jun 10, 2014, at 7:27 AM, Vincent Danjean wrote:
> On 10/06/2014 00:45, Leo Singer wrote:
>> Hi,
>>
>> In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing OpenMP
>> symbols. See, for example, this excerpt from
>> https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&ar
Vincent Danjean wrote:
>On 10/06/2014 00:45, Leo Singer wrote:
>> Hi,
>>
>> In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing OpenMP
>> symbols. See, for example, this excerpt from
>> >>https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=i386&ver=3.11.2-6&stamp=1401
* Vincent Danjean , 2014-06-10, 16:27:
In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing
OpenMP symbols. See, for example, this excerpt from
https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=i386&ver=3.11.2-6&stamp=1401836504:
At a quick glance, I do not see t
On 10/06/2014 00:45, Leo Singer wrote:
> Hi,
>
> In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing OpenMP
> symbols. See, for example, this excerpt from
> https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=i386&ver=3.11.2-6&stamp=1401836504:
At a quick glance,
s
> dpkg-shlibdeps: warning: symbol omp_get_wtime used by
> debian/libhealpix-cxx0/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found
> in none of the libraries
> ...
Furthermore, the package built by the buildd is missing a dependency on
libgomp1:
https://packages.debian.org/sid/libhea
On 27/02/14 11:57, Jakub Wilk wrote:
>>> "any" may be interpreted as the prefered arch, which is advised (but
>>> not required) to be amd64. If multiple values are provided, the first
>>> value (only) will be used to build the arch:all package.
>>
>> Any arguments on this rough concept?
>
> What a
I'm afraid we might not be able to build this bikeshed after all. ;P
* Paul Tagliamonte , 2014-02-26, 21:51:
For the implementation we might want to have a priority list. The
first architecture from the priority list that is allowed in
Build-Arch-Indep (or whatever) would build the arch:all pac
On Wed, Feb 26, 2014 at 10:09:22PM -0500, James McCoy wrote:
> On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> > So, building off this mail (and ideas I had kicking around):
> >
> >
> > | Build-Depends-Indep field is defined as a list of architectures that the
> ^-- Build
On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> So, building off this mail (and ideas I had kicking around):
>
>
> | Build-Depends-Indep field is defined as a list of architectures that the
^-- Build-Architecture-Indep, right?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 20
On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote:
> Comments?
Erm, also - any package which omits this field may be considerd "any"
(or something like that)
Cheers,
Paul
--
.''`. Paul Tagliamonte | Proud Debian Developer
: :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7
fered arch, which is advised (but not
| required) to be amd64. If multiple values are provided, the first value
| (only) will be used to build the arch:all package.
Any arguments on this rough concept?
I figure we can treat the list sorta like we do with OR'd
Build-Depends (after all, aren't
On Wed, Feb 26, 2014 at 11:28 PM, Ansgar Burchardt wrote:
> "Build-Architecture-Indep" might also work and is visually similar to
> the already existing "Build-Depends-Indep" and "Build-Conflicts-Indep"
> fields.
Why not just Build-Architectures? That also covers the case where an
arch-dependent
1 - 100 of 824 matches
Mail list logo
