On 2016-11-17 03:58 +1030, Ron wrote:
> On Wed, Nov 16, 2016 at 04:40:59PM +0000, Wookey wrote:
> >
> > I just confirmed that this is still true in testing and unstable
> > for drupal-7.32.1 and drupal-7.50.2.
> > $ gtags
> > input buffer overflow, can't enlarge b
On 2016-11-16 06:02 +1030, Ron wrote:
> On Mon, Nov 14, 2016 at 04:55:06PM +0000, Wookey wrote:
> > On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote:
> > >
> > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and
> > > last time I used it
to drive git-based packaging I'd upload this to the
repo, but I don't (and don't seem to have permissions anyway), so you
can get it here instead (for a while):
http://wookware.org/software/global_6.5.5-1.dsc
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org
and it works fine.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
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, although
On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
> On Tue, 15 Nov 2016 17:22:12 +0000 Wookey <woo...@wookware.org> wrote:
> > Package: dpkg
> > Version: 1.18.10
> > Severity: normal
> >
> > I built a large package (mythtv) with this recipie:
> > git
On 2016-11-16 04:57 +1030, Ron wrote:
> On Mon, Nov 14, 2016 at 06:46:23PM +0000, Wookey wrote:
> > Package: global
> > Version: 5.7.1-2
> > Severity: normal
> >
> > I have a built kernel tree for 3.16.
> >
> > running gtags on it gives a "di
Package: dpkg
Version: 1.18.10
Severity: normal
I built a large package (mythtv) with this recipie:
git clone https://github.com/MythTV/packaging -b fixes/0.28
cd packaging/deb
./build-debs.sh fixes/0.28
This all works fine until the dh_shlibdeps when packing it up at the
end.
which
bian/build/build_arm64_none_arm64/source/debian/build/source_none/' is
ignored.
Warning: symbolic link loop detected.
'debian/build/build_arm64_none_arm64/source/debian/build/build_arm64_none_arm64/source/'
is ignored.
wookey@seattle-wookey:~/debian/linux-3.16.7-ckt9$ global -s enable_dbg
arch/arm64/i
There is half a patch for this here:
https://anonscm.debian.org/git/collab-maint/global.git/commit/?id=a86673861d20d73b53d8c42cd1ef3b988947a97e
It adds the files, but does not include the necessary added dependency.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org
d.
only 2 files generated:
GPATH
GTAGS
global 6.5.4 (upstream release) works on both.
( I also found 844330 in the process, which is just a packaging update issue )
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2016-11-14 14:18 +, Debian Bug Tracking System wrote:
More detail on the reason for the changed requirement is given in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736062
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description
Package: global
Version: 5.7.1-2
Severity: normal
Dear Maintainer,
I installed global on jessie, and got this output:
Setting up global (5.7.1-2) ...
ERROR: global is broken - called emacs-package-install as a new-style add-on,
but has no compat file.
Install global for emacs
Package: firmware-brcm80211
Version: 20160824-1
Severity: normal
The firmware file brcm/brcmfmac43362-sdio.bin is available in the
package, but the driver brcmfmac (at least on cubietruck and maybe
always) does not work unless the file brcmfmac43362-sdio.txt is also
supplied.
See the thread here
Package: abcde
Version: 2.6-2
Severity: wishlist
abcde found the wrong CD in the CDDB database, but then printed the correct
Artist+track info from 'CD-Text':
CD-Text: detected
CD-Extra: not detected
Album title: 'Welcome to the Rock Revolution' [from Motion Device]
Track 1: 'Drama Queen'
Package: abcde
Version: 2.6-2
Severity: minor
On startup abcde prints
Looking at EXTRAVERBOSE ()
which appears to be debug info not normally shown.
You might want to turn that off.
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64
Package: abcde
Version: 2.6-2
Severity: normal
The default CDDB lookup found the wrong CD (a different one with the
same number of tracks). Changing the lookup to muscibrainz (as
recommended by the author :-) made it find the right info.
musicbrainz should probably now be the default.
also the
On 2016-10-20 03:21 +, Debian Bug Tracking System wrote:
Bit more info trying to get it installed (so I can do the work I'm supposed to
be doing!)
sudo fmtutil --sys --no-error-if-no-engine=luajittex --all
results in:
fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/mptopdf.fmt installed.
x
> * install the new packages
> and then tell me what happens?
It still breaks.
I curently have installed:
(unstable-amd64)wookey@kh:~/packages$ dpkg -l | grep texlive
ii texlive-base 2016.20160819-2 all
TeX Live: Essential programs and
with, but asking the TC to rule seems like a
more correct way to try and unbung this situation.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2016-09-25 13:47 +0100, Wookey wrote:
> On 2016-09-22 17:03 +, Debian Bug Tracking System wrote:
>
> I fixed the doc-building, but then I realised that things weren't
> going to multiarch paths. Still working on that (pkgconfig now goes in
> the right place, but
r it will ideally become obsolete, but I don't think
we are there yet. It is true that Helmut has spend a lot more time on
this recently than I have.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@debian.org>
Package name: mali-driver
Version : 0.1
Upstream Author : ARM Limited
URL :
http://malideveloper.arm.com/develop-for-mali/features/mali-t6xx-gpu-use
r-space-drivers/
License
ed to use CGAL instead of Triangle.
Maenwhile there have been a could of new releases, so I will update to
latest, include the above and hopefully upload if no new problems are
found.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
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
worked that out, I think we are good to
upload.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2016-09-24 14:14 +0200, Bálint Réczey wrote:
> Control: tags -1 upstream fixed-upstream pending
> Control: notfound -1 17.0~alpha3+dfsg1-1
>
> Hi Wookey,
>
> 2016-09-17 2:26 GMT+02:00 Wookey <woo...@debian.org>:
> > The changes have also been sent upst
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@debian.org>
Package name: dxtool
Version : 0.1
Upstream Author : Mateusz Golicz <mateusz.gol...@pza.org.pl>
URL : http://jaskinie.jaszczur.org/index_en.html
License : LGPL2.1
Program
On 2016-09-22 23:42 +0800, 殷啟聰 wrote:
> Hi Wookey,
>
> Thanks for your bug report!
>
> I have spotted the issue and fixed it in VCS. Please see:
> <https://anonscm.debian.org/cgit/android-tools/android-platform-system-core.git/commit/?id=6a17508>.
>
> libunwind
On 2016-09-15 14:46 +0200, Iztok Jeras wrote:
> Hi wookey,
>
> I tried to install this library on my Xilinx Zynq ARM board with Ubuntu
> 16.04.01. I noticed make install was missing. I searched bug reports and pull
> requests for some help and found a patch. I updated
this is useful.
There is still a bootstrapping issue with the self-dependency on
android-platform-system-core-headers
not sure if there is any build magic to generate those, or build without them?
--
Wookey
diff -Nru android-platform-system-core-6.0.1+r55/debian/adb.manpages android-platform-system-core
three cases? Or
is there some good reason for this rather confusing behaviour?
If 'build-dep' is spelled correctly then all 3 flavours work as expected.
--
Wookey
is using, because that
contained an incorrect <=16 test.
In the current 1.13 the <=16 test has been corrected to <16 so the
overflow no longer occurs. This is the correct fix, so this version
should work fine if used by ntt.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://woo
On 2016-09-03 11:30 +0800, Paul Wise wrote:
> On Fri, 2016-09-02 at 12:56 +0100, Wookey wrote:
libsquish is now uploaded https://tracker.debian.org/pkg/libsquish
> > Then I'll upload and file bugs against all these packages about the
> > option to use a system library.
>
&g
On 2016-09-17 00:51 +, Debian Bug Tracking System wrote:
sorry, cut'n'paste error in original report:
The embedded squish library in in fact in:
libraries/source/nvtt/src/src/nvtt/squish/
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
On 2016-09-17 00:45 +, Debian Bug Tracking System wrote:
Sorry, cut'n'paste error in original report.
The path of the embedded squish library is in fact: rts/lib/squish
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital
On 2016-09-17 00:42 +, Debian Bug Tracking System wrote:
Sorry, the path for the embedded library is in fact:
src/dds.imageio/squish
(cut'n'paste error in original message)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital
i1.10+ (1.10+metric/BC45)
(tools/depends/native/libsquish-native)
- mame1.13+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
1.13+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
1.10+ (1.10+metric/BC45) (lib/libsquish)
- kodi1.10+ (1.10+metric/BC45)
(tools/depends/native/libsquish-native)
- mame1.13+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
/BC45) (lib/libsquish)
- kodi1.10+ (1.10+metric/BC45)
(tools/depends/native/libsquish-native)
- mame1.13+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
)
- mame1.13+ (BC45) (3rdparty/bgfx/3rdparty/libsquish)
Hope this is useful.
Wookey
an.org>.
>
> Please retitle bug 837078 from RFP to ITP and set yourself as the owner.
Ah. well spotted. I checked the ITP list, but not the RFP list, for this
package.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@debian.org>
Package name: ne10
Version : 1.2.1
Upstream Author : ARM Limited and Contributors
URL : http://projectne10.github.io/Ne10/doc/index.html
License : BSD
Programming Lang: C, ass
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@debian.org>
Package name: dewalls
Version : 1.0.0
Upstream Author : Andy Edwards
URL : https://github.com/jedwards1211/dewalls
License : MIT
Programming Lang: C++
Description :
On 2016-09-01 12:21 +0800, Paul Wise wrote:
> On Thu, 2016-09-01 at 04:12 +0100, Wookey wrote:
>
> > I'll look into those and see if they have diverged from upstream
> > significantly.
OK. summary:
- nvidia-texture-tools 1.7 (src/nvtt/squish)
- 0ad 1.7
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
Package name: cavewhere
Version : 0~20160817
Upstream Author : Philip Schuchardt <vpica...@gmail.com>
URL : http://www.cavewhere.com/
License : GPL3
Programming Lang: C++
On 2016-09-01 10:43 +0800, Paul Wise wrote:
> On Thu, Sep 1, 2016 at 9:18 AM, Wookey wrote:
>
> > This package is a build-dependency of Cavewhere
>
> FYI, there are also a number of copies of it already in the archive:
>
> https://anonscm.debian.org/viewvc/secure-te
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
Package name: libsquish
Version : 1.13
Upstream Author : Simon Brown, Stefan Röttger
URL : https://sourceforge.net/projects/libsquish
License : MIT
Programming Lang: C++
Descr
On 2016-08-27 10:19 +0200, Tobias Frost wrote:
> Hi Wookey,
>
> reopening, as Jörg Sommer has not been really removed from d/control:
>
> https://tracker.debian.org/media/packages/j/jed-extra/control-2.5.7-1
Doh! Thanks for noting my high enthusiasm to competence ratio :-)
New
ium
+
+ * Non-maintainer upload.
+ * Use dh_autotools_dev instead of dh_autoreconf
+as autoreconf needs a major autofoo update
+
+ -- Wookey <woo...@debian.org> Thu, 04 Aug 2016 23:29:53 +
+
most (5.0.0a-2.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru most-5.0.0a/de
until today.
Now we just have to work out what to do about them (other then 'don't
use systemd, it's too bloody clever by half).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Package: src:schroot
Followup-For: Bug #816326
I can confirm that Raphael's patch fixes this issue for me too (not
very surprisingly).
Wookey
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
* Package name: javolution
Version : 6.0.0
Upstream Author : Javolution (http://javolution.org/)
* URL : http://javolution.org/
* License : BSD (2-clause)
Programming Lang: J
On 2016-07-28 20:28 +0200, Sven Joachim wrote:
> On 2016-07-28 17:45 +0100, Wookey wrote:
>
> > On 2016-07-28 15:19 +0200, Sven Joachim wrote:
> >>
> >> They should not be used at all, but Mr. Davis has these special broken
> >> tests for them. :-( And
On 2016-07-28 15:19 +0200, Sven Joachim wrote:
> Control: found -1 1:0.99.19-6
>
> On 2016-07-25 18:21 +0100, Wookey wrote:
>
> > On 2016-07-25 18:45 +0200, Sven Joachim wrote:
> >>
> >> I have tried the attached patch, but unfortunately the build broke
On 2016-07-27 13:57 +0900, Norbert Preining wrote:
> Hi Wookey,
>
> thanks for your report. THere seems something fishy, and
> I can even immagine that there is a problem in the paper
> handling, but somehow all this looks strange.
>
> Firt of all, can you please send
for
it?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: tex-common
Version: 6.05
Severity: normal
Dear Maintainer,
I installed hevea in an unstable chroot. That brought in tex-comon
amongst other things. The install failed, producing a fmtutil temp log
file:
Building format(s) --all.
This may take some time...
fmtutil failed. Output has
not really necessary although the comments say
> otherwise.
This may be because I changed to debhelper 9 mode, which IIRC sets this
variable automatically anyway, so this bit in the rules file is
probably pointless.
It's always hard to know when to remove stuff that is/maybe no longer
needed, wi
sy when I got round to it, as the only 'non-patch' dpatch patch was
doing config.{sub,guess} updates, and I know how to do that properly
using other mechanisms (modulo failing to actually get it right on
first attempt :-)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
r 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
. If the
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
5.0.0a-2.2 NMU
+
+ -- Wookey <woo...@debian.org> 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 +0100
+++ most-
just the uboot
with lower-level tools, and automating the setting of the uboot runes
as much as possible.
I guess we can call this bug closed, as it's not the kernel that's at fault.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
nel 4.5, but not 4.6? The userspace
should be the same, although I presume we are still in the initrd at
this point, and those could differ in some important way?
Clues welcome.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digi
Package: linux-image-4.6.0-1-armmp-lpae
Version: 4.6.1-1
Severity: normal
I installed an nvidia jetson board (armhf, v7) with the stretch alpha6
installer. It all worked nicely.
See documentation at:
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1
On upgrading the kernel to
Package: gnu-fdisk
Version: 1.2.4-3.1
Severity: wishlist
Dear Maintainer,
If you foolishly type "cfdisk /dev/sdc1" when you really meant "cfdisk
/dev/sdc", the tool will happily show a normal-looking partition table
and let you change the type (e.g. from DOS (06) to ext2 (83), and then
will save
Package: devscripts
Version: 2.16.4
Severity: normal
File: /usr/bin/uscan
The watch file in couchdb is like this:
debian/watch
version=3
http://couchdb.apache.org/ \
(?:.*/|.*=|)apache-couchdb[\-\._](\d\S*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)(?:/\S*)?
Testing in a fresh, clean, unstable
Package: dpkg
Version: 1.18.7
Severity: wishlist
There is a new ABI for arm64 which is the equivalent of x32 on amd64.
It uses the armv8 instruction set for a 32-bit ABI (32-bit
instructions, longs and pointers). Generally referred-to is 'ILP32' in
comparison to the 'LP64' standard arm64 ABI.
, luajit should at
least run on ARM64, and be consistent with upstream on their next release.
I guess I should test this.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
to close it.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
* Package name: esp-r
Version : 12.3
Upstream Author : Energy Systems Research Unit, University of Strathcycle
* URL : http://www.esru.strath.ac.uk/Programs/ESP-r_central.htm
* License
, and/or uploading a 1.59 which would make this issue go away,
at least for arm64. Is there anything we can do to help? (I guess a
report saying that the patch was tested working on arm64 would be
helpful).
I see that the last upload migrated to testing only at the weekend, so
I guess you were wai
+++ Mattia Rizzolo [2016-03-27 12:39 +]:
> On Sun, Mar 27, 2016 at 12:21:33PM +0100, Wookey wrote:
> > +++ Christopher Baines [2016-03-27 10:49 +0100]:
> > > On 20/03/16 03:12, Mattia Rizzolo wrote:
> > > A possible alternative would be to include a
thus best avoided if
possible. Adding support for a 'nodocs' profile to skip its use is one
way to (mostly) deal with that.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: multistrap
Version: 2.2.1
Severity: normal
Creating an arm64 foreign chroot with the attached config file (on an
amd64 machine) results in a file /etc/dpkg/dpkg.cfg.d/multiarch being created,
containing:
foreign-architecture armhf
This is fatal to the operation of the dpkg 1.17.26 also
+++ Debian Bug Tracking System [2016-03-22 19:12 +]:
The linaro page is now accessible at:
https://collaborate.linaro.org/display/TCWGPUB/The+State+of+LuaJit+for+ARM+64+-+March+2016
(thanks to Ryan Arnold for fixing that)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http
so people outside Linaro
can't read it. (Yay for open development Linaro!)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
ile this upstream too, referring back here.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Description: Change VM pointer size limit to 48bits for aarch64
Aarch64 (arm64) has a 48bit address space, whereas x86_64 has a 47bit address space
Luajit checks that pointers
+++ Wookey [2016-03-18 18:42 +]:
A bit more detail from the gdb session:
(gdb) bt full
#0 getcurrenv (L=0xb7d80378, L=0xb7d80378) at lj_api.c:76
fn = 0x7fffb7d80378
#1 cpcall (L=0xb7d80378, func=0x404c08 , ud=0x0) at lj_api.c:1062
fn = 0x7fffb7d80378
top
kages are redundant (and unbuildable) once
gcc-4.9 is no longer in the archive, so should go away.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Source: luajit
Version: 2.1.0~beta2+dfsg-1
Severity: important
Dear Maintainer,
Yay - luajit with arm64 support uploaded!
However, whilst it builds, it doesn't appear to work at all.
Running it gives an immediate segfault
I installed the debug version (thank you debian for automatic dbgsym
Package: tex-common
Version: 6.04
Severity: normal
On installing tex (in fact apt-get build-dep rustc) in a fresh unstable
chroot I get this failure (on both amd64 and arm64 machines):
--
Processing triggers for tex-common (6.04) ...
debconf: unable to initialize frontend:
p that makes it possible to get a dbus message failure?
>
> At least in my case, I usually run wicd-curses only if I need it and
> don't have it running all the time.
Good point - I guess most people use wicd-gtk, which doesn't have this issue.
Wookey
--
Principal hats: Linaro, Debian,
+++ Axel Beckert [2016-03-11 11:52 +0100]:
> Hi Wookey,
>
> Wookey wrote:
> > Issue still present in v 1.7.2.4-4.1
> > (rebuilt from testing/unstable source on jessie)
>
> Are you sure about that version number? Testing/Unstable currently has
> 1.7.4+tb2-1. 1.7.2.
uses include: the remote application did not send a
reply, the message bus security policy blocked the reply, the reply timeout
expired, or the network connection was broken.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Package: pybit-client
Version: 1.0.0-2.1
Severity: important
I installed and set up pybit.
But trying to use /usr/share/pybitclient/buildd-test.py just gave
'ImportError: No module named subversion'
I thought this was about missing python-subversion, but no, it turned
out to be that all the
date-path-of-libjvm-and-arch-name.diff to patch
configure.ac instead of generated configure
And it still doesn't build because prtty-printer is not having the all
the boost libraries needed by opernvrml expanded onto the build line
for some reason.
Wookey
--
Principal hats: Linaro, Debian, Wook
+++ 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, Deb
+++ 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 direct
> involve
Package: meshlab
Version: 1.3.2+dfsg1-2+b1
Severity: normal
The help menu has an 'online documentation', as is sadly common these
days (rather than having to docs actually on the machine you are on). Selecting
this now produces:
An error has been encountered in accessing this page.
, 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 hats: Linaro, Debian, Wookware, ARM
http
relien - can we help move this along?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
+++ Andreas Tille [2016-01-28 20:58 +0100]:
> Hi Wookey,
>
> since you are just maintaining several packages in Debian Science I
> assume you will do so with this package as well. I'm just forwarding
> the ITP to the list.
Yes. It doesn't seem to change very often, so shouldn't
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
* Package name: jscience
Version : 4.3.1
Upstream Author : 2007 JScience (http://jscience.org/)
* URL : http://jscience.org/
* License : JScience
Programming Lang: Java
Descr
Package: wnpp
Severity: wishlist
Owner: Wookey <woo...@wookware.org>
* Package name: geoapi
Version : 3.0.0
Upstream Author : 2003-2011 Open Geospatial Consortium, Inc.
* URL : http://www.geoapi.org
* License : geoapi (BSDish)
Programming Lang
Control: tags 759445 + pending
Dear maintainer,
I've prepared an NMU for unmass (versioned as 0.9-3.1) and uploaded it
to DELAYED/07. This fixes the bugs filed in 2014 to let it build on
newer architectures. Diff attached.
Regards.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http
Source: sbuild
Severity: wishlist
I always want to do an sbuild build of a package in a clean chroot
before uploading. These days it is best practice to do sourceful
uploads, so having a way to get a foo_version_source.changes at the
end of the build instead of (or as well as) a
301 - 400 of 1341 matches
Mail list logo
