Hi all,
We'd like to know if there's an update planned for stable too, these could be
nasty and are flagging in our security software. If there's anything that we
can do to help let us know.
Regards
Rowan
2
builds, not 3.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ally just build -21 with -17 if I can persuade the build system, or
will something important break with that much version-skew?
can I build -19 with -17 (and appropriate t64 dep updates) (-18 is no longer in
the archive so I really hope we don't need to go 18,19,20,21
Clues welcome on th
/include -I./libprelude-error -I../libmissing -I../libmissing
-I/usr/include/p11-kit-1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/home/wookey/debian/libprelude-5.2.0=.
-fstack-protector
On 2023-11-08 20:10 +0100, Martin Budaj wrote:
> On Tue, Nov 7, 2023 at 4:25 PM Wookey wrote:
>
> > It looks like moving to catch3 and adding:
> > target_link_libraries(test PRIVATE Catch2::Catch2WithMain)
> > in the test targets should do the trick.
> >
>
Catch2/blob/devel/docs/migrate-v2-to-v3.md
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
are just told to 'use the right one' will do so,
and I thought it worth pointing out that that's not correct). Info for
your average maintainer needs to go one step back and say "use stringA
in this circumstance and stringB in this circumstance. . The reason why it matter
00 +
+++ openjfx-11.0.11+1/debian/changelog 2023-07-14 11:53:33.0 +
@@ -1,3 +1,10 @@
+openjfx (11.0.11+1-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply patch from webkit #217079 so arm64 builds again
+
+ -- Wookey Fri, 14 Jul 2023 11:53:33 +
+
openj
The attached patch is confirmed as fixing the problem.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
diff -Nru mdbtools-1.0.0+dfsg/debian/changelog mdbtools-1.0.0+dfsg/debian/changelog
--- mdbtools-1.0.0+dfsg/debian/changelog 2021-10-31 14:01:12.0 +
p 32-bit
time.
So in summary, tar is a good candidate for enabling LFS and time64
early but some checks should be done first, unless it is known that
there are no external interface changes other than to glibc.
I hope that is helpful.
Wookey
--
Principal hats: Debian, Wookware, ARM
http:/
#x27;t for at least another month
(on holiday away from computers).
Ah, but I see Bernhard has fixed it in the meantime.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Package: armnn
Version: 20.08
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
armnn has built fine in the past but -10 and -7 both failed to build when the
build machine was antheil.
Antheil is one of the Marvell armada 32-bit
that fixes the problem is attached to this message.
Thanks Rafael.
I'm away on expedition with negligible internet until 12th Sept, so if
anyone wishes to NMU this, that's fine by me. Otherwise it'll get done
sometime after I get back.
--
Wookey
Severity: normal
This is not a serious bug and is currently slated to remove monit from testing.
Please check for severities here
https://www.debian.org/Bugs/Developer#severities
It's been rejected upstream I'll let the maintainers here comment on if it
should be accepted or rejected here.
-1 pam_yubico fails to install module in multiarch path
> control: found -1 2.23-1
>
>>>>>> "Rowan" == Rowan Wookey writes:
>
> Rowan> It
Wookey wrote::
> Testing it now.
Nope, that doesn't actually fix the problem, although it appears to
have reduced the number of instances of complaint (that may just be an artifact
of parallel=1)
Not totally clear what's going on here (the function and prototype
seems to match
On 2021-04-29 09:04 +0200, Michael R. Crusoe wrote:
>I found a PR that someone else sent to upstream to fix this at
>https://github.com/projectNe10/Ne10/pull/260 (I haven't tested it, though)
That does indeed look like the right fix. Cheers for finding that. Testing it
n
.deb
>
> Those files have been added in version 2.6.16, and it seems it was just
> a mistake.
Hmm. That's a bit of a cock-up! Not sure how that happened.
Fixed. Upload to follow.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
t) is such that there is no real point debian maintaining this
free wrapper for the non-free driver any longer (and certainly not for
a whole stable cycle).
Looks like I failed to get round to filing a remove bug. I'll do that
if it's not too late.
Wookey
--
Principal hats: Lin
ed to get the migration going and allow others to test. I
should be able to contrive a non-headless armhf machine too, given a
bit of time (not today)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ted to python3 and we have a useful package again :-)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Not had an answer on how this is generated yet, but so far as I can
tell the consensus is that no-one really cares about this driver being
in debian now that the free drivers are in reasonable shape so
probably best to just quietly let this die.
I guess I should file a removal request.
Wookey
piece of software
which can be modified and updated on its own so I'm not convinced that
this is actually grounds to throw it out.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2020-11-28 07:32 -0400, David Bremner wrote:
> Wookey writes:
>
> > On 2020-11-27 10:28 -0400, David Bremner wrote:
> >
> >> I'm talking about remove polymake/arm64, not perl.
> >
> > Right, but perl build-depends on polymake, so with no polymake
On 2020-11-27 10:28 -0400, David Bremner wrote:
> I'm talking about remove polymake/arm64, not perl.
Right, but perl build-depends on polymake, so with no polymake we
can't update perl (e.g. for security reasons)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http:/
On 2020-11-27 06:52 -0400, David Bremner wrote:
> Wookey writes:
>> On 2020-11-17 21:19 +, Dominic Hargreaves wrote:
>>> Thanks for your work on this. As of today polymake has been uploaded
>>> to use gcc-9 which doesn't have this problem, so the perl t
polymake codebase, which ICEs all the way back to GCC 6, so this has
been around for a while.
(Thanks for investigating, Alex)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
So this is the failing command from the build:
g++ -c -o
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o
-MMD -MT
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o
-MF
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl
.
Building the one file alone:
g++ -c -o
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o
-MMD -MT
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o
-MF
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o.d
illustrate the
coupling between the APIs on these packages. I will consult with
upstream about exactly how this should best be done. The rate of
change may slow soon and this become moot, but I'm not sure about
that.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookwar
yes, the attempt in the package rules to avoid build failures on unsupported
architectures actually was null in the debian context and just broke the
ability to build the arch-all binaries on any architecture (needed for
source-only uploads).
Fixed in 19.11-3, just uploaded.
Wookey
y it longer or cancel the NMU.
Thanks for that fix. I have a mostly-prepared 0.14 here, which was
waiting for upstream to make some other fixes, and to solve the
javahelper build issue, but upstream seems to have stalled for now, so
I'll upload 0.14 with your fix.
Wookey
--
Principal hats:
st cases: 17 | 16 passed | 1 failed
> assertions: 41 | 38 passed | 3 failed
Hmm. turns out this test works with libproj 7.0.1 but fails with
libproj 7.1.0. Odd. (and that was uploaded just after I did my build).
I'll take a look at what's up.
Wookey
--
Principal hats: Linaro,
Correction: The va_list problem seems to affect ARM architectures only.
This is a classic 'porting to arm' issue which used to catch people
out regularly 15 years ago because it was something where you could do
technically incorrect things that worked fine on other
architectures. It&#x
On 2019-04-19 00:32 +0100, Wookey wrote:
> > jh_build: Compatibility levels before 9 are deprecated (level 7 in use)
> > jh_build: Cannot find (any matches for) "caveconverter" (tried in .)
>
> Confirmed, thanks. I'll work out what's gone wrong there and
are deprecated (level 7 in use)
> jh_build: Cannot find (any matches for) "caveconverter" (tried in .)
Confirmed, thanks. I'll work out what's gone wrong there and upload a fix.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
CPU}
> +endif
> +
> %:
> dh $@
>
> override_dh_auto_configure:
> +
> dh_auto_configure -- \
> - -DNE10_LINUX_TARGET_ARCH=$(DEB_TARGET_GNU_CPU) \
> + -DNE10_LINUX_TARGET_ARCH=$(NE10_LINUX_TARGET_ARCH) \
> -DGNULINUX_PLATFORM=ON \
> -DNE10_BUILD_SHARED=ON
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2018-12-07 04:03 +, Debian Bug Tracking System wrote:
I have now uploaded drf-extensions 0.4.0-1.1 to delayed/10, so this
should become sorted in due course if everyone is happy with that.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
there
are reasons not to? I don't see any obvious ones.
I propose to NMU this to 0.4 (delayed/7) unless someone objects.
Proposed package is here:
http://wookware.org/software/repo/pool/main/d/drf-extensions/
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
sig
h
v1.11 on the wiki page: https://wiki.debian.org/Qbs, but had forgotten
about it. Updated now.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2018-04-01 11:11 +0100, Chris Lamb wrote:
> Source: horizon-eda
> Version: 0.20180331-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Wookey
>
> Hi,
>
> I just ACCEPTed horizon-eda from NEW but noticed it was missing
> attribution in debia
> }
Aha. Cheers very much for that. Upstream hadn't provided one yet, so I was
thinking I was going to have to try and work it out myself.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ttps://buildd.debian.org/status/package.php?p=dewalls
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
our purposes.
e.g.
/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:31: FAILED:
CHECK( WallsSurveyParser("5:4").azimuth(Angle::Degrees) == UAngle(5 + 4 /
60.0, Angle::Degrees) )
with expansion:
5.06667 deg == 5.06667 deg
I see that 'approx' is used in the cod
On 2018-03-09 05:06 +, Wookey wrote:
>
> Changing the tests to this:
> CHECK_THROWS( WallsSurveyParser("360.1").azimuth(Angle::Degrees)
> );
> CHECK_THROWS( WallsSurveyParser("-0.1").azimuth(Angle::Degrees) );
> CHECK_TH
e same as
libc in this regard, and having to be asked for explicitly, but
clearly I am either confused or out of date.
You are right that simply not specifying it does work in a clean
build, and thus is the simplest way to proceed.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://
this really is a
rounding problem on i386. I could experiment further to try and
determine the size of the rounding error.
I could leave this bodge in in order to get i386 built and dewalls
migrated into testing, but it would be better to actually fix the
problem if possible. I could also a
sid_i386-dchroot)wookey@barriere:~/dewalls-1.0.0+ds1$
qbs-build/dewalls-test.a3cdf9ea/dewalls-test -f test/azimuthparsingtests.cpp
azimuth* -c "misc invalid values throw"
===
All tests passed (6 assertions in 1 tes
On 2018-03-08 18:20 +, Wookey wrote:
> It looks like we have libstdc++6 and libstdc++-dev virtual
> packages. Is it OK to build-depend on just a virtual package? Perusing
> Policy has not made me much wiser.
Using:
Build-Depends: libstdc++-dev
builds OK, but I found the info poi
avoid causing this problem again in future.
It looks like we have libstdc++6 and libstdc++-dev virtual
packages. Is it OK to build-depend on just a virtual package? Perusing
Policy has not made me much wiser.
Is there a doc about this somewhere?
Wookey
--
Principal hats: Linaro, Debian,
e some bottom-getting-to.
I should probbaly just have used a debian porter-box, but that machine
needed updating anyway.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
I've reported this to upstream in the hope of a clue as to why it
fails on i386 but works on all the other release arches.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
s I couldn't check an sbuild build on my armhf
device so there was a risk of bugs like this.
Update coming shortly.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
r form
in builds as it's supposed to be set to non-existant to catch this
sort of breakage.
Confirmed that --settings-dir works with all prvious config cleaned out.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
> the description should make that clear.
The mali reverse-engineering effort has recently restarted after being
moribund for a few years, (https://github.com/yuq/mesa-lima) and it's
possible that this driver will be useful there, but I don't know that
yet. I'll check with that pr
o be too cleaver and access struct members
directly.
I tried this on two architectures and both fail the same way.
Wookey
is gone for now. It should
probably be retitled to something about library sync/using host libs
and left open until it's fixed propoerly.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable
Dear Maintainer,
The current installer, with the new 4.9 kernel, is unable to resolve
domains, so is quite seriously broken.
This was noted during install on an arm64 gigabyte MP30-AR1
desktop/server,
#package working correctly
close 796331
thanks
--
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
On 2016-12-08 22:03 +, Ben Hutchings wrote:
> Control: severity -1 serious
>
> Raising severity; this should be a release blocker.
>
> On Fri, 18 Mar 2016 18:42:24 + Wookey wrote:
> > Source: luajit
> > Version: 2.1.0~beta2+dfsg-1
> > Severity: i
Sorry this has taken so long to reply. Elena is right, the software is
working as expected and trying to tell you that the key the main jessie
emdebian archive is signed with has been revoked.
i.e. it is working as expected.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http
Wookey wrote:
Anyway, I'll test raphael's patch.
OK, so building dpkg is a bit tricky becuase it FTBFS with the same
ld-linux-armhf.so.3 dpkg-shlibdeps error, but adding a -l/lib/ in the
rules file fixed it.
With the new dpkg installed, mythtv did indeed run through
dh_shlibdeps OK
On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
> On Tue, 15 Nov 2016 17:22:12 +0000 Wookey wrote:
> > Package: dpkg
> > Version: 1.18.10
> > Severity: normal
> >
> > I built a large package (mythtv) with this recipie:
> > git clone https://github.com
the delay fixing this, but it
turns out to be a little complicated.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
(5.0.0a-2.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use dh_autotools_dev instead of dh_autoreconf
+as autoreconf needs a major autofoo update
+
+ -- Wookey Thu, 04 Aug 2016 23:29:53 +
+
most (5.0.0a-2.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru most-5.
ou meant?
When might one use one or the other?
Should I adjust the advice on https://wiki.debian.org/Autoreconf ?
Guess I'd better read the man page.
Anyway thanks for the report. I'll fix, test and reupload.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
maintainer wants any changes I'm happy to re-upload.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
hitectures
+ * Reinstate quiltification from 5.0.0a-2.2 NMU
+
+ -- Wookey Fri, 22 Jul 2016 01:26:53 +0100
+
most (5.0.0a-2.3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru most-5.0.0a/debian/compat most-5.0.0a/debian/compat
--- most-5.0.0a/debian/compat 2016-07-22 01:42:16.0
+++ Debian Bug Tracking System [2016-02-15 19:33 +]:
> Guess I'd better test this build on amd64 and see if I get the same failure
OK. I do indeed get the same failure on amd64, so this is due to the
autoreconfing and associated changes somehow.
Wookey
--
Principal hats: Linaro
+++ tony [2016-02-11 07:43 -0800]:
> Hi Wookey,
>
> Just a quick response - I haven't yet had any time to dig into this in
> any detail, but also didn't want your email to go un-answered.
cheers
> First of all, thank you for working on this! I don't have any dire
ailed after the src build, because debian
patches back in Makefile.am a 'lookat' target into, the source file
for which was removed in 2006! after dh_autoreconfing this gets back
into the build and it barfs.
GUess I'd better fix that and try again...
Wookey
--
Principal h
not looked to see how well the
APIs match up.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
> /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld:
> this linker was not configured to use sysroots
> collect2: error: ld returned 1 exit status
Right. I hit this problem too.
I can confirm that the new upload 2.25.1-3 fixes it
Wookey
--
Principal h
this is a
non-automake/non-libtool package.
So it does all make sense.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ol file so the above one-line
change is all that's needed). Patch attached anyway, as I've done one.
I'm happy to NMU this if you like.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -Nru elinks-0.12~pre6/debian/changelog elinks-0.12~pre6/
ecause gcc-4.9-arm-linux-gnueabihf depends on version
> 4.9.2-18 of libgcc-4.9-dev, but only 4.9.2-21 is available. The same for
> gcc-4.9-arm-linux-gnueabi.
Yes, the gcc packages got out of date and were not rebuildable (on
amd64) for a while due to 787004.
That's fixed now so I've
in/bugreport.cgi?bug=787004 is fixed, I
can't build a replacement upload yet. Hopefully that will be sorted
soon. Use a snapshot or testing in the meantime.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...
ebian/changelog
--- linux-4.0.4/debian/changelog 2015-05-26 02:30:07.0 +0100
+++ linux-4.0.4.new/debian/changelog 2015-06-05 03:13:13.936808845 +0100
@@ -1,3 +1,10 @@
+linux (4.0.4-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on amd64 (Closes: #787004)
+
+ -- W
ll
need to be applied to make these packages build. The relevant
wanna-build bug is #770925.
(In fact some builds with multiarch build-deps worked before the
jessie upgrade, but only due to the way the wheezy version of dose
worked)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http:
x27;t installed.
>
> Installing realpath allowed cross-gcc-gensource to work, so
> cross-gcc-dev should depend on realpath...
Well spotted. Fixed in git. THere will be a new upload in the next few
days.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
know dpkg-cross is considered completely deprecated and
> that it should be left to die, the config.site support is something
> that is supposed to move elsewhere AFAIK, so that's the reason I've
> bothered reporting this at all.
Yes, some functionality something like this ne
//packages.debian.org/unstable/gcc-4.9-arm-linux-gnueabihf
I just checked.
Did you do
dpkg --add-architecture armhf
before the update?
That is needed to have the dependencies available.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email t
+++ Uwe Kleine-König [2014-11-27 20:16 +0100]:
> Source: gcc-arm-linux-gnueabihf
> Version: 4.9.2-2
> Severity: serious
> Justification: Not installable
>
> Hello wookey,
>
> gcc-arm-linux-gnueabihf depends on gcc-4.9-arm-linux-gnueabihf which in
> turn:
>
>
Just a datapoint:
It builds fine under sbuild:
sbuild -A -s -d unstable mpi4py_1.3.1+hg20131106-1.dsc
The test run OK there, but maybe sbuild does less environment sanitising?
As it's sbuild that gets used on the buildds, does that mean that this
is not actually a serious bug?
W
0.9b/po/Makefile.in.in gtktrain-0.9b/po/Makefile.in.in
reverted:
diff -u gtktrain-0.9b/debian/changelog gtktrain-0.9b/debian/changelog
--- gtktrain-0.9b/debian/changelog
+++ gtktrain-0.9b/debian/changelog
@@ -1,3 +1,10 @@
+gtktrain (0.9b-13.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Use
Package: gtktrain
Followup-For: Bug #759232
This bug isnot due to spaces/TABs but due to having this stanza in
intl/Makefile.in:
# The dependency for intlh.inst is different in gettext and all other
# packages. Because we cannot you GNU make features we have to solve
2013-06-19 10:55:06.0 +
+++ openmeeg-2.0.0.dfsg/debian/changelog 2014-10-27 01:36:10.0 +
@@ -1,3 +1,10 @@
+openmeeg (2.0.0.dfsg-5.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Transition libtiff dependencies away from libtiff4 (Closes: 736035)
+
+ -- Wookey M
, but as the
others stuff (built from the same version) have to be in sync anyway
this makes no practical difference.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
d build-profiles support)
available in the normal release makes it easier for people to work on
this stuff.
So I see no reason to block these packages because they do not include
cross-gobjc, cross-gccgo, cross-gcj etc.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http:/
st packages in Debian to require this. ia32-libs
and some wine packages already do this.
So until buildds are actually updated this bug is technically correct,
but I do not believe it should block the packages from
migrating. Ultimately the release team gets to decide.
Wookey
--
Principal hats: Li
an to do an NMU in order to unblock arm64 builds.
Wookey
diff -Nru qtwebkit-2.2.1/debian/changelog qtwebkit-2.2.1/debian/changelog
--- qtwebkit-2.2.1/debian/changelog 2013-11-05 01:15:31.0 +
+++ qtwebkit-2.2.1/debian/changelog 2014-06-08 00:20:13.0 +
@@ -1,3 +1,10 @@
+qtw
m
+
+ * Non-maintainer upload
+ * Add acinclude.m4 macro to find correct intlh header whether or
+not gettext is present (Closes: #748626)
+ * Update rules file to use dh-autoreconf rather than manual commands
+and update configure.in enough for autoreconf to work
+
+ -- Wookey Wed, 06 A
Source: pcre3
Version: 8.35-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
You have addded dh-autoreconf support (thank you!), but forgotten to
add the dh-autoreconf build-dep that it needs. (Always test with
sbuild/pbuilder before up
tags 724078 + pending
thanks
Dear maintainer,
This package has been FTBFS for several months, and thus failed to
build in arm64 which is building now:
(http://buildd.debian-ports.org/status/architecture.php?a=arm64&suite=sid).
So I've prepared an NMU for dhcpcd-dbus (versioned as 0.6.0-1.1) and
quot;. This one just removes them.
My understanding of c++ symbols is such that I don't know which is
better (or whether the arm64 fix works on mips64). But either fix
makes the package satisfactory on arm64 so is OK with me.
Hope this is a useful datapoint.
Wookey
--
Principal hats: Linaro
Hmm, apparently I failed to actually upload this.
Trying again...
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Conta
I just confirmed this issue on arm64 (building raptor for the first time).
Removing the autoreconf.mk line from debian/rules lets it build. So
the shipped ./configure is OK, but the one generated by the autoreconf
isn't.
I've not yet investigated further.
Wookey
--
Principal hat
tags 749061 + pending
thanks
Dear maintainer,
I've prepared an NMU for graphviz (versioned as 2.26.3-17.1)
fixing this issue, which unblocks a lot of packages for the arm64 port.
I've uploaded it to DELAYED/2. Please feel free to tell me that I
should delay it longer.
cheers
--
W
I prepared a patch for this, and tested it on arm64. Fixes the build
problem as advertised.
Simple patch attached. I'm happy to NMU this if you like,
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
diff -Nru psensor-0.8.0.4/debian/changelog ps
ncy=low
+
+ * Correct typo in rules so config.{sub,guess} is actually updated.
+
+ -- Wookey Fri, 23 May 2014 14:25:42 +
+
graphviz (2.26.3-17) unstable; urgency=medium
* QA upload.
diff -Nru graphviz-2.26.3/debian/rules graphviz-2.26.3/debian/rules
--- graphviz-2.26.3/debian/rules 2014-
1 - 100 of 140 matches
Mail list logo
