hat it's not gone
away now that you are in fact setting the right one? It should do (and
just did in my quick test). But I guess if the arch is set first, and
CC later (as is probably normal in most rules files driven by
dpkg-buildpackage -a) then you will always see this warning,
On 2018-04-07 12:06 +, Debian Bug Tracking System wrote:
libopencsd is now in the NEW queue. I'm not sure if you'll get a
noticfication when the ITP bug closure unblocks this one so I'll
comment again here when that happens.
Wookey
--
Principal hats: Linaro, Debian, Woo
0 +
+++ linux-4.16~rc6/debian/changelog 2018-04-06 21:12:15.0 +
@@ -1,3 +1,10 @@
+linux (4.16~rc6-1~exp2) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * add build-dep on libopencsd for perf on arm
+
+ -- Wookey Fri, 06 Apr 2018 22:12:15 +0100
+
linux (
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
of a good tool for munging the set of
pages to remove all those links and pages to make some thing which is
just the core, then I may have a go to see if it can be got down to a
more sensible size.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
> }
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
o/conbuilder
> * License : GPLv3
> Programming Lang: Python
> Description : container-basade package builder for Debian packages
'Container-based' ?
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
But these should be useful for initial testing/feedback.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Wookey
* Package name: libopencsd
Version : 0.8.0
Upstream Author : ARM Limited (maintained by Mike Leach
)
* URL : https://github.com/Linaro/OpenCSD
* License : BSD-3
Programming Lang: C++
Description : ARM
the moment).
Progress can also be tracked at the uptream github issue:
https://github.com/carrotIndustries/horizon/issues/122
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
r bad (self-dependency at the same version is much more of a
problem than self-dependency at older versions).
Anyway, Pirate - I suggest you ask about this on debian-devel where we
can have a pulic discussion about policy and whether there is anything
special about this case which makes it not su
Package: ocaml-native-compilers
Version: 4.05.0-10
Severity: important
Tags: upstream
When building hhvm 3.21.0+dfsg-2 on arm64, the build fails with an
error compiling ocaml:
[ 47%] Built target ocaml
Finished, 28 targets (28 cached) in 00:00:00.
+ /usr/bin/ocamlopt.opt -c -g -w A -w -3-4-6-29-3
Package: hhvm
Version: 3.21.0+dfsg-2
Severity: wishlist
Arm64 support was added to hiphopvm in version 2.1 so this package
should now be built for arm64 as well as amd64.
However I tried this in order to send you a patch, which should just be:
--- debian/control.orig 2018-02-13 15:48:36.397440719
Package: wnpp
Severity: wishlist
Owner: Wookey
* Package name: horizon-eda
Version : 0.2018-02
Upstream Author : Lukas Kramer
* URL : https://github.com/carrotIndustries/horizon
* License : GPL-3
Programming Lang: C++
Description : EDA layout and
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
ething like this is that it
lets you upstream patches (which change dependencies) in a reasonably
clean way.
Clearly a downstream distro can instead maintain patches, but we
encourage upstreaming in general and this mechanism allows that.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
his is abuse of that mechanism. An architecture is an ABI and life is
complicated enough without adding baggage to that concept.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2017-12-15 16:20 +, Wookey wrote:
> On 2017-12-15 11:06 -0500, Aaron M. Ucko wrote:
> > The failed builds were all against qbs 1.6.x or older, whereas 1.8.x
> > (1.8.1+dfsg-4) is current. Please version the build dependency
> > accordingly, bearing in mind that dewall
s features/stop using deprecated ones in the process of
getting it working on linux. That's probably not helpful on these
arches. But this is such a niche package I'm not sure there is much
point doing any more work than versioning the dependency correctly. I
guess they'll catch up eventually.
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
hich
makes quilt format 3 'unable to represent binary changes in tarball'.
I have to manually delete this (or include a pointless
runtime-generated 110K binary). It's not clear what the right way to
deal with this is.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookwa
On 2017-11-05 17:40 +0100, Helmut Grohne wrote:
> Package: cross-gcc-dev
> Version: 154
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> Hi Dima and Wookey,
>
> gcc-8/0008-g-include-directories-functional-again.patch has two hunks.
> The first of
ther instances of package libsquish-dev:armel
Hmm. this is interesting.
The first 3 arches I tried were all the same, but it seems we do have 2
flavours of the file:
$ ls -l graph_legend*
-rw-r--r-- 1 wookey wookey 20695 Aug 6 21:05 graph_legend_amd64.png
-rw-r--r-- 1 wookey wookey 20695 Aug 6 21:05 gra
On 2017-01-27 03:42 +, Wookey wrote:
> On 2017-01-26 12:40 +, Toby Speight wrote:
> > Package: tunnelx
> > Version: 20160713-3
> >
> > Characters outside US-ASCII get corrupted when saving and loading
> > tunnel sketches.
> Cheers for that. You miss
ould not find or load main class
> footleg.cavesurvey.cmdline.CaveConverter
> \
Hmm, you are right.
It seems that the file moved so the manifest is out of date.
It should now be looking for footleg.cavesurvey.converter.CaveConverter.
And clearly my testing sucks ;-/
Thanks for the bug report. Ne
Package: coreutils
Version: 8.26-3
Severity: normal
Tags: upstream patch
If you crossbuild coreutils (after fixing the manpages issue covered in #721358)
it fails with:
Recursive variable 'INSTALL' references itself (eventually).$
in context:
make[4]: Leaving directory '/tmp/bu
Package: coreutils
Version: 8.26-3
Followup-For: Bug #721358
I hit this problem cross-building coreutils.
I didn't find this bug report till now, and it seems that the 'use
native binaries' solution is not particularly favoured. Although in
the debian case it works well because you are normally c
as I have them working.
Wouldn't it make sense to leave this bug open for anyone that needs to
fix this for use on stable? I guess it's linked from the arm64ilp32
port page so the fairly small number of people that care can probably
find it even if closed.
Wookey
--
Principal hats:
> 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
On 2017-07-28 20:35 +0200, Cyril Brulebois wrote:
> Wookey (2017-07-28):
> > OK. I'll go ahead with a 9u1 update then.
>
> You're supposed to wait for a green light (usually materialized by a
> +confirmed rather than with a +moreinfo)…
Cyril, Can I get an OK to uplo
On 2017-09-16 15:36 +0300, Niko Tyni wrote:
> On Sat, Sep 16, 2017 at 10:48:42AM +0100, Wookey wrote:
> > On 2017-09-16 10:43 +0300, Niko Tyni wrote:
>
> > > (I can still include them in sid, but they aren't going to be functional
> > > there as-is...)
> >
On 2017-09-16 10:43 +0300, Niko Tyni wrote:
> On Sat, Sep 16, 2017 at 01:23:40AM +0100, Wookey wrote:
> > Package: perl
> > Version: 5.24.1-3+deb9u1
> > Severity: normal
> > Tags: patch
> >
> > Attached are the config.sh.static and patches for the other
On 2017-09-16 11:16 +0300, Niko Tyni wrote:
> On Sat, Sep 16, 2017 at 01:06:48AM +0100, Wookey wrote:
> > Package: perl
> > Version: 5.24.1-3+deb9u1
> > Severity: normal
> > Tags: upstream patch
>
> > There is no obvious variable in the config file to set up th
tracked at: https://wiki.debian.org/Arm64ilp32Port
Wookey
diff -urN perl-5.24.1.orig/debian/cross/arm64ilp32/config.sh.debug.patch perl-5.24.1/debian/cross/arm64ilp32/config.sh.debug.patch
--- perl-5.24.1.orig/debian/cross/arm64ilp32/config.sh.debug.patch 1970-01-01 01:00:00.0 +0100
ate this by moving all the
headers in libc6-dev from /usr/include to /usr/include/$DEB_HOST_MULTIARCH
Patch supplied as simple patch and dpkg 3.0 (quilt) format fix.
Wookey
diff -urN perl-5.24.1.orig/ext/Errno/Errno_pm.PL perl-5.24.1/ext/Errno/Errno_pm.PL
--- perl-5.24.1.orig/ext/Errno/Errno
On 2017-09-09 17:00 +0100, Alessandro Ghedini wrote:
> On Sat, Sep 09, 2017 at 04:11:59PM +0100, Wookey wrote:
> > Package: curl
> > Version: 7.52.1-5
> > Severity: normal
> > Tags: patch
> >
> > curl needs dh-exec to build, because curl.install is
> >
Package: curl
Version: 7.52.1-5
Severity: normal
Tags: patch
curl needs dh-exec to build, because curl.install is
#!/usr/bin/dh-exec
usr/bin/curl
usr/share/zsh/*
But this build-dependency is not declared.
Presumably dh-exec is normally present or pulled in by something else
so it's not normally
Package: openssl1.0
Version: 1.0.2l-2
Severity: normal
Tags: patch
This patch allows openssl1.0 to build on the new arm64ilp32
architecture. It's pretty straightforward, and turns off the arm64
acceleration as that would need more work to port.
The port status is tracked at: https://wiki.debian.
o be too cleaver and access struct members
directly.
I tried this on two architectures and both fail the same way.
Wookey
or adding support to the debian
packaging so that once upstream supports this it can be built.
To actually build a glibc for arm64ilp32 you also need the 250K glibc
patch which I won't include here, and a couple of fixes. These three commits
show what's needed:
https://anonsc
On 2017-09-07 16:01 +0100, Ben Hutchings wrote:
> On Thu, 2017-09-07 at 15:01 +0100, Wookey wrote:
> > OK, but we need the kernel-headers package in order build the
> > toolchain, so at least that needs to be built (which is in fact all I
> > have done/tested so far).
>
&
6 +117,7 @@
pr77857 \
pr80533 \
pr60818 \
+arm64-ilp32-default \
ifeq ($(libstdcxx_abi),new)
debian_patches += libstdc++-functexcept
>From 7a35625da966a0aa0733843fee7d100e2f026808 Mon Sep 17 00:00:00 2001
From: Wookey
Date: Mon, 8 May 2017 01:58:54 +0100
Subject: [P
OK, but we need the kernel-headers package in order build the
toolchain, so at least that needs to be built (which is in fact all I
have done/tested so far).
I agree that the arm64 kernel will work for both. But will
dependencies work for automatically bringing that in?
Wookey
--
Principal hats: Linar
s in
debian:
https://anonscm.debian.org/cgit/users/wookey/rebootstrap.git/commit/?h=ilp32-stable&id=01fe063bff353cba63b2048ff803f41314b888a5
Status for the port (in Debian) is tracked here:
https://wiki.debian.org/Arm64ilp32Port
commit e12a78fddd7bdf77768b94645cd8ae0d8e5f2070
Author: Wookey
Date: Tue A
On 2017-09-04 14:09 +0200, Alex Mestiashvili wrote:
> On 09/04/2017 12:00 PM, Wookey wrote:
> > On 2017-09-04 10:06 +0200, Andreas Tille wrote:
> >> Hi Edmund,
> >>
> >> On Thu, Aug 31, 2017 at 07:37:38PM +0100, Edmund Grimley Evans wrote:
> >>>
no I don't think you should just close this. In fact I still can't
see any reason not to let this build on arm64, (and ppc64el and s390x,
and ppc64 and sparc64, all of which have bowtie already built). So in
fact I think you should just remove the arch restriction.
Wookey
e expanded to other hardware over time, and the binary
drivers uploaded too fairly soon.
Thanks very much to Guillaume Tucker who did nearly all the
heavy-lifting for this.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
n/patches/arm64ilp32-unaccelerated.patch 2017-08-17 13:05:35.367653710 +
@@ -0,0 +1,24 @@
+Description: Disable asm for aarch64 ILP32
+ The aarch64 sha acceleration assembler does not support ILP32 ABI yet,
+ so disable it when building for ILP32
+Bug:
+Bug-Debian: https://bugs.debian.org/
+Forwarded: no
Source: libgc
Version: 7.4.2-8
Severity: normal
Tags: patch upstream
arm64ilp32 is a new arm64 ABI currently being bootstrapped. libgc
needs symbols updates and a config update.
Attached is a patch to add the config.
And another for the symbols update.
The symbols update can also easily done wit
t: systemd (via /run/systemd/system)
Description: Add arm64 ILP32 support to nspr config
nspr (2:4.12-6) unstable; urgency=medium
Author: Wookey
Last-Update: 2017-08-11
--- nspr-4.12.orig/nspr/pr/include/md/_linux.cfg
+++ nspr-4.12/nspr/pr/include/md/_linux.cfg
@@ -659,6 +659,51 @@
#else
#er
package.
https://tracker.debian.org/pkg/libsquish
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2017-07-28 20:35 +0200, Cyril Brulebois wrote:
> Wookey (2017-07-28):
> > OK. I'll go ahead with a 9u1 update then.
>
> You're supposed to wait for a green light (usually materialized by a
> +confirmed rather than with a +moreinfo)…
OK then. I'll wait for a
On 2017-07-28 19:30 +0200, Cyril Brulebois wrote:
> Wookey (2017-07-28):
> > On 2017-07-01 05:54 +0200, Cyril Brulebois wrote:
> >
> > OK, so it seems 9.1 got released so I guess I'm targetting 9.2 now.
>
> Well, you replied on the 22nd, which is also the date
On 2017-07-01 05:54 +0200, Cyril Brulebois wrote:
OK, so it seems 9.1 got released so I guess I'm targetting 9.2 now.
Should I do an upload with the previous patch just set for 9u2. i.e. version
113+deb9u2?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookwar
Package: dose-builddebcheck
Version: 5.0.1-8
Severity: minor
A minor nit.
I got this error message due to giving dose-builddebcheck a duff filename:
Fatal error in module common/input.ml:
Input file /var/lib/apt/lists/*_main_binary-amd64_Packages does not exists.
dose-builddebcheck failed with
ing arm64 assembly with minor prolog/epilog changes,
+ but that requires deeper understanding of the codebase.
+ .
+Author: Wookey
+Last-Update: 2017-07-25
+
+--- gmp-6.1.2+dfsg.orig/configure.ac
gmp-6.1.2+dfsg/configure.ac
+@@ -592,16 +592,19 @@ case $host in
+
+
+ arm*-*-* | aarch64*-*
l chime in with more
details of an actual implementation and you can tell us if there is
some reason why that won't work.
Wookey
-07-24 17:26:52.0 +0100
@@ -1,3 +1,9 @@
+libgpg-error (1.26-2.1) unstable; urgency=medium
+
+ * Add aarch64 ILP32 support
+
+ -- Wookey Mon, 24 Jul 2017 17:26:52 +0100
+
libgpg-error (1.26-2) unstable; urgency=medium
* bump symbols version for gpgrt_yield to 1.25
diff -Nru libgpg-
was that porters would provide info for their
architectures, and thus get the details right. We could probably find
out the answers for various arches with some effort. If you provide
files I am happy to include them. I guess I could check by logging on
to porter boxes and collecting suitable details.
On 2017-07-21 17:57 -0700, Dima Kogan wrote:
> Wookey writes:
>
>
> It looks like gcc-5 and gcc-7 are not in stable, so we only care about
> gcc-6. Yes?
Yes, only gcc-6 is relevant. Cheers for checking. I've done an updated
patch in 866537. We'll see if that meets
On 2017-07-01 05:54 +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
[sorry for slow response - missed this message]
> Wookey (2017-06-30):
> > cross-gcc-dev has to be in very close sync with the version of gcc in
> > order for it's patches to apply. The cros
On 2017-07-21 12:47 -0700, Dima Kogan wrote:
> Wookey writes:
>
> > Package: cross-gcc-dev
> > Version: 113
> > Severity: important
> > Tags: patch
> >
> > The cross-gcc-dev that made it into the stable release (113) was
> > prepared against gcc-
ription: Ensure that clean actually cleans
+ configure.lineno was not getting tidied up
+Author: Wookey
+
+Last-Update: 2017-07-05
+
+--- attr-2.4.47.orig/Makefile
attr-2.4.47/Makefile
+@@ -25,7 +25,7 @@ endif
+
+ CONFIGURE = \
+ aclocal.m4 \
+- configure config.guess config.sub \
++ conf
Source: libatomic-ops
Version: 7.4.4-3
Severity: wishlist
Tags: upstream patch
libatomic-ops FTBFS on arm64ilp32 arch. This trival patch fixes that.
It might be better to refactor the code to check for ILP32 on all
64-bit arches that support it rather than this per-arch fix, but I
don't know enou
Package: openssl
Version: 1.1.0f-3
Severity: wishlist
Tags: patch
This package FTBFS on arm64ilp32. The package has upstream support
already. It just needs the correct debian target conf information adding.
"debian-arm64ilp32" => {
inherit_from => [ "linux-arm64ilp32", "debian"
tches for gcc 6.3.0-18 in stable
+
+ -- Wookey Thu, 22 Jun 2017 01:44:00 +
+
cross-gcc (113) unstable; urgency=medium
* rebuild for 6.3.0-2
diff -Nru cross-gcc-113/patches/gcc-6/0010-gcc-.-base-dependencies-reverted-to-gcc-VER-base-whe.patch cross-gcc-113+deb9u1/patches/gcc-6/0010-gcc-.
Package: cross-gcc-dev
Version: 113
Severity: important
Tags: patch
The cross-gcc-dev that made it into the stable release (113) was
prepared against gcc-6 6.3.0-2, whereas the version of gcc that ended
up released was 6.3.0-18, and one patch does not apply, rendering the
package largely useless.
;
>
> Experimental:
>
> nmu wine-development_2.8-1 . arm64 . experimental . -m "Rebuild with fixed
> binutils"
> nmu wine-2.0.1-1 . arm64 . experimental . -m "Rebuild with fixed binutils"
OK. All scheduled. (couple of version typos sorted)
> I'm *guessing* all the Haskell packages might involve triggering more
> rebuild of all the rdeps too, not sure...
Hopefully someone with haskell clue will advise here...
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: src:efl
Followup-For: Bug #858563
You can use dpkg-buildpackage -nc -T to call debian/rules,
but still have the advantages of dpkg-buildpackage setting up the
environment. So the debian/rules specific-rule-running feature is
still available along with a 'use dpkg-buildpackage' stipulation
You can used dpkg-buildpackage -nc -T to call debian/rules, but still
have the advantages of dpkg-buildpackage setting up the environment. So the
debian/rules specific-rule-running feature is still available along with a 'use
dpkg-buildpackage' stipulation.
(I assume it still sets up the correc
there are in the python-bluez package).
Hope this is useful. I don't claim any real python packaging
expertise, but I did read the python policy and wiki pages, so I think
it's up to date with current idiom.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.
Oh dear. This means that python-bluez does not support python3 in
Stretch, even though that support was added in v0.20 (released Jan 2014).
That's quite bad. But apparently no-one noticed in time to fix it for
Stretch. I'm looking to see how easy the update to the real 0.22 i
hanks for your assistance with this.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -ur dpkg-1.18.23.ilp32/data/abitable dpkg-1.18.23/data/abitable
--- dpkg-1.18.23.ilp32/data/abitable 2017-03-10 01:25:46.966846921 +
+++ dpkg-1.18.23/data/abitable 2017-02-22
th a snapshot of that documentation
> (if the licensing permits)?
Yes. That would probably be a good idea. I used to package the therion
wiki in a -doc package. I'll leave this bug open as a wishlist reminder.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
t; that.
bugs - with patches - lovely!
Cheers for that. You missed debian stable deadline by about 1 day, and
debian is frozen for the time being, so I won't do an upload right
now, but will forward to Julian.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
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,
Source: dput-ng
Version: 1.8
Severity: normal
Dear Maintainer,
I tried to use dcut dm to give my co-maintainer (Punit Agrawal) upload
permissions. It didn't go well.
this page:
https://wiki.debian.org/DebianMaintainer#Granting_Permissions
says comands of this format should work:
dcut dm --uid 0x
id you list all the arches specificaly and not just put 'any'?
Or if there are one or two arches to exclude, use the !arch syntax to
exclude those. Listing all arches specifically means that every time
an arch comes or goes tha package has to be fixed to stay in sync, so
it is not robust in
Package: ftp.debian.org
Severity: normal
Binutils now builds lots of cross- binutils packages, and can be made
to build others (using binutils source). So the cross-binutils package
is now superfluous.
is is supposed to work.
All I really want to know is 'what is the rune to get 1804772E.txt
into the right format to to go in /etc/apt/trusted.gpg.d', and 'what
should it be called?'
I guess I can work this out by trial and error, but it would be good
to be sure I was doi
Package: global
Version: 6.5.5-1
Severity: normal
Saving this as a bug to avoid it getting forgotten.
Wookey noted:
global fails to build on hurd:
https://buildd.debian.org/status/fetch.php?pkg=global&arch=hurd-i386&ver=6.5.5-1&stamp=1481673154
Punit replied:
This one has interestin
On 2016-12-14 10:50 +0100, Ansgar Burchardt wrote:
> Control: reopen -1
> Control: found -1 2.1
>
> On Wed, 2016-12-14 at 03:40 +, Wookey wrote:
> > close 796548 2.0.4
>
> emdebian-archive-keyring 2.1 still has "Priority: important" in
> d/control. (No
rs. Warm potato accepted :-)
> Wookey: if you want the complete git history, right back to the very first
> package in 1999, you can grab it from the Vcs-Git URL in the sid package.
> I'm not going to go Full Bruce and rage delete it, but eventually I should
> decruft alioth and re
should arrive in 3 days time.
Here's the changelog.
global (6.5.5-0.3) experimental; urgency=medium
[Wookey]
* Non-maintainer upload.
[ Punit Agrawal ]
* Add missing icons, javascript and images
* Update package repository vcs location
-- Wookey Fri, 09 Dec 2016 00:53:32 +
g
On 2016-12-08 17:03 +0100, Didier 'OdyX' Raboud wrote:
Sorry missed this in all yesterday's mail.
> Wookey, Vincent, Punit: would any of you be willing to receive the 'global'
> package maintainer hat? (which would of course come with the possibility to
> shar
On 2016-12-08 17:33 +, Wookey wrote:
> On 2016-12-08 23:32 +1030, Ron wrote:
> > But it also outputs a .htaccess enabling execution in the directory
> > where the output is generated, whether you want to use it from there
> > or not (and adds a second CGI, and a bunch of
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
On 2016-12-09 11:58 +0900, Shigio YAMAGUCHI wrote:
> Hello all,
> 2016 19:05:55 +, Wookey wrote:
> > The .cgi scripts are generated from .in files which are correctly
> > parameterised with @PERLPATH@ and @GLOBALPATH@ etc. Upstream
> > unhelpfully ships pre-generated
for debian, which
> brings us back to exactly where we are - unless we just remove it all.
> But that would need Time, whoever does it.
I have not grokked why the shoddy code in 5.7.1 is safe but the same
shoddy code in v6 cannot be let out. Did htmake+htconfig stop people
entering $patte
ched patch enables it for all architectures. We can review
failures if they are any once it is uploaded, and perhaps restrict it
to a specific set of arches if need be.
I am happy to NMU this minor fix if the maintainer is busy.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware
201 - 300 of 1349 matches
Mail list logo
