Bug#973578: qemu-system-arm: -machine sbsa-ref does not boot UEFI
W dniu 02.11.2020 o 05:00, Ryutaroh Matsumoto pisze: Package: qemu-system-arm Version: 1:5.1+dfsg-4+b1 Severity: minor Dear Maintainer, # cp /usr/share/AAVMF/AAVMF_VARS.fd /var/tmp/efivars.fd; qemu-system-aarch64 \ -machine sbsa-ref -cpu cortex-a57 -nographic -net nic,model=virtio \ -net user -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0,id=rng-device0 \ -drive file=/var/lib/debci/qemu/sid-arm64.img,if=virtio,index=0,format=qcow2 \ -drive if=pflash,format=raw,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd \ -drive if=pflash,format=raw,file=/var/tmp/efivars.fd -m 1024 gives the error qemu-system-aarch64: device requires 268435456 bytes, block backend provides 67108864 bytes On the other hand, if I change -machine sbsa-ref to -machine virt, it works fine as SBSA Reference Platform requires both UEFI firmware and UEFI variables file to be 256MB in size. Virt machine uses 64MB files. So it is not a bug in qemu.
Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt
W dniu 02.11.2021 o 22:26, Michael Tokarev pisze: What do you want us to do here? I know full well that libvirt in buster is too old for new qemu. I don't have enough experience to backport libvirt (I never ever used it myself). Even if I had such experience, what I should do with this bugreport? You are right. I am forgetting that there are people using qemu directly. Should I maybe remove the qemu backport and hence close this bugreport? More recent qemu is definitely useful on buster - for me and for some other people as well, so I don't quite want to remove it from bpo. So I don't see a way to deal with this bugreport. Close it please. Sorry for that.
Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt
Package: qemu-system-common Version: 1:5.2+dfsg-11 Severity: normal X-Debbugs-Cc: marcin.juszkiew...@linaro.org I am maintaining Debian support in OpenStack Kolla project. We are building container images with OpenStack components and provide way to deploy whole OpenStack from them. As we have new release cycle now I looked into possible package upgrades. Newer QEMU in bullseye-backports got my intention. Then I tried to install it: root@puchatek /]# apt-get install --no-install-recommends libvirt-clients libvirt-daemon-system qemu-block-extra qemu-system -t bullseye-backports libvirt-daemon Reading package lists... Done Building dependency tree... Done 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: qemu-system-common : Breaks: libvirt-daemon (< 7.2.0-1) but 7.0.0-3 is to be installed E: Unable to correct problems, you have held broken packages. So it looks like I have to stay with previous version (libvirt maintainer was never fan of backporting libvirt). -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.14.0-0.bpo.2-arm64 (SMP w/16 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-common depends on: ii libaio10.3.112-9 ii libc6 2.31-13+deb11u2 ii libcap-ng0 0.7.9-2.2+b1 ii libgbm120.3.5-1 ii libglib2.0-0 2.66.8-1 ii libgnutls303.7.1-5 ii libnettle8 3.7.3-1 ii libpixman-1-0 0.40.0-1 ii libseccomp22.5.1-1 pn liburing1 pn libvirglrenderer1 ii zlib1g 1:1.2.11.dfsg-2 qemu-system-common recommends no packages. qemu-system-common suggests no packages. -- no debconf information
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
W dniu 08.12.2020 o 11:13, Alper Nebi Yasak pisze: On 08/12/2020 12:26, Marcin Juszkiewicz wrote: Both standard and graphical installer contain kernel modules for virtio framebuffer. And both ignore video output forcing user to use serial console. Also while 'standard' installer gives "d-i in screen", graphical one gave just d-i on serial console. /proc/consoles has only ttyAMA0 This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now. The arm64 graphical installer should be working fine in this release with device-tree systems, which do have tty0 in /proc/consoles. So maybe there should be message "Debian is for SBC, please use $OTHER_DISTRO for servers/etc" on d-i website? You can still work around it with "console=tty0". Even more, the ACPI case is fixed on git (by explicitly checking /dev/tty0), but that didn't make into this alpha release. D-I has issues with AArch64/ACPI systems since probably forever.
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
W dniu 08.12.2020 o 09:06, Ryutaroh Matsumoto pisze: Hi Debian Arm users, I tried Bullseye d-i Alpha3 released on December 6 for building a qemu disk image usable by qemu-system-aarch64. To me, Alpha 3 d-i seems almost unusable for that purpose. I filed a report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 If you have interest, please have a look. Ryutaroh You have started machine in QEMU without any graphics support and got surprised by lack of graphics? But even with "-device virtio-gpu-pci" added Bullseye alpha3 installer follows the path of Buster :( Both standard and graphical installer contain kernel modules for virtio framebuffer. And both ignore video output forcing user to use serial console. Also while 'standard' installer gives "d-i in screen", graphical one gave just d-i on serial console. /proc/consoles has only ttyAMA0 I used fresh build of upstream EDK2. Command used: qemu-system-aarch64 \ -drive if=pflash,format=raw,file=QEMU_EFI.fd \ -drive if=pflash,format=raw,file=QEMU_EFI-vars.fd \ -drive if=virtio,format=raw,readonly=on,media=cdrom,file=debian-bullseye-DI-alpha3-arm64-netinst.iso \ -device virtio-gpu-pci \ -device qemu-xhci,id=usb \ -usb \ -device usb-kbd \ -device usb-tablet \ -machine virt,gic-version=3,iommu=smmuv3 \ -cpu max \ -smp 2 \ -m 4096 \ -monitor telnet::45454,server,nowait \ -serial stdio I gave up on getting sane installer experience in Debian/arm64.
Bug#972940: pmdk: Provide pmdk packages for arm64 for buster
W dniu 26.10.2020 o 13:56, Adam Borowski pisze: On Mon, Oct 26, 2020 at 12:46:01PM +, Marcin Juszkiewicz wrote: Once libfabric gets fixed then pmdk 1.9.1-3 can get most of it's dependencies from buster-backports. Valgrind 0.15 is not available for buster. Without that fix, valgrind tests crash on cache flush instructions. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973009 oponed for Valgrind.
Bug#973009: valgrind: Backport 3.16 to buster
Source: valgrind Severity: normal Could you update version of valgrind package in buster to 3.16? Let me tell you why. Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer one is not available for arm64 architecture (bug [1] reported) 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442 The reason is lack of pmdk build for arm64. Which requires valgrind 3.15+ to pass tests on arm64 (information from bug [2] against pmdk). 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972940 -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#972940: pmdk: Provide pmdk packages for arm64 for buster
Source: pmdk Severity: important Could you provide arm64 version of pmdk package in buster (or buster-backports)? Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer one is not available for arm64 architecture (bug [1] reported) 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442 The reason is lack of pmdk build for arm64. Which requires libfabric. Both those packages are amd64/i386 only in buster. I reported bug [2] against libfabric already. 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972939 Once libfabric gets fixed then pmdk 1.9.1-3 can get most of it's dependencies from buster-backports. Valgrind 0.15 is not available for buster. pmdk 1.9.1-3 compiles for arm64 - it is going through tests while I report bug. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#972939: libfabric: Provide libfabric packages for arm64
Source: libfabric Severity: important Could you provide arm64 version of libfabric package in buster (or buster-backports)? Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer one is not available for arm64 architecture (bug [1] reported) 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442 The reason is lack of pmdk build for arm64. Which requires libfabric. Both those packages are amd64/i386 only in buster. I will report bug against pmdk too. libfabric 1.11.0-2 built fine on buster. 1.6.2-3 requires libpsm-infinipath1-dev package which is not available for arm64. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#971442: qemu: No arm64 package in buster-backports
Source: qemu Version: 1:5.0-14~bpo10+1 Severity: important QEMU 5.0 build depends on libpmem which is x86 only in Buster. Due to this there is no arm64 package available in buster-backports repository. This cause a problem because if we want to use current OpenStack then we are not able to - Nova (compute component) requires QEMU 4.0.0 or latest. Rebuild of qemu backport without pmem support for arm64 looks like the easiest solution. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-11-amd64 (SMP w/5 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#963208: Grub can not be installed on AArch64 board when booted from U-Boot via EFI services
Package: debian-installer Severity: important I am trying to install Debian 'testing' on RockPro64 board. System booted from mainline U-Boot with EFI services enabled. Directly into d-i from 2020.06.15 copy of debian-testing-arm64-netinst.iso [1]. 1. https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso Whole installation went fine until Grub installation: Jun 20 14:44:56 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sdb2 Jun 20 14:44:56 50mounted-tests: debug: mounted using GRUB fat filesystem driver Jun 20 14:44:56 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/40lsb Jun 20 14:44:56 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro Jun 20 14:44:56 grub-installer: info: Installing grub on 'dummy' Jun 20 14:44:57 grub-installer: info: grub-install does not support --no-floppy Jun 20 14:44:57 grub-installer: info: Running chroot /target grub-install --force "dummy" Jun 20 14:44:57 grub-installer: Installing for arm64-efi platform. Jun 20 14:45:01 grub-installer: grub-install: warning: Cannot set EFI variable Boot. Jun 20 14:45:01 grub-installer: grub-install: warning: vars_set_variable: write() failed: Invalid argument. Jun 20 14:45:01 grub-installer: grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: No such file or directory. Jun 20 14:45:01 grub-installer: grub-install: error: failed to register the EFI boot entry: No such file or directory. Jun 20 14:45:01 grub-installer: error: Running 'grub-install --force "dummy"' failed. I see Grub being present in /target/boot/efi: ~ # ls -l /target/boot/efi/ drwx--3 root root 8192 Jun 20 14:44 EFI ~ # ls -l /target/boot/efi/EFI/ drwx--2 root root 8192 Jun 20 14:45 debian ~ # ls -l /target/boot/efi/EFI/debian/ -rwx--1 root root 110 Jun 20 14:45 BOOTAA64.CSV -rwx--1 root root819152 Jun 20 14:45 fbaa64.efi -rwx--1 root root 126 Jun 20 14:45 grub.cfg -rwx--1 root root 1799536 Jun 20 14:45 grubaa64.efi -rwx--1 root root884952 Jun 20 14:45 mmaa64.efi -rwx--1 root root918872 Jun 20 14:45 shimaa64.efi ~ # But 'grub.cfg' in /target/boot/grub/ directory was not created: ~ # ls -l /target/boot/grub/ drwxr-xr-x2 root root 12288 Jun 20 14:45 arm64-efi drwxr-xr-x2 root root 4096 Jun 20 14:45 fonts -rw-r--r--1 root root 1024 Jun 20 14:45 grubenv -rw-r--r--1 root root 2395475 Jun 20 14:44 unicode.pf2 I chrooted to /target and started 'update-grub' by hand to create config file: ~ # chroot /target/ # update-grub Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.6.0-2-arm64 Found initrd image: /boot/initrd.img-5.6.0-2-arm64 done Then I went back to D-I and selected 'continue without boot loader' option. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.13-300.fc32.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds
W dniu 26.05.2020 o 20:33, Alper Nebi Yasak pisze: > Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds >> And that's plain wrong. >> >> I want to run D-I on my monitor. Nevermind is it text mode one or gtk >> one. My board does not require serial console to boot as I have >> graphical output in U-Boot and can control it using USB keyboard. > > I agree they should be included, so I'm changing bug metadata to that > (hopefully correctly). Thanks!
Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used
W dniu 26.05.2020 o 19:25, Alper Nebi Yasak pisze: > On 26/05/2020 20:09, Marcin Juszkiewicz wrote: >> RockPro64 does not enable screen at all. And there are no DRM >> modules in netinstall image [1]: >> >> ~ # cd /lib/modules/5.6.0-1-arm64/ /lib/modules/5.6.0-1-arm64 # >> find . -name *drm* /lib/modules/5.6.0-1-arm64 # >> >> 1. >> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso > >> > There are two initrds in that iso, 'install.a64/initrd.gz' doesn't > have drm modules, but the 'install.a64/gtk/initrd.gz' one has them. > Can you try booting the gtk one? If you boot to GRUB, 'Graphical > Install' should be using that. And that's plain wrong. I want to run D-I on my monitor. Nevermind is it text mode one or gtk one. My board does not require serial console to boot as I have graphical output in U-Boot and can control it using USB keyboard. And I prefer text mode D-I over gtk one. > However, that image is currently broken due to a kernel version > mismatch and won't actually install, try the weekly build instead: > > https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso Thanks. Works like a charm.
Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used
W dniu 26.05.2020 o 16:41, Alper Nebi Yasak pisze: > On 26/05/2020 15:03, Marcin Juszkiewicz wrote: >> Devices with Mali gpu can use 'panfrost' driver to provide working >> framebuffer. And then Debian installer can be run on screen instead of >> serial console. >> >> But 'panfrost' module is not available when d-i starts ;( >> >> So please include 'panfrost' in 'fb-modules' udeb. > > Panfrost shouldn't be necessary for a working framebuffer. On my > rk3399-gru-kevin, rockchipdrmfb handles that and d-i runs on the > screen just fine. > > Which device are you having this issue with? RockPro64 does not enable screen at all. And there are no DRM modules in netinstall image [1]: ~ # cd /lib/modules/5.6.0-1-arm64/ /lib/modules/5.6.0-1-arm64 # find . -name *drm* /lib/modules/5.6.0-1-arm64 # 1. https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used
Package: linux Severity: important Tags: d-i Devices with Mali gpu can use 'panfrost' driver to provide working framebuffer. And then Debian installer can be run on screen instead of serial console. But 'panfrost' module is not available when d-i starts ;( So please include 'panfrost' in 'fb-modules' udeb. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.13-300.fc32.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#960924: librdkafka: Backport 1.4.2 to buster
Source: librdkafka Version: 1.4.2-1 Severity: important I work on getting OpenStack working on AArch64 (arm64) architecture. Using Debian 'buster' as main development platform. The problem is "confluent-kafka" Python package. For x86 arch it is easy as wheel is provided on Pypi.org website. But on other architectures we need to build it. And it requires librdkafka development headers in version newer than one in Buster: building 'confluent_kafka.cimpl' extension [78/1959] creating build/temp.linux-aarch64-3.6 creating build/temp.linux-aarch64-3.6/tmp creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c /tmp/pip-build-b71a1ssk/confluent ka/confluent_kafka/src/confluent_kafka.c -o build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.o In file included from /tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.c:17:0: /tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.h:65:2: error: #error "confluent-kafka-python requires librdkafka v1.4.0 or later. Install the latest version of librdkafka from the Confluent rep ories, see http://docs.confluent.io/current/installation.html; #error "confluent-kafka-python requires librdkafka v1.4.0 or later. Install the latest version of librdkafka from the Confluent repositories, see http://docs.confluent.io/current/installation.html; ^ In file included from /tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.c:17:0: 1.4.2-1 from Debian 'testing' builds fine in 'buster' so maybe it would be possible to get it as official backport? -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.12-300.fc32.x86_64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#950995: [Pkg-libvirt-maintainers] Bug#950995: [arm64] virNetDevGetPhysicalFunction:1391 : internal error: The PF device for VF eth1 has no network device name
W dniu 09.02.2020 o 14:55, Guido Günther pisze: > Thanks for digging out the patches. Marking as fixed in newer versions > then. We might want to fold this into a point release at some point. > Cheers, > -- Guido Any plans for 5.6.0 backport maybe?
Bug#950995: [arm64] virNetDevGetPhysicalFunction:1391 : internal error: The PF device for VF eth1 has no network device name
Source: libvirt
Version: 5.0.0-4
Severity: normal
On AArch64 systems with Cavium ThunderX cpus libvirt refuses to handle
on board network cards:
2018-04-30 15:50:09.053+: 5069: info : hostname: uk-dc-cavium-01
2018-04-30 15:50:09.249+: 5069: error : virNetDevGetPhysicalFunction:1391 :
internal error: The PF device for VF eth0 has no network device name
https://bugs.linaro.org/show_bug.cgi?id=3778 has more details.
Fixes were merged into 5.1.0 upstream release:
>From 6452e2f5e1837bd753ee465e6607ed3c4f62b815 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:12 -0700
Subject: [PATCH 1/4] util: fixing wrong assumption that PF has to have netdev
assigned
>From 10bca495e040ef834760a244a31f8b87391c2378 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:13 -0700
Subject: [PATCH 2/4] util: Code simplification
>From 8fac64db5e7941efb820626f0043f5e0a31c79ee Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:14 -0700
Subject: [PATCH 3/4] util: Fix for NULL dereference
>From 04983c3c6a821f67994b1c65d4d6175f3ac49d69 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:15 -0700
Subject: [PATCH 4/4] util: Fixing invalid error checking from virPCIGetNetname()
Those patches apply to 5.0.0-4 Debian package without any problems.
I have patched version in my repository [1].
1. http://obs.linaro.org/home:/marcin.juszkiewicz/debian-buster/
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.4.0-1-arm64 (SMP w/46 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pl_PL.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)
LSM: AppArmor: enabled
>From 6452e2f5e1837bd753ee465e6607ed3c4f62b815 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:12 -0700
Subject: [PATCH 1/4] util: fixing wrong assumption that PF has to have netdev
assigned
libvirt wrongly assumes that VF netdev has to have the
netdev assigned to PF. There is no such requirement in SRIOV standard.
This patch change the virNetDevSwitchdevFeature() function to deal
with SRIOV devices which does not have netdev on PF. Also corrects
one comment about PF netdev assumption.
One example of such devices is ThunderX VNIC.
By applying this change, VF device is used for virNetlinkCommand() as
it is the only netdev assigned to VNIC.
Signed-off-by: Radoslaw Biernacki
Signed-off-by: dann frazier
Signed-off-by: Michal Privoznik
---
src/util/virnetdev.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1355,9 +1355,8 @@
}
if (!*pfname) {
-/* this shouldn't be possible. A VF can't exist unless its
- * PF device is bound to a network driver
- */
+/* The SRIOV standard does not require VF netdevs to have
+ * the netdev assigned to a PF. */
virReportError(VIR_ERR_INTERNAL_ERROR,
_("The PF device for VF %s has no network device name"),
ifname);
@@ -3178,8 +3177,12 @@
if ((is_vf = virNetDevIsVirtualFunction(ifname)) < 0)
return ret;
-if (is_vf == 1 && virNetDevGetPhysicalFunction(ifname, ) < 0)
-goto cleanup;
+if (is_vf == 1) {
+/* Ignore error if PF does not have netdev assigned.
+ * In that case pfname == NULL. */
+if (virNetDevGetPhysicalFunction(ifname, ) < 0)
+virResetLastError();
+}
pci_device_ptr = pfname ? virNetDevGetPCIDevice(pfname) :
virNetDevGetPCIDevice(ifname);
>From 10bca495e040ef834760a244a31f8b87391c2378 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki
Date: Tue, 22 Jan 2019 12:26:13 -0700
Subject: [PATCH 2/4] util: Code simplification
Removing redundant sections of the code
Signed-off-by: Radoslaw Biernacki
Signed-off-by: dann frazier
Signed-off-by: Michal Privoznik
---
src/util/virnetdev.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1443,29 +1443,20 @@
virNetDevGetVirtualFunctionInfo(const char *vfname, char **pfname,
int *vf)
{
-char *pf_sysfs_path = NULL, *vf_sysfs_path = NULL;
int ret = -1;
*pfname = NULL;
if (virNetDevGetPhysicalFunction(vfname, pfname) < 0)
-return ret;
-
-if (virNetDevSysfsFile(_sysfs_path, *pfname, "device") < 0)
-goto cleanup;
+return -1;
-if (virNetDevSysfsFile(_sysfs_path, vfname, "device") < 0)
+if (virNetDevGetVirtualFunctionIndex(*pfname, vfname, vf) < 0)
goto cleanup;
-ret = virPCIGetVirtualFunctionIndex(pf_sysfs_path, vf_sysfs_path, vf);
-
+ret = 0;
Bug#939470: haproxy: Haproxy fails to install if there is 'haproxy' user already in system
Source: haproxy Severity: normal I am using Kolla to build container images with OpenStack components. One of images contains haproxy. And it fails to build. Part of build is creation of users with fixed UID/GID values. Which works fine for most situations as packages usually are fine with user accounts already existing. But not haproxy ;( root@2a75f0b07b80:/# id haproxy uid=42454(haproxy) gid=42454(haproxy) groups=42454(haproxy) root@2a75f0b07b80:/# apt install haproxy -y Reading package lists... Done Building dependency tree Reading state information... Done haproxy is already the newest version (1.8.19-1). 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up haproxy (1.8.19-1) ... adduser: The user `haproxy' already exists, but is not a system user. Exiting. dpkg: error processing package haproxy (--configure): installed haproxy package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: haproxy E: Sub-process /usr/bin/dpkg returned an error code (1) root@2a75f0b07b80:/# -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925143: ceph-common drags Python 2.7 into system
Package: ceph-common Version: 12.2.11+dfsg1-2 Severity: normal Dear Maintainer, I am working on moving container images built with OpenStack Kolla to use Python 3 where possible. Got images building without Python 2.7 but with one exception: all images involving Ceph (directly or via qemu/libvirt) get Python 2.7 installed. Checked and it looks that 'ceph-common' is to blame: $ aptitude why python2.7 i ceph-common Depends python-rbd (= 12.2.11+dfsg1-2) i A python-rbd Depends python (>= 2.7~) i A python Depends python2.7 (>= 2.7.15-1~) Are there plans to change it? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.10.0-957.5.1.el7.x86_64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages ceph-common depends on: ii libbabeltrace1 1.5.6-2 ii libblkid1 2.33.1-0.1 ii libboost-iostreams1.67.01.67.0-13 ii libboost-program-options1.67.0 1.67.0-13 ii libboost-regex1.67.01.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libboost-thread1.67.0 1.67.0-13 ii libc6 2.28-7 ii libcurl3-gnutls 7.64.0-1 ii libexpat1 2.2.6-1 ii libgcc1 1:8.2.0-21 ii libgoogle-perftools42.7-1 ii libibverbs1 22.1-1 ii libkeyutils11.6-6 ii libldap-2.4-2 2.4.47+dfsg-3 ii libnspr42:4.20-1 ii libnss3 2:3.42.1-1 ii librados2 12.2.11+dfsg1-2 ii libradosstriper112.2.11+dfsg1-2 ii librbd1 12.2.11+dfsg1-2 ii libsnappy1v51.1.7-1 ii libstdc++6 8.2.0-21 ii libudev1240-6 ii python 2.7.15-4 ii python-cephfs 12.2.11+dfsg1-2 ii python-prettytable 0.7.2-4 ii python-rados12.2.11+dfsg1-2 ii python-rbd 12.2.11+dfsg1-2 ii python-requests 2.21.0-1 ii python2.7 2.7.16~rc1-1 ii python3 3.7.2-1 ii python3-prettytable 0.7.2-4 ii zlib1g 1:1.2.11.dfsg-1 ceph-common recommends no packages. Versions of packages ceph-common suggests: pn ceph pn ceph-mds -- no debconf information
Bug#920800: ValueError: could not convert string to float: '6.06 LTS'
Package: lsb-release Version: 10.2018112800 Severity: normal Dear Maintainer, * What led up to the situation? At first this system was Ubuntu 13.04, then 13.10, 14.04 and 16.04 version. Yesterday I upgraded it to Debian 10 with just APT/Aptitude. * What exactly did you do (or not do) that was effective (or ineffective)? $ lsb_release -a * What was the outcome of this action? Traceback (most recent call last): File "/usr/bin/lsb_release", line 95, in main() File "/usr/bin/lsb_release", line 59, in main distinfo = lsb_release.get_distro_information() File "/usr/lib/python3/dist-packages/lsb_release.py", line 356, in get_distro_information distinfo = guess_debian_release() File "/usr/lib/python3/dist-packages/lsb_release.py", line 246, in guess_debian_release get_distro_info(distinfo['ID']) File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in get_distro_info RELEASES_ORDER.sort(key=lambda n: float(n[0])) File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in RELEASES_ORDER.sort(key=lambda n: float(n[0])) ValueError: could not convert string to float: '6.06 LTS' * What outcome did you expect instead? Some sensible output. -- Package-specific info: lsb_release output -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- Apt policy -*- -*- -*- -*- -*- Package files: 100 /var/lib/dpkg/status release a=now 500 https://deb.debian.org/debian buster/main i386 Packages release o=Debian,a=testing,n=buster,l=Debian,c=main,b=i386 origin deb.debian.org 500 https://deb.debian.org/debian buster/main amd64 Packages release o=Debian,a=testing,n=buster,l=Debian,c=main,b=amd64 origin deb.debian.org Pinned packages: -*- -*- -*- -*- -*- sources.list -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- /etc/lsb_release -*- -*- -*- -*- -*- - none -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lsb-release depends on: ii distro-info-data 0.39 ii python3 3.7.2-1 Versions of packages lsb-release recommends: ii apt 1.8.0~beta1 Versions of packages lsb-release suggests: pn lsb -- debconf-show failed
Bug#915628: trickle: Please build for arm64
Package: trickle Severity: normal Trickle is not built for arm64 architecture. It builds fine for it once config.* files get updated. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-323-arm64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages trickle depends on: ii libbsd0 0.8.3-1 ii libc6 2.24-11+deb9u3 pn libevent-2.1-6 trickle recommends no packages. trickle suggests no packages.
Bug#914422: linux: Enable network drivers for Huawei D06 server board
Package: src:linux Version: 4.18.6-1~bpo9+1 Severity: important Attached patch enables network drivers for Huawei D06 server board. With those changes we are able to run debian installer over the network. I can not add kernel boot messages due to lack of access to machine. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-311-arm64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.18.0-0.bpo.1-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-0.bpo.1-arm64 recommends: ii apparmor 2.11.0-3+deb9u2 ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2.3 Versions of packages linux-image-4.18.0-0.bpo.1-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.18 Versions of packages linux-image-4.18.0-0.bpo.1-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information From 727236c28418584658281f8d38b2eee29f95a844 Mon Sep 17 00:00:00 2001 From: Marcin Juszkiewicz Date: Thu, 22 Nov 2018 10:56:15 +0100 Subject: [PATCH] Enable D06 networking - #3962 --- debian/config/arm64/config | 5 + debian/installer/modules/arm64/nic-modules | 4 2 files changed, 9 insertions(+) diff --git a/debian/config/arm64/config b/debian/config/arm64/config index d6ea2ac27a41..5dee724cf1f8 100644 --- a/debian/config/arm64/config +++ b/debian/config/arm64/config @@ -609,6 +609,11 @@ CONFIG_HIP04_ETH=m CONFIG_HNS=m CONFIG_HNS_DSAF=m CONFIG_HNS_ENET=m +CONFIG_HNS3=m +CONFIG_HNS3_HCLGE=m +CONFIG_HNS3_DCB=y +CONFIG_HNS3_HCLGEVF=m +CONFIG_HNS3_ENET=m ## ## file: drivers/net/ethernet/intel/Kconfig diff --git a/debian/installer/modules/arm64/nic-modules b/debian/installer/modules/arm64/nic-modules index 8c17a20c5186..1569da967a49 100644 --- a/debian/installer/modules/arm64/nic-modules +++ b/debian/installer/modules/arm64/nic-modules @@ -11,6 +11,10 @@ hns_mdio hnae hns_dsaf hns_enet_drv +hns3 +hclge +hclgevf +hnae3 nicpf ? nicvf ? thunder_bgx ? -- 2.19.1
Bug#911133: Graphical installer
W dniu 19.10.2018 o 01:03, Ben Hutchings pisze: > On Thu, 2018-10-18 at 19:48 +0200, Marcin Juszkiewicz wrote: >> What we probably need is expanding fb-modules udeb for arm64 with >> several entries: >> >> - radeonfb > > We don't build radeonfb for arm64, since it only supports old Radeon > chips (up to about 2004). > > For current AMD chips the only native driver is amdgpu; for older chips > it's radeon. Both of them will need some firmware just to light up the > display. OK. Last time I used Radeon cards few years ago - before amdgpu driver. HD5450 worked fine in arm64 machine without being initialized by mainboard firmware - Linux was able to get it running with loading it's firmware from hard drive. But yeah - non-free part. Which (according to [1]) can be put on install media by user. 1. https://wiki.debian.org/Firmware >> - nouveau > > This also needs firmware to drive recent chips. It's possible the > driver can set up the display controller without it though. As above. >> - virtio-gpu (for VM guest instances) >> >> This should cover real hardware machines with either AMD Radeon or >> NVidia graphic cards and also virtual machines. >> >> UEFI does not even need to have X86EmulatorPkg to get it working. For >> Radeon cards (not checked with NVidia) kernel can initialize them >> perfectly fine without Option ROM support. >> >> And for VMs it just works with recent EDK2 used. > I really don't think it makes sense to try to support this case. It > seems to be that the proportion of ARM64 systems booting with UEFI > *and* using a plug-in graphics card *and* using that card for display > (rather than off-screen rendering or GPGPU) is likely to be vanishingly > small. Now I know why there is nearly no desktop-class hardware for arm64 - no one believes that it will have any use. When all what is needed is one change to kernel packaging. There are people using Macchiatobin, Synquacer etc boards as their desktops. I do not expect them to have to use serial cables just to install operating system.
Bug#911133: Graphical installer
What we probably need is expanding fb-modules udeb for arm64 with several entries: - radeonfb - nouveau - virtio-gpu (for VM guest instances) This should cover real hardware machines with either AMD Radeon or NVidia graphic cards and also virtual machines. UEFI does not even need to have X86EmulatorPkg to get it working. For Radeon cards (not checked with NVidia) kernel can initialize them perfectly fine without Option ROM support. And for VMs it just works with recent EDK2 used.
Bug#902501: Please enable spice support on arm64
Source: qemu Version: 1:2.12+dfsg-1 Severity: normal Qemu is important component for running OpenStack. And since Queens release we have working graphical console on arm64. But we can not use SPICE as it is not enabled in Debian's qemu package. Sure, VNC works but the only thing which keeps us from using SPICE is enabling it in qemu package. So please enable SPICE support for arm64. It works. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64)
Bug#900055: Please enable seccomp support on arm64
Source: qemu Version: 1:2.12+dfsg-1 Severity: normal Qemu is important component for running OpenStack. But libvirt used by Nova (compute part of OpenStack) is now requiring qemu with seccomp support enabled: libvirtError: internal error: process exited while connecting to monitor: 2018-05-22T09:20:11.610142Z qemu-system-aarch64: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: seccomp support is disabled ARM64 support in seccomp exists for quite a long time so please enable it so we can use qemu for OpenStack without changing package each time we backport it to our stretch environment. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64)
Bug#890340: Unable to checkout Grafana 4.6.3
Package: dh-make-golang Version: 0.0~git20180129.37f630a-1 Go packagers suggest using 'dh-make-golang' to create skeleton package for software written in Go. So I tried it: 16:28 (0s) linaro@cb-r1-m1-c1n1:dh-make-golang$ dh-make-golang -git_revision v4.6.3 github.com/grafana/grafana 2018/02/13 16:28:15 Downloading "github.com/grafana/grafana/..." go get: 240.09 MiB2018/02/13 16:29:38 Checking out git revision "v4.6.3" 2018/02/13 16:29:38 Refreshing "github.com/grafana/grafana/..." go get: 516.27 MiBpackage assert: unrecognized import path "assert" (import path does not begin with hostname) 2018/02/13 16:30:43 Could not create a tarball of the upstream source: exit status 1 Same result with version in 'stretch', 'sid' or with one built from git HEAD.
Bug#884282: erlang: Please build erlang-base-hipe for arm64
Source: erlang Severity: normal Dear Maintainer, I am building OpenStack components as Docker images (using Kolla project as a tool). One of components is 'rabbitmq' for which we grab arch:all package from upstream and install it with rest of dependencies taken from Debian 'stretch' repositories. The problem is that package depends on 'erlang-base-hipe' which is not built for arm64 architecture. I have to admit that I have no idea what that 'hipe' thing is (nor have any knowledge about Erlang). Tried to enable it for arm64 and got it built but do not know how to test does it work. Can it be enabled and tested on arm64? Backport of such change to stretch-backports would be lovely but I can handle package rebuild on my own. -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.14.0-rc7-arm64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports
W dniu 31.10.2017 o 14:36, Balint Reczey pisze: >> But then it is installed to $(pkg-config --variable plugindir wireshark) >> directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while > This is fixed in later version. Which is not present in 'stretch' nor 'stretch-backports' therefore bug is still valid. Please backport the fix.
Bug#880428: libwireshark-dev: plugin dir contains /usr//usr/ breaking libvirt backports
Package: libwireshark-dev
Version: 2.2.6+g32dac6a-2
Severity: normal
Dear Maintainer,
I am backporting libvirt for our use. During build of libvirt 3.6.0+
wireshark dissector is supposed to be built. And it is built. No issues.
But then it is installed to $(pkg-config --variable plugindir wireshark)
directory. Which is /usr//usr/lib/ARCH-NAME-TRIPLET/wireshark/ while
libvirt packaging expects it to be in sane
/usr/lib/ARCH-NAME-TRIPLET/wireshark one.
I checked and the fault is in 'stretch' version of wireshark. Checked
amd64 and arm64 packages and both have plugindir defined wrong:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}//usr/lib/x86_64-linux-gnu
includedir=${prefix}/include
sharedlibdir=${libdir}
plugindir=${libdir}/wireshark/plugins/2.2.6
Please consider fixing it.
-- System Information:
Debian Release: 9.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.14.0-rc4-arm64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libwireshark-dev depends on:
ii libwireshark8 2.2.6+g32dac6a-2
ii libwsutil-dev 2.2.6+g32dac6a-2
libwireshark-dev recommends no packages.
libwireshark-dev suggests no packages.
-- debconf-show failed
Bug#871777: libvirt: Please backport libvirt 3.6.0 to stretch
Source: libvirt Version: 3.6.0-1 Severity: normal Tags: upstream Please backport libvirt 3.6.0 to Debian 'stretch' release. It will provide several fixes for using virtual machines on AArch64 (arm64) architecture. It is first version which supports 'logfile' character devices on arm64 architecture. This allows us to use it with OpenStack without any extra hacking. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.12.0-rc5-arm64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#858903: Mongodb server fails to install if there is 'mongodb' user already in system.
Package: mongodb-server Version: 1:3.2.11-2 Severity: normal I am using Kolla to build container images with OpenStack components. One of images contains mongodb. And it fails to build. Part of build is creation of users with fixed UID/GID values. Which works fine for most situations as packages usually are fine with user accounts already existing. But not mongodb ;( root@6b1baf99f51e:/# id mongodb uid=20007(mongodb) gid=20007(mongodb) groups=20007(mongodb) root@6b1baf99f51e:/# apt install mongodb-server Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: mongodb-clients The following NEW packages will be installed: mongodb-clients mongodb-server 0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded. Need to get 32.6 MB of archives. After this operation, 116 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://deb.debian.org/debian stretch/main amd64 mongodb-clients amd64 1:3.2.11-2 [20.7 MB] Get:2 http://deb.debian.org/debian stretch/main amd64 mongodb-server amd64 1:3.2.11-2 [11.9 MB] Fetched 32.6 MB in 2s (13.9 MB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package mongodb-clients. (Reading database ... 11580 files and directories currently installed.) Preparing to unpack .../mongodb-clients_1%3a3.2.11-2_amd64.deb ... Unpacking mongodb-clients (1:3.2.11-2) ... Selecting previously unselected package mongodb-server. Preparing to unpack .../mongodb-server_1%3a3.2.11-2_amd64.deb ... Unpacking mongodb-server (1:3.2.11-2) ... Setting up mongodb-clients (1:3.2.11-2) ... Setting up mongodb-server (1:3.2.11-2) ... adduser: The user `mongodb' already exists. Exiting. dpkg: error processing package mongodb-server (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mongodb-server E: Sub-process /usr/bin/dpkg returned an error code (1) root@6b1baf99f51e:/# -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.10.3-200.fc25.x86_64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages mongodb-server depends on: ii adduser 3.115 ii init-system-helpers 1.47 ii libboost-chrono1.62.0 1.62.0+dfsg-4 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-program-options1.62.0 1.62.0+dfsg-4 ii libboost-regex1.62.01.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-9 ii libgcc1 1:6.3.0-6 ii libgoogle-perftools42.5-2.2 ii libpcre32:8.39-2.1 ii libpcrecpp0v5 2:8.39-2.1 ii libsnappy1v51.1.3-3 ii libssl1.0.2 1.0.2k-1 ii libstdc++6 6.3.0-6 ii libstemmer0d0+svn585-1+b2 ii libyaml-cpp0.5v50.5.2-4 ii lsb-base9.20161125 ii mongodb-clients 1:3.2.11-2 ii zlib1g 1:1.2.8.dfsg-5 mongodb-server recommends no packages. mongodb-server suggests no packages. -- no debconf information
Bug#827737: FTBFS: AttributeError: You cannot access Response.text unless charset is set
Source: neutron Version: 8.0.0-2 Severity: normal Tags: upstream During build of neutron 8.0.0-2 under Jessie I got: Traceback (most recent call last): File "/tmp/buildd/neutron-8.0.0/neutron/tests/unit/extensions/test_dns.py", line 455, in test_api_extension_validation_with_bad_dns_names 'cannot be converted to lowercase string' in res.text or File "/usr/lib/python2.7/dist-packages/webob/response.py", line 420, in _text__get "You cannot access Response.text unless charset is set") AttributeError: You cannot access Response.text unless charset is set Digged a bit and found bug report in upstream bugtracker: https://bugs.launchpad.net/neutron/+bug/1561151 Where patch is provided and also information that bug is fixed in 8.1.1 version. Please consider update. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.4.0-104-arm64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#816196: extlinux is x86 only
Extlinux should be replaced by grub also because openstack can be used also on non-x86 architectures while extlinux is built ONLY for x86 ones.
Bug#733753: AArch64 support
Take a look at Fedora change [1] as well as it handles LE and BE variants. 1. http://pkgs.fedoraproject.org/cgit/cfitsio.git/commit/?id=d7b88bafc7ee0074b767cbca67adc3f57a5b33d0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668134: AArch64 fix for the same issue
Take a look at upstream change [1] done for AArch64 support. It simplified code in similar way as sh4.diff did. 1. http://sourceforge.net/p/indi/code/1610/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739810: Bug is fixed upstream
I got hit by same issue in Fedora. It was also reported upstream: https://bugzilla.gnome.org/show_bug.cgi?id=724085 and fix was provided and merged upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
::fetchAndAddRelaxed(qptrdiff valueToAdd)
+{
+T *val;
+Q_COMPILER_MEMORY_BARRIER;
+val = __atomic_fetch_add(_q_value, valueToAdd, __ATOMIC_RELAXED);
+Q_COMPILER_MEMORY_BARRIER;
+return val;
+}
+
+inline bool QBasicAtomicInt::testAndSetAcquire(int expectedValue, int newValue)
+{
+bool returnValue = testAndSetRelaxed(expectedValue, newValue);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+inline bool QBasicAtomicInt::testAndSetRelease(int expectedValue, int newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+return testAndSetRelaxed(expectedValue, newValue);
+}
+
+inline bool QBasicAtomicInt::testAndSetOrdered(int expectedValue, int newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+bool returnValue = testAndSetRelaxed(expectedValue, newValue);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+inline int QBasicAtomicInt::fetchAndStoreAcquire(int newValue)
+{
+int returnValue = fetchAndStoreRelaxed(newValue);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+inline int QBasicAtomicInt::fetchAndStoreRelease(int newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+return fetchAndStoreRelaxed(newValue);
+}
+
+inline int QBasicAtomicInt::fetchAndStoreOrdered(int newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+int returnValue = fetchAndStoreRelaxed(newValue);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+inline int QBasicAtomicInt::fetchAndAddAcquire(int valueToAdd)
+{
+int returnValue = fetchAndAddRelaxed(valueToAdd);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+inline int QBasicAtomicInt::fetchAndAddRelease(int valueToAdd)
+{
+Q_DATA_MEMORY_BARRIER;
+return fetchAndAddRelaxed(valueToAdd);
+}
+
+inline int QBasicAtomicInt::fetchAndAddOrdered(int valueToAdd)
+{
+Q_DATA_MEMORY_BARRIER;
+int returnValue = fetchAndAddRelaxed(valueToAdd);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE bool QBasicAtomicPointerT::testAndSetAcquire(T *expectedValue, T *newValue)
+{
+bool returnValue = testAndSetRelaxed(expectedValue, newValue);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE bool QBasicAtomicPointerT::testAndSetRelease(T *expectedValue, T *newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+return testAndSetRelaxed(expectedValue, newValue);
+}
+
+template typename T
+Q_INLINE_TEMPLATE bool QBasicAtomicPointerT::testAndSetOrdered(T *expectedValue, T *newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+bool returnValue = testAndSetAcquire(expectedValue, newValue);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndStoreAcquire(T *newValue)
+{
+T *returnValue = fetchAndStoreRelaxed(newValue);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndStoreRelease(T *newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+return fetchAndStoreRelaxed(newValue);
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndStoreOrdered(T *newValue)
+{
+Q_DATA_MEMORY_BARRIER;
+T *returnValue = fetchAndStoreRelaxed(newValue);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndAddAcquire(qptrdiff valueToAdd)
+{
+T *returnValue = fetchAndAddRelaxed(valueToAdd);
+Q_DATA_MEMORY_BARRIER;
+return returnValue;
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndAddRelease(qptrdiff valueToAdd)
+{
+Q_DATA_MEMORY_BARRIER;
+return fetchAndAddRelaxed(valueToAdd);
+}
+
+template typename T
+Q_INLINE_TEMPLATE T *QBasicAtomicPointerT::fetchAndAddOrdered(qptrdiff valueToAdd)
+{
+Q_DATA_MEMORY_BARRIER;
+T *returnValue = fetchAndAddRelaxed(valueToAdd);
+Q_COMPILER_MEMORY_BARRIER;
+return returnValue;
+}
+
+#undef Q_DATA_MEMORY_BARRIER
+#undef Q_COMPILER_MEMORY_BARRIER
+
+QT_END_NAMESPACE
+
+QT_END_HEADER
+
+#endif // QATOMIC_AARCH64_H
--- qt.orig/src/corelib/arch/qatomic_arch.h
+++ qt/src/corelib/arch/qatomic_arch.h
@@ -94,6 +94,8 @@ QT_BEGIN_HEADER
# include QtCore/qatomic_sh4a.h
#elif defined(QT_ARCH_NACL)
# include QtCore/qatomic_generic.h
+#elif defined(QT_ARCH_AARCH64)
+# include QtCore/qatomic_aarch64.h
#else
# error Qt has not been ported to this architecture
#endif
From 2e049836ee16f4aedbe7ccc3335fc57852725716 Mon Sep 17 00:00:00 2001
From: Riku Voipio riku.voi...@iki.fi
Date: Tue, 7 Jan 2014 16:15:56 +0100
Subject: [PATCH] Detect AArch64 architecture
Adds WTF platform support for the AArch64 architecture.
Patch is based on WebKit-gtk patch done by Riku Voipio, and was
cherry-picked and tested by Marcin Juszkiewicz.
Task-number: QTBUG-35442
Change-Id: Ie6194f3c430cb6513367a3cdf221a41d60a1ed14
Signed-off-by: Riku Voipio riku.voi...@iki.fi
Signed-off-by: Marcin Juszkiewicz mar...@juszkiewicz.com.pl
Reviewed-by: Allan Sandfeld Jensen
Bug#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 29.01.2014 02:27, Lisandro Damián Nicanor Pérez Meyer pisze: Mark: please take a look at [0] for more context or ask Marcin. Quick context: getting AArch64 (aka arm64) Qt4 patches in upstream. Marcin, Mark: to get the code into the Qt4 tree I either need you to: a) push the code to Qt's gerrit instance or b) license the patches as BSD or something equally permissive The (a) case would be the simpler one for us (Qt / all other distros) but you might not be able to do so. So we can still the go the (b) way. In case (b) I would need a mail of each of you (preferably to this bug, 735...@bugs.debian.org) stating that you license the patches as BSD. My patches are usually licensed in a way upstream license a code. For this situation you can consider them to be on CC0 (aka public domain) or simply BSD licenced. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS6OANAAoJECbKqQEReiUeLcMP/0rrHQTHlwzA8N0RhKAc47Bt WhdJV8doN4uVaqCpr29aipjXa3fSy08GX6ViwwpCAxyii+13bD2ahZ/zvE3dn6TW FXVFRqMEi/1Qu66wqDmziLMa6CtixLDQ09/HhZtCzqXxETgYNhGjVRbrRA+fMNOR ExO2y1aEzAQdQ+tWrsuibiaNULsgFSD0x7Xi0ZwSSTn/R3HtCtFWomDY7wOyeLUN dyntH8vkzp7tI7ByuwqjcnfyemuD21ftkbdcGu4irm8nFvTp8Hq95KQ3OSIlRmfM Yc+91LJPk+RMczIUF0JfkET1Hjll8H6KwZ5POztLnbW+pGbr3sriGya7zwU/neRb 646aSyfgUUV6lsOOFgfu/fMoYkbQUyP+HNz1zmSvBq9nfF9g67YLJ8zKYEfatJz7 llEAyTTTrsveDXai23sn6At3Weng23+uzkv0GKq6Eu85CrcF6qcMWFqscjB0xW8/ BkOsFy+l1t6rxC6tMFw7xtmjXrR2j7DGGRu9uZhHtDcSaD8ZVYQ0F9P4HAAu4Ova 8ag9ly6ttVFRuKTsCDjBJUEGJ4yso0YkalrBG1aPhO+QFWLSm9/NUNvniX82oho8 LTLWgX2OWcek0Pdnnu7buv3T2U1iTtjX7v3iDX36nAquxXwNEFv+ZsfCThOKTnBH IwpQYpWOPEZ+iaoCLlbH =GmlU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 23.01.2014 18:57, Lisandro Damián Nicanor Pérez Meyer pisze: I've tried to summarize the current arm64 situation. The following are my conclusions, feel free to point if something is wrong, give more info/feedback, etc. As you know from my blog post [0] Qt/AArch64 patch has long history. 0. http://marcin.juszkiewicz.com.pl/2014/01/20/the-story-of-qtaarch64-patching/ = Stuff under debian/ - As explained in a mail before, we don't like the idea of passing -fpermissive as it can lead to very strange crashes. The code will need proper fixing. - We are building webkit with a separate source, -no-javascript-jit and the relevant webkit patches should be applied in src:qtwebkit. The relevant patches contained in the patch submitted by Wookey come from Riku Voipio and seems too similar to other patches we already have there, so it should not be a problem to apply them once we have Qt4 ready form arm64. - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. = Code patches aarch64.patch: - *No copyright* nor license. We need this at least to be able to apply it and ask upstream if they see it fit. There's the chance that some code comes from Ubuntu people. - Webkit stuff: as described above. If you need that for something: Author: Marcin Juszkiewicz mar...@juszkiewicz.com.pl based on gtkwebkit changes by Riku Voipio riku.voi...@linaro.org License: same as upstream one aarch64_fix_atomic_set.patch: - Copyright present. - Possibly needs the above patch applied. It requires aarch64.patch as it just change two lines. = Some extra remarks We need at least the proper copyright and license for the patches. In that way I'm able to apply them in the package and ping upstream wrt them. Of course, if the original author can push it to upstream's gerrit the better, because in case some objection arises I don't need to be in the middle as a (possibly noisy) proxy. Qt4 patches are not accepted upstream. All new code has to go to Qt5 and since 5.2.0 QAtomics stuff is using std::atomic so compiler takes care of it and there is no code for separate architectures. And all required patches were submitted - just one change to qtwebkit is stuck in review. https://bugreports.qt-project.org/browse/QTBUG-35442 is upstream bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS5owyAAoJECbKqQEReiUedDgQAIoJP8WhTIA+w08/LfuHsGMa gVI5vEtIsMb+IkMDPqFNmWok1//ocmdXPCJJPFRsHT7Nuy2z8I4pmmZFTzG6llgr zrbKb5mP3MCb6/tzv17YtOi3e8Inrz9+Z6YqdMEmhEtnKEO9llLQ55Af1n9ot7NP xB5OSGgWZSmwVpABEuO6+Ehg4wwyjciclC2JJFHUkTgEYjN4fzBDFGg007qS7fNe Q5jArjHnwXyfNFKsdtKWLbh/52IpwXm9t0Sa5OxqWjdmwmAnLo2YHDLrJWlLI1Of 4M7N36ph57huNuuN8pEuLgwM7BHhicK4EoDhjPD4dKisGUwTOaEGGhZMB+d1EjiQ pOCO8NUehWm96JvMmihv1Zb+j2R3q4q8zwwXK1nUQThTTBEE5Mdg63D5TAcHPV5P sL2GjaaKqHgePnQLrxekmZiSHNmfrjcJw12naTGUPsrf+tK4hZ3qGlHwznAKOKwn ZgJEH8mFiTRBNZ83gHSjP8j9NXiHCaxiRNFUL38e6dnYyNyEdz6zB+U4CyaHuEPR h7GQCyVapvHDe5PrA0aXIjVAAQQTw6TI57Ct4lYBdHqDNvBQZIvLr4lP8EYLWVhA gCdia6C7sbjGb96Gio8W8RtEuxhywh+g0wgndgWkF7RjMTXJxw4CFzOi/5WiTdQf topl5mzNXk+tvnb4jn6R =oz85 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
W dniu 27.01.2014 19:20, Wookey pisze: +++ Marcin Juszkiewicz [2014-01-27 17:41 +0100]: - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. I think this is correct. I recall hitting that issue. There was also stuff to do with selecting /lib64 vs /lib IIRC. (/lib is correct for arm64/aarch64). /lib or /lib64 is also distro choice. Are QT4 patches going to be accepted at some point or will distros have to carry an arm64 patch for QT4 as long as it remains supported? Ask in https://bugreports.qt-project.org/browse/QTBUG-35442 please -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 27.01.2014 19:14, Lisandro Damián Nicanor Pérez Meyer pisze: So what we are currently missing should be: - The copyright and license of the qatomic stuff. Author: Mark Salter msal...@redhat.com License: same as upstream one -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS5qZHAAoJECbKqQEReiUeZPQQALLzIGAeCJtUDdk/yBoNv1dh T01VrWX8/aCW1n/DlgAdBGtZm8lTbL/29glib3qhoqLTHDvh4VmQ9kBRRt537vCt 7Qj/v3mDDmZYv5pAyReX7i0N8RRExKWk4alXnBJy62lP3TAGZar4VYjyU5STCIkK NVqs4oE1It38uQObdUaVoDynB0HP1rPsr9UHqZlT716QpORE2qh2PUFDZ4ACZHZh 7bAStNL/JOYqTEGolIm+q8kti3Ozkjx/EdnSjW3yHYy0Ih5PhTtVtqBeWEyv9CXw i5L1TKzV6XFlmm0qHvUHkTKQtidnnpO3/ew5E6tdz8oXVpo9prBVFpO6CE+FPvmn +N6tX+h44fjZ189b1+XB57Z7mV+PrRL6Wk60pKxrJrk5zp9scI0Bb/TEo1FkwPcA CioHrDxCFvywEN15LlUjNQgr2eeO6sPgfaXmrPQ9RAiSX1ojUb8h3BVbqVE8sQHr x1CugZvAGo4v7rSi7paZEGfJdHUWV8+FX/XmeddJq2kqA0icMYLPMPCVc+s7hy3m wLTyACVCFVdaoc6rau8V4pbMgEItvKXkiQueKe4KE5BLBXmVdkT5y+1ltubimrhY 44sQIR1py/gHwQSRrNZ85fio4DpVbzhqwFvAADlJZCbuKr9VNTt9tk9Fz55Gd3+3 LHb+qyxBhHE0vf3R5WN6 =w740 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644520: Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices
W dniu 10.11.2012 08:17, Steve Langasek napisał(a): On Fri, Nov 09, 2012 at 04:57:49PM -0500, Jeremy Bicha wrote: Marcin, since I'm actively using heimdall at the moment, I'd like to get this into the archive sooner rather than later. I've prepared a package with the name from the original ITP, 'heimdall-flash'; I think this is better than 'android-tools-heimdall' since this isn't part of the android-tools upstream. I've also incorporated several fixes from your package, including your patch for the Qt #define conflict. If you're interested in maintaining this package long-term, I'm more than happy to hand it over to you after the initial upload... just as long as it keeps working with my device. ;) (Philipp, the same goes for you as the ITP owner - though you've been marked as owner since June, so maybe you're no longer interested in this package?) In the meantime, I'm uploading my package to the NEW queue. You can find my source package at bzr+ssh://bzr.debian.org/bzr/users/vorlon/heimdall/trunk/. I was asked by one person to take a look and package but I do not have any device supported by heimdall. So if you use it then I think you will be much better maintainer then I would be. Hope you're having fun in Barcelona :) Barcelona was fun, now I am in Palamos (~150km east) for long weekend. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690253: debian-maintainers: Please add Marcin Juszkiewicz as a Debian Maintainer
Package: debian-maintainers Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please add me, Marcin Juszkiewicz mar...@juszkiewicz.com.pl to the Debian Maintainers keyring. jetstring attached. - -- System Information: Debian Release: wheezy/sid APT prefers quantal APT policy: (999, 'quantal'), (50, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel armhf Kernel: Linux 3.5.0-17-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQdun8AAoJECbKqQEReiUeGFEQAIkxRmKOicMuY1BUG7jjGSck S3smrYMDJ4Ci2z5+eAx01zXR449tgyJBOQfx9RmorHhcuwjSdLV/ImC3WYJrlXHk DKhSZW4q7Ql83DmsAXoZNL56d4ACjYJrQ6PL9sKj4Knw0k2ywUxc1ylBguU/9i4r pqCSRFFpxoVasKs+z7B9gxFW+JDYCpLwjLb8mGB7ekUe4miWOl5RqMxeiXETGVvH B9VOw0vowlwB4nJ49Wpe/ArljQ7P/YpK2B5DwupIyew5G8O40rivFFAbSTN8x37B j8iVkf70u0VyVILAm38mmxoQZca1ZDCzpcRPZOhKyglpfIBB5uMY/oTVNLx/jhnL pJbZySD03qmxhUg7FiL/kLx2N++xI0YPAvOLJ8vInuOCgfgh4LqCiMVQxzyHUood swkwDLxwTCAax4VWLPSc7AWXI/A4hsoNTqYHd2tHx+ETz2t6m1mkC5bw5x3mQg4b F1RnT42QLsjocZQWk3ZLKV+h0IBLWETNCFiJsCHBLur3NHKjfrxaTLwMPgqlf9V2 AyLsUB4u/HSFcHhgwjzSD8MtOTqedL5M9JMbPNFx/1pOZITXTR8fxDfZj3NPDPqJ 50QHSmNgnA0kiebKZ/KeIN4wZU4BQ4ONesvq1UP3tbo+cvEfPTtEZRKwiB3iiXCZ 1WYt9a69pG+m4rMQVksr =hNTS -END PGP SIGNATURE- Recommended-By: Hector Oron hector.o...@gmail.com, Steve McIntyre st...@einval.com Agreement: http://lists.debian.org/debian-newmaint/2012/09/msg00012.html Advocates: http://lists.debian.org/debian-newmaint/2012/09/msg00021.html http://lists.debian.org/debian-newmaint/2012/09/msg1.html Comment: Marcin Juszkiewicz mar...@juszkiewicz.com.pl Date: Thu, 11 Oct 2012 17:40:34 +0200 Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBE1kL2EBEADKGnDqvDJRHMyuw2t7DQ57de6ENidRwZHbMYP2r9TDvq4Z8IIR dVaQb8BJs6q4Z5J/frZp78mZNzbOOZ6kdOoUQmeU1qoo8A9rl7FO1VmxLt5hLQ7x 3fC+f/vEMGcenx1TqoRNu8y0HtE7/OgkyDdNaNSVW2/DrmKNOCrmE+Bj/4QmCL9q IotfWNY4+5EqK+zcr0C1VdUri5YP4fUUY6I2GcKkHHtsF2VG32Cktj+j5HFExSok AAP9y5EEeby6/SVKnrf10GnnYhyxRG4YQKcQu2t2ty2XNhuF3tMRUiYo0IBGqwnv i8tqWuDYaCHLYleGgU8vSGrghR/Jw3sgBHa+1s2FHFZ2g4XjWE9i4KoUoXlyoqMK vYdcK1AMvbbTxxdl+f9e7VZ+aNPx9LFobE/+p3hQyhZ+0c2q6NlsYxb3YLsSYODP 56pKszQZpdkNeWWMaMYeSEk1/H1eKqAOnf2iLvrRVhpTejDbSy9UZPeZ0Ng30W4K j83kYgpCkvdXC2grIrpiOlR7GvXLl1nKqq/yAG8Cu4tvdC42SWRxeiSWDWw8lpyi x3RMmejbNhxHCgTkgf0Y6t4GQSScMsgAWS2v/mRQqB2bT8gW6PDtnGByvY0v4F71 YWUnKCsDngvWSYneHPgC8EO+eTHyo24N82SelNXaoytfu0hYVBXOHqPRMQARAQAB tEFNYXJjaW4gSnVzemtpZXdpY3ogKENhbm9uaWNhbCkgPG1hcmNpbi5qdXN6a2ll d2ljekBjYW5vbmljYWwuY29tPokCPgQTAQIAKAUCT/1PwgIbAwUJA8JnAAYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AACgkQJsqpARF6JR4/NA/8CCVyeqvCK1sXPW7w 7kYICqTLrF6XkozPHB95nPB4HpGgwUX+hF2syv6LQDy6CRwOhbYdETaA2MV6Fn5c 1sKMaoQ5HS8bSCQ4WCYdjOPMnK5SUIKBgE81uKaer3XOLVkUmzhT13B979K2Zwg+ gBjCDscO6o7cXJ9xpaRgTPw3vi7Nx+hCKQfP5+tNudXmdKPg5BeDuczd1QJ/s+74 WmluTe5f5GRlSnAedvzgi48uQ5XfdHTL8DiyW56xyLwCAYuv9PYJZSbDjQFq2fLk Ydxbcwcvib0jVZ0BqDSVU+BfMlnKVJ/EYStAMY08gdiWZ8v3QRsyyOkvjWZSaTm4 vFws7qW6pcv0MRcoZFhBwmMrPWbjh4EwHpsN8M83K3OtCqgIAi+Ld1NXi9Jpbvod xZiJEjWTTxS10UEz8Ftfy3QpecpMBcg+TTSts+CqT50zed4ov7lukfXFHK4Axomq NqjS5a+gFQ+RHOtGuFOzWw27sB6WtaMYe7P9mv7T4ozTmHu74YgzDXqAA7rU/apg fv/kCcDZAzZhmxXbizll9b4FDuw0NZLuca2IuPIfcBnj3H42nw4fTFB4ccIDeBg5 8CNnNDOnQBGyjrOVzhZF8JeWk+TiCA3w7N89Z4UOX4inXzngVTMrojAvBPejnkqk oGpnv1AWfpmCSFLGbcsgQLLPgBGJAhwEEAEIAAYFAlBrEu4ACgkQ8RQITAhhERG5 DhAAztn2tFv8ypfV5WAqr/KxkiYl9lpOuVI+0uJHRkVHTcrk/bT7yx38+9KAwSGV 7rVYalmdEx5Yds0lqgQ/+SBQZD8xCkFTHWZd21BNB7w9HSowawOmFDVyyQH29Asp 66ZG7PJMFuSdDwuFzQ7a55nGJQyu2cJ87D7DQ6SipeOuBfwTKtuyssxnEzJyEEjO 2ar6d2d9WQhq0QdS0cxNoUA1Kw2Pg3TwvhVjHOK5mWpwqImri2LJUpGyk1laCHZK +PNMitHThbjktL+xmG4NovqBv7jepqn3AnBfu2roR3jjqpjd6G7ekHt2LPIS08Wv MbOsME/n2FMP/77DU2tUUM+n3xNBtViRrOLmPsfrDs0+76QTu9VteZVXqCUcz9BS 7Z0QmedEFGEE7Tmhv7N2DKwj8yFPDVaMnH+mNUjbfKPcQkRGu4H36vgpQX0fOSJU XHPCCrF+P3LbmGqsN/tFPmelXAOSc7QBYFYAmVwsoZ2PZw3X8OI+Y36RdYS/hUxJ 5VRoLBnyjUNg8eN3+WNgzsZinNeyPQ3sKbABuJLI/Vbcgz4o8ovTjXpM50SVb0si Ivf+mkp2k0dUVsNbacUj3kbQzb+x0rRuUoGKZlRKtxnSnobB7cGZO39U5ori5qdm mKHQut09/oNj6CDpqqFFxJQbneShp+ASblJ8oxXBlA5K+HKIRgQQEQIABgUCUHL2 pwAKCRBRU9AbOjYxL1Y6AJ4mM85lRXayHUZa1YhdMC0cPxCmJQCeNIaxyBev8iC1 gknyIWQds8MMELO0O01hcmNpbiBKdXN6a2lld2ljeiAoTGluYXJvKSA8bWFyY2lu Lmp1c3praWV3aWN6QGxpbmFyby5vcmc+iQI+BBMBAgAoBQJP/U+FAhsDBQkDwmcA BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAmyqkBEXolHuaeD/94c18D+sdr p+gFktJ6BRFhu3Res3G3uHKoiCg0sEOKMbHzNIWPI5M4JE4P+eGm9K8Shn25oWgF avnHQLJb0yLmv48l9HHo6EIAVnC5rXZi58Cofrf+hb2f0C7rFMOXo2vnvew2ql8r HKm4ILiA+Dn6aAfbYZ/nhLv93hZQ8SEGd/MU31l9d4CVxzR9vY+IgqqmHVF5mTeH K+g68NxemiZAs5PTrpnGp6dnEnaLWA/jAoX5kOM8wmhRL637Vm7AA5Evm20GA4kW HACwM0G8VpZTtttCDYNE4kKmDyEsEsaYuVo1/0iyIhzl7T1aVtYyaRjQ6IHHyye/ 1Ym/ZQRxNiJPE5CxfRdCBx2NSVmscw/Lst7PRPyJVOfjYo4NTrp/wSjPJV5JAiPj PON5ynreBtAMm
Bug#688668: iptraf: Fix FTFBS with recent kernels
Package: iptraf Version: 3.0.0-8 Severity: serious Tags: patch Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recent Ubuntu rebuild of iptraf [1] shown that it does not build with recent kernels. Attached patch fixes problem. 1. https://launchpadlibrarian.net/116983818/buildlog_ubuntu-quantal-amd64.iptraf_3.0.0-8_FAILEDTOBUILD.txt.gz - -- System Information: Debian Release: wheezy/sid APT prefers quantal APT policy: (999, 'quantal'), (50, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel armhf Kernel: Linux 3.5.0-15-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iptraf depends on: ii libc62.15-0ubuntu18 ii libncurses5 5.9-10 ii libtinfo55.9-10 iptraf recommends no packages. iptraf suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEUEARECAAYFAlBggxkACgkQeQ6MlGH/2qtBpwCVGc/YbYIaAE3ZnrQ29I9htK0O KwCggvqyXZG/I14qRbEXE9UaA463g+U= =2OYg -END PGP SIGNATURE- diff -aur iptraf-3.0.0/src/hostmon.c iptraf-3.0.0-ubu/src/hostmon.c --- iptraf-3.0.0/src/hostmon.c 2012-09-24 17:55:28.0 +0200 +++ iptraf-3.0.0-ubu/src/hostmon.c 2012-09-24 17:44:36.0 +0200 @@ -31,7 +31,7 @@ #include linux/if_packet.h #include linux/if_ether.h #include linux/if_fddi.h -#include linux/if_tr.h +#include netinet/if_tr.h #include net/if_arp.h #include stdlib.h #include time.h diff -aur iptraf-3.0.0/src/othptab.c iptraf-3.0.0-ubu/src/othptab.c --- iptraf-3.0.0/src/othptab.c 2012-09-24 17:55:28.0 +0200 +++ iptraf-3.0.0-ubu/src/othptab.c 2012-09-24 17:44:36.0 +0200 @@ -32,7 +32,7 @@ /*#include linux/socket.h*/ #include linux/if.h #include linux/if_ether.h -#include linux/if_tr.h +#include netinet/if_tr.h #include linux/if_fddi.h #include linux/if_arp.h #include netdb.h diff -aur iptraf-3.0.0/src/packet.c iptraf-3.0.0-ubu/src/packet.c --- iptraf-3.0.0/src/packet.c 2012-09-24 17:55:28.0 +0200 +++ iptraf-3.0.0-ubu/src/packet.c 2012-09-24 17:44:36.0 +0200 @@ -36,7 +36,7 @@ #include linux/if_packet.h #include linux/if_ether.h #include linux/if_fddi.h -#include linux/if_tr.h +#include netinet/if_tr.h #include linux/sockios.h #include msgboxes.h #include deskman.h diff -aur iptraf-3.0.0/src/tcptable.h iptraf-3.0.0-ubu/src/tcptable.h --- iptraf-3.0.0/src/tcptable.h 2012-09-24 17:55:28.0 +0200 +++ iptraf-3.0.0-ubu/src/tcptable.h 2012-09-24 17:44:36.0 +0200 @@ -22,7 +22,7 @@ #include linux/if_packet.h #include linux/if_ether.h #include linux/if_fddi.h -#include linux/if_tr.h +#include netinet/if_tr.h #include netinet/ip.h #include netinet/udp.h #include servname.h
Bug#644520: heimdall package
At http://tygrysek.juszkiewicz.com.pl/~hrw/debian/heimdall/ I already have some work in progress package for Heimdall flasher. There are things to change in packaging - Paul Wise made a review and pointed me some errors and things to check/fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686183: cross-building binutils fails due to --strip-program setting including paramters
W dniu 29.08.2012 18:39, Wookey pisze:
If binutils is cross-built, using
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -aarmhf -uc -us
This results in install failing because 'install' is run with
--strip-program=arm-linux-gnueabihf-strip --remove-section=.comment
--remove-section=.note
which of course results in 'file not found', because --strip-program is
expecting an
actual binary name.
This works on the native build because
install_binary = install -m 755 -s
i.e. does not include the --strip-program setting.
There is no --strip-options setting in install so far as I can see, so if
this behvaiour
is important then I think it can only be done with a wrapper script.
Attached patch fixes strip problem and also changes debian/control
handling to make sure that proper file is generated for cross builds.
diff -Naur /usr/src/binutils/debian/rules debian/rules
--- /usr/src/binutils/debian/rules 2012-08-22 16:16:16.0 +0200
+++ debian/rules 2012-08-31 14:18:33.770224213 +0200
@@ -105,7 +105,8 @@
CROSS := $(DEB_HOST_GNU_TYPE)-
CC = $(CROSS)gcc
CXX = $(CROSS)g++
- STRIP= $(CROSS)strip --remove-section=.comment --remove-section=.note
+ STRIP= $(CURDIR)/debian/strip.cross
+ #$(CROSS)strip --remove-section=.comment --remove-section=.note
install_binary = install -m 755 -s --strip-program=$(STRIP)
endif
@@ -311,9 +312,12 @@
-rm -rf debian/patched debian/tmp debian/files* debian/substvars
-rm -f debian/*.orig debian/*.rej
-rm -rf $(d_cross) debian/files debian/substvars
- -rm -rf builddir-$(TARGET) {configure,build,install}-cross-stamp
+ -rm -rf builddir-$(TARGET) {configure,build,install}-cross-stamp ontrol-stamp
+ -rm -rf debian/strip.cross
+ cp debian/control.in debian/control
for i in debian/*.in; do \
case $$i in debian/control*.in) continue; esac; \
+ case $$i in debian/strip.cross.in) continue; esac; \
rm -f $${i%*.in}; \
done
@@ -321,7 +325,7 @@
-debian/control: debian/control.in $(if $(TARGET),debian/control.cross.in)
+control-stamp: debian/control.in $(if $(TARGET),debian/control.cross.in)
ifneq (,$(TARGET))
sed /^$$/ q debian/control.in debian/control
sed -e s/__TARGET__/$$(echo -n $(TARGET) | sed s/_/-/g)/ \
@@ -329,6 +333,12 @@
else
cp debian/control.in debian/control
endif
+ifneq (,$(CROSS))
+ sed -e s/__TARGET__/$$(echo -n $(CROSS) | sed s/_/-/g)/ \
+ debian/strip.cross.in debian/strip.cross
+ chmod 755 debian/strip.cross
+endif
+ touch $@
###
# single-arch targets #
@@ -339,7 +349,7 @@
SINGLE_CONFARGS += --enable-ld=default --enable-gold
endif
-configure-single-stamp: patch-stamp debian/control
+configure-single-stamp: patch-stamp control-stamp
$(checkdir)
ifeq ($(with_check),yes)
@@ -919,7 +929,6 @@
dpkg --build $(d_cross) ..
else
- cp debian/control.in debian/control
: # generate some control helper files
nver=$$(echo $(DEB_UPSTREAM) | awk -F. '{ OFS=.; $$NF=$$NF+1; print }'); \
for i in debian/*.in; do \
@@ -1191,7 +1200,7 @@
CONFARGS += --enable-ld=default --enable-gold
endif
-configure-cross-stamp: patch-stamp debian/control
+configure-cross-stamp: patch-stamp control-stamp
$(checkdir)
test != $(TARGET)
rm -rf configure-cross-stamp builddir-$(TARGET)
diff -Naur /usr/src/binutils/debian/strip.cross.in debian/strip.cross.in
--- /usr/src/binutils/debian/strip.cross.in 1970-01-01 01:00:00.0 +0100
+++ debian/strip.cross.in 2012-08-31 13:27:28.766166672 +0200
@@ -0,0 +1 @@
+__TARGET__strip --remove-section=.commend --remove-section=.note $*
Bug#685607: Preliminary package
As 2.1 version contains also ARM related changes we (Linaro) also want to have 2.1 ready. http://people.linaro.org/~hrw/debian/ contains my version of package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459219: android-tools packaging
W dniu 15.08.2012 20:48, Laszlo Boszormenyi (GCS) pisze: On Wed, 2012-08-15 at 16:07 +0200, Adnan Hodzic wrote: On Tue, Aug 14, 2012 at 8:01 PM, Laszlo Boszormenyi (GCS) g...@debian.hu wrote: I think this ITP should be several ones. One for command like tools like adb , one for Eclipse plugin and one for the emulator at least. I never looked too much at Android SDK structure - have it installed on one machine but then decided to create android-tools package cause I was mainly using adb and fastboot commands. ATM Adnan's work is great. I'm a DD and just changed bits in his packaging to be perfect. Thank you for appreciating my work. Which bits did you change because I don't see any chances in the code. I've my own package, not yet uploaded to anywhere. Attached a diff what I've changed. I was wrong by the way, it's Marcin who made a very good package of android-tools. He tries to outsmart debhelper and do some parts by hand. It's not needed, just show debhelper where it can find the files. Also, install manpage as is, not with the binary. Thanks for deb.diff - I am too used to debhelper 7 where all steps were present in debian/rules ;) I would be happy to maintain android-tools with him or me for Debian and he is for Ubuntu but with the same package base. I plan to apply for DM soon so we could co-maintain it in Debian and just request syncs in Ubuntu. But decided to first get some packages sponsored otherwise it would does not have sense. Also why do you think we should separate them in couple of pieces instead of having the installer which could let you select which pieces you want and which you don't? I personally would like to have it all in a single package, thus why I started working on this installer. But you are fetching binaries so I do not think that it may end in 'main' part of Debian. Not to mention lack of support for architectures other then i386/amd64 which mean no adb/fastboot for my Efika MX Smartbook (which runs armhf). May add more CLI tools to android-tools package, but currently it seems to be a good start. Adding more tools is in TODO - so far users of package does not requested other ones. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459219: Android tools
W dniu 27.07.2012 19:56, Adnan Hodzic pisze: I was too busy for last few days so I didn't even get to reply. Either way, just now I publicly published what I have when it comes to android-sdk-installer script. And yes, I'd rather have all those tools as one package as I originally intended if you don't mind. I am fine with it. But do you cover !i386 !amd64 architectures? There are people who are using armel/armhf/mipsel laptops/netbooks and Android devices at same time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682661: ITP: powerdebug -- tool to display regulator, sensor and clock information
Package: wnpp Severity: wishlist Owner: Marcin Juszkiewicz marcin.juszkiew...@linaro.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: powerdebug Version : 0.6.1-2011.10 Upstream Author : Linaro Power Management Working Group linaro-pm...@lists.launchpad.net * URL : https://launchpad.net/linaro-powerdebug * License : EPL-1.0 Programming Lang: C Description : tool to display regulator, sensor and clock information PowerDebug is a tool to display regulator, sensor and clock information. Data is refreshed every few seconds. There is also dump option to display the information just once. .. Tool is mostly useful on non-x86 platforms. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAOkMYACgkQeQ6MlGH/2qua/gCbB8Kd6RxAgFV97iYUsG8oYwxg XVsAn2WPvKXtBRafaRn8t5/E/ejowrV2 =qw19 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459219: Android tools
Hello I packaged Android tools (adb + fastboot) and provide it for Ubuntu in Linaro Tools PPA [1] and also as source on my website [2]. Can you tell me does it have a sense to add it into Debian or rather wait for your Android SDK packages which will provide those tools? 1. https://launchpad.net/~linaro-maintainers/+archive/tools/ 2. http://marcin.juszkiewicz.com.pl/~hrw/debian/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682661: ITP: powerdebug -- tool to display regulator, sensor and clock information
W dniu 24.07.2012 14:50, Konstantin Khomoutov pisze: Package name sounds too generic to me for such a narrow use-case. May be arm-powerdebug? (I googled linaro, and it appears to be centered about ARM SoCs so I suppose this tool is to debug such systems, and hence is why I propose this arm- prefix.) Yes, Linaro is concentrated on ARM but powerdebug is useful also on other architectures like SuperH or MIPS. Or any with clocks and regulators. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680590: FTFBS cross ;(
control.m4 change breaks cross builds:
-
Package: libgcc1-dbg-armhf-cross
Architecture: all
Section: debug
Priority: extra
Depends: gcc-4.7-arm-linux-gnueabihf-base (= ${gcc:Version}),
libgcc1-armhf-cross (= ${gcc:EpochVersion}), ${misc:Depends}
dnldnl
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
.
This package contains files for armhf architecture, for use in
cross-compile
environment.
-
Notice dnldnl. But I see what the problem you had:
-
Package: libgcc1-dbg
Architecture: any
Section: debug
Priority: extra
Depends: gcc-4.7-base (= ${gcc:Version}), libgcc1 (=
${gcc:EpochVersion}), ${misc:Depends}
Provides: libgcc1-dbg-armel [armel], libgcc1-dbg-armhf [armhf]
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
-
This change should satisfy all situations:
diff --git a/debian/control.m4 b/debian/control.m4
index 42714b1..e22374e 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -185,7 +185,7 @@ Architecture: ifdef(`TARGET',`all',`any')
Section: debug
Priority: extra
Depends: BASEDEP, libgcc1`'LS (= ${gcc:EpochVersion}), ${misc:Depends}
-ifdef(`TARGET',`dnl',`dnl
+ifdef(`TARGET',`',`dnl
ifdef(`MULTIARCH',`Multi-Arch: same
')dnl
Provides: libgcc1-dbg-armel [armel], libgcc1-dbg-armhf [armhf]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675511: gcc-4.7: Please drop dpkg-cross build-dependency when building cross-compilers
Acked-by: Marcin Juszkiewicz marcin.juszkiew...@linaro.org This kind of patch was on my todo list for quite long time. It is safe to merge and would be great to get it in wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670200: gdb: ships syscalls decls for unrelated archs
W dniu 24.04.2012 00:03, Yann Dirson pisze: In /usr/share/gdb/syscalls/, the standard gdb package installs many files, seamingly for support of other archs, although set arch will make it obvious that very few of those are indeed usable with the installed binary. This makes it uncomfortable to simultaneously install cross gdb packages from emdebian, as those currently ship the same set of files - and even if they only shipped the relevant ones, there would be conflict on those files they seem the more legitimate to ship. Maybe we can merge Ubuntu changes to get gdb-multiarch package instead of building gdb/cross per architecture. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666389: klibc: Fails to cross build
Package: klibc
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Klibc fails to cross build for armel architecture:
http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/klibc_1.5.25-1ubuntu1-precise-ma-cross-armel-20120323-023815.34378.log
echo 'multiarch_path=arm-linux-gnueabi' klcc/klibc.config
perl klcc/makeklcc.pl /«PKGBUILDDIR»/klcc/klcc.in klcc/klibc.config
/usr/bin/perl klcc/klcc || ( rm -f klcc/klcc ; exit 1 ) chmod a+x klcc/klcc
:
make -f /«PKGBUILDDIR»/scripts/Kbuild.klibc obj=.
make -rR -f /«PKGBUILDDIR»/scripts/Kbuild.klibc obj=scripts/basic
gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c
:
make -rR -f /«PKGBUILDDIR»/scripts/Kbuild.klibc obj=usr/klibc
arm-linux-gnueabi-gcc -Wp,-MD,usr/klibc/.__static_init.o.d -nostdinc
-iwithprefix include -I/«PKGBUILDDIR»/usr/include/arch/x86_64
-Iusr/include/arch/x86_64 -I/«PKGBUILDDIR»/usr/include/bits64
-Iusr/include/bits64 -I/«PKGBUILDDIR»/usr/klibc/../include
-Iusr/klibc/../include -I/«PKGBUILDDIR»/usr/include -Iusr/include
-I/«PKGBUILDDIR»/linux/include -Ilinux/include
-I/«PKGBUILDDIR»/linux/arch/x86/include -Ilinux/arch/x86/include -D__KLIBC__=1
-D__KLIBC_MINOR__=5 -D_BITSIZE=64 -fno-stack-protector -fwrapv -m64 -Os
-fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1
-falign-jumps=1 -falign-loops=1 -W -Wall -Wno-sign-compare
-Wno-unused-parameter -c -o usr/klibc/__static_init.o usr/klibc/__static_init.c
cc1: error: unrecognized command line option '-m64'
make[4]: *** [usr/klibc/__static_init.o] Error 1
make[3]: *** [all] Error 2
make[2]: *** [klibc] Error 2
make[2]: Leaving directory `/«PKGBUILDDIR»'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
For armhf it fails later:
make -f /tmp/porting/klibc-1.5.25/scripts/Kbuild.install obj=.
echo INSTALL headers + man pages to debian/tmp/usr/lib/klibc
INSTALL headers + man pages to debian/tmp/usr/lib/klibc
mkdir -p debian/tmp/usr/bin
mkdir -p debian/tmp/usr/man/man1
mkdir -p debian/tmp/lib
mkdir -p debian/tmp/usr/lib/klibc
rm -rf debian/tmp/usr/lib/klibc/include
mkdir -p debian/tmp/usr/lib/klibc/include
mkdir -p debian/tmp/usr/lib/klibc/lib
mkdir -p debian/tmp/usr/lib/klibc/bin
if [ -n arm-linux-gnueabihf ]; then \
ln -s /usr/include/arm-linux-gnueabihf/asm
debian/tmp/usr/lib/klibc/include/ || exit; \
fi
for x in /usr/include/linux /usr/include/asm*; do \
ln -s ${x} debian/tmp/usr/lib/klibc/include/ || exit; \
done
ln: failed to create symbolic link `debian/tmp/usr/lib/klibc/include/asm': File
exists
make[3]: *** [header] Error 1
make[2]: *** [install] Error 2
make[2]: Leaving directory `/tmp/porting/klibc-1.5.25'
make[1]: *** [override_dh_auto_install] Error 2
make[1]: Leaving directory `/tmp/porting/klibc-1.5.25'
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1350:
dpkg-buildpackage -rfakeroot -d -us -uc -b -aarmhf -nc failed
Attached patch adds ARCH=arm which is needed when cross building for
armel architecture. Also I am patching order of symlinks done by
klibc-linux-libc-dev patch to make sure that build will use
/usr/include/asm/ of target architecture.
- -- System Information:
Debian Release: wheezy/sid
APT prefers precise-updates
APT policy: (999, 'precise-updates'), (999, 'precise'), (500,
'precise-security'), (50, 'precise')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-20-generic (SMP w/8 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk91hkkACgkQeQ6MlGH/2qs+OQCfbGvGbTy1ulO+JS5nfvUJPc2t
KmIAnRcLXlDOYPcL8hPY+AA397pGdz7Y
=e5/E
-END PGP SIGNATURE-
diff -Nru klibc-2.0~rc3/debian/changelog klibc-2.0~rc3/debian/changelog
--- klibc-2.0~rc3/debian/changelog 2012-03-02 11:08:54.0 +0100
+++ klibc-2.0~rc3/debian/changelog 2012-03-30 12:06:21.0 +0200
@@ -1,3 +1,9 @@
+klibc (2.0~rc3-2) unstable; urgency=low
+
+ * Fix cross building - LP: #963047
+
+ -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Fri, 30 Mar 2012 12:05:41 +0200
+
klibc (2.0~rc3-1) unstable; urgency=low
* New upstream snapshot (closes: #653790)
diff -Nru klibc-2.0~rc3/debian/patches/fix-cross-build klibc-2.0~rc3/debian/patches/fix-cross-build
--- klibc-2.0~rc3/debian/patches/fix-cross-build 1970-01-01 01:00:00.0 +0100
+++ klibc-2.0~rc3/debian/patches/fix-cross-build 2012-03-30 12:03:03.0 +0200
@@ -0,0 +1,32 @@
+Author: Marcin Juszkiewicz marcin.juszkiew...@linaro.org
+Description: fix cross build
+
+When klibc is cross built we want /usr/include/DEB_HOST_MULTIARCH/asm as
+include/asm not /usr/include
Bug#665965: FTCBFS: Cross build calls wrong-arch strip
Package: dash Version: 0.5.7-2ubuntu1 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dash does not call the correct arch strip so cross-builds fail right at the end. debian/rules binary rm -rf '/tmp/dash-0.5.7/debian/ash' install -d -m0755 '/tmp/dash-0.5.7/debian/ash'/bin ln -s dash '/tmp/dash-0.5.7/debian/ash'/bin/ash install -d -m0755 '/tmp/dash-0.5.7/debian/ash'/usr/share/man/man1/ ln -s dash.1.gz '/tmp/dash-0.5.7/debian/ash'/usr/share/man/man1/ash.1.gz # changelog test -r changelog || ln -s ChangeLog changelog # dash rm -rf '/tmp/dash-0.5.7/debian/dash' install -d -m0755 '/tmp/dash-0.5.7/debian/dash'/bin install -m0755 build-tmp/src/dash '/tmp/dash-0.5.7/debian/dash'/bin/dash strip -R .comment -R .note '/tmp/dash-0.5.7/debian/dash'/bin/dash strip: Unable to recognise the format of the input file `/tmp/dash-0.5.7/debian/dash/bin/dash' make: *** [install-arch] Error 1 dpkg-buildpackage: error: debian/rules binary gave error exit status 2 - -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (999, 'precise-updates'), (999, 'precise'), (500, 'precise-security'), (50, 'precise') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-14-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dash depends on: ii debianutils 4.2.1ubuntu1 ii dpkg 1.16.1.2ubuntu5 ii libc62.15-0ubuntu6 dash recommends no packages. dash suggests no packages. - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9xre4ACgkQeQ6MlGH/2qtvGQCePZayJHfXesL8qls+FGstI72d lCwAoIuINuuMMpTcJLQj909ajbyDfQTa =i6VE -END PGP SIGNATURE- diff -u dash-0.5.7/debian/rules dash-0.5.7/debian/rules --- dash-0.5.7/debian/rules +++ dash-0.5.7/debian/rules @@ -8,6 +8,7 @@ DEB_BUILD_GNU_TYPE =$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CC =$(DEB_HOST_GNU_TYPE)-gcc + STRIP =$(DEB_HOST_GNU_TYPE)-strip endif ifneq (,$(findstring diet,$(DEB_BUILD_OPTIONS))) diff -u dash-0.5.7/debian/changelog dash-0.5.7/debian/changelog --- dash-0.5.7/debian/changelog +++ dash-0.5.7/debian/changelog @@ -1,3 +1,9 @@ +dash (0.5.7-2ubuntu2) precise; urgency=low + + * Ensure correct strip is called when cross-building LP: #966103 + + -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Tue, 27 Mar 2012 10:31:15 + + dash (0.5.7-2ubuntu1) precise; urgency=low * Merge from Debian testing, remaining changes:
Bug#665971: FTCBFS: Cross build calls wrong-arch strip
Package: dash Version: 0.5.7-2ubuntu1 Severity: normal Tags: patch Dash does not call the correct arch strip so cross-builds fail right at the end. debian/rules binary rm -rf '/tmp/dash-0.5.7/debian/ash' install -d -m0755 '/tmp/dash-0.5.7/debian/ash'/bin ln -s dash '/tmp/dash-0.5.7/debian/ash'/bin/ash install -d -m0755 '/tmp/dash-0.5.7/debian/ash'/usr/share/man/man1/ ln -s dash.1.gz '/tmp/dash-0.5.7/debian/ash'/usr/share/man/man1/ash.1.gz # changelog test -r changelog || ln -s ChangeLog changelog # dash rm -rf '/tmp/dash-0.5.7/debian/dash' install -d -m0755 '/tmp/dash-0.5.7/debian/dash'/bin install -m0755 build-tmp/src/dash '/tmp/dash-0.5.7/debian/dash'/bin/dash strip -R .comment -R .note '/tmp/dash-0.5.7/debian/dash'/bin/dash strip: Unable to recognise the format of the input file `/tmp/dash-0.5.7/debian/dash/bin/dash' make: *** [install-arch] Error 1 dpkg-buildpackage: error: debian/rules binary gave error exit status 2 - -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (999, 'precise-updates'), (999, 'precise'), (500, 'precise-security'), (50, 'precise') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-14-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dash depends on: ii debianutils 4.2.1ubuntu1 ii dpkg 1.16.1.2ubuntu5 ii libc62.15-0ubuntu6 dash recommends no packages. dash suggests no packages. - -- debconf information excluded diff -u dash-0.5.7/debian/rules dash-0.5.7/debian/rules --- dash-0.5.7/debian/rules +++ dash-0.5.7/debian/rules @@ -8,6 +8,7 @@ DEB_BUILD_GNU_TYPE =$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CC =$(DEB_HOST_GNU_TYPE)-gcc + STRIP =$(DEB_HOST_GNU_TYPE)-strip endif ifneq (,$(findstring diet,$(DEB_BUILD_OPTIONS))) diff -u dash-0.5.7/debian/changelog dash-0.5.7/debian/changelog --- dash-0.5.7/debian/changelog +++ dash-0.5.7/debian/changelog @@ -1,3 +1,9 @@ +dash (0.5.7-2ubuntu2) precise; urgency=low + + * Ensure correct strip is called when cross-building LP: #966103 + + -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Tue, 27 Mar 2012 10:31:15 + + dash (0.5.7-2ubuntu1) precise; urgency=low * Merge from Debian testing, remaining changes:
Bug#657139: elfutils: Multi-arch support
Package: elfutils
I added Multi-arch support into elfutils package to be able to install
amd64 and armel versions at same time.
Built rpm, kcov, systemtap, makedumpfile with resulting packages.
- -- System Information:
Debian Release: wheezy/sid
APT prefers precise-updates
APT policy: (999, 'precise-updates'), (999, 'precise'), (999,
'oneiric'), (500, 'precise-security'), (50, 'precise')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-10-generic (SMP w/8 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages elfutils depends on:
ii libasm1 0.152-1ubuntu3
ii libc62.13-24ubuntu4
ii libdw1 0.152-1ubuntu3
ii libelf1 0.152-1ubuntu3
elfutils recommends no packages.
elfutils suggests no packages.
- -- no debconf information
diff -Nru elfutils-0.152/debian/changelog elfutils-0.152/debian/changelog
--- elfutils-0.152/debian/changelog 2011-11-02 14:07:02.0 +0100
+++ elfutils-0.152/debian/changelog 2012-01-24 13:01:38.0 +0100
@@ -1,3 +1,11 @@
+elfutils (0.152-1ubuntu3) precise; urgency=low
+
+ * Convert to multiarch.
+ * Added build-{arch,indep} targets.
+ * Switched to use 'dh_prep' instead of 'dh_clean -k'
+
+ -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Tue, 24 Jan 2012 12:39:33 +0100
+
elfutils (0.152-1ubuntu2) precise; urgency=low
* Rebuild for liblzma5.
diff -Nru elfutils-0.152/debian/compat elfutils-0.152/debian/compat
--- elfutils-0.152/debian/compat 2009-03-10 20:07:51.0 +0100
+++ elfutils-0.152/debian/compat 2012-01-24 12:38:49.0 +0100
@@ -1 +1 @@
-5
+9
diff -Nru elfutils-0.152/debian/control elfutils-0.152/debian/control
--- elfutils-0.152/debian/control 2010-04-24 13:23:00.0 +0200
+++ elfutils-0.152/debian/control 2012-01-24 13:12:42.0 +0100
@@ -2,7 +2,7 @@
Priority: optional
Maintainer: Kurt Roeckx k...@roeckx.be
Uploaders: Christian Aichinger gre...@gmx.net
-Build-Depends: debhelper (= 5.0.0), autotools-dev, bzip2, zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext
+Build-Depends: debhelper (= 8.1.3), autotools-dev, bzip2, zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext
Build-Conflicts: autoconf2.13, automake1.4
Standards-Version: 3.8.4
Section: libs
@@ -11,6 +11,7 @@
Package: elfutils
Section: utils
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, libdw1 (= ${binary:Version}), ${misc:Depends}
Description: collection of utilities to handle ELF objects
Elfutils is a collection of utilities, including eu-ld (a linker),
@@ -21,7 +22,9 @@
Package: libelf1
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
Description: library to read and write ELF files
The libelf1 package provides a shared library which allows reading and
writing ELF files on a high level. Third party programs depend on
@@ -33,6 +36,7 @@
Package: libelf-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: libelf1 (= ${binary:Version}), ${misc:Depends}
Conflicts: libelfg0-dev
Description: libelf1 development libraries and header files
@@ -44,6 +48,7 @@
Package: libdw-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: libelf-dev, libdw1 (= ${binary:Version}), ${misc:Depends}
Description: libdw1 development libraries and header files
libdw1 provides a library that provides access to DWARF debug information
@@ -56,7 +61,9 @@
Package: libdw1
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
Description: library that provides access to the DWARF debug information
libdw1 provides a library that provides access to DWARF debug information
stored inside ELF files.
@@ -65,7 +72,9 @@
Package: libasm1
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
Description: library with a programmable assembler interface
The libasm1 package provides a library with a programmable assembler
interface. It allows you to create ELF files on a low level.
@@ -75,6 +84,7 @@
Package: libasm-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: libasm1 (= ${binary:Version}), libelf-dev, ${misc:Depends}
Conflicts: libelfsh0-dev, libasm0-dev
Description: libasm development libraries and header files
diff -Nru elfutils-0.152/debian/libasm1.install elfutils-0.152/debian/libasm1.install
--- elfutils-0.152/debian/libasm1.install 2009-03-10 20:07:51.0 +0100
+++ elfutils-0.152/debian/libasm1.install 2012-01-24 12:45:36.0 +0100
@@ -1,2 +1,2 @@
-usr/lib/libasm.so.1
-usr/lib/libasm-*.so
+usr/lib/*/libasm.so.1
+usr/lib/*/libasm-*.so
diff -Nru elfutils-0.152/debian/libasm-dev.install elfutils-0.152/debian/libasm-dev.install
--- elfutils-0.152/debian/libasm-dev.install 2009-03-10 20:07:51.0 +0100
+++ elfutils-0.152/debian/libasm-dev.install 2012-01-24 12:39:09.0 +0100
@@ -1,3
Bug#644439: Bootstrap stage1 cross-compiler depends on nonexistent libgcc
When compiling a GCC stage1 cross-compiler, the generated control file depends on libgcc even when one is not built, making it impossible to install the stage1 compiler to prepare for stage2. I have to admit that I never installed stage1 or stage2 packages - I only unpack them and use for next bootstrap step: http://anonscm.debian.org/gitweb/?p=collab-maint/cross-toolchain.git;a=shortlog;h=refs/heads/armel-cross-toolchain-base Will take a look at your patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644439: Bootstrap stage1 cross-compiler depends on nonexistent libgcc
W dniu 07.10.2011 11:48, Marcin Juszkiewicz pisze: When compiling a GCC stage1 cross-compiler, the generated control file depends on libgcc even when one is not built, making it impossible to install the stage1 compiler to prepare for stage2. I have to admit that I never installed stage1 or stage2 packages - I only unpack them and use for next bootstrap step: http://anonscm.debian.org/gitweb/?p=collab-maint/cross-toolchain.git;a=shortlog;h=refs/heads/armel-cross-toolchain-base Will take a look at your patch. Tested-by: Marcin Juszkiewicz marcin.juszkiew...@linaro.org patch is sane - please merge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626672: raxml should be x86 only
I looked at raxml failure on armel in Ubuntu [1] and then got information about Debian bug [2]. raxml is using xmmintrin.h header file which is available only for x86 architectures (amd64/i386). Inside are functions which calls ASM mnemonics directly. So it looks like package is buildable only on those 2 architectures (under Debian also will build for kFreeBSD ones). I made debdiff which makes a change - it is available at Launchpad [3]. 1. https://bugs.launchpad.net/ubuntu/+source/raxml/+bug/791321 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626672 3. https://launchpadlibrarian.net/73207596/raxml.debdiff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626671: fix for monav
Attached patch drops all uses of -march=native from monav source
package. Build tested under Ubuntu/armel.
diff -Nru monav-0.3/debian/changelog monav-0.3/debian/changelog
--- monav-0.3/debian/changelog 2011-06-11 19:19:27.0 +0200
+++ monav-0.3/debian/changelog 2011-06-15 14:49:50.0 +0200
@@ -1,3 +1,9 @@
+monav (0.3-3build2) oneiric; urgency=low
+
+ * Drop -march=native as this is not available on !x86 architectures.
+
+ -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Wed, 15 Jun 2011 14:49:22 +0200
+
monav (0.3-3build1) oneiric; urgency=low
* No change rebuild for protobuf transition.
diff -Nru monav-0.3/debian/patches/05-drop-march-native.patch monav-0.3/debian/patches/05-drop-march-native.patch
--- monav-0.3/debian/patches/05-drop-march-native.patch 1970-01-01 01:00:00.0 +0100
+++ monav-0.3/debian/patches/05-drop-march-native.patch 2011-06-15 16:15:42.0 +0200
@@ -0,0 +1,131 @@
+Description: Drop -march=native as this is not available on !x86 architectures
+Author: Marcin Juszkiewicz marcin.juszkiew...@linaro.org
+Origin: other
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626671
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/monav/+bug/791312
+Forwarded: no
+Last-Update: 2011-06-15
+
+--- monav-0.3.orig/plugins/gpsgrid/gpsgrid.pro
monav-0.3/plugins/gpsgrid/gpsgrid.pro
+@@ -28,7 +28,6 @@ HEADERS += ../../interfaces/ipreprocesso
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+--- monav-0.3.orig/plugins/testimporter/testimporter.pro
monav-0.3/plugins/testimporter/testimporter.pro
+@@ -10,7 +10,7 @@ SOURCES += \
+ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+- QMAKE_CXXFLAGS_RELEASE += -O3 -march=native -Wno-unused-function
++ QMAKE_CXXFLAGS_RELEASE += -O3 -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+
+--- monav-0.3.orig/plugins/contractionhierarchies/contractionhierarchies.pro
monav-0.3/plugins/contractionhierarchies/contractionhierarchies.pro
+@@ -7,7 +7,6 @@ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function \
+ -fopenmp
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function \
+--- monav-0.3.orig/plugins/osmrenderer/qtilerenderer.pro
monav-0.3/plugins/osmrenderer/qtilerenderer.pro
+@@ -21,7 +21,6 @@ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+--- monav-0.3.orig/plugins/osmrenderer/mapnikrenderer.pro
monav-0.3/plugins/osmrenderer/mapnikrenderer.pro
+@@ -16,7 +16,6 @@ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function \
+ -fopenmp
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function \
+--- monav-0.3.orig/plugins/osmrenderer/osmrenderer.pro
monav-0.3/plugins/osmrenderer/osmrenderer.pro
+@@ -13,7 +13,6 @@ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+--- monav-0.3.orig/plugins/unicodetournamenttrie/unicodetournamenttrie.pro
monav-0.3/plugins/unicodetournamenttrie/unicodetournamenttrie.pro
+@@ -26,7 +26,7 @@ HEADERS += unicodetournamenttrie.h \
+
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+- QMAKE_CXXFLAGS_RELEASE += -O3 -march=native -Wno-unused-function
++ QMAKE_CXXFLAGS_RELEASE += -O3 -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+
+--- monav-0.3.orig/plugins/osmimporter/osmimporter.pro
monav-0.3/plugins/osmimporter/osmimporter.pro
+@@ -31,7 +31,7 @@ SOURCES += osmimporter.cpp \
+ DESTDIR = ../../bin/plugins_preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+- QMAKE_CXXFLAGS_RELEASE += -O3 -march=native -Wno-unused-function
++ QMAKE_CXXFLAGS_RELEASE += -O3 -Wno-unused-function
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function
+ }
+
+--- monav-0.3.orig/preprocessor/preprocessor-gui.pro
monav-0.3/preprocessor/preprocessor-gui.pro
+@@ -45,7 +45,6 @@ FORMS += preprocessingwindow.ui \
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function \
+ -fopenmp
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function \
+--- monav-0.3.orig/preprocessor/preprocessor.pro
monav-0.3/preprocessor/preprocessor.pro
+@@ -39,7 +39,6 @@ TARGET = monav-preprocessor
+ unix {
+ QMAKE_CXXFLAGS_RELEASE -= -O2
+ QMAKE_CXXFLAGS_RELEASE += -O3 \
+- -march=native \
+ -Wno-unused-function \
+ -fopenmp
+ QMAKE_CXXFLAGS_DEBUG += -Wno-unused-function \
+--- monav-0.3.orig
Bug#623791:
I think that patching debian/control.m4 is just work around. It should be cleaned up to get rid of special handling of cross target so one set of rules will be used for all targets. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619939: ncurses: Fix dh_strip usage
Package: ncurses Severity: minor Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ncurses debian/rules calls dh_strip with -X$(package-dbg) - -X$(package-dbgw) -X$(package-libw) where -N should be used. -Npackage, --no-package=package Do not act on the specified package even if an -a, -i, or -p option lists the package as one that should be acted on. -Xitem, --exclude=item Exclude files that contain item anywhere in their filename from being stripped. You may use this option multiple times to build up a list of things to exclude. Debdiff attached. - -- System Information: Debian Release: squeeze/sid APT prefers natty APT policy: (999, 'natty') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-7-generic (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2Qk/0ACgkQeQ6MlGH/2qteWQCfQ73L9kMs0/GBY0+u4MlFDYLP LjwAn1A4bdlOZ7w2K2yiwXkuAmNZGKBi =6DN3 -END PGP SIGNATURE- diff -Nru ncurses-5.7+20101128/debian/changelog ncurses-5.7+20101128/debian/changelog --- ncurses-5.7+20101128/debian/changelog 2010-12-20 03:41:51.0 +0100 +++ ncurses-5.7+20101128/debian/changelog 2011-03-28 15:44:37.0 +0200 @@ -1,3 +1,10 @@ +ncurses (5.7+20101128-1ubuntu1) natty; urgency=low + + * Use -N instead of -X to exclude separate -dbg packages from dh_strip call. +Change suggested by Martin Pitt. + + -- Marcin Juszkiewicz marcin.juszkiew...@linaro.org Mon, 28 Mar 2011 15:43:29 +0200 + ncurses (5.7+20101128-1) experimental; urgency=low [ Sven Joachim ] diff -Nru ncurses-5.7+20101128/debian/rules ncurses-5.7+20101128/debian/rules --- ncurses-5.7+20101128/debian/rules 2010-12-18 13:23:42.0 +0100 +++ ncurses-5.7+20101128/debian/rules 2011-03-28 15:43:24.0 +0200 @@ -366,8 +366,8 @@ dh_installdirs -s # Strip the packages, shipping detached debugging symbols. Need to strip - # $(package-devw) separately, because -X$(package-libw) excludes it. - dh_strip -s -X$(package-dbg) -X$(package-dbgw) -X$(package-libw) \ + # $(package-devw) separately, because -N$(package-libw) excludes it. + dh_strip -s -N$(package-dbg) -N$(package-dbgw) -N$(package-libw) \ --dbg-package=$(package-dbg) dh_strip -p$(package-devw) dh_strip -p$(package-libw) --dbg-package=$(package-dbgw)
Bug#619939: ncurses: Fix dh_strip usage
Dnia 2011-03-28, pon o godzinie 17:14 +0200, Sven Joachim pisze: On 2011-03-28 15:58 +0200, Marcin Juszkiewicz wrote: Ncurses debian/rules calls dh_strip with -X$(package-dbg) -X$(package-dbgw) -X$(package-libw) where -N should be used. Thanks for spotting that. It does not seem to make any difference in the content of the binary packages, right? I found issue with pkg-create-dbgsym while playing with cross building ncurses and this was line where it failed. Issue was found in few minutes and fixed as it was bug in pkg-create-dbgsym but the use of -X got attention so I checked does it works if done properly with -N argument. Did not compared contents of packages but they should be exactly the same. # Strip the packages, shipping detached debugging symbols. Need to strip - # $(package-devw) separately, because -X$(package-libw) excludes it. - dh_strip -s -X$(package-dbg) -X$(package-dbgw) -X$(package-libw) \ + # $(package-devw) separately, because -N$(package-libw) excludes it. Actually that comment is no longer correct either, if it ever was, so… :) dh_strip -p$(package-devw) …this line can be ditched, it seems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619400: dpkg-cross does not do sensible things with multi-arch: same packages
Package: dpkg-cross
Version: 2.6.3ubuntu1
Severity: important
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a copy of Ubuntu bug #739151
https://bugs.launchpad.net/ubuntu/+source/dpkg-cross/+bug/739151
Running dpkg-cross against the Multi-Arch: same version of libc6
currently in natty does not produce sensible output. Instead it
generates a .deb that contains only a large number of iconv .so modules
under /usr/x86_64-linux-gnu/include, e.g.:
./usr/x86_64-linux-gnu/include/gconv/libCNS.so
I have no idea why it's installing to include. The source location was
../usr/lib/x86_64-linux-gnu/gconv/.
It might seem that it's not a big deal for dpkg-cross to not handle
multiarch packages since multiarch packages can just be installed
directly; but since we can't use foreign-architecture build dependencies
on the buildds yet, cross-toolchain packages in the archive (such as
armel-cross-toolchain-base) need to build using gcc-4.5-source,
eglibc-source, etc. and run dpkg-cross afterwards to output their binary
packages. So the armel cross-compiler in the archive isn't buildable
until this is resolved.
I've checked with dpkg-cross 2.6.2 from Debian unstable; the same
problem is present there.
- -- Package-specific info:
- -- /etc/dpkg-cross/cross-compile --
#
# /etc/dpkg-cross/cross-compile: configuration for dpkg-cross
#
# default architecture for dpkg-cross (to avoid always typing the -a option
# if you do cross installations only for one architecture)
# Note: default_arch is managed by debconf - it can be overridden
# if ~/.dpkg-cross/cross-compile exists or by specifying an
# architecture on the command line.
# Use '[sudo] dpkg-reconfigure dpkg-cross' to change this value.
#default_arch =
# All subsequent variables may be removed (and/or become
# unsupported) at any time.
#
# general section: paths of cross compiling environment
#
# you can set the following variables here:
# crossprefix: prefix for cross compiling binaries; default:
$(DEB_HOST_GNU_SYSTEM)-
# crossbase : base prefix for the following; default: /usr
# crossdir : base directory for architecture; default:
# $(CROSSBASE)/$(DEB_HOST_GNU_TYPE)
# crossbin : dir for binaries; default: $(CROSSDIR)/bin
# crosslib : dir for libraries; default: $(CROSSDIR)/lib
# crossinc : dir for headers; default: $(CROSSDIR)/include
# maintainer : maintainer name to pass to original dpkg-buildpackage
# in -m option. If not set at all, don't pass a -m, thus
# dpkg-buildpackage will use the name from the changelog
# file. If set to the special string CURRENTUSER,
# dpkg-buildpackage will use the name from the
# changelog, too, but signing the .changes will be done
# as the current user (default key).
# removedeps : comma-separated list of package names that should be removed
# from depends/conflicts/etc fields
# keepdeps : comma-separated list of package names that should be kept
# in depends/conflicts/etc fields as is, without adding
# -arch-cross.
#
# In preparation for merging dpkg-cross into dpkg, the previous
# defaults have been removed.
- -- System Information:
Debian Release: squeeze/sid
APT prefers natty
APT policy: (999, 'natty')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-7-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg-cross depends on:
ii debconf [debconf-2.0] 1.5.36ubuntu4Debian configuration management sy
ii dpkg-dev1.16.0~ubuntu6 Debian package development tools
ii libconfig-auto-perl 0.20-2 Magical config file parser
ii libdebian-dpkgcross-per 2.6.3ubuntu1 functions to aid cross-compiling D
ii perl5.10.1-17ubuntu3 Larry Wall's Practical Extraction
Versions of packages dpkg-cross recommends:
ii fakeroot 1.14.4-1ubuntu1 Gives a fake root environment
Versions of packages dpkg-cross suggests:
ii binutils-multia 2.21.0.20110322-1ubuntu1 Binary utilities that support mult
- -- debconf information:
dpkg-cross/default-arch: None
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk2KEToACgkQeQ6MlGH/2quYngCfYp1ZT44SjXmj3X2Kwp+IYGB9
AwQAn2iZHPk+DuRby91TFEzMVeGdSf8A
=kVUV
-END PGP SIGNATURE-
Index: dpkg-cross
===
RCS file: /cvsroot/dpkg-cross/dpkg-cross/dpkg-cross,v
retrieving revision 1.83
diff -u -r1.83 dpkg-cross
--- dpkg-cross 23 Feb 2011 14:46:33 - 1.83
+++ dpkg-cross 23 Mar 2011 14:32:35 -
@@ -507,7 +507,7 @@
}
close(CONTROL);
- if (defined ($control{'multi-arch'})) {
+ if (defined ($control{'multi-arch'}) and !$anyway) {
my $output = basename ($package);
warn sprintf(_g(%s: Skipping the '%s' Multi-Arch package.\n), $progname, $output);
if (not -f
Bug#618450: gcc-4.6-source: There are missing conflicts on 4.5 packages
Package: gcc-4.6-source
Version: 4.6-20110227-1
Severity: normal
Tags: patch
Packages built from gcc 4.6 source conflict with 4.4 packages but not with 4.5
ones.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-6-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-4.6-source depends on:
ii autoconf2.64 2.64-3 automatic configure script builder
ii automake 1:1.11.1-1 A tool for generating GNU Standard
ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
ii make 3.81-8 An utility for Directing compilati
ii patchutils0.3.2-1Utilities to work with patches
ii quilt 0.48-7 Tool to work with series of patche
gcc-4.6-source recommends no packages.
gcc-4.6-source suggests no packages.
-- no debconf information
--- debian.orig/control.m4 2011-01-05 03:24:03.0 +0100
+++ debian/control.m4 2011-03-15 10:29:18.559005771 +0100
@@ -1640,7 +1640,7 @@
ifdef(`TARGET',`Provides: libstdc++CXX_SO-dbg-TARGET-dcv1
',`')`'dnl
Recommends: libstdc++CXX_SO`'PV-dev`'LS (= ${gcc:Version})
-Conflicts: libstdc++5-dbg`'LS, libstdc++5-3.3-dbg`'LS, libstdc++6-dbg`'LS,
libstdc++6-4.0-dbg`'LS, libstdc++6-4.1-dbg`'LS, libstdc++6-4.2-dbg`'LS,
libstdc++6-4.3-dbg`'LS, libstdc++6-4.4-dbg`'LS
+Conflicts: libstdc++5-dbg`'LS, libstdc++5-3.3-dbg`'LS, libstdc++6-dbg`'LS,
libstdc++6-4.0-dbg`'LS, libstdc++6-4.1-dbg`'LS, libstdc++6-4.2-dbg`'LS,
libstdc++6-4.3-dbg`'LS, libstdc++6-4.4-dbg`'LS, libstdc++6-4.5-dbg`'LS
Description: The GNU Standard C++ Library v3 (debugging
files)`'ifdef(`TARGET)',` (TARGET)', `')
This package contains the shared library of libstdc++ compiled with
debugging symbols.
@@ -1657,7 +1657,7 @@
Depends: BASEDEP, lib32stdc++CXX_SO`'LS (= ${gcc:Version}),
libstdc++CXX_SO`'PV-dev`'LS (= ${gcc:Version}), lib32gcc`'GCC_SO-dbg`'LS,
${shlibs:Depends}, ${misc:Depends}
ifdef(`TARGET',`Provides: lib32stdc++CXX_SO-dbg-TARGET-dcv1
',`')`'dnl
-Conflicts: lib32stdc++6-dbg`'LS, lib32stdc++6-4.0-dbg`'LS,
lib32stdc++6-4.1-dbg`'LS, lib32stdc++6-4.2-dbg`'LS, lib32stdc++6-4.3-dbg`'LS,
lib32stdc++6-4.4-dbg`'LS
+Conflicts: lib32stdc++6-dbg`'LS, lib32stdc++6-4.0-dbg`'LS,
lib32stdc++6-4.1-dbg`'LS, lib32stdc++6-4.2-dbg`'LS, lib32stdc++6-4.3-dbg`'LS,
lib32stdc++6-4.4-dbg`'LS, lib32stdc++6-4.5-dbg`'LS
Description: The GNU Standard C++ Library v3 (debugging
files)`'ifdef(`TARGET)',` (TARGET)', `')
This package contains the shared library of libstdc++ compiled with
debugging symbols.
@@ -1674,7 +1674,7 @@
Depends: BASEDEP, lib64stdc++CXX_SO`'LS (= ${gcc:Version}),
libstdc++CXX_SO`'PV-dev`'LS (= ${gcc:Version}), lib64gcc`'GCC_SO-dbg`'LS,
${shlibs:Depends}, ${misc:Depends}
ifdef(`TARGET',`Provides: lib64stdc++CXX_SO-dbg-TARGET-dcv1
',`')`'dnl
-Conflicts: lib64stdc++6-dbg`'LS, lib64stdc++6-4.0-dbg`'LS,
lib64stdc++6-4.1-dbg`'LS, lib64stdc++6-4.2-dbg`'LS, lib64stdc++6-4.3-dbg`'LS,
lib64stdc++6-4.4-dbg`'LS
+Conflicts: lib64stdc++6-dbg`'LS, lib64stdc++6-4.0-dbg`'LS,
lib64stdc++6-4.1-dbg`'LS, lib64stdc++6-4.2-dbg`'LS, lib64stdc++6-4.3-dbg`'LS,
lib64stdc++6-4.4-dbg`'LS, lib64stdc++6-4.5-dbg`'LS
Description: The GNU Standard C++ Library v3 (debugging
files)`'ifdef(`TARGET)',` (TARGET)', `')
This package contains the shared library of libstdc++ compiled with
debugging symbols.
@@ -1691,7 +1691,7 @@
Depends: BASEDEP, libn32stdc++CXX_SO`'LS (= ${gcc:Version}),
libstdc++CXX_SO`'PV-dev`'LS (= ${gcc:Version}), libn32gcc`'GCC_SO-dbg`'LS,
${shlibs:Depends}, ${misc:Depends}
ifdef(`TARGET',`Provides: libn32stdc++CXX_SO-dbg-TARGET-dcv1
',`')`'dnl
-Conflicts: libn32stdc++6-dbg`'LS, libn32stdc++6-4.0-dbg`'LS,
libn32stdc++6-4.1-dbg`'LS, libn32stdc++6-4.2-dbg`'LS,
libn32stdc++6-4.3-dbg`'LS, libn32stdc++6-4.4-dbg`'LS
+Conflicts: libn32stdc++6-dbg`'LS, libn32stdc++6-4.0-dbg`'LS,
libn32stdc++6-4.1-dbg`'LS, libn32stdc++6-4.2-dbg`'LS,
libn32stdc++6-4.3-dbg`'LS, libn32stdc++6-4.4-dbg`'LS, libn32stdc++6-4.5-dbg`'LS
Description: The GNU Standard C++ Library v3 (debugging
files)`'ifdef(`TARGET)',` (TARGET)', `')
This package contains the shared library of libstdc++ compiled with
debugging symbols.
@@ -1707,7 +1707,7 @@
Section: doc
Priority: PRI(optional)
Depends: gcc`'PV-base (= ${gcc:SoftVersion}), ${misc:Depends}
-Conflicts: libstdc++5-doc, libstdc++5-3.3-doc, libstdc++6-doc,
libstdc++6-4.0-doc, libstdc++6-4.1-doc, libstdc++6-4.2-doc, libstdc++6-4.3-doc,
libstdc++6-4.4-doc
+Conflicts: libstdc++5-doc, libstdc++5-3.3-doc, libstdc++6-doc,
libstdc++6-4.0-doc, libstdc++6-4.1-doc, libstdc++6-4.2-doc, libstdc++6-4.3-doc,
libstdc++6-4.4-doc,
Bug#617482: buildd.emdebian.org: gdb-arm-linux-gnueabi fails to install
This bug is probably duplicate of bug #603347 [1] which got solved in Ubuntu and patch was provided to Debian. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603347 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611382: linux-2.6: Provide all packaging instructions in linux-source package
Package: linux-2.6
Severity: wishlist
Tags: patch
I am working on cross toolchain packages for Ubuntu. During work on 10.10
'maverick'
release I got it working and now want to add it also to Debian archive.
To get it done I need some changes to be done in linux-2.6 packaging. None of
them
affects backward compatibility - they extend it a bit. This bug report is about
first
change - adding debian/ directory to linux-source package so it could be
possible to
rebuild linux kernel/headers/includes packages just from contents of
linux-source
binary package.
I need this to get my armel-cross-toolchain-base package be able to generate
linux-libc-dev package during cross compiler boostrap process (which is
automated
and occurs on buildd in two source packages).
-- System Information:
Debian Release: 6.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37-12-generic
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Index: linux-2.6-2.6.37/debian/rules.real
===
--- linux-2.6-2.6.37.orig/debian/rules.real 2011-01-27 13:26:09.0 +
+++ linux-2.6-2.6.37/debian/rules.real 2011-01-28 13:36:06.744220002 +
@@ -523,11 +533,23 @@
find '$(pfull)/debian' ! -path '*/series/*' -type f -execdir bzip2 '{}' ';' -execdir chmod 644 '{}.bz2' ';'
+$(MAKE_SELF) install-base
+install-source: PACKAGE_NAME = linux-source-$(VERSION)
+install-source: PACKAGE_DIR = debian/$(PACKAGE_NAME)
install-source: DH_OPTIONS = -plinux-source-$(VERSION)
install-source: $(BUILD_DIR)/linux-source-$(UPSTREAMVERSION).tar.bz2
dh_testdir
dh_testroot
dh_install '$' /usr/src
+ find './debian' \
+ -path './debian/linux-*' -prune -o \
+ -path './debian/firmware-linux-free*' -prune -o \
+ -path './debian/$(src_pkg_name)-*' -prune -o \
+ -path './debian/build' -prune -o \
+ -path './debian/files' -prune -o \
+ -path './debian/stamps' -prune -o \
+ -path './debian/tmp' -prune -o \
+ -print | \
+ cpio -pd --preserve-modification-time '$(CURDIR)/$(PACKAGE_DIR)/usr/src/linux-source-$(VERSION)'
+$(MAKE_SELF) install-base
install-firmware: PACKAGE_NAME = firmware-linux-free
Bug#611382: linux-2.6: Provide all packaging instructions in linux-source package
Dnia piątek, 28 stycznia 2011 o 18:55:33 Bastian Blank napisał(a): On Fri, Jan 28, 2011 at 05:03:12PM +, Marcin Juszkiewicz wrote: This bug report is about first change - adding debian/ directory to linux-source package so it could be possible to rebuild linux kernel/headers/includes packages just from contents of linux-source binary package. The upstream kernel supports make deb-pkg to build packages. For everything else use the _source_ package. I do not want make deb-pkg which will build kernel which I will ignore as I need only linux-libc-dev for target architecture (which != build architecture). I need this to get my armel-cross-toolchain-base package be able to generate linux-libc-dev package during cross compiler boostrap process (which is automated and occurs on buildd in two source packages). The linux-libc-dev package exists in the target architecture. Use this package. Source package in Debian can not depend on packages for other architectures and there is no linux-libc-dev-armel-cross in amd64/i386 archive. It can not also depend on source packages. Unless something changed in last months... Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553047: libc6: (cross) libc-2.10.1.so/powerpc: ELF file data
Dnia czwartek, 28 października 2010 o 08:06:35 minami napisał(a): Shouldn't we stop tweaking LD_LIBRARY_PATH to cross-build gcc? In my understanding, the error message: error while loading shared libraries: /usr/powerpc-linux-gnu/lib/libc.so.6: ELF file data encoding not little-endian means: failed to load the Perl interpreter with $LD_LIBRARY_PATH/libc.so instead of /lib/libc.so. Yes, it means that. I solved that by adding /lib:/usr/lib: to LD_LIBRARY_PATH in attached patch. Fortunately, recent versions of dpkg-shlibdeps seems to be wise enough to detect GCC_TARGET and DEB_TARGET_GNU_TYPE and we no longer have to tell dh_shlibdeps where to search libraries using a special environment variable. Would be nice. Anyway with attached patch I managed to package biarch powerpc and triarch mipsel gcc-4.5. Please take a look. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz From 765b884759007e961f53a296183a1bddb9a07ee8 Mon Sep 17 00:00:00 2001 From: Marcin Juszkiewicz marcin.juszkiew...@linaro.org Date: Wed, 22 Dec 2010 14:08:41 +0100 Subject: [PATCH] Fix biarch/triarch cross builds. There were two problems: 1. dpkg-shlibdeps failed to find libraries for 64 or n32 builds 2. LD_LIBRARY_PATH lacked host dirs so when 1st problem got fixed it was not working. --- debian/rules.d/binary-fortran.mk|8 debian/rules.d/binary-libgcc.mk |2 +- debian/rules.d/binary-libgomp.mk|8 debian/rules.d/binary-libmudflap.mk |9 - debian/rules.d/binary-libobjc.mk| 10 +- debian/rules.d/binary-libstdcxx.mk | 10 +- debian/rules2 |2 +- 7 files changed, 24 insertions(+), 25 deletions(-) diff --git a/debian/rules.d/binary-fortran.mk b/debian/rules.d/binary-fortran.mk index cfed225..ee089ae 100644 --- a/debian/rules.d/binary-fortran.mk +++ b/debian/rules.d/binary-fortran.mk @@ -56,8 +56,8 @@ define __do_fortran mv $(install_stamp) $(install_stamp)-tmp rm -rf $(d_l) $(d_d) - dh_installdirs -p$(p_l) $(2) - DH_COMPAT=2 dh_movefiles -p$(p_l) $(2)/libgfortran.so.* + dh_installdirs -p$(p_l) $(usr_lib$(2)) + DH_COMPAT=2 dh_movefiles -p$(p_l) $(usr_lib$(2))/libgfortran.so.* debian/dh_doclink -p$(p_l) $(p_base) debian/dh_doclink -p$(p_d) $(p_base) @@ -67,7 +67,7 @@ define __do_fortran dh_fixperms -p$(p_l) -p$(p_d) dh_makeshlibs -p$(p_l) $(call cross_mangle_shlibs,$(p_l)) - $(cross_shlibdeps) dh_shlibdeps -p$(p_l) + DIRNAME=$(subst n,,$(2)) $(cross_shlibdeps) dh_shlibdeps -p$(p_l) $(call cross_mangle_substvars,$(p_l)) dh_gencontrol -p$(p_l) -p$(p_d) \ -- -v$(DEB_VERSION) $(common_substvars) @@ -79,7 +79,7 @@ define __do_fortran trap '' 1 2 3 15; touch $@; mv $(install_stamp)-tmp $(install_stamp) endef -do_fortran = $(call __do_fortran,lib$(1)gfortran$(FORTRAN_SONAME),$(usr_lib$(1))) +do_fortran = $(call __do_fortran,lib$(1)gfortran$(FORTRAN_SONAME),$(1)) define do_fortran_dev dh_installdirs -p$(2) $(gcc_lib_dir$(1)) diff --git a/debian/rules.d/binary-libgcc.mk b/debian/rules.d/binary-libgcc.mk index b45a4b4..ba1039f 100644 --- a/debian/rules.d/binary-libgcc.mk +++ b/debian/rules.d/binary-libgcc.mk @@ -64,7 +64,7 @@ define __do_libgcc ) ) - $(cross_shlibdeps) dh_shlibdeps -p$(p_l) + DIRNAME=$(subst n,,$(2)) $(cross_shlibdeps) dh_shlibdeps -p$(p_l) $(call cross_mangle_substvars,$(p_l)) dh_compress -p$(p_l) -p$(p_d) diff --git a/debian/rules.d/binary-libgomp.mk b/debian/rules.d/binary-libgomp.mk index 736b681..c18313b 100644 --- a/debian/rules.d/binary-libgomp.mk +++ b/debian/rules.d/binary-libgomp.mk @@ -15,8 +15,8 @@ define __do_gomp mv $(install_stamp) $(install_stamp)-tmp rm -rf $(d_l) $(d_d) - dh_installdirs -p$(p_l) $(2) - DH_COMPAT=2 dh_movefiles -p$(p_l) $(2)/libgomp.so.* + dh_installdirs -p$(p_l) $(usr_lib$(2)) + DH_COMPAT=2 dh_movefiles -p$(p_l) $(usr_lib$(2))/libgomp.so.* debian/dh_doclink -p$(p_l) $(p_base) debian/dh_doclink -p$(p_d) $(p_base) @@ -26,7 +26,7 @@ define __do_gomp dh_fixperms -p$(p_l) -p$(p_d) dh_makeshlibs -p$(p_l) $(call cross_mangle_shlibs,$(p_l)) - $(cross_shlibdeps) dh_shlibdeps -p$(p_l) + DIRNAME=$(subst n,,$(2)) $(cross_shlibdeps) dh_shlibdeps -p$(p_l) $(call cross_mangle_substvars,$(p_l)) dh_gencontrol -p$(p_l) -p$(p_d) \ -- -v$(DEB_VERSION) $(common_substvars) @@ -40,7 +40,7 @@ endef # -- -do_gomp = $(call __do_gomp,lib$(1)gomp$(GOMP_SONAME),$(usr_lib$(1))) +do_gomp = $(call __do_gomp,lib$(1)gomp$(GOMP_SONAME),$(1)) $(binary_stamp)-libgomp: $(install_stamp) $(call do_gomp,) diff --git a/debian/rules.d/binary-libmudflap.mk b/debian/rules.d/binary-libmudflap.mk index e35ae5c..ff89781 100644 --- a/debian/rules.d/binary-libmudflap.mk +++ b/debian/rules.d/binary-libmudflap.mk @@ -24,9 +24,8 @@ define __do_mudflap mv $(install_stamp
Bug#599206: dpkg-cross should leave files in converted package
Package: dpkg-cross Version: 2.5.8ubuntu2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dpkg-cross by default removes lot of files from converted packages. Effect it that sqlite3 can not be cross built because tcl8.5-dev-armel-cross package does not contain tclConfig.sh (which was present in tcl8.5-dev_armel.deb). - -- Package-specific info: - -- /etc/dpkg-cross/cross-compile -- # # /etc/dpkg-cross/cross-compile: configuration for dpkg-cross # # default architecture for dpkg-cross (to avoid always typing the -a option # if you do cross installations only for one architecture) # Note: default_arch is managed by debconf - it can be overridden # if ~/.dpkg-cross/cross-compile exists or by specifying an # architecture on the command line. # Use '[sudo] dpkg-reconfigure dpkg-cross' to change this value. #default_arch = # All subsequent variables may be removed (and/or become # unsupported) at any time. # # general section: paths of cross compiling environment # # you can set the following variables here: # crossprefix: prefix for cross compiling binaries; default: $(DEB_HOST_GNU_SYSTEM)- # crossbase : base prefix for the following; default: /usr # crossdir : base directory for architecture; default: # $(CROSSBASE)/$(DEB_HOST_GNU_TYPE) # crossbin : dir for binaries; default: $(CROSSDIR)/bin # crosslib : dir for libraries; default: $(CROSSDIR)/lib # crossinc : dir for headers; default: $(CROSSDIR)/include # maintainer : maintainer name to pass to original dpkg-buildpackage # in -m option. If not set at all, don't pass a -m, thus # dpkg-buildpackage will use the name from the changelog # file. If set to the special string CURRENTUSER, # dpkg-buildpackage will use the name from the # changelog, too, but signing the .changes will be done # as the current user (default key). # removedeps : comma-separated list of package names that should be removed # from depends/conflicts/etc fields # keepdeps : comma-separated list of package names that should be kept # in depends/conflicts/etc fields as is, without adding # -arch-cross. # # In preparation for merging dpkg-cross into dpkg, the previous # defaults have been removed. - -- System Information: Debian Release: squeeze/sid APT prefers maverick APT policy: (650, 'maverick') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-22-generic (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-cross depends on: ii debconf [debconf-2.0] 1.5.32ubuntu3Debian configuration management sy ii dpkg-dev1.15.8.4ubuntu3 Debian package development tools ii libconfig-auto-perl 0.20-2 Magical config file parser ii libdebian-dpkgcross-per 2.5.8ubuntu2 functions to aid cross-compiling D ii perl5.10.1-12ubuntu2 Larry Wall's Practical Extraction Versions of packages dpkg-cross recommends: ii binutils-multi 2.20.51.20100908-0ubuntu2 Binary utilities that support mult ii fakeroot 1.14.4-1ubuntu1 Gives a fake root environment dpkg-cross suggests no packages. - -- debconf information: dpkg-cross/default-arch: None -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyrTfUACgkQeQ6MlGH/2qtrkgCfXZmV/jscTrL3rHKx43OVIBKR rjgAnjizstIzWWN32uKFShY5z53A0y0m =5xDq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597708: tcl8.4: Cross compilation does not detect proper CC
Package: tcl8.4 Version: 8.4.19-4 Severity: normal Tags: patch tcl8.4 can not be cross compiled with current state due to use of AC_PROG_CC macro by upstream which checks only for $CC and gcc. To get it cross compiled (dpkg-buildpackage -b -aarmel) I needed to add few lines to configure call in debian/rules: - --- rules.orig2010-09-22 13:23:48.936069000 +0200 +++ rules 2010-09-22 13:23:50.496069000 +0200 @@ -35,6 +35,9 @@ # So so ugly but it works... touch generic/tclStubInit.c cd unix \ + CC=$(DEB_HOST_GNU_TYPE)-gcc \ + ac_cv_func_strtod=yes \ + tcl_cv_strtod_buggy=1 \ TCL_LIBRARY=/usr/share/tcltk/tcl$(v) \ TCL_PACKAGE_PATH=/usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk /usr/lib \ ./configure --host=$(DEB_HOST_GNU_TYPE) \ CC one sets compiler to native or cross one and strtod lines are to make it build as configure does not checks properly for it during cross build and assumes inproper state. - -- System Information: Debian Release: squeeze/sid APT prefers maverick APT policy: (650, 'maverick') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-22-generic (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tcl8.4 depends on: ii libc62.12.1-0ubuntu6 Embedded GNU C Library: Shared lib tcl8.4 recommends no packages. Versions of packages tcl8.4 suggests: pn tclreadline none (no description available) - -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#597708: tcl8.4: Cross compilation does not detect proper CC
Dnia środa, 22 września 2010 o 15:18:12 Francesco P. Lovergine napisał(a): On Wed, Sep 22, 2010 at 01:36:35PM +0200, Marcin Juszkiewicz wrote: Package: tcl8.4 Version: 8.4.19-4 Severity: normal Tags: patch tcl8.4 can not be cross compiled with current state due to use of AC_PROG_CC macro by upstream which checks only for $CC and gcc. To get it cross compiled (dpkg-buildpackage -b -aarmel) I needed to add few lines to configure call in debian/rules: It would help knowing if the same proper applies to 8.5 which will be next default version. tcl8.5 does not need CC to be set, but strtod lines needs to be present. It also fails on install because it uses just compiled tclsh to install message catalogs and it fail during cross compilation. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590599: gcc-4.4: Building cross gcc with 4.4.4-7, missing gcc*-base package, install error
Dnia piątek, 27 sierpnia 2010 o 04:56:57 Nobuhiro Iwamatsu napisał(a): This patch seems to be already applied in 4.4.4-9. However, this problem is not revised. 4.4.4-10 will get -base fixed. 4.4.4-9 got stages support with broken -base package. Sorry for mess. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590599: gcc-4.4: Building cross gcc with 4.4.4-7, missing gcc*-base package, install error
When cross building the gcc-4.4-4.4.4-7 pacakage, the build no longer generates a gcc-4.4-*-gnueabi-base package as part of the default build. The control file, however still references such a package as a dependency for installing the gcc-4.4-*-gnueabi package. This results in an install failure, since the dependent package is not built as follows: I have a fix for that as a part of next set of my changes to gcc-4.4/4.5: http://launchpadlibrarian.net/52036174/gcc-4.5-stage-support-v5.diff This will be solved after Debconf. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562421: bitbake: Depends on python2.4 packages
As one of BitBake developers I want to tell that is it safe to just do rebuild of package to get rid of python2.4 stuff. We maintain compatibility with Python 2.4 in 1.8.x branch of BitBake and it is compatible with 2.5 and 2.6 versions. 1.10 and 'master' branches require Python 2.5 but are not expected to be packaged yet - they are development branches. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Dnia sobota, 21 listopada 2009 o 07:25:54 Norbert Preining napisał(a): On Sa, 21 Nov 2009, Norbert Preining wrote: What about adding tex-common conflicts texlive-base-bin ? Bummer I know why: texlive-common: Conflicts: tex-base-bin, What a rubbish, it has to be texlive-base-bin so that that is removed first before installing the new. Grrr. Fixed in repository. Still fails :( 10:04 r...@home:~# LC_ALL=C dpkg --configure -a Setting up texlive-base (2009-2) ... Running mktexlsr. This may take some time... done. Building format(s) --all --cnffile /etc/texmf/fmt.d/10texlive-base.cnf. This may take some time... fmtutil-sys failed. Output has been stored in /tmp/fmtutil.QEEQ9hAA Please include this file if you report a bug. dpkg: error processing texlive-base (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of texlive-generic- recommended: texlive-generic-recommended depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-generic-recommended (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-fonts-recommended: texlive-fonts-recommended depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-fonts-recommended (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-pictures: texlive-pictures depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-pictures (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-fonts-extra: texlive-fonts-extra depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-fonts-extra (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-math-extra: texlive-math-extra depends on texlive-fonts-recommended (= 2009-1); however: Package texlive-fonts-recommended is not configured yet. dpkg: error processing texlive-math-extra (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-latex-base: texlive-latex-base depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-latex-base (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of latex-beamer: latex-beamer depends on texlive-latex-base; however: Package texlive-latex-base is not configured yet. dpkg: error processing latex-beamer (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-font-utils: texlive-font-utils depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. dpkg: error processing texlive-font-utils (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of texlive-xetex: texlive-xetex depends on texlive-base (= 2009-1); however: Package texlive-base is not configured yet. texlive-xetex depends on texlive-latex-base (= 2009-1); however: Package texlive-latex-base is not configured yet. dpkg: error processing texlive-xetex (--configure): dependency problems - leaving unconfigured dpkg:
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Dnia wtorek, 24 listopada 2009 o 06:34:59 Norbert Preining napisał(a): Ok, I found the bug ... from your fmtutil.cnf # The following added lines have been transferred from # /etc/texmf/fmt.d/10texlive-base-bin.cnf #They take precedence over earlier entries etexpdftex language.def-translate-file=cp227.tcx *etex.ini pdfetex pdftex language.def -translate-file=cp227.tcx *pdfetex.ini ### End of file: /etc/texmf/fmt.d/10texlive-base.cnf Did *you* add this lines??? I never edited that file as I do not touch TeX config files (except once few years ago when I enabled Polish support). To tell the true I did not know that this file exists before this bug discussion. They are complete rubbish, they should NOT be there, as they are already mentioned above. The quest now is *why* on earth are these lines in your /etc/texmf/fmt.d/10texlive-base.cnf They are NOT in mine, and not in the one we ship! To fix your problem, remove the stuff after # /etc/texmf/fmt.d/10texlive-base-bin.cnf to the end of file, call (as root) update-fmtutil and fmtutil-sys --all (or dpkg --configure -a) I did that, run 'dpkg --configure -a' and system works - I compiled one of my Latex beamer presentations. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Package: texlive-binaries Version: 2009-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wanted to upgrade from TeXlive 2007 to 2009 version. During update I got: Setting up texlive-binaries (2009-1) ... mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVE... mktexlsr: Updating /var/lib/texmf/ls-R... mktexlsr: Done. Building format(s) --refresh. This may take some time... fmtutil-sys failed. Output has been stored in /tmp/fmtutil.1TQs0v2P Please include this file if you report a bug. I thought that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428259 was similar and remove jadetex from system. Contents of /tmp/fmtutil.1TQs0v2P file: fmtutil: running `mf-nowin -ini -jobname=mf -progname=mf -translate-file=cp227.tcx mf.ini' ... This is METAFONT, Version 2.718281 (TeX Live 2009/Debian) (INIMF) (/usr/share/texmf-texlive/web2c/cp227.tcx) (/usr/share/texmf-texlive/metafont/config/mf.ini (/usr/share/texmf-texlive/metafont/base/plain.mf Preloading the plain base, version 2.71: preliminaries, basic constants and mathematical macros, macros for converting from device-independent units to pixels, macros and tables for various modes of operation, macros for drawing and filling, macros for proof labels and rules, macros for character and font administration, and a few last-minute items.) (/etc/texmf/metafont/misc/modes.mf) ) Beginning to dump on file mf.base (base=mf 2009.11.19) 2225 strings of total length 29921 11864 memory locations dumped; current usage is 36587844 1004 symbolic tokens Transcript written on mf.log. fmtutil: /var/lib/texmf/web2c/metafont/mf.base installed. fmtutil: running `pdftex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini' ... This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (INITEX) restricted \write18 enabled. (/usr/share/texmf-texlive/web2c/cp227.tcx) entering extended mode (/usr/share/texmf-texlive/tex/plain/config/etex.ini (/usr/share/texmf-texlive/tex/plain/etex/etex.src (/usr/share/texmf-texlive/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texmf-texlive/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texmf-texlive/tex/plain/etex/etexdefs.lib Skipping module grouptypes; Loading module interactionmodes; Skipping module nodetypes; Skipping module iftypes;) (/var/lib/texmf/tex/generic/config/language.def (/usr/share/texmf-texlive/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone, register allocation; extended register allocation; Recycling: \addlanguage, \...@nswer (not defined), \...@sk, \...@dresponsetrue, \...@dresponsefalse, \...@ckforyn, \may...@cycle, \...@xabort, \...@xbuf, \...@xfmtsrc, \...@xfilehdr, \...@xinf, \...@xpatterns, \...@ngdefnfile, \...@xt, \...@rse (not defined), \...@mpt (not defined), \...@mptloop (not defined), \for...@cycle, \u...@llback, \u...@llbacktrue, \u...@llbackfalse, Retaining: \...@xerr, \...@xinput, \...@xlibhdr, \...@xmsg, \...@xtoks, \...@xwarn, \...@xl@@d, \...@xl@ad, \...@xload, \...@xlang, \...@xhash, \eTeX, \etexhdrchk, \etexstatus, \module, \uselanguage, \...@tain, \...@cycle,) ) Beginning to dump on file etex.fmt (format=etex 2009.11.19) 2861 strings of total length 42089 7960 memory locations dumped; current usage is 2037290 1251 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 \font\preloaded=cmss10 \font\preloaded=cmssq8 \font\preloaded=cmssi10 \font\preloaded=cmssqi8 \font\tenbf=cmbx10 \font\preloaded=cmbx9 \font\preloaded=cmbx8 \font\sevenbf=cmbx7 \font\preloaded=cmbx6 \font\fivebf=cmbx5 \font\tentt=cmtt10 \font\preloaded=cmtt9 \font\preloaded=cmtt8 \font\preloaded=cmsltt10 \font\tensl=cmsl10 \font\preloaded=cmsl9 \font\preloaded=cmsl8 \font\tenit=cmti10 \font\preloaded=cmti9 \font\preloaded=cmti8 \font\preloaded=cmti7 \font\preloaded=cmu10 \font\preloaded=cmmib10 \font\preloaded=cmbsy10 \font\preloaded=cmcsc10 \font\preloaded=cmssbx10 \font\preloaded=cmdunh10 \font\preloaded=cmr7 at 14.51799pt \font\preloaded=cmtt10 at 14.4pt \font\preloaded=cmssbx10 at 14.4pt \font\preloaded=manfnt 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops out of 35111 181 for language 0 0 words of pdfTeX memory 0 indirect objects No pages of output. Transcript written on etex.log. fmtutil: /var/lib/texmf/web2c/pdftex/etex.fmt
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Dnia czwartek, 19 listopada 2009 o 15:01:10 Norbert Preining napisał(a): On Do, 19 Nov 2009, Marcin Juszkiewicz wrote: fmtutil: Infinite recursion detected, giving up!. Bummer ... Can you send me the fmtutil.cnf file, /var/lib/texmf/web2c/fmtutil.cnf attached and whether jadetex and/or xmltex is installed. None of them are installed: 15:43 r...@home:~# COLUMNS=60 dpkg -l|egrep xmlt|jade ii jade 1.2.1-47 James Clark's DSSSL Engine ii openjade 1.4devel1-19 Implementation of the DSSSL language ii xmlto 0.0.23-2 XML-to-any converter Can you do (as root, assuming bash): v=`kpsewhich -var-value TEXMFSYSVAR` c=`kpsewhich -var-value TEXMFSYSCONFIG` TEXMFVAR=$v TEXMFCONFIG=$c export TEXMFVAR TEXMFCONFIG bash -x /usr/bin/fmtutil --all fmtutil.log 21 and send me the output fmtutil.log? Attached. Called as root with bash. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz + source /etc/bash.bashrc ++ '[' -z '' ']' ++ return + alias '..=cd ..' + alias e=exit + alias 'p=ps fx' + alias cls=clear + alias 'll=ls -l' + alias 'k=kill -9 ' + export BASH_ENV=/home/hrw/.bashrc + BASH_ENV=/home/hrw/.bashrc + export email=mar...@juszkiewicz.com.pl + email=mar...@juszkiewicz.com.pl + export GTK_USE_XFT=1 + GTK_USE_XFT=1 + export SIGFIXED=/home/hrw/.signature + SIGFIXED=/home/hrw/.signature + export FORTUNES=/home/hrw/.taglines + FORTUNES=/home/hrw/.taglines + export PAGER=/usr/bin/less + PAGER=/usr/bin/less + export 'PS1=\[\e[36m\]\A \[\e[31m\]\u\[\e[34...@\[\e[33m\]\h\[\e[36m\]:\[\e[32m\]\W\[\e[35m\]\$\[\e[0m\] ' + PS1='\[\e[36m\]\A \[\e[31m\]\u\[\e[34...@\[\e[33m\]\h\[\e[36m\]:\[\e[32m\]\W\[\e[35m\]\$\[\e[0m\] ' + shopt -s histappend + PROMPT_COMMAND='history -a; ' + export HISTSIZE=100 + HISTSIZE=100 + export HISTFILESIZE=100 + HISTFILESIZE=100 + export HISTCONTROL=ignoreboth + HISTCONTROL=ignoreboth + export GREP_OPTIONS=--color=auto + GREP_OPTIONS=--color=auto + test -f /bin/ksh + unset RUNNING_KSH + test -f /bin/bsh + unset RUNNING_BSH + test -n '' + progname=fmtutil + argv0=/usr/bin/fmtutil + version=20091009.0222 + cnf=fmtutil.cnf + export PATH + . /usr/share/texlive-bin/debianize-fmtutil + main --all + destdir= + cnf_file= + cmd= + needsCleanup=false + need_find_hyphenfile=false + cfgparam= + cfgmaint= + tmpdir=/tmp/fmtutil.1315 + verboseFlag=true + mktexfmtMode=false + case $argv0 in + use_engine_dir=true + case $1 in + cmd=all + test 1 -gt 0 + shift + case $1 in + break + case $cmd in + test -n '' + test -n '' + test -z '' ++ tcfmgr --cmd find --file fmtutil.cnf ++ initTexmfMain ++ case $MT_TEXMFMAIN in +++ kpsewhich --var-value=TEXMFMAIN ++ MT_TEXMFMAIN=/usr/share/texmf ++ export MT_TEXMFMAIN ++ /usr/share/texmf/texconfig/tcfmgr --cmd find --file fmtutil.cnf + cnf_file=/var/lib/texmf/web2c/fmtutil.cnf + test -f /var/lib/texmf/web2c/fmtutil.cnf + case $cmd in + test -z '' ++ kpsewhich -var-value=TEXMFVAR + : /var/lib/texmf + destdir=/var/lib/texmf/web2c + test -d /var/lib/texmf/web2c + test -d /var/lib/texmf/web2c + test -w /var/lib/texmf/web2c ++ pwd + thisdir=/home/hrw + : /home/hrw + export KPSE_DOT + TEXINPUTS=/tmp/fmtutil.1315: + export TEXINPUTS + TEXFORMATS=/tmp/fmtutil.1315: + export TEXFORMATS + setupTmpDir + false + trap 'cleanup 1' 1 2 3 7 13 15 + needsCleanup=true + umask 077 + mkdir /tmp/fmtutil.1315 + cd /tmp/fmtutil.1315 + case $destdir in + case $cnf_file in + cache_vars ++ kpsewhich '--expand-var=$VARTEXFONTS' ++ sed 's%^!!%%' + : /tmp/texfonts ++ kpsewhich '--format=web2c files' mktexnam + : /usr/share/texmf/web2c/mktexnam ++ kpsewhich '--format=web2c files' mktexnam.opt + : /usr/share/texmf/web2c/mktexnam.opt ++ kpsewhich '--format=web2c files' mktexdir + : /usr/share/texmf/web2c/mktexdir ++ kpsewhich '--format=web2c files' mktexdir.opt + : /usr/share/texmf/web2c/mktexdir.opt ++ kpsewhich '--format=web2c files' mktexupd + : /usr/share/texmf/web2c/mktexupd ++ kpsewhich '--format=web2c files' mktex.cnf + : ++ kpsewhich '--format=web2c files' mktex.opt + : /usr/share/texmf/web2c/mktex.opt + export MT_VARTEXFONTS MT_MKTEXNAM MT_MKTEXNAM_OPT MT_MKTEXDIR + export MT_MKTEXDIR_OPT MT_MKTEXUPD MT_MKTEX_CNF MT_MKTEX_OPT + init_log_failure + log_failure_msg= + has_errors=false + init_log_warning + log_warning_msg= + has_warnings=false + case $cmd in + recreate_all + match_cmd=true + recreate_loop + OIFS=' ' + IFS=' ' ++ echo x ++ sed '/^#/d; /^[ ]*$/d' /var/lib/texmf/web2c/fmtutil.cnf + set x 'mf mf-nowin - -translate-file=cp227.tcx mf.ini' 'etexpdftex language.def-translate-file=cp227.tcx *etex.ini' 'pdfetex pdftex language.def-translate-file=cp227.tcx *pdfetex.ini' 'pdftex pdftex - -translate-file=cp227.tcx *pdftex.ini' 'tex tex - tex.ini' 'etexpdftex language.def-translate-file=cp227.tcx
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Dnia czwartek, 19 listopada 2009 o 21:02:53 Frank Küster napisał(a): So there's a duplicate entry for etex after the transfer from 10texlive-base-bin.cnf. This is probably a bug in our transitioning code. Or the code should be removed completely now? Can you please check whether there's a file whose name resembles /etc/texmf/fmt.d/10texlive-base-bin.cnf with some extension (or other mangling) that indicates we moved it out of the way? If you find it, please send it. 21:45 h...@home:~$ ls /etc/texmf/fmt.d/ -l razem 48 -rw-r--r-- 1 root root 1364 2006-11-03 00tex.cnf -rw-r--r-- 1 root root 1228 2008-06-27 10texlive-base.cnf -rw-r--r-- 1 root root 626 11-12 13:31 10texlive-base.cnf.dpkg-dist -rw-r--r-- 1 root root 625 2007-05-22 10texlive-lang-czechslovak.cnf -rw-r--r-- 1 root root 524 2007-05-22 10texlive-lang-polish.cnf -rw-r--r-- 1 root root 459 11-12 14:03 10texlive-lang-polish.cnf.dpkg-new -rw-r--r-- 1 root root 513 11-12 13:31 10texlive-latex-base.cnf.dpkg-new -rw-r--r-- 1 root root 665 2007-04-14 10texlive-math-extra.cnf -rw-r--r-- 1 root root 345 11-12 13:58 10texlive-math-extra.cnf.dpkg-new -rw-r--r-- 1 root root 420 2008-06-01 10texlive-xetex.cnf -rw-r--r-- 1 root root 372 11-12 13:31 10texlive-xetex.cnf.dpkg-new -rw-r--r-- 1 root root 565 2006-10-08 50cyrtexinfo.cnf Whole directory archived and attached. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz fmt.d.tar.bz2 Description: application/bzip-compressed-tar
Bug#557091: texlive-binaries: fmtutil-sys failed during upgrade from texlive 2007
Dnia piątek, 20 listopada 2009 o 03:13:28 Norbert Preining napisał(a): v=`kpsewhich -var-value TEXMFSYSVAR` c=`kpsewhich -var-value TEXMFSYSCONFIG` TEXMFVAR=$v TEXMFCONFIG=$c export TEXMFVAR TEXMFCONFIG kpsewhich fmtutil.cnf 07:01 r...@home:~# v=`kpsewhich -var-value TEXMFSYSVAR` 07:01 r...@home:~# c=`kpsewhich -var-value TEXMFSYSCONFIG` 07:01 r...@home:~# TEXMFVAR=$v 07:01 r...@home:~# TEXMFCONFIG=$c 07:01 r...@home:~# export TEXMFVAR TEXMFCONFIG 07:01 r...@home:~# kpsewhich fmtutil.cnf /var/lib/texmf/web2c/fmtutil.cnf Attached Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ### This file was automatically generated by update-fmtutil. # # Please do not edit it directly. If you want to add or change # anything here, please have a look at the files in: # #/etc/texmf/fmt.d/ # # and invoke update-fmtutil. # ### ### From file: /etc/texmf/fmt.d/00tex.cnf # 00tex.cnf: header of the configuration file for fmtutil. # # In Debian, fmtutil.cnf is a file that is generated from # configuration files in /etc/texmf/fmt.d/. This file, 00tex.cnf, # contains only some comments on how to edit these files. # # The text of the comments is Copyright 1998, 1999 by Thomas Esser, it # is in the Public domain. # You Customize these file to your needs, e.g. # - remove or uncomment formats that you don't need # - add your own formats # - change default engine / flags for standard formats # Some notes: # 1) tex and amstex just load hyphen.tex. No customization. # You can have you own customized (via babel's hyphen.cfg) # formats on top of plain by using bplain.tex instead of # plain.tex (see e.g. bplain.ini file for bplain format). # # 2) etex loads language.def, not language.dat. # # 3) The symbolic link to the right engines (e.g. bplain - tex) # will be generated by the texlinks script. So, if you call # fmtutil by hand and not via texconfig, please also call # texlinks afterwards. # # 4) usual comments start with # , whereas disabled configurations # start with #! in this file. # The format of the table is: # formatengine pattern-filearguments # The last part of arguments must be the name of the file to run # initex (or another ini-engine) on. ### End of file: /etc/texmf/fmt.d/00tex.cnf ### From file: /etc/texmf/fmt.d/10texlive-base.cnf # 10texlive-base.cnf # You can change/add entries to this file and changes will be preserved # over upgrades, even if you have removed the main package prior # (not if you purged it). You should leave the following pseudo comment # present in the file! # -_- DebPkgProvidedMaps -_- # this file has been changed by the postinst script. User-changes from # mf mf-nowin- -translate-file=cp227.tcx mf.ini etexpdftex language.def-translate-file=cp227.tcx *etex.ini pdfetex pdftex language.def-translate-file=cp227.tcx *pdfetex.ini pdftex pdftex - -translate-file=cp227.tcx *pdftex.ini # # Change tex.ini - bplain.ini and - - language.dat # if you want babel support in tex. Add -translate-file=cp227.tcx before # tex.ini if you want to make all characters directly printable for # any \write (instead of ^^xy). tex tex - tex.ini # The following added lines have been transferred from # /etc/texmf/fmt.d/10texlive-base-bin.cnf #They take precedence over earlier entries etexpdftex language.def-translate-file=cp227.tcx *etex.ini pdfetex pdftex language.def-translate-file=cp227.tcx *pdfetex.ini ### End of file: /etc/texmf/fmt.d/10texlive-base.cnf ## ### /etc/texmf/fmt.d/10texlive-lang-czechslovak.cnf not included because either it wasn't ### up-to-date (conffile update pending) or the package shipping it was ### apparently removed (no corresponding .list file in ### /var/lib/tex-common/fmtutil-cnf/). ## ## ### /etc/texmf/fmt.d/10texlive-lang-polish.cnf not included because either it wasn't ### up-to-date (conffile update pending) or the package shipping it was ### apparently removed (no corresponding .list file in ### /var/lib/tex-common/fmtutil-cnf/). ## ## ### /etc/texmf/fmt.d/10texlive-math-extra.cnf not included because either it wasn't ### up-to-date (conffile update pending) or the package shipping it was ### apparently removed (no corresponding .list file in ### /var/lib/tex-common/fmtutil-cnf/). ## ## ### /etc/texmf/fmt.d/10texlive-xetex.cnf not included because either it wasn't ### up-to-date (conffile update pending) or the package shipping it was ### apparently removed (no corresponding .list file in ### /var/lib/tex-common/fmtutil-cnf/). ## ### From file: /etc/texmf/fmt.d/50cyrtexinfo.cnf # # 50cyrtexinfo.cnf # # Please leave this comment! # -_- DebPkgProvidedMaps -_-
Bug#543723: gitosis and git-daemon-run runs as other users == no cooperation
Dnia środa, 26 sierpnia 2009 o 20:31:10 Daniel Baumann napisał(a): Marcin Juszkiewicz wrote: I wanted to create local git server for my uses. So I installed 'gitosis' and 'git-daemon-run' packages. After configuring gitosis I decided to make it possible to clone repository also by other users. But here goes problem - gitosis runs as 'gitosis:gitosis' but git-daemon runs as 'gitdaemon:nogroup' so even when it is configured to check in gitosis repositories it is not possible to clone such ones. then you did something wrong[tm]. what permissions are you using on the repositories? Default ones made by gitosis. when you have both gitosis and git-daemon-run installed, it is indeed not possible (due to the fact that, by default, git-daemon and gitosis are not using the same user) to *push* through *both* gitosis and git. by default, in that situation, you do push through gitosis (ssh) only, and git-daemon becomes factually a read-only service. Thats what I want to make - push via gitosis (due to quite simple way of managing permissions), r/w pull via gitosis, r/o pull via git-daemon. I 'solved' that by running git-daemon-run as 'gitosis' user - otherwise git-daemon do not have access to gitosis repositories. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543723: gitosis and git-daemon-run runs as other users == no cooperation
Package: gitosis Version: 0.2+20080825-15 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wanted to create local git server for my uses. So I installed 'gitosis' and 'git-daemon-run' packages. After configuring gitosis I decided to make it possible to clone repository also by other users. But here goes problem - gitosis runs as 'gitosis:gitosis' but git-daemon runs as 'gitdaemon:nogroup' so even when it is configured to check in gitosis repositories it is not possible to clone such ones. Solution, I think, would be to make both those services use one user by default. - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc6-00243-g53bc5c0 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gitosis depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0]1.5.27 Debian configuration management sy ii git-core 1:1.6.3.3-2 fast, scalable, distributed revisi ii openssh-server 1:5.1p1-7 secure shell server, an rshd repla ii python 2.5.4-3 An interactive high-level object-o ii python-setuptools0.6c9-2 Python Distutils Enhancements ii python-support 1.0.3 automated rebuilding support for P ii sudo 1.7.2-2 Provide limited super user privile gitosis recommends no packages. Versions of packages gitosis suggests: ii git-daemon-run 1:1.6.3.3-2 fast, scalable, distributed revisi pn gitweb none (no description available) - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkqVXjcACgkQeQ6MlGH/2qtbEwCfe8syEJBcPt9kvH0sL4vvSc0J Iv4AmJ7uKB3miPSE/UQl0+ZqEcgwgzQ= =+H5J -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532880: cups-driver-gutenprint: Missing dependency on cups-client
Package: cups-driver-gutenprint Version: 5.2.3-2+b1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konfigurowanie cups-driver-gutenprint (5.2.3-2+b1) ... No Gutenprint PPD files to update. Reloading Common Unix Printing System: cupsd. /var/lib/dpkg/info/cups-driver-gutenprint.postinst: line 41: lpstat: command not found 'lpstat' is in cups-client package so it should be installed as dependency of this package. - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-g9396b7b (SMP w/4 CPU cores; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cups-driver-gutenprint depends on: ii cups 1.3.10-2 Common UNIX Printing System(tm) - ii libc6 2.9-13GNU C Library: Shared libraries ii libcups2 1.3.10-2 Common UNIX Printing System(tm) - ii libcupsimage2 1.3.10-2 Common UNIX Printing System(tm) - ii libgcrypt111.4.4-2 LGPL Crypto library - runtime libr ii libgnutls262.6.6-1 the GNU TLS library - runtime libr ii libgpg-error0 1.6-1 library for common error values an ii libgssapi-krb5-2 1.7dfsg~beta3-1 MIT Kerberos runtime libraries - k ii libgutenprint2 5.2.3-2+b1runtime for the Gutenprint printer ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpng12-0 1.2.37-1 PNG library - runtime ii libtasn1-3 2.2-1 Manage ASN.1 structures (runtime) ii libtiff4 3.8.2-11 Tag Image File Format (TIFF) libra ii perl 5.10.0-22 Larry Wall's Practical Extraction ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime cups-driver-gutenprint recommends no packages. Versions of packages cups-driver-gutenprint suggests: pn gutenprint-docnone (no description available) pn gutenprint-localesnone (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoyUPEACgkQeQ6MlGH/2qvvIACfSeC5tOWOpvUhdgjcTCVjC4C/ gQYAni3eDZHOfHDUm1PswOulvgw0M8N0 =W1ut -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#461768: Provide version for QT4
Package: kde-style-qtcurve Version: 0.52.3-1 Severity: wishlist --- Please enter the report below this line. --- Please provide version for QT4. It is supported in 0.55.2 version and works very good (I use my local compilation). --- System information. --- Architecture: amd64 Kernel: Linux 2.6.24-rc7 Debian Release: lenny/sid 500 unstableftp.sunet.se 500 unstableftp.pl.debian.org 500 unstabledebian.o-hand.com 1 experimentalftp.pl.debian.org --- Package information. --- Depends(Version) | Installed -+-== kdelibs4c2a (= 4:3.5.7-1) | 4:3.5.8.dfsg.1-6 libacl1(= 2.2.11-1) | 2.2.45-1 libart-2.0-2 (= 2.3.18) | 2.3.19-3 libattr1(= 2.4.4-1) | 1:2.4.39-1 libaudio2| 1.9.1-1 libc6 (= 2.6-1) | 2.7-6 libfam0 | 2.7.0-13 libfontconfig1(= 2.4.0) | 2.5.0-2 libfreetype6 (= 2.3.5) | 2.3.5-1+b1 libgcc1 (= 1:4.2-20070516) | 1:4.3-20080116-1 libice6 (= 1:1.0.0) | 2:1.0.4-1 libidn11 (= 0.5.18) | 1.1-1 libjpeg62| 6b-14 libpng12-0 (= 1.2.13-4) | 1.2.15~beta5-3 libqt3-mt (= 3:3.3.7) | 3:3.3.7-9 libsm6 | 2:1.0.3-1+b1 libstdc++6 (= 4.2-20070516) | 4.3-20080116-1 libx11-6 | 2:1.1.1-1 libxcursor1 ( 1.1.2) | 1:1.1.9-1 libxext6 | 1:1.0.3-2 libxft2 ( 2.1.1) | 2.1.12-2 libxi6 | 2:1.1.3-1 libxinerama1 | 1:1.0.2-1 libxrandr2 (= 2:1.2.0) | 2:1.2.2-1 libxrender1 | 1:0.9.4-1 libxt6 | 1:1.0.5-3 zlib1g (= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-11 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461766: please add elinks to dependencies
Package: docbook-utils Version: 0.6.14-1 Severity: minor --- Please enter the report below this line. --- Current version of docbook-utils depends on lynx | links | w3m which force elinks users to install one of them due to fact that newest version of elinks do not provide links. Solution would be making docbook-utils also depend on elinks as an option - of course when it is possible. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.24-rc7 Debian Release: lenny/sid 500 unstableftp.sunet.se 500 unstableftp.pl.debian.org 500 unstabledebian.o-hand.com 1 experimentalftp.pl.debian.org --- Package information. --- Depends(Version) | Installed -+-=== docbook-dsssl| 1.79-5 jadetex | 3.13-9 lynx | OR links| OR w3m | sgmlspl | 1.03ii-32 sp | 1.3.4-1.2.1-47 perl | 5.8.8-12 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461207: bluez-utils 3.24-1 is not installable on amd64
Package: bluez-utils Version: 3.24-1 Severity: important --- Please enter the report below this line. --- Bluez-utils 3.24-1 on amd64 depends on libglib-2.0-0 2.15.1 which is nor present in Debian repository. I had to recompile it on my system to get installable version. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.24-rc7 Debian Release: lenny/sid 500 unstableftp.sunet.se 500 unstableftp.pl.debian.org 500 unstabledebian.o-hand.com 1 experimentalftp.pl.debian.org --- Package information. --- Depends (Version) | Installed =-+- dbus | 1.1.2-1 libbluetooth2 (= 3.14) | 3.24-1 libc6 (= 2.7-1) | 2.7-6 libdbus-1-3(= 1.1.1) | 1.1.2-1 libglib2.0-0 (= 2.14.0) | 2.14.4-2 libusb-0.1-4(= 2:0.1.12) | 2:0.1.12-9 lsb-base (= 3.0-3) | 3.1-24 makedev ( 3.3.8.2-0) | 2.3.1-84 OR udev | 0.114-2 module-init-tools | 3.3-pre11-4 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413500: Bug is in xserver-xorg-core?
Installing xserver-xorg-core 2:1.2.99.901-1 (which also fetch newer ATI driver package) without upgrading xserver-xorg to 7.2 also gives me no X11. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413500: Bug is in xserver-xorg-core?
Dnia poniedziałek, 12 marca 2007, Michel Dänzer napisał: On Mon, 2007-03-12 at 11:21 +0100, Marcin Juszkiewicz wrote: Installing xserver-xorg-core 2:1.2.99.901-1 (which also fetch newer ATI driver package) without upgrading xserver-xorg to 7.2 also gives me no X11. Looks like the driver doesn't detect any monitors; does Option MonitorLayout TMDS work around it? Nope ;( (II) RADEON(0): I2C bus DDC initialized. (II) RADEON(0): Legacy BIOS detected (II) RADEON(0): Connector0: DDCType-1, DACType-0, TMDSType--1, ConnectorType-1 (WW) RADEON(0): Invalid Monitor type specified for 2nd port (**) RADEON(0): MonitorLayout Option: Monitor1--Type TMDS, Monitor2--Type (II) RADEON(0): I2C device DDC:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DDC:ddc2 removed. (II) RADEON(0): I2C device DDC:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DDC:ddc2 removed. (II) RADEON(0): I2C device DDC:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DDC:ddc2 removed. (II) RADEON(0): DDC Type: 1, Detected Type: 0 (II) RADEON(0): (II) RADEON(0): Primary: Monitor -- TMDS Connector -- Proprietary DAC Type -- Primary TMDS Type -- NONE DDC Type -- MONID (II) RADEON(0): Secondary: Monitor -- NONE Connector -- Unsupported DAC Type -- TVDAC/ExtDAC TMDS Type -- NONE DDC Type -- NONE (II) RADEON(0): PLL parameters: rf=1432 rd=6 min=2 max=47961899834432; xclk=25000 (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEON(0): Validating modes on Primary head - (II) RADEON(0): DFP table revision: 2 (II) RADEON(0): Total number of valid DDC mode(s) found: 0 --
Bug#274843: Very old bug. Do you still have the problem ?
Dnia poniedziałek, 26 lutego 2007, Olivier Vitrat napisał: the bug you've reported is ~2 years old. Can you still reproduce this bug? If yes please give us a short note, if not, this bug will be closed in a few weeks (but you are of course free to reopen it). It is upstream reported too: http://bugs.kde.org/show_bug.cgi?id=103057 Applies to 3.5.6 upgrade too. I think that KDE developers will never fix that bug. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Try not! Do, or do not! There is no try! -- Yoda
Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Dnia środa, 22 listopada 2006 18:43, Frank Küster napisał:
Marcin Juszkiewicz [EMAIL PROTECTED] wrote:
On this machine kpsewhich was stat-ing all files in filesystem
Oh, this should not happen. Maybe some conffile setting is wrong? Can
you please send the output of
grep '^TEXMF =' /etc/texmf/texmf.cnf
11:15 [EMAIL PROTECTED]:hrw$ grep '^TEXMF =' /etc/texmf/texmf.cnf
TEXMF =
{$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}
grep '^TEXMF =' /etc/texmf/texmf.d/05TeXMF.cnf
11:15 [EMAIL PROTECTED]:hrw$ grep '^TEXMF =' /etc/texmf/texmf.d/05TeXMF.cnf
TEXMF =
{$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}
kpsewhich -debug=127 --format='web2c files' fmtutil.cnf kpsewhich.log
kdebug:fopen(/usr/bin/kpsewhich, r) = 0x804d090
kdebug:fclose(0x804d090) = 0
kdebug:Search path for cnf files (from compile-time paths.h)
kdebug: = :/usr/share/texmf/web2c:/usr/share/texmf/web2c
kdebug: before expansion =
$TETEXDIR:/usr/share/texmf/web2c:/usr/share/texmf/web2c
kdebug: application override path = (none)
kdebug: application config file path = (none)
kdebug: texmf.cnf path = (none)
kdebug: compile-time path =
$TETEXDIR:/usr/share/texmf/web2c:/usr/share/texmf/web2c
kdebug: default suffixes = .cnf
kdebug: other suffixes = (none)
kdebug: search only with suffix = 0
kdebug: numeric format value = 8
kdebug: runtime generation program = (none)
kdebug: runtime generation command = (none)
kdebug: program enabled = 0
kdebug: program enable level = 0
kdebug:start search(file=texmf.cnf, must_exist=1, find_all=1,
path=:/usr/share/texmf/web2c:/usr/share/texmf/web2c).
kdebug:kpse_normalize_path () = 0
kdebug:kpse_normalize_path (/usr/share/texmf/web2c) = 1
kdebug:kpse_normalize_path (/usr/share/texmf/web2c) = 1
kdebug:path element /usr/share/texmf/web2c = /usr/share/texmf/web2c/
kdebug:kpse_normalize_path (/usr/share/texmf/web2c/texmf.cnf) = 1
kdebug:kpse_normalize_path (/usr/share/texmf/web2c) = 1
kdebug:kpse_normalize_path (/usr/share/texmf/web2c/texmf.cnf) = 1
kdebug:fopen(/usr/share/texmf/web2c/texmf.cnf, r) = 0x804e070
kdebug:fclose(0x804e070) = 0
kdebug:fopen(/usr/share/texmf/web2c/texmf.cnf, r) = 0x804e070
kdebug:fclose(0x804e070) = 0
kdebug:hash_lookup(TEXMFDBS.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFDBS) =
$TEXMFHOME:$TEXMFSYSVAR:$TEXMFLOCAL:$TEXMFMAIN:$VARTEXFONTS:$TEXMFDIST
$TEXMFHOME:$TEXMFSYSVAR:$TEXMFLOCAL:$TEXMFMAIN:$VARTEXFONTS:$TEXMFDIST
kdebug:hash_lookup(TEXMFHOME.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFHOME) = $HOME/texmf $HOME/texmf
kdebug:hash_lookup(TEXMFSYSVAR.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFSYSVAR) = /var/lib/texmf /var/lib/texmf
kdebug:hash_lookup(TEXMFLOCAL.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFLOCAL) = /usr/local/share/texmf /usr/local/share/texmf
kdebug:hash_lookup(TEXMFMAIN.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFMAIN) = /usr/share/texmf /usr/share/texmf
kdebug:hash_lookup(VARTEXFONTS.kpsewhich) = (nil)
kdebug:hash_lookup(VARTEXFONTS) = /tmp/texfonts /tmp/texfonts
kdebug:hash_lookup(TEXMFDIST.kpsewhich) = (nil)
kdebug:hash_lookup(TEXMFDIST) = /usr/share/texmf-{texlive,tetex}
/usr/share/texmf-{texlive,tetex}
kdebug:Search path for ls-R files (from texmf.cnf)
kdebug: =
/home/hrw//texmf:/var/lib/texmf:/usr/local/share/texmf:/usr/share/texmf:/tmp/texfonts:/usr/share/texmf-texlive:/usr/share/texmf-tetex
kdebug: before expansion =
$TEXMFHOME:$TEXMFSYSVAR:$TEXMFLOCAL:$TEXMFMAIN:$VARTEXFONTS:$TEXMFDIST
kdebug: application override path = (none)
kdebug: application config file path = (none)
kdebug: texmf.cnf path =
$TEXMFHOME:$TEXMFSYSVAR:$TEXMFLOCAL:$TEXMFMAIN:$VARTEXFONTS:$TEXMFDIST
kdebug: compile-time path = /usr/share/texmf:/var/spool/texmf
kdebug: default suffixes = ls-R ls-r
kdebug: other suffixes = (none)
kdebug: search only with suffix = 0
kdebug: numeric format value = 9
kdebug: runtime generation program = (none)
kdebug: runtime generation command = (none)
kdebug: program enabled = 0
kdebug: program enable level = 0
kdebug:start search(files=[ls-R ls-r], must_exist=1, find_all=1,
path=/home/hrw//texmf:/var/lib/texmf:/usr/local/share/texmf:/usr/share/texmf:/tmp/texfonts:/usr/share/texmf-texlive:/usr/share/texmf-tetex).
kdebug:kpse_normalize_path (/home/hrw//texmf) = 1
kdebug:kpse_normalize_path (/home/hrw//texmf) = 1
kdebug:hash_lookup(/home/hrw/IRC) = (nil)
kdebug:dir_links(/home/hrw/IRC) = 4
and here it start to go through filesystem and loops in kernel build due
to symlinks:
kdebug:hash_lookup(/home/hrw/src/linux/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules
Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Dnia czwartek, 23 listopada 2006 12:09, Julian Gilbey napisał:
On Thu, Nov 23, 2006 at 11:30:39AM +0100, Marcin Juszkiewicz wrote:
Dnia środa, 22 listopada 2006 18:43, Frank Küster napisał:
kdebug:kpse_normalize_path (/home/hrw//texmf) = 1
It seems that $TEXMFHOME is expanding to /home/hrw//texmf with an
extra slash in it, meaning that it's searching your entire home
directory (a silly thing to do), so I suspect an extra slash somewhere
here. You may have a corrupted/modified version of
/etc/texmf/texmf.d/05TeXMF.cnf which is causing this.
12:57 [EMAIL PROTECTED]:hrw$ grep -v ^% /etc/texmf/texmf.d/05TeXMF.cnf
TEXMFMAIN = /usr/share/texmf
TEXMFDIST = /usr/share/texmf-{texlive,tetex}
TEXMFLOCAL = /usr/local/share/texmf
TEXMFSYSVAR = /var/lib/texmf
TEXMFSYSCONFIG = /etc/texmf
TEXMFHOME = $HOME/texmf
TEXMFVAR = $HOME/.texmf-var
TEXMFCONFIG = $HOME/.texmf-config
TEXMF =
{$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}
SYSTEXMF = $TEXMFLOCAL;$TEXMFMAIN;$TEXMFDIST
VARTEXFONTS = /tmp/texfonts
TEXMFDBS =
$TEXMFHOME;$TEXMFSYSVAR;$TEXMFLOCAL;$TEXMFMAIN;$VARTEXFONTS;$TEXMFDIST
Could you please now also send the the output of:
grep '^TEXMFHOME =' /etc/texmf/texmf.cnf
12:55 [EMAIL PROTECTED]:hrw$ grep '^TEXMFHOME =' /etc/texmf/texmf.cnf
TEXMFHOME = $HOME/texmf
echo $HOME
/home/hrw/
and here it start to go through filesystem and loops in kernel build
due to symlinks:
kdebug:hash_lookup(/home/hrw/src/linux/debian/linux-image-2.6.19-rc2/l
ib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/
2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/
source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debi
an/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-im
age-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-
rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/mod
ules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19
-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source
/debian/linux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/lin
ux-image-2.6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.
6.19-rc2/lib/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/li
b/modules/2.6.19-rc2/source/debian/linux-image-2.6.19-rc2/lib/modules/2
.6.19-rc2/source/drivers/infiniband/ulp) = (nil)
This is something which kpathsea is not designed to guard against.
Hmm. Perhaps it should, say, keep track of any symlinks it meets in a
path, and if it meets the identical symlink again, stop following it.
That would require some significant changes to libkpathsea, though.
Also, I believe this is quite a Unix-specific issue.
Then again, symlink loops like this are just plain evil.
Blame kernel-package?
12:58 [EMAIL PROTECTED]:hrw$ pwd
/home/hrw
12:58 [EMAIL PROTECTED]:hrw$ ll
src/linux/debian/linux-image-2.6.19-rc5/lib/modules/2.6.19-rc5/source
lrwxrwxrwx 1 hrw pavilon 19 2006-11-10 15:51
src/linux/debian/linux-image-2.6.19-rc5/lib/modules/2.6.19-rc5/source -
/home/hrw/src/linux
--
Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Dnia wtorek, 14 listopada 2006 19:24, Frank Küster napisał: Hello Marcin, do you just rarely use this machine, or have you forgotten about the problem? I hope you don't mind that I ping you. I was overloaded recently. Today I looked more into problem and found why it was a problem. On this machine kpsewhich was stat-ing all files in filesystem - but I have mounted remote samba share with thousands (if not millions) of files, have ~50 directories with unpacked firefox trunk build etc.. I switched into 'single', umounted all filesystems and tetex was installed very fast without any problems. --
Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Dnia piątek, 3 listopada 2006 14:23, Frank Küster napisał: One more question: Please send us the listing of the directories /etc/texmf/texmf.d/ /etc/texmf/updmap.d/ /etc/texmf/fmtutil.d/ /etc/texmf/language.d/ and if there are any files in there that are not from tex-common (names starting with 00) or tetex (numbertetex*.*), try to find from which packages these are, and send us dpkg -l package. 13:35 [EMAIL PROTECTED]:texmf$ ls -R .: fmt.d language.d texmf.cnf texmf.d updmap.d web2c xdvi.cfg.dpkg-new ./fmt.d: 00tex.cnf 40jadetex.cnf.dpkg-new 50cyrtexinfo.cnf.dpkg-new ./language.d: 00tex.cnf 10tetex.cnf ./texmf.d: 05TeXMF.cnf 45TeXinputs.cnf 65BibTeX.cnf 85Misc.cnf95NonPath.cnf 15Plain.cnf 55Fonts.cnf 75DviPS.cnf 90TeXDoc.cnf 96JadeTeX.cnf.dpkg-new ./updmap.d: 00updmap.cfg 10tetex-base.cfg 10tipa.cfg.dpkg-new 20tetex-extra.cfg.dpkg-new ./web2c: mktex.cnf 13:42 [EMAIL PROTECTED]:texmf$ for f in /etc/texmf/*/* ;do LC_ALL=C dpkg -S $f;done tex-common: /etc/texmf/fmt.d/00tex.cnf dpkg: /etc/texmf/fmt.d/40jadetex.cnf.dpkg-new not found. dpkg: /etc/texmf/fmt.d/50cyrtexinfo.cnf.dpkg-new not found. tex-common: /etc/texmf/language.d/00tex.cnf tetex-base: /etc/texmf/language.d/10tetex.cnf dpkg: /etc/texmf/texmf.d/05TeXMF.cnf not found. dpkg: /etc/texmf/texmf.d/15Plain.cnf not found. dpkg: /etc/texmf/texmf.d/45TeXinputs.cnf not found. dpkg: /etc/texmf/texmf.d/55Fonts.cnf not found. dpkg: /etc/texmf/texmf.d/65BibTeX.cnf not found. dpkg: /etc/texmf/texmf.d/75DviPS.cnf not found. dpkg: /etc/texmf/texmf.d/85Misc.cnf not found. dpkg: /etc/texmf/texmf.d/90TeXDoc.cnf not found. dpkg: /etc/texmf/texmf.d/95NonPath.cnf not found. dpkg: /etc/texmf/texmf.d/96JadeTeX.cnf.dpkg-new not found. dpkg: /etc/texmf/updmap.d/00updmap.cfg not found. tetex-base: /etc/texmf/updmap.d/10tetex-base.cfg dpkg: /etc/texmf/updmap.d/10tipa.cfg.dpkg-new not found. dpkg: /etc/texmf/updmap.d/20tetex-extra.cfg.dpkg-new not found. tex-common: /etc/texmf/web2c/mktex.cnf 13:42 [EMAIL PROTECTED]:texmf$ LC_ALL=C dpkg -l tex-common tetex-base +++-==-==-=== iF tetex-base 3.0.dfsg.3-1 Basic TeX input files of teTeX ii tex-common 0.38 Common infrastructure for using and --
Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Dnia piątek, 3 listopada 2006 11:47, Frank Küster napisał: If that happens again, please send the output of ps axf. One thing is different to the older bug, though: Back then, it wasn't possible to stop it with Ctrl-C. I rebooted machine since then and did 'apt-get remove tex-common tetex*' to get clean situation. After few hours I have: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3268 root 25 0 641m 614m 432 R 93.5 48.6 150:56.82 kpsewhich ps afx tree: PID TTY STAT TIME COMMAND 2077 ?Ss 0:01 kdeinit Running... 2203 ?S 2:48 \_ konsole [kdeinit] 29185 pts/12 Ss 0:00 | \_ /bin/bash 29215 pts/12 S 0:00 | | \_ bash 460 pts/12 Sl+0:05 | | \_ aptitude install openembedded-essential 1354 pts/12 S+ 0:00 | | \_ /usr/bin/dpkg --status-fd 17 --configure libkpathsea4 tex-common tetex-base tetex-bin texinfo sgml-base xml-core sgml-data docbook libosp5 libostyle1c2 openjade docbook-dsssl tetex-extra tipa jadetex libsgmls-perl sgmlspl docbook-utils openembedded-essential 1975 pts/12 S+ 0:00 | | \_ /bin/sh -e /var/lib/dpkg/info/tetex-base.postinst configure 3268 pts/12 R+ 147:15 | | \_ kpsewhich --format=web2c files fmtutil.cnf 'openembedded-essential' is metapackage: 15:55 [EMAIL PROTECTED]:hrw$ apt-cache show openembedded-essential Package: openembedded-essential Version: 1.1-1 Priority: optional Section: devel Maintainer: Marcin Juszkiewicz [EMAIL PROTECTED] Depends: python (= 2.3), ccache, build-essential, quilt, sed, bison, wget, cvs, subversion, git-core, monotone, coreutils, unzip, texi2html, texinfo, libsdl1.2-dev, docbook-utils, gawk Also, before you kill it again, please check whether there are any directories in /tmp that look like created by tetex's postinst, and just copy (cp -a) the most recent one outside /tmp, so that it is preserved. 15:52 [EMAIL PROTECTED]:hrw$ ls /tmp/ -a . gconfd-hrw index.html?sm_command=buildksocket-hrw orbit-root v995212 .. gconfd-root index.html?sm_command=build.1 mc-hrw ssh-UvPBQF1982 vmware-hrw album_info.xml gpg-eIVKXi kde-hrwmc-root test .X0-lock aptitudeEwiQYu .ICE-unixkde-hrw~ orbit-hrw v920934 .X11-unix --
