Bug#841294: Overrule maitainer of "global" to package a new upstream version
On 2016-11-16 15:23 +0100, Didier 'OdyX' Raboud wrote: [offlist] > * I'm not happy with delaying the landing of a 6.x version of global for > another release, and despite the somehwat short time before the stretch full > freeze (2017-Feb-05), we're talking about a single binary package without > reverse dependencies. I'm really afraid that a side-effect of the TC > discussion will be yet-another release without an up-to-date src:global. Thank you for some sanity on this matter. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#756367: global chokes/segfaults while parsing drupal 7
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 buffer because scanner uses REJECT > > gtags: command failed in xargs_read(). > > > > And also that if you use the current global 6.5.5 the problem is gone > > and it works fine. > > This looks like it's because the parser scanner was generated with an > ancient version of flex in the distribution tarball and it isn't > regenerated at build time. It's not anything to do with the actual > 'source' in this case, it's hitting a limit of the generated flex > scanner. > > Could you try this again after regenerating that with recent flex? Happy to test if you give me a clue what to type. Which files, what command? I'm not familiar with flex usage, or the global source base. I confirmed that just rebuilding 5.7.1 in testing or unstable does not fix it, but then as you say the offending bit is not regenerated in the normal build (perhaps it should be?). Or you could test it yourself... Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
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, it also worked fine with the emacs integration, so > > > I don't recognise the crying from the rooftops about it being broken in > > > Debian. > > > > It seems that it depends on the kernel source tree in use. > > Just to clarify this here based on the details you provided when you > later reported https://bugs.debian.org/844356, it turns out that it > apparently doesn't depend on the kernel source tree or its version > as such - what you saw happens when the source tree is polluted with > infinite symlink loops, apparently due to a broken build script in > this case. Right. I was going to reply with that bug pointer here. It is an example of something that newer upstream versions cope with without failing. So is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756367 which I have just confirmed is still a bug with 5.7.1, but not with 6.5.5 (There was a request earlier in this thread for actual issues with 5.7.1, that are fixed in newre releases, IIRC) I added a note in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 on that packaging update. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#816924: Updating to 6.5.5
I took the repo at https://anonscm.debian.org/git/collab-maint/global.git/ (Which volker had updated to 6.3.2) And updated to global 6.5.5. The packaging there applied almost as-is. Patch 0001-Debianisation-of-htags.patch is no longer needed (upstream fixed their perl paths) patch 0003-Fix-gtags.el-to-not-use-goto-line.patch needs a refresh. dch, and add the missing emacs dependency on emacsen-common and you are done. This makes no changes to cgi scripts and Ron's htmake patch, which probably should be done, but despite endless verbiage in #841294, I haven't actually actually understood what's wrong with upstream as supplied. Or whether https://anonscm.debian.org/git/collab-maint/global.git/tree/debian/patches/0002-Introduce-htmake-for-global.patch is still OK to use as-is (I assume it needs some adjustment) For my purposes that part is not relevant. If I knew how 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/ signature.asc Description: Digital signature
Bug#756367: global chokes/segfaults while parsing drupal 7
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 buffer because scanner uses REJECT gtags: command failed in xargs_read(). And also that if you use the current global 6.5.5 the problem is gone and it works fine. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink
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 there were a lot of "dpkg-shlibdeps: warning: tried to merge the same object ($library) twice in a symfile" So, yes that patch seems to work (if rather too noisily). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink
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 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 complains about missing dependency info for > > /usr/lib/ld-linux-armhf.so.3 > > This is the same as #843073, so merging. Raphael has proposed a patch > on that bug, but it needs more testing before it is accepted. Right. Cheers for that. (I failed to check the dpkg bugs first because I started filing against glibc and checked that list, then realised part way through that this was best filed against dpkg). How is the usrmerge done? bind-mounting? hardlinks? Is dpkg-shlibdeps the only thing that is going to wrong if files stop having a canonical location in the system? It's a pretty major change having every library (and a load of binaries?) appear twice? (Or do I misunderstand how this is implemented?). Like Guillem, I'd be a lot happier if files, especially libraries, only existed in the place they existed, and if we want to move that then we should move it in the packaging. Isn't there potential for autoconf or libtool to get confused too? Anyway, I'll test raphael's patch. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#844356: gtags chokes on symlink loops
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 "directory stack over flow" error. > > ~/debian/linux-3.16.7-ckt9$ gtags > > gtags: directory stack over flow. > > What are you actually building that source with? I actually inherited this kernel tree (on a machine that needs a patched kernel). But I expect it's built with standard debian kernel-building tools (the chap who did it is not here to ask currently); and the point is really, not how this was achieved, but how global deals with it. > Because this: > > > Warning: symbolic link loop detected. > > 'debian/build/source_none/debian/build/source_none/' is ignored. > Looks like a bug in your build scripts to be creating the symlink loops. > I don't see anything like that in any of my kernel build trees ... Yes, presumably something in the build has done that. > Either way though, if you're actually seriously using this to index > built kernel trees, then I'd recommend you look at the skip option > for gtags configuration, to avoid having it uselessly crawl all over > the build artifacts in the tree in any case, every time you run it > to update the tags. > > And I assume that if you do that, it does index the kernel for you > just fine? Probably, but you were asking for examples/evidence of where there was actually a problem with global that was fixed in newer upstream releases. This was one I came across. > We could look at pulling the newer find code in if that's really a > benefit to someone, Given that I found this in the wild, clearly the code for detecting symlink loops is a benefit, and that could be backported. Obviously source trees shouldn't be doing that, but it will happen sometimes. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#844430: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink
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 complains about missing dependency info for /usr/lib/ld-linux-armhf.so.3 (log below) so the odd thing is that dpkg -S ld-linux-armhf.so.3 shows two files: libc6:armhf: /lib/ld-linux-armhf.so.3 libc6:armhf: /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 but not a copy in /usr/lib (or /usr/lib/arm-linux-gnueabihf). but there is indeed such a copy: $ ls -l /usr/lib/ld-linux-armhf.so.3 lrwxrwxrwx 1 root root 30 Oct 18 22:10 /usr/lib/ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.24.so both copies have the same md5sum. Do we expect libc6 to put 2 copies of this library (and 2 symlinks to it) onto the fs? Or has this come from somewhere else? (This is current install from stretch Debian-installer (Oct 31 2016, with .iso from Oct 31 2016), so shouldn't have any cruft). Obviously the dpkg -S lookup dkpg-shlibdeps does fails for /usr/lib/ld-linux-armhf.so.3 However removing /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 breaks everything. In fact it turns out that there is (hard linking? bind-mounting?) magic involved, so deleting /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 also deleted /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 and thus of course everything broke. i.e it's not 'really' 2 copies at all, just some kind of mirroring of /lib into /usr/lib (or the other way round?). So, after a bit of struggle putting libc back, I find that this is probably something to do with usrmerge: https://wiki.debian.org/UsrMerge So, if it is now 'correct' that all libs appear in both /lib and /usr/lib, then maybe dpkg-shlibdeps should understand that /usr/lib/ld-linux-armhf.so.3 is the same as /lib/ld-linux-armhf.so.3 and use both to look up which package is responsible in order to find the .symbols/.shlibs files? Because I don't see how we can restrict builds from finding the 'wrong' one. Or is there something I am missing about how this is supposed to work? We do have symbols and shlibs files for ld-linux-armhf.so.3: /var/lib/dpkg/info/libc6:armhf.symbols /var/lib/dpkg/info/libc6:armhf.shlibs so they should be findable. How should I fix this build? And is there a doc explaining how usrmerge is implemented on debian? log excerpt- This happens: dh_shlibdeps dpkg-shlibdeps: error: no dependency information found for /usr/lib/ld-linux-ar\ mhf.so.3 (used by debian/mythtv-common/usr/bin/mythffplay) Hint: check if the library actually comes from a package. dh_shlibdeps: dpkg-shlibdeps -Tdebian/mythtv-common.substvars debian/mythtv-com\ mon/usr/bin/mythccextractor debian/mythtv-common/usr/bin/mythmetadatalookup deb\ ian/mythtv-common/usr/bin/mythffprobe debian/mythtv-common/usr/bin/mythffserver\ debian/mythtv-common/usr/bin/mythutil debian/mythtv-common/usr/bin/mythffplay \ debian/mythtv-common/usr/bin/mythffmpeg debian/mythtv-common/usr/bin/mythshutdo\ wn debian/mythtv-common/usr/lib/mythtv/filters/liblinearblend.so debian/mythtv-\ common/usr/lib/mythtv/filters/libcrop.so debian/mythtv-common/usr/lib/mythtv/fi\ lters/libdenoise3d.so debian/mythtv-common/usr/lib/mythtv/filters/libforce.so d\ ebian/mythtv-common/usr/lib/mythtv/filters/libquickdnr.so debian/mythtv-common/\ usr/lib/mythtv/filters/libbobdeint.so debian/mythtv-common/usr/lib/mythtv/filte\ rs/libadjust.so debian/mythtv-common/usr/lib/mythtv/filters/libgreedyhdeint.so \ debian/mythtv-common/usr/lib/mythtv/filters/libivtc.so debian/mythtv-common/usr\ /lib/mythtv/filters/libinvert.so debian/mythtv-common/usr/lib/mythtv/filters/li\ bkerneldeint.so debian/mythtv-common/usr/lib/mythtv/filters/libyadif.so debian/\ mythtv-common/usr/lib/mythtv/filters/libonefield.so debian/mythtv-common/usr/li\ b/mythtv/filters/libfieldorder.so debian/mythtv-common/usr/lib/mythtv/filters/l\ ibpostprocess.so debian/mythtv-common/usr/lib/mythtv/filters/libvflip.so return\ ed exit code 2 debian/rules:96: recipe for target 'binary' failed - -- System Information: Debian Release: 8.6 Architecture: armhf (armv7l) Kernel: Linux 4.7.0-1-armmp-lpae #1 SMP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#844356: global: fails to index built kernel tree. (Newer version works OK).
Package: global Version: 5.7.1-2 Severity: normal I have a built kernel tree for 3.16. running gtags on it gives a "directory stack over flow" error. ~/debian/linux-3.16.7-ckt9$ gtags gtags: directory stack over flow. ~/debian/linux-3.16.7-ckt9$ global -s enable_dbg global: GSYMS not found. Only two of the 4 index files are generated: GPATH GTAGS I built a (packaged) copy of current upstream global 6.5.5 and tried that, and it worked correctly (reporting a recursive symlink, which is presumably what is making 5.7.1 fail): ~/debian/linux-3.16.7-ckt9$ gtags Warning: symbolic link loop detected. 'debian/build/source_none/debian/build/source_none/' is ignored. Warning: symbolic link loop detected. 'debian/build/source_none/debian/build/build_arm64_none_arm64/source/' is ignored. Warning: symbolic link loop detected. 'debian/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/include/asm/assembler.h debian/build/build_arm64_none_arm64/source/arch/arm64/include/asm/assembler.h debian/build/source_none/arch/arm64/include/asm/assembler.h -- System Information: Debian Release: 8.6 Architecture: arm64 (aarch64)
Bug#844330: global: Emacs-related error on package install "ERROR: global is broken"
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/ signature.asc Description: Digital signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote: > ]] Wei Liu > > > Gtags in Debian doesn't work with modern code base. Last time I tried > > (several > > years ago), it segfault'ed while trying to index Linux kernel. > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and > last time I used it, it also worked fine with the emacs integration, so > I don't recognise the crying from the rooftops about it being broken in > Debian. It seems that it depends on the kernel source tree in use. I just tried on a couple and found these reuslts: ~/debian/linux-4.0$ gtags ~/debian/linux-4.0$ global -s enable_dbg arch/arm64/include/asm/assembler.h 4 files generated: GPATH GTAGS GSYMS GTAGS ~/debian/linux-3.16.7-ckt9$ gtags gtags: directory stack over flow. ~/debian/linux-3.16.7-ckt9$ global -s enable_dbg global: GSYMS not found. 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
Bug#844330: (global: Emacs-related error on package install "ERROR: global is broken")
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: Digital signature
Bug#844330: global: Emacs-related error on package install "ERROR: global is broken"
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 Install global for emacs24 install/global: byte-compiling for emacs24 Loading 00debian-vars... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50global.el (source)... Loading /etc/emacs/site-start.d/50psvn.el (source)... In gtags-get-rootpath: usr/share/emacs24/site-lisp/global/gtags.el:233:14:Warning: assignment to free variable n' usr/share/emacs24/site-lisp/global/gtags.el:233:14:Warning: reference to free variable n' In gtags-select-it: usr/share/emacs24/site-lisp/global/gtags.el:523:13:Warning: goto-line' is for interactive use only; use forward-line' instead. Wrote /usr/share/emacs24/site-lisp/global/gtags.elc Suggesting that something is wrong/out-of-date with the emacs package-interfacing. It's this in the postinst: # Automatically added by dh_installemacsen if [ "$1" = "configure" ] && [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common ] then /usr/lib/emacsen-common/emacs-package-install --postinst global fi and global contains an emacs package 'gtags.el' Emacs policy: https://www.debian.org/doc/packaging-manuals/debian-emacs-policy says that a package must "add a "Depends: emacsen-common (>= 2.0.8)" and include a file like this that indicates its emacsen-common compatibility level: /usr/lib/emacsen-common/packages/compat/" but global contains neither the dependency, nor the file, presumably because it pre-dates this info. -- System Information: Debian Release: 8.6 Architecture: arm64 (aarch64) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Bug#844056: Missing brcmfmac43362-sdio.txt stops wireless working
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 for details: https://groups.google.com/forum/#!topic/linux-sunxi/NngIhT-ELVc That says that for the sdio version of this device the rom/nvram is normally not fitted so the OS has to provide the config, from this text file. It also suggests that the best thing to do is put it in the firmware package, next to the corresponding firmware. There may well be more that one variant of this for different boards, but this one covers several, probably everything using the ap6210. The file is available from http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt and looks like this. #AP6210_NVRAM_V1.2_03192013 manfid=0x2d0 prodid=0x492 vendid=0x14e4 devid=0x4343 boardtype=0x0598 # Board Revision is P307, same nvram file can be used for P304, P305, P306 and P 307 as the tssi pa params used are same #Please force the automatic RX PER data to the respective board directory if not using P307 board, for e.g. for P305 boards force the data into the following di rectory /projects/BCM43362/a1_labdata/boardtests/results/sdg_rev0305 boardrev=0x1307 boardnum=777 xtalfreq=26000 boardflags=0x80201 boardflags2=0x80 sromrev=3 wl0id=0x431b macaddr=00:90:4c:07:71:12 aa2g=1 ag0=2 maxp2ga0=74 cck2gpo=0x ofdm2gpo=0x mcs2gpo0=0x mcs2gpo1=0x pa0maxpwr=56 #P207 PA params #pa0b0=5447 #pa0b1=-658 #pa0b2=-175 #Same PA params for P304,P305, P306, P307 pa0b0=5447 pa0b1=-607 pa0b2=-160 pa0itssit=62 pa1itssit=62 cckPwrOffset=5 ccode=0 rssismf2g=0xa rssismc2g=0x3 rssisav2g=0x7 triso2g=0 noise_cal_enable_2g=0 noise_cal_po_2g=0 swctrlmap_2g=0x04040404,0x02020202,0x02020202,0x010101,0x1ff temp_add=29767 temp_mult=425 btc_flags=0x6 btc_params0=5000 btc_params1=1000 btc_params6=63 -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#842180: CD-text info printed but no option to use it
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' Track 2: 'Save Me' Track 3: 'Giving Us Life' Track 4: 'Responsibility' Track 5: 'A Piece of Rock & Roll' It would be great if it was possible to say 'use this', perhaps only if it doesn't match the retrieved CDDB/Muscibrainz basic info? Yes. I know: patches welcome. This is a placeholder in case anyone gets enthused. -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages abcde depends on: ii cd-discid 1.4-1 ii flac 1.3.0-3 ii icedax9:1.1.11-3 ii vorbis-tools 1.4.0-6+deb8u1 ii wget 1.16-1+deb8u1 Versions of packages abcde recommends: ii bsd-mailx 8.1.2-0.20141216cvs-2 ii libmusicbrainz-discid-perl 0.03-5 ii libwebservice-musicbrainz-perl 0.93-1.1 ii perl [libdigest-sha-perl] 5.20.2-3+deb8u6 ii vorbis-tools1.4.0-6+deb8u1 Versions of packages abcde suggests: ii atomicparsley0.9.2~svn110-4 pn distmp3 ii eject2.1.5+deb1+cvs20081104-13.1 pn eyed3 pn id3 ii id3v20.1.12-2.1 pn mkcue pn mp3gain ii normalize-audio 0.7.7-12 pn vorbisgain -- Configuration Files: /etc/abcde.conf changed [not included] -- no debconf information
Bug#842179: Debug enabled so spurious stuff printed
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 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages abcde depends on: ii cd-discid 1.4-1 ii flac 1.3.0-3 ii icedax9:1.1.11-3 ii vorbis-tools 1.4.0-6+deb8u1 ii wget 1.16-1+deb8u1 Versions of packages abcde recommends: ii bsd-mailx 8.1.2-0.20141216cvs-2 ii libmusicbrainz-discid-perl 0.03-5 ii libwebservice-musicbrainz-perl 0.93-1.1 ii perl [libdigest-sha-perl] 5.20.2-3+deb8u6 ii vorbis-tools1.4.0-6+deb8u1 Versions of packages abcde suggests: ii atomicparsley0.9.2~svn110-4 pn distmp3 ii eject2.1.5+deb1+cvs20081104-13.1 pn eyed3 pn id3 ii id3v20.1.12-2.1 pn mkcue pn mp3gain ii normalize-audio 0.7.7-12 pn vorbisgain -- Configuration Files: /etc/abcde.conf changed [not included] -- no debconf information
Bug#842178: Defaults to CDDB when Muscibrainz works better
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 info in /etc/abcde.conf has 'Muscibrainz' not 'musicbrainz' in the config example. -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages abcde depends on: ii cd-discid 1.4-1 ii flac 1.3.0-3 ii icedax9:1.1.11-3 ii vorbis-tools 1.4.0-6+deb8u1 ii wget 1.16-1+deb8u1 Versions of packages abcde recommends: ii bsd-mailx 8.1.2-0.20141216cvs-2 ii libmusicbrainz-discid-perl 0.03-5 ii libwebservice-musicbrainz-perl 0.93-1.1 ii perl [libdigest-sha-perl] 5.20.2-3+deb8u6 ii vorbis-tools1.4.0-6+deb8u1 Versions of packages abcde suggests: ii atomicparsley0.9.2~svn110-4 pn distmp3 ii eject2.1.5+deb1+cvs20081104-13.1 pn eyed3 pn id3 ii id3v20.1.12-2.1 pn mkcue pn mp3gain ii normalize-audio 0.7.7-12 pn vorbisgain -- Configuration Files: /etc/abcde.conf changed: CDDBMETHOD=musicbrainz -- no debconf information
Bug#832570: Info received (Bug#832570: tex-common fails to install with fmtutil error)
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. fmtutil [ERROR]: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini http://wookware.org/ signature.asc Description: Digital signature
Bug#832570: tex-common fails to install with fmtutil error
Date: Sat, 6 Aug 2016 22:41:55 +0900 [sorry I missed this message at the time (off on expedition, and it doesn't seem like the BTS delivered me a mail)] > I have again looked into this topic and couldn't find a > reasonable explanation for now. Well, I just went back to a clean build chroot and hit this issue again, so an update... > I have uploaded a new set of packages today, where several > internal files concerning pdftexconfig.tex as weell have been > reworked. > Can you please do the following: > * remove /var/lib/texmf/tex/generic/config/pdftexconfig.tex > * 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 files ii texlive-binaries 2016.20160513.41080-6amd64 Binaries for TeX Live ii texlive-latex-base 2016.20160819-2 all TeX Live: LaTeX fundamental packages ii texlive-latex-base-doc 2016.20160819-2 all TeX Live: Documentation files for texlive-latex-base ii texlive-luatex 2016.20160819-2 all TeX Live: LuaTeX packages -- (unstable-amd64)wookey@kh:~/packages$ sudo apt-get install tex-common Reading package lists... Done Building dependency tree Reading state information... Done tex-common is already the newest version (6.05). tex-common set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 275 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y Setting up tex-common (6.05) ... debconf: unable to initialize frontend: Dialogdebconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Running mktexlsr. This may take some time... done. Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.vKSJnfzq Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): ---/tmp/fmtutil.vKSJnfzq-- fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order): fmtutil: /usr/share/texmf/web2c/fmtutil.cnf fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes: fmtutil: /etc/texmf/web2c/fmtutil.cnf fmtutil [INFO]: writing formats under /var/lib/texmf/web2c fmtutil [INFO]: --- remaking luatex with luatex fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ... This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian) (INITEX) restricted system commands enabled. (/usr/share/texlive/texmf-dist/tex/plain/config/luatex.ini (/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex) (/usr/share/texlive/texmf-dist/tex/generic/config/luatex-unicode-letters.tex loading Unicode properties) (/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini (/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex ! Undefined control sequence. l.6 \pdfoutput = 1 ? ! Emergency stop. l.6 \pdfoutput = 1 ! ==> Fatal error occurred, bad output DVI file produced! No pages of output. Transcript written on luatex.log. fmtutil [INFO]: --- remaking pdftex with pdftex fmtutil: running `pdftex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdfetex.ini' ... This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (INITEX) restricted \write18 enabled. (/usr/share/texlive/texmf-dist/web2c/cp227.tcx) entering extended mode (/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini (/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex) (/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes"; Skipping module "nodetypes"; Skipping module "iftypes";) (/var/lib/texmf/tex/generic/config/language.def (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX defini
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On 2016-10-19 14:26 +0100, Ian Jackson wrote:
> Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to
> package a new upstream version"):
> > Ron Lee is the current maintainer and disagrees on some issues with
> > upstream and therefore don't want to update to a more recent
> > version. See bug #574947:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947
>
> Looking at the bug logs, Ron has failed in the one non-delegatable,
> non-negotiable task for the Debian maintainer of a package: namely, to
> make appropriate decisions with respect to the package and then to
> communicate those decisions.
>
> Even if the decision to keep the new upstream version out of Debian is
> correct, Ron has failed to provide a coherent explanation. He has
> failed to engage with those who were willing and ready to do the work.
>
> I think the package would be best served by having a new maintainer.
>
> (Sadly I don't think the TC is likely to agree with me. Historically
> the TC has very very slow to act against maintainers who block other
> people's work and who do not communicate properly.)
Indeed. The current situation is that the existing version is so old
that it doesn't work properly with modern code any more, but the
maintainer has refused to do any of:
1) upload a new package,
2) allow an upload which removes the offending CGI bit (which users don't
really care
about anyway)
3) write something to change the local behaviour to be satisfactory.
Upstream has been clear that they are not going to change how it
works, but they don't care if debian omits that bit or changes it
locally, so it seems to me that a maintainer has to do one of the
above three things. 5 years of this is more than long enough to
conclude that they are not doing their job adequately, and because of
our strong maintainership culture, are preventing other people from
doing that job.
It could just be NMUed, or a global6 uploaded so at least people would
have something to work 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
Bug#837078: packaging ne10
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 the libs don't). By the magic of cmake it's not > entirely clear why. Once I've worked that out, I think we are good to > upload. OK. I beat cmake into submission (and now have some patches to upstream). ne10 is now uploaded and is in the NEW queue. Hopefully it will migrate in the not-too-distant. I have been told that the CLA is going to go away in the next release, which is good, so this then becomes a plain BSD package. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#840323: debhelper: cmake build system: cross compilation
On 2016-10-10 21:30 +, Holger Levsen wrote:
> Hi Helmut,
>
> On Mon, Oct 10, 2016 at 08:39:39PM +0200, Helmut Grohne wrote:
> > dpkg-cross is deprecated by its former maintainer and ought to be
> > removed.
>
> this seems a fairly strong statement, considering
> https://tracker.debian.org/pkg/dpkg-cross shows not a single bug filed
> against the package.
Now that dpkg-cross has had its RC bug fixed, I am happy to keep it in
maintenance mode. It is not useless. It is also the source package
from which cross-config comes, and that remains important.
So no it's shouldn't be RMed. And yes I'm looking after it.
I have just done the formal adoption upload to make this clearer
As to the more interesting question of how best to deal with cmake
cross-building, I wish I knew what the correct thing to do is.
It is clearly better to have dpkg and debhelper conspire to set things
up so that they 'just work' if we can. Because we have multiarch there
is a good chance that this can be done in such a way that both native
and cross building work with the same config.
But I must admit that I have never managed to fully grok what was done
in cmake to make multiarch crossbuilding work. I did recently mess
with a cmake package and I specified
-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) in an
override_dh_auto_configure: to get it to build with multiarch paths.
but this was not sufficient for the library to get put in
$(DEB_HOST_MULTIARCH) even inthe native build. Indeed I was
wondering where the right place to ask about this sort of thing is?
the CmakeLists.txt file just says set(libdir ${CMAKE_INSTALL_LIBDIR})
and after that the pkgconfig file ends up in the right (multiarch)
place, but the library itself doesn't.
Anyone know what might be up there? (The offending package there is
ne10, which is not yet uploaded, because the multiarch path is only
partially working)
/end digression.
cross-config exists as a place for extra cross configuration that is
not (yet) catered for by our other systems. As we move things into
dpkg and debhelper 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
Bug#840257: ITP: mali-driver -- Mali GPU binary drivers
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 : ARM Proprietary Programming Lang: Binaries Description : Mali GPU binary drivers This binary driver provides support for ARM mali graphics hardware. It includes a dkms kernel interface module that allows a driver to work with multiple kernel versions, and variants for fbdev, x11 and wayland usage on Mali-4xx, -Txxx and -Gxx hardware are included. Opengl (eg1, gles1&2), and opencl are supported. A recent change in the Mali proprietary licence has made these drivers redistributable, without a clickthrough, specifically so that distributions can make them available. Linaro is providing time for getting the packaging done.
Bug#730638: ITP: Cloudcompare
CLoudcompare packaging stalled because it contained a bit of non-free 3rd-party code. This was fixed a while ago (Nov 2015) upstream: > As pointed by Debian FTPMaster, the "not so free" license of Triangle library > is not compatible with the LGPL/GPL license scheme adopted by CC. > This commit allow to use CGAL, a well established (and packaged) LGPL/GPL > library of geometric processing instead of Triangle where needed. > This implementation is a priori on parity with Triangle one with regards of > the > repetability. It's a little bit faster and maybe it have a small memory > overhead. > Alternatively Triangle can still be used (and is the default build choice in > the CMakeList.txt) to allow a smooth transition. But it can be safely removed > in order to eventually push a DSFG package of CloudCompare. > Travis script is updated 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
Bug#821080: src:rt-app: FTBFS: due to json API changes
OK. I tried to fix this by updating to latest rt-app release, but a bit more investigation has made it clear that this package effectively has two 'upstreams'. The nominal upstream (in last upload) and the Linaro-maintained package which has had a lot of development (in original upload). There is quite a large delta between them now. I have talked to both maintainers and everyone agrees that this should all be merged into one version but no-one has found the time yet. I intend to spend some time on this shortly, to get one version with most of the best bits. So apologies for 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
Bug#837078: packaging ne10
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 the libs don't). By the magic of cmake it's not entirely clear why. Once I've 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
Bug#838051: kodi: Embedded libsquish library now available in debian
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 upstream and will hopefully appear > > in libsquish 1.14 at some point. This has now happened, so I just uploaded 1.14. (no functional changes over 1.13-3) > Thank you for packaging libsquish. > Kodi upstream dropped many embedded code copies recently including > libsquish in 17.x. > Experimental already has a kodi version without libsquish. You mean that it doesn't actually use it any more? > I'll close this bug when Kodi 17.x enters unstable. OK. Cheers. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#838611: ITP: dxtool -- DistoX data download tool
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 Programming Lang: C Description : DistoX/DistoX2 data download tool dxtool is a minimal implementation of the DistoX and DistoX2 protocols which will download measurements from the devices over a bluetooth serial (SPP) connection. . The DistoX and DistoX2 are cave survey instruments designed by Beat Heeb. This is part of a series of cave-surveying packages that I maintain. Debian is the worlds best cave-surveying distro. :-)
Bug#838542: [Android-tools-devel] Bug#838542: android-platform-system-core: profile build does not actually work
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 and safe-iop are indeed needed in stage1, as well as pandoc > (I guess you had typos?). We never intended to set a stage for "nodoc" > which, so I also included it in stage1. The point here is that which things are skipped in a 'stage1' build is not very well defined. It is primarily there to break build-dep loops. Clearly that involves the packages from android-platform-system-extras. It is also useful to avoid needing the pango packaging tools, because that involves haskell, but that's not a specific dependency-loop here, and we have a more specific profile for doing this: 'nodoc'. So it is better to use that one, because it makes it easier to write automated tools to do bootstrapping. However it's not very important, so if you really prefer to but it all under 'stage1' I'm not going to make a fuss :-) Build-profile policy is still developing as we work out what is best, and it's not written down anywhere... > However I'm not sure about your point of self dependency of > andoid-platform-system-core-headers. This package does not > build-depend on it, but instead depends on > android-platform-build-headers. Ah yes. I was confusing the two, you are right. And android-platform-build-headers comes from android-platform-build source pakcage, but that build-depends on android-libutils-dev so there is stilla circular dependency in there? Or do you have profile info to work round that? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#837078: missing make install option
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 some whitespace as > requested by upstream developers and created a new pull request: > https://github.com/projectNe10/Ne10/pull/134 > > But I do not have cmake experience so I can not comment on the quality of the > provided patch. Patch looks good. I have included it as it makes the packaging simpler. I have a basic packaging done now, and have just clarified a question about the licencing. The only major thing missing is that the current build doesn't build the docs. I'll fix that and then upload. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#838542: android-platform-system-core: profile build does not actually work
Source: android-platform-system-core Version: 6.0.1+r55 Severity: normal Dear Maintainer, I was very pleased to see that this package had build-profile info for untangling the bootstrap of this and android-platform-system-extras. However when I tried using it I found that it didn't build. android-libunwind-dev is needed (by libbacktrace), which is needed by libutils. I don't know if it could be removed, but it seemed tricky, and as android-libunwind-dev comes from a separate source with minimal build-deps there seems to be no need to skip this build-dep. So I put it back. Similarly libsafe-iop-dev is needed too and is not obvisoulypart of a loop so I put that back. Now it builds but tries to use pango for the manpages and so fails. not using pango should use the 'nodoc' build profile rather than the 'stage1' profile as that is more specific. So I changed that and fixed up the rules files not to run those rules. And use dh-exec to avoid dh_installman trying to install non-existent manpages. Now it works. You can test it with apt-get -P stage1,nodoc build-dep android-platform-system-core cd android-platform-system-core-* dpkg-buildpackage -Pstage1,nodoc Hope 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-6.0.1+r55/debian/adb.manpages --- android-platform-system-core-6.0.1+r55/debian/adb.manpages 2016-07-21 19:07:25.0 + +++ android-platform-system-core-6.0.1+r55/debian/adb.manpages 2016-09-22 04:50:10.0 + @@ -1 +1 @@ -debian/adb.1 \ No newline at end of file +#!/usr/bin/dh-exec\n debian/adb.1\n \ No newline at end of file diff -Nru android-platform-system-core-6.0.1+r55/debian/changelog android-platform-system-core-6.0.1+r55/debian/changelog --- android-platform-system-core-6.0.1+r55/debian/changelog 2016-07-21 19:07:25.0 + +++ android-platform-system-core-6.0.1+r55/debian/changelog 2016-09-22 04:37:09.0 + @@ -1,3 +1,10 @@ +android-platform-system-core (1:6.0.1+r55-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix stage1 build so it works + + -- Wookey <woo...@debian.org> Thu, 22 Sep 2016 04:36:58 + + android-platform-system-core (1:6.0.1+r55-1) unstable; urgency=medium * New upstream release. diff -Nru android-platform-system-core-6.0.1+r55/debian/control android-platform-system-core-6.0.1+r55/debian/control --- android-platform-system-core-6.0.1+r55/debian/control 2016-07-21 19:07:25.0 + +++ android-platform-system-core-6.0.1+r55/debian/control 2016-09-22 04:39:22.0 + @@ -7,14 +7,14 @@ Chirayu Desai <chirayudes...@gmail.com> Build-Depends: android-libext4-utils-dev (>= 6.0.1+r16-2) [amd64 i386] , android-libf2fs-utils-dev (>= 6.0.1+r16-2) [amd64 i386] , - android-libunwind-dev (>= 6.0.1+r55~) [amd64 i386] , + android-libunwind-dev (>= 6.0.1+r55~) [amd64 i386], android-platform-build-headers (>= 1:6.0.1+r16-4), debhelper (>= 9.20141010), dh-exec, dpkg-dev (>= 1.17.14), - libsafe-iop-dev [amd64 i386] , + libsafe-iop-dev [amd64 i386], libssl-dev [amd64 i386] , - pandoc [amd64 i386] , + pandoc [amd64 i386] , zlib1g-dev [amd64 i386] Standards-Version: 3.9.8 Homepage: https://android.googlesource.com/platform/system/core diff -Nru android-platform-system-core-6.0.1+r55/debian/fastboot.manpages android-platform-system-core-6.0.1+r55/debian/fastboot.manpages --- android-platform-system-core-6.0.1+r55/debian/fastboot.manpages 2016-07-21 19:07:25.0 + +++ android-platform-system-core-6.0.1+r55/debian/fastboot.manpages 2016-09-22 04:50:30.0 + @@ -1 +1 @@ -debian/fastboot.1 \ No newline at end of file +#!/usr/bin/dh-exec\n debian/fastboot.1\n \ No newline at end of file diff -Nru android-platform-system-core-6.0.1+r55/debian/rules android-platform-system-core-6.0.1+r55/debian/rules --- android-platform-system-core-6.0.1+r55/debian/rules 2016-07-21 19:07:25.0 + +++ android-platform-system-core-6.0.1+r55/debian/rules 2016-09-22 04:40:10.0 + @@ -58,8 +58,11 @@ dh $@ override_dh_auto_build: $(COMPONENTS) +#skip pango usage in stage1 +ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),) pandoc -s -o debian/adb.1 debian/adb.1.md pandoc -s -o debian/fastboot.1 debian/fastboot.1.md +endif override_dh_auto_clean: dh_auto_clean
Bug#838539: apt-get gives confusing error message when -P or --build-profile is used with unknown operation
Package: apt Version: 1.3 Severity: normal If you do: apt-get build-depends -P stage1 android-platform-system-core you get: E: Command line option 'P' [from -P] is not understood in combination with the other options. If you do: apt-get --build-profiles=stage1 build-depends android-platform-system-core you get: E: Command line option --build-profiles=stage1 is not understood in combination with the other options If you do: apt-get -o Apt::Build-Profiles=stage1 build-depends android-platform-system-core you get: E: Invalid operation build-depends In all three cases the issue is actually misspelling 'build-dep' as 'build-depends'. But only in the 3rd case does the user get an indication of this. In the other two they are led to think that there is something wrong with the -P/--build-profile option, when it is in fact fine. Can the parsing be fixed to give the same error in all 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
Bug#838056: nvidia-texture-tools: Embedded libsquish library now available in debian)
On 2016-09-17 00:57 +, Debian Bug Tracking System wrote: OK. The change in nvidia-texture-tools is in fact a valid buffer overflow fix. However it is incomplete and should currently look like the code below: #if SQUISH_USE_SIMD Vec4 m_unweighted[17]; Vec4 m_metric; Vec4 m_metricSqr; Vec4 m_xxsum; Vec4 m_xsum; Vec4 m_besterror; #else Vec3 m_unweighted[17]; Vec3 m_metric; Vec3 m_metricSqr; Vec3 m_xxsum; Vec3 m_xsum; float m_besterror; #endif However that only applied in v1.7 which ntt 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://wookware.org/ signature.asc Description: Digital signature
Bug#836247: ITP: libsquish -- DXT texture compression library
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. > > Great, let me know what the bug numbers are and I'll add them to the > security team's embedded code copies data. 838051 kodi 838052 mame 838053 openimageio 838054 spring 838055 0ad 838056 nvidia-texture-tools I didn't file one against xbmc as that is now a transition package to kodi Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#838055: Acknowledgement (0ad: Embedded libsquish library now available in debian)
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 Description: Digital signature
Bug#838054: Acknowledgement (spring: Embedded libsquish library now available in debian)
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 signature
Bug#838053: Acknowledgement (openimageio: Embedded libsquish library now available in debian)
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 signature
Bug#838056: nvidia-texture-tools: Embedded libsquish library now available in debian
Source: nvidia-texture-tools Severity: normal Dear Maintainer, nvidia-texture-tools contains an embedded copy of libsquish: in src/nvtt/squish I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The nvidia-texture-tools version was forked around v1.7. It has a 1-character change which does not obviously have a reason: "Vec4 m_unweighted[16];" changed to "Vec4 m_unweighted[17];" in fastclusterfit.h. This change has not been included, because it's not in any of the other versions, and seems odd, so if there really is a reason for this then then debian package should be updated. Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the nvidia-texture-tools build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#838055: 0ad: Embedded libsquish library now available in debian
Source: 0ad Severity: normal Dear Maintainer, 0ad contains an embedded copy of libsquish: in tools/depends/native/libsquish-native I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The 0ad version is a simple copy of squish v1.7 Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the 0ad build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#838054: spring: Embedded libsquish library now available in debian
Source: spring Severity: normal Dear Maintainer, spring contains an embedded copy of libsquish: in tools/depends/native/libsquish-native I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The spring version was a simple copy of v1.10. Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the spring build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#838053: openimageio: Embedded libsquish library now available in debian
Source: openimageio Severity: normal Dear Maintainer, openimageio contains an embedded copy of libsquish: in tools/depends/native/libsquish-native I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The openimageio version was forked around v1.10 and has a couple of 1.13 features backported (extra perceptual metric). moving on to this 1.13 version of course includes this. Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the openimageio build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#838052: mame: Embedded libsquish library now available in debian
Source: mame Severity: normal Dear Maintainer, mame contains an embedded copy of libsquish: in 3rdparty/bgfx/3rdparty/libsquish I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The mame version is the current 1.13 with one extra feature: BC4 and BC5 compression format support. As this is included in this version there should be no problem using it. Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the mame build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#838051: kodi: Embedded libsquish library now available in debian
Package: kodi Severity: normal Dear Maintainer, kodi contains an embedded copy of libsquish: in tools/depends/native/libsquish-native I have recently packaged libsquish, and it is now avilable in the archive: https://tracker.debian.org/pkg/libsquish In doing this I examined all the embedded copies, checking them for changes, and have merged all the extra features into the Debian package. Thus it should be straighforward to start using the system library instead of the embedded copy, without any API changes. The changes have also been sent upstream and will hopefully appear in libsquish 1.14 at some point. The kodi version was forked around v1.10 and has some 1.13 features backported as well as some entirely new functionality (BC4 and BC5 compression format support, BGRA as well as RGBA testure source format support, pkconfig support, independent pitch and cell size in textures, and BlockMSE calculation). As all of these are included as-is in this version. Debian policy https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles say that embedded copies should not be used if the library is available in Debian, and https://wiki.debian.org/EmbeddedCodeCopies gives a bit more background. I am not familiar with the kodi build system, so have not attempted to provide a patch as that should be much easier for you, but of course I'll help if you need some. The full set of packages affected is: - nvidia-texture-tools 1.7 (src/nvtt/squish) - 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) - spring 1.10 (rts/lib/squish) - openimageio 1.10+ (1.10+metric) (src/dds.imageio/squish) - xbmc1.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
Bug#837189: closed by Bart Martens <ba...@quantz.debian.org> (closing ITP: ne10 -- ARM neon (SIMD) library)
On 2016-09-09 22:21 +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the wnpp package: > > #837189: ITP: ne10 -- ARM neon (SIMD) library > > It has been closed by Bart Martens <ba...@quantz.debian.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
Bug#837189: ITP: ne10 -- ARM neon (SIMD) library
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, assembler Description : ARM neon (SIMD) library Ne10 is a library of the most commonly used functions that have been heavily optimized for ARM-based CPUs with NEON (ARM's SIMD instructions). These functions provide consistent, well tested behavior for use in applications without having to write assembly. Ne10 is usable as a shared or static library. . Both 32 and 64-bit variants are supported. (ARM v7, 32-bit, armhf, and ARM v8, 64-bit, aarch64/arm64) I'm packaging this because someone pointed out that it wasn't available in debian, but would be useful. That seemed a reasonable point, and I'm in a packaging frame of mind at the moment, so I thought I could fix that fairly easily. This library does only support Arm, but optimised SIMD code is fundamentally arch-specific. I am not aare of a general SIMD library that supplies functions like this as altivec, neon, SSE etc, as appropriate for the arch for multiple arches, although obviously such a thing would be nice. In the absence of such a thing ne10 seems likely to be useful to some developers.
Bug#836565: ITP: dewalls -- Parser for Walls cave survey data
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 : Parser for Walls cave survey data The WALLS cave survey package stores its data in .srv files. dewalls is a parsing library for this file format. It is implemented in C++ and intended to be used by other cave survey software. - why is this package useful/relevant? This is a dependency of cavewhere (ITP:836249)
Bug#836247: ITP: libsquish -- DXT texture compression library
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 (libraries/source/nvtt/src/src/nvtt/squish/)
- spring 1.10 (rts/lib/squish)
- openimageio (embed) 1.10+ (1.10+metric) (src/dds.imageio/squish)
- xbmc (embed) 1.10+ (1.10+metric/BC4/5) (lib/libsquish)
- kodi (embed) 1.10+ (1.10+metric/BC4/5)
(tools/depends/native/libsquish-native)
- mame (embed) 1.13+ BC4,BC5formats
(3rdparty/bgfx/3rdparty/libsquish)
extras:
kodi: BC4 and BC5 compression support (merged)
pkgconfig file. (merged)
makefile .so support (already upstream)
support for BGRA as well as RGBA sources.
compute Block MSE (reduces banding in flat colour areas)
xbmc: identical to kodi
Darwin support in Makefile.in
mame: current version, with the BC4/5 support from kodi
nvidia-texture-tools (identical to 0ad, except 1-char change.
Vec4 m_unweighted[17]; (instead of 16)? in fastclusterfit.h. Is that
significant?
spring is basically as upstream
I have merged most of these extras into upstream (still need to do
BGRA support and block MSE calcs). That will give one version that
should work fine in all these packages. I'm in contact with upstream
about how much of this they want to merge ('all of it' seems
sensible).
Then I'll upload and file bugs against all these packages about the
option to use a system library.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#836249: ITP: cavewhere -- Cave survey processing and visualisation
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++ Description : Cave survey processing and visualisation GUI cave survey software, with data entry entry covering multiple data formats. Data is processed using survex. Sketches are distorted to fit and displayed in 3D, allowing very fast turnaround maps to be produced. Uses QT and works on Windows, Mac and Linux. Data can be imported from Walls and Survex. This is quite new software, with a user-friendly modern GUI and taking a different approach to Tunnel and Therion, the other free-software cave-survey drawing packages. It has a very helpful upstream. It has several dependencies which are not yet in debian and thus will need packaging first: libsquish, qmath3d, dewalls, qt-qml-tricks.
Bug#836247: ITP: libsquish -- DXT texture compression library
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-testing/data/embedded-code-copies?r1=44004=44249 Cheers, that's useful info. 7 packagings and it's still not uploaded separately! It was only supplied as a static library until quite recently, which may explain it, I guess. I've finished the basic packaging already. I'll look into those and see if they have diverged from upstream significantly. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#836247: ITP: libsquish -- DXT texture compression library
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++ Description : DXT texture compression library libsquish is a software DXT texture compression library. It implements the 5 DXT flavours and has SIMD support for x86 (SSE) and powerpc (Altivec). It can be used (as a much slower software fallback) instead of the hardware implementations present on most modern graphics chips. This package is a build-dependency of Cavewhere (https://github.com/Cavewhere, http://www.cavewhere.com), used because using the hardware implementations has been unreliable in practice, and speed is not critical here..
Bug#831556: fixed in jed-extra 2.5.7-1
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 upload shortly. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#817586: most package failed to build on arm64 + ppc64el
On 2016-08-04 08:39 +0200, Michael Prokop wrote:
> Hi!
>
> The most package didn't make it to stretch/testing yet because of:
>
> | % grep-excuses most
> | most (- to 5.0.0a-2.4)
> | Maintainer: Benjamin Mako Hill
> | 12 days old (needed 5 days)
> | missing build on arm64: most (from 5.0.0a-2.3)
> | missing build on ppc64el: most (from 5.0.0a-2.3)
> | Not considered
>
> There are build failures on arm64 + ppc64el, just wanted to clarify
> whether you're aware of that and if someone is taking care of it?
OK. I just uploaded 5.0.0a-2.5 which uses plain dh_autotools-dev instead of
dh_autoreconf.
I tested the build on arm64 to check I got it right this time!
Because the configure.ac was in a sub-dir the simple dh_autoreconf
wasn't doing anything. Adding a debian/autoreconf file listing the
'autoreconf' directory to get it to look in there revealed a load of
grumbling about the very old autofoo, with a selection of JD macros to
make it more interesting. Updating that would require some effort. As
it's not actually broken I just decided to use dh_autotools-dev to
update config.{sub,guess}
Here's the patch against the -2.4 NMU
diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
--- most-5.0.0a/debian/changelog2016-07-22 01:27:30.0 +0100
+++ most-5.0.0a/debian/changelog2016-08-05 00:55:52.0 +0100
@@ -1,3 +1,11 @@
+most (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 <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/debian/control most-5.0.0a/debian/control
--- most-5.0.0a/debian/control 2016-07-21 23:56:40.0 +0100
+++ most-5.0.0a/debian/control 2016-08-05 00:31:45.0 +0100
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Benjamin Mako Hill <m...@debian.org>
Standards-Version: 3.9.8.0
-Build-Depends: debhelper (>=9), autotools-dev, dh-autoreconf, libslang2-dev,
chrpath
+Build-Depends: debhelper (>=9), autotools-dev, libslang2-dev, chrpath
Package: most
Architecture: any
diff -Nru most-5.0.0a/debian/rules most-5.0.0a/debian/rules
--- most-5.0.0a/debian/rules2016-07-21 23:24:49.0 +0100
+++ most-5.0.0a/debian/rules2016-08-05 00:32:12.0 +0100
@@ -35,7 +35,7 @@
build-stamp:
dh_testdir
@echo "Building the binaries ..."
- dh_autoreconf
+ dh_autotools-dev_updateconfig
CC="$(CC)" CFLAGS="$(CFLAGS)" ./configure
--with-slanglib=/usr/lib/"$(DEB_HOST_MULTIARCH)"
$(MAKE) SYS_INITFILE=/etc/most.conf
touch $@
@@ -47,7 +47,7 @@
-rm -f build-stamp src/config.h
-rm -f config.log
[ ! -f Makefile ] || $(MAKE) distclean
- dh_autoreconf_clean
+ dh_autotools-dev_restoreconfig
dh_clean
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#749897: Can't end session if daemon starting after a schroot session is created uses a private mount namespace.
mnt:[4026532308] 1 mnt:[4026532323] 1 mnt:[4026532409] and tracking those via sudo ls -l /proc/*/ns/mnt | grep $mountspace ps -p $PID I find that 47 ?00:00:00 kdevtmpfs 976 ?00:00:00 cupsd 1341 ?00:00:00 colord 3633 ?00:00:00 rtkit-daemon are the offending processes. stopping the services does indeed allow me to clean-up session:rebootstrap (and other sessions) As Stuart says, you have to remove the affected chroot, before restarting the demons. It is not necessary to kill/stop kdevtmpfs Zdenek's script is a little heavy-handed. I normally want to be able to clean up specific chroots, not all of them at once. And that's what schroot needs to do too. The obvious thing is to stop any services in private mount space, before cleaning up. Should they be restarted? Are they associated with one of the chroots, or with the outer system? I don't yet understand why these things have anything to do with chroot mounts. I have cups running on my machine anyway. It has nothing to do with schroot chroots, so why does its use of a private mount space (if started by systemd) get in the way of removing the chroot mount point? Anyway, thank you to previous bug reporters for teaching me about 'mount namespaces' of which I was totally unware 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/
Bug#816326: schroot: don't fail on 15binfmt with a missing /bin/sh
Package: src:schroot Followup-For: Bug #816326 I can confirm that Raphael's patch fixes this issue for me too (not very surprisingly). Wookey
Bug#833024: ITP: javolution -- Real-time java library
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: Java, C++ Description : Real-time java library Javolution (previously known as JADE: Java Addition to Default Environment) provides a library to make applications faster and more time predictable. i.e. it minimises worst-case execution times. It provides collection classes, supporting custom views, closure-based iterations, a map-reduce paradigm, and parallel computations. It is designed to work well on multicore systems with parellisable classes, and can utilise GPUs. The library is provided in C++ and java, with struct and union base classes for direct interfacing with native applications. This package, along with geoapi, is a dependency of jscience, which I am (slowly) packaging. I have no particular expertise in this software, so if anyone else wants to help, they would be very welcome.
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
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 while I appreciate that you applied my patch to
> >> autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is
> >> not regenerated.
> >
> > Hmm. But configure is regenerated (on a second build dpkg-source
> > complains that 'configure' has changed). And I checked that the
> > updated configure has the debian terminfo directory, added from the
> > aclocal patch.
> >
> > Run dpkg-buildpackage and check the configure file:
> > grep terminfo configure
> > { $as_echo "$as_me:${as_lineno-$LINENO}: checking for terminfo" >&5
> > $as_echo_n "checking for terminfo... " >&6; }
> >MISC_TERMINFO_DIRS=`$nc5config --terminfo`
> > /usr/lib/terminfo \
> > /usr/share/terminfo \
> > /usr/share/lib/terminfo \
> > /usr/local/lib/terminfo \
> > /lib/terminfo"
> >
> > What test are you doing to determine that this problem is not fixed?
>
> I ran pbdebuild, where /usr/share/terminfo has been rmdir'ed from the
> build chroot beforehand. Attached is a build log.
I use sbuild, but this shouldn't matter.
> > It is possible I guess that the configure flie is being updated too
> > late so the dir is not checked in time, but I just checked
> > that removing the /usr/share/terminfo did not break the build.
>
> Did you also ensure that libtinfo-dev is not installed on the build
> system? Because if it is, linking with -ltermcap succeeds, and the
> jed package gains a spurious dependency on libtinfo5.
My build chroot is clean so that package is not in it. Still builds OK for me.
Same with a local build in jessie.
OK. I've managed to reproduce it now.
> Well, in a normal build system configure _is_ updated, but only after
> building jed and before building xjed. Which is a bit too late.
OK. I've done a better job of ensuring configure is generated before
first usage, and backed-up/restored so a second build works as
well. Basically a manual dh_autoreconf.
3rd time lucky... uploaded.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
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:
> >>
> >> ,
> >> | dh_testdir
> >> | #
> >> | # --- MAKE ---
> >> | #
> >> | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed #
> >> getmail
> >> | make[1]: Entering directory '/build/jed-0.99.19'
> >> | cd autoconf && autoconf && mv ./configure ..
> >> | Makefile is older than the configure script.
> >> | Please re-run the configure script.
> >> | Makefile:18: recipe for target 'Makefile' failed
> >> | make[1]: *** [Makefile] Error 1
> >> | make[1]: Leaving directory '/build/jed-0.99.19'
> >> | debian/rules:72: recipe for target 'build-stamp' failed
> >> `
> >>
> >> Apparently there's something fishy with the build system, I don't know
> >> whether it's related to debian/rules or if it is an upstream bug.
>
> > OK. I wasn't sure whether this bug was actually fixed by my changes. I
> > hoped that updating with autoreconf would make it go away (and it
> > worked for me in a fresh chroot). I admit I didn't check the details
> > very hard. So that for doing that.
> >
> > I'll look at the autofoo and try and work out what the correct fix
> > is. My main problem is that I don't really understand how the terminfo
> > libraries are used.
>
> They should not be used at all, but Mr. Davis has these special broken
> tests for them. :-( And while I appreciate that you applied my patch to
> autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is
> not regenerated.
Hmm. But configure is regenerated (on a second build dpkg-source
complains that 'configure' has changed). And I checked that the
updated configure has the debian terminfo directory, added from the
aclocal patch.
Run dpkg-buildpackage and check the configure file:
grep terminfo configure
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for terminfo" >&5
$as_echo_n "checking for terminfo... " >&6; }
MISC_TERMINFO_DIRS=`$nc5config --terminfo`
/usr/lib/terminfo \
/usr/share/terminfo \
/usr/share/lib/terminfo \
/usr/local/lib/terminfo \
/lib/terminfo"
What test are you doing to determine that this problem is not fixed?
It is possible I guess that the configure flie is being updated too
late so the dir is not checked in time, but I just checked
that removing the /usr/share/terminfo did not break the build.
So I think I must be misunderstanding something here.
I realise that my latest attempt at a fix is not at all clean, and
makes the package one of those annoying 'won't build twice' packages,
but it did seem to me to be working.
Thanks for checking - I do actually want to get this right, although I
was hoping to avoid investing loads of time in a major autoconf update
(even though that is the right thing to do).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#832570: tex-common fails to install with fmtutil error
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 me the version number of
> your packages texlive-base, too.
tex-related packages
ii libptexenc1:amd64 2016.20160513.41080-4
ii libsynctex1:amd64 2016.20160513.41080-4
ii libtexlua52:amd64 2016.20160513.41080-4
ii libtexluajit2:amd642016.20160513.41080-4
ii tex-common 6.05
ii texlive-base 2016.20160623-1
ii texlive-binaries 2016.20160513.41080-4
ii texlive-luatex 2016.20160623-1
> > l.3 \pdfoutput
> > =1
>
> This is strange, indeed.
>
> Your pdftexconfig.tex
>
> > % Set pdfTeX parameters for pdf mode (replacing pdftex.cfg file).
> > % Thomas Esser, 2004. public domain.
> > \pdfoutput=1
> > \pdfcompresslevel=9
> > \pdfdecimaldigits=3
> > % pdftex paper settings are in pdftexconfig-paper.tex
> > \input pdftexconfig-paper.tex
> > \pdfhorigin=1 true in
> > \pdfvorigin=1 true in
> > \pdfpkresolution=600
> > %
> > % As of TeX Live 2010, we output PDF 1.5 by default, so we can enable
> > % more compression. To change this for the installation, comment out or
> > % delete these lines and remake the formats. To change it for a
> > % particular LaTeX document, \RequirePackage{pdf14} early.
> > %
> > \pdfminorversion=5
> > \pdfobjcompresslevel=2
> > \pdfpageheight = 297 true mm\pdfpagewidth= 210 true mm
> > \endinput
>
> This looks also different to mine, but I have intermediate
> not released versions installed.
>
>
> > I was able to work around this issue by editing
> > /usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
> > to comment out the
> > \input pdftexconfig.tex
> > line
>
> No, please *remove* the file
> /var/lib/texmf/tex/generic/config/pdftexconfig.tex
I had already removed this and tried apt-get -f install. Only when
that failed did I try the above commenting-out.
This was done in a persistent chroot, so I cannot revert the state
exactly and try the experiment again, unfortunately (i.e the new
tex-common is now installed, but I guess it was the postinst failing,
so further tests should stil lbe relevant).
> and then try as rootsudo q
> mktexlsr /var/lib/texmf
> fmtutil-sys --byfmt luatex
> if that helps.
>
> If no, please send me the output.
OK. with /usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
restored and /var/lib/texmf/tex/generic/config/pdftexconfig.tex removed,
the above commands give:
$ sudo mktexlsr /var/lib/texmf
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
$ sudo fmtutil-sys --byfmt luatex
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil: /usr/share/texmf/web2c/fmtutil.cnf
fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil: /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian) (INITEX)
restricted system commands enabled.
(/usr/share/texlive/texmf-dist/tex/plain/config/luatex.ini
(/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex)
(/usr/share/texlive/texmf-dist/tex/generic/config/luatex-unicode-letters.tex
loading Unicode properties)
(/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
! I can't find file `pdftexconfig.tex'.
l.4 \input pdftexconfig.tex
(Press Enter to retry, or Control-D to exit)
Please type another input file name:
! Emergency stop.
l.4 \input pdftexconfig.tex
! ==> Fatal error occurred, bad output DVI file produced!
No pages of output.
Transcript written on luatex.log.
fmtutil [ERROR]: running `luatex -ini -jobname=luatex -progname=luatex
luatex.ini http://wookware.org/
signature.asc
Description: Digital signature
Bug#832570: Acknowledgement (tex-common fails to install with fmtutil error)
On 2016-07-27 03:03 +, Debian Bug Tracking System wrote: I was able to work around this issue by editing /usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini to comment out the \input pdftexconfig.tex line Is the problem that pdftex is not installed but I still have config files for it? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#832570: tex-common fails to install with fmtutil error
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 been stored in /tmp/fmtutil.f8jZR1xO Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): subprocess installed post-installation script returned error exit status 1 The failing command seems to be: fmtutil: running luatex -ini -jobname=luatex -progname=luatex luatex.ini' ... This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian) (INITEX) restricted system commands enabled. (/usr/share/texlive/texmf-dist/tex/plain/config/luatex.ini (/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex) (/usr/share/texlive/texmf-dist/tex/generic/config/luatex-unicode-letters.tex loading Unicode properties) (/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini (/var/lib/texmf/tex/generic/config/pdftexconfig.tex ! Undefined control sequence. l.3 \pdfoutput =1 ? ! Emergency stop. /var/lib/texmf/tex/generic/config/pdftexconfig.tex is attached. Oddly, it does not seem to be owned by any package, according to dpkg -S Attached are the apt output log, the fmtutil log and the pdftexconfig.tex file. removing the /var/lib/texmf/tex/generic/config/pdftexconfig.tex file did not help. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.27 ii ucf3.0030 tex-common recommends no packages. Versions of packages tex-common suggests: ii debhelper 9.20150101+deb8u2 Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 651 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up tex-common (6.05) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Running mktexlsr. This may take some time... done. Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.SetmxtF9 Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of hevea: hevea depends on tex-common (>= 6); however: Package tex-common is not configured yet. dpkg: error processing package hevea (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: tex-common hevea E: Sub-process /usr/bin/dpkg returned an error code (1) fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order): fmtutil: /usr/share/texmf/web2c/fmtutil.cnf fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes: fmtutil: /etc/texmf/web2c/fmtutil.cnf fmtutil [INFO]: writing formats under /var/lib/texmf/web2c fmtutil [INFO]: --- remaking tex with tex fmtutil: running `tex -ini -jobname=tex -progname=tex tex.ini' ... This is TeX, Version 3.14159265 (TeX Live 2016/Debian) (INITEX) (/usr/share/texlive/texmf-dist/tex/plain/config/tex.ini (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) ) Beginning to dump on file tex.fmt (preloaded format=tex 2016.7.27) 2027 strings of total length 29296 4990 memory locations dumped; current usage is 110&4877 926 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 \font\preloaded=cmss10 \font\preloaded=cmssq8 \font\preloaded=cmssi10 \font\preloaded=cmssqi8 \font\tenbf=cmbx10 \font\preloaded=cmbx9
Bug#832450: jed: typo in debian/rules: dpgk-architecture
On 2016-07-25 18:05 +0200, Sven Joachim wrote: > Source: jed > Version: 1:0.99.19-5 > Severity: normal > > I have noticed the following typo in debian/rules: > > DEB_HOST_MULTIARCH ?=$(shell dpgk-architecture -qDEB_HOST_MULTIARCH) > > This is not a problem when using dpkg-buildpackage since it sets > DEB_HOST_MULTIARCH for us, but when invoking debian/rules directly, > DEB_HOST_MULTIARCH will be set to the empty string. Sorry I'm being dim here. I think that should set DEB_HOST_MULTIARCH (to the result of 'dpgk-architecture -qDEB_HOST_MULTIARCH'), unless DEB_HOST_MULTIARCH is already set to something in which case it should keep that value. Am I wrong? I don't see why it should end up null if invoked directly as a make rule. > Nevertheless, jed > builds fine even then which suggests that passing --with-slanglib and > --with-slanginc is 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, without spending a lot of time testing. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-25 18:45 +0200, Sven Joachim wrote:
> Control: found -1 1:0.99.19-5
>
> > The configure script tries to run "ncurses5-config --terminfo", and if
> > this does not succeed, uses a hardcoded list of terminfo directories
> > which unfortunately does not include the directories /etc/terminfo and
> > /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo
> > directory, it then concludes that the system must be using termcap and
> > adds "-ltermcap" to the linker line which fails.
> >
> > I will work around that by shipping an /usr/share/terminfo directory in
> > ncurses-base, but jed might still FTBFS on the buildds until they
> > upgrade their base system.
>
> I have re-opened the bug, since removing the /usr/share/terminfo
> directory from the build system still triggers the FTBFS bug, and maybe
> we want to drop the empty directory from ncurses-base at some point in
> the future.
> > Properly fixing this bug requires patching the buggy test in
> > autoconf/aclocal.m4 and regenerating configure, but since jed does not
> > currently build-depend on autoconf and uses dpatch which I haven't used
> > for years I can't really come up with a patch.
>
> I have tried the attached patch, but unfortunately the build broke:
>
> ,
> | dh_testdir
> | #
> | # --- MAKE ---
> | #
> | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed # getmail
> | make[1]: Entering directory '/build/jed-0.99.19'
> | cd autoconf && autoconf && mv ./configure ..
> | Makefile is older than the configure script.
> | Please re-run the configure script.
> | Makefile:18: recipe for target 'Makefile' failed
> | make[1]: *** [Makefile] Error 1
> | make[1]: Leaving directory '/build/jed-0.99.19'
> | debian/rules:72: recipe for target 'build-stamp' failed
> `
>
> Apparently there's something fishy with the build system, I don't know
> whether it's related to debian/rules or if it is an upstream bug.
OK. I wasn't sure whether this bug was actually fixed by my changes. I
hoped that updating with autoreconf would make it go away (and it
worked for me in a fresh chroot). I admit I didn't check the details
very hard. So that for doing that.
I'll look at the autofoo and try and work out what the correct fix
is. My main problem is that I don't really understand how the terminfo
libraries are used.
> Anyway, thanks for switching away from dpatch!
Yeah, that makes everyone's lives a little easier. It turned out to be
easy 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
Bug#832449: jed: FTBFS on arm64: machine `aarch64' not recognized
On 2016-07-25 17:49 +0200, Sven Joachim wrote:
> Source: jed
> Version: 1:0.99.19-5
> Severity: serious
> Tags: patch
>
> The latest version of jed FTBFS on arm64[1] because config.sub is too
> old:
>
> ,
> | checking build system type... Invalid configuration `aarch64-linux-gnu':
> machine `aarch64' not recognized
> | configure: error: /bin/bash autoconf/config.sub aarch64-linux-gnu failed
> `
>
> This should be fixed by replacing config.{sub,guess} with the files from
> autotools-dev at build time. I have attached a possible patch which
> does that via dh_update_autotools_config (included in debhelper since
> version 9.20160114), but since I don't have an arm64 system, it's not
> really tested.
Doh!. I carefully updated to use dh_autoreconf to avoid exactly this
sort of issue, but it's true that I only tested on x86.
I do have an arm64 system now (as of last week!), and it's easy to
test on the porter boxes too.
When did "dh_update_autotools_config" appear? I've always used
dh_autotools-dev_updateconfig
and
dh_autotools-dev_restoreconfig
or is that what you 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
Bug#817586: Info received (most: diff for NMU version 5.0.0a-2.4)
On 2016-07-22 01:12 +, Debian Bug Tracking System wrote: Herman and I tried to re-arrange things so that my more thorough upload ended up in the archive, after 10 days, but I screwed up and accidentally did an immediate upload. Hopefully everyone is fine with this and no harm done. 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
Bug#817586: most: diff for NMU version 5.0.0a-2.4
Hi Mako,
I've prepared an NMU for most (versioned as 5.0.0a-2.4) and
uploaded it to DELAYED/10.
This is not a minimal bugfix NMU, as this package has not been touched
by the maintainer since 2010 and could clearly do with an update, so
I've updated it. Mako - if you want to keep it all old and crufty then
feel free to override, or argue about the details if any of it offends
your sensibilities :-)
The patch looks fat because it reverts the patched (but still old)
config.{sub,guess} updates for proper use of dh_autoreconf (as
recommended on https://wiki.debian.org/Autoreconf), but this actually
results in a much smaller patch overall.
Changes made:
* Update the debhelper compat level (to get most back in the archive)
* Add build-arch/indep targets to stop it getting thrown out again for that
reason
* The above dh_autoreconf so it works with new arches
* Update to current policy (use dpkg-buildflags, misc:Depends,
remove uneeded dpkg-dev dependency)
* Split the 1.0-format patch into 4 quilt-format patches. This is most
controversial perhaps, but unless you hate the quilt format for some
reason, this seems helpful to me. This puts back a fix done this way
in the -2.2 NMU then reverted in the -2.3 NMU.
* Remove $CC=gcc forcing which breaks crossbuilding and is just poor form
* Remove out-of-date specific version mention in copyright file, and make
source reference generic, (as this wasn't really made from v4.7 source
anymore.)
If you don't like any of these things I'm happy to do a different upload.
Here is the 'meaningful' diff. Attached is the full diff, dominated by
config.* reversion changes.
HTH (I can't live without most on all my machines, hence being prompted to give
it some love :-)
diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
--- most-5.0.0a/debian/changelog2016-07-22 01:42:16.0 +0100
+++ most-5.0.0a/debian/changelog2016-07-22 01:27:30.0 +0100
@@ -1,3 +1,16 @@
+most (5.0.0a-2.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Bump debhelper compat to 9 (Closes: #817586)
+ * Update to policy 3.9.8 (use dpkg-buildflags,
+add build-arch/build-indep targets)
+ * Fix lintian issues (above plus missing misc:depends)
+ * Don't force $CC=gcc (breaks cross-building)
+ * Use dh_autoreconf to support new architectures
+ * Reinstate quiltification from 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-5.0.0a/debian/compat 2016-07-21 22:03:05.0 +0100
@@ -1 +1 @@
-4
+9
diff -Nru most-5.0.0a/debian/control most-5.0.0a/debian/control
--- most-5.0.0a/debian/control 2016-07-22 01:42:16.0 +0100
+++ most-5.0.0a/debian/control 2016-07-21 23:56:40.0 +0100
@@ -2,12 +2,12 @@
Section: text
Priority: optional
Maintainer: Benjamin Mako Hill <m...@debian.org>
-Standards-Version: 3.9.1.0
-Build-Depends: debhelper (>=4), libslang2-dev, dpkg-dev (>= 1.16.0), chrpath
+Standards-Version: 3.9.8.0
+Build-Depends: debhelper (>=9), autotools-dev, dh-autoreconf, libslang2-dev,
chrpath
Package: most
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Pager program similar to more and less
Most is a paging program that displays, one windowful at a time, the
contents of a file on a terminal. A status line at the bottom of the
diff -Nru most-5.0.0a/debian/copyright most-5.0.0a/debian/copyright
--- most-5.0.0a/debian/copyright2016-07-22 01:42:16.0 +0100
+++ most-5.0.0a/debian/copyright2016-07-21 22:22:44.0 +0100
@@ -3,7 +3,7 @@
This package was put together by Chris Fearnley <c...@netaxs.com>,
from the GNU sources, which I obtained from
- ftp://space.mit.edu/pub/davis/most/most4.7.tar.gz.
+ ftp://space.mit.edu/pub/davis/most/
Modifications for Debian GNU/Linux Copyright (C) 1995 Chris Fearnley.
diff -Nru most-5.0.0a/debian/patches/keys.patch
most-5.0.0a/debian/patches/keys.patch
--- most-5.0.0a/debian/patches/keys.patch 1970-01-01 01:00:00.0
+0100
+++ most-5.0.0a/debian/patches/keys.patch 2016-07-21 23:48:55.0
+0100
@@ -0,0 +1,11 @@
+--- most-5.0.0a.orig/lesskeys.rc
most-5.0.0a/lesskeys.rc
+@@ -57,3 +57,8 @@ setkey bob "p"
+ setkey goto_mark "'"
+ setkey find_file "E"
+ setkey edit "v"
++setkey bob "^[[7~"
++setkey eob "^[[8~"
++setkey bob "^[OH"
++setkey eob "^[OF"
++
diff -Nru most-5.0.0a/debian/patches/lzma-support.patch
most-5.0.0a/debian/patches/lzma-support.patch
--- most-5.0.0a/debian/patches/lzma-support.patch 1970-01-01
01:00:00.0 +0100
+++ most-5.0.0a/debian/patches/lzma-support.patch 2016-07
Bug#827557: linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on nvidia jetson (4.5 works)
On 2016-07-19 11:40 -0700, Martin Michlmayr wrote: > I tracked it down to CONFIG_ARM_TEGRA_DEVFREQ which I enabled in > 4.6-1~exp2. > > With this module enabled, I see the same hang you do. Without the > module, it works. > > Interestingly, it depends on the version of u-boot used, though. > With the u-boot from Debian (i.e. a current mainline DENX u-boot), I > do not get this issue (which is why my tests before enabling the > module didn't find it). I only see it with the old u-boot from > NVIDIA. > > I brought this up upstream: > http://permalink.gmane.org/gmane.linux.ports.tegra/26941 > and the response was that if mainline u-boot works, I should use that. > > I then edited the Debian wiki to remove the portions about the old > u-boot and made it clear users have to upgrade to Debian's u-boot. > > IMHO it should be ok to tell users to use a modern mainline u-boot, > but I don't mind disabling CONFIG_ARM_TEGRA_DEVFREQ again either > if you think that's a good idea. OK. I've confirmed that. (and that programing the debian uboot needs the old R19.3 flash tools, otherwise it just makes the board totally dead). So yes, as it all works with the Debian bits and we've documented the wrinkles on https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1 I guess that's OK, although it is likely to catch some people out if they aren't reading that page. It would be good to work out the runes for flashing 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
Bug#827557: Acknowledgement (linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on nvidia jetson (4.5 works))
27 3 tegra_drm,drm_kms_helper autofs431151 2 ext4 559450 3 ecb 2191 0 crc16 1274 1 ext4 mbcache 9488 1 ext4 jbd2 95959 1 ext4 crc32c_generic 1862 4 dm_mod 98607 10 sd_mod 32241 3 ahci_tegra 3707 2 libahci_platform6494 1 ahci_tegra libahci22865 2 libahci_platform,ahci_tegra libata181479 3 libahci,libahci_platform,ahci_tegra sdhci_tegra 4932 0 sdhci_pltfm 3786 1 sdhci_tegra phy_tegra_usb 8822 0 usb_common 3659 1 phy_tegra_usb sdhci 39431 2 sdhci_pltfm,sdhci_tegra scsi_mod 188568 3 sg,libata,sd_mod r8169 79227 0 mii 4102 1 r8169 enabling ignore_loglevel we find out some more detail about where it goes wrong: [ 15.926802] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered [ 15.933496] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517) [ 15.966289] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered [ 15.973030] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517) [ 15.982022] at24 0-0056: 256 byte 24c02 EEPROM, writable, 8 bytes/write [ 16.007589] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered [ 16.014306] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517) [ OK ] Found device /dev/mmcblk1p1. [ 16.263028] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered [ 16.263440] input: tegra-hda HDMI/DP,pcm=3 as /devices/soc0/7003.hda/sound/card0/input1 [ 16.278098] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517) Starting File System Check on /dev/mmcblk1p1... [ 16.475671] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered [ 16.482357] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517) [ OK ] Started File System Check Daemon to report status. [ OK ] Found device RTL8111/8168/8411 PCI ...ess Gigabit Ethernet Controller. Sugesting that in fact it is initialising the ethernet controller that is going wrong? further back in the log we have: [4.763377] mii: module verification failed: signature and/or required key missing - tainting kernel [4.781616] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [4.792208] r8169 :01:00.0: enabling device (0140 -> 0143) [4.838932] r8169 :01:00.0 eth0: RTL8168g/8111g at 0xf087c000, 00:04:4b:25:ca:3f, XID 0c000800 IRQ 388 [4.848662] r8169 :01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] so the kernel-level ethernet init was fine. This looks like the systemd-level init. Right? I've managed to avoid systemd so far, but I guess I'm going to have to find out how it works. Why would this work OK with kernel 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: Digital signature
Bug#827557: linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on nvidia jetson (4.5 works)
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 'current testing', ( linux-image-4.6.0-1-armmp-lpae 4.6.1-1, and linux-image-armmp-lpae 4.6+74, from what's in alpha6 installer ( linux-image-4.5.0-2-armmp-lpae 4.5.3-2 and linux-image-armmp-lpae 4.5+73) causes the machine to no longer boot. I failed to keep a log, but after [3.266688] mmc0: Unknown controller version (3). You may experience problems. [3.314162] mmc1: Unknown controller version (3). You may experience problems. (which appears on successful boots too) I just get messages about failing to set up IO for a sound device (3 lots), then it hangs. On the working 4.5 boot I see: [ 15.714061] r8169 :01:00.0: firmware: failed to load rtl_nic/rtl8168g-2.fw (-2) Debian GNU/Linux stretch/sid debian-jetson ttyS0 debian-jetson login: -- I tried to turn extra debug on and failed. I am about to go on hols for 3 weeks so filing this bug as a placeholder in case anyone else has info to add. Clearly further investigation is needed to find out where it is going wrong. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#826863: gnu-fdisk: makes partition table inside partition without warning
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 the table inside the partition (as opposed to at the start of the drive). At no point in this process do you get any warning saying "are you really sure you want to do that, it's practically guaranteed to be wrong". Doing this, you end up with a partition table (reporting one DOS partition) remaining at the start of /dev/sdc, and a second partition table (reporting one ext2 partition) at the start of /dev/sdc1. Perhaps surprisingly, mounting /dev/sdc1 (with pmount sdc1) works fine (as ext2) so at no point in this process do you notice that you've made a very odd (arguably 'illegal') disk layout. It would be useful if cfdisk complained that writing a partition table into a partition, rather than onto the start of a device/block-device/file is probably a bad idea. I realise that sometimes it is entirely legitmately given a file or loopback block device, so it may be a bit tricky to get this right, but it should be able to do some sanity checks about writing the partition table inside a partition on the (parent) device, especially when that partent device already has a partition table. Obviously we don't want it moaning often about things that are OK, but a warning for partition-table-inside-partition seems like a good idea. My tests were done on a plain single-parttion DOS-format SD card. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnu-fdisk depends on: ii dpkg 1.17.27 ii install-info 5.2.0.dfsg.1-6 ii libc6 2.19-18+deb8u4 ii libncurses55.9+20140913-1+b1 pn libparted0debian1 ii libreadline6 6.3-8+b3 ii libuuid1 2.25.2-6 gnu-fdisk recommends no packages. gnu-fdisk suggests no packages.
Bug#826146: /usr/bin/uscan: uscan errors out on watchfile that is OK in stable
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 with couchdb build-deps installed, in the current couchdb (1.4.0-3), we find: $ uscan Undefined subroutine ::uscan_die called at /usr/bin/uscan line 1713. BEGIN failed--compilation aborted at /usr/bin/uscan line 1718. I assume that's a bug? Should uscan fail in this way? Even with an oldish watch file? uscan in stable with the same couchdb source (current, as it was not released in jessie) does this: $ uscan couchdb: Newer version (1.6.1) available on remote site: https://www.apache.org/dyn/closer.lua?path=/couchdb/source/1.6.1/apache-couchdb-1.6.1.tar.gz (local version is 1.4.0) couchdb: Possible OpenPGP signature found at: https://www.apache.org/dyn/closer.lua?path=/couchdb/source/1.6.1/apache-couchdb-1.6.1.tar.gz.asc. Please consider adding opts=pgpsigurlmangle=s/$/.asc/ to debian/watch. see uscan(1) for more details. Unknown or no compression used in ../apache-couchdb-1.6.1.tar.gz. at /usr/bin/mk-origtargz line 336. uscan: error: mk-origtargz --package couchdb --version 1.6.1 --compression gzip --directory .. --copyright-file debian/copyright ../apache-couchdb-1.6.1.tar.gz gave error exit status 255 So that correctly finds and downloads apache-couchdb-1.6.1.tar.gz, but then barfs because the '../apache-couchdb-1.6.1.tar.gz' is actually an HTML page listing mirrors. This is the behaviour I would expect (given that upstream have obviously changed things). The point is that the new uscan just seems to crash, which seems like a regression? -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present
Bug#824742: dpkg: Please add arm64ilp32 to cputable
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. This is only expected to be used in quite rare circumstances, but we do want to make it possible to build in a debian or debian-derived context, which needs dpkg support. Attached is a patch to provide that. It also add existing arm64 big-endian so that people can 'easily' build that too if need be. diff -Nru dpkg-1.18.1/cputable dpkg-1.18.1+nmu1/cputable --- dpkg-1.18.1/cputable2015-05-22 01:17:44.0 +0100 +++ dpkg-1.18.1+nmu1/cputable 2015-06-18 02:12:22.0 +0100 @@ -21,6 +21,8 @@ armeb armeb arm.*b 32 big armarm arm.* 32 little arm64 aarch64 aarch64 64 little +arm64beaarch64_be aarch64_be 64 big +arm64ilp32 aarch64 aarch64_ilp32 32 little +arm64ilp32be aarch64_be aarch64_be_ilp3232 big avr32 avr32 avr32 32 big hppa hppahppa.* 32 big m32r m32rm32r32 big
Bug#818616: luajit: laujit segfaults on arm64
This issue has been fixed upstream. The issue is tracked here: https://github.com/LuaJIT/LuaJIT/issues/49 and the fix is here: https://github.com/LuaJIT/LuaJIT/commit/0c6fdc1039a3a4450d366fba7af4b29de73f0dc6 The chosen fix is to allocate only low-enough memory that 47-bit pointers will work. There is a longer-term plan for the kernel to support applications asking for allocations that are guaranteed to be under particular sizes so they don't have to do this themselves by asking over and over until they get something that works for them. So the net result is that if we apply this patch, 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
Bug#563237: jed-extra: not obvious how to use new modes
I've added -e to the jed manpage so at least that is a bit more discovereable. And yes if someone wrote a jedrc.5 manpage that would be helpful. I think I'll leave this bug open for now as there is plenty of room for making the docs better. If I update the docs further I might decide that enough to close it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#820256: ITP: espr -- Building performance modelling software
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 : GPL2+ Programming Lang: C, Fortran Description : Building performance modelling software ESP-r is a multi-domain building performance simulation program. It can model heat, air, moisture light and electrical power flows at user specified spatial and temporal resolution. It comprises a central Project Manager around which are arranged support databases, a simulator, various performance assessment tools and a variety of third party applications for CAD, visualisation and report generation. This is useful scientific/building software, and the only Free Software for doing thermal modelling on GNU/Linux (until Therm get round to their proposed licence change 'sometime in the next two years'). It has taken me several years (of very sporadic efforts) to get this packaged as upstream have such a shitty build system. It has improved significantly (to merely crappy) since I first started prodding it so the effort is now much less herculean.
Bug#808626: boost1.58: ships empty binary packages on some archs
"Steve M. Robbins" <st...@sumost.ca>
> On December 28, 2015 11:38:38 AM Graham Inggs wrote:
> > On 28 December 2015 at 08:19, Steve M. Robbins <st...@sumost.ca> wrote:
> > > I understand that the lack of Boost.Context support for certain
> > > architectures will cause software using Boost.Context to fail to build on
> > > those architectures.
> > >
> > > I don't follow how the empty binary package is involved in the FTBFS.
> >
> > If the package build-depends on libboost-context-dev, it makes the
> > difference between 'Build-Attempted' and 'BD-Uninstallable'.
> Yes, true. For me, the distinction isn't important. But I appreciate that
> others might find it useful.
This is quite important and is giving people real grief on
arm64. ("Build-dep is not available" is a great deal more obvious than
a mysterious message about a missing header, which a diligent
maintainer will eventually be able to track back to this bug after
maybe an hour of poking and prodding and searching the interwebs).
Do you have a schedule for uploading a version of 1.58 with this patch
applied, 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 waiting for that to happen before uploading anew.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#816169: RFS: fake-factory/0.5.3-1
+++ 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 manpage made with help2man, > > > and not generate it for this version (and switch to generating it later)? > > > > Help2man breaks cross-building and is thus best avoided if > > possible. Adding support for a 'nodocs' profile to skip its use is one > > way to (mostly) deal with that. > > How can this be a problem for arch:all builds? Well I think it still breaks if one tries to cross-build arch:all packages, but you are right that one doesn't need to do that so it's not actually a problem there. (I jumped in, so wasn't sure if we were discussing something arch:all or not) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#816169: RFS: fake-factory/0.5.3-1
+++ 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 manpage made with help2man, > and not generate it for this version (and switch to generating it later)? Help2man breaks cross-building and is 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
Bug#819103: multistrap: Multistrap adds unrecognised option dpkg option 'foreign-architecture' to foreign chroots
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 installed in that chroot, which just says 'unrecognised option'. And indeed --foreign-architecture is not a dpkg option This option was removed in 2011 (to be replaced by the --add-foreign-architecture and --remove-foreign-architectures interface) Once the file is removed dpkg works (and knows what its foreign architectures are) I think multistrap should just stop writing that file. It is probably still correct for creating some very old chroots, but definitely wrong for jessie or later. I'll test this. config: [General] arch=arm64 cleanup=true unpack=true noauth=true bootstrap=Jessie aptsources=Jessie multiarch=arm64 armhf [Jessie] packages=locales net-tools nfs-common apt nano iputils-ping openssh-server dialog netbase systemd kmod dhcpcd5 xorg xfce4-t erminal openbox weston libgl1-mesa-dri python vim libgcc1 libc6 source=http://debian-mirror.cambridge.arm.com/debian keyring=debian-archive-keyring suite=jessie
Bug#818616: luajit: laujit segfaults on arm64
+++ 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://wookware.org/ signature.asc Description: Digital signature
Bug#818616: Info received (Bug#818616: Info received (luajit: laujit segfaults on arm64))
+++ Debian Bug Tracking System [2016-03-22 18:45 +]: Issue is tracked upstream on https://github.com/LuaJIT/LuaJIT/issues/49 There is also lots of quality info on https://collaborate.linaro.org/display/TCWG/The+State+of+LuaJit+for+ARM+64+-+March+2016 but its behind a login for no good reason 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
Bug#818616: Info received (luajit: laujit segfaults on arm64)
+++ Debian Bug Tracking System [2016-03-22 15:03 +]: OK, so the issue is indeed the 47/48 bit pointers. The mozilla jit had the exact same issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1143022 I've hacked up a patch (attached), which changes the pointer length to 48 bits, to demonstrate that the top bit is no longer masked and the segfault goes away. However this patch is not a proper fix (and crashes a bit later) because it does not properly deal with the fact that moving up one bit pushes the 4 tags further up and impinges on the fff8 'NaN' value currently used. My understanding of the code is not sufficient to work out whether everything can simply be shoved up by one bit to make this work. Can the NaN change, or is it set by the IEEE specs? Does it need to change in fact, or is it only use in the 32bit mode? And I don't properly understand the distinction between LJ_64 and LJ_GC64 which affects how things are laid out. So I'm well aware that my patch is half-a-bodge, and merely to prove that I was barking up the right tree. So the issue is nicely described in src/lj_obj.h 'Internal object tags' ** Format for 32 bit GC references (!LJ_GC64): ** ** Internal tags overlap the MSW of a number object (must be a double). ** Interpreted as a double these are special NaNs. The FPU only generates ** one type of NaN (0xfff8___). So MSWs > 0xfff8 are available ** for use as internal tags. Small negative numbers are used to shorten the ** encoding of type comparisons (reg/mem against sign-ext. 8 bit immediate). ** ** ---MSW---.---LSW--- ** primitive types | itype | | ** lightuserdata | itype | void * | (32 bit platforms) ** lightuserdata ||void *| (64 bit platforms, 47 bit pointers) ** GC objects | itype | GCRef | ** int (LJ_DUALNUM)| itype | int | ** number ---double-- ** ** Format for 64 bit GC references (LJ_GC64): ** ** The upper 13 bits must be 1 (0xfff8...) for a special NaN. The next ** 4 bits hold the internal tag. The lowest 47 bits either hold a pointer, ** a zero-extended 32 bit integer or all bits set to 1 for primitive types. ** ** --MSW--.--LSW-- ** primitive types|1..1|itype|1..1| ** GC objects/lightud |1..1|itype|---GCRef| ** int (LJ_DUALNUM) |1..1|itype|0..0|-int---| ** number double- So can we just change that to: ** The upper 12 bits must be 1 (0xfff...) for a special NaN. The next ** 4 bits hold the internal tag. The lowest 48 bits either hold a pointer, ** a zero-extended 32 bit integer or all bits set to 1 for primitive types. ? Or will that just break and we need to keep fff8, leaving only 3 bits for the tags? Ultimately this design needs to change, because ARM64 pointers are going to change to 52 bits in the future and x86 pointers will be getting bigger too as they are subject to the same pressures in new hardware. So putting the tags somewhere else would be smart, or maybe down at the bottom end if you know things are aligned to large enough boundaries? But perhaps we can make a smaller change for now to get this running? I'll file 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 fit into 47 bits, which results in chopping off the top bit of an aarch64 pointer and a segfault. This patch fixes that. Author: Wookey <woo...@debian.org> Bug-Debian: https://bugs.debian.org/818616 Bug: Forwarded: no Last-Update: 2016-03-22 --- luajit-2.1.0~beta2+dfsg.orig/src/lj_def.h +++ luajit-2.1.0~beta2+dfsg/src/lj_def.h @@ -47,7 +47,7 @@ typedef unsigned int uintptr_t; /* Various VM limits. */ #define LJ_MAX_MEM32 0x7f00 /* Max. 32 bit memory allocation. */ -#define LJ_MAX_MEM64 ((uint64_t)1<<47) /* Max. 64 bit memory allocation. */ +#define LJ_MAX_MEM64 ((uint64_t)1<<48) /* Max. 64 bit memory allocation. */ /* Max. total memory allocation. */ #define LJ_MAX_MEM (LJ_GC64 ? LJ_MAX_MEM64 : LJ_MAX_MEM32) #define LJ_MAX_ALLOC LJ_MAX_MEM /* Max. individual allocation length. */ @@ -103,9 +103,9 @@ typedef unsigned int uintptr_t; #define checki32(x) ((x) == (int32_t)(x)) #define checku32(x) ((x) == (uint32_t)(x)) #define checkptr32(x) ((uintptr_t)(x) == (uint32_t)(uintptr_t)(x)) -#define checkptr47(x) (((uint64_t)(x) >> 47) == 0) +#define checkptr48(x) (((uint64_t)(x) >> 48) == 0) #if LJ_GC64 -#define checkptrGC(x) (checkptr47((x))) +#define checkptrGC(x) (checkptr48((x))) #elif LJ_64 #define checkptrGC(x) (checkptr32((x))) #else --- luajit-2.1.0~beta2+dfsg.orig/src/lj_obj.h +++ luajit-2.1.0~beta2+dfsg/src/lj_obj.h @@ -6
Bug#818616: luajit: laujit segfaults on arm64
+++ 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 =
#2 0x004379d8 in lj_vm_cpcall () at buildvm_arm64.dasc:1182
No locals.
#3 0x0042bc3c in lua_cpcall (L=L@entry=0xb7d80378,
func=func@entry=0x404c08 , ud=ud@entry=0x0) at lj_api.c:1079
g = 0xb7d803d8
oldh = 0 '\000'
status = -1210580104
#4 0x0040406c in main (argc=1, argv=0xf518) at luajit.c:564
status =
L = 0xb7d80378
(gdb) list
71 }
72
73 static GCtab *getcurrenv(lua_State *L)
74 {
75GCfunc *fn = curr_func(L);
76return fn->c.gct == ~LJ_TFUNC ? tabref(fn->c.env) : tabref(L->env);
77 }
78
79 /* -- Miscellaneous API functions
- */
80
(gdb) p fn->c
Cannot access memory at address 0x7fffb7d80378
So that top 48th bit missing from the pointers looks wrong. Aarch64
has 48 bits, not the 47 of x86_64.
And we see things like this in the code:
lj_def.h:#define LJ_MAX_MEM64 ((uint64_t)1<<47) /* Max. 64 bit memory
allocation. */
lj_def.h:#define checkptr47(x) (((uint64_t)(x) >> 47) == 0)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#818767: cross-gcc-4.9-armhf: non-standard gcc/g++ used for build (gcc-4.9)
+++ Matthias Klose [2016-03-20 15:21 +]: > Package: cross-gcc-4.9-armhf > Version: 73 > Severity: important > Tags: sid stretch > User: debian-...@lists.debian.org > Usertags: non-standard-compiler, gcc-4.9, gcc-4.9-legacy > > This package builds with a non standard compiler version; please check > if this package can be built with the default version of gcc/g++, or > with gcc-5/g++-5. > The severity of this report is likely to be raised before the release, > so that the gcc-4.9 package can be removed for the release. Right, these cross-4.9 packages 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
Bug#818616: luajit: laujit segfaults on arm64
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 builds!) and got: $ luajit GNU gdb (Debian 7.10-1+b1) 7.10 ... Reading symbols from luajit...Reading symbols from /usr/lib/debug/.build-id/e0/82e0a7597824d1de104daad7beb534c4280041.debug...done. done. (gdb) directory src (gdb) run Starting program: /usr/bin/luajit Program received signal SIGSEGV, Segmentation fault. getcurrenv (L=0xb7d80378, L=0xb7d80378) at lj_api.c:76 76return fn->c.gct == ~LJ_TFUNC ? tabref(fn->c.env) : tabref(L->env); (gdb) info stack #0 getcurrenv (L=0xb7d80378, L=0xb7d80378) at lj_api.c:76 #1 cpcall (L=0xb7d80378, func=0x404c08 , ud=0x0) at lj_api.c:1062 #2 0x004379d8 in lj_vm_cpcall () at buildvm_arm64.dasc:1182 #3 0x0042bc3c in lua_cpcall (L=L@entry=0xb7d80378, func=func@entry=0x404c08 , ud=ud@entry=0x0) at lj_api.c:1079 #4 0x0040406c in main (argc=1, argv=0xf518) at luajit.c:564 I will investigate this further, but filing this bug for now in case it's obvious to anyone else what's up. Kernel: Linux 3.18.0-rc3 (SMP w/6 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages luajit depends on: ii libc6 2.22-3 ii libgcc1 1:5.3.1-8 ii libluajit-5.1-2 2.1.0~beta2+dfsg-1 ii libluajit-5.1-common 2.1.0~beta2+dfsg-1 luajit recommends no packages. luajit suggests no packages. -- no debconf information
Bug#818372: tex-common: Trigger fails on initial install of tex-common
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: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Running updmap-sys. This may take some time... updmap-sys failed. Output has been stored in /tmp/updmap.nSgwfadc Please include this file if you report a bug. Sometimes, not accepting conffile updates in /etc/texmf/updmap.d causes updmap-sys to fail. Please check for files with extension .dpkg-dist or .ucf-dist in this directory dpkg: error processing package tex-common (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of texlive-xetex: texlive-xetex depends on tex-common (>= 6); however: Package tex-common is not configured yet. dpkg: error processing package texlive-xetex (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of tipa: tipa depends on tex-common (>= 3); however: Package tex-common is not configured yet. dpkg: error processing package tipa (--configure): dependency problems - leaving unconfigured -- This is the log left in /tmp/updmap.nSgwfadc: updmap will read the following updmap.cfg files (in precedence order): /usr/share/texmf/web2c/updmap.cfg /usr/share/texlive/texmf-dist/web2c/updmap.cfg updmap may write changes to the following updmap.cfg file: /etc/texmf/web2c/updmap.cfg dvips output dir: "/var/lib/texmf/fonts/map/dvips/updmap" pdftex output dir: "/var/lib/texmf/fonts/map/pdftex/updmap" dvipdfmx output dir: "/var/lib/texmf/fonts/map/dvipdfmx/updmap" updmap [ERROR]: The following map file(s) couldn't be found: updmap [ERROR]: lm.map (in /usr/share/texmf/web2c/updmap.cfg) updmap [ERROR]: tipa.map (in /usr/share/texmf/web2c/updmap.cfg) updmap [ERROR]: Did you run mktexlsr? You can disable non-existent map entries using the option --syncwithtrees. - Simply re-running the install command means that it fixes itself, so this appears to be a 'fresh-install, first time' issue. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages tex-common depends on: ii dpkg 1.18.3 ii ucf 3.0031 tex-common recommends no packages. Versions of packages tex-common suggests: ii debhelper 9.20160115 Versions of packages texlive-base depends on: ii debconf [debconf-2.0] 1.5.58 ii libpaper-utils 1.1.24+nmu4 ii texlive-binaries 2015.20160222.37495-1 ii ucf3.0031 ii xdg-utils 1.1.1-1 Versions of packages texlive-base recommends: ii lmodern 2.004.5-1 Versions of packages texlive-base suggests: ii ghostscript [postscript-viewer] 9.16~dfsg-2.1 ii perl-tk 1:804.033-1+b1 pn xpdf-reader | pdf-viewer Versions of packages texlive-binaries depends on: ii dpkg 1.18.3 ii libc6 2.22-3 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.6.1-0.1 ii libgcc1 1:5.3.1-7 ii libgmp10 2:6.1.0+dfsg-2 ii libgraphite2-31.3.4-2 ii libgs99.16~dfsg-2.1 ii libharfbuzz-icu0 1.0.1-1+b1 ii libharfbuzz0b 1.0.1-1+b1 ii libice6 2:1.0.9-1+b1 ii libicu55 55.1-7 ii libkpathsea6 2015.20160222.37495-1 ii libmpfr4 3.1.3-2 ii libpaper1 1.1.24+nmu4 ii libpixman-1-0 0.33.6-1 ii libpoppler57 0.38.0-2 ii libpotrace0 1.13-2 ii libptexenc1 2015.20160222.37495-1 ii libsm62:1.2.2-1+b1 ii libstdc++65.3.1-7 ii libsynctex1 2015.20160222.37495-1 ii libtexlua52 2015.20160222.37495-1 ii libtexluajit2 2015.20160222.37495-1 ii libx11-6 2:1.6.3-1 ii libxaw7 2:1.0.13-1 ii libxext6 2:1.3.3-1 ii libxi62:1.7.5-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.11-1+b1 ii libxt61:1.1.5-1 ii libzzip-0-13 0.13.62-3 ii perl 5.22.1-7 ii t1utils 1.39-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages texlive-binaries recommends: ii python2.7.11-1 pn ruby ii texlive-base 2015.20160117-1 pn wish -- no debconf information
Bug#692344: wicd-curses dies when moving around a conference
+++ Axel Beckert [2016-03-13 02:25 +0100]: > > What I don't understand is why everyone isn't complaining about > > this. It's been affecting me at nearly every conference for 3-4 > > years... Does everyone else put up with it, or is there something odd > > about my setup 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, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#692344: wicd-curses dies when moving around a conference
+++ 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.4-4.1 is the version in Jessie. Sorry. The version I have installed is 1.7.4+tb2-1, so I did test the right one. What I don't understand is why everyone isn't complaining about this. It's been affecting me at nearly every conference for 3-4 years... Does everyone else put up with it, or is there something odd about my setup that makes it possible to get a dbus message failure? > > Can we just take out the dbus assert for this as it seems to be > > inappropriate? > > I'll have a look. Thanks for the hint. I know nothing about dbus. It seems that the author thinks this should never happen. All I know is that it happens nearly every time I move between wifi zones (on an x200 thinkpad - amybe it's specific to the wifi chipset/driver). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#692344: wicd-curses dies when moving around a conference
Issue still present in v 1.7.2.4-4.1
(rebuilt from testing/unstable source on jessie)
The line-numbers have changed from the original report in 2012 but the error
seems to be identical.
Can we just take out the dbus assert for this as it seems to be inappropriate?
Traceback (most recent call last):
File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper
return func(*args, **kargs)
File "/usr/share/wicd/curses/wicd-curses.py", line 920, in update_status
if check_for_wired(wired.GetWiredIP(''), self.set_status):
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes 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
Bug#815169: pybit-client: Broken links so buildd-test won't run
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 links in /var/lib/pybit-client.d/ are dangling. They point at /usr/share/pyshared/pybitclient when the files in question are now in /usr/lib/python2.7/dist-packages/pybitclient The attached patch fixes that (although it would be better if it could get the 'current python modules path' from the build system somehow to avoid a similar problem in the future, or when there is a new python version and that versionned path changes...). I don't know how to do that, and this does at least fix it for now. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#755840: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4
> I created this patch that call autoreconf to updates the autotool > files during the build > I tested it on ppc64el and it worked Really? I have hit a number of problems from dh-autoreconfing this package. Made more complicated since you filed the bug because two other FTBFS issues have come up due to external changes (jdk8), so more patches are needed. But dh-autoreconfing alone breaks the build. Details are in #791232, but in summary: 1) The dh_autoreconf_clean is in the wrong place (2nd build fails because autottols changes are cleaned up before make clean tidies up the build dir) 2) the debian patches patch the .in files and configure not the .am and .ac files so after autoreconfing the changes are lost or (in one case) wrong. Fixes so far: * Made 010_sdl_example.diff patch examples/Makefile.am to say that lookat depend on sdl-viewer.cpp instead of the noni-existant lookat.cpp. * Made 010_sdl_example.diff patch examples/Makefile.am to say that 'lookat' should be linked against libopenvrml as well as libopenvrml-gl (how did this ever build? Is it different on arm64? seems unlikely) * removed the 020_rebootstrap patch fro the series as that was essentially patching in the results of a dh-autoreconf * Fixed 030_doc_makefile to patch Makefile.am, not Makefile.in (patching both is pointless now that there is a dh-autoreconf, and breaks the clean rule because makefile.in got regenerated and quilt can't unpatch it) * Change 040_Update-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, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#791232: Info received (openvrml NMU)
+++ 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, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#791232: openvrml NMU
+++ 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 > involvement with openvrml aside from trying to keep it in (and others > like it) in the archive when it seems like there is a userbase. Yeah. I was expecting just to apply a simple dh_autoreconf fix to support new arches, but it's led down this rabbithole... If you simply skip the two patches 010_sdl_example.diff and 020_rebootstrap.diff (which just seem to try and replace sdl-viewer with lookat, and then deal with that fallout in autotools), then the build gets a bit further but now fails with ~/bin/bash ../libtool --tag=CXX --mode=link g++ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -g -Os -I/usr/lib/jvm/default-java//include -I/usr/lib/jvm/default-java//include/linux -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -L/usr/lib/aarch64-linux-gnu -lSDL -lGLU -lfontconfig -lfreetype -fPIE -pie -Wl,-z,relro -Wl,-z,now -o sdl-viewer sdl_viewer-sdl_viewer.o ../src/libopenvrml-gl/libopenvrml-gl.la -lboost_system libtool: link: g++ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -g -Os -I/usr/lib/jvm/default-java//include -I/usr/lib/jvm/default-java//include/linux -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/sdl-viewer sdl_viewer-sdl_viewer.o -L/usr/lib/aarch64-linux-gnu -lSDL -lGLU -lfontconfig /usr/lib/aarch64-linux-gnu/libfreetype.so ../src/libopenvrml-gl/.libs/libopenvrml-gl.so -lboost_system -pthread /usr/bin/aarch64-linux-gnu-ld.bfd.real: sdl_viewer-sdl_viewer.o: undefined reference to symbol '_ZN8openvrml19x3d_vrml_media_typeE' //home/wookey/NMU/pending/openvrml-0.18.9/src/libopenvrml/.libs/libopenvrml.so.9: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:451: recipe for target 'sdl-viewer' failed~ It would be helpful to know from the maintainer what this s/sdl-viewer/lookat/ stuff is/was for. Given that lookat.cpp was removed a decade ago according to the changelog I am confused. It looks like maybe the patch was intended to use the new sdl-viewer code, but have the binary still come out as 'lookat', possibly because that's what users were used to? But in that case making a link at the end (after the build) would be much simpler. Re the above error: _ZN8openvrml19x3d_vrml_media_typeE does exist in libopenvrml.so.9.1.1, the code being in browser.cpp, and adding ../src/libopenvrml/libopenvrml.la to the build line makes it work. OK. So there turn out to be several issues due to the debian patches patching the Makefile and Makefile.in, and configure, either instead of the Makefile.am, and configure.ac, or doing the two differently! autoreconfing, brings these issues to the fore. So. I have now 1) Made 010_sdl_example.diff patch examples/Makefile.am to say that lookat depend on sdl-viewer.cpp instead of the noni-existant lookat.cpp. 2) Made 010_sdl_example.diff patch examples/Makefile.am to say that 'lookat' should be linked against libopenvrml as well as libopenvrml-gl (how did this ever build? Is it different on arm64? seems unlikely) 3) removed the 020_rebootstrap patch fro the series as that was essentially patching in the results of a dh-autoreconf 4) Fixed 030_doc_makefile to patch Makefile.am, not Makefile.in (patching both is pointless now that there is a dh-autoreconf, and breaks the clean rule because makefile.in got regenerated and quilt can't unpatch it) 5) Change 040_Update-path-of-libjvm-and-arch-name.diff to patch configure.ac instead of generated configure This gets me further than before but the examples are still failing to build with a missing boost symbol (now on pretty-print rather than sdl-viewer/lookat): /bin/bash ../libtool --tag=CXX --mode=link g++ -g -Os -I/usr/lib/jvm/default-java//include -I/usr/lib/jvm/default-java//include/linux -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIE -pie -Wl,-z,relro -Wl,-z,now -o pretty-print pretty_print-pretty_print.o ../src/libopenvrml/libopenvrml.la -lboost_system Adding -lboost_thread fixes that. But now I am left with a question (how did this ever build before? Oh, no, not that question :-) ): where is teh right place to fix this? that -lboost_system comes from configure. There is nothing special in example/Makefile.am: pretty_print_SOURCES = pretty_print.cpp pretty_print_CPPFLAGS = \ -I$(top_builddir)/src/libopenvrml \ -I$(top_srcdir)/src/libopenvrml pretty_print_LDADD = $(top_builddir)/src/libopenvrml/libopenvrml.la In the exsiting amd64 build log the smae command: /bin/bash ../libtool --tag=CXX --mode=link g++ -g -Os -I/usr/lib/jvm/default-java//include
Bug#814254: meshlab: clicking on 'online documentation' gives 403 error
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. 1. Server: meshlab.sourceforge.net 2. URL path: /wiki/ 3. Error notes: NONE 4. Error type: 403 5. Request method: GET 6. Request query string: NONE 7. Time: 2016-02-09 14:48:46 UTC (1455029326) Reporting this problem: The problem you have encountered is with a project web site hosted by SourceForge.net. This issue should be reported to the SourceForge.net-hosted project (not to SourceForge.net). If this is a severe or recurring/persistent problem, please do one of the following, and provide the error text (numbered 1 through 7, above): Contact the project via their designated support resources. Contact the project administrators of this project via email (see the upper right-hand corner of the Project Summary page for their usernames) at user-n...@users.sourceforge.net If you are a maintainer of this web content, please refer to the Site Documentation regarding web services for further assistance. NOTE: As of 2008-10-23 directory index display has been disabled by default. This option may be re-enabled by the project by placing a file with the name ".htaccess" with this line: Options +Indexes Which is a sad state of afairs. If authors are going to foist online docs on us, they could at least make sure they remain available whilst the package is in stable distros. This is really something to pass on to upstream, and illustrates why actual internal documentation is still a useful thing, never mind cases when net acess is not available or expensive.
Bug#791232: openvrml NMU
OK. I just tested the fixes in openvrml for building on new arches (arm64, ppc64le, ppc64) And I included the java fixes so that it would build. But now neither of us can upload our NMU due to this g++-5 ABI issue. The maintainer seems to be MIA (Sam - are you out there?) so I'd very much like to just upload something if we can. If we were really keen we'd do a library transition just to be on the safe side. Does anyone know what's involved with that? openvrml is kind of old and unloved these days, but I would expect some software to be using it as it's a file format still supported by some things. libg3d, meshlab and openscenegraph claim vrml support for example? Did they drop it, do we not build the osg-vrml plugin, perhaps they have internal code for reading? These are questions the maintainer should be able to help answer. I've tried a build but it failed 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 hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
> what do you mean by that? Source packages like cross-gcc-4.9-armhf > *do* have cross-arch build-deps. Were you talking about missing > support in britney to properly transition source packages with > cross-arch build-deps? Is there a bug about this open somewhere? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770925 Stalled since debconf. Although that's actually the wanna-build code, rather than britney. We've been waiting for w-b to be implemented before we could sensibly worry about britney. But time is getting short if we are to have this working this release. Aurelien - can we help move this along? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#812562: ITP: jscience -- Java science library (algebra, matrices, physical models)
+++ 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 be much work. I don't actually know any Java to speak of, so if anything difficult comes up I'll have to ask for help :-) I've already hit an issue with the jscience -> geoapi -> jscience bootstrap. (jscience builds agains the geoapi.jar it comes with, but not against the libgeoapi-java package I've made, and I don't understand what's wrong). I'll send a more detailed mail when I have a little time to explain the problem. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#812562: ITP: jscience -- Java science library (algebra, matrices, physical models)
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 Description : Java science library (algebra, matrices, physical models) JScience library provides a comprehensive Java library for the scientific community. It contains the following modules: . * Units of Measurement services. * A coordinates module compliant with OGC/ISO specifications for the development and deployment of geographic applications. * A rigourous mapping of mathematical structures (e.g. Group, Ring, Field, VectorSpace ) to Java interfaces. * A linear algebra module, which includes a first parameterized matrix class capable of resolving linear system of equations involving any kind of elements. * A functions module for symbolic calculations and analysis. * Support for exact or arbitrary precision measurements * Support for Standard, Relativistic, High-Energy, Quantum and Natural physical models. * A monetary module for precision-guaranteed calculations and currencies conversions. I am packaging this because it is needed by the current release of caveconverter for calculating hulls. And it seems like quite a generally useful java package. This package depends recursively(!) on geoapi (http://www.geoapi.org/ ). Presumably that recursiveness is not a good enough reason to just put geoapi in the same source package, and build them together, so I should file an ITP for that too (and ideally put in staged builds so they can easily be built)? There was #24 filed about this in 2009, and closed in 2011.
Bug#812563: ITP: geoapi -- Set of Java interfaces for geospatial applications
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: Java Description : Set of Java interfaces for geospatial applications geoapi is a set of java bindings provided for geospatial applications by the GeoAPI project. They are neutral, interface-only APIs derived from OGC/ISO Standards. . The interfaces developed by the GeoAPI project include many of the data structures and manipulation methods needed for geographic information system applications. GeoAPI 3.0 defines a core set of interfaces for metadata handling, for geodetic referencing, projection and conversion, and is a standard of the Open Geospatial Consortium (OGC). . The GeoAPI interfaces closely follow the ISO 19100 series standards: ISO 19115: Metadata, ISO 19111: Referencing by coordinates, ISO 19123: Coverage. GeoAPI provides an interpretation and adaptation of these standards to match the expectations of Java programmers. This is being packaged as it is closely tied to jscience. jscience needs geoapi to build (org.opengis.*) geoapi need javax.measure.utils from jscience to build.
Bug#759445: unmass: diff for NMU version 0.9-3.1
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://wookware.org/ diff -u unmass-0.9/debian/changelog unmass-0.9/debian/changelog --- unmass-0.9/debian/changelog +++ unmass-0.9/debian/changelog @@ -1,3 +1,11 @@ +unmass (0.9-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Use dh-autoreconf to support new architectures +(Closes: #759445 #735386 #759451) + + -- Wookey <woo...@debian.org> Fri, 22 Jan 2016 15:35:53 + + unmass (0.9-3) unstable; urgency=low * Small fix, add missing comments. (Closes: #456108) @@ -5,7 +13,7 @@ * Update email address. -- Gürkan Sengün <gur...@phys.ethz.ch> Mon, 28 Apr 2008 11:01:46 +0200 - + unmass (0.9-2) unstable; urgency=low * Fix clean target in debian/rules. (Closes: #442754) diff -u unmass-0.9/debian/control unmass-0.9/debian/control --- unmass-0.9/debian/control +++ unmass-0.9/debian/control @@ -2,7 +2,7 @@ Section: utils Priority: optional Maintainer: Gürkan Sengün <gur...@phys.ethz.ch> -Build-Depends: debhelper (>= 5) +Build-Depends: debhelper (>= 5), dh-autoreconf Homepage: http://mirex.mypage.sk/index.php?selected=1#Unmass Standards-Version: 3.7.3 diff -u unmass-0.9/debian/rules unmass-0.9/debian/rules --- unmass-0.9/debian/rules +++ unmass-0.9/debian/rules @@ -13,6 +13,7 @@ configure: configure-stamp configure-stamp: dh_testdir + dh_autoreconf cd kdev && ./configure --prefix=/usr touch configure-stamp @@ -29,6 +30,7 @@ rm -f build-stamp configure-stamp [ ! -f kdev/Makefile ] || $(MAKE) -C kdev clean -rm -f kdev/config.log kdev/Makefile kdev/src/Makefile kdev/config.status kdev/config.h kdev/libtool + dh_autoreconf_clean dh_clean install: build only in patch2: unchanged: --- unmass-0.9.orig/debian/autoreconf +++ unmass-0.9/debian/autoreconf @@ -0,0 +1 @@ +kdev \ No newline at end of file signature.asc Description: Digital signature
