Bug#775322: Bootloader code issues and improvements
Additional issue: #23) syslinux does not apply kernel version filtering to multi-flavour scenarios -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Additional issue: #23) d syslinux does not apply kernel version filtering to multi-flavour scenarios -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775655: installation-reports: Successful installation on Asus X101CH
Package: installation-reports Severity: normal Boot method: USB Image version: http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-lxde-CD-1.iso Date: 2015-01-05 05:45 Machine: Asus X101CH Base System Installation Checklist: Initial boot:[O] Detect network card: [O] Configure network: [O] Detect CD:[O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives:[O] Partition hard drives: [O] Install base system: [O] Install tasks: [O] Install boot loader: [O] Overall install:[O] Comment: I'm happy. Thank you very much for the work done! = Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="8 (jessie) - installer build 20150105-00:02" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux comp 3.16.0-4-586 #1 Debian 3.16.7-ckt2-1 (2014-12-08) i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller [8086:0bf1] (rev 03) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:84a9] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller [8086:0be1] (rev 09) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:84a9] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8516] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 3 [8086:27d4] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 4 [8086:27d6] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation NM10 Family LPC Controller [8086:27bc] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] [8086:27c1] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: Kernel driver in use: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus Controller [8086:27da] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad] lspci -knn: 02:00.0 Network controller [0280]: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01) lspci -knn: Subsystem: AzureWave Device [1a3b:1089] lspci -knn: Kernel driver in use: ath9k lspci -knn: 04:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8152 v2.0 Fast Ethernet [1969:2062] (rev c1) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8468] lspci -knn: Kernel driver in use: atl1c usb-list: usb-list: Bus 01 Device 01: UHCI Host Controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Sub
Bug#775653: linux-image-3.16.0-4-amd64: screen/Xorg freezes for seconds on intel hardware/laptop
Package: src:linux Version: 3.16.7-ckt2-1 Severity: important While working on my X1 Carbon (haswell) laptop this morning my screen frooze, but keyboard was still working. I managed to contact my laptop from another laptop and get the kernel log I've replaced below. I forgot to get error state, sorry, if that was relevant. -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=UUID=bde07f5a-8ab2-4859-826e-d5068330ca5a ro loglevel=4 cryptdevice=/dev/mapper/sda4_crypt:sda4_crypt:discard ** Not tainted ** Kernel log: [ 853.722634] virbr1: port 4(vnet4) entered listening state [ 854.137031] kvm: zapping shadow pages for mmio generation wraparound [ 855.727497] virbr1: port 4(vnet4) entered learning state [ 857.732539] virbr1: topology change detected, propagating [ 857.732542] virbr1: port 4(vnet4) entered forwarding state [ 860.369152] kvm [2899]: vcpu0 unhandled rdmsr: 0x606 [ 861.005937] kvm [2899]: vcpu0 unhandled rdmsr: 0x611 [ 861.006533] kvm [2899]: vcpu0 unhandled rdmsr: 0x639 [ 861.007073] kvm [2899]: vcpu0 unhandled rdmsr: 0x641 [ 861.007608] kvm [2899]: vcpu0 unhandled rdmsr: 0x619 [ 866.505385] device vnet5 entered promiscuous mode [ 866.529293] virbr1: port 5(vnet5) entered listening state [ 866.529308] virbr1: port 5(vnet5) entered listening state [ 866.928964] kvm: zapping shadow pages for mmio generation wraparound [ 868.534151] virbr1: port 5(vnet5) entered learning state [ 870.539190] virbr1: topology change detected, propagating [ 870.539193] virbr1: port 5(vnet5) entered forwarding state [ 873.176930] kvm [2983]: vcpu0 unhandled rdmsr: 0x606 [ 873.831159] kvm [2983]: vcpu0 unhandled rdmsr: 0x611 [ 873.831684] kvm [2983]: vcpu0 unhandled rdmsr: 0x639 [ 873.832156] kvm [2983]: vcpu0 unhandled rdmsr: 0x641 [ 873.832623] kvm [2983]: vcpu0 unhandled rdmsr: 0x619 [ 1640.241086] [ cut here ] [ 1640.241143] WARNING: CPU: 0 PID: 1278 at /build/linux-CMiYW9/linux-3.16.7-ckt2/drivers/gpu/drm/i915/intel_display.c:3324 intel_crtc_wait_for_pending_flips+0x165/0x170 [i915]() [ 1640.241145] Modules linked in: vhost_net vhost macvtap macvlan xt_conntrack ipt_REJECT xt_tcpudp iptable_filter tun bridge stp llc binfmt_misc bnep xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables deflate ctr twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cbc cmac xcbc rmd160 sha512_ssse3 sha512_generic sha256_ssse3 sha256_generic [ 1640.241184] hmac crypto_null af_key xfrm_algo arc4 nls_utf8 nls_cp437 vfat fat ecb iTCO_wdt iTCO_vendor_support iwlmvm mac80211 uvcvideo videobuf2_vmalloc videobuf2_memops x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp videobuf2_core v4l2_common efi_pstore videodev kvm_intel media kvm btusb psmouse iwlwifi bluetooth efivars cdc_mbim serio_raw snd_usb_audio cdc_wdm cdc_ether i2c_i801 cdc_ncm snd_usbmidi_lib 6lowpan_iphc cfg80211 usbnet mii cdc_acm lpc_ich snd_rawmidi snd_seq_device mfd_core snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic joydev snd_hda_intel snd_hda_controller wmi snd_hda_codec thinkpad_acpi snd_hwdep snd_pcm_oss mei_me snd_mixer_oss shpchp mei snd_pcm snd_timer nvram snd soundcore rfkill i2c_designware_platform i2c_designware_core evdev tpm_tis ac battery [ 1640.241224] tpm processor loop fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq algif_skcipher af_alg hid_generic usbhid hid dm_crypt dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel e1000e ptp aesni_intel pps_core aes_x86_64 lrw gf128mul glue_helper ablk_helper ahci ehci_pci cryptd libahci ehci_hcd i915 xhci_hcd libata i2c_algo_bit drm_kms_helper scsi_mod drm usbcore usb_common i2c_core thermal video thermal_sys button [ 1640.241260] CPU: 0 PID: 1278 Comm: Xorg Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1 [ 1640.241262] Hardware name: LENOVO 20A70092MD/20A70092MD, BIOS GRET42WW (1.19 ) 11/20/2014 [ 1640.241263] 0009 81507263 81065847 [ 1640.241267] 8802338d3000 880236388210 88003692f000 [ 1640.241269] 88003692f000 a0219e85 88023526ec20 [ 1640.241273] Call Trace: [ 1640.241280] [] ? dump_stack+0x41/0x51 [ 1640.241286] [] ? warn_slowpath_common
Bug#775654: RM: ooniprobe/1.2.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi! Even if ooniprobe is more or less usable in its current state, I think it is not yet ready to be part of a stable release. #766061 makes a bad user experience and the software is still elvolving fast. An old version is likely to just be a burden for upstream in two years. Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#775652: Acknowledgement (Package: libreoffice)
Sorry -- I should have said "menu-bar has disappeared" On Sun, Jan 18, 2015 at 1:03 PM, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian LibreOffice Maintainers > > If you wish to submit further information on this problem, please > send it to 775...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 775652: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775652 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems -- http://www.the-magus.in http://blog.languager.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775322: live-build: ditch grub-legacy support?
On Sat, 17 Jan 2015 03:44:49 +0100 "emil.widm...@gmail.com" wrote: > pleace don't ditch grub-legacy if not necessary I managed to completely overlook your message somehow. Please state a (good) reason. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775652: Package: libreoffice
Subject: libreoffice: Menus have disappeared in LO Package: libreoffice Version: 1:4.3.3-2 Severity: important Dear Maintainer, Menus have disappeared from libreoffice -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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) Versions of packages libreoffice depends on: ii fonts-dejavu 2.34-1 ii fonts-sil-gentium-basic1.1-7 ii libreoffice-avmedia-backend-gstreamer 1:4.3.3-2 ii libreoffice-base 1:4.3.3-2 ii libreoffice-calc 1:4.3.3-2 ii libreoffice-core 1:4.3.3-2 ii libreoffice-draw 1:4.3.3-2 ii libreoffice-impress1:4.3.3-2 ii libreoffice-java-common1:4.3.3-2 ii libreoffice-math 1:4.3.3-2 ii libreoffice-report-builder-bin 1:4.3.3-2 ii libreoffice-writer 1:4.3.3-2 ii python3-uno1:4.3.3-2 Versions of packages libreoffice recommends: ii fonts-liberation 1.07.4-1 ii libpaper-utils1.1.24+nmu3 Versions of packages libreoffice suggests: ii cups-bsd 1.7.5-10 ii default-jre [java5-runtime] 2:1.7-52 pn gstreamer1.0-ffmpeg ii gstreamer1.0-plugins-bad 1.4.0-1 ii gstreamer1.0-plugins-base 1.4.0-1 ii gstreamer1.0-plugins-good 1.4.0-1 ii gstreamer1.0-plugins-ugly 1.4.0-1 ii hunspell-en-us [hunspell-dictionary] 20070829-6 pn hyphen-hyphenation-patterns ii iceweasel 31.0-3 ii imagemagick 8:6.8.9.6-4+b1 ii libgl1-mesa-glx [libgl1] 10.2.6-1 pn libreoffice-gnome | libreoffice-kde pn libreoffice-grammarcheck pn libreoffice-help-4.3 pn libreoffice-l10n-4.3 pn libreoffice-officebean ii libsane 1.0.24-1.1+b1 ii libxrender1 1:0.9.8-1+b1 pn myspell-dictionary pn mythes-thesaurus pn openclipart-libreoffice ii openjdk-7-jre [java5-runtime] 7u65-2.5.2-4 pn pstoedit pn unixodbc Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.1 ii fonts-opensymbol 2:102.6+LibO4.3.2-1 ii libatk1.0-0 2.12.0-1 ii libboost-date-time1.55.0 1.55.0+dfsg-2 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libclucene-contribs1 2.3.3.4-4 ii libclucene-core1 2.3.3.4-4 ii libcmis-0.4-4 0.4.1-7 ii libcups2 1.7.5-10 ii libcurl3-gnutls 7.38.0-4 ii libdbus-1-3 1.8.8-1+b1 ii libdbus-glib-1-2 0.102-1 ii libeot0 0.01-3 ii libexpat1 2.1.0-6 ii libexttextcat-2.0-0 3.4.4-1 ii libfontconfig12.11.0-6 ii libfreetype6 2.5.2-1.1 ii libgcc1 1:4.9.1-19 ii libgdk-pixbuf2.0-02.30.7-1 ii libgl1-mesa-glx [libgl1] 10.2.6-1 ii libglew1.10 1.10.0-3 ii libglib2.0-0 2.42.0-2 ii libgltf-0.0-0 0.0.2-2 ii libglu1-mesa [libglu1]9.0.0-2 ii libgraphite2-31.2.4-3 ii libgtk2.0-0 2.24.24-1 ii libharfbuzz-icu0 0.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libhunspell-1.3-0 1.3.3-2 ii libhyphen02.8.7-3 ii libice6 2:1.0.9-1+b1 ii libicu52 52.1-5 ii libjpeg62-turbo 1:1.3.1-11 ii liblangtag1 0.5.1-2 ii liblcms2-22.6-3+b3 ii libldap-2.4-2 2.4.39-1.1+b1 ii libmythes-1.2-0 2:1.2.4-1 ii libneon27-gnutls 0.30.0-4 ii libnspr4 2:4.10.7-1 ii libnss3 2:3.17-1 ii libodfgen-0.1-1 0.1.1-2 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-01.2.50-2 ii librdf0 1.0.17-1+b1 ii libreoffice-common1:4.3.3-2 ii librevenge-0.0-0 0.0.1-3 ii libsm62:1.2.2-1+b1 ii libssl1.0.0 1.0.1j-1 ii libstdc++64.9.1-19 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxinerama1 2:1.1.3-1+b1 ii libxml2 2.9.1+dfsg1-4 ii libxrandr22:1.4.2-1+b1 ii libxrender1 1:0.9.8-1+b1 ii libxslt1.11.1.28-2 ii li
Bug#775651: systemd: /run/user/$UID directories are created with type tmpfs_t on SE Linux
Package: systemd
Version: 215-9
Severity: normal
# grep auditallow local.te
auditallow domain tmpfs_t:dir create;
# grep granted /var/log/audit/audit.log
type=AVC msg=audit(1421563773.398:239): avc: granted { create } for pid=4302
comm="systemd" name="systemd" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:240): avc: granted { create } for pid=4302
comm="systemd" name="generator" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:241): avc: granted { create } for pid=4302
comm="systemd" name="generator.early" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:242): avc: granted { create } for pid=4302
comm="systemd" name="generator.late" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
# ls -laZ /run/user
total 0
drwxr-xr-x. 4 root root system_u:object_r:var_auth_t:SystemLow 80 Jan 18
17:58 .
drwxr-xr-x. 26 root root system_u:object_r:var_run_t:SystemLow 1080 Jan 18
17:58 ..
drwx--. 3 root root system_u:object_r:var_auth_t:SystemLow 60 Jan 18
17:34 0
drwx--. 3 rjc rjc system_u:object_r:tmpfs_t:SystemLow 60 Jan 18
17:58 1001
I have an auditallow rule to audit creation of tmpfs_t directories. As you can
see systemd creates such directories when I login. The directory "0" has the
correct context because I ran "restorecon" but the directory "1001" has the
wrong context because I just logged in as that user.
There are no auto trans rules to give it the type tmpfs_t and the file_contexts
also specify var_auth_t. I think that systemd is requesting tmpfs_t as the
type.
-- Package-specific info:
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-58
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-4
ii libgcrypt20 1.6.2-4+b1
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2+b3
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-9
ii mount 2.25.2-4
ii sysv-rc 2.88dsf-58
ii udev215-9
ii util-linux 2.25.2-4
Versions of packages systemd recommends:
ii dbus1.8.14-1
ii libpam-systemd 215-9
Versions of packages systemd suggests:
pn systemd-ui
-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=25M
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774467: references cdn.debian.net, which is deprecated
On Sat, 2015-01-17 at 00:21 +0900, Osamu Aoki wrote: > control: severity 774468 minor ... > So this is not so urgent/important issue which requires a new upload > just for this documentation bug during the late freeze period. > Its a minor documentation bug. Agreed for debmake but for pbuilder the default configuration contains cdn.debian.net so I don't think we should refer to it from packages in jessie. The release team have accepted updates to fix this issue in other packages (such as piuparts) so I would suggest trying to fix this. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#775618: beets: FTBFS in jessie: Tests failures
Looks like: https://github.com/sampsyo/beets/commit/80038e2a3fe6f5ac174a30f6fd01ebf8dd63e414 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
(forgot to cc the bug, here's a copy) > I did not find that problem in my tests. But that can be explained by > saying that my initial tests were done with live-build-4.0. The problem also exists in 4.x. For my text amd64 sid build using grub2, I have the following grub2 menu entries: - Debian GNU/Linux - live - Debian GNU/Linux - live (fail-safe mode) - Debian GNU/Linux - live, kernel 3.16.0-4-amd64 - Debian GNU/Linux - live, kernel 3.16.0-4amd64 (fail-safe mode) - If you ignore the labels and look at the kernel, initrd and append (kernel param) details behind them (by looking at the grub config file, or using edit mode when grub is running), you'll see that the 1st entry is identical to the 3rd and the 2nd is identical to the 4th. (In actual fact all four will be identical building from the current 4.x/5.x codebases due to a mistake in the code, which I have fixed in the set of patches provided earlier). The current code always outputs the first two "default" entries (if you specify multiple kernel flavours then it uses the first specified here), then it outputs a pair for each and every kernel flavour specified, even though that creates duplicate entries for the first. This is not the case in syslinux. I intend to rework grub2 to remove this redundancy, matching syslinux. > As I was about to improve grub2 support on Live Build (changed my mind > because Debian's Grub2 package does not match the minimum for Super > Grub2 Disk) I'll explain a bit about what I had in mind. > > Hopefully you can share some of these ideas and, who knows, implement > some of them. > > 1) SVG and bootloaders directory > 1.1) If you check the current default Debian Live, at least in Debian > Wheezy, you will see that its boot background image for > syslinux/isolinux family is based on a: svg.in file which gets > converted into a svg. Finally the svg file is converted into something > that svg can understand. I had no idea what you were talking about, then I went and took a brief look at the live-build v3.x code and I see it. I haven't used 3.x, and I haven't looked in any detail at the code you're referring to, but 4.x changed this behaviour; it replaces a few text placeholders in the svg it uses, but then just uses that svg, it does not convert it to a png. That is, with a config that defaults to using the /usr/share/live/build/bootloaders files, and thus the splash with the black background and yellow construction workers helmet, which contains those placeholders. If using a config from the live-images package, these contain a local config copy of the bootloader files, with a different, Debian themed svg, without the text placeholders, so the svg is used as is. > I'm just saying to clone and reuse this code but to produce an image > that grub2 can understand and use in one of its themes. For grub2, the "template" files in /usr/share/live/build/templates/grub2 are used, including a tga splash image which is identical to the default syslinux one, except being a tga, the text placeholder thing can't be done. So unless you really want that text, the splash is otherwise the same, and I see no point in generating a tga/png from the svg. On the issue of the text displayed in the svg, I actually really dislike it. I was considering the possibility of alternate solutions for providing that info in the bootloader. I haven't explored that much yet though since I've got much more important things to work on. > 1.2) Rework the theme to match the default syslinux one. > > Rework the current grub2 theme (if there is one) to match the current > syslinux one. Why? I would like to see the same boot menu by default > either by using syslinux as a bootloaer or by using grub2. I am not completely sure what you're talking about here, there are three possibilities that come to mind (perhaps you mean more than one of these): 1) Menu label consistency between grub2 and syslinux, and menu hierarchy. I would like to see consistency here and that's something I'm working towards in these patches. 2) Splash "theme" consistency. The splash, with the exception of the text mentioned above, is already identical. 3) Trying to manipulate grub2 into displaying things similarly to syslinux, e.g. changing the size and location of the menu "box", etc. I have no idea whether this can be done, though I have noticed that the EFI grub2 bootloader menu displayed from an official Debian Wheezy install disc looks completely different to how I expect grub menus to look. Perhaps you can theme things much more than I realise (more than just splash and a few text/background/highlight colours). If we can, and a brief google image search suggests it may very well be possible, then I am totally on board with doing that, and by all means go ahead and get started on this if you like; I would suggest you start by taking the new Jessie svg splash I supplied in bug #775527, make a png from that, use live-build v5.x from debian next, plus my supplied set of patches,
Bug#626185: awstats can't handle bad request log entries
Package: awstats Followup-For: Bug #626185 Okay, so these are the exact steps how to reproduce this, using a QEMU/KVM virtual machine running the latest Debian/Stable. If you still can't reproduce this, please provide the Apache log line you got instead, so I can analyze why you can't reproduce this. --- Part A: Setup virtual machine A.1. Download latest Debian/Stable Netinst ISO debian-7.8.0-amd64-netinst.iso A.2. Verify its checksum echo '9792020579824057723446a92ab97d50fdb7af15d265ff4be9081a963e36b3e3e6f44127766219320bc863c6a7ec378388a9d6faa7b51c3f74b259dc9049e071 debian-7.8.0-amd64-netinst.iso' | shasum -c A.3. Create image for QEMU/KVM qemu-img create test.raw 2G A.4. Boot from ISO image qemu-system-x86_64 -boot once=d -enable-kvm -m 1G -hda test.raw -cdrom debian-7.8.0-amd64-netinst.iso A.5. Run installer using all default settings A.6. Finally reboot --- Part B: Within the virtual machine B.1. Login into the virtual machine as root, run the following commands there B.2. Update to latest updates, just to be sure apt-get update apt-get upgrade B.3. Install Apache, using just he default configuration apt-get install apache2-mpm-prefork B.4. Perform invalid HTTP request wget -qO- https://localhost:80 B.5. Show last log line tail -1 /var/log/apache2/access.log B.6. The output of the last command is (timestamp replaced with "..."): ::1 - - [...] "\x16\x03" 501 289 "-" "-" -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775450: clojure1.6: clojure 1.6 doesn't work with gij/gcj 4.9 instead of openjdk
On 01/15/2015 01:44 PM, Rogério Brito wrote: > On Jan 15 2015, Emmanuel Bourg wrote: >> But at least we should replace java2-runtime-headless with >> java6-runtime-headless. > > That's great and would, at least, make it clear that once installed, at > least the basics of clojure would work. I have updated the dependency - it will be part of the next upload. Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#634986: /donations.html: Please link to debian.ch for donations in CHF
On Fri, 2015-01-16 at 16:49 +, Philipp Hug wrote: > Yes, I'll enable ssl on it. I've committed the change to the donations page, when SSL is available, please either commit the change to webwml or poke me about it. If you would prefer not to pay for the SSL cert, you could use this offer: https://www.globalsign.com/ssl/ssl-open-source/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#775638: gdnsd: FTBFS in jessie: dh_auto_test: make -j1 test returned exit code 2
reassign 775638 geoip-database 20141027-1 retitle 775638 IPv6 database is corrupt severity 775638 grave thanks Hi, thanks On Sun, Jan 18, 2015 at 01:44:44AM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in jessie (in a jessie chroot, not a > sid chroot), your package failed to build on amd64. > > Relevant part (hopefully): > > > Checking basic database load on file /usr/share/GeoIP/GeoIP.dat ... OK > > Checking basic database load on file /usr/share/GeoIP/GeoIPv6.dat ... > > Load-only test on file '/usr/share/GeoIP/GeoIPv6.dat' failed w/ exit status > > 134; Test Output: > > info: Loading configuration from > > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/config' > > info: plugin_geoip: map 'my_prod_map': Processing GeoIP database > > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' > > error: plugin_geoip: map 'my_prod_map': Error traversing GeoIP database, > > corrupt? > > error: plugin_geoip: map 'my_prod_map': (Re-)loading geoip database > > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' > > failed! > > fatal: plugin_geoip: map 'my_prod_map': cannot continue initial load This is a test suite failure, reporting that geoip-database's GeoIPv6.dat is corrupt. It looks like something's fishy there, after checking with MaxMind's own geoiplookup6 tools: $ dpkg-query -W geoip-database geoip-database 20141009-1 $ geoiplookup6 www.maxmind.com GeoIP Country V6 Edition: HK, Hong Kong $ geoiplookup6 2001::1 GeoIP Country V6 Edition: IP Address not found $ dpkg-query -W geoip-database geoip-database 20141027-1 $ geoiplookup6 www.maxmind.com $ geoiplookup6 2001::1 $ I've verified that gdnsd builds fine with geoip-database 20141009-1, which corresponds with the above output. it seems that geoip-database 20141027-1 ships a corrupt, IPv6 database. Reassigning & bumping severity. Best regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775650: gnome-shell: Brightness slider moves uncontrollably.
Package: gnome-shell
Version: 3.14.2-3+b1
Severity: normal
Tags: patch
Dear Maintainer,
My computer is a Sony VAIO VPCEA45FL laptop, with 9 different brightness
levels.
The brightness slider on the shell's top panel moves uncontrollably when trying
to adjust screen brightness.
* What led up to the situation? Installing GNOME 3.14 on Jessie.
* What exactly did you do (or not do) that was effective (or
ineffective)? Scrolling or dragging the brightness slider.
* What was the outcome of this action? Slider moves erratically, along with
the screen's brightness levels.
* What outcome did you expect instead? I expected the slider to move
normally, adjusting the brightness accordingly.
It seems to be that two methods are involved in this, in file
js/ui/status/brightness.js, the _sliderChanged and the _sync functions, the
first takes the slider value and sets the brightness and the second syncs the
slider, taking the brightness value and setting the slider, basically making a
recursive call between them. I made this patch were I added a variable that
counts the instances were the brightness was changed by the slider, so it only
syncs when brightness was changed by an external factor (e.g. fn brightness
keys).
## BEGINNING OF FILE ##
Index: gnome-shell-3.14.2/js/ui/status/brightness.js
===
--- gnome-shell-3.14.2.orig/js/ui/status/brightness.js
+++ gnome-shell-3.14.2/js/ui/status/brightness.js
@@ -19,6 +19,8 @@ const BrightnessInterface = ' \
const BrightnessProxy = Gio.DBusProxy.makeProxyWrapper(BrightnessInterface);
+var changeCount = 0;
+
const Indicator = new Lang.Class({
Name: 'BrightnessIndicator',
Extends: PanelMenu.SystemIndicator,
@@ -58,13 +60,18 @@ const Indicator = new Lang.Class({
_sliderChanged: function(slider, value) {
let percent = value * 100;
+changeCount++;
this._proxy.Brightness = percent;
},
_sync: function() {
-let visible = this._proxy.Brightness >= 0;
-this._item.actor.visible = visible;
-if (visible)
-this._slider.setValue(this._proxy.Brightness / 100.0);
+if (changeCount==0&&!this._slider._dragging) {
+let visible = this._proxy.Brightness >= 0;
+this._item.actor.visible = visible;
+if (visible)
+this._slider.setValue(this._proxy.Brightness / 100.0);
+}
+if(changeCount>0)
+changeCount--;
},
});
## END OF FILE
This fixed the problem for me, but the actual change in brightness can be very
slow, probably because it requests a change for every little change in the
slider,
which I think it's every 2%, so I added some changes to this patch, so just
changes bigger than 5 percent are requested, however this may affect systems
with
more than 20 different levels, but I'm including it in case you may find it
useful,
## BEGINNING OF FILE ##
Index: gnome-shell-3.14.2/js/ui/status/brightness.js
===
--- gnome-shell-3.14.2.orig/js/ui/status/brightness.js
+++ gnome-shell-3.14.2/js/ui/status/brightness.js
@@ -19,6 +19,9 @@ const BrightnessInterface = ' \
const BrightnessProxy = Gio.DBusProxy.makeProxyWrapper(BrightnessInterface);
+var changeCount = 0;
+var lastValue = 0;
+
const Indicator = new Lang.Class({
Name: 'BrightnessIndicator',
Extends: PanelMenu.SystemIndicator,
@@ -53,18 +56,27 @@ const Indicator = new Lang.Class({
this._item.actor.connect('key-press-event', Lang.bind(this,
function(actor, event) {
return this._slider.onKeyPressEvent(actor, event);
}));
+lastValue = this._proxy.Brightness;
},
_sliderChanged: function(slider, value) {
let percent = value * 100;
-this._proxy.Brightness = percent;
+if(Math.abs(percent-lastValue)>=5||percent==0||percent==100) {
+changeCount++;
+this._proxy.Brightness = percent;
+lastValue = percent;
+}
},
_sync: function() {
-let visible = this._proxy.Brightness >= 0;
-this._item.actor.visible = visible;
-if (visible)
-this._slider.setValue(this._proxy.Brightness / 100.0);
+if (changeCount==0&&!this._slider._dragging) {
+let visible = this._proxy.Brightness >= 0;
+this._item.actor.visible = visible;
+if (visible)
+this._slider.setValue(this._proxy.Brightness / 100.0);
+}
+if(changeCount>0)
+changeCount--;
},
});
## END OF FILE
A proper fix would probably be implementing detection of available
brightness levels, but that's beyond my skills.
Thanks for your attention.
-
Bug#775635: [Pkg-tcltk-devel] Bug#775635: chiark-tcl: FTBFS in jessie: build-dependency not installable: tcl8.4-dev
Hi Ian! On Sun, Jan 18, 2015 at 3:37 AM, Ian Jackson wrote: > > Anyway, I'm a bit puzzled. I uploaded a new version of this package > in November 2014 and it built fine. tcl8.4-dev seemed to be available > then. I deliberately did not update it to build-depend on 8.5 because > I wanted to avoid perturbing what was in testing by potentially > introducing depedencies on 8.5-specific aspects of the Tcl ABI. > > But according to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737104 > tcl8.4-dev was removed in January 2014. How did I and the buildds > manage to build chiark-tcl 1.1.2 using tcl8.4-dev in November ? > https://buildd.debian.org/status/logs.php?pkg=chiark-tcl Tcl/Tk 8.4 is removed from jessie, and not removed from sid yet (a few packages still depend on it). This means that if you upload a package to unstable it will happily find tcl8.4-dev but it won't be able to go to testing. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775649: ITP: haskell-formatting -- Type safe format function
Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name: haskell-formatting Version : 6.1.1 Upstream Author : Chris Done * URL : http://hackage.haskell.org/package/formatting * License : BSD3 Programming Lang: Haskell Description : Type safe format function Combinator-based type-safe formatting (like printf() or FORMAT), modelled from the HoleyMonoids package. This package is dependency of `git-vogue`. I maintain is as part of debian-haskell-group. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775648: ITP: haskell-text-format -- Text formatting
Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name: haskell-text-format Version : 0.3.1.1 Upstream Author : Bryan O'Sullivan * URL : https://hackage.haskell.org/package/text-format * License : BSD3 Programming Lang: Haskell Description : Text formatting Text formatting library optimized for both ease of use and high performance. This package is dependency of `git-vogue` to be packaged after. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775053: debbugs: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/debbugs/examples/config
On Sat, 17 Jan 2015, Vagrant Cascadian wrote: > That said, debbugs hasn't seen an upload to unstable since 2003, and > the upload in experimental was in 2010 (the patch should apply to git > without many changes)... maybe it shouldn't ship with Jessie? Yeah, I'm trying to figure that out myself; I think it probably should ship with Jessie, because I'd want to fix any security bugs that people found, but I'm not sure how useful it is in general. Thanks for the patch; I'll get this uploaded this weekend. -- Don Armstrong http://www.donarmstrong.com Leukocyte... I am your father. -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775647: Acknowledgement (ed: Use upstream "red" script rather than symbolic link)
On 2015-01-18 02:09, Debian Bug Tracking System wrote: > If you wish to submit further information on this problem, please > send it to 775...@bugs.debian.org. I can't tell from this (closed) bug-report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710865 whether this was the same issue and/or if it was actually fixed. However, since there are security implications, I would recommend switching from the symlink to the upstream red(1) shell-script in Stable as well as any changes that may have gone into Testing/Sid. -Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
El 17/01/15 a las 02:21, jnqnfe escribió: On 15/01/2015 14:52, adrian15 wrote: I just write down here that I will have to review your mentioned: #1, #2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for loopback.cfg file) so that it matches your improvements and fixes. No problem, I will upload the first batch of work soon, just running a test and need to find out why I'm getting an error trying to load memtest86 first. I will also take your looback support into consideration and try to help review it and mold it into a state ready to merge. Thank you very much! Do you mean the normal entry and the single entry per one kernel? Or do you actually mean repeated kernels? Syslinux generates only a single pair (normal + failsafe) when there is only one kernel, and if multiple kernels, one such pair each. With grub/grub2, it's outputting this pair of entries as a "standard/default" pair, then also one per kernel, so for one of the kernels you're getting double entries, i.e. if you've only got only one kernel, you get two "normal" entries and two "failsafe" entries that are identical except in their labels, which is unecessary. I intend to bring grub2 inline with syslinux. I did not find that problem in my tests. But that can be explained by saying that my initial tests were done with live-build-4.0. I had also thought on this problem. I think there should a way of just reusing the current syslinux SVG file so that it generates a suitable image that can be used by grub2 as a background image. I disagree, why add such complexity to live-build when you can just provide a ready made image file as we do now. Besides, this problem wasn't about creation of the image, it was about grub2 not displaying it. I have created a small set of commits which improve the grub2 config file, solving several graphics configuration issues, including a getting the splash background displayed. As I was about to improve grub2 support on Live Build (changed my mind because Debian's Grub2 package does not match the minimum for Super Grub2 Disk) I'll explain a bit about what I had in mind. Hopefully you can share some of these ideas and, who knows, implement some of them. 1) SVG and bootloaders directory 1.1) If you check the current default Debian Live, at least in Debian Wheezy, you will see that its boot background image for syslinux/isolinux family is based on a: svg.in file which gets converted into a svg. Finally the svg file is converted into something that svg can understand. I'm just saying to clone and reuse this code but to produce an image that grub2 can understand and use in one of its themes. 1.2) Rework the theme to match the default syslinux one. Rework the current grub2 theme (if there is one) to match the current syslinux one. Why? I would like to see the same boot menu by default either by using syslinux as a bootloaer or by using grub2. You will understand why a bit later. 2) Syslinux and loopback If you check my bug about loopback cfg support you will see that I'm using as much as I can the default grub2 code. Let's suppose you build a Debian Live which has loopack cfg support. If you boot it normally isolinux will show the default syslinux theme and it will be pretty. If you boot it from Super Grub2 Disk thanks to its option to load loopback cfg you will find another no-so-pretty menu. If the loopback cfg support code in Live Build takes that into consideration it will take the syslinux svg.in, convert it into svg, then into a grub2-theme-suitable-image. Then you can have a great menu even if booting from Super Grub2 Disk or other loopback cfg system. 3) Syslinux and grub hybrid iso My grub2 improvements suggestions are given by me wanting Super Grub2 Disk to be included by default on Debian Live builds. The thing is that I do not want it to be emulated as a RAM image but I want it to be native. That would also add the benefit of supporting EFI by default very easily. So, first of all I need a grub2 based Debian Live which its grub2 package matches minimum requirements for Super Grub2 Disk (not in Jessie currently). Then I just need to make the Super Grub2 Disk scripts (they are just cfg files) get into that disk. So what does happen when you have a grub2 Debian Live iso? How do the multi distro usb tools handle them? Well, most of these tools cannot handle them. However these tools are very good at handling isolinux based isos. So... a nice new option for Debian Live which I think I would only use myself for Rescatux would be the following one: Build a grub2 based Debian Live while at the same time you add to it the files that isolinux build would have added. Just to be clear in the end the ISO would be booted by grub2 but not by isolinux. This new kind of syslinux and grub hybrid iso will have the advantage of having a native grub2 (thus a native Super Grub2 Disk would be easy) and at the same time the Multi USB tools will detect
Bug#696223: linux-image-3.6-trunk-amd64: USB keyboard and mouse stop working
Package: src:linux Version: 3.16.7-ckt2-1 Followup-For: Bug #696223 Dear Maintainer, * What led up to the situation? Upgrading system * What exactly did you do (or not do) that was effective (or ineffective)? Boot into system * What was the outcome of this action? Keyboard and mice behind USB hub (HP Monitor) don't work after bootup * What outcome did you expect instead? Working keyboard and mice after booting currently in Debian/testing I have trouble with my keyboard (Lenovo) and mice (Lenovo) which don't respond to any input after some time when booting. Until systemd switches from the kernel details output keyboard and mice work but then they become unresponsive. Only replugging keyboard and mice after XDM appears helps -- working then again. The Lenovo keyboard and Lenovo mice are connected behind a HP Compaq LA1952g Monitor. While replugging the devices I get the following kernel messages: Jan 18 02:53:07 g6 kernel: [ 2661.078799] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.079668] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.082815] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.087041] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.087169] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.091058] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.091263] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.095391] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.095670] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.099677] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.099919] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.103940] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.104175] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.108428] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.112192] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.112438] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.116188] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.120193] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.120433] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.124434] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.124657] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.128700] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.128939] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.133193] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.135329] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.137200] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.139322] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.143300] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.143562] usb 3-1.4: clear tt 1 (0070) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.147828] usb 3-1.4: clear tt 2 (0080) error -71 Jan 18 02:53:07 g6 kernel: [ 2661.151716] hid-generic 0003:17EF:601D.0004: can't reset device, :00:1a.0-1.4.1/i nput0, status -71 Jan 18 02:53:07 g6 kernel: [ 2661.151834] hid-generic 0003:04B3:3025.0005: can't reset device, :00:1a.0-1.4.2/i nput0, status -71 : Thank you. With many greetings, Adrian Immanuel KIESS -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=5a7bc907-35b2-4039-8928-50d6afad3863 ro splash vga=795 splash vga=775 resume=/dev/sdb2 ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [ 2627.540839] tun: Universal TUN/TAP device driver, 1.6 [ 2627.5
Bug#775053: debbugs: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/debbugs/examples/config
Control: tags -1 +patch
On 2015-01-10, Andreas Beckmann wrote:
> a test with piuparts revealed that your package uses files from
> /usr/share/doc in its maintainer scripts which is a violation of
> Policy 12.3: "Packages must not require the existence of any files in
> /usr/share/doc/ in order to function."
...
> Setting up debbugs (2.4.1) ...
> cp: cannot stat '/usr/share/doc/debbugs/examples/config': No such file or
> directory
> No such file or directory at /usr/sbin/debbugsconfig line 75.
> dpkg: error processing package debbugs (--configure):
>subprocess installed post-installation script returned error exit status 2
> Errors were encountered while processing:
>debbugs
I think the following patch will fix the issue, although I haven't
tested with piuparts, or tested the built package works, but it does
successfully install.
On fresh installs, /usr/share/doc/debbugs/examples is a symlink to
/usr/share/debbugs/examples, but on upgrades, it doesn't handle the
examples directory transforming to a symlink and leaves an empty
directory in /usr/share/doc/debbugs/examples.
diff -Nru debbugs-2.4.1/debian/debbugsconfig
debbugs-2.4.1+nmu2/debian/debbugsconfig
--- debbugs-2.4.1/debian/debbugsconfig 2002-11-25 04:34:56.0 -0800
+++ debbugs-2.4.1+nmu2/debian/debbugsconfig 2015-01-17 17:33:41.0
-0800
@@ -72,7 +72,7 @@
sub template {
my ($name, $destdir) = @_;
if (! -f "$destdir/$name") {
- system("cp /usr/share/doc/debbugs/examples/$name $destdir/$name") == 0 ||
+ system("cp /usr/share/debbugs/examples/$name $destdir/$name") == 0 ||
die "$!";
print "created $destdir/$name from template.\n";
}
diff -Nru debbugs-2.4.1/debian/dirs debbugs-2.4.1+nmu2/debian/dirs
--- debbugs-2.4.1/debian/dirs 2002-11-17 09:09:40.0 -0800
+++ debbugs-2.4.1+nmu2/debian/dirs 2015-01-17 17:37:08.0 -0800
@@ -2,7 +2,7 @@
etc/debbugs/indices
usr/lib/debbugs
usr/sbin
-usr/share/doc/debbugs/examples
+usr/share/debbugs/examples
var/lib/debbugs/indices
var/lib/debbugs/www/cgi
var/lib/debbugs/www/db
diff -Nru debbugs-2.4.1/debian/rules debbugs-2.4.1+nmu2/debian/rules
--- debbugs-2.4.1/debian/rules 2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1+nmu2/debian/rules 2015-01-17 17:48:19.0 -0800
@@ -28,6 +28,7 @@
$(MAKE) install_mostfiles DESTDIR=$(tmp_dir)
dh_installdocs
dh_installchangelogs
+ dh_link usr/share/debbugs/examples usr/share/doc/debbugs/examples
dh_strip
dh_compress -X examples/text
dh_fixperms
diff -Nru debbugs-2.4.1/Makefile debbugs-2.4.1+nmu2/Makefile
--- debbugs-2.4.1/Makefile 2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1+nmu2/Makefile 2015-01-17 17:33:38.0 -0800
@@ -8,7 +8,7 @@
doc_dir:= $(DESTDIR)/usr/share/doc/debbugs
man_dir:= $(DESTDIR)/usr/share/man
man8_dir := $(man_dir)/man8
-examples_dir := $(doc_dir)/examples
+examples_dir := $(DESTDIR)/usr/share/debbugs/examples
scripts_in := $(filter-out scripts/config.in scripts/errorlib.in
scripts/text.in, $(wildcard scripts/*.in))
htmls_in := $(wildcard html/*.html.in)
That said, debbugs hasn't seen an upload to unstable since 2003, and the
upload in experimental was in 2010 (the patch should apply to git
without many changes)... maybe it shouldn't ship with Jessie?
live well,
vagrant
signature.asc
Description: PGP signature
Bug#775647: ed: Use upstream "red" script rather than symbolic link
Subject: ed: Use upstream "red" script rather than link Package: ed Version: 1.6-2 Severity: normal Dear Maintainer, With the upstream change from v1.4 to v1.5, ed(1) no longer recognizes "red" as a name under which restricted mode will be invoked. $ echo hello > example.txt $ # errant behavior $ red example.txt 6 e /etc/passwd 4210 !pwd /home/tim ! q $ # correct behavior that should also happen with "red" $ ed -r example.txt 6 e /etc/passwd ? !pwd ? q As a workaround, "ed -r" can be used instead. Prior to ed(1) v1.5, the symbolic link sufficed. However, since v1.5, it's now a shell-script that is provided as part of the build process. http://download.savannah.gnu.org/releases/ed/ If including v1.5 or later, the solution is to use the "red" shell-script from the upstream package build rather than using a symlink. -Tim -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ed depends on: ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u6 ed recommends no packages. ed suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766982: RFS: plowshare4/1.0.6-1
Dear mentors, In the time that this request has been sitting here there have been two new upstream versions released. Since this tool depends on many external (website) APIs which are constantly in flux, it needs to be updated relatively often to keep pace. Is it best if I package these one version at a time keeping each diff minimal for easier review? Or should I just jump directly to the latest version and abandon the present request? It seems that my previous sponsor is still away from this list, so in the meantime if anyone else would consider sponsoring my package I would be very grateful. Cheers, Carl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775646: SIGSEGV in ntfs_mft_record_alloc
Package: ntfs-3g
Version: 1:2014.2.15AR.3-1
Severity: important
Tags: upstream
I'm trying to rsync a directory from ext4 to ntfs but I get constantly crash
It happens also after windows chkdsk
here out/gdb info:
Reading symbols from ntfs-3g...Reading symbols from
/usr/lib/debug/.build-id/7e/eead72bf06909ac8adab4bbea346fc8cc4dc22.debug.
...done.
done.
(gdb) run -o no_detach /dev/sdb2 /mnt/ntfs/
Starting program: /bin/ntfs-3g -o no_detach /dev/sdb2 /mnt/ntfs/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Version 2014.2.15AR.3 integrated FUSE 28
Mounted /dev/sdb2 (Read-Write, label "BoySlim", NTFS 3.1)
Cmdline options: no_detach
Mount options:
allow_other,nonempty,relatime,fsname=/dev/sdb2,blkdev,blksize=4096
Ownership and permissions disabled, configuration type 7
ntfs_mst_post_read_fixup_warn: magic: 0xe1ba5cb3 size: 1024 usa_ofs: 34725
usa_count: 45939: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x65eb6da0 size: 1024 usa_ofs: 25253
usa_count: 14028: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0xd4758cc9 size: 1024 usa_ofs: 39555
usa_count: 19090: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x7f93ea5a size: 1024 usa_ofs: 13271
usa_count: 31837: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x867ec319 size: 1024 usa_ofs: 58829
usa_count: 33503: Invalid argument
Program received signal SIGSEGV, Segmentation fault.
ntfs_mft_record_alloc (vol=0x7f0e7c44f3c0, base_ni=0x3ec, base_ni@entry=0x0) at
mft.c:1757
1757mft.c: No such file or directory.
gdb) bt
#0 ntfs_mft_record_alloc (vol=0x7f0e7c44f3c0, base_ni=0x3ec,
base_ni@entry=0x0) at mft.c:1757
#1 0x7f0e7ba9e338 in __ntfs_create (dir_ni=0x7f0e7c4b32b0, securid=0,
name=0x7f0e7c4b34c0, name_len=83 'S',
type=32768, dev=0, target=0x0, target_len=0) at dir.c:1508
#2 0x7f0e7baa0742 in ntfs_create (dir_ni=0x7f0e7c44f3c0, securid=1004,
name=0x7f0e7c4b87f0, name_len=71 'G',
type=2081425152) at dir.c:1763
#3 0x7f0e7c119c69 in ntfs_fuse_create (org_path=,
typemode=33152, dev=, target=0x0,
fi=0x7fffaa4ccfc0) at ntfs-3g.c:1743
#4 0x7f0e7c11a275 in ntfs_fuse_mknod_common (org_path=,
mode=33152, dev=0, fi=0x7fffaa4ccfc0)
at ntfs-3g.c:1880
#5 0x7f0e7c121647 in fuse_lib_create (req=0x7f0e7c4b3140, parent=249,
name=0x7f0e7bf33048
"Doctor.Who.2005.1x12.Padroni.Dell.Universo.-.1^.Parte.iTaEnG.DVDMux-DarkSideMux.srt",
mode=33152,
fi=0x7fffaa4ccfc0) at fuse.c:1792
#6 0x7f0e7c1250ad in do_create (req=, nodeid=, inarg=)
at fuse_lowlevel.c:644
#7 0x7f0e7c12425a in fuse_session_loop (se=0x7f0e7c4589d0) at
fuse_loop.c:34
#8 0x7f0e7c11724c in main (argc=0, argv=0x7f0e7b7fc090) at ntfs-3g.c:3987
(gdb) p *(le16*)((u8*)m + m->usa_ofs)
Cannot access memory at address 0x7f0e7c4c6dbd
(gdb) p m
$6 = (MFT_RECORD *) 0x7f0e7c4b87f0
(gdb) p *m
$7 = {magic = 2256454425, usa_ofs = 58829, usa_count = 33504, lsn =
5559363449530884608, sequence_number = 11938,
link_count = 8277, attrs_offset = 41994, flags = 52348, bytes_in_use =
3528076468, bytes_allocated = 3503433910,
base_mft_record = 13344062644253006997, next_attr_instance = 54086, reserved
= 56111, mft_record_number = 1200265100}
source:
usn = *(le16*)((u8*)m + le16_to_cpu(m->usa_ofs));
There are additional info I can provide?
Regards
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
Versions of packages ntfs-3g depends on:
ii fuse 2.9.3-15+b1
ii libc6 2.19-13
ii libgcrypt201.6.2-4+b1
ii libgnutls-deb0-28 3.3.8-5
ii libgpg-error0 1.17-3
ii multiarch-support 2.19-13
ntfs-3g recommends no packages.
ntfs-3g suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775627: [Pkg-javascript-devel] Bug#775627: node-tap: FTBFS in jessie: Tests failures
Le dimanche 18 janvier 2015 à 01:42 +0100, Lucas Nussbaum a écrit : > 8< http://aws-logs.debian.net/ftbfs-logs/2015/01/17/node-tap_0.4.13-1_jessie.log I'd like to know the output of nodejs -e "console.log(process.platform)" on that build machine, to see if it is nodejs that sets a wrong process.platform or if it is this node-tap test that assumes something wrong about the linux platform. Thank you, Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775645: iceweasel: multiple breakages in FF after upgraded to 35, when taking the old prefs.js
Package: iceweasel
Version: 35.0-1
Severity: important
Hi.
Since I've upgraded to 35, I've experienced multiple issues.
- One of them is the breakage of search load options, which I've
already reported in #775391.
- Another was that the search bar didn't work anymore at all
(i.e. hitting enter and nothing happened at all).
This turned out to be a problem in tab mix plus, which was solved
by the version 0.4.1.6 already in experimental.
But several problems remained, which I first suspected to be tab
mix plus either:
- Undo closing tabs (Ctrl-Shift-t) no longer worked.
- session management (at least with the SM from TM+) didn't work
anymore, neither on restart after crash, nor on loading manually
saved sessions.
I've reported these upstream at:
http://tmp.garyr.net/forum/viewtopic.php?f=2&t=19018
I further found out that add block plus stopped working, which
meant:
- adds were shown
- I cannot longer open the preferences of the add on (nothing
happens when I click on the button).
- And everything from add on's page in the add on manager is
displayed broken,... it doesn't display the underscore on the
objects, but "&" before (see the screenshot for what I mean).
So I came to the suspicion it may not be TM+ and digged deeper:
With a fresh profile everything seems to work fine again,
but it would be really annoying having to start from scratch,
since I have so many settings in FF and all plugins.
Starting FF with an empty .mozilla gives:
$ iceweasel
(process:12321): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size
== 0' failed
1421544782793 addons.xpi WARNException running bootstrap method
startup on fire...@software.joehewitt.com: TypeError: scope.gcli.addCommand is
not a function (resource://firebug/gcli.js:126:4) JS Stack trace:
addcomm...@gcli.js:126:5 < registercomma...@gcli.js:132:1 <
firebuggclicommands.star...@gcli.js:45:9 <
startup@resource://gre/modules/addons/XPIProvider.jsm ->
file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/fire...@bootstrap.js:78:5
< xpi_callbootstrapmet...@xpiprovider.jsm:4436:9 <
xpi_star...@xpiprovider.jsm:2159:13 < callprovi...@addonmanager.jsm:208:12 <
_startprovi...@addonmanager.jsm:667:5 < ami_star...@addonmanager.jsm:821:9 <
amp_star...@addonmanager.jsm:2399:5 < amc_obse...@addonmanager.js:55:7
0 migrated.
console.error:
[CustomizableUI]
TypeError: window.caligon.status4evar is undefined --
resource://status4evar/Australis.jsm:166
=> everything seems to work again, even Search Load Options, which is why
I'll close that bug shortly after.
Starting FF with my profile (i.e. the one where I get all these
errors shows):
$ iceweasel
(process:10162): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size
== 0' failed
1421543699278 addons.xpi ERROR Failed to load bootstrap addon
searchloadoptions@esteban.torres from
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/searchloadoptions@esteban.torres:
[Exception... "Unexpected error in XPConnect" nsresult: "0x80570008
(NS_ERROR_XPC_UNEXPECTED)" location: "JS frame ::
resource://gre/modules/addons/XPIProvider.jsm :: XPI_loadBootstrapScope :: line
4307" data: no] Stack trace:
XPI_loadBootstrapScope()@resource://gre/modules/addons/XPIProvider.jsm:4307 <
XPI_callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4408 <
XPI_startup()@resource://gre/modules/addons/XPIProvider.jsm:2159 <
callProvider()@resource://gre/modules/AddonManager.jsm:208 <
_startProvider()@resource://gre/modules/AddonManager.jsm:667 <
AMI_startup()@resource://gre/modules/AddonManager.jsm:821 <
AMP_startup()@resource://gre/modules/AddonManager.jsm:2399 <
AMC_observe()@resource://gre/components/addonManager.js:55 <
1421543699280 addons.xpi ERROR Failed to load bootstrap addon
{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} from
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:
[Exception... "Unexpected error in XPConnect" nsresult: "0x80570008
(NS_ERROR_XPC_UNEXPECTED)" location: "JS frame ::
resource://gre/modules/addons/XPIProvider.jsm :: XPI_loadBootstrapScope :: line
4307" data: no] Stack trace:
XPI_loadBootstrapScope()@resource://gre/modules/addons/XPIProvider.jsm:4307 <
XPI_callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4408 <
XPI_startup()@resource://gre/modules/addons/XPIProvider.jsm:2159 <
callProvider()@resource://gre/modules/AddonManager.jsm:208 <
_startProvider()@resource://gre/modules/AddonManager.jsm:667 <
AMI_startup()@resource://gre/modules/AddonManager.jsm:821 <
AMP_startup()@resource://gre/modules/AddonManager.jsm:2399 <
AMC_observe()@resource://gre/components/addonManager.js:55 <
console.error:
[CustomizableUI]
Custom widget with id loop-button-throttled does not return a valid node
console.error:
[CustomizableUI]
Custom widget with id loop-button-throttled does not return a valid nod
Bug#775635: chiark-tcl: FTBFS in jessie: build-dependency not installable: tcl8.4-dev
Lucas Nussbaum writes ("Bug#775635: chiark-tcl: FTBFS in jessie:
build-dependency not installable: tcl8.4-dev"):
> Source: chiark-tcl
> Version: 1.1.2
> Severity: serious
> > The following packages have unmet dependencies:
> > sbuild-build-depends-chiark-tcl-dummy : Depends: tcl8.4-dev but it is not
> > installable
> > E: Unable to correct problems, you have held broken packages.
The actual build-depends line is this:
Build-Depends: libadns1-dev (>= 1.2), nettle-dev, libcdb-dev | tinycdb
(<= 0.75), tcl8.4-dev | tcl8.3-dev | tcl8.2-dev | tcl-dev, debhelper (>= 5)
(It's a shame that Tcl no longer provides a `tcl-dev' virtual package.)
Anyway, I'm a bit puzzled. I uploaded a new version of this package
in November 2014 and it built fine. tcl8.4-dev seemed to be available
then. I deliberately did not update it to build-depend on 8.5 because
I wanted to avoid perturbing what was in testing by potentially
introducing depedencies on 8.5-specific aspects of the Tcl ABI.
But according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737104
tcl8.4-dev was removed in January 2014. How did I and the buildds
manage to build chiark-tcl 1.1.2 using tcl8.4-dev in November ?
https://buildd.debian.org/status/logs.php?pkg=chiark-tcl
I guess, unless the explanation for this conundrum contains a reason
not to do so, that I will have to update it to build-depend on 8.5.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774867: [Pkg-lirc-maint] Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
Hi
On Saturday 17 January 2015, gregor herrmann wrote:
> Control: tags 774867 + patch
> Control: tags 774867 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
First of all, I acknowledge the NMU - thanks a lot, go ahead as you
wish, but...
[feel free to ignore the rest of this mail]
I don't object to the patch, but it doesn't really help with this bug.
The bug itself only happens when dist-upgrading from squeeze to wheezy,
neither wheezy, jessie or wheezy-->jessie upgrades are affected at all,
so fixing this bug in jessie doesn't help any squeeze user who's just
now starting to look at dist-upgrading to wheezy at all. Actually it's
even worse, symlink_to_dir was only added to dpkg's maintscript
collection in dpkg 1.17.14, while squeeze is at 1.15.11 (admitted,
Pre-Depends: ${misc:Pre-Depends} should handle that aspect).
Therefore I'm curious, what is your plan with this bugfix?
Asking the release team for a jessie unblock doesn't really meet the
unblock criteria anymore, as the bug doesn't affect jessie nor wheezy
to jessie dist-upgrades (actually, had this bug been reported and fixed
in time before the wheezy release, I would have already removed this
kind of pre-wheezy upgrade support from the packages intended for
jessie).
Asking the stable-release managers to accept a wheezy-proposed-updates
upload for an equivalent fix targetting the next wheezy point release
would be justified - and I certainly would have done so up to 'a year
ago', but now that squeeze is EOL for over half a year already, it
feels a bit late (still correct, but as no actual user ever complained,
'why bother' (and get the stable-release managers busy for basically an
obsolete problem) at this point in time)?
So considerding that this change is neither needed for jessie+1
(stretch), nor fullfills the unblock criterias for jessie (and isn't
actually needed there either), the (correct) upload can only migrate
to testing (==stretch) after jessie has been released - when and where
it is even less needed than in jessie itself.
Accordingly, my plan was waiting until this weekend for a potential
response from the reporter, but pending that, to close the bug for
lirc 0.9.0~pre1-1.1 (the package version in jessie, technically not
100% correct, but it conveys the message correctly; asking the release
team for a jessie-ignore would basically do the same job) and tagging
it wheezy and wontfix. But as I mentioned, your change is the correct
solution, it's imho just way too late to fix at this point in time,
when the fix won't ever propagate to the only ones (current squeeze
users who are planning to dist-upgrade to wheezy) anymore. Making it
just academic busy-work for everyone involved.
To be clear, I very much appreciate your effort - thanks a lot - and
I'm fine with getting this uploaded to unstable, but I personally don't
see a need to bother the release team with an unblock request
(certainly not for jessie, nor -at this point in time- for wheezy
anymore) at this point in the freeze.
...and the next regular /post-jessie/ lirc upload will just remove all
pre-jessie upgrade support (including this change[1]) from the package
anyways...
This piuparts mass bug filing imho would have better concentrated on
just wheezy to jessie issues, rather than murkying the waters by
including squeeze-->wheezy issues as well, that ship has sailed long
time ago.
Regards
Stefan Lippers-Hollmann
[1] there would be reason to make an exception for this particular
change to go through one stable release, just to get it fixed
once and for all for everyone, but that's mostly academic here.
signature.asc
Description: This is a digitally signed message part.
Bug#775615: Upstream bug
This looks like the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=54226 pgpeLoROPienY.pgp Description: OpenPGP digital signature
Bug#774867: Fwd: Re: [Pkg-lirc-maint] Bug#774867: lirc-x: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
[ Just as reference, as this previous mail doesn't appear to have
reached bugs.d.o either ('thanks' to changes in my provider's
smarthost configuration) ]
-- Forwarded Message --
Subject: Re: [Pkg-lirc-maint] Bug#774867: lirc-x: unhandled symlink to
directory conversion: /usr/share/doc/PACKAGE
Date: Friday 09 January 2015
From: "Stefan Lippers-Hollmann"
To: 774...@bugs.debian.org
Hi
On Thursday 08 January 2015, Andreas Beckmann wrote:
> Package: lirc-x
> Version: 0.9.0~pre1-1.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
[...]
> This was observed on the following upgrade paths:
>
> squeeze -> wheezy -> jessie
This affects only the <=squeeze --> wheezy upgrade path. Considering
that upgrades skipping a stable release aren't formally supported and
generally don't work, it does not affect >=jessie anymore, even though
both wheezy and jessie share the same version of lirc.
With squeeze being EOL for over half a year by now (disregarding the
more server centric, rather inofficial LTS efforts) and lirc being a
predominantly desktop/ multimedia centric package, with no actual user
report about this particular issue so far, I'd tend not to touch this
problem for wheezy anymore - and jessie isn't affected either way.
> 2m28.1s ERROR: FAIL: silently overwrites files via directory symlinks:
> /usr/share/doc/lirc-x/NEWS.Debian.gz (lirc-x) !=
> /usr/share/doc/lirc/NEWS.Debian.gz (lirc)
> /usr/share/doc/lirc-x -> lirc
> /usr/share/doc/lirc-x/changelog.Debian.gz (lirc-x) !=
> /usr/share/doc/lirc/changelog.Debian.gz (lirc)
> /usr/share/doc/lirc-x -> lirc
> /usr/share/doc/lirc-x/copyright (lirc-x) != /usr/share/doc/lirc/copyright
> (lirc)
> /usr/share/doc/lirc-x -> lirc
While the bug itself is definately serious/ RC for wheezy, I'd tend to
consider this problem wontfix for wheezy at this stage[1] and not-a-bug
for jessie - can you agree with this evaluation?
Regards
Stefan Lippers-Hollmann
[1] it does affect dist-upgrades from squeeze to wheezy
it does not affect fresh installations of wheezy
it does not affect dist-upgrades from wheezy to jessie
it does not affect fresh installations of jessie
it won't affect dist-upgrading from jessie upwards to stretch+
as such, I don't think a bugfix for this would meet the unblock
criteria for jessie at this point of the freeze, but with wheezy
and jessie sharing the same version of lirc, any change for wheezy
would also require an update for jessie.
---
signature.asc
Description: This is a digitally signed message part.
Bug#775643: pymvpa: FTBFS in jessie: tests failed
Source: pymvpa Version: 0.4.8-3 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150118 qa-ftbfs Justification: FTBFS in jessie on i386 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on i386. Relevant part (hopefully): > fakeroot debian/rules binary > pyversions: missing X(S)-Python-Version in control file, fall back to > debian/pyversions > test -x debian/rules > dh_testroot > dh_clean -k > dh_clean: dh_clean -k is deprecated; use dh_prep instead > dh_installdirs -A > mkdir -p "." > /usr/share/cdbs/1/rules/buildcore.mk:110: CDBS WARNING: > DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85 > /usr/share/cdbs/1/rules/buildcore.mk:110: CDBS WARNING: > DEB_PYTHON_BUILD_ARGS is deprecated since 0.4.89 > mkdir -p debian/python-module-stampdir > cd . && \ > python setup.py build \ > --build-base="/«PKGBUILDDIR»/./build" --with-libsvm > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands --compiler > options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands --fcompiler > options > running build_src > build_src > building extension "mvpa.clfs.libsmlrc.smlrc" sources > building extension "mvpa.clfs.libsvmc._svmc" sources > building data_files sources > build_src: building npy-pkg config files > running build_py > copying mvpa/clfs/libsvmc/svmc.py -> > /«PKGBUILDDIR»/./build/lib.linux-i686-2.7/mvpa/clfs/libsvmc > package init file 'mvpa/tests/badexternals/__init__.py' not found (or not a > regular file) > package init file 'mvpa/tests/badexternals/__init__.py' not found (or not a > regular file) > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > running build_scripts > touch debian/python-module-stampdir/python-mvpa > Adding cdbs dependencies to debian/python-mvpa.substvars > dh_installdirs -ppython-mvpa > cd . && \ > python setup.py install \ > --root="/«PKGBUILDDIR»/debian/python-mvpa" \ > --install-purelib=/usr/lib/python2.7/site-packages/ \ > --prefix=/usr --no-compile -O0 --with-libsvm > running install > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands --compiler > options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands --fcompiler > options > running build_src > build_src > building extension "mvpa.clfs.libsmlrc.smlrc" sources > building extension "mvpa.clfs.libsvmc._svmc" sources > building data_files sources > build_src: building npy-pkg config files > running build_py > package init file 'mvpa/tests/badexternals/__init__.py' not found (or not a > regular file) > package init file 'mvpa/tests/badexternals/__init__.py' not found (or not a > regular file) > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > running build_scripts > running install_lib > creating /«PKGBUILDDIR»/debian/python-mvpa/usr > creating /«PKGBUILDDIR»/debian/python-mvpa/usr/lib > creating /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7 > creating /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages > creating > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa > creating > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests > creating > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/cPickle_disabled.py > -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/ctypes.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/griddata.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/gzip.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/hcluster.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/libsvm.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/mdp.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexternals > copying build/lib.linux-i686-2.7/mvpa/tests/badexternals/nifti.py -> > /«PKGBUILDDIR»/debian/python-mvpa/usr/lib/python2.7/site-packages/mvpa/tests/badexter
Bug#775641: pocl: FTBFS in jessie: dh_makeshlibs: failing due to earlier errors
Source: pocl
Version: 0.10-10
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150118 qa-ftbfs
Justification: FTBFS in jessie on i386
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on i386.
Relevant part (hopefully):
> make[1]: Entering directory '/«PKGBUILDDIR»'
> dh_makeshlibs
> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see
> diff output below
> dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols
> file: see diff output below
> dpkg-gensymbols: warning: debian/libpocl1/DEBIAN/symbols doesn't match
> completely debian/libpocl1.symbols
> --- debian/libpocl1.symbols (libpocl1_0.10-10_i386)
> +++ dpkg-gensymbolszGLZnH 2015-01-17 22:54:35.701642771 +
> @@ -21,6 +21,7 @@
>
> (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeEjEES1_RKT_RKT0_@Base
> 0.10
>
> (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeEjjEES1_RKT_RKT0_RKT1_@Base
> 0.10
>
> (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeElEES1_RKT_RKT0_@Base
> 0.10
> + _ZN4llvm12hash_combineIllEENS_9hash_codeERKT_RKT0_@Base 0.10-10
>
> (optional=templinst|subst|arch=kfreebsd-i386)_ZN4llvm12hash_combineI{int64_t}lEENS_9hash_codeERKT_RKT0_@Base
> 0.10
>
> (optional=templinst)_ZN4llvm15SmallVectorImplIN5clang14TypoCorrectionEEaSEOS3_@Base
> 0.10
>
> (optional=templinst)_ZN4llvm15SmallVectorImplIN5clang15CharSourceRangeEEaSERKS3_@Base
> 0.10
> @@ -592,10 +593,12 @@
> _ZN5clang11FileManager12addStatCacheEPNS_19FileSystemStatCacheEb@Base 0.10
> _ZN5clang11FileManager12getDirectoryEN4llvm9StringRefEb@Base 0.10
>
> _ZN5clang11FileManager12getStatValueEPKcRNS_8FileDataEbPSt10unique_ptrINS_3vfs4FileESt14default_deleteIS7_EE@Base
> 0.10
> + _ZN5clang11FileManager14getVirtualFileEN4llvm9StringRefEll@Base 0.10-10
>
> (subst|arch=kfreebsd-i386)_ZN5clang11FileManager14getVirtualFileEN4llvm9StringRefE{int64_t}l@Base
> 0.10
> _ZN5clang11FileManager15clearStatCachesEv@Base 0.10
> _ZN5clang11FileManager15invalidateCacheEPKNS_9FileEntryE@Base 0.10
> -
> (subst)_ZN5clang11FileManager15modifyFileEntryEPNS_9FileEntryE{int64_t}l@Base
> 0.10
> + _ZN5clang11FileManager15modifyFileEntryEPNS_9FileEntryEll@Base 0.10-10
> +#MISSING: 0.10-10#
> (subst)_ZN5clang11FileManager15modifyFileEntryEPNS_9FileEntryE{int64_t}l@Base
> 0.10
> _ZN5clang11FileManager15removeStatCacheEPNS_19FileSystemStatCacheE@Base 0.10
> _ZN5clang11FileManager16getBufferForFileEN4llvm9StringRefEPSs@Base 0.10
> _ZN5clang11FileManager16getBufferForFileEPKNS_9FileEntryEPSsbb@Base 0.10
> @@ -1576,6 +1579,7 @@
>
> _ZN5clang13serialization13ModuleManager13removeModulesEPPNS0_10ModuleFileES4_RN4llvm15SmallPtrSetImplIS3_EEPNS_9ModuleMapE@Base
> 0.10
>
> _ZN5clang13serialization13ModuleManager14setGlobalIndexEPNS_17GlobalModuleIndexE@Base
> 0.10
>
> _ZN5clang13serialization13ModuleManager15visitDepthFirstEPFbRNS0_10ModuleFileEbPvES4_@Base
> 0.10
> +
> _ZN5clang13serialization13ModuleManager16lookupModuleFileEN4llvm9StringRefEllRPKNS_9FileEntryE@Base
> 0.10-10
>
> (subst|arch=kfreebsd-i386)_ZN5clang13serialization13ModuleManager16lookupModuleFileEN4llvm9StringRefE{int64_t}lRPKNS_9FileEntryE@Base
> 0.10
>
> _ZN5clang13serialization13ModuleManager16returnVisitStateEPNS1_10VisitStateE@Base
> 0.10
>
> _ZN5clang13serialization13ModuleManager17addInMemoryBufferEN4llvm9StringRefEPNS2_12MemoryBufferE@Base
> 0.10
> @@ -1584,6 +1588,7 @@
>
> _ZN5clang13serialization13ModuleManager5visitEPFbRNS0_10ModuleFileEPvES4_PN4llvm11SmallPtrSetIPS2_Lj4EEE@Base
> 0.10
> _ZN5clang13serialization13ModuleManager6lookupEN4llvm9StringRefE@Base 0.10
> _ZN5clang13serialization13ModuleManager6lookupEPKNS_9FileEntryE@Base 0.10
> +
> _ZN5clang13serialization13ModuleManager9addModuleEN4llvm9StringRefENS0_10ModuleKindENS_14SourceLocationEPNS0_10ModuleFileEjllRS7_RSs@Base
> 0.10-10
>
> (subst|arch=kfreebsd-i386)_ZN5clang13serialization13ModuleManager9addModuleEN4llvm9StringRefENS0_10ModuleKindENS_14SourceLocationEPNS0_10ModuleFileEj{int64_t}lRS7_RSs@Base
> 0.10
> _ZN5clang13serialization13ModuleManagerC1ERNS_11FileManagerE@Base 0.10
> _ZN5clang13serialization13ModuleManagerC2ERNS_11FileManagerE@Base 0.10
> @@ -5178,7 +5183,8 @@
> _ZN5clang7ASTUnit16ConcurrencyStateC2Ev@Base 0.10
> _ZN5clang7ASTUnit16ConcurrencyStateD1Ev@Base 0.10
> _ZN5clang7ASTUnit16ConcurrencyStateD2Ev@Base 0.10
> - (subst)_ZN5clang7ASTUnit16PreambleFileHash13createForFileE{int64_t}l@Base
> 0.10
> + _ZN5clang7ASTUnit16PreambleFileHash13createForFileEll@Base 0.10-10
> +#MISSING: 0.10-10#
> (subst)_ZN5clang7ASTUnit16PreambleFileHash13createForFileE{int64_t}l@Base 0.10
>
> _ZN5clang7ASTUnit16PreambleFileHash21createForMemoryBufferEPKN4llvm12MemoryBufferE@Base
> 0.10
> _ZN5clang7ASTUnit16addFileLevelDeclEPNS_4DeclE@Base 0.10
> _ZN5clang7ASTUnit16addTemporaryFileEN4llvm9StringRefE@Base 0.10
>
Bug#775642: stressapptest: FTBFS in jessie: configure: error: i586 is not supported! Try x86_64, i686, powerpc, or armv7a
Source: stressapptest Version: 1.0.6-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150118 qa-ftbfs Justification: FTBFS in jessie on i386 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on i386. Relevant part (hopefully): > configure: WARNING: unrecognized options: --disable-maintainer-mode > configure: Compiling with dynamically linked libraries. > checking build system type... i586-pc-linux-gnu > checking host system type... i586-pc-linux-gnu > checking target system type... i586-pc-linux-gnu > configure: error: i586 is not supported! Try x86_64, i686, powerpc, or armv7a The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/18/stressapptest_1.0.6-1_jessie-i386.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775644: check-postgres: FTBFS in jessie: Tests failures
Source: check-postgres Version: 2.21.0-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150118 qa-ftbfs Justification: FTBFS in jessie on i386 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on i386. Relevant part (hopefully): > t/02_wal_files.t ... ok > t/03_translations.t skipped: Test skipped unless environment > variable RELEASE_TESTING is set > t/04_timeout.t . ok > t/05_docs.t ok > t/99_cleanup.t . ok > > Test Summary Report > --- > t/02_replicate_row.t (Wstat: 256 Tests: 19 Failed: 1) > Failed test: 18 > Non-zero exit status: 1 > Files=50, Tests=872, 190 wallclock secs ( 0.24 usr 0.20 sys + 73.94 cusr > 44.04 csys = 118.42 CPU) > Result: FAIL > Failed 1/50 test programs. 1/872 subtests failed. > make[2]: *** [test_dynamic] Error 255 > Makefile:784: recipe for target 'test_dynamic' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/18/check-postgres_2.21.0-2_jessie-i386.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775638: gdnsd: FTBFS in jessie: dh_auto_test: make -j1 test returned exit code 2
Source: gdnsd Version: 2.1.0-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > make[6]: Entering directory '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t' > ASDIR="/«PKGBUILDDIR»/plugins/meta/libgdmaps/t" > ABDIR="/«PKGBUILDDIR»/plugins/meta/libgdmaps/t" GEOLITE_FILES="LICENSE.txt > GeoIP-20111210.dat GeoIPv6-20111210.dat GeoLiteCity-20111210.dat > GeoLiteCityv6-20111210.dat regioncodes-20130115.csv" TLIST="t00_v4db t01_v6db > t02_v4citydb t03_v6citydb t04_v64db t05_v64citydb t06_v4nets t07_v6nets > t08_cityauto t09_complex t10_def t11_def2 t12_defnone t13_castatdef > t14_missingcoords t15_nogeo t99_loadonly t16_extnets t17_extn_empty > t18_extn_all t19_extn_allg t20_extn_allgs t21_extn_subs t22_nets_corner > t23_gn_corner" ./trunner.sh > Skipping GeoIP-based libgdmaps unit tests; missing GeoLite data. > If you care to run these, execute 'make check-download' before > 'make check' (This will download several megabytes of data from > the public Internet!) > If you wish to test basic loading success for arbitrary local > GeoIP databases with plugin_geoip, please specify a list of > absolute pathnames in $GDMAPS_GEOIP_TEST_LOAD > By default, tests will be run against all of the following that > exist and are readable in /usr/share/GeoIP/: > GeoIP.dat GeoIPv6.dat GeoIPCity.dat GeoIPCityv6.dat GeoLiteCity.dat > GeoLiteCityv6.dat > Running test t15_nogeo ... > Running test t17_extn_empty ... > Running test t18_extn_all ... > Running test t21_extn_subs ... > Running test t22_nets_corner ... > Checking basic database load on file /usr/share/GeoIP/GeoIP.dat ... OK > Checking basic database load on file /usr/share/GeoIP/GeoIPv6.dat ... > Load-only test on file '/usr/share/GeoIP/GeoIPv6.dat' failed w/ exit status > 134; Test Output: > info: Loading configuration from > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/config' > info: plugin_geoip: map 'my_prod_map': Processing GeoIP database > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' > error: plugin_geoip: map 'my_prod_map': Error traversing GeoIP database, > corrupt? > error: plugin_geoip: map 'my_prod_map': (Re-)loading geoip database > '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' > failed! > fatal: plugin_geoip: map 'my_prod_map': cannot continue initial load > Aborted > make[6]: *** [check-local] Error 99 > Makefile:1029: recipe for target 'check-local' failed > make[6]: Leaving directory '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t' > make[5]: *** [check-am] Error 2 > Makefile:899: recipe for target 'check-am' failed > make[5]: Leaving directory '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t' > make[4]: *** [check-recursive] Error 1 > Makefile:494: recipe for target 'check-recursive' failed > make[4]: Leaving directory '/«PKGBUILDDIR»/plugins/meta/libgdmaps' > make[3]: *** [check-recursive] Error 1 > Makefile:536: recipe for target 'check-recursive' failed > make[3]: Leaving directory '/«PKGBUILDDIR»/plugins/meta' > make[2]: *** [check-recursive] Error 1 > Makefile:392: recipe for target 'check-recursive' failed > make[2]: Leaving directory '/«PKGBUILDDIR»/plugins' > make[1]: *** [check-recursive] Error 1 > Makefile:501: recipe for target 'check-recursive' failed > make[1]: Leaving directory '/«PKGBUILDDIR»' > dh_auto_test: make -j1 test returned exit code 2 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/gdnsd_2.1.0-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775637: openstack-trove: FTBFS in jessie: Tests failures
Source: openstack-trove Version: 2014.1.3-4 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > _StringException: returncode 1 > > > == > FAIL: process-returncode > process-returncode > -- > _StringException: returncode 1 > > > -- > Ran 635 tests in 5.725s > > FAILED (failures=148, skipped=1) > make[1]: *** [override_dh_auto_test] Error 1 > debian/rules:57: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/openstack-trove_2014.1.3-4_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775640: libarchive-zip-perl: FTBFS in jessie: Tests failures
Source: libarchive-zip-perl Version: 1.39-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > # expected: '0' > # Looks like you failed 1 test of 4. > t/17_bug_73797.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests > > Test Summary Report > --- > t/17_bug_73797.t(Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=17, Tests=250, 3 wallclock secs ( 0.07 usr 0.09 sys + 2.04 cusr > 0.75 csys = 2.95 CPU) > Result: FAIL > Failed 1/17 test programs. 1/250 subtests failed. > make[2]: *** [test_dynamic] Error 1 > Makefile:910: recipe for target 'test_dynamic' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/libarchive-zip-perl_1.39-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775636: horizon: FTBFS in jessie: Tests failures
Source: horizon Version: 2014.1.3-6 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > msg_prefix + "Couldn't find %s in response" % text_repr) > AssertionError: Couldn't find 'Europe/Moscow (UTC +04:00)' in response > u"Couldn't find 'Europe/Moscow (UTC +04:00)' in response" = > self._formatMessage(u"Couldn't find 'Europe/Moscow (UTC +04:00)' in > response", "%s is not true" % safe_repr(False)) > >> raise self.failureException(u"Couldn't find 'Europe/Moscow (UTC +04:00)' > >> in response") > > > -- > Ran 880 tests in 41.828s > > FAILED (SKIP=7, failures=1) > nosetests openstack_dashboard --nocapture --nologcapture > --cover-package=openstack_dashboard --cover-inclusive --all-modules > --exclude-dir=openstack_dashboard/test/integration_tests --verbosity=1 > Creating test database for alias 'default'... > Destroying test database for alias 'default'... > Tests failed. > make[1]: *** [override_dh_auto_test] Error 1 > debian/rules:50: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/horizon_2014.1.3-6_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775591: [src:linux] AUFS missing from 3.18.0 kernel => Docker 10x slower
Hi On Saturday 17 January 2015, Török Edwin wrote: [...] DISCLAIMER: I can't speak for the Debian kernel maintainers. [ Keep in mind that kernel >= 3.18 is not targetting jessie, but will only enter unstable/ testing (==stretch) after jessie has been released. ] > Using linux-image-3.18.0-trunk-amd64 I noticed that AUFS is missing from > /proc/filesystems. > This causes Docker to slow down even 10x in some situations: > https://github.com/docker/docker/issues/10161 > Please consider enabling AUFS again. You cannot just 'enable' AUFS, aufs3 is a rather invasive out-of-tree patch set, which requires a significant maintenance overhead. Kernel 3.18 has just gained support for overlayfs (aka overlay/ ovl) upstream/ in mainline, which is mostly equivalent to AUFS in most aspects. At this point, overlayfs has slightly less features than aufs3, but they're sufficient for live CD usages and most likely for docker as well - and there are extensive improvements in the queue for kernel >=3.20, it's likely to expect that the docker userland intended for >= stretch will therefore provide support for overlayfs (in addition or even instead of AUFS), alleviating this temporary problem. The removal of aufs from kernel >= 3.18 has been an intentional change by the Debian kernel maintainters and has been announced in [1] and more or less already been pre-announced in [2]. For a live-CD context, switching support from AUFS to overlayfs basically involved a 2-line change (loading overlay.ko instead of aufs.ko and mounting it with only slightly different mount options compared to aufs3), I assume the situation will be equally easy for docker as well. Therefore I'd suggest to close this bug as wontfix. Regards Stefan Lippers-Hollmann [1] https://lists.debian.org/<1418154910.3599.44.ca...@decadent.org.uk> 2014 [2] https://lists.debian.org/<1310334299.8783.13.camel@localhost> 2011 signature.asc Description: This is a digitally signed message part.
Bug#775639: neon27: FTBFS in jessie: tests failed
Source: neon27 Version: 0.30.1-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory > '/«PKGBUILDDIR»/debian/build-tree/neon-openssl/test' > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/uri-tests.c -o > uri-tests.lo > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/common/tests.c -o > common/tests.lo > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/common/child.c -o > common/child.lo > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/utils.c -o > utils.lo > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/util-socks.c -o > util-socks.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o libtest.la > common/tests.lo common/child.lo utils.lo util-socks.lo ../src/libneon.la > /bin/bash ../libtool --silent --mode=link gcc -no-install -o uri-tests > uri-tests.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/util-tests.c -o > util-tests.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o util-tests > util-tests.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/string-tests.c -o > string-tests.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o string-tests > string-tests.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/socket.c -o > socket.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o socket > socket.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/session.c -o > session.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o session > session.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/request.c -o > request.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o request > request.lo libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/auth.c -o auth.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o auth auth.lo > libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/basic.c -o > basic.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o basic basic.lo > libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/stubs.c -o > stubs.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o stubs stubs.lo > libtest.la > /bin/bash ../libtool --silent --mode=compile gcc -isystem > /usr/include/mit-krb5 -I/usr/include/libxml2 -I.. -I. -I/«PKGBUILDDIR»/src > -I/«PKGBUILDDIR»/test/common -O2 -g -c /«PKGBUILDDIR»/test/redirect.c -o > redirect.lo > /bin/bash ../libtool --silent --mode=link gcc -no-install -o redirect > redi
Bug#775634: php-mdb2: FTBFS in jessie: exception 'InvalidArgumentException' with message 'Unknown PEAR dependency level: 'group'' in /usr/share/php/pkgtools/phppear/source.php:205
Source: php-mdb2
Version: 2.5.0b5-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> fakeroot debian/rules binary
> dh binary --buildsystem=phppear --with phppear
>dh_testroot -O--buildsystem=phppear
>dh_prep -O--buildsystem=phppear
>dh_auto_install -O--buildsystem=phppear
> warning: pear/MDB2 requires package "pear/PEAR" (version >= 1.3.6)
> install ok: channel://pear.php.net/MDB2-2.5.0b5
> MDB2: Optional feature fbsql available (Frontbase SQL driver for MDB2)
> MDB2: Optional feature ibase available (Interbase/Firebird driver for MDB2)
> MDB2: Optional feature mssql available (MS SQL Server driver for MDB2)
> MDB2: Optional feature mysql available (MySQL driver for MDB2)
> MDB2: Optional feature mysqli available (MySQLi driver for MDB2)
> MDB2: Optional feature oci8 available (Oracle driver for MDB2)
> MDB2: Optional feature odbc available (ODBC driver for MDB2)
> MDB2: Optional feature pgsql available (PostgreSQL driver for MDB2)
> MDB2: Optional feature querysim available (Querysim driver for MDB2)
> MDB2: Optional feature sqlite available (SQLite2 driver for MDB2)
> MDB2: Optional feature sqlsrv available (MS SQL Server driver for MDB2)
> MDB2: To install optional features use "pear install pear/MDB2#featurename"
>dh_installdocs -O--buildsystem=phppear
>dh_installchangelogs -O--buildsystem=phppear
>dh_perl -O--buildsystem=phppear
>dh_phppear -O--buildsystem=phppear
> exception 'InvalidArgumentException' with message 'Unknown PEAR dependency
> level: 'group'' in /usr/share/php/pkgtools/phppear/source.php:205
> Stack trace:
> #0 /usr/share/php/pkgtools/phppear/command.php(98):
> Pkgtools\Phppear\Source->getDependencies()
> #1 [internal function]: Pkgtools\Phppear\Command->runSubstvars()
> #2 /usr/share/php/pkgtools/base/command.php(181): call_user_func_array(Array,
> Array)
> #3 /usr/share/php/pkgtools/base/command.php(169):
> Pkgtools\Base\Command->parseArgs(Array)
> #4 /usr/bin/pkgtools(32): Pkgtools\Base\Command->parseArgs()
> #5 {main}
> dh_phppear: /usr/bin/pkgtools -v --sourcedirectory . phppear substvars
> returned exit code 1
> make: *** [binary] Error 29
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/php-mdb2_2.5.0b5-1_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775629: pry: FTBFS in jessie: ERROR: Test "ruby2.1" failed: Bacon::Error: /\* $/.===("[1] pry(main)* ") failed
Source: pry
Version: 0.10.1-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> Bacon::Error: /\* $/.===("[1] pry(main)* ") failed
> /«PKGBUILDDIR»/spec/spec_helpers/repl_tester.rb:75:in `prompt':
> eval_string and binding_stack - should immediately evaluate eval_string after
> cmd if complete
> /«PKGBUILDDIR»/spec/pry_repl_spec.rb:93:in `block (4 levels) in (required)>'
> /«PKGBUILDDIR»/spec/spec_helpers/repl_tester.rb:36:in `instance_eval'
> /«PKGBUILDDIR»/spec/spec_helpers/repl_tester.rb:36:in `block in start'
> /«PKGBUILDDIR»/spec/spec_helpers/mock_pry.rb:24:in `redirect_pry_io'
> /«PKGBUILDDIR»/spec/spec_helpers/repl_tester.rb:34:in `start'
> /«PKGBUILDDIR»/spec/pry_repl_spec.rb:90:in `block (3 levels) in (required)>'
> /«PKGBUILDDIR»/spec/pry_repl_spec.rb:81:in `block (2 levels) in (required)>'
> /«PKGBUILDDIR»/spec/pry_repl_spec.rb:30:in `block in '
> /«PKGBUILDDIR»/spec/pry_repl_spec.rb:3:in `'
>
> 1110 tests, 1628 assertions, 1 failures, 0 errors
> debian/ruby-tests.rb:1:in `': unhandled exception
> ERROR: Test "ruby2.1" failed:
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/pry_0.10.1-1_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775628: libdate-calc-perl: FTBFS in jessie: Tests failures
Source: libdate-calc-perl Version: 6.3-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > t/m012.t .. ok > t/m013.t .. ok > > Test Summary Report > --- > t/f016.t (Wstat: 0 Tests: 25 Failed: 16) > Failed tests: 1-4, 6-7, 9-12, 15-17, 21-23 > t/f027.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30-35, 44-45 > t/f028.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30, 32, 34-37, 44-45 > Files=51, Tests=3381, 3 wallclock secs ( 0.31 usr 0.26 sys + 2.33 cusr > 0.63 csys = 3.53 CPU) > Result: FAIL > Failed 3/51 test programs. 60/3381 subtests failed. > make[1]: *** [test_dynamic] Error 255 > Makefile:867: recipe for target 'test_dynamic' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/libdate-calc-perl_6.3-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775633: php-crypt-gpg: FTBFS in jessie: exception 'InvalidArgumentException' with message 'Unknown PEAR dependency type 'os'' in /usr/share/php/pkgtools/phppear/source.php:225
Source: php-crypt-gpg
Version: 1.3.2-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> fakeroot debian/rules binary
> dh binary --buildsystem=phppear --with phppear
>dh_testroot -O--buildsystem=phppear
>dh_prep -O--buildsystem=phppear
>dh_auto_install -O--buildsystem=phppear
> install ok: channel://pear.php.net/Crypt_GPG-1.3.2
>dh_installdocs -O--buildsystem=phppear
>dh_installchangelogs -O--buildsystem=phppear
>dh_perl -O--buildsystem=phppear
>dh_phppear -O--buildsystem=phppear
> exception 'InvalidArgumentException' with message 'Unknown PEAR dependency
> type 'os'' in /usr/share/php/pkgtools/phppear/source.php:225
> Stack trace:
> #0 /usr/share/php/pkgtools/phppear/command.php(98):
> Pkgtools\Phppear\Source->getDependencies()
> #1 [internal function]: Pkgtools\Phppear\Command->runSubstvars()
> #2 /usr/share/php/pkgtools/base/command.php(181): call_user_func_array(Array,
> Array)
> #3 /usr/share/php/pkgtools/base/command.php(169):
> Pkgtools\Base\Command->parseArgs(Array)
> #4 /usr/bin/pkgtools(32): Pkgtools\Base\Command->parseArgs()
> #5 {main}
> dh_phppear: /usr/bin/pkgtools -v --sourcedirectory . phppear substvars
> returned exit code 1
> make: *** [binary] Error 29
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/php-crypt-gpg_1.3.2-1_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775632: libdate-pcalc-perl: FTBFS in jessie: Tests failures
Source: libdate-pcalc-perl Version: 6.1-3 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > t/m012.t .. ok > t/m013.t .. ok > > Test Summary Report > --- > t/f016.t (Wstat: 0 Tests: 25 Failed: 16) > Failed tests: 1-4, 6-7, 9-12, 15-17, 21-23 > t/f027.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30-35, 44-45 > t/f028.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30, 32, 34-37, 44-45 > Files=51, Tests=3378, 2 wallclock secs ( 0.24 usr 0.24 sys + 1.00 cusr > 0.26 csys = 1.74 CPU) > Result: FAIL > Failed 3/51 test programs. 60/3378 subtests failed. > make[1]: *** [test_dynamic] Error 255 > Makefile:1026: recipe for target 'test_dynamic' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/libdate-pcalc-perl_6.1-3_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775631: ruby-pygments.rb: FTBFS in jessie: ERROR: Test "ruby2.1" failed: Running tests for ruby2.1 using debian/ruby-tests.rb...
Source: ruby-pygments.rb Version: 0.5.4~ds1-1.1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > Running tests for ruby2.1 using debian/ruby-tests.rb... > Run options: > > # Running tests: > > F... > > Finished tests in 9.125198s, 5.2602 tests/s, 10.7395 assertions/s. > > 1) Failure: > PygmentsHighlightTest#test_highlight_works_with_larger_files > [/«PKGBUILDDIR»/test/test_pygments.rb:35]: > <455203> expected but was > <451844>. > > 48 tests, 98 assertions, 1 failures, 0 errors, 0 skips > > ruby -v: ruby 2.1.5p273 (2014-11-13) [x86_64-linux-gnu] > rake aborted! > Command failed with status (1): [ruby -I"lib" -rubygems > -I"/usr/lib/ruby/vendor_ruby" > "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_pygments.rb" ] > > Tasks: TOP => default => test > (See full trace by running task with --trace) > ERROR: Test "ruby2.1" failed: The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/ruby-pygments.rb_0.5.4~ds1-1.1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775635: chiark-tcl: FTBFS in jessie: build-dependency not installable: tcl8.4-dev
Source: chiark-tcl Version: 1.1.2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > ┌──┐ > │ Install chiark-tcl build dependencies (apt-based resolver) > │ > └──┘ > > Installing build dependencies > Reading package lists... > Building dependency tree... > Reading state information... > 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: > sbuild-build-depends-chiark-tcl-dummy : Depends: tcl8.4-dev but it is not > installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/chiark-tcl_1.1.2_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775630: mysql-5.5: FTBFS in jessie: make[4]: *** [CMakeFiles/abi_check] Error 1
Source: mysql-5.5
Version: 5.5.40-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> make[4]: Entering directory '/«PKGBUILDDIR»/builddir'
> make[4]: Nothing to be done for 'extra/CMakeFiles/innochecksum.dir/build'.
> make[4]: Leaving directory '/«PKGBUILDDIR»/builddir'
> /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/builddir/CMakeFiles
> [ 11%] make[4]: Entering directory '/«PKGBUILDDIR»/builddir'
> make[4]: Nothing to be done for 'sql/CMakeFiles/gen_lex_hash.dir/build'.
> make[4]: Leaving directory '/«PKGBUILDDIR»/builddir'
> /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/builddir/CMakeFiles 4
> [ 11%] make[4]: Entering directory '/«PKGBUILDDIR»/builddir'
> make[4]: Nothing to be done for
> 'unittest/mysys/CMakeFiles/my_rdtsc-t.dir/build'.
> make[4]: Leaving directory '/«PKGBUILDDIR»/builddir'
> /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/builddir/CMakeFiles 28
> 1,103c1,243
> < #include "mysql/psi/psi.h"
> < C_MODE_START
> < struct PSI_mutex;
> < struct PSI_rwlock;
> < struct PSI_cond;
> < struct PSI_table_share;
> < struct PSI_table;
> < struct PSI_thread;
> < struct PSI_file;
> < struct PSI_bootstrap
> < {
> < void* (*get_interface)(int version);
> < };
> < struct PSI_mutex_locker;
> < struct PSI_rwlock_locker;
> < struct PSI_cond_locker;
> < struct PSI_file_locker;
> < enum PSI_mutex_operation
> < {
> < PSI_MUTEX_LOCK= 0,
> < PSI_MUTEX_TRYLOCK= 1
> < };
> < enum PSI_rwlock_operation
> < {
> < PSI_RWLOCK_READLOCK= 0,
> < PSI_RWLOCK_WRITELOCK= 1,
> < PSI_RWLOCK_TRYREADLOCK= 2,
> < PSI_RWLOCK_TRYWRITELOCK= 3
> < };
> < enum PSI_cond_operation
> < {
> < PSI_COND_WAIT= 0,
> < PSI_COND_TIMEDWAIT= 1
> < };
> < enum PSI_file_operation
> < {
> < PSI_FILE_CREATE= 0,
> < PSI_FILE_CREATE_TMP= 1,
> < PSI_FILE_OPEN= 2,
> < PSI_FILE_STREAM_OPEN= 3,
> < PSI_FILE_CLOSE= 4,
> < PSI_FILE_STREAM_CLOSE= 5,
> < PSI_FILE_READ= 6,
> < PSI_FILE_WRITE= 7,
> < PSI_FILE_SEEK= 8,
> < PSI_FILE_TELL= 9,
> < PSI_FILE_FLUSH= 10,
> < PSI_FILE_STAT= 11,
> < PSI_FILE_FSTAT= 12,
> < PSI_FILE_CHSIZE= 13,
> < PSI_FILE_DELETE= 14,
> < PSI_FILE_RENAME= 15,
> < PSI_FILE_SYNC= 16
> < };
> < struct PSI_table_locker;
> < typedef unsigned int PSI_mutex_key;
> < typedef unsigned int PSI_rwlock_key;
> < typedef unsigned int PSI_cond_key;
> < typedef unsigned int PSI_thread_key;
> < typedef unsigned int PSI_file_key;
> < struct PSI_v2
> < {
> < int placeholder;
> < };
> < struct PSI_mutex_info_v2
> < {
> CMake Error at /«PKGBUILDDIR»/cmake/do_abi_check.cmake:78 (MESSAGE):
> ABI check found difference between
> /«PKGBUILDDIR»/include/mysql/psi/psi_abi_v2.h.pp
> and /«PKGBUILDDIR»/builddir/abi_check.out
>
> < int placeholder;
> < };
>
> < struct PSI_rwlock_info_v2
> < {
> < int placeholder;
> < };
> < struct PSI_cond_info_v2
> < {
> < int placeholder;
> < };
> < struct PSI_thread_info_v2
> < {
> < int placeholder;
> < };
> < struct PSI_file_info_v2
> < {
> < int placeholder;
> < };
> < struct PSI_mutex_locker_state_v2
> < {
> < int placeholder;
> < };
> < struct PSI_rwlock_locker_state_v2
> < {
> < int placeholder;
> < };
> < struct PSI_cond_locker_state_v2
> < {
> < int placeholder;
> < };
> < struct PSI_file_locker_state_v2
> < {
> < int placeholder;
> < };
> < struct PSI_table_locker_state_v2
> < {
> < int placeholder;
> ---
> > #include "plugin.h"
> > #include
> > #include
> > extern struct my_snprintf_service_st {
> > size_t (*my_snprintf_type)(char*, size_t, const char*, ...);
> > size_t (*my_vsnprintf_type)(char *, size_t, const char*, va_list);
> > } *my_snprintf_service;
> > size_t my_snprintf(char* to, size_t n, const char* fmt, ...);
> > size_t my_vsnprintf(char *to, size_t n, const char* fmt, va_list ap);
> > #include
> > struct st_mysql_lex_string
> > {
> > char *str;
> > size_t length;
> > };
>
Bug#775627: node-tap: FTBFS in jessie: Tests failures
Source: node-tap Version: 0.4.13-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > ... > ok 4 should be equivalent > ok 5 should be equivalent > ok 6 should be equal > ok 7 test/valid-command.js > > 1..7 > # tests 7 > # pass 6 > # fail 1 > > total ... 214/216 > > not ok > make[1]: *** [override_dh_auto_test] Error 1 > debian/rules:15: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/node-tap_0.4.13-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775626: php-structures-datagrid: FTBFS in jessie: exception 'InvalidArgumentException' with message 'Unknown PEAR dependency level: 'group'' in /usr/share/php/pkgtools/phppear/source.php:205
Source: php-structures-datagrid
Version: 0.9.3-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> fakeroot debian/rules binary
> dh binary --buildsystem=phppear --with phppear
>dh_testroot -O--buildsystem=phppear
>dh_prep -O--buildsystem=phppear
>dh_installdirs -O--buildsystem=phppear
>dh_auto_install -O--buildsystem=phppear
> pear/Structures_DataGrid can optionally use package "pear/PHPUnit" (version
> >= 1.3.2)
> pear/Structures_DataGrid can optionally use package "pear/File" (version >=
> 1.3.0)
> pear/Structures_DataGrid can optionally use package "pear/Net_URL_Mapper"
> (version >= 0.9.0)
> pear/Structures_DataGrid can optionally use PHP extension "sqlite"
> install ok: channel://pear.php.net/Structures_DataGrid-0.9.3
> Structures_DataGrid: Optional feature datasources available ((un)installs all
> official DataSource drivers)
> Structures_DataGrid: Optional feature renderers available ((un)installs all
> official Renderer drivers)
> Structures_DataGrid: To install optional features use "pear install
> pear/Structures_DataGrid#featurename"
>dh_installdocs -O--buildsystem=phppear
>dh_installchangelogs -O--buildsystem=phppear
>dh_perl -O--buildsystem=phppear
>dh_phppear -O--buildsystem=phppear
> exception 'InvalidArgumentException' with message 'Unknown PEAR dependency
> level: 'group'' in /usr/share/php/pkgtools/phppear/source.php:205
> Stack trace:
> #0 /usr/share/php/pkgtools/phppear/command.php(98):
> Pkgtools\Phppear\Source->getDependencies()
> #1 [internal function]: Pkgtools\Phppear\Command->runSubstvars()
> #2 /usr/share/php/pkgtools/base/command.php(181): call_user_func_array(Array,
> Array)
> #3 /usr/share/php/pkgtools/base/command.php(169):
> Pkgtools\Base\Command->parseArgs(Array)
> #4 /usr/bin/pkgtools(32): Pkgtools\Base\Command->parseArgs()
> #5 {main}
> dh_phppear: /usr/bin/pkgtools -v --sourcedirectory . phppear substvars
> returned exit code 1
> make: *** [binary] Error 29
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/php-structures-datagrid_0.9.3-1_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775625: symfony: FTBFS in jessie: Tests failures
Source: symfony Version: 2.3.21+dfsg-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Process.php:995 > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Process.php:261 > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Tests/AbstractProcessTest.php:682 > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Tests/SigchildEnabledProcessTest.php:120 > > 3) Symfony\Component\Process\Tests\SimpleProcessTest::testStartAfterATimeout > Symfony\Component\Process\Exception\RuntimeException: The process timed-out. > > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Process.php:995 > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Process.php:261 > /«BUILDDIR»/symfony-2.3.21+dfsg/src/Symfony/Component/Process/Tests/AbstractProcessTest.php:682 > [37;41m [0m > [37;41mFAILURES! [0m > [37;41mTests: 11818, Assertions: 22116, Errors: 3, Skipped: 1348.[0m > make[1]: *** [override_dh_auto_test] Error 2 > debian/rules:43: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/symfony_2.3.21+dfsg-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775624: procps: FTBFS in jessie: dh_auto_test: make -j1 check returned exit code 2
Source: procps Version: 2:3.3.9-8 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > make[4]: Entering directory '/«PKGBUILDDIR»/testsuite' > Making a new site.exp file ... > srcdir='.'; export srcdir; \ > EXPECT=expect; export EXPECT; \ > if /bin/bash -c "runtest --version" > /dev/null 2>&1; then \ > exit_status=0; l='pmap slabtop sysctl kill free lib pgrep pkill ps pwdx > uptime vmstat w'; for tool in $l; do \ > if runtest --tool $tool --srcdir $srcdir ; \ > then :; else exit_status=1; fi; \ > done; \ > else echo "WARNING: could not find 'runtest'" 1>&2; :;\ > fi; \ > exit $exit_status > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:49 2015 > Native configuration is x86_64-pc-linux-gnu > > === pmap tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./pmap.test/pmap.exp ... > > === pmap Summary === > > # of expected passes 11 > /«PKGBUILDDIR»/pmap version 3.3.9 > > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:50 2015 > Native configuration is x86_64-pc-linux-gnu > > === slabtop tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./slabtop.test/slabtop.exp ... > > === slabtop Summary === > > # of unsupported tests1 > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:50 2015 > Native configuration is x86_64-pc-linux-gnu > > === sysctl tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./sysctl.test/sysctl_read.exp ... > > === sysctl Summary === > > # of expected passes 5 > /«PKGBUILDDIR»/sysctl version 3.3.9 > > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:50 2015 > Native configuration is x86_64-pc-linux-gnu > > === kill tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./kill.test/kill.exp ... > > === kill Summary === > > # of expected passes 5 > /«PKGBUILDDIR»/kill version 3.3.9 > > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:50 2015 > Native configuration is x86_64-pc-linux-gnu > > === free tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./free.test/free.exp ... > > === free Summary === > > # of expected passes 11 > /«PKGBUILDDIR»/free version 3.3.9 > > WARNING: Couldn't find tool init file > Test Run By user on Sat Jan 17 22:44:52 2015 > Native configuration is x86_64-pc-linux-gnu > > === lib tests === > > Schedule of variations: > unix > > Running target unix > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using ./config/unix.exp as tool-and-target-specific interface file. > Running ./lib.test/fileutils.
Bug#775623: golang-go-xdg: FTBFS in jessie: dh_auto_test: go test -v launchpad.net/go-xdg/v0 returned exit code 1
Source: golang-go-xdg Version: 0~bzr20140219-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build --buildsystem=golang --with=golang >dh_testdir -O--buildsystem=golang >dh_auto_configure -O--buildsystem=golang >dh_auto_build -O--buildsystem=golang > launchpad.net/go-xdg/v0 >dh_auto_test -O--buildsystem=golang > === RUN TestXDGd > > -- > FAIL: :5: xdgdNoHomeSuite.TestDirsUsesDefault > > base_directory_test.go:71: > c.Check(hs[0], Matches, s.home+".*"+s.val1) > ... value string = "/home/user/something" > ... regex string = "/sbuild-nonexistent.*something" > > > -- > FAIL: :2: xdgdNoHomeSuite.TestHomeUsesDefault > > base_directory_test.go:45: > c.Check(h, Matches, s.home+".*"+s.val1) > ... value string = "/home/user/something" > ... regex string = "/sbuild-nonexistent.*something" > > OOPS: 16 passed, 2 FAILED > --- FAIL: TestXDGd (0.01 seconds) > FAIL > exit status 1 > FAIL launchpad.net/go-xdg/v0 0.012s > dh_auto_test: go test -v launchpad.net/go-xdg/v0 returned exit code 1 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/golang-go-xdg_0~bzr20140219-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775620: mail-notification: FTBFS in jessie: e-contact-store.h:30:31: fatal error: libebook/libebook.h: No such file or directory
Source: mail-notification Version: 5.4.dfsg.1-12 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > cc -c -o > build/src/liborg-jylefort-mail-notification-mn-evolution-folder-tree-server.o > -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS -pthread > -I/usr/include/webkitgtk-3.0 -I/usr/include/enchant -I/usr/include/gtk-3.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include > -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/nss > -I/usr/include/nspr -I/usr/include/libsecret-1 -I/usr/include/libsoup-2.4 > -I/usr/include/libxml2 -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/evolution-3.12 > -I/usr/include/gnome-desktop-3.0 -I/usr/include/libgtkhtml-4.0/editor > -I/usr/include/libgtkhtml-4.0 -I/usr/include/evolution-3.12 > -I/usr/include/evolution-data-server -I/usr/include/gsettings-desktop-schemas > -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fPIC > -g -O2 -fstack-protector-strong -Wformat -Werror=format-security > -DHAVE_REENTRANT_RESOLVER -DSTRING_ARCH_UNALIGNED -DHAVE_TIMEGM > -DWITH_EVOLUTION=1 -DWITH_GMAIL=1 -DWITH_HOTMAIL=1 -DWITH_IMAP=1 > -DWITH_MAILDIR=1 -DWITH_MBOX=1 -DWITH_MH=1 -DWITH_MOZILLA=1 -DWITH_POP3=1 > -DWITH_SYLPHEED=1 -DWITH_YAHOO=1 -DWITH_IPV6=1 -DWITH_SASL=1 -DWITH_SSL=1 > -DWITH_GCONF_SANITY_CHECK=1 -Isrc -Ibuild/src > -DGETTEXT_PACKAGE='"mail-notification"' -DENABLE_NLS -DPIC > -D_FORTIFY_SOURCE=2 -MT > build/src/liborg-jylefort-mail-notification-mn-evolution-folder-tree-server.o > -MD -MP -MF > build/src/liborg-jylefort-mail-notification-mn-evolution-folder-tree-server.o.deps > build/src/mn-evolution-folder-tree-server.c > In file included from /usr/include/evolution-3.12/e-util/e-util.h:85:0, > from > /usr/include/evolution-3.12/libemail-engine/em-vfolder-context.h:31, > from > /usr/include/evolution-3.12/libemail-engine/e-mail-session.h:35, > from > /usr/include/evolution-3.12/libemail-engine/libemail-engine.h:30, > from src/mn-evolution-folder-tree-server.gob:26, > from build/src/mn-evolution-folder-tree-server.c:15: > /usr/include/evolution-3.12/e-util/e-contact-store.h:30:31: fatal error: > libebook/libebook.h: No such file or directory > #include >^ > compilation terminated. > ERROR: command failed > make: *** [build-stamp] Error 1 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/mail-notification_5.4.dfsg.1-12_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775618: beets: FTBFS in jessie: Tests failures
Source: beets Version: 1.3.8+dfsg-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > track_artist: 2.0 > track_index: 1.0 > track_length: 2.0 > track_id: 5.0 > preferred: > countries: [] > media: [] > original_year: no > ignored: [] > required: [] > track_length_grace: 10 > track_length_max: 30 > > > make[1]: *** [override_dh_auto_test] Error 1 > debian/rules:12: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/beets_1.3.8+dfsg-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775621: python-biopython: FTBFS in jessie: Tests failures
Source: python-biopython
Version: 1.64+dfsg-5
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> E: pybuild pybuild:256: test: plugin custom failed with: exit code=1: set -e;
> \
> mkdir -p
> /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/home; \
> mkdir -p
> /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Doc; \
> cp -a Doc/Tutorial.tex
> /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Doc; \
> cp -a Tests
> /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build; \
> cd
> /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/Tests; \
> env DIALIGN2_DIR=/usr/share/dialign
> EMBOSS_ROOT=/usr/lib/emboss
> HOME=/«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_2.7/build/home
> python2.7 run_tests.py --offline
> dh_auto_test: pybuild --test -i python{version} -p 2.7 --test --system=custom
> --test-args=set -e; \
> mkdir -p {build_dir}/home; \
> mkdir -p {build_dir}/Doc; \
> cp -a Doc/Tutorial.tex {build_dir}/Doc; \
> cp -a Tests {build_dir}; \
> cd {build_dir}/Tests; \
> env DIALIGN2_DIR=/usr/share/dialign
> EMBOSS_ROOT=/usr/lib/emboss HOME={build_dir}/home {interpreter} run_tests.py
> --offline --dir . returned exit code 13
> make[1]: *** [override_dh_auto_test] Error 13
> debian/rules:71: recipe for target 'override_dh_auto_test' failed
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/python-biopython_1.64+dfsg-5_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775622: lua-rings: FTBFS in jessie: Tests failures
Source: lua-rings Version: 1.3.0-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > ldd /«PKGBUILDDIR»/5.2-rings/app-static > linux-vdso.so.1 (0x7fff5cb41000) > liblua5.2.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 > (0x7f81cd4ad000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f81cd1ac000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f81ccfa7000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f81ccbfe000) > /lib64/ld-linux-x86-64.so.2 (0x7f81cd6e6000) > *** app static (5.2) * > Test: cd src/ && @@LUA@@ ../tests/test.lua > Rings 1.3.0 > Hello World! > app.c: ../tests/test.lua:139: Cache is not being collected > make[2]: *** [test-app-static-real] Error 1 > /usr/share/dh-lua/make/dh-lua.Makefile.single:309: recipe for target > 'test-app-static-real' failed > make[1]: *** [test] Error 1 > /usr/share/dh-lua/make/dh-lua.Makefile.multiple:12: recipe for target 'test' > failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/lua-rings_1.3.0-2_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775619: seaborn: FTBFS in jessie: Tests failures
Source: seaborn
Version: 0.4.0-2
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20150117 qa-ftbfs
Justification: FTBFS in jessie on amd64
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.
Relevant part (hopefully):
> File "/usr/lib/python2.7/dist-packages/numpy/testing/decorators.py", line
> 146, in skipper_func
> return f(*args, **kwargs)
> File
> "/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build/seaborn/tests/test_distributions.py",
> line 202, in test_statsmodels_univariate_kde
> self.cut, self.clip)
> File
> "/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build/seaborn/distributions.py", line
> 674, in _statsmodels_univariate_kde
> kde = sm.nonparametric.KDEUnivariate(data)
> AttributeError: 'module' object has no attribute 'KDEUnivariate'
>
> --
> Ran 241 tests in 54.035s
>
> FAILED (SKIP=7, errors=7)
> E: pybuild pybuild:256: test: plugin custom failed with: exit code=1:
> nosetests -s -v --with-doctest /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build/
> dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit
> code 13
> make[1]: *** [override_dh_auto_test] Error 13
> debian/rules:15: recipe for target 'override_dh_auto_test' failed
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2015/01/17/seaborn_0.4.0-2_jessie.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775617: libdate-calc-xs-perl: FTBFS in jessie: Tests failures
Source: libdate-calc-xs-perl Version: 6.3-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > t/m012.t ... ok > t/m013.t ... ok > > Test Summary Report > --- > t/f016.t (Wstat: 0 Tests: 25 Failed: 16) > Failed tests: 1-4, 6-7, 9-12, 15-17, 21-23 > t/f027.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30-35, 44-45 > t/f028.t (Wstat: 0 Tests: 46 Failed: 22) > Failed tests: 7-15, 22, 24-27, 30, 32, 34-37, 44-45 > Files=52, Tests=3384, 2 wallclock secs ( 0.25 usr 0.26 sys + 1.13 cusr > 0.35 csys = 1.99 CPU) > Result: FAIL > Failed 3/52 test programs. 60/3384 subtests failed. > make[1]: *** [test_dynamic] Error 255 > Makefile:997: recipe for target 'test_dynamic' failed The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2015/01/17/libdate-calc-xs-perl_6.3-1_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775616: kwave: FTBFS in jessie: help_fr.docbook:292: parser error : Entity 'url_svn_instructions' not defined
Source: kwave Version: 0.8.11-1-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20150117 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): > make[3]: Entering directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > Generating cs.gmo > [ 0%] Generating SampleSink.moc > Generating help_en-shifted.docbook > Generating RecordController.moc > Generating ZeroPlugin.moc > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > Generating VolumePlugin.moc > [ 0%] Generating TreeWidgetWrapper.moc > Generating SonagramWindow.moc > Generating Drag.moc > Generating RecordThread.moc > [ 0%] [ 0%] Built target plugin_saveblocks_automoc > Built target plugin_selectrange_automoc > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > [ 0%] Generating help_en.pot > [ 0%] Generating index_en.cache.bz2 > [ 1%] Generating SampleSource.moc > Built target plugin_volume_automoc > [ 1%] Generating RecordPlugin.moc > [ 1%] Converting kwave_zoom_out.png > Generating SonagramDialog.moc > Generating FileDialog.moc > Built target plugin_zero_automoc > [ 1%] Converting kwave_zoom_original.png > Generating de.gmo > Generating MimeData.moc > [ 1%] make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > [ 1%] Converting kwave_zoom_in.png > [ 1%] [ 1%] Generating SignalManager.moc > Built target plugin_sonagram_automoc > Built target plugin_record_automoc > Generating ViewItem.moc > [ 1%] [ 1%] Converting kwave_viewmagfit.png > [ 2%] Generating es.gmo > Converting kwave_viewmag.png > [ 2%] Converting kwave_player_stop.png > Generating Track.moc > Converting kwave_player_start.png > Generating FilterPlugin.moc > [ 3%] [ 3%] Generating fr.gmo > [ 3%] Generating PlaybackSink.moc > [ 3%] [ 4%] Converting kwave_player_rew.png > Generating TrackPixmap.moc > Converting kwave_player_play.png > Converting kwave_player_record.png > [ 4%] Converting kwave_player_pause_2.png > Generating Encoder.moc > [ 4%] [ 4%] [ 4%] Generating MenuNode.moc > Converting kwave_player_pause.png > [ 5%] Converting kwave_player_fwd.png > Converting kwave_player_end.png > [ 5%] Converting kwave_player_bg.png > Converting kwave_player_loop.png > Generating TrackWriter.moc > [ 5%] Generating SelectTimeWidget.moc > [ 5%] Generating help_cs-tmp.po > [ 6%] make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > Generating help_de-tmp.po > Generating help_fr-tmp.po > Generating help_es-tmp.po > Generating RateConverter.moc > [ 6%] Built target translations > Generating HMSTimeWidget.moc > Generating StreamObject.moc > . > done. > . done. > .. > done. > .. done. > Generating FrequencyResponseWidget.moc > Generating UndoInsertAction.moc > Generating MenuGroup.moc > Generating StreamWriter.moc > [ 6%] [ 6%] [ 6%] [ 6%] Building help_es.docbook (Español) > Building help_cs.docbook (čeština) > Building help_fr.docbook (Francais) > Building help_de.docbook (Deutsch) > Generating WorkerThread.moc > Generating LabelItem.moc > Generating MultiTrackWriter.moc > Generating MenuSub.moc > Generating SampleReader.moc > Generating TrackView.moc > Generating Selection.moc > Generating MenuRoot.moc > Generating MultiWriter.moc > make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' > Generating Writer.moc > [ 6%] Built target libkwavegui_automoc > Generating Indexer.moc > Generating Delay.moc > Generating CodecManager.moc > help_fr.docbook:292: parser error : Entity 'url_svn_instructions' not defined > >, consultez l'URL ^ > help_fr.docbook:293: parser error : Entity 'url_svn_instructions' not defined > >"&url_svn_instructions;" ^ > help_fr.docbook:910: parser error : Entity 'url_svn_trunk' not defined > >svn checkout &url_svn_trunk; kwave ^ > help_fr.docbook:717: element link: valiGenerating PluginManager.
Bug#775614: u-boot-tools fails to build with cross-toolchain
Package: u-boot Version: 2014.10+dfsg1-2 Severity: wishlist When attempting to build u-boot using a cross-toolchain (crossbuild-essential-armhf, gcc-4.9-arm-linux-gnueabihf, etc.) with sbuild, the individual board targets appear to build fine, but it fails on the tools-only target: make[2]: Leaving directory '/«BUILDDIR»/u-boot-2014.10+dfsg1' # board-independent tools /usr/bin/make O=debian/build/tools -j5 \ HOSTCC=arm-linux-gnueabihf-gcc \ HOSTSTRIP=arm-linux-gnueabihf-strip \ NO_SDL=1 \ tools-only make[2]: Entering directory '/«BUILDDIR»/u-boot-2014.10+dfsg1' CHK include/config/uboot.release CHK include/generated/timestamp_autogenerated.h HOSTCC scripts/basic/fixdep UPD include/generated/timestamp_autogenerated.h UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h /bin/sh: 1: scripts/basic/fixdep: not found make[4]: *** [scripts/basic/fixdep] Error 127 scripts/Makefile.host:118: recipe for target 'scripts/basic/fixdep' failed make[3]: *** [scripts_basic] Error 2 /«BUILDDIR»/u-boot-2014.10+dfsg1/Makefile:384: recipe for target 'scripts_basic' failed make[2]: *** [sub-make] Error 2 Makefile:134: recipe for target 'sub-make' failed make[2]: Leaving directory '/«BUILDDIR»/u-boot-2014.10+dfsg1' make[1]: *** [override_dh_auto_build] Error 2 debian/rules:28: recipe for target 'override_dh_auto_build' failed make[1]: Leaving directory '/«BUILDDIR»/u-boot-2014.10+dfsg1' make: *** [build] Error 2 debian/rules:24: recipe for target 'build' failed dpkg-buildpackage: error: debian/rules build gave error exit status 2 live well, vagrant signature.asc Description: PGP signature
Bug#775612: amanda-server: Intermittently occurring
Package: amanda-server Version: 1:3.3.6-4 Followup-For: Bug #775612 This bug is rather strange as I have rerun using the exact commandline and now the command succeeds with no error message. I have been getting these messages in some but not all of my emails from amanda. There is something distinctly strange going on. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amanda-server depends on: ii amanda-common 1:3.3.6-4 ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 ii libc6 2.19-13 ii libcurl3 7.38.0-4 ii libglib2.0-0 2.42.1-1 ii libssl1.0.01.0.1j-1 ii mailutils [mailx] 1:2.99.98-2 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.3.6-4 ii cpio 2.11+dfsg-4 pn gnuplot ii mt-st 1.1-6 ii perl [perl5] 5.20.1-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774867: [Pkg-lirc-maint] Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
On Sun, 18 Jan 2015 01:03:36 +0100, Stefan Lippers-Hollmann wrote: > On Saturday 17 January 2015, gregor herrmann wrote: > > I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and > > uploaded it to DELAYED/2. Please feel free to tell me if I > > should delay it longer. > First of all, I acknowledge the NMU - thanks a lot, go ahead as you > wish, but... Thanks! > I don't object to the patch, but it doesn't really help with this bug. > The bug itself only happens when dist-upgrading from squeeze to wheezy, > neither wheezy, jessie or wheezy-->jessie upgrades are affected at all, > so fixing this bug in jessie doesn't help any squeeze user who's just > now starting to look at dist-upgrading to wheezy at all. I thought the same too, when looking at the bug, but my tests were quite interesting: - squeeze chroot, lirc-x installed - updated to wheezy - here the bug occurs - updated to jessie with the patched package: here the problem gets fixed So my conclusion is that the fix does help people who upgraded from squeeze (but it's indeed not necessary for people who install(ed) only the wheezy or jessie version). > Therefore I'm curious, what is your plan with this bugfix? > Asking the release team for a jessie unblock doesn't really meet the > unblock criteria anymore, as the bug doesn't affect jessie nor wheezy > to jessie dist-upgrades (actually, had this bug been reported and fixed > in time before the wheezy release, I would have already removed this > kind of pre-wheezy upgrade support from the packages intended for > jessie). I'll let Jonathan answer this question; but since he uploaded the same fix I'd assume that the release team will unblock the package :) > This piuparts mass bug filing imho would have better concentrated on > just wheezy to jessie issues, rather than murkying the waters by > including squeeze-->wheezy issues as well, that ship has sailed long > time ago. I'm also a bit ambivalent about the value of those squeeze->wheezy->jessie upgrade tests where many issues just can't be fixed anymore. But unless I'm confusing something in my test setup, this is a case where a fix in jessie "repairs" a problem introduced earlier. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Schmetterlinge: Ballade vom Glück und Ende des Kapitals signature.asc Description: Digital Signature
Bug#775613: systemd: why is /run/systemd/inhibit/1.ref inherited?
Package: systemd
Version: 215-9
Severity: normal
type=AVC msg=audit(1421538903.417:232): avc: denied { use } for pid=23546
comm="kded4" path="/run/systemd/inhibit/1.ref" dev="tmpfs" ino=91124
scontext=rjc:user_r:user_t:s0-s0:c0.c1023
tcontext=system_u:system_r:systemd_logind_t:s0 tclass=fd permissive=0
When I login via kdm the KDE user processes (and presumably user processes
from any other desktop environment) inherit /run/systemd/inhibit/1.ref.
Is this desired? If so why? I have SE Linux preventing it and everything
works.
-- Package-specific info:
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-58
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-4
ii libgcrypt20 1.6.2-4+b1
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2+b3
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-9
ii mount 2.25.2-4
ii sysv-rc 2.88dsf-58
ii udev215-9
ii util-linux 2.25.2-4
Versions of packages systemd recommends:
ii dbus1.8.14-1
ii libpam-systemd 215-9
Versions of packages systemd suggests:
pn systemd-ui
-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=25M
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
On 17/01/15 21:38, Fabian Greffrath wrote: > Chex 1/2 and Hacx should go into doom.yaml. For at least Chex Quest, I disagree. My intention is that the division into YAML files (and, one day, entries in a GUI) is not about whether things happen to run on the same engine - that's an implementation detail. Rather, it's about whether, based on how the game is/was advertised and distributed, an average player would think of it as "the same game" or not. Chex Quest was a standalone game given away in breakfast cereal to children too young to be playing Doom, that's clearly not meant to be "basically the same" :-) That's why plutonia-wad and tnt-wad are now generated by final-doom.yaml. Technically, they're IWADs for a Doom II-compatible engine, so on a technical basis you could argue for them to be either two separate "games" like they were in shell-script-based g-d-p (because they're independent IWADs and you can in principle have one but not the other) or part of Doom II (because they run on the Doom II engine) - but they were sold together as Final Doom, a standalone game (as opposed to an expansion pack for Doom II), and so that's how I think their g-d-p support should be structured. Hacx is more ambiguous, because it isn't clear from the info I've seen whether it was originally sold as a Doom II addon, or as a standalone game with its own copy of the Doom II executable. I would tend to err on the side of separating it out rather than putting it in doom2.yaml, but I'll defer to the superior knowledge of people who've actually played it :-P S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775612: amanda-server: Depends on Tie/StdHash.pm which exists on NO package in debian
Package: amanda-server Version: 1:3.3.6-4 Severity: serious Justification: depends on software not in debian Seen when attemping to do amrmtape, but also occurs when doing a flush: an't locate Tie/StdHash.pm: Permission denied at /usr/share/perl/5.20/base.pm line 97. ...propagated at /usr/share/perl/5.20/base.pm line 106. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config/FoldingHash.pm line 3. Compilation failed in require at /usr/lib/amanda/perl/Amanda/Config.pm line 753. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config.pm line 753. Compilation failed in require at /usr/sbin/amrmtape line 27. BEGIN failed--compilation aborted at /usr/sbin/amrmtape line 27. StdHash.pm is not a file that exists in ANY package in debian according to apt-file. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amanda-server depends on: ii amanda-common 1:3.3.6-4 ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 ii libc6 2.19-13 ii libcurl3 7.38.0-4 ii libglib2.0-0 2.42.1-1 ii libssl1.0.01.0.1j-1 ii mailutils [mailx] 1:2.99.98-2 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.3.6-4 ii cpio 2.11+dfsg-4 pn gnuplot ii mt-st 1.1-6 ii perl [perl5] 5.20.1-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774867: [Pkg-lirc-maint] Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
Hi
[ Apologies if you receive this twice, my mail relay/ smarthost seems
to have problems and my previous/ identical response hasn't gotten
through yet. ]
On Saturday 17 January 2015, gregor herrmann wrote:
> Control: tags 774867 + patch
> Control: tags 774867 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
First of all, I acknowledge the NMU - thanks a lot, go ahead as you
wish, but...
[feel free to ignore the rest of this mail]
I don't object to the patch, but it doesn't really help with this bug.
The bug itself only happens when dist-upgrading from squeeze to wheezy,
neither wheezy, jessie or wheezy-->jessie upgrades are affected at all,
so fixing this bug in jessie doesn't help any squeeze user who's just
now starting to look at dist-upgrading to wheezy at all. Actually it's
even worse, symlink_to_dir was only added to dpkg's maintscript
collection in dpkg 1.17.14, while squeeze is at 1.15.11 (admitted,
Pre-Depends: ${misc:Pre-Depends} should handle that aspect).
Therefore I'm curious, what is your plan with this bugfix?
Asking the release team for a jessie unblock doesn't really meet the
unblock criteria anymore, as the bug doesn't affect jessie nor wheezy
to jessie dist-upgrades (actually, had this bug been reported and fixed
in time before the wheezy release, I would have already removed this
kind of pre-wheezy upgrade support from the packages intended for
jessie).
Asking the stable-release managers to accept a wheezy-proposed-updates
upload for an equivalent fix targetting the next wheezy point release
would be justified - and I certainly would have done so up to 'a year
ago', but now that squeeze is EOL for over half a year already, it
feels a bit late (still correct, but as no actual user ever complained,
'why bother' (and get the stable-release managers busy for basically an
obsolete problem) at this point in time)?
So considerding that this change is neither needed for jessie+1
(stretch), nor fullfills the unblock criterias for jessie (and isn't
actually needed there either), the (correct) upload can only migrate
to testing (==stretch) after jessie has been released - when and where
it is even less needed than in jessie itself.
Accordingly, my plan was waiting until this weekend for a potential
response from the reporter, but pending that, to close the bug for
lirc 0.9.0~pre1-1.1 (the package version in jessie, technically not
100% correct, but it conveys the message correctly; asking the release
team for a jessie-ignore would basically do the same job) and tagging
it wheezy and wontfix. But as I mentioned, your change is the correct
solution, it's imho just way too late to fix at this point in time,
when the fix won't ever propagate to the only ones (current squeeze
users who are planning to dist-upgrade to wheezy) anymore. Making it
just academic busy-work for everyone involved.
To be clear, I very much appreciate your effort - thanks a lot - and
I'm fine with getting this uploaded to unstable, but I personally don't
see a need to bother the release team with an unblock request
(certainly not for jessie, nor -at this point in time- for wheezy
anymore) at this point in the freeze.
...and the next regular post-jessie lirc upload will just remove all
pre-jessie upgrade support (including this change[1]) from the package
anyways...
This piuparts mass bug filing imho would have better concentrated on
just wheezy to jessie issues, rather than murkying the waters by
including squeeze-->wheezy issues as well, that ship has sailed long
time ago.
Regards
Stefan Lippers-Hollmann
[1] there would be reason to make an exception for this particular
change to go through one stable release, just to get it fixed
once and for all for everyone, but that's mostly academic here.
signature.asc
Description: This is a digitally signed message part.
Bug#762984: Alert! /dev/vg0/usr does not exist
On Thu, 27 Nov 2014 11:51:48 + Simon McVittie wrote: > On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: > > I suspect this is essentially the same bug as #616689 and #678696, > > except that now it may affect mounting /usr as well as /. > > I think this bug report is actually describing more than one bug in more > than one package that have similar symptoms. There might be things > that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 > regressions without needing to implement a full event-driven setup in > initramfs-tools. [...] > LVM (Elimar's "System 1", Sven, Torsten, IOhannes, Javier) > > In the LVM case, debian/initramfs-tools/lvm2/scripts/local-top > does this: > > activate_vg "$ROOT" > activate_vg "$resume" > > Note the lack of handling for /usr here. > > Further, activate_vg uses "lvm lvchange" to activate only the LV > necessary for the root filesystem; if /usr is on a separate VG, > it's not going to work. > > This on its own would be enough to make Sven Hartge's system fail: > /usr needs a LVM partition activated that / does not. Similarly, > I think Elimar's "System 1" is going to activate vg0/root but not > vg0/usr. [...] > The ideal thing in both of these situations would be to use the same > logic as *mounting* /usr - mount the rootfs first, then read its fstab > to find out where /usr is, avoiding hard-coding that knowledge into > the initramfs - but I think that would need a significantly more > complicated hook structure. I'm proposing to add another hook for this, which will initially only be implemented by lvm2. So far as I can see, mdadm and lvm2 have to find the required devices in different ways: - mdadm cannot generally tell which RAID arrays are needed, as the root device may be identified by filesystem UUID or LV name but it only works with RAID array UUIDs and the component device names - lvm2 can tell exactly which VG is needed as a root device on an LV is identified by VG and LV name The same goes for mounting /usr. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#718362: Link to the documentation
For the record, here is the link to the documentation about this situation: http://security-team.debian.org/security_tracker.html#packages-in-experimental-only Cheers, luciano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771301: Failure to set up md-RAID device backing /usr partition in initramfs
On Thu, 27 Nov 2014 11:51:48 + Simon McVittie wrote: > On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: > > I suspect this is essentially the same bug as #616689 and #678696, > > except that now it may affect mounting /usr as well as /. > > I think this bug report is actually describing more than one bug in more > than one package that have similar symptoms. There might be things > that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 > regressions without needing to implement a full event-driven setup in > initramfs-tools. > > RAID (Elimar, Sven) > > Elimar Riesebieter's "System 2" has a bunch of mdadm (RAID) partitions. > > Elimar, what is in your /etc/default/mdadm on "System 2" (and "System 1" > for that matter)? I predict that the answer includes something like > "INITRDSTART=/dev/md6". > > The problem here seems to be that mdadm tries to determine a minimal > set of multi-disk partitions need to be assembled by the initramfs > based on the assumption that the initramfs only needs the root device; > but initramfs-tools >= 0.117 wants to mount /usr as well, so that > assumption is no longer true. > > So it might be necessary to modify mdadm so that, if /usr is a separate > filesystem on (a LVM VG on) a MD array, it will try to prepare that too. [...] Given that there is an INITRDSTART setting to explicitly specify the wanted devices, and that the default value of 'all' will continue to work, I am inclined to document this problem in NEWS and release notes. We could do a bit better by checking for this case at upgrade time and showing a debconf error, or even better by offering to fix it. I don't think the problem is likely to be common enough to deserve that much work. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#775563: libgl1-mesa-dri: dlopen i915_dri.so fails: undefined symbol: _glapi_tls_Didpatch
On Sat, Jan 17, 2015 at 23:38:14 +, Dominic Hargreaves wrote: > libGL.so.1 => /usr/lib/tls/libGL.so.1 (0xb7611000) that's not something we ship. Cheers, Julien signature.asc Description: Digital signature
Bug#775611: [sh]: FTBFS due to unknown compiler option '-m32'
Package: linux Version: 3.16.7-ckt4-1 Severity: normal Tags: patch Hi! The kernel package currently fails to build from source on sh4 since the build scripts try to pass the '-m32' compiler option on gcc which is not available with gcc on sh4 (also according to the manpage). Selecting HAVE_C_RECORDMCOUNT in arch/sh/Kconfig (see attached patch by Ben Hutchings) fixes the issues. However, I also suggest removing the line "$cc .= " -m32";" for sh compiler options in scripts/ recordmcount.pl. Thanks! Adrian diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 0f09f52..b2c9904 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -44,6 +44,7 @@ config SUPERH select OLD_SIGSUSPEND select OLD_SIGACTION select HAVE_ARCH_AUDITSYSCALL + select HAVE_C_RECORDMCOUNT help The SuperH is a RISC processor targeted for use in embedded systems and consumer electronics; it was also used in the Sega Dreamcast
Bug#775563: libgl1-mesa-dri: dlopen i915_dri.so fails: undefined symbol: _glapi_tls_Didpatch
On Sun, Jan 18, 2015 at 12:20:50AM +0100, Julien Cristau wrote: > On Sat, Jan 17, 2015 at 12:48:33 +, Dominic Hargreaves wrote: > > > Package: libgl1-mesa-dri > > Version: 10.3.2-1 > > Severity: grave > > Justification: renders package unusable > > > > After upgrading from wheezy to jessie, I found I was unable to use gdm3 > > (with an unhelpful generic error message, but that's beside the point). > > > > The X log reveals: > > > > [ 130.136] (EE) AIGLX error: dlopen of > > /usr/lib/i386-linux-gnu/dri/i915_dri.so > > failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: undefined symbol: > > _glapi_tls_D > > ispatch) > > [ 130.136] (EE) AIGLX: reverting to software rendering > > [ 130.146] (EE) AIGLX error: dlopen of > > /usr/lib/i386-linux-gnu/dri/swrast_dri. > > so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: > > _glapi_t > > ls_Dispatch) > > [ 130.146] (EE) GLX: could not load software renderer > > [ 130.146] (II) GLX: no usable GL providers found for screen 0 > > > What's the output from ldd /usr/lib/xorg/modules/extensions/libglx.so? dom@callisto:~$ ldd /usr/lib/xorg/modules/extensions/libglx.so linux-gate.so.1 (0xb76e3000) libGL.so.1 => /usr/lib/tls/libGL.so.1 (0xb7611000) libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb75f5000) libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb75ef000) libaudit.so.1 => /lib/i386-linux-gnu/libaudit.so.1 (0xb75c9000) libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7583000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb73d8000) libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0xb6f23000) libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb6f0d000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6dbb000) /lib/ld-linux.so.2 (0xb76e6000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6d95000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6d91000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6d8b000) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775350: util-linux: diff for NMU version 2.25.2-4.1
On Sat, Jan 17, 2015 at 09:12:53PM +0100, Andreas Henriksson wrote: > Hello Jonathan Wiltshire. > > On Sat, Jan 17, 2015 at 04:31:54PM +, Jonathan Wiltshire wrote: > > Control: tags 775350 + patch > > Control: tags 775350 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for util-linux (versioned as 2.25.2-4.1) and > > uploaded it to DELAYED/5. Please feel free to tell me if I > > should delay it longer. > > I'm guessing you're also aware of #773354. I'm a bit skeptical if > what is requested there is something that should be done on > util-linux turf at all. Your opinion (why you choose not to do > something about it in your NMU) would be appreciated. Oh that's easy, I hadn't spotted it in the list before uploading. > If a breaks for #773354 is added, I think one for #772846 should be > as well. (And I wonder how many more...) > > Anyway, if you feel that your NMU is the right set of bugfixes > then please feel free to go ahead with your NMU without delay. I'll have a look tomorrow at those other bugs. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Bug#770492: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks
chown() and write() should clear all privilege attributes on a file - setuid, setgid, setcap and any other extended privilege attributes. However, any attributes beyond setuid and setgid are managed by the LSM and not directly by the filesystem, so they cannot be set along with the other attributes. Currently we call security_inode_killpriv() in notify_change(), but in case of a chown() this is too early - we have not called inode_change_ok() or made any filesystem-specific permission/sanity checks. Add a new function setattr_killpriv() which calls security_inode_killpriv() if necessary, and change the setattr() implementation to call this in each filesystem that supports xattrs. This assumes that extended privilege attributes are always stored in xattrs. Compile-tested only. XXX This is a silent change to the VFS API, but we should probably change something so OOT filesystems fail to compile if they aren't updated to call setattr_killpriv(). Reported-by: Ben Harris References: https://bugs.debian.org/770492 --- drivers/staging/lustre/lustre/llite/llite_lib.c | 4 fs/9p/vfs_inode.c | 4 fs/9p/vfs_inode_dotl.c | 4 fs/attr.c | 32 + fs/btrfs/inode.c| 4 fs/ceph/inode.c | 4 fs/cifs/inode.c | 11 - fs/ext2/inode.c | 4 fs/ext3/inode.c | 4 fs/ext4/inode.c | 4 fs/f2fs/file.c | 4 fs/fuse/dir.c | 15 +++- fs/fuse/file.c | 3 ++- fs/fuse/fuse_i.h| 2 +- fs/gfs2/inode.c | 3 +++ fs/hfs/inode.c | 4 fs/hfsplus/inode.c | 4 fs/jffs2/fs.c | 4 fs/jfs/file.c | 4 fs/kernfs/inode.c | 17 + fs/libfs.c | 3 +++ fs/nfs/inode.c | 11 +++-- fs/ocfs2/file.c | 6 - fs/reiserfs/inode.c | 4 fs/ubifs/file.c | 4 fs/xfs/xfs_acl.c| 3 ++- fs/xfs/xfs_file.c | 2 +- fs/xfs/xfs_ioctl.c | 2 +- fs/xfs/xfs_iops.c | 16 ++--- fs/xfs/xfs_iops.h | 10 ++-- include/linux/fs.h | 1 + mm/shmem.c | 4 32 files changed, 176 insertions(+), 25 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c b/drivers/staging/lustre/lustre/llite/llite_lib.c index a8bcc51..2a714b2 100644 --- a/drivers/staging/lustre/lustre/llite/llite_lib.c +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c @@ -1434,6 +1434,10 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr *attr, bool hsm_import) spin_unlock(&lli->lli_lock); } + rc = setattr_killpriv(dentry, attr); + if (rc) + return rc; + /* We always do an MDS RPC, even if we're only changing the size; * only the MDS knows whether truncate() should fail with -ETXTBUSY */ diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index 296482f..735cbf84 100644 --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -1130,6 +1130,10 @@ static int v9fs_vfs_setattr(struct dentry *dentry, struct iattr *iattr) if (S_ISREG(dentry->d_inode->i_mode)) filemap_write_and_wait(dentry->d_inode->i_mapping); + retval = setattr_killpriv(dentry, iattr); + if (retval) + return retval; + retval = p9_client_wstat(fid, &wstat); if (retval < 0) return retval; diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c index 02b64f4..f3ca76d 100644 --- a/fs/9p/vfs_inode_dotl.c +++ b/fs/9p/vfs_inode_dotl.c @@ -583,6 +583,10 @@ int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct iattr *iattr) if (S_ISREG(inode->i_mode)) filemap_write_and_wait(inode->i_mapping); + retval = setattr_killpriv(dentry, iattr); + if (retval) + return retval; + retval = p9_client_setattr(fid, &p9attr); if (retval < 0) return retval; diff --git a/fs/attr.c b/fs/attr.c index 6530ced..184f3bf 100644 --- a/fs/attr.c +++ b/fs/attr.c @@ -168,6 +168,28 @@ void setattr_copy(struct inode *inode, const struct iattr *attr) EXPORT_SYMBOL(setattr_copy); /** + *
Bug#762984: [PATCH initramfs-tools 2/2] control: Add versioned Breaks on lvm2 without a local-extra boot script
Closes: #762984
Signed-off-by: Ben Hutchings
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index fb2c918..928a8de 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Depends: klibc-utils (>= 2.0-1~), cpio, kmod |
module-init-tools, udev, ${misc:D
Suggests: bash-completion
Provides: linux-initramfs-tool
Conflicts: linux-initramfs-tool, usplash (<< 0.5.50)
-Breaks: cryptsetup (<< 2:1.6.6-4~), elilo (<< 3.12-3.1~), lilo (<< 22.8-8.2~),
s390-tools (<< 1.8.3-2~), console-setup (<< 1.72), systemd-sysv (<< 186)
+Breaks: cryptsetup (<< 2:1.6.6-4~), elilo (<< 3.12-3.1~), lilo (<< 22.8-8.2~),
s390-tools (<< 1.8.3-2~), console-setup (<< 1.72), systemd-sysv (<< 186), lvm2
(<< 2.02.111-2.1~)
Description: generic modular initramfs generator
This package contains tools to create a bootable initramfs for Linux kernel
packages. The initramfs is a compressed cpio archive. At boot time, the
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
signature.asc
Description: This is a digitally signed message part
Bug#762984: [PATCH initramfs-tools 1/2] local: Call local-extra boot scripts to prepare additional block devices
Signed-off-by: Ben Hutchings --- initramfs-tools.8 | 7 +++ scripts/local | 2 ++ 2 files changed, 9 insertions(+) diff --git a/initramfs-tools.8 b/initramfs-tools.8 index 1d48e66..dbb430c 100644 --- a/initramfs-tools.8 +++ b/initramfs-tools.8 @@ -415,6 +415,13 @@ present (local) or the network interface is expected to be usable (NFS). .TP \fB\fI +local-extra +These scripts are called with the name of a local device other than +that used for root. After these scripts have been executed, that +device node is expected to be present. + +.TP +\fB\fI local-premount OR nfs-premount are run after the sanity of the root device has been verified (local) or the network interface has been brought up (NFS), but before the actual root fs has diff --git a/scripts/local b/scripts/local index cb6b0f0..f9e588d 100644 --- a/scripts/local +++ b/scripts/local @@ -147,6 +147,8 @@ local_mount_fs() read_fstab_entry "$1" MNT_FSNAME=$(resolve_device "$MNT_FSNAME") + run_scripts /scripts/local-extra "$MNT_FSNAME" + local_device_setup "$MNT_FSNAME" "$1" local_premount -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#756253: Upgrade from 2.02~beta2-10 to 2.02~beta2-11 left grub unbootable
On Sat, Jan 17, 2015 at 05:22:52PM +, Steve McIntyre wrote: > On Sat, Jan 17, 2015 at 04:16:56PM +0900, Mike Hommey wrote: > >On Fri, Jan 16, 2015 at 10:28:51PM +, Steve McIntyre wrote: > >> Hi Mike, > >> > >> Have you seen this again recently? Is it still happening for you? > > > >As a matter of fact, it hasn't happened recently. That being said, I'm > >not upgrading grub that often, but I happen to have upgraded it today, > >and a reboot worked. It's too late now to know what the efi boot table > >looked like before, but during the package install, efibootmgr > >complained like this: > > > >Installing for x86_64-efi platform. > >efibootmgr: Could not set variable Boot0001: No such file or directory > >efibootmgr: Could not prepare boot variable: No such file or directory > > Oh, that's much more interesting. That suggests your actual problem is > below grub - either efibootmgr or your firmware. Note that I don't think this was being printed when I filed the bug. As a matter of fact, message #20 says I had a Boot0001 back then, and I had 2 Windows boot manager entries, so the gap probably comes from me fixing that afterwards. > Adding a CC to the > efibootmgr package maintainer too. What versions do you have for > libefivar0 and efibootmgr? If you run ii efibootmgr 0.11.0-3 amd64 ii libefivar0:amd640.15-3 amd64 Now, since the history of the bug says that I filed it in july and had it still occur on oct 24, here is another possibly interesting bit of data: # zgrep -h upgrade\ libefivar0 dpkg.log* | sort 2014-07-01 14:31:17 upgrade libefivar0:amd64 0.10-2 0.10-4 2014-07-15 18:03:11 upgrade libefivar0:amd64 0.10-4 0.10-5 2014-10-04 09:26:11 upgrade libefivar0:amd64 0.10-5 0.12-1 2014-10-18 10:44:58 upgrade libefivar0:amd64 0.12-1 0.14-1 2014-11-03 11:26:54 upgrade libefivar0:amd64 0.14-1 0.15-1 2014-12-16 08:55:38 upgrade libefivar0:amd64 0.15-1 0.15-2 2014-12-23 19:23:29 upgrade libefivar0:amd64 0.15-2 0.15-3 # zgrep -h upgrade\ efibootmgr dpkg.log* | sort 2014-05-07 17:19:09 upgrade efibootmgr:amd64 0.5.4-7 0.6.1-3 2014-06-20 21:20:34 upgrade efibootmgr:amd64 0.6.1-3 0.7.0-1 2014-07-15 18:04:01 upgrade efibootmgr:amd64 0.7.0-1 0.7.0-2 2014-10-04 09:27:00 upgrade efibootmgr:amd64 0.7.0-2 0.9.0-1 2014-10-18 10:57:25 upgrade efibootmgr:amd64 0.9.0-1 0.9.0-2 2014-11-03 11:27:20 upgrade efibootmgr:amd64 0.9.0-2 0.11.0-1 2014-12-16 08:58:39 upgrade efibootmgr:amd64 0.11.0-1 0.11.0-1.1 2014-12-23 19:23:49 upgrade efibootmgr:amd64 0.11.0-1.1 0.11.0-3 # zgrep -h upgrade\ grub-efi-amd64 dpkg.log* | sort 2014-04-09 12:11:00 upgrade grub-efi-amd64:amd64 2.00-22 2.02~beta2-8 2014-04-09 12:11:00 upgrade grub-efi-amd64-bin:amd64 2.00-22 2.02~beta2-8 2014-06-20 21:20:52 upgrade grub-efi-amd64:amd64 2.02~beta2-8 2.02~beta2-10 2014-06-20 21:20:53 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-8 2.02~beta2-10 2014-07-28 08:39:14 upgrade grub-efi-amd64:amd64 2.02~beta2-10 2.02~beta2-11 2014-07-28 08:39:15 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-10 2.02~beta2-11 2014-09-24 06:10:56 upgrade grub-efi-amd64:amd64 2.02~beta2-11 2.02~beta2-13 2014-09-24 06:10:57 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-11 2.02~beta2-13 2014-10-04 09:28:07 upgrade grub-efi-amd64:amd64 2.02~beta2-13 2.02~beta2-14 2014-10-04 09:28:08 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-13 2.02~beta2-14 2014-10-18 10:58:07 upgrade grub-efi-amd64:amd64 2.02~beta2-14 2.02~beta2-15 2014-10-18 10:58:07 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-14 2.02~beta2-15 2014-12-16 08:59:19 upgrade grub-efi-amd64:amd64 2.02~beta2-15 2.02~beta2-18 2014-12-16 08:59:20 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-15 2.02~beta2-18 2014-12-23 19:23:52 upgrade grub-efi-amd64:amd64 2.02~beta2-18 2.02~beta2-19 2014-12-23 19:23:53 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-18 2.02~beta2-19 2015-01-17 11:38:15 upgrade grub-efi-amd64:amd64 2.02~beta2-19 2.02~beta2-20 2015-01-17 11:38:16 upgrade grub-efi-amd64-bin:amd64 2.02~beta2-19 2.02~beta2-20 > # strace -f -o strace grub-install I don't think this would be relevant to the original bug, but here you are, attached. There is a ENOSPC in response to creating a new variable. So in fact, it may well be not fixed, but "seems" to be fixed because efibootmgr fails to do anything and doesn't break the boot configuration as a result. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732253: Cannot reproduce this bug
Thank you for the comprehensive report. I cannot reproduce this bug on any of my systems running jessie or sid (I cannot test on wheezy). But it has also been reported in the Ubuntu version of this package: https://bugs.launchpad.net/ubuntu/+source/angband/+bug/1309711 I share your suspicion that this is a bug in libsdl-ttf2.0, but am uncertain of my grounds for reassigning the bug. If any more experienced maintainers/DDs are reading this, any advice appreciated. Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775563: libgl1-mesa-dri: dlopen i915_dri.so fails: undefined symbol: _glapi_tls_Didpatch
On Sat, Jan 17, 2015 at 12:48:33 +, Dominic Hargreaves wrote: > Package: libgl1-mesa-dri > Version: 10.3.2-1 > Severity: grave > Justification: renders package unusable > > After upgrading from wheezy to jessie, I found I was unable to use gdm3 > (with an unhelpful generic error message, but that's beside the point). > > The X log reveals: > > [ 130.136] (EE) AIGLX error: dlopen of > /usr/lib/i386-linux-gnu/dri/i915_dri.so > failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: undefined symbol: > _glapi_tls_D > ispatch) > [ 130.136] (EE) AIGLX: reverting to software rendering > [ 130.146] (EE) AIGLX error: dlopen of > /usr/lib/i386-linux-gnu/dri/swrast_dri. > so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: > _glapi_t > ls_Dispatch) > [ 130.146] (EE) GLX: could not load software renderer > [ 130.146] (II) GLX: no usable GL providers found for screen 0 > What's the output from ldd /usr/lib/xorg/modules/extensions/libglx.so? Cheers, Julien signature.asc Description: Digital signature
Bug#775583: [PATCH] Add initramfs-tools boot script for preparing additional block devices (Closes: #775583)
Control: tag -1 patch
Here is a new script cribbed from the existing scripts/local-top/lvm2.
Tested in conjunction with the patch I'm about to send to #762984.
--- /dev/null
+++ b/debian/initramfs-tools/lvm2/scripts/local-extra/lvm2
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+PREREQ="mdadm mdrun multipath"
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+if [ ! -e /sbin/lvm ]; then
+ exit 0
+fi
+
+dev="$1"
+
+# Make sure that we have a d-m path
+dev="${dev#/dev/mapper/}"
+if [ "$dev" = "$1" ]; then
+ exit 0
+fi
+
+eval $(dmsetup splitname --nameprefixes --noheadings --rows "$dev")
+
+if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
+ lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
+ rc=$?
+ if [ $rc = 5 ]; then
+ echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
+ fi
+fi
+
+exit 0
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
signature.asc
Description: This is a digitally signed message part
Bug#775610: policycoreutils: strange access to /root/tmpfiles.d from restorecond
Package: policycoreutils
Version: 2.3-1
Severity: normal
# dmesg|grep tmpfiles.d
[ 48.978396] audit: type=1400 audit(1421535877.996:30): avc: denied { read
} for pid=746 comm="restorecond" name="tmpfiles.d" dev="dm-0" ino=207033
scontext=system_u:system_r:restorecond_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=lnk_file permissive=0
# find /root -inum 207033
/root/tmpfiles.d
For some reason restorecond is trying to read the symlink /root/tmpfiles.d.
The symlink in question was created in 2012 and I don't know why I created it
or if it was created by a script.
A grep of the source code didn't show a reason for this access, there is no
match for the string tmpfiles.d in the policycoreutils source.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect
Versions of packages policycoreutils depends on:
ii init-system-helpers 1.22
ii libaudit11:2.4-1+b1
ii libc62.19-13
ii libcap2 1:2.24-6
ii libdbus-1-3 1.8.14-1
ii libdbus-glib-1-2 0.102-1
ii libgcc1 1:4.9.2-10
ii libglib2.0-0 2.42.1-1
ii libpam0g 1.1.8-3.1
ii libpcre3 2:8.35-3.3
ii libselinux1 2.3-2
ii libsemanage1 2.3-1+b1
ii libsepol12.3-2
ii libstdc++6 4.9.2-10
ii lsb-base 4.1+Debian13+nmu1
ii psmisc 22.21-2
ii python 2.7.8-2
ii python-ipy 1:0.81-1
ii python-selinux 2.3-2
ii python-semanage 2.3-1+b1
ii python-sepolgen 1.2.1-1
ii python-sepolicy 2.3-1
ii python-setools 3.3.8-3.1
ii selinux-utils2.3-2
Versions of packages policycoreutils recommends:
pn python-audit
ii selinux-policy-default 2:2.20140421-7.2
Versions of packages policycoreutils suggests:
ii selinux-policy-dev 2:2.20140421-7
-- Configuration Files:
/etc/init.d/mcstrans [Errno 13] Permission denied: u'/etc/init.d/mcstrans'
/etc/init.d/restorecond [Errno 13] Permission denied: u'/etc/init.d/restorecond'
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774366: also on wheezy
On Tue, Jan 06, 2015 at 12:23:47PM +0100, Nicolas wrote: > >2015-01-06 12:14 GMT+01:00 Holger Levsen : > >> control: tags -1 moreinfo >> >> Hi, >> >> thanks for your bug report. Do you know (or can find out) whether this also >> happens on wheezy? > >I can patch but I'm afraid pLoader is more maintained by upstream. >Should we remove it from debian ? Agreed. I've dug into this bug, and I can tell you the exact problem. ploader is using libwx-perl, and newer versions of libwx-perl are no longer exposing the ParseDate() method from the WxWidgets library underneath. This changed when WxWidgets went to version 2.9 - see the code in libwx-perl-0.9923/ext/datetime/XS/DateTime.xsp. It probably wouldn't be too hard to fix this particular bug, but: * I agree that upstream doesn't look very active at all * the copyright file is currently also RC-buggy (the link http://piwigo.org/ext/download.php?eid=269 currently returns a copy of pLoader-1.5_ubuntu.tar.gz, *not* 1.6 of anything, and I don't see any mention of 1.6 anywhere either. * there are only a tiny number of users AFAICS It's up to you as the maintainer, but I'd be very tempted to file for removal at this point. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
On Sat, 17 Jan 2015 22:57:07 +, Jonathan Wiltshire wrote: > I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. This looks very similar to the NMU I uploaded a few hours ago :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Bug#737789: Cannot reproduce this bug
tags 737789 moreinfo thanks When I apt-get install angband 3.3.2-2.1, I see three icons appearing in my gnome3 applications menu: angband(GTK) angband(X11) angband(SDL) All three have the same "Mr Att" icon (an @ symbol wearing a cap). Please could you explain in more detail on which menu of which platform or window manager the icons are missing. Thanks, Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
Control: tag -1 + patch pending
Dear maintainer,
I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
diff -Nru lirc-0.9.0~pre1/debian/changelog lirc-0.9.0~pre1/debian/changelog
--- lirc-0.9.0~pre1/debian/changelog 2014-09-11 10:18:21.0 +0100
+++ lirc-0.9.0~pre1/debian/changelog 2015-01-17 18:54:58.0 +
@@ -1,3 +1,11 @@
+lirc (0.9.0~pre1-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix unhandled symlink_to_dir conversion on
+/usr/share/doc/lirc-x (Closes: #774867)
+
+ -- Jonathan Wiltshire Sat, 17 Jan 2015 18:54:56 +
+
lirc (0.9.0~pre1-1.1) unstable; urgency=low
* Non-maintainer upload with maintainers permission.
diff -Nru lirc-0.9.0~pre1/debian/control lirc-0.9.0~pre1/debian/control
--- lirc-0.9.0~pre1/debian/control 2014-09-11 10:17:10.0 +0100
+++ lirc-0.9.0~pre1/debian/control 2015-01-17 18:55:20.0 +
@@ -42,6 +42,7 @@
Package: lirc-x
Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
${misc:Depends},
lirc (= ${binary:Version})
diff -Nru lirc-0.9.0~pre1/debian/lirc-x.maintscript lirc-0.9.0~pre1/debian/lirc-x.maintscript
--- lirc-0.9.0~pre1/debian/lirc-x.maintscript 1970-01-01 01:00:00.0 +0100
+++ lirc-0.9.0~pre1/debian/lirc-x.maintscript 2015-01-17 18:56:34.0 +
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/lirc-x /usr/share/doc/lirc 0.9.0~pre1-1.2~
signature.asc
Description: Digital signature
Bug#775608: shutdown-at-night: fails to shut down the system if gdm3 is used
Package: shutdown-at-night
Version: 0.14
Severity: important
Tags: patch
The gdm3 greeter seems to be a special gnome-session running as a user
with name '(unknown)'. shutdown-at-night uses 'who' to decide if users
are still active but doesn't recognize this very case.
The patch has been tested and commited to git.
(wheezy is affected as well, version: 0.10+deb7u2)
diff --git a/shutdown-at-night b/shutdown-at-night
index 4427ef7..9411014 100755
--- a/shutdown-at-night
+++ b/shutdown-at-night
@@ -98,7 +98,7 @@ prepare_wakeonlan() {
# Return true if local user is logged in, false otherwise
is_local_user() {
-if [ "$(who)" ] ; then
+if [ "$(who | grep -v '\(unknown\)')" ] ; then
return 0
else
return 1
Wolfgang
signature.asc
Description: Digital signature
Bug#775591: [src:linux] AUFS missing from 3.18.0 kernel => Docker 10x slower
reassign 775591 docker.io thanks On Sat, Jan 17, 2015 at 10:43:23PM +, Ben Hutchings wrote: > Control: reassign -1 docker > Control: retitle -1 Docker should support overlayfs as alternative to aufs > > On Sat, 2015-01-17 at 21:45 +0200, Török Edwin wrote: > > Package: src:linux > > Version: 3.18-1~exp1 > > Severity: normal > > > > --- Please enter the report below this line. --- > > Using linux-image-3.18.0-trunk-amd64 I noticed that AUFS is missing from > > /proc/filesystems. > > This causes Docker to slow down even 10x in some situations: > > https://github.com/docker/docker/issues/10161 > > Please consider enabling AUFS again. > > No, we don't like carrying out-of-tree patches. Docker should support > the union filesystem that is in the mainline kernel tree. It's docker.io instead of docker. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775591: [src:linux] AUFS missing from 3.18.0 kernel => Docker 10x slower
Control: reassign -1 docker Control: retitle -1 Docker should support overlayfs as alternative to aufs On Sat, 2015-01-17 at 21:45 +0200, Török Edwin wrote: > Package: src:linux > Version: 3.18-1~exp1 > Severity: normal > > --- Please enter the report below this line. --- > Using linux-image-3.18.0-trunk-amd64 I noticed that AUFS is missing from > /proc/filesystems. > This causes Docker to slow down even 10x in some situations: > https://github.com/docker/docker/issues/10161 > Please consider enabling AUFS again. No, we don't like carrying out-of-tree patches. Docker should support the union filesystem that is in the mainline kernel tree. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#775607: libxine2-xvdr: Freezing of vdr-sxfe/vdr-fbfe with trap divide error
Package: libxine2-xvdr Version: 1.1.0-1+b3 Severity: important Hallo maintainers, I prepare new version of software to my TV box based on jessie packages using VDR and DVB-T card. Stable version of this box runs well for years, so thank you for your work. Trying jessie with VDR version 2.0 brings me a problem. Watching of selected channels is impossible - during 1 or 2 minutes screen is broken (squares on screen looking like poor DVB-T signal), pictures are stopped and then skip to actual picture, then after some random time program stops. Syslog contains following message about trap divide error in xineplug_inp_xvdr.so (more messages included for better identification of problem): Jan 17 22:01:09 tvnext systemd[1306]: Starting Paths. Jan 17 22:01:09 tvnext systemd[1306]: Reached target Paths. Jan 17 22:01:09 tvnext systemd[1306]: Starting Timers. Jan 17 22:01:09 tvnext systemd[1306]: Reached target Timers. Jan 17 22:01:09 tvnext systemd[1306]: Starting Sockets. Jan 17 22:01:09 tvnext systemd[1306]: Reached target Sockets. Jan 17 22:01:09 tvnext systemd[1306]: Starting Basic System. Jan 17 22:01:09 tvnext systemd[1306]: Reached target Basic System. Jan 17 22:01:09 tvnext systemd[1306]: Starting Default. Jan 17 22:01:09 tvnext systemd[1306]: Reached target Default. Jan 17 22:01:09 tvnext systemd[1306]: Startup finished in 21ms. Jan 17 22:01:11 tvnext vdr: [555] [xine..put] Client 0 connected: 192.168.9.19:35283 Jan 17 22:01:11 tvnext vdr: [555] loading /var/lib/vdr/plugins/xineliboutput/allowed_hosts.conf Jan 17 22:01:11 tvnext vdr: [555] [xine..put] cxSocket: setsockopt(SO_SNDBUF): got 262144 bytes Jan 17 22:01:11 tvnext vdr: [555] [xine..put] Trying PIPE connection ... Jan 17 22:01:11 tvnext vdr: [555] creating directory /var/lib/vdr/plugins/xineliboutput/pipes.512 Jan 17 22:01:11 tvnext vdr: [555] removing /var/lib/vdr/plugins/xineliboutput/pipes.512 Jan 17 22:01:11 tvnext vdr: [555] [xine..put] cBackgroundWriterI initialized (buffer 2048 kb) Jan 17 22:01:11 tvnext vdr: [555] [xine..put] cTcpWriter initialized (buffer 2048 kb) Jan 17 22:01:11 tvnext vdr: [555] [xine..put] Pipe open Jan 17 22:07:08 tvnext kernel: [11931.174789] traps: vdr-sxfe[1382] trap divide error ip:7f76ca33e08e sp:7f76b7d5dce0 error:0 in xineplug_inp_xvdr.so[7f76ca32d000+27000] Jan 17 22:07:08 tvnext vdr: [555] [xine..put] Client connection 0 closed Jan 17 22:07:08 tvnext vdr: [1379] [xine..put] cBackgroundWriter: TCP write error Jan 17 22:07:08 tvnext vdr: [1379] [xine..put](ERROR (tools/backgroundwriter.c,247): Roura přerušena (SIGPIPE)) Jan 17 22:07:08 tvnext vdr: [555] [xine..put] Closing connection 0 In the past I've found similar message with Play Buffer overflow before, I'll append this for information, but it seems that this error message is not relevant to this problem (today no such message occurs). Dec 21 01:41:02 tvnext vdr: [1348] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE) Dec 21 01:41:02 tvnext vdr: [1348] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE) Dec 21 01:41:02 tvnext vdr: [1348] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE) Dec 21 01:41:02 tvnext kernel: [ 5717.662270] traps: vdr-sxfe[1258] trap divide error ip:7ffb9fbe208e sp:7ffb9e5a7ce0 error:0 in xineplug_inp_xvdr.so[7ffb9fbd1000+27000] Dec 21 01:41:02 tvnext vdr: [539] [xine..put] Client connection 0 closed Dec 21 01:41:02 tvnext vdr: [1255] [xine..put] cBackgroundWriter: TCP write error Dec 21 01:41:02 tvnext vdr: [1255] [xine..put](ERROR (tools/backgroundwriter.c,247): Chybný popisovač souboru) Dec 21 01:41:02 tvnext vdr: [539] [xine..put] Closing connection 0 Installing sid version of xineliboutput-sxfe, xineliboutput-fbfe and libxine2-xvdr doesn't help. When I access TV box from my workstation (Debian wheezy, usually updated to last version with security packages) it works without problems. When I try to install wheezy version of these 3 packages (with some neccessary libraries) from stable repository, problem disappear. But I think it is not too comfortable to use older version of client packages (for mainstream users) and I hope it will not be big problem to find why this error occurs in new version of library and it will be fixed soon. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxine2-xvdr depends on: ii libavutil54 6:11.1-1 ii libc62.19-13 ii libxine2 1.2.6-1+b2 ii libxine2-ffmpeg 1.2.6-1+b2 libxine2-xvdr recommends no packages. libxine2-xvdr suggests no packages. -- no debconf information Thank you for your help, Pavel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.
Bug#775176: please manage address/port listenings with the conf.d snippets system or something similar
retitle 775176 please manage address/port listenings with the conf.d snippets system or something similar stop On Sat, 2015-01-17 at 13:51 +0100, Harald Dunkel wrote: > This bug report is about the files provided with the package. All > I'm asking for is using a2enconf instead of ports.conf. I've understood that (and I corrected the title accordingly, since that implied something completely different)... So I did some tests just now, and unlike to what I was sure myself before, it *does* work, that you remove e.g. Listen foo:80, and still have Vhosts enabled which are configured for foo:80. Sorry for not having correctly verified that earlier. Therefore taking that back and claiming the opposite ;-) So you were right in that matter, one can actually make the Listen like a feature one disables/enables. At least the vhosts will continue to work, but just those where one still has listeners (e.g. on 443) will answer. I have *not* checked though, whether it works with all other places in apache, which refer to internal ports/addresses ... e.g. there *may* be directives, which reference port 80, and that simply make daemon start fail when that is no longer listening. Now with respect to your request: In principle you can implement this already now: Just empty ports.conf and add your Listen statement to e.g. conf.d snippets... > I'm OK with > having a single file for both ports. ... but of course the above only makes sense when you have multiple ports.conf like files, e.g. a2en/dis http.conf a2en/dis https.conf a2en/dis svn.conf ...where each of them contains the Listen directive's for one of these protocols. Whether this makes sense in practical usage is another question,... I for example configure my sites to do what I want, and if I don't want the to listen on http, I just don't configure them to do so,.. or I set up an (insecure) redirect to https. And if I'd have no http altogether (in all my sites), THEN I'd remove the Listen line from ports.conf But I'd never switch one or the other on/off on a regular/daily basis. So for me personally(!!) it wouldn't make that much sense, and I still think the handling should stay as it is... ...because, what definitely doesn't work (at least up to until Apache 2.2) is that you have the same Listen statement multiple times. So you cannot just add these to the sites configs (conceptually). So right now I think it makes more sense to take ports.conf as the single file that handles the listeners. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#775606: ITP: golang-codegangsta-cli -- small package for building Go command-line tools
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: golang-codegangsta-cli Version : 0.0 Upstream Author : Jeremy Saenz * URL : https://github.com/codegangsta/cli * License : MIT Programming Lang: Go Description : small package for building Go command-line tools cli.go is simple library for building command line apps in Go. It allows is writing fast and distributable command line applications in an expressive way. (cli.go is a dependency for etcd) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770090: systemd: systemctl poweroff doesn't poweroff
Hi again, I've found this site and followed the steps to try to debug the problem: http://freedesktop.org/wiki/Software/systemd/Debugging/ This is the output of dmesg during shutdown: [ 6792.054805] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING) [ 6792.068552] cfg80211: Calling CRDA to update world regulatory domain [ 6792.102857] systemd[1]: lightdm.service: main process exited, code=exited, status=1/FAILURE [ 6792.103138] systemd[1]: Unit lightdm.service entered failed state. [ 6792.177885] cfg80211: World regulatory domain updated: [ 6792.177889] cfg80211: DFS Master region: unset [ 6792.177891] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 6792.177893] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 6792.177896] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 6792.177898] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 6792.177900] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 6792.177902] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 6792.177904] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 6792.177906] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 6792.177908] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 6792.178140] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 6792.576545] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 6797.460556] systemd[1]: systemd-cryptsetup@sda2_crypt.service: control process exited, code=exited status=1 [ 6797.461659] systemd[1]: Unit systemd-cryptsetup@sda2_crypt.service entered failed state. [ 6797.470527] systemd[1]: Shutting down. [ 6797.505107] watchdog watchdog0: watchdog did not stop! [ 6797.557957] systemd-journald[239]: Received SIGTERM from PID 1 (systemd-shutdow). [ 6797.953759] EXT4-fs (dm-3): re-mounted. Opts: (null) [ 6797.962966] EXT4-fs (dm-3): re-mounted. Opts: (null) [ 6797.962971] EXT4-fs (dm-3): re-mounted. Opts: (null) [ 6797.984081] systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy [ 6797.984258] systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy [ 6798.060431] EXT4-fs (dm-3): re-mounted. Opts: (null) /dev/dm-0 is my encrypted partition, which contains my root, home and swap file-systems (lvm). I'm using Debian's default full-disk encryption scheme. systemd-cryptsetup@sda2_crypt.service is an auto-generated .service file which just invokes this on service stop: /lib/systemd/systemd-cryptsetup detach 'sda2_crypt' According to systemd's source, that command should print some error messages: https://github.com/systemd/systemd/blob/b9e616cc2256501f484f138999ec63a0094f5c4f/src/cryptsetup/cryptsetup.c But I don't see any of those on my dmesg log, even though I enabled debug output in systemd via kernel params: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 Any ideas about what else I could try to debug further? Kind regards, Francesc
Bug#762709: ca-certificates: Import http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt Root CA certificate which is missing
Control: tags -1 + pending On 10/06/2014 05:23 PM, Michael Shuler wrote: Do I understand this chain correctly to be the new root: CN=USERTrust RSA Certification Authority which is currently open for inclusion into Mozilla? mozilla.org: Status: ASSIGNED - https://bugzilla.mozilla.org/show_bug.cgi?id=606947 NSS: Status: NEW - https://bugzilla.mozilla.org/show_bug.cgi?id=1062589 PSM: Status: NEW - https://bugzilla.mozilla.org/show_bug.cgi?id=1062600 Marking bug as pending upload, since Mozilla has included this CA in the NSS dev tree as version 2.2 and I've imported. The Mozilla bug status remains the same, since NSS has not released this version to production. Once this CA bundle version is released in NSS, this will be uploaded to Debian. http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/commit/?id=36e9bdc2a3fce7c0633b839ae311b611901cec4a -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775508: unace-nonfree: BASE_MEMORY_InitMaxAllocate is slow
* Fabian Greffrath , 2015-01-17, 12:48: Please consider making this faster. BASE_MEMORY_EXTERN_MaxMemoryRequirement() returns 16MB, which is not much these days, so perhaps you could just set: So, you propose to comment out the entire while() loop and just set BASE_MEMORY.MaxAllocate = BASE_MEMORY_EXTERN_MaxMemoryRequirement(); instead of BASE_MEMORY.MaxAllocate = Size; right? That's right. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775504: unace-nonfree: broken when built with noopt
* Fabian Greffrath , 2015-01-17, 12:41: I rebuilt unace-nonfree with DEB_BUILD_OPTIONS=noopt, and now the binary segfaults all the time: [...] I couldn't get unace not to crash with your fuzzed archive when it was built without optimization but with -fpie. Is this somehow related? It's not unusual that changing optimization options hides memory bugs. But other than that, I don't think they're related. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
