Bug#948587: iipimage-server: Unsupported image type jpeg2000
Control: fixed -1 1.1-2 Native support for JPEG2000 with OpenJPEG was only added in 1.1-2 (you would need kakadu before that).
Bug#948186:
Control: tags -1 patch -D_Python_CONFIG:FILEPATH=/usr/bin/x86_64-linux-gnu-python3.7-config \ -DPython_EXECUTABLE:FILEPATH=/usr/bin/python3.7 \ should read: -D_Python_CONFIG:FILEPATH=/usr/bin/x86_64-linux-gnu-python3.8-config \ -DPython_EXECUTABLE:FILEPATH=/usr/bin/python3.8 \ Maybe double-check if PYTHON_PREFER_VERSION is a more robust alternative? Also make sure to update d/control: X-Python3-Version: 3.7 into X-Python3-Version: 3.8
Bug#948862: ITP: jpeg-xl -- A reference implementation of JPEG XL
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: jpeg-xl Version : 0.1 Upstream Author : JPEG (ISO/IEC SC29/WG1) * URL : https://gitlab.com/wg1/jpeg-xl * License : Apache 2 Programming Lang: C++ Description : A reference implementation of JPEG XL JPEG XL was designed for two main requirements: . * high quality: visually lossless at reasonable bitrates; * decoding speed: multithreaded decoding should be able to reach around 400 Megapixel/s on large images. . These goals apply to various types of images, including HDR content, whose support is made possible by full-precision (float32) computations and extensive support of color spaces and transfer functions. . High performance is achieved by designing the format with careful consideration of memory bandwidth usage and ease of SIMD/GPU implementation.
Bug#948486: Remove : debian/ThirdPartyDownloads/mongoose-3.8.tgz
Source: Orthanc Version: 1.5.4+dfsg-1 Severity: minor I believe orthanc on Debian switch away from mongoose web server. So please cleanup source package and remove debian/ThirdPartyDownloads/mongoose-3.8.tgz Thanks
Bug#944370: uscan: Should specify explicit core.abbrev=6
Package: devscripts Version: 2.19.5+deb10u1 Severity: normal Dear Maintainer, I realized that uscan does not expect user to have custom git config, eg: $ tail -2 ~/.gitconfig [core] abbrev = 12 This leads to the following libjpeg package: https://tracker.debian.org/pkg/libjpeg Where: 0.0~git20190821.87636f3b26b4-1 was generated, but it is expected to be truncated to only 6 chars. See for instance the report on the watch page: https://qa.debian.org/developer.php?login=ma...@debian.org 0.0~git20190821.87636f3 Someone should be able to pass in the proper core.abbrev value in uscan source code. Thanks -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.19.7 ii fakeroot 1.23-1 ii file 1:5.35-4+deb10u1 ii gnupg 2.2.12-1+deb10u1 ii gpgv 2.2.12-1+deb10u1 ii libc6 2.28-10 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20180523.0-1 ii libmoo-perl 2.003004-2 ii libwww-perl 6.36-2 ii patchutils0.3.4-2 ii perl 5.28.1-6 ii python3 3.7.3-1 ii sensible-utils0.0.12 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 1.8.2 pn at ii curl7.64.0-4 ii dctrl-tools 2.24-3 pn debian-keyring ii dput-ng [dput] 1.25+deb10u1 ii equivs 2.2.0 ii libdistro-info-perl 0.21 ii libdpkg-perl1.19.7 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn libgitlab-api-v4-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-2 pn libsoap-lite-perl pn libstring-shellquote-perl ii libtry-tiny-perl0.30-1 ii liburi-perl 1.76-1 pn licensecheck ii lintian 2.15.0 ii man-db 2.8.5-2 ii patch 2.7.6-3+deb10u1 ii python3-apt 1.8.4 ii python3-debian 0.1.35 pn python3-magic ii python3-requests2.21.0-1 pn python3-unidiff ii python3-xdg 0.25-5 pn strace ii unzip 6.0-23+deb10u1 ii wget1.20.1-1.1 ii xz-utils5.2.4-1 Versions of packages devscripts suggests: pn adequate pn autopkgtest pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20180807cvs-1 ii build-essential 12.6 pn check-all-the-things pn cvs-buildpackage ii debhelper12.1.1 pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime pn gnuplot pn how-can-i-help ii libauthen-sasl-perl 2.1600-1 pn libdbd-pg-perl ii libfile-desktopentry-perl0.22-1 pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3000-2 pn libyaml-syck-perl ii mailutils [mailx]1:3.5-3 pn mozilla-devscripts ii mutt 1.10.1-2.1 ii openssh-client [ssh-client] 1:7.9p1-10+deb10u1 pn piuparts pn postgresql-client ii quilt0.65-3 pn ratt pn reprotest pn svn-buildpackage pn w3m -- no debconf information
Bug#943765: libvtkgdcm3-dev: missing Breaks+Replaces: libvtkgdcm2-dev
On Tue, Oct 29, 2019 at 3:39 PM Andreas Beckmann wrote: > > Followup-For: Bug #943765 > > and furthermore libgdcm3-dev is missing breaks+Replaces: libgdcm2-dev > > Preparing to unpack .../libgdcm3-dev_3.0.3-1~exp1_amd64.deb ... > Unpacking libgdcm3-dev (3.0.3-1~exp1) ... > dpkg: error processing archive > /var/cache/apt/archives/libgdcm3-dev_3.0.3-1~exp1_amd64.deb (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libgdcmCommon.so', which is > also in package libgdcm2-dev 2.8.8-9+b1 > Errors were encountered while processing: >/var/cache/apt/archives/libgdcm3-dev_3.0.3-1~exp1_amd64.deb I believe this is the right time to finally kill libgdcm2-dev. Just like what was done for dcmtk, time is now to releave a libgdcm-dev package and get rid of this issue forever. As a side note libgdcm3-dev, should really be libgdcm3.0-dev, since SOVERSION is 3.0. I belive this is mandated in the dev reference handbook. 2cts
Bug#942496: nmu: libopenvdb5.2_5.2.0-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu I messed up the openvdb binary upload on amd64 (build with older libopenexr23) So please schedule a binNMU: nmu libopenvdb5.2_5.2.0-6 . amd64 . -m 'Rebuild against libopenexr24 to correct dependency' Thanks
Bug#939553: openjpeg2: CVE-2018-21010
Hugo, On Mon, Oct 7, 2019 at 10:16 AM Hugo Lefeuvre wrote: > > Hi Salvatore, Matthieu, > s/Matthieu/Mathieu/ > I'm going to bump unstable to 2.3.1, this should address the four > currently open issues. > > Matthieu, if you want to double check the debdiff before upload, let me know. > :) I was about to upload 2.3.1 this week, so this should be just fine. Pay attention to 2.3.0-3 in your dch that's all I care really. I'll import in git after the upload since it is ready. > I might prepare a small jessie update for CVE-2018-21010. I had a quick > look, and so far it seems that this vulnerability would allow significant > heap write overflow. Hard to exploit, but this is enough for a DLA, in my > opinion. > > Regarding stretch and buster, I don't think this is worth a DSA, but we > could fix this via a point update later on. > good > cheers, > Hugo > > -- > Hugo Lefeuvre (hle)|www.owl.eu.com > RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD > ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
Bug#849426: python3 pending
Control: tags -1 pending See: https://ftp-master.debian.org/new/openvdb_5.2.0-6.html
Bug#900279:
fixed 900279 1.1-2 thanks Forgot to update d/changelog when uploading 1.1.
Bug#928794: iipimage FTCBFS: abuses AC_CHECK_FILE
fixed 928794 1.1-2 thanks Should be fixed in latest upstream.
Bug#941448: ITP: hw-probe -- Hardware probe and system info collection tool
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: hw-probe Version : 1.4 Upstream Author : Andrey Ponomarenko * URL : https://github.com/linuxhw/hw-probe/ * License : LGPL 2.1 Programming Lang: Perl Description : Hardware probe and system info collection tool A tool to probe for hardware and upload results to the Linux hardware database https://linux-hardware.org
Bug#939371: lshw: Hyundai displayed in memory instead of Hynix
Package: lshw Version: 02.18.85-0.1 Severity: normal I believe there is a typo in the manufacturer list since I can see: $ sudo lshw -C memory -numeric -sanitize | tail -25 *-memory description: System Memory physical id: e slot: System board or motherboard size: 6GiB *-bank:0 description: DIMM DDR3 Synchronous 1333 MHz (0.8 ns) product: HMT325U6CFR8C-H9 vendor: Hyundai physical id: 0 serial: [REMOVED] slot: DIMM0 size: 2GiB width: 64 bits clock: 1333MHz (0.8ns) *-bank:1 description: DIMM DDR3 Synchronous 1333 MHz (0.8 ns) product: HMT351U6BFR8C-H9 vendor: Hyundai physical id: 1 serial: [REMOVED] slot: DIMM1 size: 4GiB width: 64 bits clock: 1333MHz (0.8ns) It would be nice to display Hynix here instead. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-rc1 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lshw depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 Versions of packages lshw recommends: ii pciutils 1:3.5.2-1 ii usbutils 1:010-3 lshw suggests no packages. -- no debconf information
Bug#935955: Fwd: epubcheck manpage error
Package: epubcheck Version: 4.0.1-2 Hello! "Modes and versions supported: -mode opf -v 2.0// For single OPF file validation (EPUB 2) -mode opf -v 3.0 // For single OPF file validation (EPUB 3) -mode xhtml -v 2.0 // For single XHTML file validation (EPUB 2) -mode xhtml -v 3.0 // For single XHTML file validation (EPUB 3) -mode svg -v 2.0// For single SVG file validation (EPUB 2) -mode svg -v 3.0// For single SVG file validation (EPUB 3) -mode nav -v 3.0// For single 'Navigation Document' validation -mode mo -v 3.0// For single 'Media Overlays' validation -mode exp // For validating expanded EPUB archives This tool also accepts the following flags: -save = saves the epub created from the expanded epub (-mode exp) -quiet = no message sent to stdout, only errors in stderr -out = output an assessment XML document in file (experimental) -? or -help = displays this help message" ===> " Modes and versions supported: -mode opf -v 2.0// For single OPF file validation (EPUB 2) -mode opf -v 3.0// For single OPF file validation (EPUB 3) -mode xhtml -v 2.0 // For single XHTML file validation (EPUB 2) -mode xhtml -v 3.0 // For single XHTML file validation (EPUB 3) -mode svg -v 2.0// For single SVG file validation (EPUB 2) -mode svg -v 3.0// For single SVG file validation (EPUB 3) -mode nav -v 3.0// For single 'Navigation Document' validation -mode mo -v 3.0// For single 'Media Overlays' validation -mode exp // For validating expanded EPUB archives This tool also accepts the following flags: -save = saves the epub created from the expanded epub (-mode exp) -quiet= no message sent to stdout, only errors in stderr -out= output an assessment XML document in file (experimental) -? or -help = displays this help message" I added .nf and .fi? lxc
Bug#935879: Update to use CharLS 2.0
Source: dcmtk Version: 3.6.4-2.1 Since resolution of bug #923433, dcmtk is now built with the convinient charls copy. It would make sense in the long term to switch to the system charls (debian package). This has been accepted as feature by upstream: * https://support.dcmtk.org/redmine/issues/344#note-5 The implementation strategy for DCMTK decided by the team will be to keep the internal CharLS version available in DCMTK (for platforms where CharLS is not available as an external library or compilers that do not support C++11/C++14) but provide an option to compile DCMTK either with the internal or with an external CharLS library. For the external CharLS library, we will primarily aim at supporting CharLS 2.x. This does require several modification of the build system, though, and these will only be implemented after DCMTK 3.6.5.
Bug#933664: Acknowledgement (qemu-system-ppc: Initialization of device VGA failed: failed to find romfile "vgabios-stdvga.bin")
Turns out this is simple as: $ sudo apt-get install qemu-system-x86 I do not have recommends: $ cat /etc/apt/apt.conf.d/99local APT::Install-Recommends "false"; APT::Install-Suggests "false"; Sorry for the noise
Bug#933664: qemu-system-ppc: Initialization of device VGA failed: failed to find romfile "vgabios-stdvga.bin"
Package: qemu-system-ppc Version: 1:3.1+dfsg-8~deb10u1 Severity: normal Dear Maintainer, I tried booting my shiny new kernel: $ file g4/vmlinux g4/vmlinux: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, BuildID[sha1]=aec02dbaa89aea93d2cab980a6328b97de8d9820, with debug_info, not stripped Using: $ qemu-system-ppc -m 1024 -kernel g4/vmlinux -cdrom /tmp/mini.iso -boot d qemu-system-ppc: Initialization of device VGA failed: failed to find romfile "vgabios-stdvga.bin" It would be nice to fix the installation path. Thanks, The iso file is coming from the tarball: http://ftp.ports.debian.org/debian-ports/pool-powerpc/main/d/debian-installer/debian-installer-images_20190702_powerpc.tar.gz -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-system-ppc depends on: ii libaio1 0.3.112-3 ii libasound2 1.1.8-1 ii libbluetooth3 5.50-1 ii libbrlapi0.65.6-10 ii libc6 2.28-10 ii libcacard0 1:2.6.1-1 ii libcapstone34.0.1+really+3.0.5-1 ii libepoxy0 1.5.3-0.1 ii libfdt1 1.4.7-3 ii libgbm1 18.3.6-2 ii libgcc1 1:8.3.0-6 ii libglib2.0-02.58.3-2 ii libgnutls30 3.6.7-4 ii libibverbs1 22.1-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libncursesw66.1+20181013-2 ii libnettle6 3.4.1-1 ii libnuma12.0.12-1 ii libpixman-1-0 0.36.0-1 ii libpng16-16 1.6.36-6 ii librdmacm1 22.1-1 ii libsasl2-2 2.1.27+dfsg-1 ii libseccomp2 2.3.3-4 ii libspice-server10.14.0-1.3 ii libtinfo6 6.1+20181013-2 ii libusb-1.0-02:1.0.22-2 ii libusbredirparser1 0.8.0-1 ii libvdeplug2 2.3.2+r586-2.2 ii libvirglrenderer0 0.7.0-2 ii openbios-ppc1.1.git20181001-1 ii openhackware0.4.1+git-20140423.c559da7c-4.1 ii qemu-slof 20180702+dfsg-1 ii qemu-system-common 1:3.1+dfsg-8~deb10u1 ii qemu-system-data1:3.1+dfsg-8~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages qemu-system-ppc recommends: pn ipxe-qemu pn qemu-system-gui pn qemu-utils pn seabios Versions of packages qemu-system-ppc suggests: pn qemu-block-extra pn samba pn vde2 -- no debconf information
Bug#932304: do_IRQ: 0.37 No irq handler for vector
Control: tags -1 fixed-upstream patch pending OK, I found it: b7107a67f0d1 x86/irq: Handle spurious interrupt after shutdown gracefully
Bug#932304: do_IRQ: 0.37 No irq handler for vector
Package: src:linux Followup-For: Bug #932304 Installing a kernel from git/master show that the symptoms are now gone. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#932304: do_IRQ: 0.37 No irq handler for vector
On Wed, Jul 17, 2019 at 10:51 PM Miguel A. Vallejo wrote: > But for me this problem is triggered by the Arduino IDE. Interesting. The system bell only starts when I open my xfce session. I'll continue digging in the audio direction. Thanks
Bug#932304: Fwd: do_IRQ: 0.37 No irq handler for vector
False positive. Turns out commit e9d0ba506ea8661a7d91d67e04abe69a535b6048 is present in debian linux kernel on buster. -- Forwarded message - From: Kai-Heng Feng Date: Wed, Jul 17, 2019 at 4:13 PM Subject: Re: do_IRQ: 0.37 No irq handler for vector To: Mathieu Malaterre Hi Mathieu, at 22:05, Mathieu Malaterre wrote: > Hi Kai, > > I just stumble upon your post: > > https://lore.kernel.org/lkml/e5521441-be1e-4a43-ab5c-0e91165e0...@canonical.com/ > > Would you be kind and tell me what is the actual commit -stable which > was needed ? commit e9d0ba506ea8661a7d91d67e04abe69a535b6048 Author: Daniel Drake Date: Thu Sep 27 15:47:33 2018 -0500 PCI: Reprogram bridge prefetch registers on resume I think this affect many PCI devices that facilitate MSI-X Kai-Heng
Bug#932304: Acknowledgement (do_IRQ: 0.37 No irq handler for vector)
Could that be: https://bugzilla.kernel.org/show_bug.cgi?id=198855 but it says that it should be closed in 4.17.3
Bug#932304: do_IRQ: 0.37 No irq handler for vector
Package: src:linux Version: 4.19.37-5 Severity: normal hi there, I've updated my desktop to buster and I am getting a flood of messages such as: [ 920.728347] do_IRQ: 0.37 No irq handler for vector So far I've solved the symptoms with: # rmmod pcspkr Would be nice to have a fix. I'll try newer kernel(s) and hopefully find out what is the root issue. -- Package-specific info: ** Version: Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=dc3d1d5a-c1bf-4867-b16a-5c0542b5b258 ro quiet ** Not tainted ** Kernel log: [ 920.728347] do_IRQ: 0.37 No irq handler for vector [ 926.852416] do_IRQ: 0.37 No irq handler for vector [ 927.852687] do_IRQ: 0.37 No irq handler for vector [ 928.852963] do_IRQ: 0.37 No irq handler for vector [ 929.853244] do_IRQ: 0.37 No irq handler for vector [ 930.853526] do_IRQ: 0.37 No irq handler for vector [ 931.853800] do_IRQ: 0.37 No irq handler for vector [ 932.854058] do_IRQ: 0.37 No irq handler for vector [ 933.854334] do_IRQ: 0.37 No irq handler for vector [ 934.854611] do_IRQ: 0.37 No irq handler for vector [ 935.854883] do_IRQ: 0.37 No irq handler for vector [ 941.976398] do_IRQ: 0.37 No irq handler for vector [ 942.976650] do_IRQ: 0.37 No irq handler for vector [ 943.976903] do_IRQ: 0.37 No irq handler for vector [ 944.977164] do_IRQ: 0.37 No irq handler for vector [ 945.977444] do_IRQ: 0.37 No irq handler for vector [ 946.977713] do_IRQ: 0.37 No irq handler for vector [ 947.977969] do_IRQ: 0.37 No irq handler for vector [ 948.978243] do_IRQ: 0.37 No irq handler for vector [ 949.978503] do_IRQ: 0.37 No irq handler for vector [ 950.978758] do_IRQ: 0.37 No irq handler for vector [ 957.045238] do_IRQ: 0.37 No irq handler for vector [ 958.045506] do_IRQ: 0.37 No irq handler for vector [ 959.045762] do_IRQ: 0.37 No irq handler for vector [ 960.046021] do_IRQ: 0.37 No irq handler for vector [ 961.046282] do_IRQ: 0.37 No irq handler for vector [ 962.046555] do_IRQ: 0.37 No irq handler for vector [ 963.046822] do_IRQ: 0.37 No irq handler for vector [ 964.047087] do_IRQ: 0.37 No irq handler for vector [ 965.047362] do_IRQ: 0.37 No irq handler for vector [ 966.047631] do_IRQ: 0.37 No irq handler for vector [ 972.113909] do_IRQ: 0.37 No irq handler for vector [ 973.114152] do_IRQ: 0.37 No irq handler for vector [ 974.114465] do_IRQ: 0.37 No irq handler for vector [ 975.114747] do_IRQ: 0.37 No irq handler for vector [ 976.115016] do_IRQ: 0.37 No irq handler for vector [ 977.115293] do_IRQ: 0.37 No irq handler for vector [ 978.115565] do_IRQ: 0.37 No irq handler for vector [ 979.115835] do_IRQ: 0.37 No irq handler for vector [ 980.116110] do_IRQ: 0.37 No irq handler for vector [ 981.116387] do_IRQ: 0.37 No irq handler for vector [ 987.185152] do_IRQ: 0.37 No irq handler for vector [ 988.185417] do_IRQ: 0.37 No irq handler for vector [ 989.185687] do_IRQ: 0.37 No irq handler for vector [ 990.185927] do_IRQ: 0.37 No irq handler for vector [ 991.186174] do_IRQ: 0.37 No irq handler for vector [ 992.186426] do_IRQ: 0.37 No irq handler for vector [ 993.186690] do_IRQ: 0.37 No irq handler for vector [ 994.186955] do_IRQ: 0.37 No irq handler for vector [ 995.187231] do_IRQ: 0.37 No irq handler for vector [ 996.187498] do_IRQ: 0.37 No irq handler for vector [ 1002.253174] do_IRQ: 0.37 No irq handler for vector [ 1003.253440] do_IRQ: 0.37 No irq handler for vector [ 1004.253699] do_IRQ: 0.37 No irq handler for vector [ 1005.253979] do_IRQ: 0.37 No irq handler for vector [ 1006.254243] do_IRQ: 0.37 No irq handler for vector [ 1007.254512] do_IRQ: 0.37 No irq handler for vector [ 1008.254773] do_IRQ: 0.37 No irq handler for vector [ 1009.255050] do_IRQ: 0.37 No irq handler for vector [ 1010.255332] do_IRQ: 0.37 No irq handler for vector [ 1011.255594] do_IRQ: 0.37 No irq handler for vector [ 1017.376392] do_IRQ: 0.37 No irq handler for vector [ 1018.376661] do_IRQ: 0.37 No irq handler for vector [ 1019.376937] do_IRQ: 0.37 No irq handler for vector [ 1020.377200] do_IRQ: 0.37 No irq handler for vector [ 1021.377490] do_IRQ: 0.37 No irq handler for vector [ 1022.30] do_IRQ: 0.37 No irq handler for vector [ 1023.378040] do_IRQ: 0.37 No irq handler for vector [ 1024.378302] do_IRQ: 0.37 No irq handler for vector [ 1025.378578] do_IRQ: 0.37 No irq handler for vector [ 1026.378921] do_IRQ: 0.37 No irq handler for vector [ 1032.445226] do_IRQ: 0.37 No irq handler for vector [ 1033.445557] do_IRQ: 0.37 No irq handler for vector [ 1034.445860] do_IRQ: 0.37 No irq handler for vector [ 1035.446235] do_IRQ: 0.37 No irq handler for vector [ 1036.446507] do_IRQ: 0.37 No irq handler for vector [ 1037.446784] do_IRQ: 0.37 No irq handler for vector [ 1038.447078] do_IRQ: 0.37 No irq handler for vector [ 1039.447435] do_IRQ: 0.37 No irq handler for vector [ 1040.447683] do_IRQ: 0.37 No irq handler for
Bug#887526: new upstream version available v4.8.1
I suspect the actual bug is rather switching from: https://github.com/mrward/nuget to the official source now: https://github.com/NuGet/NuGet.Client This may be quite a bit of work, or package maintainer has a good reason to stick to the nuget version from mrward.
Bug#923433: 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156)
On Mon, May 20, 2019 at 4:50 PM Mathieu Malaterre wrote: > > Gert, > > On Mon, May 20, 2019 at 3:31 PM Andreas Tille wrote: > > > > Hint, hint, hint: Feel free to do an NMU / team upload of RC buggy > > package. > > What's your opinion on this ? Revert to charls 1.x as suggested or > investigated actual regression ? debdiff attached. I've uploaded to delayed/10. Let me know of any issue. Thanks charls923433.debdiff Description: Binary data
Bug#923433: 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156)
Gert, On Mon, May 20, 2019 at 3:31 PM Andreas Tille wrote: > > Hint, hint, hint: Feel free to do an NMU / team upload of RC buggy > package. What's your opinion on this ? Revert to charls 1.x as suggested or investigated actual regression ?
Bug#923433: 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156)
Control: severity -1 grave Justification: Debian patches are introducing regression compared to upstream Steps: $ cd /tmp/ $ wget ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk364/bin/dcmtk-3.6.4-linux-x86_64-static.tar.bz2 $ tar xf dcmtk-3.6.4-linux-x86_64-static.tar.bz2 $ cd dcmtk-3.6.4-linux-x86_64-static/bin/ $ curl https://raw.githubusercontent.com/neurolabusc/dcm_qa/master/In/Orientation/ax/axasc35/MR.1.3.12.2.1107.5.2.32.35131.2014031012493950715786673 > foo.dcm $ chmod +x dcmdjpls dcmcjpls $ ./dcmcjpls foo.dcm jpegls.dcm $ ./dcmdjpls jpegls.dcm raw.dcm $ gdcminfo --md5sum foo.dcm | grep md5 md5sum: 8680e6fdccd8635581a3d21d131e95dd $ gdcminfo --md5sum raw.dcm | grep md5 md5sum: 8680e6fdccd8635581a3d21d131e95dd Please remove Debian/CharLS patches and use the convenient charls copy. The Debian policy does not make it a strong requirement anyway.
Bug#916864: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
On Fri, May 3, 2019 at 1:15 PM John Paul Adrian Glaubitz wrote: > > Hi! > > On 5/3/19 10:53 AM, Frank Scheiner wrote: > >> Could you reply to the Debian bug number so that I can get a clean > >> view of the issue. > > > > Sure. > > > >> Then simply please post the output of: > >> > >> (1) yaboot/ofpath (the one that works) > > > > `` > > root@powermac-g5:~# ofpath /dev/sda2 > > /ht@0,f200/pci@9/k2-sata-root@c/@0/@0:2 > > ``` > > > >> (2) grub-ofpathname (specify if this with my patch) > > > > The `grub-ofpathname` used in the following has your patch included: > > > > ``` > > root@powermac-g5:~# grub-ofpathname /dev/sda2 > > /ht@0,f200/pci@9/k2-sata-root@c/@0:2 > > ``` > > For reference, here's the same with GRUB 2.04~rc1 on one of the IBM POWER > machines we have at Debian (running in big-endian mode): > > root@redpanda:~# ./yaboot-test/usr/sbin/ofpath /dev/sda2 > /vdevice/v-scsi@3004/@1:2 > root@redpanda:~# ./grub/grub-ofpathname /dev/sda2 > /vdevice/v-scsi@3004/disk@8100:b > root@redpanda:~# > > So, I'm not sure that Mathieu's patch would be enough to mimic the behavior > of Yaboot's ofpath whose sources can be found at: > > > http://git.ozlabs.org/?p=yaboot.git;a=blob;f=ybin/ofpath;h=aff5583457e645f878c01e1084e59689cee94b88;hb=HEAD > > I will have a look at ofpath vs. grub-ofpathname once I am finished with > the cd-boot changes to debian-installer/debian-cd unless someone else > is faster. > > > Using that with `,\grub` added in the NVRAM var `boot-device` does not > > boot the machine: > > > > ``` > > root@powermac-g5:~# nvsetenv boot-device > > "/ht@0,f200/pci@9/k2-sata-root@c/@0:2,\grub" > > root@powermac-g5:~# echo $? > > 0 > > root@powermac-g5:~# nvram --print-config="boot-device" > > /ht@0,f200/pci@9/k2-sata-root@c/@0:2,\grub > > > > ## Reboot into OF > > > > 0 > boot load-size=0 adler32=1 > > > > LOAD-SIZE is too small > > > > ok > > 0 > > > ``` > > You actually don't need to prove it doesn't work, I believe you anyway ;). > > FWIW, where did you install grub-ofpathname from? I don't actually see it > in the grub-common package on powerpc/ppc64: > > root@redpanda:~# dpkg -L grub-common |grep ofpath > root@redpanda:~# dpkg -L grub2-common |grep ofpath > root@redpanda:~# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916830
Bug#928375: Announce - swig-4.0.0
Source: swig Would be super nice to have swig 4 in Debian. Thanks -- Forwarded message - *** ANNOUNCE: SWIG 4.0.0 (27 Apr 2019) *** http://www.swig.org We're pleased to announce SWIG-4.0.0, the latest SWIG release. What is SWIG? = SWIG is a software development tool that reads C/C++ header files and generates the wrapper code needed to make C and C++ code accessible from other programming languages including Perl, Python, Tcl, Ruby, PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D, Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in the form of XML. Major applications of SWIG include generation of scripting language extension modules, rapid prototyping, testing, and user interface development for large C/C++ systems. Release Notes = Detailed release notes are available with the release and are also published on the SWIG web site at http://swig.org/release.html. Availability The release is available for download on Sourceforge at http://prdownloads.sourceforge.net/swig/swig-4.0.0.tar.gz A Windows version is also available at http://prdownloads.sourceforge.net/swig/swigwin-4.0.0.zip Please report problems with this release to the swig-devel mailing list, details at http://www.swig.org/mail.html. --- The SWIG Developers
Bug#916864: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
Frank, On Fri, May 3, 2019 at 9:27 AM Frank Scheiner wrote: > On 5/3/19 08:19, Mathieu Malaterre wrote: > > Dear grub developers, > > > > We are looking to extend grub-ofpathname so that it also handles > > PowerPC system such as PowerMac with a limited OpenFirmware > > implementation[1]. In particular the following patch has been found to > > produce an output compatible with such system [2]. > > > > While we understand that components of a path are in this general form: > > > > @: > > > > We also do understand that name can be safely omitted as the device is > > actually getting located by > > its address. Therefore, these two paths refer to the same device: > > > > /pci@f400/ata-6@d/disk@0:b > > > > /@f400/@d/@0:b > > > > However for the PowerMac we tested it on, only the second form has > > been found to be accepted. > > On which machine did this work? I wrote earlier today that the modified > grub-ofpathname does not work on a 11,2 type G5, so the patch seems to > be not generic enough. Sorry about that. I must say there are way too many emails to read. Could you reply to the Debian bug number so that I can get a clean view of the issue. Then simply please post the output of: (1) yaboot/ofpath (the one that works) (2) grub-ofpathname (specify if this with my patch) from your 11,2 type G5. Thanks
Bug#926842: Format: DIB (Microsoft Windows 3.X Packed Device-Independent Bitmap)
Source: file Version: 1:5.30-1+deb9u2 It would be super nice to handle DIB (Microsoft Windows 3.X Packed Device-Independent Bitmap) file format. Right now here is what I see: $ file 01.bmp 61.bmp 01.bmp: dBase IV DBT of \300\377.DBF, blocks size 0, block length 4096, next free block index 40, next free block 1347247444, next used block 2022922061 61.bmp: dBase IV DBT of \300\377.DBF, blocks size 0, block length 4096, next free block index 40, next free block 1800967823, next used block 1956287382 While: $ identify -verbose 01.bmp Image: 01.bmp Format: DIB (Microsoft Windows 3.X Packed Device-Independent Bitmap) Class: PseudoClass Geometry: 64x64+0+0 Units: PixelsPerCentimeter Type: Grayscale Endianess: Undefined Colorspace: sRGB Depth: 8-bit Channel depth: gray: 8-bit Channel statistics: Pixels: 4096 Gray: min: 0 (0) max: 255 (1) mean: 21.8655 (0.085747) standard deviation: 34.6758 (0.135984) kurtosis: 3.16922 skewness: 1.75718 entropy: 0.593336 Colors: 163 Histogram: 1954: ( 0, 0, 0) #00 gray(0) 113: ( 1, 1, 1) #010101 gray(1) 112: ( 2, 2, 2) #020202 gray(2) 109: ( 3, 3, 3) #030303 gray(3) 99: ( 4, 4, 4) #040404 gray(4) 74: ( 5, 5, 5) #050505 gray(5) 80: ( 6, 6, 6) #060606 gray(6) 66: ( 7, 7, 7) #070707 gray(7) 51: ( 8, 8, 8) #080808 gray(8) 39: ( 9, 9, 9) #090909 gray(9) 26: ( 10, 10, 10) #0A0A0A gray(10) 21: ( 11, 11, 11) #0B0B0B gray(11) 22: ( 12, 12, 12) #0C0C0C gray(12) 19: ( 13, 13, 13) #0D0D0D gray(13) 6: ( 14, 14, 14) #0E0E0E gray(14) 13: ( 15, 15, 15) #0F0F0F gray(15) 10: ( 16, 16, 16) #101010 gray(16) 13: ( 17, 17, 17) #11 gray(17) 5: ( 18, 18, 18) #121212 gray(18) 4: ( 19, 19, 19) #131313 gray(19) 3: ( 20, 20, 20) #141414 gray(20) 10: ( 21, 21, 21) #151515 gray(21) 6: ( 22, 22, 22) #161616 gray(22) 8: ( 23, 23, 23) #171717 gray(23) 5: ( 24, 24, 24) #181818 gray(24) 8: ( 25, 25, 25) #191919 gray(25) 6: ( 26, 26, 26) #1A1A1A gray(26) 11: ( 27, 27, 27) #1B1B1B gray(27) 10: ( 28, 28, 28) #1C1C1C gray(28) 11: ( 29, 29, 29) #1D1D1D gray(29) 10: ( 30, 30, 30) #1E1E1E gray(30) 8: ( 31, 31, 31) #1F1F1F gray(31) 9: ( 32, 32, 32) #202020 gray(32) 11: ( 33, 33, 33) #212121 gray(33) 8: ( 34, 34, 34) #22 gray(34) 10: ( 35, 35, 35) #232323 gray(35) 10: ( 36, 36, 36) #242424 gray(36) 16: ( 37, 37, 37) #252525 gray(37) 15: ( 38, 38, 38) #262626 gray(38) 13: ( 39, 39, 39) #272727 gray(39) 14: ( 40, 40, 40) #282828 gray(40) 18: ( 41, 41, 41) #292929 gray(41) 13: ( 42, 42, 42) #2A2A2A gray(42) 18: ( 43, 43, 43) #2B2B2B gray(43) 20: ( 44, 44, 44) #2C2C2C gray(44) 16: ( 45, 45, 45) #2D2D2D gray(45) 21: ( 46, 46, 46) #2E2E2E gray(46) 33: ( 47, 47, 47) #2F2F2F gray(47) 19: ( 48, 48, 48) #303030 gray(48) 20: ( 49, 49, 49) #313131 gray(49) 22: ( 50, 50, 50) #323232 gray(50) 27: ( 51, 51, 51) #33 gray(51) 23: ( 52, 52, 52) #343434 gray(52) 28: ( 53, 53, 53) #353535 gray(53) 22: ( 54, 54, 54) #363636 gray(54) 18: ( 55, 55, 55) #373737 gray(55) 25: ( 56, 56, 56) #383838 gray(56) 30: ( 57, 57, 57) #393939 gray(57) 23: ( 58, 58, 58) #3A3A3A gray(58) 15: ( 59, 59, 59) #3B3B3B gray(59) 19: ( 60, 60, 60) #3C3C3C gray(60) 20: ( 61, 61, 61) #3D3D3D gray(61) 12: ( 62, 62, 62) #3E3E3E gray(62) 10: ( 63, 63, 63) #3F3F3F gray(63) 22: ( 64, 64, 64) #404040 gray(64) 15: ( 65, 65, 65) #414141 gray(65) 19: ( 66, 66, 66) #424242 gray(66) 13: ( 67, 67, 67) #434343 gray(67) 11: ( 68, 68, 68) #44 gray(68) 17: ( 69, 69, 69) #454545 gray(69) 16: ( 70, 70, 70) #464646 gray(70) 16: ( 71, 71, 71) #474747 gray(71) 14: ( 72, 72, 72) #484848 gray(72) 12: ( 73, 73, 73) #494949 gray(73) 14: ( 74, 74, 74) #4A4A4A gray(74) 10: ( 75, 75, 75) #4B4B4B gray(75) 6: ( 76, 76, 76) #4C4C4C gray(76) 12: ( 77, 77, 77) #4D4D4D gray(77) 14: ( 78, 78, 78) #4E4E4E gray(78) 12: ( 79, 79, 79) #4F4F4F gray(79) 10: ( 80, 80, 80) #505050 gray(80) 11: ( 81, 81, 81) #515151 gray(81) 13: ( 82, 82, 82) #525252 gray(82) 7: ( 83, 83, 83) #535353 gray(83) 13: ( 84, 84, 84) #545454 gray(84) 15: ( 85, 85, 85) #55 gray(85) 11: ( 86, 86, 86) #565656 gray(86) 14: ( 87, 87, 87) #575757 gray(87) 13: ( 88, 88, 88) #585858 gray(88) 9: ( 89, 89, 89) #595959 gray(89) 12: ( 90, 90, 90) #5A5A5A gray(90) 9: ( 91, 91, 91)
Bug#924924: Release 1.79.2
Source: docbook-xsl It seems like there is a new release: 1.79.2 : https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2 This means the d/watch file should not refer to the old sf.net page anymore: https://sourceforge.net/projects/docbook/files/docbook-xsl/
Bug#924385: RM: esajpip -- ROM; RC buggy, unmaintained
Package: ftp.debian.org Severity: normal esajpip has FTBFS in the past without any activity from the maintainer (me) for about a month (#921780). I've actually lost interest in this package and given that it has a very low popcon, I do not believe it is of any use for Debian user. So I think it should be removed from Debian. Thanks
Bug#921780: esajpip: FTBFS (LaTeX error)
Control: tags -1 wontfix Hi, On Sat, Feb 9, 2019 at 1:18 AM Santiago Vila wrote: > ! ==> Fatal error occurred, no output PDF file produced! I cannot also reproduce this Latex issue. Are you sure there has not been a broken latex package upload recently ? In any case esajpip should migrate back to testing hopefully.
Bug#923750: gdcm: FTBFS in buster/sid
Control: severity -1 important On Tue, Mar 5, 2019 at 8:24 AM Mathieu Malaterre wrote: > > On Tue, Mar 5, 2019 at 1:21 AM Santiago Vila wrote: > > make[2]: *** [Makefile:6: refman.pdf] Error 1 > > That must be a regression in one of the tex (sid) packages. I can > build the pdf documentation just fine from my jessie Debian system: > > https://sourceforge.net/projects/gdcm/files/gdcm%202.x/GDCM%202.8.9/gdcm-2.8.9.pdf > > I'll check pdf build ASAP. Odd gdcm arch-indep does not FTBFS from buildd: https://buildd.debian.org/status/fetch.php?pkg=gdcm=all=2.8.8-7=1552044907=0 lowering severity.
Bug#923433: 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156)
Control: severity -1 important Control: tags -1 patch Turns out that every single DICOM instance that I tried seems to produce the exact same SEGFAULT. Running in valgrind show something like this for me (*). I would suggest the following trivial patch to have a stable DCMTK+JPEGLS encoder in buster: $ cat debian/patches/series 01_dcmtk_3.6.0-1.patch #02_system_charls.patch 03_datadic_install.patch 04_Fixed-OFoptional-by-introducing-OFalign.patch 05_performance.patch 07_dont_export_all_executables.patch 08_remove_system_processor.patch #09_charls-2.0.patch I suspect there is little value in using CharLS 2.0 for DCMTK until upstream decide to make the move. Thanks for consideration, (*) ==3030== Invalid write of size 1 ==3030==at 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156) ==3030==by 0x5106554: EncoderStrategy::AppendToBitStream(int, int) (encoderstrategy.h:87) ==3030==by 0x5116F95: EncodeMappedValue (scan.h:347) ==3030==by 0x5116F95: DoRegular (scan.h:271) ==3030==by 0x5116F95: JlsCodec, EncoderStrategy>::DoLine(unsigned short*) (scan.h:660) ==3030==by 0x5117169: JlsCodec, EncoderStrategy>::DoScan() (scan.h:739) ==3030==by 0x5117502: JlsCodec, EncoderStrategy>::EncodeScan(std::unique_ptr >, ByteStreamInfo&, void*) (scan.h:820) ==3030==by 0x5127BBD: JpegImageDataSegment::Serialize(JpegStreamWriter&) (jpegstreamreader.cpp:81) ==3030==by 0x5128C90: JpegStreamWriter::Write(ByteStreamInfo const&) (jpegstreamwriter.cpp:65) ==3030==by 0x5100C29: JpegLsEncodeStream(ByteStreamInfo, unsigned long&, ByteStreamInfo, JlsParameters const&, char*) (interface.cpp:136) ==3030==by 0x5100D65: JpegLsEncode (interface.cpp:218) ==3030==by 0x4875A20: DJLSEncoderBase::compressRawFrame(unsigned char const*, unsigned short, unsigned short, unsigned short, unsigned short, unsigned sho rt, OFString const&, DcmPixelSequence*, OFList&, unsigned long&, DJLSCodecParameter const*) const (djcodece.cc:676) ==3030==by 0x34B60D1E920A2A2: ??? ==3030==by 0x148147302459A4FF: ??? ==3030== Address 0x1fff001000 is not stack'd, malloc'd or (recently) free'd ==3030== ==3030== ==3030== Process terminating with default action of signal 11 (SIGSEGV) ==3030== Access not within mapped region at address 0x1FFF001000 ==3030==at 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156) ==3030==by 0x5106554: EncoderStrategy::AppendToBitStream(int, int) (encoderstrategy.h:87) ==3030==by 0x5116F95: EncodeMappedValue (scan.h:347) ==3030==by 0x5116F95: DoRegular (scan.h:271) ==3030==by 0x5116F95: JlsCodec, EncoderStrategy>::DoLine(unsigned short*) (scan.h:660) ==3030==by 0x5117169: JlsCodec, EncoderStrategy>::DoScan() (scan.h:739) ==3030==by 0x5117502: JlsCodec, EncoderStrategy>::EncodeScan(std::unique_ptr >, ByteStreamInfo&, void*) (scan.h:820)
Bug#923750: gdcm: FTBFS in buster/sid
On Tue, Mar 5, 2019 at 1:21 AM Santiago Vila wrote: > make[2]: *** [Makefile:6: refman.pdf] Error 1 That must be a regression in one of the tex (sid) packages. I can build the pdf documentation just fine from my jessie Debian system: https://sourceforge.net/projects/gdcm/files/gdcm%202.x/GDCM%202.8.9/gdcm-2.8.9.pdf I'll check pdf build ASAP. -M
Bug#923433: EncoderStrategy::Flush (this=0x5555557452f0) at ./src/encoderstrategy.h:156
Package: dcmtk
Version: 3.6.4-2
It seems there is a regression in the JPEG-LS/CharLS encoder at least
for some files. dcmcrle / dcmcjpeg seems to be ok. GDCM is able to
compress it:
$ gdcmconv --jpegls /tmp/foo.dcm /tmp/o.dcm
Steps:
$ cd /tmp
$ curl
https://raw.githubusercontent.com/neurolabusc/dcm_qa/master/In/Orientation/ax/axasc35/MR.1.3.12.2.1107.5.2.32.35131.2014031012493950715786673
> foo.dcm
$ gdb dcmcjpls
(gdb) r /tmp/foo.dcm /tmp/o.dcm
...
Starting program: /usr/bin/dcmcjpls /tmp/foo.dcm /tmp/o.dcm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x776dd3b3 in EncoderStrategy::Flush (this=0x557452f0) at
./src/encoderstrategy.h:156
156 *_position = static_cast(_bitBuffer >> 24);
(gdb) bt full
#0 0x776dd3b3 in EncoderStrategy::Flush (this=0x557452f0)
at ./src/encoderstrategy.h:156
i = 0
i =
#1 0x776dd555 in EncoderStrategy::AppendToBitStream
(this=0x557452f0, bits=93, bitCount=) at
./src/encoderstrategy.h:87
mask =
__PRETTY_FUNCTION__ = "void
EncoderStrategy::AppendToBitStream(int32_t, int32_t)"
#2 0x776edfb8 in JlsCodec, EncoderStrategy>::EncodeMappedValue (limit=64,
mappedError=,
k=, this=0x557452f0) at ./src/losslesstraits.h:112
highbits =
highbits =
#3 JlsCodec,
EncoderStrategy>::DoRegular (pred=, x=112,
Qs=, this=0x557452f0)
at ./src/scan.h:271
ctx = @0x55745ad4: {A = 1573, B = -7, C = -1, N = 8}
k =
Px = 159
ErrVal = -47
sign =
__PRETTY_FUNCTION__ = "typename TRAITS::SAMPLE
JlsCodec::DoRegular(int32_t, int32_t, int32_t,
EncoderStrategy*) [with TRAITS = LosslessTraitsT; STRATEGY = EncoderStrategy; typename "...
sign =
ctx =
k =
Px =
ErrVal =
#4 JlsCodec,
EncoderStrategy>::DoLine (this=this@entry=0x557452f0) at
./src/scan.h:660
Ra =
Rc =
Qs =
index = 162
Rb = 59
Rd = 79
#5 0x776ee16a in JlsCodec, EncoderStrategy>::DoScan (this=this@entry=0x557452f0)
at /usr/include/c++/8/bits/stl_vector.h:930
component =
line =
pixelstride = 388
components = 1
vectmp = std::vector of length 776, capacity 776 = {0, 0, 25,
21, 18, 23, 23, 22, 25, 23, 27, 41, 69, 73, 93, 78, 72, 43, 231, 216,
92, 88, 128, 87,
85, 54, 50, 22, 15, 26, 37, 32, 31, 33, 43, 60, 16, 36, 33,
53, 24, 43, 49, 88, 47, 49, 47, 121, 100, 124, 174, 100, 90, 47, 53,
39, 15, 20, 20,
20, 20, 20, 25, 15, 20, 0, 24, 23, 25, 29, 22, 16, 33, 30,
24, 19, 54, 44, 126, 171, 191, 83, 87, 47, 30, 113, 51, 37, 131, 232,
53, 39, 33, 26,
52, 43, 26, 18, 24, 43, 28, 30, 22, 32, 29, 65, 57, 55, 85,
49, 68, 80, 39, 97, 162, 92, 72, 85, 57, 39, 21, 19, 20, 15, 30, 24,
32, 22, 16, 0,
Bug#782093: For more details on chapter file syntax...broken link
Control: forwarded -1 https://github.com/gpac/gpac/issues/1208 On Fri, Feb 15, 2019 at 12:52 PM Reinhard Tartler wrote: > > Control: tag -1 upstream > > Hi Mathieu, > > Sorry for the late reply. > > This is an upstream issue and needs to be dealt as such. Can you please visit > https://github.com/gpac/gpac/issues/new and report back the issue number you > got? I'd be happy to add the necessary linking so that we are notified when > this gets resolved upstream. > > Thanks for your understanding. > > > On Tue, Apr 7, 2015 at 3:57 PM Mathieu Malaterre wrote: >> >> Package: gpac >> Version: 0.5.0+svn5324~dfsg1-1+b3 >> Severity: minor >> >> The man page point to broken link: >> >> [...] >>-chap chap_file >> adds chapter information contained in chap_file to >> movie. For more details on chapter file syntax, cf >> http://gpac.sourceforge.net/auth_mp4box.php. >> [...] >> >> While: >> >> $ HEAD http://gpac.sourceforge.net/auth_mp4box.php >> 404 Not Found >> Connection: close >> Date: Tue, 07 Apr 2015 19:54:39 GMT >> Via: 1.1 varnish >> Age: 0 >> Server: Apache/2.2.15 (CentOS) >> Vary: Host >> Content-Length: 1677 >> Content-Type: text/html >> Client-Date: Tue, 07 Apr 2015 19:54:40 GMT >> Client-Peer: 216.34.181.96:80 >> Client-Response-Num: 1 >> X-Varnish: 838453151 >> >> ___ >> pkg-multimedia-maintainers mailing list >> pkg-multimedia-maintain...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers > > > > -- > regards, > Reinhard
Bug#782125: Support atom Xtra
Control: forwarded -1 https://github.com/gpac/gpac/issues/1207 On Fri, Feb 15, 2019 at 12:49 PM Reinhard Tartler wrote: > > Control: tag -1 upstream > > Hi Mathieu, > > Sorry for the late reply. > > This is an upstream issue and needs to be dealt as such. Can you please visit > https://github.com/gpac/gpac/issues/new and report back the issue number you > got? I'd be happy to add the necessary linking so that we are notified when > this gets resolved upstream. > > Thanks for your understanding. > > On Wed, Apr 8, 2015 at 5:03 AM Mathieu Malaterre wrote: >> >> Package: gpac >> Version: 0.5.0+svn5324~dfsg1-1+b3 >> Severity: minor >> >> It would be nice to support atom Xtra. Currenly it dumps as: >> >> >> >> >> >> >> Reference implementation is at: >> http://code.google.com/p/mp4v2/issues/detail?id=113 >> > -- > regards, > Reinhard
Bug#919867: Could not find JS function 'encodeURIComponent'
Source: youtube-dl
Version: 2019.01.16-1
Tags: upstream fixed-upstream
Forwarded: https://github.com/rg3/youtube-dl/issues/18873
Looks like youtube-dl does not handle some videos from youtube:
$ youtube-dl --verbose https://youtu.be/v_B3qkp4nO4
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', 'https://youtu.be/v_B3qkp4nO4']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2019.01.16
[debug] Python version 3.5.3 (CPython) -
Linux-4.18.0-0.bpo.1-amd64-x86_64-with-debian-9.6
[debug] exe versions: ffmpeg 3.2.12-1, ffprobe 3.2.12-1, phantomjs
2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[youtube] v_B3qkp4nO4: Downloading webpage
[youtube] v_B3qkp4nO4: Downloading video info webpage
[youtube] {18} signature length 42.44, html5 player vfl-jbnrr
[youtube] v_B3qkp4nO4: Downloading player
https://www.youtube.com/yts/jsbin/player_ias-vfl-jbnrr/en_US/base.js
ERROR: Signature extraction failed: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1232, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1140, in _extract_signature_function
res = self._parse_sig_js(code)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1207, in _parse_sig_js
initial_function = jsi.extract_function(funcname)
File "/usr/lib/python3/dist-packages/youtube_dl/jsinterp.py", line
245, in extract_function
raise ExtractorError('Could not find JS function %r' % funcname)
youtube_dl.utils.ExtractorError: Could not find JS function
'encodeURIComponent'; please report this issue on
https://yt-dl.org/bug . Make sure you are using the latest version;
see https://yt-dl.org/update on how to update. Be sure to call
youtube-dl with the --verbose flag and include its complete output.
(caused by ExtractorError("Could not find JS function
'encodeURIComponent'; please report this issue on
https://yt-dl.org/bug . Make sure you are using the latest version;
see https://yt-dl.org/update on how to update. Be sure to call
youtube-dl with the --verbose flag and include its complete
output.",)); please report this issue on https://yt-dl.org/bug . Make
sure you are using the latest version; see https://yt-dl.org/update
on how to update. Be sure to call youtube-dl with the --verbose flag
and include its complete output.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1232, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1140, in _extract_signature_function
res = self._parse_sig_js(code)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1207, in _parse_sig_js
initial_function = jsi.extract_function(funcname)
File "/usr/lib/python3/dist-packages/youtube_dl/jsinterp.py", line
245, in extract_function
raise ExtractorError('Could not find JS function %r' % funcname)
Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"
Hi, On Fri, Jan 11, 2019 at 5:29 PM wrote: > > I don't think I've seen anything like this - maybe when I was trying to > get Boehm-GC working? I'll note that I haven't really poked ppc32 *or* > Linux either. I'm considering cc'ing another person who knows more > ppc32/linux than I do. I remember that sgen vs boehm was an issue in the past. I'll try to go through the diff and check what was the old patch doing. > Reading the code, (and the fact that the stack trace is truncated...) > CreatePointerOperatorsTable is in between a bunch of other methods like > it. Unlike say, CreateStandardOperatorsTable, it *does* have nulls in > it, but you'd see issue son other platforms is this was problematic, > no? Feels almost like a JIT issue or memory (like heap corruption?) > > Wait, I just got another email as I was writing this one. SIGILL? It > looks like it just jumped to the middle of nowhere. (which on AIX, I'd > get disturbingly often because 0x0 is both mapped and RWX, which is > explicitly invalid on PPC - for that I slapped down explicit null > checking, which isn't the problem here) > > -Original Message- > From: Jo Shields > Sent: January 11, 2019 11:34 AM > To: Mathieu Malaterre > Cc: 918...@bugs.debian.org; Mark Cave-Ayland ; > Calvin Buckley > Subject: Re: Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown > target CPU" > > > On 11/01/2019 10:22, Mathieu Malaterre wrote: > > However the build failed for me later on, reporting a failure to find > > 'mcs' (*). My G4 is rather slow so let me try again to check there are > > no other build failure later on. Mark do you have a faster ppc machine > > ? > > > > (*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then > > :; else chmod -R +w > > /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi > > cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make > > --no-print-directory -s NO_DIR_CHECK=1 > > PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 > > ' CC='gcc' all-profiles > > mkdir -p -- build/deps > > make[7]: mcs: Command not found > > > The class library needs a C# compiler, so first it checks whether you > have one in $PATH it can use. It is normal that you wouldn't have one > (and it would likely be too out of date anyway, and get rejected) > > > > make[7]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 127 > > *** The runtime 'mono' doesn't appear to be usable. > > *** Trying the 'monolite-linux/1051600014' directory. > > > Now it's looking at the bootstrap compiler bundled into the source > package, and checking the version on it. > > > > Unhandled Exception: > > System.NullReferenceException: Object reference not set to an instance > > of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: > > Object reference not set to an instance of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > > Here's a real problem - the runtime is totally screwing up the basic > compiler check. Looping in Calvin (HI CALVIN!) - does the above look > familiar, in any of your PowerPC tinkering? > > > > make[9]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 1 > > *** The contents of your 'monolite-linux/1051600014' directory may be > > out-of-date > > *** You may want to try 'make get-monolite-latest' > > > The build system gives up as it can't find a viable compiler to use. > >
Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"
On Fri, Jan 11, 2019 at 4:34 PM Jo Shields wrote: > > > On 11/01/2019 10:22, Mathieu Malaterre wrote: > > However the build failed for me later on, reporting a failure to find > > 'mcs' (*). My G4 is rather slow so let me try again to check there are > > no other build failure later on. Mark do you have a faster ppc machine > > ? > > > > (*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then > > :; else chmod -R +w > > /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi > > cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make > > --no-print-directory -s NO_DIR_CHECK=1 > > PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 > > ' CC='gcc' all-profiles > > mkdir -p -- build/deps > > make[7]: mcs: Command not found > > > The class library needs a C# compiler, so first it checks whether you > have one in $PATH it can use. It is normal that you wouldn't have one > (and it would likely be too out of date anyway, and get rejected) > > > > make[7]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 127 > > *** The runtime 'mono' doesn't appear to be usable. > > *** Trying the 'monolite-linux/1051600014' directory. > > > Now it's looking at the bootstrap compiler bundled into the source > package, and checking the version on it. > > > > Unhandled Exception: > > System.NullReferenceException: Object reference not set to an instance > > of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: > > Object reference not set to an instance of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > > Here's a real problem - the runtime is totally screwing up the basic > compiler check. Looping in Calvin (HI CALVIN!) - does the above look > familiar, in any of your PowerPC tinkering? > > > > make[9]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 1 > > *** The contents of your 'monolite-linux/1051600014' directory may be > > out-of-date > > *** You may want to try 'make get-monolite-latest' > > > The build system gives up as it can't find a viable compiler to use. > Ah right now I understand what is going on. For some reason, rebuilding it from scratch, I get now a much complete backtrace: if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then :; else chmod -R +w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 ' CC='gcc' all-profiles make[7]: mcs: Command not found make[7]: *** [build/profiles/basic.make:118: build/deps/basic-profile-check.exe] Error 127 *** The runtime 'mono' doesn't appear to be usable. *** Trying the 'monolite-linux/1051600014' directory. Stacktrace: /proc/self/maps: 0010-00103000 r-xp 00:00 0 [vdso] 00211000-003de000 r-xp 08:03 1654 /lib/powerpc-linux-gnu/libc-2.28.so 003de000-003fc000 ---p 001cd000 08:03 1654 /lib/powerpc-linux-gnu/libc-2.28.so 003fc000-00401000 r--p 001db000 08:03 1654 /lib/powerpc-linux-gnu/libc-2.28.so 00401000-00402000 rw-p 001e 08:03 1654 /lib/powerpc-linux-gnu/libc-2.28.so 00402000-00405000 rw-p 00:00 0 00415000-0043a000 r-xp 08:03 1813 /lib/powerpc-linux-gnu/libpthread-2.28.so 0043a000-00454000 ---p 00025000 08:03 1813 /lib/powerpc-linux-gnu/libpthread-2.28.so 00454000-00455000 r--p 0002f000 08:03 1813 /lib/powerpc-linux-gnu/libpthread-2.28.so 00455000-00456000 rw-p 0003 08:03 1813 /lib/powerpc-linux-gnu/libpthread-2.28.so 00456000-00458000 rw-p 00:00 0 00468000-0046b000 r-xp 08:03 1758 /lib/powerpc-linux-gnu/libdl-2.28.so 0046b000-00487000 ---p 3000 08:03 1758 /lib/powerpc-linux-gnu/libdl-2.28.so 00487000-00488000 r--p f000 08:03 1758 /lib/powerpc-linux-gnu/libdl-2.28.so 00488000-00489000 rw-p 0001 08:03 1758 /lib/powerpc-linux-gnu/libdl-2.28.so 00499000-004a2000 r-xp 08:03 1822 /lib/powerpc-linux-gnu/librt-2.28.so 004a2000-004b8000 ---p 9000 08:03 1822 /lib/powerpc-linux-gnu/librt-2.28.so 004b8000-004b9000 r--p f000 08:03 1822 /lib/powerpc-linux-gnu/librt-2.28.so 004b9000-004ba000 rw-p 0001 08:03 1822 /lib/powerpc-linux-gnu/librt-2.28.so 004ca000-005a r-xp 08:03 1764 /lib/powerpc-linux-gnu/libm-2.28.so 005a-005b5000 ---p 000d6000 08:03 1764 /lib/powerpc-linux-gnu/libm-2
Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"
On Fri, Jan 11, 2019 at 4:11 PM Jo Shields wrote:
>
> Hi Mathieu,
>
>
> Are you in a position to test a patch? In theory
> https://github.com/mono/boringssl/commit/59b78d07a483450a5d2a1c06b83f04a1e64ba68a
> is sufficient to make it work. I don't want to throw another build at
> the buildd until this gets through into testing.
Starring at it it should work. I was about to submit:
@@ -85,6 +85,8 @@ extern "C" {
#define OPENSSL_ARM
#elif defined(__PPC64__) || defined(__powerpc64__)
#define OPENSSL_64_BIT
+#elif defined(__PPC__) && !defined(__PPC64__)
+#define OPENSSL_32_BIT
#elif defined(__mips__) && !defined(__LP64__)
#define OPENSSL_32_BIT
#define OPENSSL_MIPS
Since:
$ powerpc-linux-gnu-gcc -m32 -dM -E - < /dev/null | grep PPC
#define _ARCH_PPC 1
#define __PPC__ 1
#define __PPC 1
#define PPC 1
mathieu@macbookpro $ powerpc-linux-gnu-gcc -m64 -dM -E - < /dev/null | grep PPC
#define _ARCH_PPCGR 1
#define __PPC64__ 1
#define _ARCH_PPC 1
#define __PPC__ 1
#define _ARCH_PPC64 1
Stick to upstream this looks just fine.
However the build failed for me later on, reporting a failure to find
'mcs' (*). My G4 is rather slow so let me try again to check there are
no other build failure later on. Mark do you have a faster ppc machine
?
(*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then
:; else chmod -R +w
/home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi
cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make
--no-print-directory -s NO_DIR_CHECK=1
PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14
' CC='gcc' all-profiles
mkdir -p -- build/deps
make[7]: mcs: Command not found
make[7]: *** [build/profiles/basic.make:118:
build/deps/basic-profile-check.exe] Error 127
*** The runtime 'mono' doesn't appear to be usable.
*** Trying the 'monolite-linux/1051600014' directory.
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance
of an object
at Mono.CSharp.Binary.CreatePointerOperatorsTable
(Mono.CSharp.BuiltinTypes types) [0x0006b] in
<9d70195405974ada92fc07fda5c6d57c>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException:
Object reference not set to an instance of an object
at Mono.CSharp.Binary.CreatePointerOperatorsTable
(Mono.CSharp.BuiltinTypes types) [0x0006b] in
<9d70195405974ada92fc07fda5c6d57c>:0
make[9]: *** [build/profiles/basic.make:118:
build/deps/basic-profile-check.exe] Error 1
*** The contents of your 'monolite-linux/1051600014' directory may be
out-of-date
*** You may want to try 'make get-monolite-latest'
Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"
Source: mono Version: 5.16.0.220+dfsg3-1 User: debian-powe...@lists.debian.org Usertags: powerpc mono currently fails to compile on powerpc, let's log progress here. Ref: * https://buildd.debian.org/status/fetch.php?pkg=mono=powerpc=5.16.0.220%2Bdfsg3-1=1547184646=0
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 1:59 PM Mathieu Malaterre wrote: > > On Wed, Jan 9, 2019 at 1:56 PM Yavor Doganov wrote: > > > > Mathieu Malaterre wrote: > > > On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > > > Mathieu Malaterre wrote: > > > > > Based on the error on powerpc (2): > > > > > > > > > > description.m:26:3: warning: passing argument 3 of > > > > > 'initWithXMLString:options:error:' from incompatible pointer type > > > > > [-Wincompatible-pointer-types] > > > > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > > > > options:0 error:error]; > > > > >^~ > > > > > description.m:26:3: note: expected 'struct NSError **' but argument is > > > > > of type 'struct NSError *' > > > > > > > > OK, there's a typo here (should be ). But that's certainly not > > > > the reason for the failure; all NXSMLNode tests pass. > > > > > > > > > I would say something is bogus in the deps (update version number in > > > > > d/control to prevent possible incompatible deps). > > > > > > > > I'm afraid I don't understand. What's wrong with the deps? > > > > > > Reading from the error log, it felt like an API was changed (hence the > > > compilation error). So I suggested updating X.Y in something like > > > Depends: libfoo-dev (>= X.Y) in your d/control. > > > > But this doesn't make sense. That's gnustep-base's own testsuite > > which is self-contained: test programs link with the just built > > library and use uninstalled headers from the src tree for compilation. > > I fail to see what debian/control has to do with it. (And it's a > > warning, not compilation error, due to an innocent typo that's also > > present in the version in unstable.) > > I now realize my mistake. I grepped for "error:"... sorry for the noise. > > I'll give it a try on my powerpc box. Builds is ok, on MacMini G4 / 512M
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 1:56 PM Yavor Doganov wrote: > > Mathieu Malaterre wrote: > > On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > > Mathieu Malaterre wrote: > > > > Based on the error on powerpc (2): > > > > > > > > description.m:26:3: warning: passing argument 3 of > > > > 'initWithXMLString:options:error:' from incompatible pointer type > > > > [-Wincompatible-pointer-types] > > > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > > > options:0 error:error]; > > > >^~ > > > > description.m:26:3: note: expected 'struct NSError **' but argument is > > > > of type 'struct NSError *' > > > > > > OK, there's a typo here (should be ). But that's certainly not > > > the reason for the failure; all NXSMLNode tests pass. > > > > > > > I would say something is bogus in the deps (update version number in > > > > d/control to prevent possible incompatible deps). > > > > > > I'm afraid I don't understand. What's wrong with the deps? > > > > Reading from the error log, it felt like an API was changed (hence the > > compilation error). So I suggested updating X.Y in something like > > Depends: libfoo-dev (>= X.Y) in your d/control. > > But this doesn't make sense. That's gnustep-base's own testsuite > which is self-contained: test programs link with the just built > library and use uninstalled headers from the src tree for compilation. > I fail to see what debian/control has to do with it. (And it's a > warning, not compilation error, due to an innocent typo that's also > present in the version in unstable.) I now realize my mistake. I grepped for "error:"... sorry for the noise. I'll give it a try on my powerpc box.
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > Mathieu Malaterre wrote: > > Based on the error on powerpc (2): > > > > description.m:26:3: warning: passing argument 3 of > > 'initWithXMLString:options:error:' from incompatible pointer type > > [-Wincompatible-pointer-types] > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > options:0 error:error]; > >^~ > > description.m:26:3: note: expected 'struct NSError **' but argument is > > of type 'struct NSError *' > > OK, there's a typo here (should be ). But that's certainly not > the reason for the failure; all NXSMLNode tests pass. > > > I would say something is bogus in the deps (update version number in > > d/control to prevent possible incompatible deps). > > I'm afraid I don't understand. What's wrong with the deps? Reading from the error log, it felt like an API was changed (hence the compilation error). So I suggested updating X.Y in something like Depends: libfoo-dev (>= X.Y) in your d/control. 2cts -M
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 11:21 AM Yavor Doganov wrote: > > Source: gnustep-base > Version: 1.26.0-1 > Severity: important > Tags: sid buster ftbfs > User: debian-powe...@lists.debian.org > Usertags: powerpc powerpcspe ppc64 > > Hi PowerPC folks, > > As the subject says, gnustep-base failed to build in experimental on > these architectures so I'd appreciate some help. > > The powerpcspe failure [1] is extremely awkward; the build appears > successful but the log seems truncated, interrupted during dh_install. > On powerpc [2] and ppc64 [3] there is testsuite failure, but all these > tests pass for me on gcc110 from the GCC Compile Farm. However, > that's different toolchain and it's not even running Debian so any > conclusion is unreliable. I don't have access to the porter machines > to test. > > Could these failures be related to the fact that kapitsa/kapitsa2 have > some network-related issues as uploading build logs appears to be > suspended for a certain (long) period? > > I guess give-backs on these three architectures wouldn't harm? Based on the error on powerpc (2): description.m:26:3: warning: passing argument 3 of 'initWithXMLString:options:error:' from incompatible pointer type [-Wincompatible-pointer-types] xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr options:0 error:error]; ^~ description.m:26:3: note: expected 'struct NSError **' but argument is of type 'struct NSError *' I would say something is bogus in the deps (update version number in d/control to prevent possible incompatible deps). > [1] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpcspe=1.26.0-1=1546973971=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpc=1.26.0-1=1547024045=0 > [3] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=ppc64=1.26.0-1=1547024045=0 >
Bug#916864: Fwd: ofpathname is bash only
Components of a path are in this general form: @: Name can be safely omitted as the device is actually getting located by its address. Therefore, these two paths refer to the same device: /pci@f400/ata-6@d/disk@0:b /@f400/@d/@0:b Find freely available references on openfirmware matters at: http://firmworks.com/ https://www.openfirmware.org/Welcome_to_OpenBIOS
Bug#918382: broken upload
On Sun, Jan 6, 2019 at 12:09 PM 積丹尼 Dan Jacobson wrote: > > As you can see in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918382 > gimp is relying (Depending) on a broken upload. > > Perhaps you could make it Depend on libopenexr24 instead of libopenexr23. > Well then, take the binary package from sid: https://packages.debian.org/sid/libopenexr23
Bug#918382: trying to overwrite '/usr/lib/x86_64-linux-gnu/libIlmImf-2_3.so.24.0.0', which is also in package libopenexr23:amd64 2.3.0-3
Control: tags -1 wontfix Hi, Thanks for the bug report. On Sat, Jan 5, 2019 at 6:21 PM 積丹尼 Dan Jacobson wrote: > trying to overwrite '/usr/lib/x86_64-linux-gnu/libIlmImf-2_3.so.24.0.0', > which is also in package libopenexr23:amd64 2.3.0-3 Yeah that's correct. However please consider 2.3.0-3 a broken upload. Sorry about that, you'll need to purge it first. Sorry about that.
Bug#886560: CharLS 2.0.0
On Fri, Dec 21, 2018 at 11:39 AM Andreas Tille wrote: > > Control: tags -1 help > > I've commited charls 2.0 to Git[1]. Unfortunately it does not build > out of the box: Fixed: 3f15f491eef6 Update to match SOVERSION d10b1dafe79c Use default c++ standard used by gcc when compiling 4766801f4044 Refresh patch for v2.0.0 There is still something wrong. I see -O0 in compilation log, and hardening does not pass -D stuff on the command line... > It would be nice if you could help getting the package you > injected into Debian upgraded. Thank you > > Andreas. > > [1] https://salsa.debian.org/med-team/charls > > -- > http://fam-tille.de
Bug#916864: Make grub-ofpathname behaves like yaboot/ofpath on PowerPC system
Source: grub2
Version: 2.02+dfsg1-9
User: debian-powe...@lists.debian.org
Usertags: powerpc
Please consider applying the following patch to grub2 in Debian. This
will allow us to replace yaboot/ofpath with grub2/ofpathname now that
yaboot package is gone. In the long term this will allow grub2 to be a
complete replacement of yaboot on PowerPC/PowerMac.
Thanks
Description: Make grub-ofpathname behaves like yaboot/ofpath
This change in convention is needed for PowerMac system
Author: Mathieu Malaterre
Index: grub2-2.02+dfsg1/grub-core/osdep/linux/ofpath.c
===
--- grub2-2.02+dfsg1.orig/grub-core/osdep/linux/ofpath.c
+++ grub2-2.02+dfsg1/grub-core/osdep/linux/ofpath.c
@@ -282,14 +282,22 @@ __of_path_common(char *sysfs_path,
digit_string = trailing_digits (device);
if (*digit_string == '\0')
{
+#ifdef __powerpc__
+ snprintf(disk, sizeof (disk), "/@%d", devno);
+#else
snprintf(disk, sizeof (disk), "/disk@%d", devno);
+#endif
}
else
{
int part;
sscanf(digit_string, "%d", );
+#ifdef __powerpc__
+ snprintf(disk, sizeof (disk), "/@%d:%c", devno, '1' + (part - 1));
+#else
snprintf(disk, sizeof (disk), "/disk@%d:%c", devno, 'a' + (part - 1));
+#endif
}
strcat(of_path, disk);
return of_path;
Bug#916830: Acknowledgement (grub-common: Install grub-ofpathname also on powerpc)
Control: tags -1 patch Attached (shameless copy of sparc64). Let me know if you prefer a PR on salsa.d.o. Thanks much ofpathname.debdiff Description: Binary data
Bug#916830: grub-common: Install grub-ofpathname also on powerpc
Package: grub-common Version: 2.02+dfsg1-9 User: debian-powe...@lists.debian.org Usertags: powerpc Please install grub-ofpathname also for arch powerpc.
Bug#916746: powerpc-utils 1.3.6 is out
Source: powerpc-utils Version: 1.3.2-1 User: debian-powe...@lists.debian.org Usertags: ppc64 powerpc ppc64el Release 1.3.6 is out. Please package it. Let me know if you need help with updating the package. Thanks
Bug#808839: Badly build jlatexmath-fop
Looks like something went terribly wrong when building the jar file in recent uploads: $ jar tvf /usr/share/java/jlatexmath-fop.jar 0 Tue Sep 25 06:28:10 UTC 2018 META-INF/ 76 Tue Sep 25 06:28:10 UTC 2018 META-INF/MANIFEST.MF 15122 Tue Sep 25 06:28:10 UTC 2018 META-INF/COPYING 1740 Tue Sep 25 06:28:10 UTC 2018 META-INF/LICENSE 0 Tue Sep 25 06:28:10 UTC 2018 META-INF/maven/ 0 Tue Sep 25 06:28:10 UTC 2018 META-INF/maven/org.scilab.forge/ 0 Tue Sep 25 06:28:10 UTC 2018 META-INF/maven/org.scilab.forge/jlatexmath-fop/ 96 Tue Sep 25 06:28:10 UTC 2018 META-INF/maven/org.scilab.forge/jlatexmath-fop/pom.properties 1861 Tue Sep 25 06:28:10 UTC 2018 META-INF/maven/org.scilab.forge/jlatexmath-fop/pom.xml 0 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/ 56 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/org.apache.fop.fo.ElementMapping 53 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/org.apache.fop.render.XMLHandler 74 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageConverter 73 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageLoaderFactory 65 Tue Sep 25 06:28:10 UTC 2018 META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImagePreloader 0 Tue Sep 25 06:28:10 UTC 2018 org/ 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/ 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/ 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/ 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/ 7125 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathElement.class 284 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathElementMapping$1.class 1364 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathElementMapping$JLMEMaker.class 1357 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathElementMapping$JLMMaker.class 1442 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathElementMapping.class 768 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathObj.class 2143 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/JLaTeXMathXMLHandler.class 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/ 1296 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/ImageJLaTeXMath.class 0 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/ 2489 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/Graphics2DImagePainterJLaTeXMath.class 1738 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/ImageConverterJLaTeXMathToG2D.class 1909 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/ImageLoaderFactoryJLaTeXMath.class 2455 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/ImageLoaderJLaTeXMath.class 3312 Tue Sep 25 06:28:10 UTC 2018 org/scilab/forge/jlatexmath/fop/image/loader/PreloaderJLaTeXMath.class Some class have disapear (eg. org/scilab/forge/jlatexmath/TeXFormula)
Bug#915046: mariadb-10.3: Please build with -latomic where necessary
On Fri, Nov 30, 2018 at 1:05 PM John Paul Adrian Glaubitz wrote: > > Hi! > > Attaching a proof-of-concept patch which fixes the issue for me. > > The patch shouldn't be used as-is as it links against libatomic > unconditionally while it should only link against it when necessary. src:tbb is unconditionally using -latomic for a few Debian releases now and this has not been an issue. libatomic will default to using the correct intrinsics on supported hardware, so the link step should even be able to drop totally deps to that lib.
Bug#909865: double rounding x87 FPU
Control: tags -1 patch Usual stuff on x86 (again). Could someone with better automake expertise confirm the patch is not too silly. Technically we only need to apply this on x86 arch (linux-x86, hurd-x86, maybe kFreeBSD?). Maybe I should be using IlmImfTest_CFLAGS but I did not check to much. % cat debian/patches/bug909865.patch --- openexr-2.2.1.orig/IlmImfTest/Makefile.am +++ openexr-2.2.1/IlmImfTest/Makefile.am @@ -54,6 +54,8 @@ IlmImfTest_SOURCES = main.cpp tmpDir.h t AM_CPPFLAGS = -DILM_IMF_TEST_IMAGEDIR=\"$(srcdir)/\" +AM_CPPFLAGS += -ffloat-store + if BUILD_IMFHUGETEST IlmImfTest_SOURCES += testDeepScanLineHuge.cpp testDeepScanLineHuge.h AM_CPPFLAGS += -DENABLE_IMFHUGETEST
Bug#808839:
Correct backtrace: change nwalsh into docbook-xsl to find: /usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl Then: $ fop -xsl ./jlatexmath-fop/examples/latex.xsl -c ./jlatexmath-fop/examples/conf.xml -xml ./jlatexmath-fop/examples/latex_docbook.xml -pdf /tmp/bla.pdf [INFO] FopConfParser - Default page-height set to: 11in [INFO] FopConfParser - Default page-width set to: 8.26in [WARN] InputHandler - Note: namesp. cut : stripped namespace before processing Very simple book with mathematical formulas [WARN] InputHandler - Making portrait pages on USletter paper (8.5inx11in) [WARN] FOUserAgent - Font "Symbol,normal,700" not found. Substituting with "Symbol,normal,400". [WARN] FOUserAgent - Font "ZapfDingbats,normal,700" not found. Substituting with "ZapfDingbats,normal,400". [INFO] FOUserAgent - Rendered page #1. [WARN] FOUserAgent - Hyphenation pattern not found. URI: en. [INFO] FOUserAgent - Rendered page #2. Exception in thread "main" java.lang.NoClassDefFoundError: org/scilab/forge/jlatexmath/TeXFormula at org.scilab.forge.jlatexmath.fop.JLaTeXMathElement.calculate(JLaTeXMathElement.java:162) at org.scilab.forge.jlatexmath.fop.JLaTeXMathElement.getDimension(JLaTeXMathElement.java:100) at org.apache.fop.fo.flow.InstreamForeignObject.prepareIntrinsicSize(InstreamForeignObject.java:112) at org.apache.fop.fo.flow.InstreamForeignObject.getIntrinsicWidth(InstreamForeignObject.java:125) at org.apache.fop.layoutmgr.inline.AbstractGraphicsLayoutManager.getInlineArea(AbstractGraphicsLayoutManager.java:61) at org.apache.fop.layoutmgr.inline.AbstractGraphicsLayoutManager.getNextKnuthElements(AbstractGraphicsLayoutManager.java:116) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(InlineLayoutManager.java:329) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(InlineLayoutManager.java:329) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:698) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:627) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:148) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:251) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:770) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:389) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:143) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190) at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:263) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1401) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2402) at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:128) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2402) at org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:394) at org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:248) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2402) at org.apache.xalan.templates.ElemIf.execute(ElemIf.java:162) at
Bug#808839: Affects 2.3 as well
$ fop -xsl ./jlatexmath-fop/examples/latex.xsl -c ./jlatexmath-fop/examples/conf.xml -xml ./jlatexmath-fop/examples/latex_docbook.xml -pdf /tmp/bla.pdf [INFO] FopConfParser - Default page-height set to: 11in [INFO] FopConfParser - Default page-width set to: 8.26in file:/tmp/libjlatexmath-java-1.0.7/./jlatexmath-fop/examples/latex.xsl; Line #7; Column #78; Had IO Exception with stylesheet file: /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl file:/tmp/libjlatexmath-java-1.0.7/./jlatexmath-fop/examples/latex.xsl; Line #26; Column #119; org.apache.xml.utils.WrappedRuntimeException: Could not find variable with the name of page.width [ERROR] FOP - Exception org.apache.fop.apps.FOPException: java.lang.NullPointerException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116) at org.apache.fop.cli.Main.startFOP(Main.java:186) at org.apache.fop.cli.Main.main(Main.java:217) Caused by: java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:279) ... 3 more - java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:279) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116) at org.apache.fop.cli.Main.startFOP(Main.java:186) at org.apache.fop.cli.Main.main(Main.java:217) with: $ fop -version FOP Version 2.3
Bug#639683: fop does not run any tests
Control: retitle -1 fop does not check test results Since switch of build system to maven src:fop now execute test suite. But since some of them are failing, the results of the tests are currently being discarded.
Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2
On Fri, Nov 23, 2018 at 12:04 PM Mattia Rizzolo wrote: > > On Fri, Nov 23, 2018 at 11:41:10AM +0100, Mathieu Malaterre wrote: > > As you've noticed the ABI breakage occur in between two minor uploads > > -1 and -2. So I suspect this may confuse reader that bug be reported > > against src:gdcm, since obviously not a single line change could have > > occurred in between two minor uploads. > > I don't understand this sentence of yours. > The debian revision in a version doesn't convey any particular meaning > about the "dimension" of the changes. In fact going from 2.8.7-1 to > 2.8.7-2 could techinically ship a completely different upstream tarball > with completely different code in it, still you would call that a "minor > upload"? > > So everything could have happened in between. https://www.debian.org/doc/debian-policy/ch-controlfields.html#version [...]debian_revision This part of the version number specifies the version of the Debian package based on the upstream version. [...] In any case, the upstream source did not change a bit in between uploads of those two debian_version. > > Trying to read the changelog of 2.8.7-2 I only find reference to py3 > > changes, however digging a bit in the d/control Deps I can see a > > switch from vtk6 to vtk7: > > > > https://salsa.debian.org/med-team/gdcm/commit/616785342cdfc6747125a3f505af0b985d4d8fee > > > > Since libvtkgdcm2.8 is a c++ project, I suspect that any change of any > > inherited c++ class will change the ABI. I would suggest that > > libvtkgdcm2.8 be removed, and a new binary package libvtk7gdcm2.8 be > > uploaded instead. > > Please also read the rest of my email, that's what I deduced and > recomended as well (apart from suggesting a particular name for the > binary). [...] Also, I don't know what triggered this, if it was the py3 change or the vtk change (most likely). [...] So my point was simply to remove this potential confusion. That is all. > Also, before doing that somebody should check all the other binaries, > and verify they didn't change their ABI either. Which binaries ? Those build from src:gdcm ? > BTW, it bothers me quite a lot that such a big change as moving from > VTK6 to VTK7 has not been mentioned in the changelog at all. True. Hence the confusion, which my email tried to remove. > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2
> This is a diff of a .symbols file I generated from libvtkgdcm2.8 > versions 2.8.7-1 and 2.8.7-2. Thanks Mattia for tracking this issue ! As you've noticed the ABI breakage occur in between two minor uploads -1 and -2. So I suspect this may confuse reader that bug be reported against src:gdcm, since obviously not a single line change could have occurred in between two minor uploads. Trying to read the changelog of 2.8.7-2 I only find reference to py3 changes, however digging a bit in the d/control Deps I can see a switch from vtk6 to vtk7: https://salsa.debian.org/med-team/gdcm/commit/616785342cdfc6747125a3f505af0b985d4d8fee Since libvtkgdcm2.8 is a c++ project, I suspect that any change of any inherited c++ class will change the ABI. I would suggest that libvtkgdcm2.8 be removed, and a new binary package libvtk7gdcm2.8 be uploaded instead.
Bug#873209: Please drop dependency on avalon-framework
Control: tags -1 + upstream Control: tags -1 - patch Hi, Thanks for the update, but this is realistically only an upstream issue. I am not going to maintain a fop fork just to get rid of some hypothetic issues while break user code.
Bug#847190: The following feature isn't implemented by Apache FOP, yet: table-layout="auto" (on fo:table)
Control: tags -1 - patch On Wed, Jun 20, 2018 at 10:02 AM Petter Reinholdtsen wrote: > > [Petter Reinholdtsen] > > I see from > https://docs.oracle.com/javase/tutorial/jaxp/properties/properties.html > > > these were new in JAXP 1.5, but fail to understand why they are not > > available when > > building with javac in jdk 10. :( > > I tried building in Debian Stable with JDK 8, and here it worked. :/ I'll upload 2.3 soon to unstable, so removing the tag patch since it does not apply anymore.
Bug#914105: dh_install: Cannot find (any matches for) "pdfbox/target/apidocs/*" (tried in ., debian/tmp)
Control: tags -1 wontfix On Mon, Nov 19, 2018 at 4:46 PM Markus Koschany wrote: > > Am 19.11.18 um 16:30 schrieb Mathieu Malaterre: > > On Mon, Nov 19, 2018 at 4:15 PM Markus Koschany wrote: > >> Are you sure you are trying to build src:libpdfbox-java and not > >> src:libpdfbox2-java? > > > > Sorry my fault. Fixed now. > > > >> In any case both packages build fine for me in Sid. > > > > Thanks for answering, I was hoping you would do so :) > > > > What is the output of this command on your side: > > > > $ apt-cache policy libbcprov-java-doc > > > > In case this package is installed, please run `dpkg --purge` on it, > > then try `debuild` again. > > > > Thanks > > I'm not sure what you are trying to achieve. libbcprov-java-doc is not a > build-dependency, so it should not be installed when you build > libpdfbox2-java but it also should not have any effect at all if it > exists. The dpkg --search commands are not fatal. If I recall correctly, > only some links in the java documentation will be missing. But the > implementation is not very efficient at the moment and I assume it could > be improved. See also maven-debian-helper bug > > https://bugs.debian.org/871669 > > I cannot reproduce the symptoms in a new sid chroot as of today. Closing as invalid. Sorry for the noise
Bug#914181: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 841: ordinal not in range(128)
Package: devscripts Version: 2.18.9 Something did not work in the transition from py27 to py3: Steps: $ apt-get source fop $ cd fop-* $ wrap-and-sort Traceback (most recent call last): File "/usr/bin/wrap-and-sort", line 317, in main() File "/usr/bin/wrap-and-sort", line 302, in main modified_files = wrap_and_sort(args) File "/usr/bin/wrap-and-sort", line 219, in wrap_and_sort if remove_trailing_whitespaces(copyright_file, args): File "/usr/bin/wrap-and-sort", line 176, in remove_trailing_whitespaces content = file_object.read() File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 841: ordinal not in range(128) Thanks
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
On Tue, Nov 20, 2018 at 8:31 AM Mathieu Malaterre wrote: > > On Tue, Nov 20, 2018 at 8:19 AM Timo Aaltonen wrote: > > > > On 20.11.2018 9.04, Mathieu Malaterre wrote: > > > Package: mesa-common-dev > > > Version: 18.2.5-1 > > > Severity: serious > > > Tags: ftbfs > > > > > > OpenVDB fails to build from source because of: > > > > > > In file included from /usr/include/GL/gl.h:2055, > > > from viewer/Font.h:40, > > > from viewer/Font.cc:31: > > > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No > > > such file or directory > > > #include > > > ^~~ > > > compilation terminated. > > > > > > ref: > > > https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-5=154226=0 > > > > > > It would be nice to fix this, upstream seems to have provided a patch: > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > > > That commit is in 18.2.5: > > > > commit 2645ea5817f4fd05905b8deda96c268cd69fa48c > > Author: Eric Engestrom > > Date: Tue Aug 7 12:56:25 2018 +0100 > > > > configure: install KHR/khrplatform.h when needed > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" > > Signed-off-by: Eric Engestrom > > Tested-by: Brad King > > Reviewed-by: Emil Velikov > > (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f) > > > > so something else is wrong. > > I must admit I was hoping for some help here. Here is what I see on my side: > > $ head -n 467 /usr/include/GL/glext.h | tail -1 > #include > > So this is a bit mysterious what is happening on all the buildds... As a side note, the experimental build of OpenVDB (same orig tarball as the one in sid) went find using the previous version of mesa: https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-4=1542634335=0 ... Get: 164 http://ftp.gr.debian.org/debian unstable/main amd64 mesa-common-dev amd64 18.1.9-1 [587 kB] ...
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
On Tue, Nov 20, 2018 at 8:19 AM Timo Aaltonen wrote: > > On 20.11.2018 9.04, Mathieu Malaterre wrote: > > Package: mesa-common-dev > > Version: 18.2.5-1 > > Severity: serious > > Tags: ftbfs > > > > OpenVDB fails to build from source because of: > > > > In file included from /usr/include/GL/gl.h:2055, > > from viewer/Font.h:40, > > from viewer/Font.cc:31: > > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No > > such file or directory > > #include > > ^~~ > > compilation terminated. > > > > ref: > > https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-5=154226=0 > > > > It would be nice to fix this, upstream seems to have provided a patch: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > That commit is in 18.2.5: > > commit 2645ea5817f4fd05905b8deda96c268cd69fa48c > Author: Eric Engestrom > Date: Tue Aug 7 12:56:25 2018 +0100 > > configure: install KHR/khrplatform.h when needed > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 > Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" > Signed-off-by: Eric Engestrom > Tested-by: Brad King > Reviewed-by: Emil Velikov > (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f) > > so something else is wrong. I must admit I was hoping for some help here. Here is what I see on my side: $ head -n 467 /usr/include/GL/glext.h | tail -1 #include So this is a bit mysterious what is happening on all the buildds...
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
Package: mesa-common-dev Version: 18.2.5-1 Severity: serious Tags: ftbfs OpenVDB fails to build from source because of: In file included from /usr/include/GL/gl.h:2055, from viewer/Font.h:40, from viewer/Font.cc:31: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory #include ^~~ compilation terminated. ref: https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-5=154226=0 It would be nice to fix this, upstream seems to have provided a patch: https://bugs.freedesktop.org/show_bug.cgi?id=107511
Bug#849513: d/control: Conflicts can be removed
While the binary name is a long story, I believe it does not make sense to continue keeping: $ cat d/control ... Conflicts: ninja Thanks for maintaining ninja !
Bug#914131: transition: openvdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I'd like to proceed with the transition of openvdb from 5.0 to 5.2 now. All reverse dependencies are good (blender). This will address #911891. Current status in exp: https://buildd.debian.org/status/package.php?p=openvdb=experimental Ben file: title = "openvdb"; is_affected = .depends ~ "libopenvdb5.0" | .depends ~ "libopenvdb5.2"; is_good = .depends ~ "libopenvdb5.2"; is_bad = .depends ~ "libopenvdb5.0"; -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#914105: dh_install: Cannot find (any matches for) "pdfbox/target/apidocs/*" (tried in ., debian/tmp)
On Mon, Nov 19, 2018 at 4:15 PM Markus Koschany wrote: > Are you sure you are trying to build src:libpdfbox-java and not > src:libpdfbox2-java? Sorry my fault. Fixed now. > In any case both packages build fine for me in Sid. Thanks for answering, I was hoping you would do so :) What is the output of this command on your side: $ apt-cache policy libbcprov-java-doc In case this package is installed, please run `dpkg --purge` on it, then try `debuild` again. Thanks
Bug#914105: dh_install: Cannot find (any matches for) "pdfbox/target/apidocs/*" (tried in ., debian/tmp)
Source: libpdfbox-java Version: 1:1.8.16-1 For some reason I cannot build libpdfbox-java locally, it fails to build with: Offline mode. Give up looking for package containing /usr/share/doc/libbcprov-java/apidocs/index.html > dpkg --search /usr/share/doc/libbcprov-java-doc/apidocs/index.html dpkg failed to execute successfully Offline mode. Give up looking for package containing /usr/share/doc/libbcprov-java-doc/apidocs/index.html bash -c "rm -f target/apidocs/*.sh target/apidocs/options" mh_unpatchpoms -plibpdfbox2-java dh_install -O--buildsystem=maven dh_install: Cannot find (any matches for) "pdfbox/target/apidocs/*" (tried in ., debian/tmp) dh_install: libpdfbox2-java-doc missing files: pdfbox/target/apidocs/* dh_install: Cannot find (any matches for) "fontbox/target/apidocs/*" (tried in ., debian/tmp) dh_install: libfontbox2-java-doc missing files: fontbox/target/apidocs/* dh_install: missing files, aborting make: *** [debian/rules:4: binary] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui failed
Bug#913888: node-babel: Make source package bootstrappable
Source: node-babel Version: 6.26.0+dfsg-3 Severity: wishlist Currently, node-babel is involved in build dependency cycles such as: $ grep node-babel-core debian/control , node-babel-core , node-babel-core (>= 6.18.0) Package: node-babel-core , node-babel-core (>= 6.18.0) It would be nice if src:node-babel could provide a stage1 build profile to allow for the source package to be bootstrapped.
Bug#912661: python-tifffile: tifffile is not installed as distribution
> Debian makes use of the individual files via a mirror at > https://github.com/malaterre/tifffile which seems to exist for Debian > only. I'll remove this repo ASAP, to avoid spreading more confusion. Thanks for the report.
Bug#913878: Acknowledgement (/usr/lib/ghc/rts/libHSrts.a(TopHandler.o):function exitTopHandler: error: relocation overflow)
Another bug #904915 seems to suggest that switching to GNU BFD linker may avoid some Gold issue on exotic arch.
Bug#913878: /usr/lib/ghc/rts/libHSrts.a(TopHandler.o):function exitTopHandler: error: relocation overflow
Source: ghc Version: 8.4.3+dfsg1-4 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc It would be nice to make ghc compile on powerpc, current failure: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/lib/ghc/rts/libHSrts.a(TopHandler.o):function exitTopHandler: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(Stable.o):function exitStableTables: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(Stable.o):function exitStableTables: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(Stable.o):function exitStableTables: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(Stable.o):function exitStableTables: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(RtsStartup.o):function hs_exit_: error: relocation overflow /usr/lib/ghc/rts/libHSrts.a(RtsStartup.o):function hs_exit_: error: relocation overflow ... Maybe related to: https://lists.gnu.org/archive/html/bug-binutils/2015-03/msg00109.html But documentation states otherwise: $ grep -1 -r unresolved-symbols * libraries/Cabal/Cabal/Distribution/Simple/GHC.hs-resolve these symbols_. We can tell the static linker not to report these libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:errors by using `--unresolved-symbols=ignore-all` and all will be fine when we libraries/Cabal/Cabal/Distribution/Simple/GHC.hs-run the program ([(indeed, this is what the gold linker ref: https://buildd.debian.org/status/fetch.php?pkg=ghc=powerpc=8.4.3%2Bdfsg1-4=1540679666=0
Bug#911891: [openvdb] FTBFS with boost1.67
On Fri, Nov 16, 2018 at 10:55 AM Mathieu Malaterre wrote: > > Control: tags -1 pending > > On Thu, Oct 25, 2018 at 10:18 PM Giovanni Mascellani wrote: > > Please consider applying the attached patch as soon as boost1.67 is made > > default in order to avoid FTBFS. > > I understand what you are trying to do the in patch. I'll tweak it a > bit, in particular only d/rules should be touched (:= in Makefile), > also I prefer linking explicitly to py27 version for now (until full > deprecatation of py27). > > Thanks for the notification ! For clarification, I meant only this part should be applied: diff --git a/debian/rules b/debian/rules index a61f095..a905eb6 100755 --- a/debian/rules +++ b/debian/rules @@ -38,7 +38,7 @@ TESTOPS = CPPUNIT_INCL_DIR=/usr/include CPPUNIT_LIB_DIR=/usr/lib/$(DEB_HOST_MULT ILMBASE_INCL_DIR=/usr/include/OpenEXR ILMBASE_LIB_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ HT=/usr HDSO=/usr/lib \ LOG4CPLUS_INCL_DIR=/usr/include LOG4CPLUS_LIB_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) -ALLOPTS = $(BUILDDOC) $(TESTOPS) BOOST_PYTHON_LIB=-lboost_python-py27 PYTHON_VERSION=2.7 \ +ALLOPTS = $(BUILDDOC) $(TESTOPS) BOOST_PYTHON_LIB=-lboost_python27 PYTHON_VERSION=2.7 \ BOOST_PYTHON_LIB_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) PYTHON_LIB_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ PYTHON_INCL_DIR=/usr/include/python2.7 NUMPY_INCL_DIR=/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/ \ PYTHON_SONAME_FLAGS= \
Bug#911891: [openvdb] FTBFS with boost1.67
Control: tags -1 pending On Thu, Oct 25, 2018 at 10:18 PM Giovanni Mascellani wrote: > Please consider applying the attached patch as soon as boost1.67 is made > default in order to avoid FTBFS. I understand what you are trying to do the in patch. I'll tweak it a bit, in particular only d/rules should be touched (:= in Makefile), also I prefer linking explicitly to py27 version for now (until full deprecatation of py27). Thanks for the notification !
Bug#913813: [Pkg-javascript-devel] Bug#913813: node-tar : Depends: node-yallist (>= 3.0.2~) but 2.0.0-1 is to be installed
Control: tags -1 wontfix On Fri, Nov 16, 2018 at 5:50 AM Pirate Praveen wrote: > > > > On 2018, നവംബർ 15 9:01:15 PM IST, Mathieu Malaterre wrote: > >The following information may help to resolve the situation: > > > >The following packages have unmet dependencies: > >node-tar : Depends: node-yallist (>= 3.0.2~) but 2.0.0-1 is to be > >installed > >E: Unable to correct problems, you have held broken packages. > > It in NEW for last 2 weeks. > > https://ftp-master.debian.org/new/node-yallist_3.0.2-1~bpo9+1.html Sorry for the noise.
Bug#913812: [Pkg-javascript-devel] Bug#913812: node-boxen : Depends: node-camelcase (>= 4.0.0) but 3.0.0-1 is to be installed
Control: tags -1 wontfix On Fri, Nov 16, 2018 at 5:52 AM Pirate Praveen wrote: > > > > On 2018, നവംബർ 15 8:54:58 PM IST, Mathieu Malaterre wrote: > >The following information may help to resolve the situation: > > > >The following packages have unmet dependencies: > >node-boxen : Depends: node-camelcase (>= 4.0.0) but 3.0.0-1 is to be > >installed > >E: Unable to correct problems, you have held broken packages. > > It is in NEW for last 2 weeks > > https://ftp-master.debian.org/new/node-camelcase_4.1.0-1~bpo9+1.html Sorry for the noise.
Bug#913813: node-tar : Depends: node-yallist (>= 3.0.2~) but 2.0.0-1 is to be installed
Package: node-tar Version: 4.4.6+ds1-3~bpo9+1 Severity: grave Looks like the package is pretty much invalid: $ sudo apt-get install -t stretch-backports node-tar Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: node-tar : Depends: node-yallist (>= 3.0.2~) but 2.0.0-1 is to be installed E: Unable to correct problems, you have held broken packages.
Bug#913812: node-boxen : Depends: node-camelcase (>= 4.0.0) but 3.0.0-1 is to be installed
Package: node-boxen Version: 1.2.2-1~bpo9+1 Severity: grave Looks like the package is pretty much invalid: $ sudo apt-get install -t stretch-backports node-boxen Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: node-boxen : Depends: node-camelcase (>= 4.0.0) but 3.0.0-1 is to be installed E: Unable to correct problems, you have held broken packages.
Bug#913722: orthanc: Update README.Debian url
Package: orthanc Version: 1.2.0+dfsg-1 Severity: wishlist Dear Maintainer, It would be nice if you updated the README.Debian to reflect the move to a new website. In particular: https://code.google.com/p/orthanc/wiki/OrthancCookbook#Opening_Orthanc_Explorer Thanks -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages orthanc depends on: ii adduser3.115 ii dcmtk 3.6.1~20160216-4 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-locale1.62.0 1.62.0+dfsg-4 ii libboost-regex1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libboost-thread1.62.0 1.62.0+dfsg-4 ii libc6 2.24-11+deb9u3 ii libcurl3 7.52.1-5+deb9u8 ii libdcmtk8 3.6.1~20160216-4 ii libgcc11:6.3.0-18+deb9u1 ii libjpeg62-turbo1:1.5.1-2 ii libjsoncpp11.7.4-3 ii liblua5.1-05.1.5-8.1+b2 ii libpng16-161.6.28-1 ii libpugixml1v5 1.7-2 ii libsqlite3-0 3.16.2-5+deb9u1 ii libssl1.0.21.0.2l-2+deb9u3 ii libstdc++6 6.3.0-18+deb9u1 ii libuuid1 2.29.2-1+deb9u1 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-5 orthanc recommends no packages. orthanc suggests no packages. -- no debconf information
Bug#913716: org.debian.maven.repo.DependencyNotFoundException: Dependency not found org.apache.xmlgraphics:fop-parent:pom:2.3
Package: maven-debian-helper Version: 2.3.2 I cannot run multiple times mh_make, it would be nice if this was possible to incrementally build a package. For fop it fails with: Analysing pom.xml... Enter the upstream version for the package. [2.3] > Version of org.apache.xmlgraphics:fop-parent is debian Choose how the version will be transformed: 0 - Change the version to the symbolic 'debian' version [1] - Keep the version 2 - Custom rule > This project contains modules. Include all modules? (no to select them individually) [Y/n] > Analysing fop/pom.xml... Nov 14, 2018 9:43:52 AM org.debian.maven.packager.DependenciesSolver resolveDependencies SEVERE: Error while resolving ./fop/pom.xml: Dependency not found org.apache.xmlgraphics:fop-parent:pom:2.3 Nov 14, 2018 9:43:52 AM org.debian.maven.packager.DependenciesSolver resolveDependencies SEVERE: org.debian.maven.repo.DependencyNotFoundException: Dependency not found org.apache.xmlgraphics:fop-parent:pom:2.3 at org.debian.maven.repo.Repository.registerPom(Repository.java:414) at org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:321) at org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:421) at org.debian.maven.packager.DependenciesSolver.solveDependencies(DependenciesSolver.java:261) at org.debian.maven.packager.DependenciesSolver.main(DependenciesSolver.java:967)
Bug#913575: SEVERE: Cannot resolve dependencies in ./fop-servlet/pom.xml: Dependency not found org.apache.xmlgraphics:batik-all:jar:debian
For reference: > dpkg --search /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/*/* Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/debian/batik-all-debian.pom in libbatik-java Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/1.10/batik-all-1.10.pom in libbatik-java > dpkg --status libbatik-java [error] Package libbatik-java (1.10) is already installed and contains a possible match, but I cannot resolve library org.apache.xmlgraphics:batik-all:jar:debian in it. [error] Please check manually that the library is up to date, otherwise it may be necessary to package version debian in Debian. Nov 14, 2018 9:13:53 AM org.debian.maven.packager.DependenciesSolver$ToResolve resolve SEVERE: Cannot resolve dependencies in /home/mathieu/tmp/debian/fop/fop-servlet/pom.xml: Dependency not found org.apache.xmlgraphics:batik-all:jar:debian ERROR: fop-servlet/pom.xml: dependency is not packaged in the Maven repository for Debian: org.apache.xmlgraphics:batik-all:debian
Bug#913585: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'Sint32' {aka 'int'} [-Wformat=]
Source: dcmtk
Version: 3.6.3-1~exp1
Tags: fixed-upstream
It seems some of the build warnings have been fixed upstream, namely
those showing up on i386 (*), have been fixed by:
http://git.dcmtk.org/?p=dcmtk.git;a=commitdiff;h=386b588
...
/<>/dcmdata/libsrc/dcvrsl.cc: In member function 'virtual
void DcmSignedLong::print(std::ostream&, size_t, int, const char*,
size_t*)':
/<>/dcmdata/libsrc/dcvrsl.cc:192:41: warning: format
'%ld' expects argument of type 'long int', but argument 3 has type
'Sint32' {aka 'int'} [-Wformat=]
sprintf(buffer, "%ld", *sintVals);
^ ~
/<>/dcmdata/libsrc/dcvrsl.cc:194:41: warning: format
'%ld' expects argument of type 'long int', but argument 3 has type
'Sint32' {aka 'int'} [-Wformat=]
sprintf(buffer, "\\%ld", *sintVals);
^~~ ~
[...
<>/dcmdata/libsrc/dcvrul.cc: In member function 'virtual
void DcmUnsignedLong::print(std::ostream&, size_t, int, const char*,
size_t*)':
/<>/dcmdata/libsrc/dcvrul.cc:190:41: warning: format
'%lu' expects argument of type 'long unsigned int', but argument 3 has
type 'Uint32' {aka 'unsigned int'} [-Wformat=]
sprintf(buffer, "%lu", *uintVals);
^ ~
/<>/dcmdata/libsrc/dcvrul.cc:192:41: warning: format
'%lu' expects argument of type 'long unsigned int', but argument 3 has
type 'Uint32' {aka 'unsigned int'} [-Wformat=]
sprintf(buffer, "\\%lu", *uintVals);
ref:
https://buildd.debian.org/status/fetch.php?pkg=dcmtk=i386=3.6.3-1~exp1=1534157098=0
Thanks
Bug#913575: SEVERE: Cannot resolve dependencies in ./fop-servlet/pom.xml: Dependency not found org.apache.xmlgraphics:batik-all:jar:debian
Hi Emmanuel, On Mon, Nov 12, 2018 at 2:02 PM Emmanuel Bourg wrote: > > Le 12/11/2018 à 13:54, Mathieu Malaterre a écrit : > > > It should be possible to tweak the package to remove the following > > from mh_make on user side: > > Hi Mathieu, > > Looking at the log I fail to understand the issue. Could you be more > specific on the behavior you expect and why? Thanks for your kind help. I forgot to reference your original email: https://lists.debian.org/debian-java/2018/06/msg00048.html ... I'm not sure to understand why you get this error. Try adding the following rule in debian/maven.rules and run mh_make again: org.apache.xmlgraphics batik-all * s/.*/debian/ * * ... So I'd like the behavior of mh_make to be as smooth as possible. So if I understand correctly something needs to be fixed on the batik side. Let me know if I misunderstood your original comment -M
Bug#913575: SEVERE: Cannot resolve dependencies in ./fop-servlet/pom.xml: Dependency not found org.apache.xmlgraphics:batik-all:jar:debian
Package: libbatik-java Version: 1.10-1 User: debian-j...@lists.debian.org Usertags: maven-debian-helper It should be possible to tweak the package to remove the following from mh_make on user side: In fop-servlet/pom.xml: This dependency cannot be found in the Debian Maven repository. Ignore this dependency? org.apache.xmlgraphics:batik-all:jar:debian [y/N] > > dpkg --search /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/*/* Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/debian/batik-all-debian.pom in libbatik-java Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/1.10/batik-all-1.10.pom in libbatik-java > dpkg --status libbatik-java [error] Package libbatik-java (1.10) is already installed and contains a possible match, but I cannot resolve library org.apache.xmlgraphics:batik-all:jar:debian in it. [error] Please check manually that the library is up to date, otherwise it may be necessary to package version debian in Debian. Try again to resolve the dependency? [Y/n] > Rescanning /usr/share/maven-repo... Resolving org.apache.xmlgraphics:batik-all:jar:debian of scope runtime... [check dependency with bundle type] > dpkg --search /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/*/* Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/debian/batik-all-debian.pom in libbatik-java Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/1.10/batik-all-1.10.pom in libbatik-java > dpkg --status libbatik-java [error] Package libbatik-java (1.10) is already installed and contains a possible match, but I cannot resolve library org.apache.xmlgraphics:batik-all:jar:debian in it. [error] Please check manually that the library is up to date, otherwise it may be necessary to package version debian in Debian. Try again to resolve the dependency? [Y/n] > Rescanning /usr/share/maven-repo... Resolving org.apache.xmlgraphics:batik-all:jar:debian of scope runtime... [check dependency with bundle type] > dpkg --search /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/*/* Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/debian/batik-all-debian.pom in libbatik-java Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/1.10/batik-all-1.10.pom in libbatik-java > dpkg --status libbatik-java [error] Package libbatik-java (1.10) is already installed and contains a possible match, but I cannot resolve library org.apache.xmlgraphics:batik-all:jar:debian in it. [error] Please check manually that the library is up to date, otherwise it may be necessary to package version debian in Debian. Try again to resolve the dependency? [Y/n] > Rescanning /usr/share/maven-repo... Resolving org.apache.xmlgraphics:batik-all:jar:debian of scope runtime... [check dependency with bundle type] > dpkg --search /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/*/* Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/debian/batik-all-debian.pom in libbatik-java Found /usr/share/maven-repo/org/apache/xmlgraphics/batik-all/1.10/batik-all-1.10.pom in libbatik-java > dpkg --status libbatik-java [error] Package libbatik-java (1.10) is already installed and contains a possible match, but I cannot resolve library org.apache.xmlgraphics:batik-all:jar:debian in it. [error] Please check manually that the library is up to date, otherwise it may be necessary to package version debian in Debian. Try again to resolve the dependency? With: $ apt-cache policy libbatik-java libbatik-java: Installed: 1.10-1 Candidate: 1.10-1 Version table: *** 1.10-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status
Bug#913304: W: no data dictionary loaded, check environment variable: DCMDICTPATH
On Fri, Nov 9, 2018 at 12:12 PM Mathieu Malaterre wrote: > $ dmesg > ... > [ 2040.713725] traps: dcmdump[6029] trap invalid opcode > ip:7fc70e4d0d51 sp:7ffe5a0f2728 error:0 > [ 2040.713736] in libdcmdata.so.13.3.6.3[7fc70e441000+df000] Using debug package: (gdb) r test.acr Starting program: /usr/bin/dcmdump test.acr [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". W: no data dictionary loaded, check environment variable: DCMDICTPATH Program received signal SIGILL, Illegal instruction. 0x77f0ed51 in memset (__len=132, __ch=0, __dest=0x5558b2b8) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71 warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) bt #0 0x77f0ed51 in memset (__len=132, __ch=0, __dest=0x5558b2b8) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71 #1 DcmMetaInfo::setPreamble (this=this@entry=0x5558b210) at /home/gerddie/Debian/debian-med/build-area/dcmtk-3.6.3/dcmdata/libsrc/dcmetinf.cc:240 #2 0x77f0fbd5 in DcmMetaInfo::DcmMetaInfo() () at /home/gerddie/Debian/debian-med/build-area/dcmtk-3.6.3/dcmdata/libsrc/dcmetinf.cc:56 #3 0x77ef0732 in DcmFileFormat::DcmFileFormat() () at /home/gerddie/Debian/debian-med/build-area/dcmtk-3.6.3/dcmdata/libsrc/dcfilefo.cc:61 #4 0xb652 in ?? () #5 0x77807b17 in __libc_start_main (main=0x8dc8, argc=2, argv=0x7fffe618, init=, fini=, rtld_fini=, stack_end=0x7fffe608) at ../csu/libc-start.c:310 #6 0xd18a in _start ()
Bug#913304: W: no data dictionary loaded, check environment variable: DCMDICTPATH
Package: dcmtk
Version: 3.6.3-1~exp1
Thanks for maintaining dcmtk !
For some reason something went really wrong with the experimental
package. The first issue would need a deeper look since it appears
that support for dicom.dic has been lost in between sid and
experimental:
$ dcmdump test.acr
W: no data dictionary loaded, check environment variable: DCMDICTPATH
Indeed:
$ strace dcmdump test.acr 2>&1 | grep dicom.dic
access("/usr//dcmtk/dicom.dic", F_OK) = -1 ENOENT (No such file or directory)
However
$ dpkg -L libdcmtk13| grep dicom.dic
/usr/share/libdcmtk13/dicom.dic
---
I am reporting the second issue also here, but I suspect this is
related to the fact that the amd64 was build on a local machine
instead of a buildd. Anyway for later reference:
$ dcmdump test.acr
W: no data dictionary loaded, check environment variable: DCMDICTPATH
Illegal instruction
Which is reported as:
$ dmesg
...
[ 2040.713725] traps: dcmdump[6029] trap invalid opcode
ip:7fc70e4d0d51 sp:7ffe5a0f2728 error:0
[ 2040.713736] in libdcmdata.so.13.3.6.3[7fc70e441000+df000]
At the time of installation I had:
$ sha1sum *.deb
4f7446f8799892ebf43e99e527b8d5981048a527 dcmtk_3.6.3-1~exp1_amd64.deb
c8b5d206fccdd2a4018f16f10ba217b4af89bc57 libdcmtk13_3.6.3-1~exp1_amd64.deb
Bug#913227: dcmqrcbm.cc:319:38: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 128
Source: dcmtk Version: 3.6.3-1~exp1 Current compilation warning is: /<>/dcmqrdb/libsrc/dcmqrcbm.cc:319:38: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 128 [-Wformat-overflow=] sprintf(dstHostNamePlusPort, "%s:%d", dstHostName, dstPortNumber); ^~~ In file included from /usr/include/stdio.h:862, from /usr/include/c++/8/cstdio:42, from /<>/ofstd/include/dcmtk/ofstd/ofstdinc.h:290, from /<>/dcmnet/include/dcmtk/dcmnet/dicom.h:98, from /<>/dcmnet/include/dcmtk/dcmnet/dimse.h:88, from /<>/dcmqrdb/include/dcmtk/dcmqrdb/dcmqrcbm.h:26, from /<>/dcmqrdb/libsrc/dcmqrcbm.cc:24: /usr/include/aarch64-linux-gnu/bits/stdio2.h:33:34: note: '__builtin___sprintf_chk' output between 3 and 141 bytes into a destination of size 129 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~ __bos (__s), __fmt, __va_arg_pack ()); ~
Bug#912208: ITP: libjpeg -- A complete implementation of 10918-1 (JPEG)
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: libjpeg Version : 0.1 Upstream Author : Thomas Richter * URL : https://github.com/thorfdbg/libjpeg * License : GPL3 Programming Lang: C Description : A complete implementation of 10918-1 (JPEG) A complete implementation of 10918-1 (JPEG) comming from jpeg.org (the ISO group) with extensions for HDR currently discussed for standardization. . This release also includes the "JPEG on Steroids" improvements implemented for the ICIP 2016 Grand Challenge on Image Compression.
Bug#695524: jpeginfo: 1.6.1 is out
ping ? On Tue, Aug 23, 2016 at 9:18 AM Mathieu Malaterre wrote: > > ...while at it, it would be nice to populate d/control: Homepage > infomation as well as a d/watch file. > > See package src:jpegoptim in case this helps.
Bug#910870: gdcm: FTBFS with poppler 0.69.0-1
Control: fixed -1 2.8.7-5 On Thu, Oct 18, 2018 at 10:10 AM Emilio Pozuelo Monfort wrote: > > On 18/10/2018 09:45, Mathieu Malaterre wrote: > > Control: tags -1 upstream patch > > > > On Fri, Oct 12, 2018 at 5:51 PM Emilio Pozuelo Monfort > > wrote: > >> > >> Source: gdcm > >> Version: 2.8.7-3 > >> Severity: important > >> > >> Hi, > >> > >> Your package fails to build against poppler 0.69, currently in > >> experimental. > >> In some cases there are patches in Ubuntu, the PTS has links. > >> > >> For the memCheck errors, you can just patch out those calls, those were > >> noops anyway as we didn't build with DEBUG_MEM, see > >> > >> https://cgit.freedesktop.org/poppler/poppler/commit/?id=c362ab1b97f20c5b73b3bad8d52015f679178748 > >> > >> I intend to update our poppler soon as there are some security fixes > >> in the newer versions. I'd appreciate if you can take a look at this > >> and apply any necessary fixes. > >> > >> Full build log attached. > > > > Looks like this should work: > > > > https://sourceforge.net/p/gdcm/bugs/462/#1701 > > Cool. I'm uploading the new poppler, so if you can upload the fix that'd be > appreciated. Thanks to Gianfranco for the correct fix. Will update GDCM upstream.
Bug#910870: gdcm: FTBFS with poppler 0.69.0-1
Control: tags -1 upstream patch On Fri, Oct 12, 2018 at 5:51 PM Emilio Pozuelo Monfort wrote: > > Source: gdcm > Version: 2.8.7-3 > Severity: important > > Hi, > > Your package fails to build against poppler 0.69, currently in experimental. > In some cases there are patches in Ubuntu, the PTS has links. > > For the memCheck errors, you can just patch out those calls, those were > noops anyway as we didn't build with DEBUG_MEM, see > > https://cgit.freedesktop.org/poppler/poppler/commit/?id=c362ab1b97f20c5b73b3bad8d52015f679178748 > > I intend to update our poppler soon as there are some security fixes > in the newer versions. I'd appreciate if you can take a look at this > and apply any necessary fixes. > > Full build log attached. Looks like this should work: https://sourceforge.net/p/gdcm/bugs/462/#1701
Bug#902532: Cannot backport batik 1.10 to stretch
On Wed, Sep 5, 2018 at 1:53 PM Emmanuel Bourg wrote: > > Hi Mathieu, > > Le 27/06/2018 à 15:41, Mathieu Malaterre a écrit : > > > It would be nice to update the dependencies in d/control to match > > exactly requirement. Otherwise it is hard to backport to stretch: > > I've been able to build batik/1.10-1 on stretch by reverting the > debhelper compat level to 10. Using a backport of a recent version of > maven-debian-helper should also work (at least version 2.2.3 I think). Either way. As long as it does not involve a source upload. I remember (top of my head) having to add '~' to debhelper compat (which is annoying). Thanks
