Bug#745253: Please include cronjob to update the data
Package: ieee-data Version: 20131224.1 Severity: wishlist Hi, I'm considering making aircrack-ng recommend this package and use the data it provides instead of shipping another copy of the same data. My personal experience is that this data changes much more often than one might expect. For example, since you shipped the package to now: $ diff -u /usr/share/misc/oui.txt (curl -s http://standards.ieee.org/develop/regauth/oui/oui.txt)|diffstat 63 | 2766 - 1 file changed, 2571 insertions(+), 195 deletions(-) In order to keep this data updated, I think that shipping a cronjob that regularly updates it, is a good idea. Maybe shipping it on /etc/cron.weekly (or even /etc/cron.monthly), and it can be something as simple as: #!/bin/sh if ! ping -c1 standards.ieee.org /dev/null 21 ; then # no internet exit 0 fi update-oui /dev/null Regards! signature.asc Description: OpenPGP digital signature
Bug#744896: libsdl-perl: FTBFS on amd64 and s390x (failed test)
On Tue, 15 Apr 2014 22:53:40 +0200, Julien Cristau wrote: Source: libsdl-perl Version: 2.540-5 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, see the build logs linked from https://buildd.debian.org/status/logs.php?pkg=libsdl-perlver=2.540-5%2Bb1suite=sid Interesting bug. * It failed on the buildds. * It did not fail for Gianfranco in #745229. * It also works for me (cowbuilder sid amd64). * dod seems to imply in https://github.com/PerlGameDev/SDL/issues/260 that he can reproduce the problem, at least somehow. Where does this leave us? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nick Drake: Man In A Shed signature.asc Description: Digital Signature
Bug#745091: jing-trang: FTBFS with Java 8: ServiceConfigurationError: Illegal configuration-file syntax
Control: tags -1 + help Hello, Emmanuel Bourg, le Thu 17 Apr 2014 23:39:07 +0200, a écrit : /«BUILDDIR»/jing-trang-20131210+dfsg+1/build.xml:42: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory: jar:file:/usr/share/java/Saxon-HE.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102) I have to say I'm not even sure where to start looking for the issue, so will most likely need help on this. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745254: python-osmgpsmap: New upstream release, fixing #744868
Package: python-osmgpsmap Version: 0.7.3-3 Severity: normal Dear Maintainer, experiencing the problem described in #744868 (gpxviewer: GPXViewer is not showing OSM map tiles) it turns out, that the current debian version of python- osmgpsmap does not provide a valid user-agent string which leads to osm not delivering any tiles. This is fixed in the upstream-release of (python-)osmgpsmap. Would it be possible to package the current version? Thanks and best regards, Oliver -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-osmgpsmap depends on: ii libatk1.0-0 2.12.0-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libfontconfig1 2.11.0-5 ii libfreetype62.5.2-1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libosmgpsmap2 0.7.3-3 ii libpango1.0-0 1.36.3-1 ii libsoup2.4-12.46.0-2 ii python 2.7.5-5 ii python-gtk2 2.24.0-3+b1 python-osmgpsmap recommends no packages. Versions of packages python-osmgpsmap suggests: pn libosmgpsmap2-dbg none -- 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#742993: closed by Rahul Amaram amaramra...@users.sourceforge.net (Done: python-pycalendar: Please update to new svn snapshot)
Hi, On Sun, Apr 13, 2014 at 05:39:24PM +0530, Rahul Amaram wrote: URL: https://svn.calendarserver.org/repository/calendarserver/PyCalendar/branches/CalendarServer-5.2 Last Changed Rev: 13177 I am anyway planning to update calendarserver in the next couple of weeks. Will the above pycalendar version work for you? Looking at the diff I guess we need current trunk. But as I said an upload to experimental would be sufficient for now and we an hopefully run with the next release. My offer to handle the upload to experimental still holds. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743374: #743374: not a bug (libopencl1 isn't hardware specific)
nvidia-libopencl1 is OpenCL 1.1, not 1.2, and pyopencl hence doesn't work with it: https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1174205 You can still use pyopencl with Nvidia hardware, as the hardware-specific part is opencl-icd not libopencl1. The choices for this are: nvidia-opencl-icd (Nvidia GPUs) mesa-opencl-icd (Radeon GPUs; plans to support more in the future) amd-opencl-icd (Radeon GPUs, and CPUs) amd-opencl-icd-legacy (older Radeon GPUs) beignet (Intel GPUs) At present it is necessary to choose the correct opencl-icd manually, as the package management system doesn't know what GPU you have, and installing them all doesn't work as beignet crashes if its hardware is not present. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745255: Not enough room for initial game mode text
Package: gweled Version: 0.9.1-3+b1 Severity: normal If the board size is set to medium or small, the initial game mode text (normal/timed/endless) does not have enough room and gets cut off. This becomes worse if the system has a larger text size set, such as for a high-DPI screen or the accessibility-mode large text option. - Josh Triplett -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-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 Versions of packages gweled depends on: ii libatk1.0-0 2.12.0-1 ii libc62.18-4 ii libcairo21.12.16-2 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.4.9-1.1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-0 2.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libmikmod3 3.3.6-2 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii librsvg2-2 2.40.2-1 gweled recommends no packages. gweled 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#745250: wheezy-pu: package libdatetime-timezone-perl/1:1.58-1+2014a
Control: tags -1 + pending On 2014-04-19 19:56, gregor herrmann wrote: On Sat, 19 Apr 2014 19:47:15 +0100, Adam D. Barratt wrote: On 2014-04-19 19:39, gregor herrmann wrote: [...] However: The update includes the Olson DB versions 2013i and 2014a (but not yet 2014b). Given that this would bring it in line with the tzdata upload in p-u, if the upload could be made this evening then I'd be prepared to accept it for 7.5. Thank you! Uploaded. Flagged for acceptance; thanks. 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#743717: closed by Thomas Goirand z...@debian.org (Bug#743717: fixed in subunit 0.0.18-3)
Hi Thomas and Ivo, The build still fails on all architectures. There is probably something that happens in the local build in your environment that doesn't work on the buildds. I'm afraid that's the problem. I managed to rebuild the package on fresh i386 and amd64 cowbuild env with no problem. Best regards, -- Gonéri pgp9RiB4VAC2X.pgp Description: PGP signature
Bug#743402: capnproto: failed to run test on mips64el
Okay, thanks -- confirmed with upstream that the issue is a little trickier
to fix than he first thought. He doesn't have access to MIPS hardware to
test out his ideas for a fix, though. I'm going to ask around a little
see if we can get direct access to a MIPS system to attack this bug. I'll
keep you posted.
On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:
dpkg-buildpackage -B
On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
Weird. Can I ask what commands you're using to build the package from the
github repo?
On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com wrote:
seems still the same problem
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make all-recursive
make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
Testsuite summary for Capn Proto 0.4.1
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to capnpr...@googlegroups.com
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
dh_auto_test: make -j1 check returned exit code 2
On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
Great, thanks again. Seems like this may have been an upstream bug.
I've
pushed a patch -- can you try the latest code on master?
http://github.com/thomaslee/capnproto-debian
Cheers,
Tom
On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
wrote:
On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
Thanks! Can you try the same thing, but instead of passing an empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
__builtin_nanf(0)
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fa0 7ff4 7ff4
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com
wrote:
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
wrote:
Hey Yunqiang,
I spoke to the upstream maintainer. He's asked if you can
compile
run
this
small C program (with and without optimizations) and to send the
output
from
both:
// begin
#include stdio.h
#include inttypes.h
#include string.h
int main() {
float nanf = __builtin_nanf();
double nand = __builtin_nan();
double nancast = nanf;
uint32_t nanfi;
uint64_t nandi;
uint64_t nancasti;
memcpy(nanfi, nanf, 4);
memcpy(nandi, nand, 8);
memcpy(nancasti, nancast, 8);
printf(%x %llx %llx\n, nanfi, nandi, nancasti);
return 0;
}
// end
Thanks!
Tom
On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com
wrote:
make check-TESTS
make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make all-recursive
make[7]:
Bug#716927: grub-efi-amd64: grub-efi doesn't support HFS+ EFI partitions
Hi Mike, So finally, I had a time to test what you have written. On Thu, Apr 03, 2014 at 02:21:03PM +0900, Mike Hommey wrote: Actually, it works, but requires the mach_kernel file to be in /boot/efi/EFI/debian. Once you're past that, all chances are you get an unbootable system. At least that's the state mine is right now. That's correct. After placing the mach_kernel file in /boot/efi/EFI/debian the system gets in an unbootable state even if grub-install says everything is ok. On Thu, Apr 03, 2014 at 05:28:04PM +0900, Mike Hommey wrote: So, the problem is that the new grub expecting and putting stuff in /boot/efi/EFI/debian conflicts with my previous hack. Once I purge /boot/efi/System, and rerun grub-install, I can finally get a bootable system. I have tried to purge /boot/efi/System and rerun grub-install but my system is still unbootable. I also tried the following: with a bootable system in efi mode using grub 2.00-22 with your hack, I purged grub completely (apt-get --purge remove grub*). Then I started the procedure from scratch using this latest version but this didn't work either for me So for the moments, I have just gotten back to grub-efi-amd64 version 2.00-22. I marked as in hold: grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin grub2-common. I find your hack very convenient (many things work better in efi mode in my macbook). So I prefer to stay with this old version more time to see if I get it working than use grub-pc. Regards -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745256:
package: wnpp Severity: wishlist Owner: 'Pau Garcia i Quiles' pgqui...@elpauer.org *Package Name : jquery-jplayer-circleplayer Version : 2.6.0 Upstream Author : HappyWorm. *URL : https://www.jplayer.org *License : GPL *Description : Circle Player skin for jPlayer This is another official skin for jquery-jplayer -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745257: almanah: FTBFS with clang instead of gcc
Package: pkg-name
Severity: minor
Usertags: clang-ftbfs
User: pkg-llvm-t...@lists.alioth.debian.org
Tag: patch
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Thanks,
Arthur
diff -Naur almanah.orig/almanah-0.11.0/debian/changelog almanah/almanah-0.11.0/debian/changelog
--- almanah.orig/almanah-0.11.0/debian/changelog 2014-04-17 14:20:12.216199092 -0500
+++ almanah/almanah-0.11.0/debian/changelog 2014-04-19 15:28:31.686253045 -0500
@@ -1,3 +1,11 @@
+almanah (0.11.0-2) unstable; urgency=low
+
+ * Fix FTBFS with clang
+- Fixed the non-void function should not return a value error in
+ src/widgets/tag.c
+
+ -- Arthur Marble art...@info9.net Sat, 19 Apr 2014 15:28:31 -0500
+
almanah (0.11.0-1) unstable; urgency=low
* Imported Upstream version 0.11.0
diff -Naur almanah.orig/almanah-0.11.0/debian/patches/clang-ftbfs.diff almanah/almanah-0.11.0/debian/patches/clang-ftbfs.diff
--- almanah.orig/almanah-0.11.0/debian/patches/clang-ftbfs.diff 1969-12-31 18:00:00.0 -0600
+++ almanah/almanah-0.11.0/debian/patches/clang-ftbfs.diff 2014-04-19 15:31:00.182249729 -0500
@@ -0,0 +1,22 @@
+--- a/src/widgets/tag.c
b/src/widgets/tag.c
+@@ -436,7 +436,7 @@ almanah_tag_get_tag (AlmanahTag *tag_wid
+ return tag_widget-priv-tag;
+ }
+
+-void
++int
+ almanah_tag_remove (AlmanahTag *tag_widget)
+ {
+ g_return_val_if_fail (ALMANAH_IS_TAG (tag_widget), NULL);
+--- a/src/widgets/tag.h
b/src/widgets/tag.h
+@@ -45,7 +45,7 @@ typedef struct {
+ GTypealmanah_tag_get_type (void) G_GNUC_CONST;
+ GtkWidget *almanah_tag_new (const gchar *tag);
+ const gchar *almanah_tag_get_tag (AlmanahTag *tag_widget);
+-void almanah_tag_remove (AlmanahTag *tag_widget);
++int almanah_tag_remove (AlmanahTag *tag_widget);
+
+ G_END_DECLS
+
Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database
Well, goal of all packages should be that they should be as lintian clean as possible. As you said, 5.5 is in the archives, I say 10.0 is not; for many DDs lintian cleaness is a requirement for sponsoring. (Also note that lintian evolves and therefor will report now issues that where not detected at that time 5.5 was introduced) OK, I am determined to make both 10.0 and 5.5 as Lintian clean as possible now, including even spelling errors. BTW, when you iterate, can you always upload to mentors afterwards? Yes, I'll do so. The latest version is uploding now and soon visible at http://mentors.debian.net/package/mariadb-10.0 Ok, browsing the source I have the impression that the source of it is indeed maridb-5.5. (Some residual references on it). So I suggest you review every single file in your debian directory. I saw already some problems (random ordering): - d/control builds same binary packages as mdb-5.5. That won't work. MariaDB 10.0 is intended to supersede 5.5, and in future the mariadb-common, libmariadbclient etc packages are supposed to come from 10.0 source package. Should I maybe disable them at this stage? - d/copyright needs to be updated, please use dep5 format The format does follow http://dep.debian.net/deps/dep5/ and I now fixed the 5.5 typos in it. I also grepped debian/* for 5.5. to make sure there are no other 5.5 typos. - d/patches please add dep3 compliant headers (using quilt header -e --dep3) I have now used the '## DP:' markup as Lintian suggested, but I will change the patches I've done myself to dep3 format now. - some d/patches are fuzzy, needs to be refreshed What does this mean? That the line numbers don't match? What tool do you use to detect fuzzyness? - I saw in some postinst a call to ldconfig. This is a policy violation the way it is. However, debhelper will take care of it, so remove this postinst script. e.g libmariadbclient18.postinst but there are more postinsts to be checked. Probably you can just remove the postinstse here. MySQL 5.6 does not seem to use neither of these postinstalls, so I removed them. Will later run more tests to make sure there are no regressions. But to be honest I don't fully understand what they do, and that is the reason I was afraid to remove them earlier when I read about ldconfig and suspected they might be obsolete. - d/changelog for new packages is just Initial Upload (Closes: #ITP-Bug) Done. - (personal taste) please review if d/rules can be shortened and converted to short debhelper formart.. Some rules look a little weird, too. For example, the ha_cassandra.so detection: It is there (due to B-D) or not. And, the change to the *.install file is nowhere undone. Yes, this is a hack. But I think it is the least ugly of all solutions. I added more comments to d/rules to describe it. (There is no B-D on libthrift.dev on d/control) Libthrift-dev is not in Debian, so I cannot depend on it, but hope to use the same Debian packaging and rules file to build MariaDB 10.0 on an environment with manually installed libthrift-dev. The manpages can also be installed by debhelper (I you feel so, I really suggest to switch to short debhelper and then add the really required pieces) I use the same format as http://anonscm.debian.org/gitweb/?p=pkg-mysql/mysql-5.6.git;a=blob;f=debian/rules to stay a bit more compatible. Isn't this format already the short debhelper format, does some other debhelper format exist? - There are many conflicts against mysql. Are they really needed? It would be best if they could life in coexistance, at least co-installable. Yes, only the -common and shared libs are co-installable, the other stuff is not. This part has been extensively reviewed in multiple discussions with all the MySQL variant packagers and this is how all the virtual-mysql-packages are now defined. That does not mean it is perfect, but I don't think there is any other solution at the moment. (Stopping here as running out of time) Ok, thanks again for your feedback on the other details nobody else so far noticed! -- Check out our blog at http://seravo.fi/blog and follow @ottokekalainen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682094: nautilus: report 'read-only' when trying to write to a writable USB volume - solution
Package: nautilus Version: 3.4.2-1+build1 Followup-For: Bug #682094 Dear Maintainer, I experienced the same with with a regular vfat usb stick. Any writing operation triggers a 'target is readonly' (or similar) error message in Nautilus, while I have write access, cp, mkdir, etc. work in a terminal. There is many similar reports for Ubuntu and Debian online, see: http://google.com/search?q=nautilus+usb+read+only This one offers also a solution: http://forums.debian.net/viewtopic.php?f=10t=107470 The lines corresponding to usb drives in /etc/fstab seems to cause the problem, and removing (or commenting out) them solves it. This work around worked for me, as well! I hava had in /etc/fstab the lines: /dev/sdb1 /media/usb0 autorw,user,noauto 0 0 /dev/sdb2 /media/usb1 autorw,user,noauto 0 0 Based on this, I hope this flaw can be traced down and sorted out easily. Andras -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages nautilus depends on: ii desktop-file-utils 0.20-0.1 ii gsettings-desktop-schemas 3.4.2-3 ii gvfs 1.12.3-4 ii libatk1.0-02.4.0-2 ii libc6 2.13-38+deb7u1 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libexempi3 2.2.0-1 ii libexif12 0.6.20-3 ii libgail-3-03.4.2-7 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libglib2.0-data2.33.12+really2.32.4-5 ii libgnome-desktop-3-2 3.4.2-1 ii libgtk-3-0 3.4.2-7 ii libnautilus-extension1a3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libselinux12.1.9-5 ii libtracker-sparql-0.14-0 0.14.1-3 ii libx11-6 2:1.5.0-1+deb7u1 ii libxml22.8.0+dfsg1-7+nmu3 ii nautilus-data 3.4.2-1+build1 ii shared-mime-info 1.0-1+b1 Versions of packages nautilus recommends: ii brasero 3.4.1-4 ii eject2.1.5+deb1+cvs20081104-13 ii gnome-sushi 0.4.1-3 ii gvfs-backends1.12.3-4 ii librsvg2-common 2.36.1-2 -- 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#745258: libnss-cache: FTBFS with clang instead of gcc
Package: pkg-name Severity: minor Usertags: clang-ftbfs User: pkg-llvm-t...@lists.alioth.debian.org Tag: patch Hello, Using the rebuild infrastructure, your package fails to build with clang (instead of gcc). Thanks, Arthur diff -Naur libnss-cache.orig/libnss-cache-0.11/debian/changelog libnss-cache/libnss-cache-0.11/debian/changelog --- libnss-cache.orig/libnss-cache-0.11/debian/changelog 2014-04-19 15:45:41.830230040 -0500 +++ libnss-cache/libnss-cache-0.11/debian/changelog 2014-04-19 16:02:56.334206937 -0500 @@ -1,3 +1,11 @@ +libnss-cache (0.11-2) unstable; urgency=low + + * Fix FTBFS with clang +- Fixed the potential usage of an uninitialized variable error in + nss_cache.c + + -- Arthur Marble art...@info9.net Sat, 19 Apr 2014 16:02:56 -0500 + libnss-cache (0.11-1) unstable; urgency=medium * New upstream release. diff -Naur libnss-cache.orig/libnss-cache-0.11/debian/patches/clang-ftbfs.diff libnss-cache/libnss-cache-0.11/debian/patches/clang-ftbfs.diff --- libnss-cache.orig/libnss-cache-0.11/debian/patches/clang-ftbfs.diff 1969-12-31 18:00:00.0 -0600 +++ libnss-cache/libnss-cache-0.11/debian/patches/clang-ftbfs.diff 2014-04-19 16:01:46.890208487 -0500 @@ -0,0 +1,11 @@ +--- a/nss_cache.c b/nss_cache.c +@@ -80,7 +80,7 @@ enum nss_status _nss_cache_bsearch2(stru + FILE *system_file_stream = NULL; + struct stat system_file; + struct stat sorted_file; +- enum nss_status ret; ++ enum nss_status ret = 100; + long offset = 0; + void* mapped_data = NULL; + diff -Naur libnss-cache.orig/libnss-cache-0.11/debian/patches/series libnss-cache/libnss-cache-0.11/debian/patches/series --- libnss-cache.orig/libnss-cache-0.11/debian/patches/series 1969-12-31 18:00:00.0 -0600 +++ libnss-cache/libnss-cache-0.11/debian/patches/series 2014-04-19 15:46:35.366228844 -0500 @@ -0,0 +1 @@ +clang-ftbfs.diff
Bug#745257: almanah: FTBFS with clang instead of gcc
Control: reassign -1 almanah
On Sb, 19 apr 14, 15:32:45, Arthur Marble wrote:
Package: pkg-name
Severity: minor
Usertags: clang-ftbfs
User: pkg-llvm-t...@lists.alioth.debian.org
Tag: patch
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Thanks,
Arthur
diff -Naur almanah.orig/almanah-0.11.0/debian/changelog
almanah/almanah-0.11.0/debian/changelog
--- almanah.orig/almanah-0.11.0/debian/changelog 2014-04-17
14:20:12.216199092 -0500
+++ almanah/almanah-0.11.0/debian/changelog 2014-04-19 15:28:31.686253045
-0500
@@ -1,3 +1,11 @@
+almanah (0.11.0-2) unstable; urgency=low
+
+ * Fix FTBFS with clang
+- Fixed the non-void function should not return a value error in
+ src/widgets/tag.c
+
+ -- Arthur Marble art...@info9.net Sat, 19 Apr 2014 15:28:31 -0500
+
almanah (0.11.0-1) unstable; urgency=low
* Imported Upstream version 0.11.0
diff -Naur almanah.orig/almanah-0.11.0/debian/patches/clang-ftbfs.diff
almanah/almanah-0.11.0/debian/patches/clang-ftbfs.diff
--- almanah.orig/almanah-0.11.0/debian/patches/clang-ftbfs.diff
1969-12-31 18:00:00.0 -0600
+++ almanah/almanah-0.11.0/debian/patches/clang-ftbfs.diff2014-04-19
15:31:00.182249729 -0500
@@ -0,0 +1,22 @@
+--- a/src/widgets/tag.c
b/src/widgets/tag.c
+@@ -436,7 +436,7 @@ almanah_tag_get_tag (AlmanahTag *tag_wid
+ return tag_widget-priv-tag;
+ }
+
+-void
++int
+ almanah_tag_remove (AlmanahTag *tag_widget)
+ {
+ g_return_val_if_fail (ALMANAH_IS_TAG (tag_widget), NULL);
+--- a/src/widgets/tag.h
b/src/widgets/tag.h
+@@ -45,7 +45,7 @@ typedef struct {
+ GTypealmanah_tag_get_type (void) G_GNUC_CONST;
+ GtkWidget *almanah_tag_new (const gchar *tag);
+ const gchar *almanah_tag_get_tag (AlmanahTag *tag_widget);
+-void almanah_tag_remove (AlmanahTag *tag_widget);
++int almanah_tag_remove (AlmanahTag *tag_widget);
+
+ G_END_DECLS
+
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
Bug#745251: accerciser crashes in cairo_status when selecting an object
I can avoid crashes by inserting an immediate return in highlight method src/lib/accerciser/node.py. So something inside the highlighting code goes wrong. Jarek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745215: /sbin/cfdisk: Installation doesn't correctly detect disks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/19/2014 12:23 AM, Nigel Horne wrote: Package: util-linux Version: 2.20.1-5.7 Severity: normal File: /sbin/cfdisk Dear Maintainer, I've tried three versions of Debian and all fail to correctly detect the disks on my new machine. I've tried 'stable' x86 and amd64, and 'testing' amd64. I have 2 2TB disks formatted as NTFS which I want to repartition. However the intaller (cfdisk?) claims that the 1st drive has two partitions (300MB and the rest) - it doesn't it only has one, and the 2nd drive has no paritions and no data - that's also wrong it has one partition with data on it. I can't install Debian on this machine and I'd really like it to be dual-boot. Please provide the output of of parted -l -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTUunXAAoJEI5FoCIzSKrw+vEIAJ1Zy93zHEDGduXnTramWcse zkaZpWkkA0ijhdG3XqdILZQvoMpxGN48mNvRzsSL1EclgYhQmGUYYYRGbKOsvFUI Mcu1n35+wq1X9zNJEbcQiP22VnATfXbRnItiL/CcjMKYv7sGq+CHefLCEdVQryuh AeQRJLKB6TbXpfuvBCEeorZG2exoGLgdQh6LT7yunYYhjYdvQ6MdWGcq7Qed7Ior L7AzhcNPTSw25A8JefQqd5LY79sbMfMKQVf1kDHOt1FmD5q9jTatTpVG5f24w6XL MR3l+xgoIMajsX70fA6s2gqyGJZKLnUQHoKtz4VHGmcrqvxLJ2E1crusprdUbeg= =QVKZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743402: capnproto: failed to run test on mips64el
I can provide you a porterbox for remote access.
Please give me your ssh public key with gpg signed.
On Sun, Apr 20, 2014 at 4:00 AM, Tom Lee deb...@tomlee.co wrote:
Okay, thanks -- confirmed with upstream that the issue is a little trickier
to fix than he first thought. He doesn't have access to MIPS hardware to
test out his ideas for a fix, though. I'm going to ask around a little see
if we can get direct access to a MIPS system to attack this bug. I'll keep
you posted.
On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:
dpkg-buildpackage -B
On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
Weird. Can I ask what commands you're using to build the package from
the
github repo?
On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com wrote:
seems still the same problem
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make all-recursive
make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
Testsuite summary for Capn Proto 0.4.1
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to capnpr...@googlegroups.com
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
dh_auto_test: make -j1 check returned exit code 2
On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
Great, thanks again. Seems like this may have been an upstream bug.
I've
pushed a patch -- can you try the latest code on master?
http://github.com/thomaslee/capnproto-debian
Cheers,
Tom
On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
wrote:
On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
Thanks! Can you try the same thing, but instead of passing an
empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
__builtin_nanf(0)
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fa0 7ff4 7ff4
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com
wrote:
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
wrote:
Hey Yunqiang,
I spoke to the upstream maintainer. He's asked if you can
compile
run
this
small C program (with and without optimizations) and to send
the
output
from
both:
// begin
#include stdio.h
#include inttypes.h
#include string.h
int main() {
float nanf = __builtin_nanf();
double nand = __builtin_nan();
double nancast = nanf;
uint32_t nanfi;
uint64_t nandi;
uint64_t nancasti;
memcpy(nanfi, nanf, 4);
memcpy(nandi, nand, 8);
memcpy(nancasti, nancast, 8);
printf(%x %llx %llx\n, nanfi, nandi, nancasti);
return 0;
}
// end
Thanks!
Tom
On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su
wzss...@gmail.com
wrote:
make check-TESTS
make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
Bug#732349: Autoreconfing libgc
Package: src:libgc
Version: 7.2d-6
Followup-For: Bug #732349
Thanks for updating the package to use autoreconf, which ought to have
fixed it for arm64, butin fact this hasn't worked, as explained in the
long thread on debian-devel this week about autotools-dev and
dh-autoreconf.
https://lists.debian.org/debian-devel/2014/04/msg00459.html
Because you used the upstream autogen.sh file (not unreasonably), and
the config.sub (but not guess, oddly) in the package was too old it
still didn't get updated files.
And in fact it turns out that the upstream autogen.sh file doesn't do
anything useful and just breaks building in the 'new arch'
circumstance it's best not used:
https://lists.debian.org/debian-devel/2014/04/msg00497.html
So here's a patch that works.
(actually it just configures correctly and tries to build with this but falls
over for a different reason:
In file included from ./include/private/gc_priv.h:94:0,
from allchblk.c:17:
./include/private/gcconfig.h:518:5: error: #error The collector has not been
ported to this machine/OS combinat
ion.
# error The collector has not been ported to this machine/OS combination.
^
In file included from ./include/private/gc_priv.h:94:0,
from allchblk.c:17:
./include/private/gcconfig.h:2433:3: error: #error -- undefined ALIGNMENT
# error -- undefined ALIGNMENT
The fix for this is in
http://patches.ubuntu.com/libg/libgc/libgc_1:7.2d-5ubuntu2.patch but
I've not integrated and tested that, and may not have time for a while
as I'm off the Opensuse conf and then holiday for a week or two.
At least part of that patch is bogus - pkg-kde-tools and symbolhelped
is fine on arm64 now, but the rest looks about right.
So, thanks for being a poster-boy for the dh-autoreconf discussion - I
think we've reached a sensible place on all that. And either apply
that ubuntu patch too to get this to work or wait till I have time to
do so.
You can see build attempts for libgc on arm64 here:
http://buildd.debian-ports.org/status/package.php?p=libgcsuite=sid
And I can get you access to a machine if you need it.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
diff -Nru libgc-7.2d/debian/changelog libgc-7.2d/debian/changelog
--- libgc-7.2d/debian/changelog 2013-12-23 11:49:36.0 +
+++ libgc-7.2d/debian/changelog 2014-04-17 16:25:49.0 +
@@ -1,3 +1,10 @@
+libgc (1:7.2d-6.1) unreleased; urgency=low
+
+ * Non-maintainer upload.
+ * Fix autoreconfing to include updated config.sub,guess files
+
+ -- Buildd user bui...@turfan.debian.net Thu, 17 Apr 2014 16:25:03 +
+
libgc (1:7.2d-6) unstable; urgency=medium
* Run full autoreconf during build
diff -Nru libgc-7.2d/debian/control libgc-7.2d/debian/control
--- libgc-7.2d/debian/control 2013-12-23 11:28:03.0 +
+++ libgc-7.2d/debian/control 2014-04-17 17:17:46.0 +
@@ -3,7 +3,8 @@
Section: libs
Priority: standard
Build-Depends: debhelper (= 9),
- autoconf,
+ dh-autoreconf,
+ autotools-dev,
libatomic-ops-dev (= 7.3~),
pkg-config,
pkg-kde-tools
diff -Nru libgc-7.2d/debian/rules libgc-7.2d/debian/rules
--- libgc-7.2d/debian/rules 2013-12-23 11:28:27.0 +
+++ libgc-7.2d/debian/rules 2014-04-19 01:54:44.0 +
@@ -8,7 +8,7 @@
LDFLAGS += -pthread
%:
- dh $@ --with pkgkde_symbolshelper
+ dh $@ --with autotools-dev,autoreconf,pkgkde_symbolshelper
override_dh_auto_configure:
[ ! -d libatomic_ops-1.2 ] || mv libatomic_ops-1.2 libatomic_ops-1.2.bak
@@ -27,9 +27,6 @@
--build=$(DEB_BUILD_GNU_TYPE) \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
-override_dh_autoreconf:
- dh_autoreconf ./autogen.sh
-
override_dh_auto_test:
$(MAKE) check
Bug#733705: Ping?
Control: tags -1 - moreinfo As far as I can tell this is ready to be removed. Any other issues? -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#740406: Ping?
This should be ready to be removed. -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#742427: Ping?
This is ready to be removed. There are still about 6 untransitioned packages but they have FTBFS bugs and I don't think any of these are important enough to block this removal. -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#745259: ITP: apt-transport-tor -- APT transport for anonymous package downloads via Tor
Package: wnpp Severity: wishlist Owner: Tim Retout dioc...@debian.org * Package name: apt-transport-tor Version : 0.1 Upstream Author : Tim Retout dioc...@debian.org * URL : https://github.com/diocles/apt-transport-tor * License : GPL Programming Lang: C++ Description : APT transport for anonymous package downloads via Tor Provides support in APT for downloading packages anonymously via the Tor network. . APT already includes mechanisms for guaranteeing the authenticity of the packages you download. However, an adversary sniffing your network traffic can still see what software you are installing. . Install apt-transport-tor, edit your sources.list to include only tor:// URLs, and you can apt-get install anarchism without fear of reprisals. This software works! It was forked from the apt HTTPS transport. It doesn't yet have a build system or any packaging, but hopefully that's the easy part. Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745260: sysvinit: Please fix hurd-console addition to inittab on Hurd
Package: sysvinit
Version: 2.88dsf-53
Severity: wishlist
Tags: patch
On hurd, attached patch fixes hurd-console addition to inittab if inittab file
is already present and fixes /libexec/getty replacement in commented out lines
as well.
Thanks for considering.
commit c7eb1326cf1bfb930298a13cb30a5e4902ead65d
Author: Gabriele Giacone 1o5g4...@gmail.com
Date: Tue Apr 1 10:54:01 2014 +0200
Fix hurd-console addition and getty pathnames in inittab [hurd].
diff --git a/debian/changelog b/debian/changelog
index d3ba717..86a90a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sysvinit (2.88dsf-55) UNRELEASED; urgency=medium
+
+ * sysv-rc:
+- [hurd] Fix hurd-console addition to inittab if inittab already existent.
+- [hurd] Replace /libexec/getty in commented out lines as well.
+
+ -- Gabriele Giacone 1o5g4...@gmail.com Mon, 07 Apr 2014 12:59:55 +0200
+
sysvinit (2.88dsf-54) experimental; urgency=medium
[ Justus Winter ]
diff --git a/debian/sysvinit-core.config b/debian/sysvinit-core.config
index ce34f63..a828037 100755
--- a/debian/sysvinit-core.config
+++ b/debian/sysvinit-core.config
@@ -22,7 +22,8 @@ case $1 in
| md5sum --status --check -; then
# The file is unmodified, update it silently.
:
- elif fgrep -q '/libexec/getty' /etc/inittab; then
+ elif [ `fgrep -c -e '/libexec/getty' /etc/inittab` -gt 0 ] || \
+ [ `grep -c '^c:' /etc/inittab` -eq 0 ]; then
db_input low sysvinit/hurd-fix-inittab || true
db_go
fi
diff --git a/debian/sysvinit-core.postinst b/debian/sysvinit-core.postinst
index d78fe86..44b6fba 100755
--- a/debian/sysvinit-core.postinst
+++ b/debian/sysvinit-core.postinst
@@ -86,15 +86,27 @@ rm -f /etc/ioctl.save
if [ ! -f /etc/inittab ]
then
cp -p /usr/share/sysvinit/inittab /etc/inittab
-elif [ $(uname) = GNU ] fgrep -q '/libexec/getty' /etc/inittab; then
- rm -f -- /etc/inittab.dpkg-new
- sed -e '/^[^#]/ s|/libexec/getty|/sbin/getty|' \
- /etc/inittab /etc/inittab.dpkg-new
-
- db_get sysvinit/hurd-fix-inittab
- if [ ${RET} = true ]; then
- mv -- /etc/inittab /etc/inittab.dpkg-old
- mv -- /etc/inittab.dpkg-new /etc/inittab
+elif [ $(uname) = GNU ]; then
+ ITAB=/etc/inittab
+ ITABNEW=${ITAB}.dpkg-new
+ cp $ITAB $ITABNEW
+ if fgrep -q '/libexec/getty' $ITABNEW; then
+ sed -e 's|/libexec/getty|/sbin/getty|' \
+ -i $ITABNEW
+ fi
+ if ! grep -q '^c:' $ITABNEW; then
+ sed -e '/^6:/a c:23:respawn:/sbin/getty 38400 console' \
+ -i $ITABNEW
+ fi
+
+ if ! diff $ITAB $ITABNEW /dev/null; then
+ db_get sysvinit/hurd-fix-inittab
+ if [ ${RET} = true ]; then
+ mv -- $ITAB ${ITAB}.dpkg-old
+ mv -- $ITABNEW $ITAB
+ fi
+ else
+ rm -f -- $ITABNEW
fi
fi
diff --git a/debian/sysvinit-core.templates b/debian/sysvinit-core.templates
index 06c693c..759bbff 100644
--- a/debian/sysvinit-core.templates
+++ b/debian/sysvinit-core.templates
@@ -1,14 +1,14 @@
Template: sysvinit/hurd-fix-inittab
Type: boolean
-_Description: Update getty file names in /etc/inittab?
- Your /etc/inittab seems to use /libexec/getty as getty. The default
- inittab has been changed, however your /etc/inittab has been
- modified. Note that sysvinit has never been used to boot an Hurd
- system, so any errors in that file would not have shown up.
+_Description: Update getty pathnames and add hurd-console?
+ Your /etc/inittab seems to use /libexec/getty as getty and/or to miss
+ hurd-console entry. The default inittab has been changed, however your
+ /etc/inittab has been modified. Note that sysvinit has never been used
+ to boot an Hurd system, so any errors in that file would not have shown
+ up.
.
- If you want to change /etc/inittab to use /sbin/getty as getty, choose
- yes. If you choose yes, a backup will be stored in /etc/inittab.dpkg-old.
+ If you allow this change, a backup will be stored in /etc/inittab.dpkg-old.
.
- If you choose no, an updated inittab will be written to
+ If you don't allow this change, an updated inittab will be written to
/etc/inittab.dpkg-new. Please review the changes and update your
/etc/inittab accordingly.
Bug#745260: [PATCH 1/2] Fix hurd-console addition and getty pathnames in inittab [hurd].
On Tue, Apr 8, 2014 at 1:31 AM, Samuel Thibault sthiba...@debian.org wrote: Yes, this seems good. Applied. Thanks for reviewing. -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745143: pulseaudio: Getting serious pops and clicks in audio in Debian 7.4 64-bit.
Hi Felipe, Well, for various reasons I actually ended up going back from Kubuntu to Debian 7.4. And inadvertently I installed 32-bit 7.4 instead of 64-bit 7.4. For whatever reason, I now do not have have the audio problem, at least not nearly as severely. This is based on 5 minutes of listening. I really need to test it for an hour, but before I was getting clicks and pops every several seconds. Besides the 32 bit and 64 bit difference, the only other thing I can think of was that I had installed apt-get install sox apt-get install pavucontrol before I had tried to listening to music on (64 bit), so I am not sure which it was. If I do anything that causes it to come back I will email Debian bug tracking. Thanks. - Scott On Sat, Apr 19, 2014 at 8:59 AM, Felipe Sateler fsate...@debian.org wrote: Hi Scott On Sat, Apr 19, 2014 at 8:59 AM, Scott Borisch scott.bori...@gmail.com wrote: Hi Felipe, 1) I actually ended up re-installing with Kubuntu 13.10 64-bit, (1) to see if it fixed the problem, but (2) because there where unrelated reasons I decided Kubuntu would work better for me. 2) However, I still get the pop/click/dropouts in Kubuntu, albeit not as severely. 3) I have attached 5 log files. (1) The ones with pa in the name are from pulseaudio - command. The ones with 1404 in the name are from Kubuntu 14.04 (installed directly from 13.10 upgrade GUI -- I had installed 13.10 from CD) -- the ones without 1404 in the name are Kubuntu 13.10 64-bit. (3) The ones with pactl in the name are from the pactl command. 4) Based on the output in the pa***.log files, I'm not sure the command worked as desired (albeit under Kubuntu, not Debian). The logs are not very useful, because the daemon was already running so pa exits. Please retry the pa -k ; pa - dance until the new daemon sticks (ie, it doesn't exit right away). 5) Since I'm using Kubuntu now, let me know if I should just contact them on the issue instead. I don't know how different pulseaudio is under Kubuntu vs. Debian. It wil make it harder to debug because debian unstable is a version ahead of Kubuntu. PS: please remember to CC the bug report. -- Saludos, Felipe Sateler
Bug#743402: capnproto: failed to run test on mips64el
Oh great, thanks very much! Would you mind if I instead got the upstream
maintainer (Kenton Varda, CCed on this email) to give you his public key?
He's in a better position to fix the busted test.
Once he's got a patch I'll weave it back into the Debian packaging scripts
let you know when they're ready to try again.
On Sat, Apr 19, 2014 at 2:26 PM, Yunqiang Su wzss...@gmail.com wrote:
I can provide you a porterbox for remote access.
Please give me your ssh public key with gpg signed.
On Sun, Apr 20, 2014 at 4:00 AM, Tom Lee deb...@tomlee.co wrote:
Okay, thanks -- confirmed with upstream that the issue is a little
trickier
to fix than he first thought. He doesn't have access to MIPS hardware to
test out his ideas for a fix, though. I'm going to ask around a little
see
if we can get direct access to a MIPS system to attack this bug. I'll
keep
you posted.
On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:
dpkg-buildpackage -B
On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
Weird. Can I ask what commands you're using to build the package from
the
github repo?
On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com
wrote:
seems still the same problem
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make all-recursive
make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
Testsuite summary for Capn Proto 0.4.1
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to capnpr...@googlegroups.com
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
dh_auto_test: make -j1 check returned exit code 2
On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
Great, thanks again. Seems like this may have been an upstream bug.
I've
pushed a patch -- can you try the latest code on master?
http://github.com/thomaslee/capnproto-debian
Cheers,
Tom
On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
wrote:
On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co
wrote:
Thanks! Can you try the same thing, but instead of passing an
empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
__builtin_nanf(0)
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fa0 7ff4 7ff4
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su
wzss...@gmail.com
wrote:
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
wrote:
Hey Yunqiang,
I spoke to the upstream maintainer. He's asked if you can
compile
run
this
small C program (with and without optimizations) and to send
the
output
from
both:
// begin
#include stdio.h
#include inttypes.h
#include string.h
int main() {
float nanf = __builtin_nanf();
double nand = __builtin_nan();
double nancast = nanf;
uint32_t nanfi;
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
Package: liferea Version: 1.10.8-1 Followup-For: Bug #666145 Dear maintainer, The original report and all comments are related to the version in Debian Wheezy (currently stable). This comment is just to report the issue is still present in Jessie with liferea version 1.10.8. Carnë Draug -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liferea depends on: ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii gir1.2-gtk-3.0 3.12.0-4 ii gir1.2-peas-1.0 1.8.1-1 ii libatk1.0-0 2.12.0-1 ii libc62.18-4 ii libcairo21.12.16-2 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libgirepository-1.0-11.40.0-2 ii libglib2.0-0 2.40.0-2 ii libgtk-3-0 3.12.0-4 ii libindicate5 0.6.92-2 ii libjson-glib-1.0-0 1.0.0-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.3-1 ii libpeas-1.0-01.8.1-1 ii libsoup2.4-1 2.46.0-2 ii libsqlite3-0 3.8.4.1-1 ii libwebkitgtk-3.0-0 2.2.6-1 ii libxml2 2.9.1+dfsg1-3 ii libxslt1.1 1.1.28-2 ii liferea-data 1.10.8-1 ii python-gi3.10.2-2+b1 pn python:any none Versions of packages liferea recommends: ii dbus 1.8.0-3 ii dbus-x11 1.8.0-3 ii gir1.2-gnomekeyring-1.0 3.4.1-1 ii gnome-icon-theme 3.12.0-1 ii gnome-keyring3.8.2-2+b1 ii steadyflow 0.2.0-1 Versions of packages liferea suggests: pn network-manager none -- 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#743402: capnproto: failed to run test on mips64el
yes, it is OK.
On Sun, Apr 20, 2014 at 8:27 AM, Tom Lee deb...@tomlee.co wrote:
Oh great, thanks very much! Would you mind if I instead got the upstream
maintainer (Kenton Varda, CCed on this email) to give you his public key?
He's in a better position to fix the busted test.
Once he's got a patch I'll weave it back into the Debian packaging scripts
let you know when they're ready to try again.
On Sat, Apr 19, 2014 at 2:26 PM, Yunqiang Su wzss...@gmail.com wrote:
I can provide you a porterbox for remote access.
Please give me your ssh public key with gpg signed.
On Sun, Apr 20, 2014 at 4:00 AM, Tom Lee deb...@tomlee.co wrote:
Okay, thanks -- confirmed with upstream that the issue is a little
trickier
to fix than he first thought. He doesn't have access to MIPS hardware to
test out his ideas for a fix, though. I'm going to ask around a little
see
if we can get direct access to a MIPS system to attack this bug. I'll
keep
you posted.
On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:
dpkg-buildpackage -B
On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
Weird. Can I ask what commands you're using to build the package from
the
github repo?
On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com
wrote:
seems still the same problem
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make all-recursive
make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
Testsuite summary for Capn Proto 0.4.1
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to capnpr...@googlegroups.com
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
dh_auto_test: make -j1 check returned exit code 2
On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
Great, thanks again. Seems like this may have been an upstream
bug.
I've
pushed a patch -- can you try the latest code on master?
http://github.com/thomaslee/capnproto-debian
Cheers,
Tom
On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
wrote:
On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co
wrote:
Thanks! Can you try the same thing, but instead of passing an
empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
__builtin_nanf(0)
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fa0 7ff4 7ff4
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su
wzss...@gmail.com
wrote:
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
wrote:
Hey Yunqiang,
I spoke to the upstream maintainer. He's asked if you can
compile
run
this
small C program (with and without optimizations) and to send
the
output
from
both:
// begin
#include stdio.h
#include inttypes.h
#include string.h
int main() {
float nanf =
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
On 04/19/2014 07:05 PM, Carnë Draug wrote: Package: liferea Version: 1.10.8-1 Followup-For: Bug #666145 Dear maintainer, The original report and all comments are related to the version in Debian Wheezy (currently stable). This comment is just to report the issue is still present in Jessie with liferea version 1.10.8. Can you please check Tools - Preferences - Browser - Browser If you have a browser set there that isn't installed then you're going to get an error. We've tried to suggest to upstream that maybe they should only list browsers installed on the system but they think it makes the browser configuration unnecessarily complicated and it also makes sense in a way, because they want to make sure they only list browsers there that they've confirmed to work with liferea (as far as passing urls to the browser and such, it isn't as standardized as it should be). You can use the generic x-www-browser option and then configure which browser to use with update-alternatives --config x-www-browser. As you add/remove browsers from the system, dpkg will automatically update the x-www-browser option so if you set that in liferea it *should* always work. If it doesn't, let me know. Last I checked, x-www-browser is the default.. And so long as you have a web browser on your system installed from the debian repos, x-www-browser should point to it. Otherwise, you will need to configure it manually. Let me know what browser you have configured in liferea and whether or not you have that browser installed. Keep in mind that Firefox is not the same as Iceweasel because the app specifically expects the firefox bin to be in your user's path. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745262: console-setup: Caps lock doesn't take effect on øæå (Danish characters)
Package: console-setup Version: 1.102 Severity: important Tags: l10n -- Bug description On the Linux console the caps lock key doesn't take effect on the Danish characters æøå. With caps lock on they are simply rendered æøå (lower case), and not ÆØÅ as one would expect. Caps lock works as expected on the Linux console in Wheezy. I've made a fresh install of Jessie on a virtual machine on different hardware and the problem persisted. During installation I chose Danish keyboard layout. In addition I've tried all available settings for Danish keyboard with 'dpkg-reconfigure keyboard-configuration'. I've also tried installing console-data and then 'loadkeys dk' and 'loadkeys dk-latin1' (the two Danish keymaps available) and the problem persists. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages console-setup depends on: ii console-setup-linux 1.102 ii debconf 1.5.52 ii keyboard-configuration 1.102 ii xkb-data2.10.1-1 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.18-4 ii lsb-base 4.1+Debian12 Versions of packages keyboard-configuration depends on: ii debconf 1.5.52 ii initscripts 2.88dsf-51 ii liblocale-gettext-perl 1.05-8 Versions of packages console-setup-linux depends on: ii kbd 1.15.5-1 ii keyboard-configuration 1.102 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common none pn console-datanone pn console-tools none ii kbd 1.15.5-1 -- debconf information: * keyboard-configuration/variant: Danish * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages keyboard-configuration/unsupported_options: true console-setup/guess_font: * keyboard-configuration/variantcode: * console-setup/charmap47: UTF-8 * keyboard-configuration/compose: No compose key * keyboard-configuration/store_defaults_in_debconf_db: true * console-setup/fontsize-fb47: 8x16 * keyboard-configuration/toggle: No toggling console-setup/store_defaults_in_debconf_db: true * keyboard-configuration/switch: No temporary switch * keyboard-configuration/other: console-setup/fontsize-text47: 8x16 keyboard-configuration/unsupported_config_options: true keyboard-configuration/unsupported_layout: true debian-installer/console-setup-udeb/title: keyboard-configuration/ctrl_alt_bksp: false console-setup/framebuffer_only: * keyboard-configuration/layout: Danish console-setup/codesetcode: Lat15 * keyboard-configuration/altgr: The default for the keyboard layout console-setup/use_system_font: * keyboard-configuration/xkb-keymap: cn * console-setup/fontface47: Fixed * keyboard-configuration/layoutcode: dk console-setup/fontsize: 8x16 keyboard-configuration/unsupported_config_layout: true * keyboard-configuration/optionscode: * keyboard-configuration/modelcode: pc105 * keyboard-configuration/model: Generic 105-key (Intl) PC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
On 04/19/2014 08:26 PM, David Smith wrote: Can you please check Tools - Preferences - Browser - Browser And naturally I forgot to mention that the Default Browser listed in Liferea refers *SPECIFICALLY* to the Gnome desktop default browser.. ie: It would require the desktop-file-utils package to be installed. That's why we go with the x-www-browser option as the default for liferea in Debian as the x-www-browser is automatically updated by dpkg while the Default Gnome desktop browser is not automatically updated since it's a user config that you set in Gnome. If you have Default Browser listed there, it might be a user configuration that's left over from a previous version and you're just going to have to change it to x-www-browser or something else. I mean, we could always migrate Default Browser user setting to the x-www-browser user setting in liferea to be sure they don't get this error but that's screwing around with user's configurations that they've already set or was set by a previous version of liferea installed on the system and that's probably bad practice. Hope that helps. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743717: [PKG-Openstack-devel] Bug#743717: closed by Thomas Goirand z...@debian.org (Bug#743717: fixed in subunit 0.0.18-3)
On 04/20/2014 03:42 AM, Gonéri Le Bouder wrote: Hi Thomas and Ivo, The build still fails on all architectures. There is probably something that happens in the local build in your environment that doesn't work on the buildds. I'm afraid that's the problem. I managed to rebuild the package on fresh i386 and amd64 cowbuild env with no problem. Best regards, Hi Goneri, Yes, I did rebuild it also in a fresh amd64 cowbuilder env as well. In fact, that's what does Jenkins each time I push (it even rebuilds for Wheezy, Precise and Trusty), but out of options, I did try to setup a completely new Sid environment using Cowbuilder. And it did work as well, which is weird. So now, I really don't get what is happening with the buildds, and why they don't have binaries in $(CURDIR)/debian/subunit/usr/bin/* just right after dh_python3 happens (eg: see the log, this is what this bug is about, and IMO it has very little to do with my system being up-to-date or not). Yes, I could try to get myself setup with sbuild, but I'm not sure it would help to understand what's going on. :( Does anyone have a clue? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744985: lintian: Privacy breach should not complain about links to example.org
On Sat, 2014-04-19 at 20:54 +0200, Bastien ROUCARIES wrote: I think this should be added to thé policy bug as a footnote. Feel free to forward my mail there, I don't know which bug you refer to. Are we sûre ?what is the normative reference ? I tested in Iceweasel and did not get any HTTP request for it. Reading the RFC though it appears more complicated, some link tags may get loaded and others not depending on the parent tag. https://tools.ietf.org/html/rfc4287 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#745262:
I asked for a solution to the problem in the Unix Linux StackExchange forum: http://unix.stackexchange.com/questions/125577/caps-lock-doesnt-take-effect-on-all-letters So far to no avail.
Bug#741406: (linux-image-3.13-1-amd64: tcp traffic fails after approx 1/2hour boot time 'TCP: out of memory -- consider tuning tcp_mem')
I believe that linux-image-3.13-1-amd64 3.13.10-1 fixes this problem. I've been testing all package updates since 3.13.5-1 and this is the first version of 3.13 where I've been able to run it for 12 hours+ without tcp dropping out.I only have the computer effected by this bug on during the day so can't test longer than 12hours, but given in the past the longest it stayed up was sub 2hours I'm fairly confident the problem is gone. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745263: ITP: airspy-host -- host support for a low cost software radio receiver.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: wnpp Severity: wishlist Owner: A. Maitland Bottoms bott...@debian.org * Package name: airspy-host Version : git snapshot Upstream Author : Benjamin Vernoux bvern...@airspy.com and Youssef Touil yous...@airspy.com * URL : http://airspy.com * License : GPL, version 2 or later Programming Lang: C++ Description : Software defined radio receiver AirSpy: A tiny and efficient software defined radio. Airspy is a very tiny (5×3 cm) software defined radio receiver capable of sampling 10MHz of spectrum anywhere between 24MHz and 1.7GHz. It is the fruit of countless hours of head scratching, fiddling and experimenting with the cutting edge Radio and DSP technologies. The early prototypes gave such an unexpected satisfaction to us and our friends, that we decided to give it a chance to survive commercially. -- http://airspy.com This Debian package effort provides host support for the AirSpy hardware, allowing it to be used by GNU Radio and gr-osmosdr software. AirSpy is a receiver project based upon the HackRF project. - -Maitland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTUzs3AAoJEFBB8YkfROCQ3XoP/jGh2xOn7Q2UR8Ts1bKiXuih fSwume/MZTkqZ8VI1DHuSi0/hVLPu6biX5HcggmapRq50AmPb03cDz64mV2BndUz FuBHoCO7nlOCokkZEV9Nn/JNEDNntQgddBBx5ltak6aZXomBjWNjmq95L/PTlDBl k0hzu1hwgZXmpbJLqFN+XnHaTh/DnettxrJ6W17bSJYP1CnckcsjWmaBMJ9EjFyr m6kq5M9H4QONDlRrUuSHvcKXa/8rYd20ON96PlJyO8W7idiHDI+gl1dPq5S0TnZ2 h7HKwZn4fVWxShN3k3LHVXxL7bbEnzFYNijwMqNAqa25+mln/+Bt1j+G6yLAIL0k bTkP8GeYyJqAJYMzB0lTJiIlzCyXdaUKufFD6wGFEGok1x1Ck5p4fLTOK5kFa2pj sr7zNl4ZbgfUULjvyrO88KFoznSz2ddIc5vaBFDMKFsYL9xbL/tyLZsv6OVtx8ir I87utuV21OqMZfHlfkak+cMAbm2Ec6XsOZZAgonEh3sjseTiyT4eZqDe1Q6wl3D9 vfqkwpGYi2RBMz7EvuRkF/W34zknxMz6qPYxUG4P3PyGHOH1dfe491HVVWHS15gK zQcUwkLPrHrMn6rfCEyCq/PLn5yzAIa1VKTH9uAdZxbHO+dFdTMGEYTKfogJSJ3l LQ03R6wSaZIoJCapqB9Z =pMpa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744935: docker.io: run fails with Error resize: Error: bad file descriptor (despite of cfgroups-mount being installed)
On 16 April 2014 07:20, Johannes Graumann johannes_graum...@web.de wrote: DOCKER_OPTS='--bridge=none --graph=/home/docker' Did you ever get a chance to test without the quotes on this like we discussed on IRC? (ie, --bridge=none) ♥, - Tianon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742993: closed by Rahul Amaram amaramra...@users.sourceforge.net (Done: python-pycalendar: Please update to new svn snapshot)
On Sunday 20 April 2014 01:01 AM, Guido Günther wrote: Hi, On Sun, Apr 13, 2014 at 05:39:24PM +0530, Rahul Amaram wrote: URL: https://svn.calendarserver.org/repository/calendarserver/PyCalendar/branches/CalendarServer-5.2 Last Changed Rev: 13177 I am anyway planning to update calendarserver in the next couple of weeks. Will the above pycalendar version work for you? Looking at the diff I guess we need current trunk. But as I said an upload to experimental would be sufficient for now and we an hopefully run with the next release. My offer to handle the upload to experimental still holds. Cheers, -- Guido Hi Guido, Kindly go ahead and do a non-maintainer upload to experimental. Do mention the Breaks condition. Also, as I understand, the package from experimental will not get propagated to unstable. Thanks, Rahul. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745264: postgrey: Fails to reload
Package: postgrey Version: 1.34-1.1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, * What led up to the situation? I added an entry to /etc/postgrey/whitelist_clients, and tried to reload the daemon using both service postgrey reload, and by caling the init script directly. * What exactly did you do (or not do) that was effective (or ineffective)? Added the entry, then: $ sudo service postgrey reload [FAIL] Reloading postfix greylisting daemon configuration..failed. I get the same error when: $ sudo /etc/init.d/postgrey reload Nothing appears in /var/log/mail.info. * What was the outcome of this action? Nothing. * What outcome did you expect instead? I expected the daemon ti reload it's config. - -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgrey depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii libberkeleydb-perl 0.51-1 ii libnet-dns-perl0.66-2+b2 ii libnet-server-perl 2.006-1+deb7u1 ii perl 5.14.2-21+deb7u1 ii ucf3.0025+nmu3 Versions of packages postgrey recommends: ii exim4 4.80-7 ii libnet-rblclient-perl 0.5-2 ii libparse-syslog-perl 1.10-2 postgrey suggests no packages. - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJTU0XYAAoJEC9jv4oEFMfigngP/i7zxqde1yfxfN3Pu2kf4bQO Xi05PDLmuCHZGJi78EgXIynxgP+JCVVNeFeXLP2PjL6rvlag+P8m2lTSmtqJx1Mp cfpUtt5X56oKJIujOTzvfAiKeS398x4NQ3ZKV42eX06OyH3NTLTn9mdglUiXgK1M ueEUsad0QTQDmNAE2Vah/rlHXNRSvMwLfsO5nBDHOHaozkFGxhT3rkCjdiAY3e+N paaGjWPKPueD1DuReJjJoqqhkh+glnposVmouwphXPji/bsbw20+jb1+T3EM73bb nemQoshUfH39ZPXuf0+zC1ONBl/SdAYl6SKBFq+/1VIPV0nK+I7BjLDcpMdtT3qr XoVB2ynwkB7VJ0Mx6qPpR95C5MKnLGBpBnFsWySSu9mmXpo2ENb1jzov/dVUwyCy hfRfhTW3tNfUkYoaiz7t0tKHeoz1/TZrUF6a02NCQ202YdpfcU5OHZtEYj45FBgp 2w0iq4Ik2P6TasMZiTZsOluHg3vQZxEe3+JGcP9pTjewbQhVL4J/a9NaRyWWToof i1ChSTFsA3Jys7a/adZ8W8jd0YE3cYwzCIpUwGpMq+ocJPLcfoas35lzdJEiRyg5 0qaT2/6gWMcKULOuu+gTN7ewdL6VWUHy6h6q34BgvV004XSkjQEgClMNtyKMGgLa dABXsMaNxrUCseIx+wlm =Y6Od -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744935: docker.io: run fails with Error resize: Error: bad file descriptor (despite of cfgroups-mount being installed)
On 2014-04-20 6:26, Tianon Gravi wrote: On 16 April 2014 07:20, Johannes Graumann johannes_graum...@web.de wrote: DOCKER_OPTS='--bridge=none --graph=/home/docker' Did you ever get a chance to test without the quotes on this like we discussed on IRC? (ie, --bridge=none) ♥, - Tianon --bridge=none indeed fixes the behavior. This particular notation is somewhat in contradiction to the documentation, where $ docker.io --help Usage of docker.io: ... -b, --bridge=: Attach containers to a pre-existing network bridge; use 'none' to disable container networking ... there's definitely s there ... Not sure whether that's a docker, or a debian-specific (/etc/default/docker.io-parsing) bug. Sincerely, Joh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745265: libgrib-api-1.10.4: paramId.def.orig not in upstream package
Package: libgrib-api-1.10.4 Version: 1.10.4-3 Severity: wishlist Dear Maintainer, two files named 'paramId.def.orig' are found in /usr/share/grib_api/definitions/grib1 and /usr/share/grib_api/definitions/grib2 but not in the upstream package. Maybe they should be removed. Alberto -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgrib-api-1.10.4 depends on: ii libc6 2.18-4 ii libgcc1 1:4.9-20140411-2 ii libgfortran3 4.9-20140411-2 ii libjasper11.900.1-debian1-1 ii libpng12-01.2.50-1 ii libquadmath0 4.9-20140411-2 libgrib-api-1.10.4 recommends no packages. libgrib-api-1.10.4 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#745266: weechat-plugins: Split up the package to avoid unecessary dependencies (weechat-plugins-tcl, *-ruby etc).
Source: weechat-plugins Severity: wishlist Dear Maintainer, it would be very kind if the weechat-plugins package could be split up in one package per script type. E.g. weechat-plugins-tcl, weechat-plugins-ruby, weechat-plugins-lua and so on. Personally I prefer python and do not use ruby, lua or tcl. So it feels unecessary to install all the required dependencies for these other languages when they are not used. Thank you. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13-1-486 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745267: src:gcc-4.9: FTCBFS x32: subdirectories libvtv and libcilkrts missing from cross-ma-install-location.diff
Package: src:gcc-4.9
Version: 4.9-20140411-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi doko,
While trying to build a gcc stage3 for x32
with_deps_on_target_arch_pkgs=yes, I get the following error:
mv debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a
debian/libgcc-4.9-dev/usr/lib/gcc/x86_64-linux-gnux32/4.9/
mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a': No such
file or directory
This is due to libvtv installation installing into the wrong directory:
make[7]: Entering directory
`/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/build/x86_64-linux-gnux32/libvtv'
true DO=install multi-do # /usr/bin/make
test -z /usr/x86_64-linux-gnux32/lib/../lib || /bin/mkdir -p
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
/bin/bash ./libtool --mode=install /usr/bin/install -c libvtv.la
'/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib'
libtool: install: /usr/bin/install -c .libs/libvtv.so.0.0.0
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.so.0.0.0
libtool: install: (cd
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
{ ln -s -f libvtv.so.0.0.0 libvtv.so.0 || { rm -f libvtv.so.0 ln -s
libvtv.so.0.0.0 libvtv.so.0; }; })
libtool: install: (cd
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
{ ln -s -f libvtv.so.0.0.0 libvtv.so || { rm -f libvtv.so ln -s
libvtv.so.0.0.0 libvtv.so; }; })
libtool: install: /usr/bin/install -c .libs/libvtv.lai
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.la
libtool: install: /usr/bin/install -c .libs/libvtv.a
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: chmod 644
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: /usr/x86_64-linux-gnux32/bin/ranlib
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: warning: remember to run `libtool --finish
/usr/x86_64-linux-gnux32/lib/../lib'
test -z /usr/lib/gcc/x86_64-linux-gnux32/4.9/include || /bin/mkdir -p
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/4.9/include
make[7]: Leaving directory
`/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/build/x86_64-linux-gnux32/libvtv'
This kind of issue is supposed to be covered by
cross-ma-install-location.diff, but the libvtv directory was added in
gcc-4.9 and cross-ma-install-location.diff was not updated. Once this is
fixed, the same applies to libcilkrts. After fixing both gcc stage3
succeeds.
Helmut
diff -u gcc-4.9-4.9-20140411/debian/changelog
gcc-4.9-4.9-20140411/debian/changelog
--- gcc-4.9-4.9-20140411/debian/changelog
+++ gcc-4.9-4.9-20140411/debian/changelog
@@ -1,3 +1,11 @@
+gcc-4.9 (4.9-20140411-2.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Add new libraries src/libvtv and src/libcilkrts to
+cross-ma-install-location.diff. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 19 Apr 2014 15:16:47 +0200
+
gcc-4.9 (4.9-20140411-2) unstable; urgency=medium
* Disable running the testsuite on kfreebsd, hangs the buildds.
diff -u gcc-4.9-4.9-20140411/debian/patches/cross-ma-install-location.diff
gcc-4.9-4.9-20140411/debian/patches/cross-ma-install-location.diff
--- gcc-4.9-4.9-20140411/debian/patches/cross-ma-install-location.diff
+++ gcc-4.9-4.9-20140411/debian/patches/cross-ma-install-location.diff
@@ -346,0 +347,40 @@
+--- a/src/libvtv/configure.ac
b/src/libvtv/configure.ac
+@@ -72,15 +72,8 @@
+ toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
+ ;;
+ no)
+-if test -n $with_cross_host
+- test x$with_cross_host != xno; then
+- # Install a library built with a cross compiler in tooldir, not libdir.
+- toolexecdir='$(exec_prefix)/$(target_alias)'
+- toolexeclibdir='$(toolexecdir)/lib'
+-else
+- toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+- toolexeclibdir='$(libdir)'
+-fi
++toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
++toolexeclibdir='$(libdir)'
+ multi_os_directory=`$CC -print-multi-os-directory`
+ case $multi_os_directory in
+ .) ;; # Avoid trailing /.
+--- a/src/libcilkrts/configure.ac
b/src/libcilkrts/configure.ac
+@@ -103,15 +103,8 @@
+ toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
+ ;;
+ no)
+-if test -n $with_cross_host
+- test x$with_cross_host != xno; then
+- # Install a library built with a cross compiler in tooldir, not libdir.
+- toolexecdir='$(exec_prefix)/$(target_alias)'
+- toolexeclibdir='$(toolexecdir)/lib'
+-else
+- toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+- toolexeclibdir='$(libdir)'
+-fi
++toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
++
Bug#745268: vor: Please move from contrib to main (povray is now agpl)
Package: vor Version: 0.5.5-2 Severity: normal Dear Maintainers, Povray finally has a DFSG-compliant license! I'm so excited. This means that vor can now be included in main right?! I'm pretty sure the old povray license was the only thing relegating vor to contrib. Please move vor to main :) Note: It looks like the debian package for this new (AGPL-licensed) version of povray is still a work in progress, in that it only successfully builds on one architecture. Do you need to wait for it to build on more architectures before moving vor to main? I'm pretty sure povray is _not_ used in building the debian package for vor (because the upstream tarball releases of vor come with the graphics already rendered.) I think it is sufficient (for vor to be allowed into main) that povray is available from povray.org under a DFSG-compliant license, but this paragraph is here in case I'm wrong about that. Thank you thank you! -- Jason -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745269: qemu-system: Ctrl+Alt keyboard shortcuts not working in qemu-system-* when compiled against SDL 2.0
Package: qemu-system Version: 2.0.0+dfsg-2 Severity: important Hello, On a Debian Sid system that is up-to-date as of today, when I use qemu-system-* (i.e. qemu-system-i386, qemu-system-x86_64, ...) with the SDL user interface, I cannot use the Ctrl+Alt+2 keyboard shortcut from within the GUI window in order to access qemu's monitor mode. Similarly, Ctrl+Alt+f does not switch to full-screen mode either. Because these are important features in qemu, I marked this bug report as important. While trying to debug this issue, I rebuilt the qemu (2.0.0+dfsg-2) source package with a modification to the debian/control-in file which forces qemu to be compiled against SDL 1.2 (as opposed to the maintainer's default of SDL 2.0). With SDL 1.2 the aforementioned keyboard shortcuts work as intended and as expected. Is there any possibility of uploading a version of qemu 2.0.0+dfsg compiled against SDL 1.2 to Debian unstable, at least until this issue with SDL 2.0 is resolved? Thank you, Vefa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742642: iotop reports gnome-shell I/O% but no disk I/O being done
On Tue, 2014-03-25 at 16:59 -0400, Dominique Brazziel wrote: I think this may be a quirk (or maybe bug) in the netlink/taskstats interface where Unix socket I/O is being counted as block I/O. I will try and write a test program to loop doing socket I/O and see if iotop shows it doing a % of I/O. Did you manage to complete this test program? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#745265: libgrib-api-1.10.4: it must be renamed to paramId.def
Package: libgrib-api-1.10.4 Version: 1.10.4-3 Followup-For: Bug #745265 Dear Maintainer, following my previous bug report, I noticed that the mentioned files must not be removed but renamed to paramId.def. Without renaming grib-api tools keep saying: GRIB_API ERROR : Unable to load paramIdECMF from (null) GRIB_API ERROR : Unable to load paramId from (null) Alberto -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgrib-api-1.10.4 depends on: ii libc6 2.18-4 ii libgcc1 1:4.9-20140411-2 ii libgfortran3 4.9-20140411-2 ii libjasper11.900.1-debian1-1 ii libpng12-01.2.50-1 ii libquadmath0 4.9-20140411-2 libgrib-api-1.10.4 recommends no packages. libgrib-api-1.10.4 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#745269: qemu-system: Ctrl+Alt keyboard shortcuts not working in qemu-system-* when compiled against SDL 2.0
Control: severity 745185 important Control: reassign 745185 qemu-system Control: merge 745269 745185 Control: forwarded 745269 http://thread.gmane.org/gmane.comp.emulators.qemu/267839 20.04.2014 09:03, M. Vefa Bicakci wrote: Package: qemu-system Version: 2.0.0+dfsg-2 Severity: important Hello, On a Debian Sid system that is up-to-date as of today, when I use qemu-system-* (i.e. qemu-system-i386, qemu-system-x86_64, ...) with the SDL user interface, I cannot use the Ctrl+Alt+2 keyboard shortcut from within the GUI window in order to access qemu's monitor mode. Similarly, Ctrl+Alt+f does not switch to full-screen mode either. Because these are important features in qemu, I marked this bug report as important. While trying to debug this issue, I rebuilt the qemu (2.0.0+dfsg-2) source package with a modification to the debian/control-in file which forces qemu to be compiled against SDL 1.2 (as opposed to the maintainer's default of SDL 2.0). With SDL 1.2 the aforementioned keyboard shortcuts work as intended and as expected. Yes, I debugged it yesterday too, after receiving #745185, and yes your observation are correct. Is there any possibility of uploading a version of qemu 2.0.0+dfsg compiled against SDL 1.2 to Debian unstable, at least until this issue with SDL 2.0 is resolved? Sure, that appears to be the solution. I asked upstream about this (see Forwarded URL), but no reply so far, and looking at the code I don't see an easy fix, apparently monitor and guest serial output are not even implemented for sdl2. Please give me one more day for this, to get definitive opinion. I have quite some changes pending for the next release already which will have to be backed up for this change to be uploaded (new changes introduces some new packages, namely libcacard, so will wait in NEW). Note that usage of SDL2 is required for modular monitor (in loadable modules), because SDL1 replaces main() routine to do pre-initialization and hence can't be loaded later. Thank you for the excellent bugreport! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
