Bug#731547: Accepted upstream
Hi! The patch is accepted upstream: https://git.gnome.org/browse/glib/commit/?id=f7b13e05f9bc5bd2b54f589d16ad580f6d833173 Can we now have a Debian build with the patch applied??!! Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#784567: intent to NMU sysvinit really soon -- followup fix
I noticed something strange when I upgraded my sid chroot for the first time in a while. I only used 'apt-get upgrade', and the util-linux and most sysvinit packages were held back: The following packages have been kept back: cpp-4.8 cpp-4.9 g++-4.9 gcc-4.8 gcc-4.8-base gcc-4.9 gcc-4.9-base git-buildpackage initscripts libasan0 libasan1 libatomic1 libavcodec-dev libavcodec56 libavformat-dev libavformat56 libavresample-dev libavresample2 libavutil-dev libavutil54 libcilkrts5 libcloog-isl4 libgcc-4.8-dev libgcc-4.9-dev libgcc1 libgfortran3 libglib2.0-0 libglib2.0-bin libgomp1 libgphoto2-6 libitm1 liblist-moreutils-perl liblsan0 libpam-systemd libpcre3 libpcre3-dev libpcrecpp0 libquadmath0 libsane libsane-common libstdc++-4.9-dev libstdc++6 libsystemd0 libtsan0 libubsan0 rsyslog systemd sysvinit-utils util-linux virtualbox virtualbox-qt vmdebootstrap But even then, I saw this unexpected message at the end of the upgrade: Running hooks in /etc/ca-certificates/update.d... /etc/ca-certificates/update.d/jks-keystore: 33: /etc/ca-certificates/update.d/jks-keystore: mountpoint: not found the keytool command requires a mounted proc fs (/proc). E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. I guess things will improve with a dist-upgrade, but this tell me the ordering of dependencies/breaks is not quite right. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786763: redmine: error messages during update of ruby-rails packages
Control: reassign -1 redmine On 2015-05-29 12:49, Antonio Terceiro wrote: > Control: reassign -1 dpkg > Hi Antonio, > On Mon, May 25, 2015 at 02:07:37PM +0200, Jörg-Volker Peetz wrote: >> Antonio Terceiro wrote on 05/25/2015 13:48: >> >> >>> I'm sorry but I cannot see what is the problem; did you forget to >>> include the actual error messages? >>> >> Hi Antonio, >> >> it's further down: >> >> [...] > > That looks like a problem in dpkg. Did you try upgrading dpkg before > upgrading the rest of the system? Or trying again after the above > happened? > The output from dpkg suggests redmine has an /awaiting/ trigger cycle. In particular, on itself? Indeed, redmine has the following triggers: """ interest /usr/share/redmine/plugins interest /usr/lib/ruby/vendor_ruby """ (From http://anonscm.debian.org/cgit/pkg-ruby-extras/redmine.git/tree/debian/redmine.triggers) If possible, please consider switching these to noawait variants (though note that noawait may defer the trigger a bit longer). Alternatively, if noawait triggers do not provide enough guarantees, you may have to replace the interest triggers all together. Please note that: * No package /depending/ on redmine can use an "await" trigger. If they do, it will lead to a trigger cycle. Please see man 5 deb-triggers for more information. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787232: bsdutils depends on systemd
Package: bsdutils Version: 1:2.20.1-5.3 Severity: critical Justification: breaks the whole system bsdutils depends on systemd and can not be installed on an uninfested Debian system -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages bsdutils depends on: ii libc6 2.13-38+deb7u7 Versions of packages bsdutils recommends: ii bsdmainutils 9.0.3 bsdutils suggests no packages. -- debconf-show failed -- debsums errors found: dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 54291 package 'cnews': error in Version string 'cr.g7-40.4': version number does not start with digit dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 54291 package 'cnews': error in Version string 'cr.g7-40.4': version number does not start with digit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787230: python-toposort: clobbers Python standard library ‘test’ package
Package: python-toposort Version: 1.1-1 Severity: normal Dear Maintainer, The package ‘python-toposort’ installs a top-level ‘test’ package. This clobbers the Python standard library ‘test’ package. Instead, the ‘python-toposort’ package should install its ‘test’ Python package into a private directory for the package, perhaps under ‘/usr/share/python-toposort/’. (This report applies equally to ‘python3-toposort’, I believe.) -- \“The World is not dangerous because of those who do harm but | `\ because of those who look at it without doing anything.” | _o__) —Albert Einstein | Ben Finney signature.asc Description: Digital signature
Bug#787231: mktemp: failed to create directory via template ‘/var/tmp/mkinitramfs_XXXXXX
Package: initramfs-tools
Version: 0.120
Severity: normal
Tags: patch
Dear Maintainer,
First of all, thank you very much for maintaining
Debain's initramfs-tools package.
I love to see generous and civic minded people.
When I was upgrading the kernel with
$ aptitude install linux-image-686-pae
I happened to notice that it failed with
The following partially installed packages will be configured:
linux-image-4.0.0-1-686-pae linux-image-686-pae
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 2486 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up linux-image-4.0.0-1-686-pae (4.0.2-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.0.0-1-686-pae
mktemp: failed to create directory via template
‘/var/tmp/mkinitramfs_XX’: No such file or directory
update-initramfs: failed for /boot/initrd.img-4.0.0-1-686-pae with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at
/var/lib/dpkg/info/linux-image-4.0.0-1-686-pae.postinst line 634.
dpkg: error processing package linux-image-4.0.0-1-686-pae (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-686-pae:
linux-image-686-pae depends on linux-image-4.0.0-1-686-pae; however:
Package linux-image-4.0.0-1-686-pae is not configured yet.
So the kernel wasn't upgraded.
I believe the problem is that the /var/tmp/
directory did not exist.
Since /var/tmp is specified in Debian's Filesystem
Hierarchy Standard[1], it seems to me that it was
somehow deleted.
However, I have no clue as to who, what, when,
where or how.
/var/tmp was also reported to be missing in bug
report #696771[2], so it's not just me.
Humble suggestion:
Since /var/tmp is specified in our FHS, is
required to update the kernel, and is being
deleted, patch /usr/sbin/mkinitramfs to check if
it exists, and if it doesn't, create it.
Here's a patch.
I hope it makes sense, and is in an acceptable
format.
--- /usr/sbin/mkinitramfs 2015-03-01 15:18:25.0 -0800
+++ /tmp/mkinitramfs2015-05-29 21:53:16.420497308 -0700
@@ -162,6 +162,10 @@
if [ ! -e "${MODULESDIR}/modules.dep" ]; then
depmod ${version}
fi
+#
/var/tmp is specified in the Filesystem Hierarchy Standard.
+if ! test -d /var/tmp ; then#
Does it exist?
+mkdir -m 1777 /var/tmp
# No, so create it.
+fi
[ -n "${TMPDIR}" ] && [ ! -w "${TMPDIR}" ] && unset TMPDIR
DESTDIR="$(mktemp -d ${TMPDIR:-/var/tmp}/mkinitramfs_XX)" || exit 1
Thanks,
Kingsley
References
[1] Debian's Filesystem Hierarchy Standard for
/var/tmp
https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE
[2] Debian bug report #696771
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696771
-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root disk 6.0M Aug 12 2011 /boot/initrd.img-2.6.18-4-k7
-rw-r--r-- 1 root disk 6.8M Aug 12 2011 /boot/initrd.img-2.6.25-2-686
-rw-r--r-- 1 root disk 6.8M Mar 11 2010 /boot/initrd.img-2.6.25-2-686.bak
-rw-r--r-- 1 root disk 8.3M Aug 12 2011 /boot/initrd.img-2.6.32-5-686
-rw-r--r-- 1 root disk 8.0M Feb 10 2011 /boot/initrd.img-2.6.32-5-686.bak
-rw-r--r-- 1 root disk 11M May 25 15:23 /boot/initrd.img-3.0.0-1-686-pae
-rw-r--r-- 1 root disk 15M May 27 14:06 /boot/initrd.img-4.0.0-1-686-pae
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-686-pae
root=UUID=a9792df8-2513-4185-bb81-589f5f9d508d ro quiet
-- resume
RESUME=/dev/hdc3
-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat
-- lsmod
Module Size Used by
nls_utf8 16384 1
nls_cp437 16384 1
vfat 20480 1
fat57344 1 vfat
usb_storage45056 1
ipheth 16384 0
snd_hrtimer16384 1
binfmt_misc20480 1
nf_log_ipv416384 3
nf_log_common 16384 1 nf_log_ipv4
xt_LOG 16384 3
iptable_mangle 16384 0
iptable_filter 16384 1
iptable_nat16384 0
ip_tables 20480 3 iptable_filter,iptable_mangle,iptable_nat
nf_conntrack_ipv4 20480 1
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
nf_nat_ipv416384 1 iptable_nat
nf_nat 20480 1 nf_nat_ipv4
nf_conntrack 73728 3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
x_tables 20480 4 ip_tables,xt_LOG,iptable_filter,iptable_mangle
bridge 94208 0
stp16384 1 bridge
llc
Bug#787095: texlive-latex-extra: Example tex file for pdfcomment.sty does not build
The upstream maintainer has commented on the issue: the root of the issue seems to be some unfortunate interaction with the microtype and zref packages. Not loading the microtype package (which is not used anyway) will fix the issue. The maintainer promised to do this for some upcoming bugfix release. signature.asc Description: OpenPGP digital signature
Bug#715048: Patch to add support for an indpendendent initramfs networking config
On Fri, 29 May 2015 19:30:35 +0200 Guilhem Moulin wrote: > > The problem is that, while klibc can bring up and down network > > interfaces, the interface configuration does not go away. > > What doesn't go away exactly? (What do you mean by “interface > configuration”?) I wonder if ip(8) could help, by the way. It's > included in the initrd, can flush routes (‘ip addr flush dev $DEVICE’) > and bring down interfaces (‘ip link set dev $DEVICE down’). The thing to try would be to change line 43 of the original patch from using ipconfig to using ip and doing a flush. (Of course you'd have to use a patched klibc.) Or maybe adding a flush after the ipconfig brings the interface down. Hopefully this would remove the old "boot-temporary" ip netmask, routes, etc. and leave the interface "clean" and ready to get it's normal configuration. Unfortunately I just don't have time right now to try this. Any help would be appreciated. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787229: xen-hypervisor-4.4-amd64: xl command hangs on Dell R720
Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9 Severity: grave Justification: renders package unusable Hi, I was running Debian Wheezy (amd64) and xen-hypervisor 4.1 on a Dell PowerEdge R720. Xen was working fine. Xen was configured with LVM Now, I'm trying Debian Jessie (amd64) and I have a strange problem. After booting, Xen seems to be working : /etc/init.d/xen status ● xen.service - LSB: Xen daemons Loaded: loaded (/etc/init.d/xen) Active: activating (start) since sam. 2015-05-29 23:20:50 CEST; 33s ago Control: 1150 (xen) CGroup: /system.slice/xen.service ├─1150 /bin/sh /etc/init.d/xen start └─1229 xenstore-write /local/domain/0/name Domain-0 mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs xenstored mai 29 22:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. mai 29 23:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. When I try to run a simple 'xl list' : I got this in console : root@jango:~# xl list NameID Mem VCPUs State Time(s) The cursor is blinking, nothing happens. I have not touched any config files yet. (/etc/xen contains default config files). /var/log/xen is empty. In /var/log/syslog, I got this : May 29 23:28:01 jango kernel: [ 245.721670] INFO: task xl:1440 blocked for more than 120 seconds. May 29 23:28:01 jango kernel: [ 245.721780] Not tainted 3.16.0-4-amd64 #1 May 29 23:28:01 jango kernel: [ 245.721872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 29 23:28:01 jango kernel: [ 245.721973] xl D 8807ee86a528 0 1440 1425 0x May 29 23:28:01 jango kernel: [ 245.721981] 8807ee86a0d0 0286 00012f00 8800bc41bfd8 May 29 23:28:01 jango kernel: [ 245.721985] 00012f00 8807ee86a0d0 81adaf70 8800bc41be48 May 29 23:28:01 jango kernel: [ 245.721989] 81adaf74 8807ee86a0d0 81adaf78 May 29 23:28:01 jango kernel: [ 245.721994] Call Trace: May 29 23:28:01 jango kernel: [ 245.722007] [] ? schedule_preempt_disabled+0x25/0x70 May 29 23:28:01 jango kernel: [ 245.722012] [] ? __mutex_lock_slowpath+0xd3/0x1c0 May 29 23:28:01 jango kernel: [ 245.722019] [] ? remove_wait_queue+0x12/0x50 May 29 23:28:01 jango kernel: [ 245.722023] [] ? mutex_lock+0x1b/0x2a May 29 23:28:01 jango kernel: [ 245.722029] [] ? xenbus_dev_request_and_reply+0x25/0xb0 May 29 23:28:01 jango kernel: [ 245.722034] [] ? xenbus_file_write+0x27e/0x540 May 29 23:28:01 jango kernel: [ 245.722041] [] ? __sb_start_write+0x42/0xd0 May 29 23:28:01 jango kernel: [ 245.722047] [] ? vfs_write+0xb2/0x1f0 May 29 23:28:01 jango kernel: [ 245.722053] [] ? SyS_write+0x42/0xa0 May 29 23:28:01 jango kernel: [ 245.722058] [] ? system_call_fast_compare_end+0x10/0x15 I tried with xen-hypervisor 4.5 with no luck. I tried with linux-image-4. from unstable with no luck. xl info command output : host : jango release: 3.16.0-4-amd64 version: #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) machine: x86_64 nr_cpus: 32 max_cpu_id : 47 nr_nodes : 2 cores_per_socket : 8 threads_per_core : 2 cpu_mhz: 2400 hw_caps: bfebfbff:2c100800::3f00:17bee3ff::0001: virt_caps : hvm hvm_directio total_memory : 32722 free_memory: 127 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version: 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder cc_compiler: gcc (Debian 4.9.2-10) 4.9.2 cc_compile_by : waldi cc_compile_domain : debian.org cc_compile_date: Mon Apr 6 18:24:28 UTC 2015 xend_config_format : 4 Unfortunatly, this server is not a test server, so I'll have to reinstall wheezy. Have you any clue about this problem ? Is there anything I can test to debug this ? Thanks a lot. Benoit -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#738478: pngcrush maintenance
With regret, I do not have time to take that on right now, and I'm not using pngcrush anymore myself, either. On Fri, May 29, 2015 at 8:25 AM, Dmitry Smirnov wrote: > Hi Zack, > > According to #738478 [1] the position of "pngcrush" maintainer is vacant. > I shall be happy to sponsor your work if you are willing to step in. > > Nelson, are you still interested/able to work on "pngcrush"? > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738478 > > -- > All the best, > Dmitry Smirnov > GPG key : 4096R/53968D1B > > --- > > Success consists of going from failure to failure without loss of enthusiasm. > -- Winston Churchill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775242: gnome-clocks: Uses ridiculous amount of CPU time for timer and stop watch
forwarded 775242 https://bugzilla.gnome.org/show_bug.cgi?id=738469 thanks This bug has been reported upstream by Michael Biebl a few months before I submitted my bug report. So let's just use his report as the forwarded address. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, hello Detrick, Am 29.05.2015 um 22:02 schrieb Fabian Greffrath: >> I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: > is this on a fresh Jessie install? Is a Jessie-Testing installation from 30th November 2014. At least upgraded to the latest (Jessie) versions 20 days ago. >> (amd64 did not show the fault) > Ack, I couldn't reproduce it on my amd64 system as well. I tried a little further and was able to reproduce the crash in a "Jessie i386 chroot" on a 64bit-kernel too, so probably we can rule out a qemu bug. (Had proc not bind-mounted into chroot.) >> (gdb) bt >> #0 0xb76e30c9 in init_xrpow_core_sse () from >> /usr/lib/i386-linux-gnu/libmp3lame.so.0 > So, this seems to be a bug in SSE code. Which means that either the code > itself is buggy or your system does not support SSE instructions at all > (though the latter should throw a SIGILL instead of a SIGSEGV). => 0xb76df6c9 :movaps %xmm0,0x20(%esp) Yes, this "movaps" seems to be a SSE instruction. Also the changes in the previous patch "should" not change the instructions but only the alignment of the memory the instructions operate on. And if that is the case, with proper alignment it is working. But probably there is a better way to convince gcc to align the memory ... > Would both of you please tell my the content of /proc/cpuinfo? In the qemu VM (qemu-system-x86_64 --enable-kvm -cpu host): benutzer@debian:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 microcode : 0x165 cpu MHz : 2600.000 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow extd_apicid pni cx16 x2apic hypervisor lahf_lm cmp_legacy svm cr8_legacy 3dnowprefetch vmmcall bogomips: 5200.00 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: On the host not inside chroot: root@rechner:/home/bernhard# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 cpu MHz : 2600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv vmmcall bogomips: 5223.84 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps (the same for the second core) Kind regards, Bernhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738478: pngcrush maintenance
On Fri, 29 May 2015 22:59:32 Zack Weinberg wrote: > With regret, I do not have time to take that on right now, and I'm not > using pngcrush anymore myself, either. No worries and thanks for your reply. It may be hard to maintain stuff that you are not using but "pngcrush" needs only little maintenance so it probably won't take much time from anyone who decides to look after it. -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#786851: maildrop: reformime -r8 is supposed to convert Q-P to 8bit
I have included two samples of QP: One ending with .ms abuses QP to conceal long lines. (The .ms is for MicroSoft not groff -ms which I like.) This is not converted to 8bit. One ending with .qp uses QP to encapsulate human readable plaintext. (This encoding would only be useful where you really did have a channel that was only 7bit clean and wished to send 8bit text.) This is was converted to 8bit. The problem with MicroSoft text is that long lines exceed the 78 or 80 chracater limit of plaintext and also opften exceed the 998 octet limit of SMTP. However I have never seen 7bit or 998 octet limits with MTAs in the wild. The simple solution would be to always convert to 8bit. The real problem with MicroSoft text is that long lines are hard to read. QP is abused to hide such text from content filters. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam= lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra= nec consectetur ante hendrerit. Donec et mollis dolor. Praesent et diam= eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim,= ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula= ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing= elit. Aenean ut gravida lorem. Ut turpis felis, pulvinar a semper sed,= adipiscing id dolor. Pellentesque auctor nisi id magna consequat sagittis.= Curabitur dapibus enim sit amet elit pharetra tincidunt feugiat nisl= imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio= eros. Donec viverra mi quis quam pulvinar at malesuada arcu rhoncus. Cum= sociis natoque penatibus et magnis dis parturient montes, nascetur= ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi at sem= facilisis semper ac in est. Vivamus fermentum semper porta. Nunc diam velit, adipiscing ut tristique= vitae, sagittis vel odio. Maecenas convallis ullamcorper ultricies.= Curabitur ornare, ligula semper consectetur sagittis, nisi diam iaculis= velit, id fringilla sem nunc vel mi. Nam dictum, odio nec pretium volutpat,= arcu ante placerat erat, non tristique elit urna et turpis. Quisque mi= metus, ornare sit amet fermentum et, tincidunt et orci. Fusce eget orci a= orci congue vestibulum. Ut dolor diam, elementum et vestibulum eu,= porttitor vel elit. Curabitur venenatis pulvinar tellus gravida ornare. Sed= et erat faucibus nunc euismod ultricies ut id justo. Nullam cursus suscipit= nisi, et ultrices justo sodales nec. Fusce venenatis facilisis lectus ac= semper. Aliquam at massa ipsum. Quisque bibendum purus convallis nulla= ultrices ultricies. Nullam aliquam, mi eu aliquam tincidunt, purus velit= laoreet tortor, viverra pretium nisi quam vitae mi. Fusce vel volutpat= elit. Nam sagittis nisi dui. Suspendisse lectus leo, consectetur in tempor sit amet, placerat quis= neque. Etiam luctus porttitor lorem, sed suscipit est rutrum non. Curabitur= lobortis nisl a enim congue semper. Aenean commodo ultrices imperdiet.= Vestibulum ut justo vel sapien venenatis tincidunt. Phasellus eget dolor= sit amet ipsum dapibus condimentum vitae quis lectus. Aliquam ut massa in= turpis dapibus convallis. Praesent elit lacus, vestibulum at malesuada et,= ornare et est. Ut augue nunc, sodales ut euismod non, adipiscing vitae= orci. Mauris ut placerat justo. Mauris in ultricies enim. Quisque nec est= eleifend nulla ultrices egestas quis ut quam. Donec sollicitudin lectus a= mauris pulvinar id aliquam urna cursus. Cras quis ligula sem, vel elementum= mi. Phasellus non ullamcorper urna. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per= inceptos himenaeos. In euismod ultrices facilisis. Vestibulum porta sapien= adipiscing augue congue id pretium lectus molestie. Proin quis dictum nisl.= Morbi id quam sapien, sed vestibulum sem. Duis elementum rutrum mauris sed= convallis. Proin vestibulum magna mi. Aenean tristique hendrerit magna, ac= facilisis nulla hendrerit ut. Sed non tortor sodales quam auctor elementum.= Donec hendrerit nunc eget elit pharetra pulvinar. Suspendisse id tempus= tortor. Aenean luctus, elit commodo laoreet commodo, justo nisi consequat= massa, sed vulputate quam urna quis eros. Donec vel. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectu= s. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricie= s a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean= ut gravida lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor. Pellentesque auctor nisi id magna consequat sagittis. Curabitur dapibus enim sit amet elit pharetra tincidunt feugiat nisl imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio eros. Donec viverra mi quis quam pulvinar at malesuad
Bug#787227: Acknowledgement (broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No s
FWIW, I have seen this on 2 machins: * Bannana pi, running bannanian with a Debian armel chroot * Cubietruck, running an image from https://romanrm.net/a10/debian with a Debian armel chroot In both cases, the kernel and boot system are armhf. I don't know if this nonstandard configuration has something to do with it. -- see shy jo signature.asc Description: Digital signature
Bug#787227: Acknowledgement (broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No s
Note that this bug is likely a security hole; /usr/bin/ghc loading .so files relative to the CWD could be exploted. When ghc's postinst runs ghc-pkg, it seems that dpkg does something that prevents those relative paths being used (possibly just a chdir, didn't check). So, it's at least not trivially exploitable by getting root to install ghc when root is in /tmp. -- see shy jo signature.asc Description: Digital signature
Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or direc
Package: ghc Version: 7.8.4-8 Severity: important root@honeybee:/# ghc /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or directory root@honeybee:/# ls -l /usr/lib/ghc/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.4.so -rw-r--r-- 1 root root 2105712 May 25 20:47 /usr/lib/ghc/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.4.so The problem isn't unique to this one .so file: root@honeybee:/# hsc2hs /usr/lib/ghc/bin/hsc2hs: error while loading shared libraries: libHSprocess-1.2.0.0-ghc7.8.4.so: cannot open shared object file: No such file or directory root@honeybee:/# ldd /usr/lib/ghc/bin/hsc2hs | grep libHSprocess libHSprocess-1.2.0.0-ghc7.8.4.so => /usr/lib/ghc/bin/../process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so (0xb6d9d000) root@honeybee:/# ls -l /usr/lib/ghc/process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so -rw-r--r-- 1 root root 156452 May 25 20:47 /usr/lib/ghc/process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so (Strange that ldd is able to resolve the paths to the libraries when ld-linux.so cannot..) LD_DEBUG=all hsc2hs sheds some light on the problem. Comparing with the output on amd64 and armhf, it seems that the linker is seeing a RUNPATH that has "tls/v7l/neon/vfp" in it, instead of a RUNPATH that gives the directories where the haskell libraries are. So, maybe something in the armel toolchain is overwriting the RUNPATH? Horrible workaround: Make a ./tls/v7l/neon/vfp/ directory, and copy all the libraries from ghc into it. :/ root@honeybee:/tmp# cp $(dpkg -L ghc |grep \.so) ./tls/v7l/neon/vfp/ root@honeybee:/tmp# ghc -V The Glorious Glasgow Haskell Compilation System, version 7.8.4 armhf LD_DEBUG=all excerpt: 4088: search path=/usr/lib/ghc/bin/../process-1.2.0.0:/usr/lib/ghc/bin/../directory-1.2.1.0:/usr/lib/ghc/bin/../unix-2.7.0.1:/usr/lib/ghc/bin/../time-1.4.2:/usr/lib/ghc/bin/../old-locale-1.0.0.6:/usr/lib/ghc/bin/../filepath-1.3.0.2:/usr/lib/ghc/bin/../containers-0.5.5.1:/usr/lib/ghc/bin/../bytestring-0.10.4.0:/usr/lib/ghc/bin/../deepseq-1.3.0.2:/usr/lib/ghc/bin/../array-0.5.0.0:/usr/lib/ghc/bin/../base-4.7.0.2:/usr/lib/ghc/bin/../integer-gmp-0.5.1.0:/usr/lib/ghc/bin/../ghc-prim-0.3.1.0:/usr/lib/ghc/bin/../rts-1.0 (RUNPATH from file /usr/lib/ghc/bin/hsc2hs) armel LF_DEBUG=all complete output for resolving the libHSprocess lib: 3791: file=libHSprocess-1.2.0.0-ghc7.8.4.so [0]; needed by /usr/lib/ghc/bin/hsc2hs [0] 3791: find library=libHSprocess-1.2.0.0-ghc7.8.4.so [0]; searching 3791: search path=tls/v7l/neon/vfp:tls/v7l/neon:tls/v7l/vfp:tls/v7l:tls/neon/vfp:tls/neon:tls/vfp:tls:v7l/neon/vfp:v7l/neon:v7l/vfp:v7l:neon/vfp:neon:vfp: (RUNPATH from file /usr/lib/ghc/bin/hsc2hs) 3791: trying file=tls/v7l/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=libHSprocess-1.2.0.0-ghc7.8.4.so 3791: search cache=/etc/ld.so.cache 3791: search path=/lib/arm-linux-gnueabi/tls/v7l/neon/vfp:/lib/arm-linux-gnueabi/tls/v7l/neon:/lib/arm-linux-gnueabi/tls/v7l/vfp:/lib/arm-linux-gnueabi/tls/v7l:/lib/arm-linux-gnueabi/tls/neon/vfp:/lib/arm-linux-gnueabi/tls/neon:/lib/arm-linux-gnueabi/tls/vfp:/lib/arm-linux-gnueabi/tls:/lib/arm-linux-gnueabi/v7l/neon/vfp:/lib/arm-linux-gnueabi/v7l/neon:/lib/arm-linux-gnueabi/v7l/vfp:/lib/arm-linux-gnueabi/v7l:/lib/arm-linux-gnueabi/neon/vfp:/lib/arm-linux-gnueabi/neon:/lib/arm-linux-gnueabi/vfp:/lib/arm-linux-gnueabi:/usr/lib/arm-linux-gnueabi/tls/v7l/neon/vfp:/usr/lib/arm-linux-gnueabi/tls/v7l/neon:/usr/lib/arm-linux-gnueabi/tls/v7l/vfp:/usr/lib/arm-linux-gnueabi/tls/v7l:/usr/lib/arm-linux-gnueabi/tls/neon/vfp:/usr/lib/arm-linux-gnueabi/tls/neon:/usr/lib/arm-linux-gnueabi/tls/vfp:/usr/lib/arm-linux-gnueabi/tls:/usr/lib/arm-linux-gnueabi/v7l/neon/vfp:/usr/lib/arm-linux-gnueabi/v7l/neon:/usr/lib/arm-linux-gnueabi/v7l/vfp:/usr/lib/arm-linux-gnueabi/v7l:
Bug#760003: transition: qt-gstreamer
On Thursday 28 May 2015 14:05:18 Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > > It won't hurt to upload the experimental version around the same time as > > kamoso though if you want to, since we'll have to wait for kamoso to age > > anyway. > > I'm afraid it's still not clear to me if you are referring to qapt (which > seems to have built fine) or qtgstreamer :-/ I have just understood how the situation is. The bad news are that the experimental version can't be pushed to unstable until kf5 is in it, which means waiting for Qt 5.4.2... not a solution now. **BUT** the good news are that qapt does not expose any gstreamer API, which means that even if the package names are deceptive they should just work as they already are. And that's why a simple binNMU just worked. So I would just simply keep the version in sid as it is, we will push the newer version with proper naming with kf5. Thanks a lot for your work! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#388365:
Bug#787032: More information
I made an experiment that someone else did in Archlinux, stoped gdm3 and started the x server alone calling "xinit". The server starts and shows a terminal. I can even call "nautilus" and it works. The first time I made the experiment it didn't work, it showed the terminal but I couldn't do anything, the virtual machine hanged when tried to move the mouse or write something, I was running qemu with this arguments: "-hda juana.img -m 256M -vga cirrus -net nic -net user -alt-grab -usb". When the test worked I was using this argumets: "-hda juana.img -m 256M -vga cirrus -net nic -net user -usbdevice mouse -usbdevice keyboard -alt-grab" Saludos!
Bug#787226: openshot: Open Shot: video preview and export returns saturated video
Package: openshot Version: 1.4.3-1.1 Severity: important Dear Maintainer, I think there might be some dependecies issue. To fully understand the problem, watch a screenshot here: http://i.imgur.com/sqCDkpL.png -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=es_AR.utf8, LC_CTYPE=es_AR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openshot depends on: ii fontconfig 2.11.0-6.3 ii gtk2-engines-pixbuf 2.24.25-3 ii librsvg2-common 2.40.9-2 ii melt 0.9.6-1 ii python 2.7.9-1 ii python-gtk2 2.24.0-4 ii python-httplib2 0.9+dfsg-2 ii python-imaging 2.6.1-2 ii python-mlt 0.9.6-1 ii python-pygoocanvas 0.14.1-1+b3 ii python-support 1.0.15 ii python-xdg 0.25-4 Versions of packages openshot recommends: ii frei0r-plugins 1.4-3 ii openshot-doc1.4.3-1.1 Versions of packages openshot suggests: pn blender ii inkscape 0.91-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#760847: gvfs: File copy fails with "Another operation in progress" still present in 1.22.2-1
Am 30.05.2015 um 02:17 schrieb Marcin Szewczyk: > I would like to propose a patch (attached). It's probably too primitive > and requires a rewrite to become event-driven instead of a polling > mechanism. But for me it works and I've found another polling part in > the code that was already there so maybe the quality loss isn't that big > after all ;) > > I kindly ask for a review/opinions and feedback. The obexftp backend is gone in 1.24.1-2, so this patch no longer applies. Please use obexpush and gnome-share to transfer files via Bluetooth [1]. Regards, Michael [1] http://www.hadess.net/2013/11/bluetooth-file-sharing-obexpush-in.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#760847: gvfs: File copy fails with "Another operation in progress" still present in 1.22.2-1
I would like to propose a patch (attached). It's probably too primitive
and requires a rewrite to become event-driven instead of a polling
mechanism. But for me it works and I've found another polling part in
the code that was already there so maybe the quality loss isn't that big
after all ;)
I kindly ask for a review/opinions and feedback.
--
Marcin Szewczyk http://wodny.org
mailto:marcin.szewc...@wodny.borg <- remove b / usuń b
xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl
--- gvfs-1.22.2-orig/daemon/gvfsbackendobexftp.c 2014-11-07 14:53:26.0 +0100
+++ gvfs-1.22.2/daemon/gvfsbackendobexftp.c 2015-05-30 02:08:30.592912133 +0200
@@ -1329,11 +1329,18 @@
{
GVfsBackendObexftp *op_backend = G_VFS_BACKEND_OBEXFTP (backend);
GError *error = NULL;
+ gboolean busy = TRUE;
g_debug ("+ do_query_info, filename: %s\n", filename);
g_mutex_lock (&op_backend->mutex);
+ while (busy > 0)
+{
+ busy = is_busy (op_backend->session_proxy, G_VFS_JOB (job));
+ g_usleep (G_USEC_PER_SEC / 100);
+}
+
if (_query_file_info_helper (backend, filename, info, &error) == FALSE)
{
g_mutex_unlock (&op_backend->mutex);
Bug#782543: ITP: gpaw -- DFT and beyond within the projector-augmented wave method
Hi, On 05/05/2015 03:49 PM, Andreas Tille wrote: On Mon, May 04, 2015 at 05:34:22PM +0200, Marcin Dulak wrote: 1. subscribed to https://lists.debian.org/debian-science/ 2. created account at https://alioth.debian.org/ 3. uploaded the public key at https://alioth.debian.org/account/editsshkeys.php I'm unable to ssh after 24 hours (by the way to ssh where? I'm trying to git.debian.org) maybe due to the fact, as the https://wiki.debian.org/Alioth/SSH states: "You have to be a member of at least one project to be able to login via ssh" I'm unable to figure out how to add myself to a project (I guess debian science?) After login in to the web interface of alioth you should find a link to ask for membership. You will find it when going to https://alioth.debian.org/projects/debian-science/ in the end of the list of members on the right. thanks to https://lists.debian.org/debian-science/2015/05/msg00027.html i managed to create a repository for gpaw at http://anonscm.debian.org/cgit/debian-science/packages/gpaw.git (for the moment it's empty), but encountered several problems when trying to created a package locally on a jessie amd64: 1. gpaw depends on gpaw-setups (https://wiki.fysik.dtu.dk/gpaw/setups/setups.html) which is ~50MB of data without which gpaw won't work. gpaw and gpaw-setups are versioned separately and gpaw-setups are updated separately from gpaw upstream. Should I open a separate ITP for gpaw-setups? 2. gpaw depends on python-ase, which, in jessie: "E: Package 'python-ase' has no installation candidate". python-ase is somehow present in wheezy, but very outdated. I'm trying to contact the maintainer to update python-ase in jessie. 3. For the purpose of packaging I'm installing both gpaw-setups and python-ase (on jessie amd64) from http://download.opensuse.org/repositories/home:/dtufys/Debian_7.0/amd64/ and getting an error from debuild -us -uc: ... dpkg-source: info: building gpaw using existing ./gpaw_0.10.0.11364.orig.tar.gz dpkg-source: info: local changes detected, the modified files are: gpaw-0.10.0.11364/configuration.log ... It looks to me like the configuration.log file, which is written during compilation of gpaw is treated as a source modification. I'm using the following debian/rules # #!/usr/bin/make -f DH_VERBOSE=1 PYTHON2=$(shell pyversions -vr) %: dh $@ --buildsystem=python_distutils --with=python2 test-python%: set -ex && mkdir tmp && cd tmp && \ PYTHONPATH=../ python$* ../tools/gpaw-test && \ cd - && rm -rf tmp; \ override_dh_auto_test: $(PYTHON2:%=test-python%) # Any suggestions? Best regards, Marcin What's next? I guess you have many users asking for this - why not updating the documentation with ALL necessary steps? Please provide a patch for the docs which seem to be clear to you. It is sometimes hard for people to write docs who passed all this hurdles long time ago. Kind regards Andreas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787225: qa.debian.org: Bug graph URLs (/data/bts/graphs/…) reporting 403 errors
Package: qa.debian.org Severity: normal This is likely more fallout from the jessie upgrade. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787224: RM: fig -- ROM; renamed to docker-compose
Package: ftp.debian.org Severity: normal Please remove fig, but if possible only after accepting docker-compose through NEW :) docker-compose does not have a package named fig, there is no transition. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787099: pulseaudio: Output is muted when headphones/speakers are plugged in
Control: tags -1 moreinfo On 28 May 2015 at 12:05, Martin Erik Werner wrote: > Package: pulseaudio > Version: 6.0-2 > Severity: normal > > Dear Maintainer, > > On Jessie, at some point during the last couple of weeks, automatic > adjustment of volume/muting when plugging in headphones (or external > spekaers) has stopped working correctly. What was the previous behavior? > > Looking in alsamixer: When headphones are plugged in, "Master" and > "Speaker+LO" are muted, the "Speaker+LO" slider is set to zero, and > "Headphones" remains muted. > > What I notice is that currently "Headphones" has no effect on the volume > output from the jack, I need to change "Speaker+LO" instead, and unmute > it and "Master", and then I get sound output from the jack. > > If I unplug it and plug it in again it returns to the same muted and > zero-volume state described above. Can pavucontrol restore the volume or is that broken as well? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786660: pulseaudio-module-bluetooth: Cracky sound when something else runs
On 28 May 2015 at 19:00, Julien Palard wrote: > Hello, > > On 05/25/2015 01:30 AM, Felipe Sateler wrote: >> >> Des this problem happen if you use the following instead of the loopback >> module? >> >> mkfifo test >> paplay --raw test & >> parec -d test > > Just tried, did not heard any crack when playing thrue the fifo. OK, this suggests a problem with the loopback module. > >> Also, please attach a verbose log of pulseaudio when the problem happens: > > I logged a few seconds of very cracky sound, hope that helps. What parameters are you giving to the loopback module? I see in the log: source="bluez_source.C4_43_8F_9F_F5_36" source_dont_move="true" sink_input_properties="media.role=music" Is that all? Try increasing the latency (default is 200), or disabling remixing. If that fails, try changing the resampler in the configuration file. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688182: linphone: kFreeBSD support
Hi,
Jonas Smedegaard wrote:
> It seems upstream now probes for and gracefully handles lack of V4L
> support, but the packaging forcefully avoids any video capabilities on
> non-Linux targets.
>
> Please try simply drop that discrimination in debian/rules and see if
> package still succeeds building on non-Linux targets.
I've tested that on kfreebsd with some interesting results:
Without V4L, it will still FTBFS:
| checking for LIBV4L2... no
| No libv4l2 found.
| checking for LIBV4L1... no
| No libv4l1 found.
| configure: error:
| Missing libv4l2. It is highly recommended to build with
| libv4l2 headers and library. Many camera will won't work or will crash
| your application if libv4l2 is not installed.
| If you know what you are doing, you can use --disable-libv4l2 to disable
| this check.
|
| configure: error: ./configure failed for mediastreamer2
but on kfreebsd if you add libv4l-dev to Built-Depends, it will detect,
enable and build OK with it now. (Haven't tested it at runtime).
There is also a proper detection for ALSA now. Without libasound
headers, it will not be enabled.
However, *with* liboss4-salsa-dev it FTBFS on kfreebsd due to some
Linuxisms in that code. But there's no point trying to fix that as
it is just a wrapper around OSS, and linphone should just use that
directly on kfreebsd (assuming it can? as I said I didn't test).
Somehow I ran into bug #782366 trying to build this on kfreebsd:
--- /usr/lib/pkgconfig/cunit.pc.orig2013-01-27 13:48:23.0 +
+++ /usr/lib/pkgconfig/cunit.pc 2015-05-29 23:49:28.841017548 +0100
@@ -1,6 +1,6 @@
prefix=/usr
exec_prefix=${prefix}
-libdir={exec_prefix}/lib
+libdir=${exec_prefix}/lib
includedir=${prefix}/include/CUnit
Name: CUnit
Please find attached a patch that would allow linphone to build with
V4L on kfreebsd. It still can't build yet on hurd without other porting
work.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/control.orig 2014-03-26 23:50:46.0 +
+++ debian/control 2015-05-30 00:03:45.118041864 +0100
@@ -12,7 +12,7 @@
libosip2-dev (>= 4), libexosip2-dev (>= 4),
libsqlite3-dev, libsoup2.4-dev, libxml-parser-perl,
libncurses5-dev, libreadline-dev, libnotify-dev,
- libudev-dev [linux-any], libasound2-dev [linux-any], libv4l-dev [linux-any],
+ libudev-dev [linux-any], libasound2-dev [linux-any], libv4l-dev [linux-any kfreebsd-any],
libspeex-dev, libspeexdsp-dev, libspandsp-dev, libopus-dev, libogg-dev,
libpulse-dev,
libgtk2.0-dev, libglew-dev,
--- debian/rules.orig 2015-05-29 23:20:29.161024487 +0100
+++ debian/rules 2015-05-30 00:00:23.947024732 +0100
@@ -1,9 +1,6 @@
#!/usr/bin/make -f
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
-ifneq ($(DEB_HOST_ARCH_OS),linux)
- CONFIGURE_ARGS += --disable-alsa --disable-video
-endif
%:
dh $@ --parallel --with autoreconf
signature.asc
Description: Digital signature
Bug#787223: RFS: vbam/1.8.0.1498-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vbam" * Package name: vbam Version : 1.8.0.1498-1 Upstream Author : VBA-M development team * URL :https://sourceforge.net/projects/vbam/ * License : GPL-2+ Section : otherosfs It builds those binary packages: vbam-common - Common files for VBA-M vbam-gtk - Nintendo Game Boy Advance emulator (GTK+ frontend) vbam-sdl - Nintendo Game Boy Advance emulator vbam-wx- Nintendo Game Boy Advance emulator (wxWidgets frontend) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/vbam Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/v/vbam/vbam_1.8.0.1498-1.dsc Regards, Sérgio Benjamim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787222: pgpool2: Watchdog - ifconfig up failed status 127 (pgpool-general: 3310)
Package: pgpool2 Version: 3.3.4-1 Severity: normal Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=es_CR.UTF-8, LC_CTYPE=es_CR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pgpool2 depends on: ii init-system-helpers 1.22 ii libc62.19-18 ii libmemcached11 1.0.18-4 ii libpam0g 1.1.8-3.1 ii libpgpool0 3.3.4-1 ii libpq5 9.4.2-0+deb8u1 ii libssl1.0.0 1.0.1k-3 ii lsb-base 4.1+Debian13+nmu1 ii postgresql-common165 ii ucf 3.0030 pgpool2 recommends no packages. pgpool2 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#787221: patch
tags 787221 + patch thanks I'm easily able to reproduce this problem and have verified that the upstream commit indeed resolves it. The attached patch applies this cherry-pick from upstream to the packaging branch. >From e0252e96d2b808ac23f671fc6d9f314e34fff63f Mon Sep 17 00:00:00 2001 From: dann frazier Date: Fri, 29 May 2015 15:56:08 -0600 Subject: [PATCH] d/p/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch: Fix data corruption on arm64 (LP: #1427406). --- debian/changelog | 7 ...7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch | 48 ++ debian/patches/series | 1 + 3 files changed, 56 insertions(+) create mode 100644 debian/patches/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch diff --git a/debian/changelog b/debian/changelog index 29b1a88..cac8ace 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +mariadb-10.0 (10.0.19-2) UNRELEASED; urgency=medium + + * d/p/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch: + Fix data corruption on arm64 (Closes: #787221). + + -- dann frazier Fri, 29 May 2015 15:45:23 -0600 + mariadb-10.0 (10.0.19-1) unstable; urgency=low * New upstream release. Fixed the server crash caused by mysql_upgrade diff --git a/debian/patches/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch b/debian/patches/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch new file mode 100644 index 000..dbde698 --- /dev/null +++ b/debian/patches/Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch @@ -0,0 +1,48 @@ +From 70bc0a3ef40b1b9348750c12ca5df8f0863b7cfd Mon Sep 17 00:00:00 2001 +From: Alexey Kopytov +Date: Tue, 26 May 2015 23:56:00 +0300 +Subject: [PATCH] Fixes MDEV-7658: MDEV-7026 fix reintroduces MDEV-6615 on + AArch64 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +This is an addendum to the fix for MDEV-7026. The ARM memory model is +similar to that of PowerPC and thus needs the same semantics with +respect to memory barriers. That is, os_atomic_test_and_set_*_release() +must be a store with a release barrier followed by a full +barrier. Unlike x86 using __sync_lock_test_and_set() which is +implemented as “exclusive load with acquire barriers + exclusive store” +is insufficient in contexts where os_atomic_test_and_set_*_release() +macros are used. +--- + storage/innobase/include/os0sync.h | 2 +- + storage/xtradb/include/os0sync.h | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +Index: mariadb-10.0/storage/innobase/include/os0sync.h +=== +--- mariadb-10.0.orig/storage/innobase/include/os0sync.h mariadb-10.0/storage/innobase/include/os0sync.h +@@ -452,7 +452,7 @@ Returns the old value of *ptr, atomicall + # define os_atomic_test_and_set_ulint(ptr, new_val) \ + __sync_lock_test_and_set(ptr, new_val) + +-#ifdef __powerpc__ ++#if defined(__powerpc__) || defined(__aarch64__) + /* + os_atomic_test_and_set_byte_release() should imply a release barrier before + setting, and a full barrier after. But __sync_lock_test_and_set() is only +Index: mariadb-10.0/storage/xtradb/include/os0sync.h +=== +--- mariadb-10.0.orig/storage/xtradb/include/os0sync.h mariadb-10.0/storage/xtradb/include/os0sync.h +@@ -452,7 +452,7 @@ Returns the old value of *ptr, atomicall + # define os_atomic_test_and_set_ulint(ptr, new_val) \ + __sync_lock_test_and_set(ptr, new_val) + +-#ifdef __powerpc__ ++#if defined(__powerpc__) || defined(__aarch64__) + /* + os_atomic_test_and_set_byte_release() should imply a release barrier before + setting, and a full barrier after. But __sync_lock_test_and_set() is only diff --git a/debian/patches/series b/debian/patches/series index a23ffa0..cc24687 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -11,3 +11,4 @@ fix-spelling-errors.patch mroonga-disable-switch.patch mysqld_multi_confd.patch mysqld_multi.server_lsb-header.patch +Fixes-MDEV-7658-MDEV-7026-fix-reintroduces-MDEV-6615.patch -- 2.1.4
Bug#787221: MDEV-7658: Memory corruption on arm64
Package: mariadb-server-10.0 Version: 10.0.19-1 Severity: important The memory model on arm64 makes it susceptible to a data corruption bug. Upstream, this is MDEV-7658: https://mariadb.atlassian.net/browse/MDEV-7658 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787220: 404 error with websocket/websocket jars not installed
Package: tomcat7 Version: 7.0.56-3 Severity: normal Dear Maintainer, Running a very simple websocket endpoint fails with a 404 (not found) error because the required websocket jars (tomcat-websocket.jar and websocket-api.jar) are not installed. I think the jars are not installed because the tomcat7 build scripts need a java7 compiler to build them (and don't assume that there is one installed). Adding the line java.7.home=/usr/lib/jvm/java-7-openjdk-amd64 to build.properties (in the root of the unpacked tomcat7 source) will make the build scripts build the required jars. Once the jars have been built, copying them to /usr/share/tomcat7/lib (and making no other changes) fixes the problem. I'd guess a "tomcat7-websocket" package (with a java7 dependency) with the required jars (and symlinks etc) would solve the problem? Thanks, Osric Wilkinson -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tomcat7 depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii tomcat7-common 7.0.56-3 ii ucf3.0030 Versions of packages tomcat7 recommends: ii authbind 2.1.1 Versions of packages tomcat7 suggests: pn libtcnative-1 ii tomcat7-admin 7.0.56-3 pn tomcat7-docs pn tomcat7-examples pn tomcat7-user -- Configuration Files: /etc/tomcat7/context.xml changed [not included] /etc/tomcat7/server.xml changed [not included] /etc/tomcat7/tomcat-users.xml [Errno 13] Permission denied: u'/etc/tomcat7/tomcat-users.xml' -- debconf information: tomcat7/groupname: tomcat7 tomcat7/username: tomcat7 tomcat7/javaopts: -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787219: Changing game type gives incorrect message about current game
Package: tali Version: 1:3.14.0-1 Severity: normal Tags: upstream If you change the type of the game (from "Colors" to "Regular" or vice versa), then close the preferences dialog, Tali displays a message "Current game will complete with original number of players.", even if the number of players has not changed. - Josh Triplett -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tali depends on: ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii libatk1.0-0 2.16.0-2 ii libc62.19-18 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libglib2.0-0 2.44.1-1 ii libgtk-3-0 3.14.5-1 ii libpango-1.0-0 1.36.8-3 Versions of packages tali recommends: ii yelp 3.16.1-1 tali 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#765854: ecryptfs-utils: Private directory not automatically unmounted anymore on logout
[Ping] On Sat, Oct 18, 2014 at 09:13:05PM +0200, Julian Andres Klode wrote: > (adding pkg-systemd-maintain...@lists.alioth.debian.org to CC) > > On Sat, Oct 18, 2014 at 08:31:38PM +0200, Julian Andres Klode wrote: > > Package: ecryptfs-utils > > Version: 103-3+b1 > > Severity: important > > Tags: security > > > > Previously, a Private directory was automatically unmounted on logout. This > > does not happen anymore. One problem could be that the systemd user instance > > is not bound to logins and will most likely only exit after the last login, > > leaving a process running as that user, and thus causing ecryptfs-utils to > > think the user is still active. > > > > This is a regression from wheezy as far as I am aware. > > > > So the reason appears to be that systemd keeps another PAM session around for > running its (sd-pam) and systemd --user processes, causing > ecryptfs-umount-private > to think one session is still remaining. This means we have to run > ecryptfs-umount-private before exiting the systemd --user session. > > The following user unit does this (called it ecryptfs-umount-private.service), > but I'm not sure if that's the best solution, if something in there is broken, > or how to correctly install that globally. > > -- ecryptfs-umount-private.service: > > [Unit] > Description=Umount Private directory > Before=systemd-exit.service > DefaultDependencies=no > Requires=shutdown.target > After=shutdown.target > > [Service] > Type=oneshot > ExecStart=/usr/bin/ecryptfs-umount-private > > [Install] > WantedBy=exit.target > -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787218: gnome-session-failed tried to wreck my X session
Package: gnome-session-bin Version: 3.14.0-2 Severity: serious I clicked the desktop chooser at the bottom right hand corner to try and go to another desktop The screen went light grey with a message in the middle telling me "Something went wrong" and with a log out button Instead of clicking this button, I pressed Alt-F1 and logged in as root on a text console and looked through my process table I saw this binary in the ps output: /usr/lib/gnome-session/gnome-session-failed --allow-logout I killed it and then went back to X and my desktop was still there, my windows still open, the "Something went wrong" thing gone. Therefore, I think this gnome-session-failed thing is unstable and I'm thinking about deleting it from the system so it won't happen again. I never saw this before updating to jessie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759277: gummiboot: function pointer typedefs using KnR-style(?) parameter declarations
On Tue, May 12, 2015 at 05:57:55PM +0200, Kay Sievers wrote: > On Tue, May 12, 2015 at 2:01 PM, Julian Andres Klode wrote: > > Control: forwarded -1 k...@vrfy.org > > > > (Adding Kay Sievers & Harald Hoyer from upstream) > > > > On Mon, Aug 25, 2014 at 09:10:48PM +0200, Michael Tautschnig wrote: > >> Package: gummiboot > >> Version: 45-2 > >> Usertags: goto-cc > >> Severity: wishlist > >> Tags: upstream > >> > >> While trying to build gummiboot using our research compiler infrastructure > >> the > >> build stumbled upon the following declaration in src/efi/console.c (from > >> line 29 > >> onwards): > >> > >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( > >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This; > >> BOOLEAN ExtendedVerification; > >> ); > >> > >> While even gcc -Wall -pedantic will emit warnings, clang entirely rejects > >> this. > >> To address this, the semicolons after the function parameters should be > >> replaced > >> by commas, and the last one should be omitted, like this: > >> > >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( > >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This, > >> BOOLEAN ExtendedVerification > >> ); > >> > >> The same problem appears multiple times in that file. > >> > >> I'm not sure about the rationale for the chosen syntax and surely this is > >> an > >> upstream problem, but I couldn't figure out what their bugtracker was. > > > > I'm not sure either, I added the upstream authors to the list > > of recipients. > > Just a bug. Surprised that gcc even accepts that. Send a patch if you > like it in the gummiboot repo, I'll fix the version in the systemd > repo. I'll just keep the bug open then, it will be closed when gummiboot is removed from unstable (after we have systemd-boot). -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64
On 05/29/2015 08:52 PM, John David Anglin wrote:
> On 2015-05-29 2:25 PM, Matthias Klose wrote:
>> I don't think I have any packaging changes which could lead to this.
> Okay. I didn't see anything in changelog entries.
>>
>> Looking at the build log, I see the CC is overridden in the build target,
>> can you check if removing the
>>CC="$(CC_for_hppa64_cross)"
>> line helps? fixing this in the VCS, but I don't see how this could be
>> related.
> Yes, CC_for_hppa64_cross is not defined. Should CC be set or just removed?
removed.
> Looking down
> at the neon hunk below, it might have same problem.
I should remove all the neon stuff, it's bitrotted anyway.
>> as a last resort, you could configure the hppa64 build with --disable-lto.
>
> I did try this and various other permutations. In some cases, the build got
> to
> the CC_for_hppa64_cross
> hunk but always something wanted target libiberty. I've wondered if the
> latter
> hunk is needed.
> I need to look at the buildd results carefully. I wasn't able to duplicate
> the
> issue with my own cross although
> I didn't try with gcc-5.
ok, I think I found it. This is a change made by YunQiang Su to build libgnatprj
and libgnatvsn as target libraries, pulling in a dependency
Makefile.def:
+dependencies = { module=all-target-libgnatprj; on=all-target-libiberty; };
Find out how to define this conditionally?
Anyway, please check if this is the real cause. attaching a hack which should
work around that.
Matthias
Index: debian/changelog
===
--- debian/changelog (revision 8077)
+++ debian/changelog (working copy)
@@ -1,3 +1,9 @@
+gcc-5 (5.1.1-9) UNRELEASED; urgency=medium
+
+ *
+
+ -- Matthias Klose Fri, 29 May 2015 20:23:31 +0200
+
gcc-5 (5.1.1-8) unstable; urgency=medium
* Update to SVN 20150528 (r223816, 5.1.1) from the gcc-5-branch.
Index: debian/hppa64-hack.diff
===
--- debian/hppa64-hack.diff (revision 0)
+++ debian/hppa64-hack.diff (working copy)
@@ -0,0 +1,10 @@
+--- a/src/Makefile.in
b/src/Makefile.in
+@@ -51365,7 +51365,6 @@
+ all-gnattools: maybe-all-target-libgnatprj
+ all-target-libgnatvsn: maybe-all-target-libada
+ all-target-libgnatprj: maybe-all-target-libgnatvsn
+-all-target-libgnatprj: maybe-all-target-libiberty
+ all-gnattools: maybe-all-target-libstdc++-v3
+ all-lto-plugin: maybe-all-libiberty
+
Index: debian/rules2
===
--- debian/rules2 (revision 8080)
+++ debian/rules2 (working copy)
@@ -1290,6 +1290,8 @@
rm -f $(configure_hppa64_stamp) $(build_hppa64_stamp)
rm -rf $(builddir_hppa64)
mkdir $(builddir_hppa64)
+ patch -p1 -b < debian/hppa64-hack.diff
+ touch -r src/Makefile.in.orig src/Makefile.in
: # configure
cd $(builddir_hppa64) && \
$(SET_PATH) \
Bug#769539: must "install" instead of "update" on first install
Control: tag -1 pending On Fri, Nov 21, 2014 at 03:13:21PM +0100, Lukas Wunner wrote: > Hi, > > > This is working as intended. I do not want to install gummiboot before > > they had the chance to properly configure it, and it also introduces > > other issues. Some users also may not want to install gummiboot to the > > ESP at all, and just want the binary for a USB stick or similar. > > Fair enough. However: > > - It would be awesome if you could document this in a README.Debian. Fixed in commit d280493c9873b8cf1baf1251f01a76b62fbaea9b. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703971: command-not-found: patch attached
On Tue, Dec 30, 2014 at 07:16:55PM +0100, Thanatermesis wrote: > Package: command-not-found > Followup-For: Bug #703971 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Small patch attached > I'd like to update the package, but I lost the repository somewhere in my laptops. I'll try to talk to upstream/Ubuntu and see if we can get sane upstream releases again, so I can properly restart maintenance. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765931: dnsmasq: Slows down shutdown/reboot a lot in systemd
On Tue, Feb 10, 2015 at 09:40:37AM +, Simon McVittie wrote: > On Sun, 19 Oct 2014 at 13:15:03 +0200, Julian Andres Klode wrote: > > When using dnsmasq in a systemd-based system, reboot gets delayed a lot. The > > log indicates that systemd starts /etc/init.d/dnsmasq > > systemd-stop-resolvconf > > as second 28 and dnsmasq only exits at second 38, thus causing a > > considerable > > slow-down of the machine. During that time, the machine appears to hang. > > I couldn't reproduce this while testing the patch I sent to > https://bugs.debian.org/776530 (either with or without dbus) so I suspect > that either that patch fixes the slow shutdown, or something has > changed in systemd since you reported this bug. > > Do you have dbus installed? Of course I have, I'm not living under a rock. > > > Your systemd unit should not use the init script either, BTW. > > Perhaps not, but during freeze is not the time to change that. > > If it is desirable for the systemd unit to support the various > options that can appear in /etc/default/dnsmasq (particularly the > deprecated ones like MAILHOSTNAME) then I don't think that > can be done without a shell script wrapper of some sort, due to > the options' syntax; perhaps for Debian 9 it would be cleaner to have > a separate shell script wrapper for the systemd side, but it > would have to duplicate parts of the init script. > AFAICT, it uses the standard syntax that is natively supported by systemd's EnvironmentFile option. See systemd.exec(7) for details. Not sure if that is useful. You can read the file using systemd and then use the environment variables in your command to be executed. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787217: clang++-3.7 generates wrong code with -O1 or -O2
Package: clang-3.7
Version: 1:3.7~svn230892-1
Severity: important
File: /usr/bin/clang++-3.7
Hi,
when I build the following code with
clang++-3.7 -O2 -o foo foo.C
and then run ./foo, I get a SIGFPE. The example is minimal (if you remove the
cerr before, no SIGFPE). That means that the code is taking the wrong path in
the "if" clause. If you uncomment any of the two cerr within the "if", not
SIGFPE anymore.
This does not affect clang++3.4 or 3.5, it does also affect clang++-3.7 with
-O1 but not not -O0.
I haven't checked yet whether that affects upstream as well.
Kind regards, Thibaut.
foo.C -
#include
#include
double computeCst(double QQ) {
std::cerr << "foo\n" << std::endl;
if (QQ==0) {
//std::cerr << "right path\n";
return 1.;
} else {
//std::cerr << "wrong path\n";
return 1/QQ;
}
}
int main(int argc, char *argv[]) {
feenableexcept(FE_DIVBYZERO);
computeCst(0.);
return 0;
}
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages clang-3.7 depends on:
ii binutils 2.25-5
ii libc62.19-18
ii libc6-dev2.19-18
ii libclang-common-3.7-dev 1:3.7~svn230892-1
ii libclang1-3.71:3.7~svn230892-1
ii libedit2 3.1-20140620-2
ii libffi6 3.1-2+b2
ii libgcc-4.9-dev 4.9.2-10
ii libgcc1 1:4.9.2-10
ii libllvm3.7 1:3.7~svn230892-1
ii libobjc-4.9-dev 4.9.2-10
ii libstdc++-4.9-dev4.9.2-10
ii libstdc++6 4.9.2-10
ii libtinfo55.9+20140913-1+b1
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages clang-3.7 recommends:
pn llvm-3.7-dev
ii python2.7.9-1
Versions of packages clang-3.7 suggests:
pn clang-3.7-doc
pn gnustep
pn gnustep-devel
-- 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#770786: python3-aptdaemon: aptdcon failed to launch due to "import gobject"
On Mon, Nov 24, 2014 at 11:29:29AM +0900, Kenshi Muto wrote: > Package: python3-aptdaemon > Version: 1.1.1-4 > Severity: important > > Dear Maintainer, Hi, Thanks for the bug report. I only kept aptdaemon in the repository for use by isenkram, I plan to remove it ASAP in this release cycle. There's no real advantage in using aptdcon over apt or packagekit, if you need a demon. I suggest using that instead. I do not think it's worth a stable release update. Regards, Julian -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785431: python-apt: Set Standards-Version to 3.9.6
Control: tag -1 pending On Sat, May 16, 2015 at 10:32:27AM +0200, von wrote: > Package: python-apt > Version: 0.9.4 > Severity: normal > Tags: patch > > Standards-Version should be upgraded from 3.9.5 to 3.9.6 > > Looking at https://www.debian.org/doc/debian-policy/upgrading-checklist > > we see that no items impact python-apt > > A patch is added to do the upgrade. Applied, thanks. But there's no real need to submit a bug report for this, it's a thing lintian warns about, so it usually get's fixed with the next upload anyway. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632186: python-software-properties: Please don't write *.save files when they're identical
On Thu, Apr 09, 2015 at 06:35:38PM +0200, Marcel Partap wrote: > Package: software-properties-common > Version: 0.92.25debian1 > Followup-For: Bug #632186 > > This is not really just a wish list item.. touching files in /etc by default, > without asking or telling the user, is not ok. Furthermore, the files are > recreated, messing up both the mtime and ctime metadata. Just sayin. It's a graphical editor for sources.list files, so it is obviously OK to edit sources.list files. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785261: python-apt: Remove the "-Wstrict-prototypes" compiler option
On Wed, May 20, 2015 at 06:13:04PM +0200, mat...@mailoo.org wrote: > > > Le 15.05.2015 12:33, Julian Andres Klode a écrit : > > > On Fri, May 15, 2015 at 12:26:28PM +0200, Julian Andres Klode wrote: > > > >> Hi, > >> > >> thanks for your patch. I seriously dislike pseudonymous contributions, > >> would it be possible that you resubmit this with your real name, or does > >> this pose a risk to you? > > > > And it would be great if the email address of the patch would match the > > bug report email address. > > Hi, > > I send you a new patch with an email address matching the bug report > email adress. Applied. > > I prefer, for now, to keep using the same pseudonym. > > I don't know the reasons of your dislike of pseudonym but you are the > maintainer, so it's up > to you to commit or not, the different patches. > It is to me a matter of respect. I tell you my name, so it's only respectful if you tell me yours. Oh, and I might be a bit OCD about names in commit logs looking real. A single word without a real name just does not look right :( I would not have noticed this if you had used a real-looking pseudonym like Matthieu Villeneuve or something like that. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786764: Fwd: Bug#786764: RFS: python-spur/0.3.14-1 [ITP]
Hi Andrey, > Please run tests at the build time. I've looked into the tests now, and I'm not sure if it so easy to get it to run during build of the Debian package. It requires an active SSH server with a known username and password. It is not exactly unit testing.. (See: https://github.com/mwilliamson/spur.py/blob/master/CONTRIBUTING.rst) :) But I will remember to check if there are any tests the next time I make a package. > ALso, "$(RM) -r .pybuild" in override_dh_auto_clean looks strange. Regarding RM -r .pybuild: I don't like when the work folder isn't restored completely when running "dh clean". Therefore I added this rule. Perhaps there's a reason for keeping it there after "dh clean"? Or is it supposed to disappear without any explicit rule? Have a nice weekend! Best regards, Ruben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717445: pu: package ndiswrapper/1.57-1+deb7u1
oOn Sat, Apr 25, 2015 at 06:33:52PM +0100, Adam D. Barratt wrote:
> On Sat, 2014-12-06 at 21:22 +0100, Philipp Kern wrote:
> > Control: tag -1 + moreinfo
> >
> > Hi,
> >
> > On Sun, Jan 26, 2014 at 02:57:22PM +0100, Julian Andres Klode wrote:
> > > I'm most likely going to ship the patch below in 1.59-2, it just drops
> > > the detection and hard-codes the modprobe.d/ndiswrapper.conf file, as
> > > the other locations are not supported anymore.
> >
> > if this request still applies, please provide an updated debdiff against
> > stable
> > of what you want to ship. Thanks!
>
> Poke.
>
> Regards,
>
> Adam
>
Sorry for not answering. I attached a new diff. The patches had to
be backported from unstable, due to some renamed (KVERS vs KVERS_UNAME)
and moved code (declaration of $modconf), but they should work, as
they are fairly obvious patches.
I do not have any devices to really test things, though.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.
diff --git a/debian/changelog b/debian/changelog
index 5654ab5..73672d0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ndiswrapper (1.57-1+deb7u1) oldstable; urgency=medium
+
+ * Use $KERNELRELEASE as target kernel version (Closes: #693638)
+ * Add BUILT_MODULE_NAME to dkms config file (Closes: #690747)
+ * Only support modprobe.d (Closes: #724890)
+
+ -- Julian Andres Klode Fri, 29 May 2015 22:15:51 +0200
+
ndiswrapper (1.57-1) unstable; urgency=low
* Imported Upstream version 1.57
diff --git a/debian/ndiswrapper-dkms.dkms.in b/debian/ndiswrapper-dkms.dkms.in
index 1053506..8c6a6de 100644
--- a/debian/ndiswrapper-dkms.dkms.in
+++ b/debian/ndiswrapper-dkms.dkms.in
@@ -1,4 +1,5 @@
PACKAGE_NAME="ndiswrapper"
PACKAGE_VERSION="@VERSION@"
DEST_MODULE_LOCATION[0]="/updates"
+BUILT_MODULE_NAME[0]="ndiswrapper"
AUTOINSTALL="yes"
diff --git a/debian/patches/Add-support-for-3.x-kernel-versions.patch b/debian/patches/Add-support-for-3.x-kernel-versions.patch
new file mode 100644
index 000..78961c1
--- /dev/null
+++ b/debian/patches/Add-support-for-3.x-kernel-versions.patch
@@ -0,0 +1,40 @@
+From 8e6e357f6c0246dbed8bea55df215a46978152ad Mon Sep 17 00:00:00 2001
+From: Julian Andres Klode
+Date: Sat, 11 Jan 2014 17:15:39 +0100
+Subject: [PATCH] Hardcode /etc/modprobe.d/ndiswrapper.conf
+
+We do not support modprobe.conf anymore. The code failed to work with
+recent kernels that only export two components in the version,
+so things were broken a bit anyway.
+
+Bug-Debian: http://bugs.debian.org/724890
+---
+ utils/ndiswrapper | 18 +-
+ 1 file changed, 1 insertion(+), 17 deletions(-)
+
+--- a/utils/ndiswrapper
b/utils/ndiswrapper
+@@ -53,22 +53,7 @@ if (@ARGV < 1) {
+ exit(1);
+ }
+
+-my $modconf;
+-if (`uname -r` =~ /(\d+)\.(\d+)\.(\d+)/) {
+-if ($2 > 4) {
+- if (-d "/etc/modprobe.d") {
+- $modconf = "/etc/modprobe.d/ndiswrapper.conf";
+- } else {
+- $modconf = "/etc/modprobe.conf";
+- }
+-} else {
+- if (-d "/etc/modutils") {
+- $modconf = "/etc/modutils/ndiswrapper";
+- } else {
+- $modconf = "/etc/modules.conf";
+- }
+-}
+-}
++my $modconf = "/etc/modprobe.d/ndiswrapper.conf";
+
+ my $res;
+ my $dbg_file;
diff --git a/debian/patches/ndiswrapper-use-KERNELRELEASE.patch b/debian/patches/ndiswrapper-use-KERNELRELEASE.patch
new file mode 100644
index 000..f1cb786
--- /dev/null
+++ b/debian/patches/ndiswrapper-use-KERNELRELEASE.patch
@@ -0,0 +1,22 @@
+From: Ben Hutchings
+Subject: Use $KERNELRELEASE as target kernel version
+Bug-Debian: http://bugs.debian.org/693638
+
+We must not assume that the running kernel version is the target
+version! DKMS and later Kbuild set $KERNELRELEASE to be the target
+kernel version.
+
+--- a/driver/Makefile
b/driver/Makefile
+@@ -12,7 +12,11 @@ DISTFILES = \
+ # By default, we try to compile the modules for the currently running
+ # kernel. But it's the first approximation, as we will re-read the
+ # version from the kernel sources.
++ifeq (,$(KERNELRELEASE))
+ KVERS ?= $(shell uname -r)
++else
++KVERS ?= $(KERNELRELEASE)
++endif
+
+ # KBUILD is the path to the Linux kernel build tree. It is usually the
+ # same as the kernel source tree, except when the kernel was compiled in
diff --git a/debian/patches/series b/debian/patches/series
index 2335794..99ec0d6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,3 @@
ndiswrapper-harden.patch
+ndiswrapper-use-KERNELRELEASE.patch
+Add-support-for-3.x-kernel-versions.patch
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Thu, May 28, 2015 at 01:21:52AM +0200, François-Régis wrote: > Le 27/05/2015 22:20, Lennart Sorensen a écrit : > > On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote: > > > I am curious though: With the am3359-evmsk board I see no network traffic > > with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at > > 100Mbit link speed. Does anyone with a beaglebone see the same behaviour? > > Using the TI sdk kernel does work at gigabit speed, so the hardware > > seems fine. > > > > AFAIK beaglebone black has only 10/100 ethernet link [1] so it's hard to > watch the same behaviour. > > [1] > http://elinux.org/Beagleboard:BeagleBoneBlack#BeagleBone_Black_Features Hmm, odd given I thought the CPU did gigabit. Doing a check of the dtb files I see that yes the CPU can do gigabit, but the phy used on the beaglebone boards is 100Mbit only, so the bug could never affect them. So only the few boards with the Am335x that have gigabit in use could see such a bug. So not an issue really. That's good. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi again Detrick, Am Freitag, den 29.05.2015, 15:55 -0400 schrieb Detrick Merz: > Given the two sets of paths listed above to reproduce this, I'm > guessing there's some holdover from the Wheezy install that's the root > cause, but it's probably not something explicitly in liquidsoap or the > libmp3lame library? i find this puzzling. Could you make sure you end up with the same libmp3lame package when dist-upgrading and when installing a fresh Jessie system? Also, could you make sure if the lib throws a SIGSEGV or a SIGILL? - Fabian signature.asc Description: This is a digitally signed message part
Bug#503440: Please check status of bug #503440
https connection was reworked with version 6.06 of libwww-perl and liblwp-protocol-https-perl. https connection through proxy now works fine. Could you check the status of this bug on your side ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785713: jessie-pu: package blackbox/0.70.1-23
On Fri, 2015-05-29 at 16:34 -0300, Herbert Parentes Fortes Neto wrote: > On Thu, 28 May 2015 19:01:03 +0100 > "Adam D. Barratt" wrote: > > > Control: tags -1 -moreinfo +confirmed > > > > On Sat, 2015-05-23 at 10:40 -0300, Herbert Parentes Fortes Neto wrote: > > > On Sat, 23 May 2015 09:28:39 +0100 > > > "Adam D. Barratt" wrote: > > [...] > > > > Could you provide a little more detail as to why this change is > > > > included? > > > > > > > > + * debian/clean: Added compile file. > > > > > > The package doesn't compile two times in sequence with this > > > file. When you run 'debuild' for the second time, it complain > > > about changes in the orig (upstream). It is not a really > > > necessary change. The user who wants to build the package can > > > read the error message and remove the file himself. The change > > > is just to give some comfort for who wants to build the package. > > > > In that case, we should skip it for the stable upload. > > > > Please feel free to go ahead with just the focus fix. > > > > I thought the upload was accepted, but I received a 'Rejected' email: > > ACL dm: not allowed to upload source package 'blackbox' Indeed you don't appear to be on the DM ACL for that package. In that case, please ask your sponsor to upload. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787216: dbconfig-common: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: dbconfig-common Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: Binary data signature.asc Description: Digital signature
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard, hi Detrick, Am Freitag, den 29.05.2015, 19:02 +0200 schrieb Bernhard Übelacker: > I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: is this on a fresh Jessie install? > (amd64 did not show the fault) Ack, I couldn't reproduce it on my amd64 system as well. > (gdb) bt > #0 0xb76e30c9 in init_xrpow_core_sse () from > /usr/lib/i386-linux-gnu/libmp3lame.so.0 So, this seems to be a bug in SSE code. Which means that either the code itself is buggy or your system does not support SSE instructions at all (though the latter should throw a SIGILL instead of a SIGSEGV). Would both of you please tell my the content of /proc/cpuinfo? Thanks! Fabian signature.asc Description: This is a digitally signed message part
Bug#777595: update-notifier: Wrong license in debian/copyright (compared to COPYING)
[mvo: Can you clarify this mess?] On Tue, Feb 10, 2015 at 12:21:34PM +0100, Axel Beckert wrote: > Source: update-notifier > Severity: serious > Version: 0.99.3debian8 0.99.3debian11 > > Both, the Squeeze version[1] as well as the Wheezy version[2] of this > package claim in debian/copyright that it's licensed under the "GNU > Lesser General Public License version 2" (or later) despite the facts > that > > a) a "version 2" of the GNU Lesser General Public License never >existed[3], and Well, that's not uncommon. It's not really correct, but I've seen many projects having this (especially in GNOME land). > > b) the file COPYING in the same tar ball[4][5] clearly contains the GNU >General Public License version 2 and neither the GNU Lesser General >Public License version 2.1 not the GNU Library General Public License >version 2.0 (which would be the closest name matches to mentioned >non-existing license). > > [1] > https://sources.debian.net/src/update-notifier/0.99.3debian8/debian/copyright/ > [2] > https://sources.debian.net/src/update-notifier/0.99.3debian11/debian/copyright/ > [3] https://www.gnu.org/licenses/old-licenses/old-licenses.html#LGPL > [4] https://sources.debian.net/src/update-notifier/0.99.3debian11/COPYING/ > [5] https://sources.debian.net/src/update-notifier/0.99.3debian11/COPYING/ > > debian/copyright seems to refer to src/update-notifier.c which sports > the same non-existing license[6][7]. > > [6] > https://sources.debian.net/src/update-notifier/0.99.3debian8/src/update-notifier.c/#L7 > [7] > https://sources.debian.net/src/update-notifier/0.99.3debian11/src/update-notifier.c/#L7 > > Even if you do not intend to do an (old)stable update for this issue, > please at least clarify the license in this bug report to allow others > to fork your work under the correct license. > > My interpretation is the following: > > * debian/copyright as well as src/update-notifier.c both refer to a > non-existing license. > > * They do not refer to an explicit file in /usr/share/common-licenses/ > but claim that the license should have been received "along with this > library". > > * "Along with this library", there is only the GPL (in the file > COPYING), but none of its LGPL-abbreviated relatives. > > * This looks like a failed and incomplete relicensing attempt from > GPL-2+ to LGPL-2.1+. > > * The GPL-2 is a stricter version of at least the LGPL-2.1. > > So it should be safe to asssume that the software can be at least copied > under the terms of the GPL-2 and probably also GPL-2+. > > But then again, IANAL. So any clarification is appreciated. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
On Wed, May 27, 2015 at 10:30 AM, Fabian Greffrath wrote: > Am Mittwoch, den 27.05.2015, 10:03 -0400 schrieb Detrick Merz: >> lame does *not* seem to produce this same error. I took a freshly built >> wheezy >> system, installed icecast2 and liquidsoap as before, upgraded to jessie, >> saw the general protection error when trying to start liquidsoap. I then >> installed lame, fed it a wav, and it happily produced an mp3 file. No errors >> appeared on stdout or in /var/log/messages. > > Alright, so it appears that this bug is rather in liquidsoap (or one of > its plugins or the way they call libmp3lame) than in libmp3lame itself. > > Before I ask you to rebuild lame on your system, please tell me the > *exact* steps that are required to reproduce the bug. I've rebuilt my test system a few times to make sure I've covered the steps correctly. - Install Debian Wheezy i386 net install (minimal is fine) - apt-get install icecast2 - apt-get install liquidsoap - start icecast2 - configure liquidsoap to output.icecast(%mp3) - sed -i 's/wheezy/jessie/g' /etc/apt/sources.list - apt-get update - apt-get install icecast2 (optional) - apt-get install liquidsoap OR apt-get upgrade - /etc/init.d/liquidsoap stop - /etc/init.d/liquidsoap start OR - Install Debian Wheezy i386 net install (minimal is fine) - sed -i 's/wheezy/jessie/g' /etc/apt/sources.list - apt-get update - apt-get upgrade - apt-get dist-upgrade - apt-get install icecast2 - apt-get install liquidsoap - start icecast2 - configure liquidsoap to output.icecast(%mp3) In the past couple of days I've discovered that using a clean Jessie install does not seem to produce the same error. I thought I had tested that before and seen otherwise, but I've tried it multiple times and cannot reproduce it with a clean Jessie build. Given the two sets of paths listed above to reproduce this, I'm guessing there's some holdover from the Wheezy install that's the root cause, but it's probably not something explicitly in liquidsoap or the libmp3lame library? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787212: libvmime: FTBFS on arm64
tags 787212 +pending thanks Hello Edmund, On Fri, May 29, 2015 at 08:26:14PM +0100, Edmund Grimley Evans wrote: > Source: libvmime > Version: 0.9.1-2 > Tags: patch > > I think you need to apply something like the attached patch. However, > you should probably read https://wiki.debian.org/Autoreconf yourself. > > With the patch it built on arm64 for me. It wasn't in a fresh chroot, > but you already build-depend on autotools-dev. thanks for your patch! I played already yesterday with exact the same changes to the rules files and was only able to test it on amd64 (to nothing get's broken] as I haven't a arm64 machine for testing. As you wrote you could test the changes successfully I will prepare a next upload with your changes. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771045: Info received (Bug#771045: Info received (Bug#771045: Info received (Bug#771045: Acknowledgement (linux-image-3.16.0-4-amd64: System randomly freezes using Kernel 3.16 and radeon))))
Still freezes. Switching now to Arch. Tom -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787162: Fwd: Re: Bug#787162: g++-mingw-w64-i686: error adding symbols: File format not recognized
Forwarding to the BTS... Courriel original Objet: Re: Bug#787162: g++-mingw-w64-i686: error adding symbols: File format not recognized Date: 29/05/2015 12:16 De: Stephen Kitt À: Mathieu Malaterre Le 29/05/2015 12:08, Mathieu Malaterre a écrit : indeed that work also. so working versions are 2.22-8+2+b1 (wheezy) & 2.25-7+6 (sid), buggy version is 2.25-5+5.2 (jessie) I've just tested the patch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=cdb602b17548eeebb5e700c507d734ea5f887a49;hp=6f98576f29a70ed947f102015df0388bccc6aa1a It works locally. It is a nasty bug, since it render mingw64 package very limited (at least for me). Excellent find, thanks! I agree that it's a nasty bug, I'll leave the severity at important and try to get a fix in a point-release. Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783881: Debugging information
I think I may have gathered a useful clue, though of the kind I was expecting... In order to gather the boot messages immediately before shutdown, that I don't normally get to see due to the graphics card output turning off early, I attached to the Linux console via serial, by adding this on the linux kernel command line: console=ttyS0,38400 After doing that, for about seven boots, I couldn't reproduce the original problem. I removed that option again for a couple of boot-shutdown cycles, and on the second one on shutdown it failed to power the machine off again. I also tried reinstating the 'quiet' option to the kernel which is there by default after installing Debian, and shutdown still failed the next time. Put the console=ttyS0,38400 back, and the problem *seems* to go away. However the failed poweroff is intermittent, so the use of console=ttyS0,38400 and it consistently powering off OK could just be happy coincidence. I intend to keep the linux console as serial for a few days, and see if I or the machine's other user experiences this poweroff problem again under normal operation rather than my forced idea of normal operation. If it's consistently OK for that time, I think it would be safe to say that this bug only appears for me if the console is the graphics card. It also appears that the display stayed on with a blinking cursor in the top left right until poweroff, whereas without that option it turned off earlier. For the record at this point, I think it's worth mentioning that my graphics adapter is: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] [10de:06e4] (rev a1) and it's being driven with the nouveau graphics driver. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785713: jessie-pu: package blackbox/0.70.1-23
On Thu, 28 May 2015 19:01:03 +0100 "Adam D. Barratt" wrote: > Control: tags -1 -moreinfo +confirmed > > On Sat, 2015-05-23 at 10:40 -0300, Herbert Parentes Fortes Neto wrote: > > On Sat, 23 May 2015 09:28:39 +0100 > > "Adam D. Barratt" wrote: > [...] > > > Could you provide a little more detail as to why this change is > > > included? > > > > > > + * debian/clean: Added compile file. > > > > The package doesn't compile two times in sequence with this > > file. When you run 'debuild' for the second time, it complain > > about changes in the orig (upstream). It is not a really > > necessary change. The user who wants to build the package can > > read the error message and remove the file himself. The change > > is just to give some comfort for who wants to build the package. > > In that case, we should skip it for the stable upload. > > Please feel free to go ahead with just the focus fix. > I thought the upload was accepted, but I received a 'Rejected' email: ACL dm: not allowed to upload source package 'blackbox' regards, -- Herbert Parentes Fortes Neto (hpfn) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705318: now in upstream stable
Hi Stéphane, I'm also interested in an update. Regards, Andrey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787215: stardict: FTBFS on arm64
Source: stardict Version: 3.0.1-9.2 Tags: patch I think you need to apply something like the attached patch. However, you should probably read https://wiki.debian.org/Autoreconf yourself. With the patch it built on arm64 for me. It wasn't in a fresh chroot, but you already build-depend on autotools-dev. diff -ru stardict-3.0.1.orig/debian/rules stardict-3.0.1/debian/rules --- stardict-3.0.1.orig/debian/rules 2011-10-13 17:57:27.0 + +++ stardict-3.0.1/debian/rules 2015-05-29 19:13:39.31000 + @@ -2,7 +2,7 @@ #export DH_VERBOSE=1 %: - dh $@ + dh $@ --with autotools-dev override_dh_auto_configure: ./autogen.sh
Bug#787212: libvmime: FTBFS on arm64
Source: libvmime
Version: 0.9.1-2
Tags: patch
I think you need to apply something like the attached patch. However,
you should probably read https://wiki.debian.org/Autoreconf yourself.
With the patch it built on arm64 for me. It wasn't in a fresh chroot,
but you already build-depend on autotools-dev.
diff -ru libvmime-0.9.1.orig/debian/rules libvmime-0.9.1/debian/rules
--- libvmime-0.9.1.orig/debian/rules 2015-05-18 19:45:40.0 +
+++ libvmime-0.9.1/debian/rules 2015-05-29 18:18:42.2 +
@@ -46,6 +46,7 @@
endif
# Add here commands to configure the package.
+ dh_autotools-dev_updateconfig
CFLAGS="$(CFLAGS) -Wl,-z,defs" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
@@ -71,6 +72,7 @@
rm -f Makefile src/Makefile vmime/Makefile vmime/config.hpp build-stamp libtool config.guess config.log config.sub config.status config.h vmime.pc stamp-h1
cd src ; rm -f `find . -type l`
+ dh_autotools-dev_restoreconfig
dh_clean
install: build
Bug#787214: 3depict: FTBFS on arm64
Source: 3depict
Version: 0.0.18-1
Tags: patch
I think you need to apply something like the attached patch. However,
you should probably read https://wiki.debian.org/Autoreconf yourself.
With the patch it built on arm64 for me. It wasn't in a fresh chroot,
but I've probably got the build-dependency right.
diff -ru 3depict-0.0.18.orig/debian/control 3depict-0.0.18/debian/control
--- 3depict-0.0.18.orig/debian/control 2015-05-17 22:14:56.0 +
+++ 3depict-0.0.18/debian/control 2015-05-29 18:57:10.62000 +
@@ -13,7 +13,8 @@
libxml2-dev,
libmgl-dev (>= 2.0),
libvigraimpex-dev,
- automake
+ automake,
+ autotools-dev
Standards-Version: 3.9.6
Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/3depict.git
Vcs-Git: git://anonscm.debian.org/debian-science/packages/3depict.git
diff -ru 3depict-0.0.18.orig/debian/rules 3depict-0.0.18/debian/rules
--- 3depict-0.0.18.orig/debian/rules 2014-04-28 18:46:01.0 +
+++ 3depict-0.0.18/debian/rules 2015-05-29 18:56:29.23000 +
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --parallel
+ dh $@ --parallel --with autotools-dev
override_dh_auto_configure:
LDFLAGS="$(LDFLAGS) -Wl,--as-needed" dh_auto_configure -- --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --enable-openmp-parallel --disable-debug-checks --with-libpng-link="-lpng" --with-libpng-flags="-L/lib" --with-ftgl-prefix="/usr" --enable-mgl2
Bug#787213: glusterfs: FTBFS on arm64
Source: glusterfs Version: 3.7.0-1 Tags: patch I think you need to apply something like the attached patch. However, you should probably read https://wiki.debian.org/Autoreconf yourself. With the patch it built on arm64 for me. It wasn't in a fresh chroot, but I've probably got the build-dependency right. diff -ru glusterfs-3.7.0.orig/debian/control glusterfs-3.7.0/debian/control --- glusterfs-3.7.0.orig/debian/control 2015-05-21 19:06:37.0 + +++ glusterfs-3.7.0/debian/control 2015-05-29 18:40:45.83000 + @@ -4,6 +4,7 @@ Maintainer: Patrick Matthäi Uploaders: Louis Zuckerman Build-Depends: debhelper (>= 9), + autotools-dev, libfuse-dev, libibverbs-dev, libdb-dev, diff -ru glusterfs-3.7.0.orig/debian/rules glusterfs-3.7.0/debian/rules --- glusterfs-3.7.0.orig/debian/rules 2015-05-21 19:06:37.0 + +++ glusterfs-3.7.0/debian/rules 2015-05-29 18:41:07.47000 + @@ -4,7 +4,7 @@ DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) %: - dh $@ --with python2 + dh $@ --with python2 --with autotools-dev override_dh_install: strip --remove-section=.comment --remove-section=.note --strip-unneeded \
Bug#787070: prosody: DNS resolution of CNAMEs fails often
On Thu, May 28, 2015 at 12:46:22PM +0300, Sergei Golovan wrote: > I think we should fix it for both sid and jessie (through the proposed > updates procedure). The fix proposed upstream works well for me (i've > patched the > 0.9.7-2). Nothing against it, but I'm busy so if you have energy for it... go! Best, -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786863: jessie-pu: package debian-lan-config/0.19
Hi Adam, On Fri, May 29, 2015 at 08:16:26AM +0100, Adam D. Barratt wrote: > Control: tags -1 + pending > > On 2015-05-28 18:50, Adam D. Barratt wrote: > >Control: tags -1 + confirmed > > > >On Thu, 2015-05-28 at 16:27 +0200, Andreas B. Mundt wrote: > >>I hope this is in a better shape now, a new debdiff is attached. > > > >Thanks. Please feel free to upload. > > Uploaded and flagged for acceptance. Great! Many thanks (in this special case and for your and the release team's work in general). Regards, Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786874: postgresql kann nicht „??fnen“, indeed…
Re: Thorsten Glaser 2015-05-29 > this is the same bug as: > > https://wiki.postgresql.org/wiki/May_2015_Fsync_Permissions_Bug#I.27ve_hit_this_bug_and_I_can.27t_restart_Postgres._What_do_I_do.3F Yes. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#785475: arm64 shift+rotate optimization bug
On Sat, 16 May 2015 20:47:34 +0200 Magnus Holmgren wrote: > Package: gcc-4.9 > Version: 4.9.2-16 > > I think I may have discovered an optimizer bug that results in incorrect code > when building nettle. The Camellia cipher contains code similar to the > following, which reproduces the bug: I don't have a Debian arm64 machine available, but I have been able to reproduce the problem with the Linaro GCC 4.9 branch. The issue is caused by a backport of r217118, and the patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63843 should fix it. For reference, the Linaro bugzilla for this is at https://bugs.linaro.org/show_bug.cgi?id=1599 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64
On 2015-05-29 2:25 PM, Matthias Klose wrote: I don't think I have any packaging changes which could lead to this. Okay. I didn't see anything in changelog entries. Looking at the build log, I see the CC is overridden in the build target, can you check if removing the CC="$(CC_for_hppa64_cross)" line helps? fixing this in the VCS, but I don't see how this could be related. Yes, CC_for_hppa64_cross is not defined. Should CC be set or just removed? Looking down at the neon hunk below, it might have same problem. as a last resort, you could configure the hppa64 build with --disable-lto. I did try this and various other permutations. In some cases, the build got to the CC_for_hppa64_cross hunk but always something wanted target libiberty. I've wondered if the latter hunk is needed. I need to look at the buildd results carefully. I wasn't able to duplicate the issue with my own cross although I didn't try with gcc-5. Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759751: libutempter: Please enable hardening compiler flags
Hi, On Sat, 30 Aug 2014 01:06:17 +0200 Simon Ruderich wrote: > Source: libutempter > Version: 1.1.5-4 > Severity: normal > Tags: patch > > Hello, > > libutempter provides a setgid binary and therefore should enable > all possible compiler hardening options. > > The attached patch enables compat=9 to automatically use > hardening flags from dpkg-buildpackage. However the build system > has a bug which drops compiler flags from the environment and > therefore the second attached patch is also necessary. It should > be sent upstream. I agree that we should enable hardening build flags. The PIE flags should however only be passed when linking executables. Your patch passes it to both the library and the executable. Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753163: [pkg-gnupg-maint] gnupg 2.0.27 in debian unstable, with some fixes that we might want to consider for jessie
* Daniel Kahn Gillmor (d...@fifthhorseman.net) wrote: > hey debian gnupg folks-- > > I've uploaded gnupg2 2.0.27-2 to unstable. This brings unstable closer > to upstream (most of debian/patches is removed), and includes some > debian-specific attempts to address some problems that might be relevant > for a wider userbase. > > The most important changes included in 2.0.27-2 that i'd like people to > look at are: > > https://anonscm.debian.org/cgit/pkg-gnupg/gnupg2.git/commit/?id=154d606ed022cee8ef1b86183f6a444d198a8a39 > >This proposes a workaround for GNOME keyring hijacking gpg-agent, >including shipping /usr/bin/gnome-keyring-unhijack-gpg-agent as an >interim measure, and suggesting its use if a hijack is detected. >(#760102 and #753163) > > https://anonscm.debian.org/cgit/pkg-gnupg/gnupg2.git/commit/?id=be070c6017fede8dbd3549c0071e3f0ac44bebcd > >This imports NIIBE's upstream fix to not choke on repeated copies of >unknown key material (#787045) > > If folks can take a look at these changes and let me know what you think > about them, that would be great. > > In particular, i want to consider the two changes above for a stable > point release, so if you see any concerns about either of them, please > say something. Both seem reasonable for inclusion, particularly the second one. Should we have a NEWS.Debian entry to explain the issues with gnome-keyring and the existence of this script as well? -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#786919: wheezy-pu: package exactimage/0.8.5-5+deb7u4
Control: tags -1 + pending On Wed, 2015-05-27 at 07:42 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On 2015-05-26 20:05, Sven Eckelmann wrote: > > I'd like to upload the attached patch to oldstable-proposed-updates to > > fix > > #786785 (CVE-2015-3885). The security team marked this one as no-dsa > > but asked > > me to propose the fixes for a point release. Would this be ok? The > > change > > matches exactimage 0.9.1-5 + the backported "dependency" patch to get > > the > > ljpeg_start result validation after the ljpeg_start call. The latter > > change > > was in unstable before 0.9.1-5 and is required to test the patch. > > Please go ahead. Uploaded and flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64
On 05/24/2015 03:34 PM, John David Anglin wrote: > Source: gcc-5 > Version: 5.1.1-6 > Severity: normal > > A since 5.1.1-6, gcc-5 no longer builds on hppa: > > checking size of long... 0 > checking for long long... no > checking for a 64-bit type... unsigned long > checking for intptr_t... no > checking for uintptr_t... no > checking for ssize_t... no > checking for pid_t... no > configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. > make[3]: *** [configure-target-libiberty] Error 1 > checking for library containing strerror... Makefile:11736: recipe for target > 'configure-target-libiberty' failed > make[3]: Leaving directory '/«PKGBUILDDIR»/build-hppa64' > make[2]: *** [all] Error 2 > make[1]: *** [stamps/05-build-hppa64-stamp] Error 2 > Makefile:859: recipe for target 'all' failed > make[2]: Leaving directory '/«PKGBUILDDIR»/build-hppa64' > debian/rules2:1318: recipe for target 'stamps/05-build-hppa64-stamp' failed > make[1]: Leaving directory '/«PKGBUILDDIR»' > make: *** [stamps/05-build-hppa64-stamp] Error 2 > debian/rules:60: recipe for target 'stamps/05-build-hppa64-stamp' failed > dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 > > Full buildd log is here: > http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-6&stamp=1432360049 > > I tried adding --disable-libiberty to hppa64 configure command. However, > this resulted in following error: > > checking whether /«PKGBUILDDIR»/build/gcc/xgcc -B/«PKGBUILDDIR»/build/gcc/ > supports -Wstrict-prototypes... checking for stdint.h... libtool: link: > /«PKGBUILDDIR»/build/gcc/xgcc -B/«PKGBUILDDIR»/build/gcc/ -shared -fPIC > -DPIC .libs/lto-plugin.o-static-libgcc ../libiberty/libiberty.a > -static-libstdc++ -static-libgcc -Wl,-soname -Wl,liblto_plugin.so.0 -o > .libs/liblto_plugin.so.0.0.0 > xgcc: error: ../libiberty/libiberty.a: No such file or directory > make[5]: *** [liblto_plugin.la] Error 1 > yes > Makefile:351: recipe for target 'liblto_plugin.la' failed > make[5]: Leaving directory '/«PKGBUILDDIR»/build-hppa64/lto-plugin' > make[4]: *** [all] Error 2 > Makefile:264: recipe for target 'all' failed > make[4]: Leaving directory '/«PKGBUILDDIR»/build-hppa64/lto-plugin' > make[3]: *** [all-lto-plugin] Error 2 > make[3]: *** Waiting for unfinished jobs > Makefile:8664: recipe for target 'all-lto-plugin' failed > > Full log for this build is here: > http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-7&stamp=1432446476 > > It is a bit of a puzzle why lto plugin support needs a target version of > libiberty. I don't think I have any packaging changes which could lead to this. Looking at the build log, I see the CC is overridden in the build target, can you check if removing the CC="$(CC_for_hppa64_cross)" line helps? fixing this in the VCS, but I don't see how this could be related. as a last resort, you could configure the hppa64 build with --disable-lto. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787211: libopenblas-base: 100% CPU load on ARM
Package: libopenblas-base Version: 0.2.14-1 Severity: normal Hi, i have experienced 100% CPU load on ARM with octave + libopenblas as reported here [0]. I don't know if this is due to my hardware setup or it can be verified on other platforms too, but if verified maybe it could be nice to contact octave mantainers and tell them to remove libopenblas from the dependencies list until a fix (or apply a more appropriate procedure for these cases, idk). I was told in the #octave IRC channel that this bug may be already known upstream, but i wonder if something can be done on the Debian side to avoid CPU cycles wastage to users who may not monitor their CPU usage during the program execution, and so may be unaware of the issue. If you need more informations let me know. Thanks. [0] http://lists.gnu.org/archive/html/help-octave/2015-05/msg00108.html -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 3.8.11 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784943: jessie-pu: package ruby-defaults/1:2.1.5+deb8u1
Control: tags -1 + pending On Fri, 2015-05-29 at 07:53 -0300, Antonio Terceiro wrote: > On Thu, May 28, 2015 at 06:54:05PM +0100, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Sun, 2015-05-10 at 19:59 -0300, Antonio Terceiro wrote: > > > This adds a Conflicts: against ruby-activesupport-2.3 to help with > > > upgrade paths from wheezy; a similar change was made before the release > > > for ruby-activesupport-3.2. > > > > Please go ahead. > > Done. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786870: jessie-pu: package virtualbox/4.3.18-dfsg-3+deb8u3
Control: tags -1 -moreinfo +pending On Tue, 2015-05-26 at 13:29 +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On 2015-05-26 11:20, Gianfranco Costamagna wrote: > > As explained in the bug report #785689, there is an important bug > > leading to a crash in raw mode. > > > > the one-line patch is from upstream and testing, and seems safe so far. > > > > following the debdiff > > > > (as you know, the u2 update is pending) > > While this looks okay, we should wait for the security upload to be > released first. Uploaded and flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786982: jessie-pu: package libraw/0.16.0-9+deb8u1
Control: tags -1 + pending On Fri, 2015-05-29 at 08:56 +0200, Matteo F. Vescovi wrote: > Hi! > > On Thu, May 28, 2015 at 9:43 PM, Adam D. Barratt > wrote: > > In that case, please feel free to go ahead. > > Uploaded. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781276: pre-approval for mutter/3.14.4-1
Control: tags -1 + pending On Fri, 2015-05-29 at 17:02 +0200, Josselin Mouette wrote: > Le lundi 04 mai 2015 à 08:23 +0200, Julien Cristau a écrit : > > On Thu, Mar 26, 2015 at 21:22:46 +0100, Josselin Mouette wrote: > > > > > unblock mutter/3.14.4-1 > > > > > > > On Thu, Mar 26, 2015 at 22:36:38 +0100, Josselin Mouette wrote: > > > > > unblock gnome-shell/3.14.4-1 > > > > > Please upload mutter/3.14.4-1~deb8u1 and gnome-shell/3.14.4-1~deb8u1 to > > jessie. > > Built; tested; uploaded. Cutting things fine. :-) Both flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715048: Patch to add support for an indpendendent initramfs networking config
It has been a while but I believe that VIP number and a net mask remained configured on the interface. I believe that "ip flush" may take care of the problem but I have not tried it. On May 29, 2015 12:30:35 PM CDT, Guilhem Moulin wrote: >Hi, > >> The problem is that, while klibc can bring up and down network >> interfaces, the interface configuration does not go away. > >What doesn't go away exactly? (What do you mean by “interface >configuration”?) I wonder if ip(8) could help, by the way. It's >included in the initrd, can flush routes (‘ip addr flush dev $DEVICE’) >and bring down interfaces (‘ip link set dev $DEVICE down’). Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692932: dropbear: no support for a different initramfs network config from that of the normal system
tags -1 patch
thanks
I believe the issue it that the init-premount script sets $IPOPTS while
‘configure_networking’ uses $IP to pick and configure interfaces.
--
Guilhem.
--- a/usr/share/initramfs-tools/scripts/init-premount/dropbear
+++ b/usr/share/initramfs-tools/scripts/init-premount/dropbear
@@ -24,7 +24,7 @@
for x in $(cat /proc/cmdline); do
case "$x" in
ip=*)
- IPOPTS="${x#ip=}"
+ IP="${x#ip=}"
;;
esac
done
signature.asc
Description: Digital signature
Bug#787052: ParseError: expected package field
* Sébastien KALT:
> For some time now I have this error on my Sid laptop when launching debsecan
> (the output is in the attached debsecan.txt file) :
>
> $ debsecan --suite sid
> [...]
> Traceback (most recent call last):
> File "/usr/bin/debsecan", line 1380, in
> rate_system(target, options, fetch_data(options, config), history)
> File "/usr/bin/debsecan", line 1297, in rate_system
> for pkg in packages:
> File "/usr/bin/debsecan", line 131, in __iter__
> self.raiseSyntaxError("expected package field, got " + `line`)
> File "/usr/bin/debsecan", line 155, in raiseSyntaxError
> raise ParseError(self.name , lineno, msg)
> __main__.ParseError: expected package field, got '#Vcs-Git:
> git://git.debian.org/collab-maint/livret.git\n'
>
> This error appeared on may 22.
I don't see this in the Packages files for sid. Can you grep for the
string "livret" in your /var/lib/dpkg/status file and show the
surrounding package entry?
The debsecan error message is certainly worthy of improvement, but
there isn't much debsecan do if this file does not match the expected
syntax.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787203: addendum: newer firmware did not help
I noticed that the kernel bugscript was complaining about "working around [a] severe firmware bug", so I dug up the latest official BIOS update for this machine and installed that. No change -- still crashes on boot with 4.0 and not 3.16, still "Tainted: G I". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787210: evince: 800% zoom does not work in certain dvi documents
Package: evince
Version: 3.14.1-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
When I open certain dvi files in evince and set the zoom level to 800%, evince
does not show anything.
I tried to replicate this with .dvi files from TeX, but there this problem does
not occur, as the zoom
level is limited to 400 %.
Here is the path that led me to the problem:
I ran `mf beta.mf; gftodvi beta.2602.gf; evince beta.dvi` (file beta.mf
attached) and set the zoom
level to 800%. My mf version is 2.7182818 and my version of gftodvi is 3.0 (TeX
Live 2015/dev/Debian)
* What was the outcome of this action?
The box displays 611.13%, and the window does not show anything except the
black lines (the gray beta and the text disappeared).
* What outcome did you expect instead?
The character should have been displayed at 800% zoom.
Best wishes,
Gabriel Pérez-Cerezo
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (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 evince depends on:
ii evince-common 3.14.1-2
ii gnome-icon-theme-symbolic 3.12.0-1
ii libatk1.0-02.14.0-1
ii libc6 2.19-18
ii libcairo-gobject2 1.14.0-2.1
ii libcairo2 1.14.0-2.1
ii libevdocument3-4 3.14.1-2
ii libevview3-3 3.14.1-2
ii libgdk-pixbuf2.0-0 2.31.1-2+b1
ii libglib2.0-0 2.42.1-1
ii libgtk-3-0 3.14.5-1
ii libnautilus-extension1a3.14.1-2
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-01.36.8-3
ii libsecret-1-0 0.18-1+b1
ii libxml22.9.1+dfsg1-5
ii shared-mime-info 1.3-1
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages evince recommends:
ii dbus-x11 1.8.16-1
ii gvfs 1.22.2-1
Versions of packages evince suggests:
ii nautilus 3.14.1-2
ii poppler-data 0.4.7-1
pn unrar
-- no debconf information
u#:=4/9pt#;
define_pixels(u);
beginchar(66,13u#,16u#,5u#);"Letter beta";
x1=2u; x2=x3=3u;
bot y1=-5u; y2=8u; y3=14u;
x4=6.5u; top y4=h;
z5=(10u,12u);
z6=(7.5u,7.5u); z8=z6;
z7=(4u,7.5u);
z9=(11.5u,2u);
z0=(5u,u);
penpos1(2u,20);
penpos2(.5u,0);
penpos3(u,-45);
penpos4(.8u,-90);
penpos5(1.5u,-180);
penpos6(.4u,150);
penpos7(.4u,0);
penpos8(.4u,210);
penpos9(1.5u,-180);
penpos0(.3u,20);
pickup pencircle;
penstroke z1e..z2e..z3e..z4e..z5e..z6e..{up}z7e..z8e..z9e..{up}z0e;
labels(range 1 thru 9);
endchar;
end
Bug#715048: Patch to add support for an indpendendent initramfs networking config
Hi, > The problem is that, while klibc can bring up and down network > interfaces, the interface configuration does not go away. What doesn't go away exactly? (What do you mean by “interface configuration”?) I wonder if ip(8) could help, by the way. It's included in the initrd, can flush routes (‘ip addr flush dev $DEVICE’) and bring down interfaces (‘ip link set dev $DEVICE down’). -- Guilhem. signature.asc Description: Digital signature
Bug#787209: ITP: mauve-aligner -- multiple genome alignment
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: mauve-aligner Version : 2.4.0+4734 Upstream Author : Aaron Darling * URL : http://darlinglab.org/mauve/ * License : GPL Programming Lang: Java Description : multiple genome alignment Mauve is a system for efficiently constructing multiple genome alignments in the presence of large-scale evolutionary events such as rearrangement and inversion. Multiple genome alignment provides a basis for research into comparative genomics and the study of evolutionary dynamics. Aligning whole genomes is a fundamentally different problem than aligning short sequences. . Mauve has been developed with the idea that a multiple genome aligner should require only modest computational resources. It employs algorithmic techniques that scale well in the amount of sequence being aligned. For example, a pair of Y. pestis genomes can be aligned in under a minute, while a group of 9 divergent Enterobacterial genomes can be aligned in a few hours. . Mauve computes and interactively visualizes genome sequence comparisons. Using FastA or GenBank sequence data, Mauve constructs multiple genome alignments that identify large-scale rearrangement, gene gain, gene loss, indels, and nucleotide substutition. . Mauve is developed at the University of Wisconsin. This package is maintained by the Debian Med team at Vcs-Git: git://anonscm.debian.org/debian-med/mauve-aligner.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632656: dropbear: duplicate mount /dev/pts in initramfs
On Fri, 29 May 2015 at 19:18:04 +0200, Guilhem Moulin wrote: > An arguably simpler alternative to copying mountpoint(1) is to grep > through /proc/mounts. Forgot the patch, sorry. -- Guilhem. --- a/usr/share/initramfs-tools/scripts/init-premount/devpts +++ b/usr/share/initramfs-tools/scripts/init-premount/devpts @@ -13,15 +13,13 @@ ;; esac -. /scripts/functions - -grep -E "[[:space:]]+devpts$" /proc/filesystems >/dev/null 2>&1 || exit 0 +grep -qE '\sdevpts$' /proc/filesystems || exit 0 # If /dev/pts is already mounted, don't re-mount it. -mountpoint -q /dev/pts || exit 0 +! grep -qE '^devpts\s+/dev/pts\s+devpts\s' /proc/mounts || exit 0 +. /scripts/functions log_begin_msg "Mounting devpts" mkdir -p /dev/pts mount -t devpts none /dev/pts - signature.asc Description: Digital signature
Bug#787208: libuim8: uim-helper-server constantly consumes memory due to unclosed socket after exec() in client
Package: libuim8
Version: 1:1.8.6-8
Severity: normal
Dear Maintainer,
When uim client exec() to long-running process (e.g. iceweasel
restarts), it leaks open socket to uim-helper-server, and by then
uim-helper-server begins to constantly consume memory, as it cannot
write to those sockets and have to infinitely buffer unsent messages to
them:
... strace -p `pidof uim-helper-server`|egrep '^(select|mremap)' ...
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
select(11, [0 1 3 4 5 6 7 9 10], [1 4 5 6 7 9 10], NULL, NULL) = 6 (out
[4 5 6 7 9 10])
note: here fd 1 points to unix-domain-socket to such iceweasel
process, and it never returns "writeable" status; there are another
socket to same iceweasel process {which was opened after restart},
which is properly handled
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
select(11, [0 1 3 4 5 6 7 9 10], [1 4 5 6 7 9 10], NULL, NULL) = 6 (out
[4 5 6 7 9 10])
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
mremap(0xb7318000, 1404928, 1409024, MREMAP_MAYMOVE) = 0xb7318000
note: this is apparently reallocation of buffered messages for this
socket; after few days, it already grown to 1.4M
select(11, [0 1 3 4 5 6 7 9 10], [1 4 5 6 7 9 10], NULL, NULL) = 6 (out
[4 5 6 7 9 10])
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
select(11, [0 1 3 4 5 6 7 9 10], [1 4 5 6 7 9 10], NULL, NULL) = 6 (out
[4 5 6 7 9 10])
select(11, [0 1 3 4 5 6 7 9 10], [1], NULL, NULL) = 1 (in [0])
...
Attached patch fixes this by setting CLOEXEC flag on all sockets (only
uim-helper-client.c part is definitely needed and safe; uim/socket.c
part theoretically can break scm scripts that intentionally passes open
socket fd to spawned processes [but AFAIK none of them does]).
Optional 2nd patch tries to use SOCK_CLOEXEC option, available in
linux-2.6.27+ (it would avoid race window between socket() and fcntl(),
if another thread spawned process at the exact same time with socket
creation), with fallback for older kernel.
This bug is also present in (all) older uim versions, and in the
upstream master branch as well.
P.S. @upstream: also, uim-helper-server could be improved a bit for
better handling of "stuck client" scenario [aside from client bugs {e.g.
uim-input-pad-ja is broken this way}, that could be stopped processes
(^Z/kill -STOP), etc]. E.g. it could forget/merge older prop_update &
focus_* messages [after reaching some size/last-writeable-time
threshold, to avoid complication in common-case scenario].
P.P.S. BTW, uim-helper-client.c looks *extremely* fragile. If someone,
somehow will call uim_helper_init_client twice, all hell will broke loose.
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libuim8 depends on:
ii libc6 2.19-18
ii libgcroots00.8.5-4.1
ii libuim-scm01:1.8.6-8
ii multiarch-support 2.19-18
ii uim-common 1:1.8.6-8
libuim8 recommends no packages.
libuim8 suggests no packages.
-- no debconf information
Index: uim-1.8.6/uim/uim-helper-client.c
===
--- uim-1.8.6.orig/uim/uim-helper-client.c
+++ uim-1.8.6/uim/uim-helper-client.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#ifdef HAVE_STRINGS_H
#include
@@ -93,6 +94,7 @@ int uim_helper_init_client_fd(void (*dis
perror("fail to create socket");
goto error;
}
+ fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | FD_CLOEXEC);
#ifdef LOCAL_CREDS /* for NetBSD */
/* Set the socket to receive credentials on the next message */
Index: uim-1.8.6/uim/socket.c
===
--- uim-1.8.6.orig/uim/socket.c
+++ uim-1.8.6/uim/socket.c
@@ -278,7 +278,10 @@ c_freeaddrinfo(uim_lisp addrinfo_)
static uim_lisp
c_socket(uim_lisp domain_, uim_lisp type_, uim_lisp protocol_)
{
- return MAKE_INT(socket(C_INT(domain_), C_INT(type_), C_INT(protocol_)));
+ int fd = socket(C_INT(domain_), C_INT(type_), C_INT(protocol_));
+ if (fd != -1)
+fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | FD_CLOEXEC);
+ return MAKE_INT(fd);
}
static uim_lisp
Index: uim-1.8.6/uim/uim-helper-client.c
===
diff -u uim-1.8.6.orig/uim/uim-helper-client.c uim-1.8.6/uim/uim-helper-client.c
--- uim-1.8.6.orig/uim/uim-helper-client.c
+++ uim-1.8.6/uim/uim-helper-client.c
@@ -89,6 +89,12 @@
server.sun_family = PF_UNIX;
strlcpy(server.sun_path, path, sizeof(server.sun_path));
+#ifdef SOCK_CLOEXEC
+ /* linux-2.6.27+ variant that p
Bug#785713: jessie-pu: package blackbox/0.70.1-23
On Thu, 28 May 2015 19:01:03 +0100 "Adam D. Barratt" wrote: > Control: tags -1 -moreinfo +confirmed > > On Sat, 2015-05-23 at 10:40 -0300, Herbert Parentes Fortes Neto wrote: > > On Sat, 23 May 2015 09:28:39 +0100 > > "Adam D. Barratt" wrote: > [...] > > > Could you provide a little more detail as to why this change is > > > included? > > > > > > + * debian/clean: Added compile file. > > > > The package doesn't compile two times in sequence with this > > file. When you run 'debuild' for the second time, it complain > > about changes in the orig (upstream). It is not a really > > necessary change. The user who wants to build the package can > > read the error message and remove the file himself. The change > > is just to give some comfort for who wants to build the package. > > In that case, we should skip it for the stable upload. > > Please feel free to go ahead with just the focus fix. > Ok, just the focus fix. Just did the upload to stable. regards, -- Herbert Parentes Fortes Neto (hpfn) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787120: RFS: par2cmdline/0.6.13-1
Uploaded. Thanks for maintaining this package. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#632656: dropbear: duplicate mount /dev/pts in initramfs
An arguably simpler alternative to copying mountpoint(1) is to grep through /proc/mounts. -- Guilhem. signature.asc Description: Digital signature
Bug#787207: cuneiform: FTBFS on arm64, ...
Source: cuneiform
Version: 1.1.0+dfsg-5
It failed to build, in a distinctive fashion ("browe dog"), on several
Debian architectures that have an unsigned char, arm64 among them:
https://buildd.debian.org/status/package.php?p=cuneiform&suite=sid
For what it's worth, I was able to build this package on arm64 simply
by adding " -fsigned-char" to the end of the line in debian/rules that
starts with "CFLAGS =".
If you wanted to fix the problem properly you could perhaps arrange to
compile some source files with and some without "-fsigned-char" and
thus discover, semi-automatically, which files contain the dodgy code.
By using "-funsigned-char" instead maybe you could even investigate
this problem on a system where plain char is signed.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787206: librpc-xml-perl: please make the build reproducible
Source: librpc-xml-perl Version: 0.78-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org Hi! While working on Debian's “reproducible builds” effort [1], we have noticed that librpc-xml-perl doesn't build reproducibly. The tool make_method adds timestamps into the comment of generated XML files. It would be nice, if they would not be included. The attached patch removes them. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/debian/patches/0002-Remove-timestamps-from-generated-xml-files.patch b/debian/patches/0002-Remove-timestamps-from-generated-xml-files.patch new file mode 100644 index 000..b797b1e --- /dev/null +++ b/debian/patches/0002-Remove-timestamps-from-generated-xml-files.patch @@ -0,0 +1,21 @@ +Index: librpc-xml-perl-0.78/etc/make_method +=== +--- librpc-xml-perl-0.78.orig/etc/make_method librpc-xml-perl-0.78/etc/make_method +@@ -363,7 +363,6 @@ sub write_file + } + } + +-my $date = scalar localtime; + my %typemap = ( + 'm' => 'method', + p => 'procedure', +@@ -399,7 +398,7 @@ sub write_file + + + diff --git a/debian/patches/series b/debian/patches/series index 71af6f7..42d2f3e 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ 0001-Explicitly-use-an-IPv4-socket-in-the-Net-Server-test.patch +0002-Remove-timestamps-from-generated-xml-files.patch signature.asc Description: OpenPGP digital signature
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, hello Detrick,
I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions:
(amd64 did not show the fault)
- apt-get install icecast2 liquidsoap liquidsoap-plugin-icecast
liquidsoap-plugin-lame liquidsoap-plugin-mad liquidsoap-plugin-ogg
liquidsoap-plugin-vorbis
- enable and start icecast2 (/etc/default/icecast2)
- get a mp3 file and put it to current directory as test.mp3
- create test.sh
- start liquidsoap in debugger "gdb --args /usr/bin/liquidsoap test.sh"
content of test.sh:
#!/usr/bin/liquidsoap
set("log.file.path","/dev/stdout")
myplaylist = single("test.mp3")
output.icecast(%mp3, host = "localhost", port = 8000, password = "hackme",
mount = "basic-radio.ogg", myplaylist)
(gdb) bt
#0 0xb76e30c9 in init_xrpow_core_sse () from
/usr/lib/i386-linux-gnu/libmp3lame.so.0
#1 0xb76d2ebf in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0
#2 0xb76d65e6 in CBR_iteration_loop () from
/usr/lib/i386-linux-gnu/libmp3lame.so.0
#3 0xb76c3e27 in lame_encode_mp3_frame () from
/usr/lib/i386-linux-gnu/libmp3lame.so.0
#4 0xb76c8e4f in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0
#5 0xb76c9b48 in lame_encode_buffer_float () from
/usr/lib/i386-linux-gnu/libmp3lame.so.0
#6 0xb781cf77 in ocaml_lame_encode_buffer_float () from
/usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs
#7 0xb781b72f in camlLame__fun_1175 () from
/usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs
#8 0x0820b06f in camlOutput__f_1354 ()
#9 0x0820b0c5 in camlOutput__fun_1740 ()
#10 0x0820b7dd in camlOutput__fun_1600 ()
#11 0x08257c6f in camlClock__fun_1848 ()
#12 0x08310b3c in camlList__fold_left_1073 ()
#13 0x08258740 in camlClock__fun_1813 ()
#14 0x082582a5 in camlClock__loop_1351 ()
#15 0x08258daa in camlClock__fun_2074 ()
#16 0x082703e3 in camlTutils__fun_1346 ()
#17 0x08307ac8 in camlThread__fun_1081 ()
#18 0x083612fa in caml_start_program ()
#19 0x0834a675 in ?? ()
#20 0xb7f1befb in start_thread (arg=0x79e8b781) at pthread_create.c:309
#21 0xcde0b850 in ?? ()
#22 0x79e8b781 in ?? ()
#23 0x8350b45b in ?? ()
#24 0x8dc314c4 in ?? ()
#25 0x00b6 in ?? ()
#26 0x27bc8d00 in ?? ()
#27 0x in ?? ()
Building libmp3lame0 with debug information:
- export DEB_BUILD_OPTIONS=nostrip
- apt-get build-dep libmp3lame0
- apt-get source libmp3lame0
- dpkg-buildpackage -b
- dpkg -i libmp3lame0_*.deb
- gdb --args /usr/bin/liquidsoap test.sh
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb49ffb40 (LWP 20251)]
init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575,
sum=0xb49fa5d0) at xmm_quantize_sub.c:73
73 vec_xrpow_max._m128 = _mm_set_ps1(0);
(gdb) bt
#0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575,
sum=0xb49fa5d0) at xmm_quantize_sub.c:73
#1 0xb76cf71f in init_xrpow (gfc=0x87318d0, cod_info=0x8731a00,
xrpow=0xb49fa6f4) at quantize.c:127
#2 0xb76d2cc6 in CBR_iteration_loop (gfc=0x87318d0, pe=0xb49fb0c4,
ms_ener_ratio=0xb49fb09c, ratio=0xb49fd06c) at quantize.c:2034
#3 0xb76c0c37 in lame_encode_mp3_frame (gfc=gfc@entry=0x87318d0,
inbuf_l=0x873e48c, inbuf_r=0x87422cc, mp3buf=mp3buf@entry=0xb4a081b9 "",
mp3buf_size=mp3buf_size@entry=8988) at encoder.c:518
#4 0xb76c5a22 in lame_encode_buffer_sample_t (mp3buf_size=9405,
mp3buf=0xb4a081b9 "", nsamples=, gfc=) at
lame.c:1786
#5 lame_encode_buffer_template (gfp=gfp@entry=0x865f580,
buffer_l=buffer_l@entry=0xb4a048e8, buffer_r=buffer_r@entry=0xb4a06480,
nsamples=nsamples@entry=1764, mp3buf=mp3buf@entry=0xb4a08018 "\377\373\220D",
mp3buf_size=mp3buf_size@entry=9405, pcm_type=pcm_type@entry=pcm_float_type,
aa=aa@entry=1, norm=norm@entry=1) at lame.c:1897
#6 0xb76c6648 in lame_encode_buffer_float (gfp=0x865f580, pcm_l=0xb4a048e8,
pcm_r=0xb4a06480, nsamples=1764, mp3buf=0xb4a08018 "\377\373\220D",
mp3buf_size=9405) at lame.c:1918
#7 0xb7819f77 in ocaml_lame_encode_buffer_float () from
/usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs
#8 0xb781872f in camlLame__fun_1175 () from
/usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs
#9 0x0820b07f in camlOutput__f_1354 ()
#10 0x0820b0d5 in camlOutput__fun_1740 ()
#11 0x0820b7ed in camlOutput__fun_1600 ()
#12 0x08257c7f in camlClock__fun_1848 ()
#13 0x08310b4c in camlList__fold_left_1073 ()
#14 0x08258750 in camlClock__fun_1813 ()
#15 0x082582b5 in camlClock__loop_1351 ()
#16 0x08258dba in camlClock__fun_2074 ()
#17 0x082703f3 in camlTutils__fun_1346 ()
#18 0x08307ad8 in camlThread__fun_1081 () at thread.ml:37
#19 0x08360506 in caml_start_program ()
#20 0x0834a6b4 in caml_thread_start ()
#21 0xb7f18efb in start_thread (arg=0x85e8b781) at pthread_create.c:309
#22 0x9de0b850 in ?? ()
#23 0x85e8b781 in ?? ()
#24 0x8350b47d in ?? ()
#25 0x8dc314c4 in ?? ()
#26 0x00b6 in ?? ()
#27 0x27bc8d00 in ?? ()
#28 0x in ?? ()
(gdb) bt full 1
#0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575,
sum=0xb49fa5d0) at xmm_quantize_sub.c:73
i =
tmp_max = 0
tmp_sum = 0
upper4 = 572
rest = 3
Bug#786765: RFS: python-zeroconf/0.17.1-1 [ITP]
Uploaded and tagged, thanks! -- WBR, wRAR signature.asc Description: Digital signature
Bug#786764: RFS: python-spur/0.3.14-1 [ITP]
Please run tests at the build time. ALso, "$(RM) -r .pybuild" in override_dh_auto_clean looks strange. -- WBR, wRAR signature.asc Description: Digital signature
Bug#787205: Keep 220 in unstable for a while
Package: systemd Version: 220-1 Severity: serious Argh, I screwed up my sbuild command this morning, and systemd (220-1) experimental; urgency=medium actually went to unstable: https://tracker.debian.org/news/687479 Now, we planned to land the experimental version in unstable around next week anyway, so it's not too bad. I didn't plan to do that on a Friday either; but at that point a revert is worse than just going through with it. There is nothing which is known to me to be a regression or broken. But let's keep 220 in unstable for a few days longer than just 5 days. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#787204: ITP: haskell-yi-rope -- Rope data structure used by Yi
Package: wnpp Severity: wishlist Owner: "Marcel Fourné" * Package name: haskell-yi-rope Version : 0.7.0.1 Upstream Author : Mateusz Kowalczyk * URL : https://hackage.haskell.org/package/yi-rope * License : GPL-2 Programming Lang: Haskell Description : Rope data structure used by Yi This is a Haskell library providing a rope data structure used by Yi This package is a new dependency for yi. Will be maintained as part of debian-haskell team. A sponsor will be needed for the upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
