Bug#744177: JBIG and JBIG2 files are not detected
Package: libmagic1 Version: 5.11-2+deb7u3 ### first lets create a demo image. bash$ cat source_ascii.pbm EOF P1 20 10 00010011001110000010100011 100110001111011100110001000000 000111110001101100010010 EOF ### convert it to binary pbm because the other tools don't like ascii ### input. bash$ pgmtopbm source_ascii.pbm source.pbm ### please install jbigkit-bin 2.0-2+deb7u1 ### lets create JBIG and JBIG2 files from our original image: bash$ pbmtojbg source.pbm comp.jbg bash$ pbmtojbg85 source.pbm comp.jbg85 ### try to display these images. ### gimp fails on both, but imageMagick can display one of them: bash$ display comp.jbg # display from ImageMagick. works! bash$ display comp.jbg85 # does not detect image format :-( ### lets now convert the JBIG images back to original: bash$ jbgtopbm comp.jbg | pgmtopbm back.pbm bash$ jbgtopbm comp.jbg85 | pgmtopbm back85.pbm ### now compare original to decompressed images bash$ md5sum *|sort you see that back85.pbm, back.pbm, source.pbm are equal. so compression and decompression of jbg and jbg85 are working. they even do for larger source images. I was thinking about replacing TIFF-G4 compressed images by JBIG or JBIG2 compressed images because they have much better compression ratio, but as images are stored as files, it is necessary that the filetype is detected by libmagic. and here is the bug / wishlist: bash$ file * back85.pbm: Netpbm PBM rawbits image data -- OK back.pbm: Netpbm PBM rawbits image data -- OK comp.jbg: MS Windows icon resource -- wrong! comp.jbg85: MS Windows icon resource -- wrong! source_ascii.pbm: Netpbm PBM image, ASCII text-- OK source.pbm: Netpbm PBM rawbits image data -- OK cu erik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743786: wine-unstable: missing wineapploader, breaking wine{boot, cfg, dbg, file, path} symlinks
I just upgraded from the previous version and I don't have anything related to wine in /usr/bin/ at all! Am I missing something? $ ls -l /usr/bin/wine* ls: cannot access /usr/bin/wine*: No such file or directory $ aptitude search '~nwine' -F %p %V %v --disable-columns | grep -v none libwine-unstable 1.7.16-1 1.7.16-1 libwine-unstable:i386 1.7.16-1 1.7.16-1 wine32-unstable:i386 1.7.16-1 1.7.16-1 wine64-unstable 1.7.16-1 1.7.16-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744178: winbindd: segfault with kerberized authentication
Package: winbindd Version: 2:4.1.6+dfsg-1~bpo70+1 Severity: normal Hi, this wheezy desktop is joined to a current samba4 domain on a testing host. wbinfo --pam-logon works using cleartext auth, wbinfo -K (and others trying to use kerberos auth via wb) cause this segfault in kerberos: Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.739328, 0] ../lib/util/fault.c:72(fault_report) Apr 11 08:11:27 david-pc4 winbindd[13486]: === Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.739443, 0] ../lib/util/fault.c:73(fault_report) Apr 11 08:11:27 david-pc4 winbindd[13486]: INTERNAL ERROR: Signal 11 in pid 13486 (4.1.6-Debian) Apr 11 08:11:27 david-pc4 winbindd[13486]: Please read the Trouble-Shooting section of the Samba HOWTO Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.739526, 0] ../lib/util/fault.c:75(fault_report) Apr 11 08:11:27 david-pc4 winbindd[13486]: === Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.739560, 0] ../source3/lib/util.c:785(smb_panic_s3) Apr 11 08:11:27 david-pc4 winbindd[13486]: PANIC (pid 13486): internal error Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.740379, 0] ../source3/lib/util.c:896(log_stack_trace) Apr 11 08:11:27 david-pc4 winbindd[13486]: BACKTRACE: 27 stack frames: Apr 11 08:11:27 david-pc4 winbindd[13486]:#0 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f8b44e18bba] Apr 11 08:11:27 david-pc4 winbindd[13486]:#1 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f8b44e18c90] Apr 11 08:11:27 david-pc4 winbindd[13486]:#2 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f) [0x7f8b491471bf] Apr 11 08:11:27 david-pc4 winbindd[13486]:#3 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(+0x1e3b6) [0x7f8b491473b6] Apr 11 08:11:27 david-pc4 winbindd[13486]:#4 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030) [0x7f8b49573030] Apr 11 08:11:27 david-pc4 winbindd[13486]:#5 /usr/lib/x86_64-linux-gnu/libkrb5.so.26(krb5_storage_free+0x1) [0x7f8b4395c9e1] Apr 11 08:11:27 david-pc4 winbindd[13486]:#6 /usr/lib/x86_64-linux-gnu/libkrb5.so.26(+0x482ad) [0x7f8b439422ad] Apr 11 08:11:27 david-pc4 winbindd[13486]:#7 /usr/lib/x86_64-linux-gnu/samba/libgse.so.0(+0x97ba) [0x7f8b459b47ba] Apr 11 08:11:27 david-pc4 winbindd[13486]:#8 /usr/lib/x86_64-linux-gnu/samba/libgse.so.0(gse_krb5_get_server_keytab+0x18b) [0x7f8b459b4d8b] Apr 11 08:11:27 david-pc4 winbindd[13486]:#9 /usr/lib/x86_64-linux-gnu/samba/libgse.so.0(+0xbb38) [0x7f8b459b6b38] Apr 11 08:11:27 david-pc4 winbindd[13486]:#10 /usr/lib/x86_64-linux-gnu/libgensec.so.0(gensec_start_mech+0x42) [0x7f8b45e457e2] Apr 11 08:11:27 david-pc4 winbindd[13486]:#11 /usr/lib/x86_64-linux-gnu/libgensec.so.0(gensec_start_mech_by_oid+0x2e) [0x7f8b45e45b3e] Apr 11 08:11:27 david-pc4 winbindd[13486]:#12 /usr/sbin/winbindd(kerberos_return_pac+0x491) [0x7f8b499d2901] Apr 11 08:11:27 david-pc4 winbindd[13486]:#13 /usr/sbin/winbindd(winbindd_dual_pam_auth+0xab8) [0x7f8b499e4d28] Apr 11 08:11:27 david-pc4 winbindd[13486]:#14 /usr/sbin/winbindd(+0x5894c) [0x7f8b499fa94c] Apr 11 08:11:27 david-pc4 winbindd[13486]:#15 /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x921b) [0x7f8b42e8121b] Apr 11 08:11:27 david-pc4 winbindd[13486]:#16 /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x76f6) [0x7f8b42e7f6f6] Apr 11 08:11:27 david-pc4 winbindd[13486]:#17 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f8b42e7c02d] Apr 11 08:11:27 david-pc4 winbindd[13486]:#18 /usr/sbin/winbindd(+0x5ae6a) [0x7f8b499fce6a] Apr 11 08:11:27 david-pc4 winbindd[13486]:#19 /usr/sbin/winbindd(+0x5b565) [0x7f8b499fd565] Apr 11 08:11:27 david-pc4 winbindd[13486]:#20 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0xe2) [0x7f8b42e7c8e2] Apr 11 08:11:27 david-pc4 winbindd[13486]:#21 /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x8faa) [0x7f8b42e80faa] Apr 11 08:11:27 david-pc4 winbindd[13486]:#22 /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x76f6) [0x7f8b42e7f6f6] Apr 11 08:11:27 david-pc4 winbindd[13486]:#23 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f8b42e7c02d] Apr 11 08:11:27 david-pc4 winbindd[13486]:#24 /usr/sbin/winbindd(main+0xaca) [0x7f8b499c9e2a] Apr 11 08:11:27 david-pc4 winbindd[13486]:#25 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8b42b0bead] Apr 11 08:11:27 david-pc4 winbindd[13486]:#26 /usr/sbin/winbindd(+0x28531) [0x7f8b499ca531] Apr 11 08:11:27 david-pc4 winbindd[13486]: [2014/04/11 08:11:27.747288, 0] ../source3/lib/dumpcore.c:317(dump_core) Apr 11 08:11:27 david-pc4 winbindd[13486]: dumping core in /var/log/samba/cores/winbindd Apr 11 08:11:27 david-pc4 winbindd[13486]: I can provide the core file if
Bug#744179: quiterss: Not all filters work on news headers.
Package: quiterss Version: 0.13.3+dfsg-2 Severity: normal Dear Maintainer, I'm using testing version of Debian, and quiteRSS does not fillter all the news headers according as i specified in the filters list. I suppose it is due to non english (russian) characters and therefore, encoding other than latin1. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (700, 'testing-updates'), (700, 'testing'), (600, 'stable-updates'), (600, 'stable') 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 quiterss depends on: ii libc6 2.18-4 ii libgcc11:4.8.2-16 ii libqt4-network 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-sql 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-sql-sqlite 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-xml 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtwebkit4 2.2.1-7 ii libsqlite3-0 3.8.4.1-1 ii libstdc++6 4.8.2-16 quiterss recommends no packages. quiterss 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#744181: quiterss: Impossible to set hot keys for moving news body up or down.
Package: quiterss Version: 0.13.3+dfsg-2 Severity: minor Dear Maintainer, I set hot keys for moving body part of news up-down w/ arrow keys up-down but instead i see moving in headers and not in the body. In the refernces (i have rusian GUI, so may it is called other way in english) i chose hot keys and then news page up/down. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (700, 'testing-updates'), (700, 'testing'), (600, 'stable-updates'), (600, 'stable') 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 quiterss depends on: ii libc6 2.18-4 ii libgcc11:4.8.2-16 ii libqt4-network 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-sql 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-sql-sqlite 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-xml 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtwebkit4 2.2.1-7 ii libsqlite3-0 3.8.4.1-1 ii libstdc++6 4.8.2-16 quiterss recommends no packages. quiterss 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#744180: [libmm-glib0] Extended description
Package: libmm-glib0 Version: 1.0.0-4 Severity: minor The extended description has a few minor issues: The parenthesis (GSM, CDMA, UMTS, ...) should either lose the last comma ((GSM, CDMA, UMTS...)) or replace the ellipsis with etcetera. It's probably best to move it at the end of the sentence too. modem manager shouldn't have a space. It is preferable to use full sentences in extended descriptions. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743883: Is it realy fixed?
Hello! After reading the advisory DSA-2896-1 openssl -- security update I have upgraded openssl on my servers to 1.0.1e-2+deb7u6 and tested them again with: http://filippo.io/Heartbleed/#example.server.domain http://rehmann.co/projects/heartbeat/?domain=example.server.domainport=443submit=Submit And still I get IS VULNERABLE results! Does it mean that tests are wrong or the package is not fixed? After a while I have discovered that upgrading openssl package is not enough! It is necessary to upgrade also packages (may be too many): libcrypto1.0.0-udeb libssl-dev libssl-doc libssl1.0.0 libssl1.0.0-dbg IT SHOULD BE WRITTEN IN THE ADVISORY Alternatively (better) openssl package should require newer versions of necessary libraries. With Best Regards, Jerzy Sobczyk -- -- Institute of Control and Computation Engineering __ Jerzy Sobczyk Warsaw University of Technology /_/ | j.sobc...@ia.pw.edu.pl Nowowiejska 15/19 / / /| | http://www.ia.pw.edu.pl/~jurek00-665 Warsaw, POLAND / / _| | tel. +48 22 234 7863 _ fax. +48 22 8253719 /_/_/ |_| -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742013: ALBERTA: old license in demo/COPYING and a small patch
Hi,
I'm working on preparing Debian packages for the new ALBERTA 3.0.0
release (thanks for that). While taking a quick look I noticed that
there is still a reference to an (old?) license in demo/COPYING:
ALBERTA is freely distributed for research and education,
but you have to sign a license agreement; download the license
agreement from
Is this only a left-over from some older version or does this apply
anywhere, for example for the demo package?
I also found another small problem: alberta-utilities.pc.in contains
-lalberta-utilities!SUFFIX!, but the shared library itself uses an
underscore instead of a dash (patch attached).
Regards,
Ansgar
--- a/alberta-utilities.pc.in
+++ b/alberta-utilities.pc.in
@@ -11,5 +11,5 @@
Description: The ALBERTA utilities library.
URL: http://www.alberta-fem.de
Requires: ${DEPENDENCIES}
-Libs: -L${libdir} -lalberta-utilities!SUFFIX!
+Libs: -L${libdir} -lalberta_utilities!SUFFIX!
Cflags: -I${includedir}
Bug#740491: Please provide a NEWS file that informs about necessary changes to idmapd.conf
Hi Steve, I have had the same trouble with upgrading a Debian sid system. Indeed modifying /etc/idmapd.conf and using /run/rpc_pipefs instead of /var/lib/nfs/rpc_pipefs fixed my rpc.idmapd issues for me. However, I think it would be good to be more transparent about this. To me it would make sense adding a NEWS file that informs about this necessary change. Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpJXyiQs0DzC.pgp Description: Digitale PGP-Signatur
Bug#744179: quiterss: Not all filters work on news headers.
Please try new version from unstable. Besides to save maintainer's time you may also consider to report non-Debian-related bugs to upstream bug tracker: https://code.google.com/p/quite-rss/issues/list Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744181: quiterss: Impossible to set hot keys for moving news body up or down.
Please try new version from unstable. Besides to save maintainer's time you may also consider to report non-Debian-related bugs to upstream bug tracker: https://code.google.com/p/quite-rss/issues/list Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#729759: Bug#736345: New flex available on mentors
On Wed, Feb 05 2014, Guillem Jover wrote: Hi! On Mon, 2014-02-03 at 12:43:07 +, Gianfranco Costamagna wrote: I have packaged (since I didn't receive answers so far) the new flex release, that closes 3 or maybe more bugs. The latest version of flex is out there now. I'll tackle make next (BTW, last week was my last day at Amazon, and now I am no longer under the legal departments yoke). manoj -- A right is not what someone gives you; it's what no one can take from you. Ramsey Clark Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Bug#744182: syslog-ng: include option should be befor the log paths in the main syslog-ng.conf file
Package: syslog-ng
Version: 3.3.5-4
Severity: wishlist
The @include /etc/syslog-ng/conf.d/ option is on the bottom of the
syslog-ng.conf file, but it should be befor the log paths, as example:
-
###
# Include all config files in /etc/syslog-ng/conf.d/
###
@include /etc/syslog-ng/conf.d/
# Log paths
log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_src); filter(f_cron); destination(d_cron); };
-
If the include option is on the bottom, rules in external files like
this are not working:
filter f_drop { (message(192.168.1.251) or message(192.168.1.252));
};
log { source(s_src); filter(f_drop); flags(final); };
because the standard log paths are already loaded befor the log paths
(in this example a drop rule) in external files...
Regards
Juan Dos Santos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743965: [Pkg-utopia-maintainers] Bug#743965: network-manager: vpnc (through dispatcher) stopped working with latest NM update
On 04/10/2014 06:39 AM, Michael Biebl wrote: In case you want logs, I have made it available at: http://people.debian.org/~rrs/tmp/nm-vpn-bug-743965.txt What am I supposed to see here? Please be more specific about the problems you are having. Reverting back to the old version, there's no problem. Is this data not enough ? The logs show that it was vpnc that was terminated. When an event is processed through dispatcher, how does NM track the event's exit status ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#743883: [Pkg-openssl-devel] Bug#743883: Is it realy fixed?
On Fri, Apr 11, 2014 at 08:40:17AM +0200, Jerzy Sobczyk wrote: Hello! After reading the advisory DSA-2896-1 openssl -- security update I have upgraded openssl on my servers to 1.0.1e-2+deb7u6 and tested them again with: http://filippo.io/Heartbleed/#example.server.domain http://rehmann.co/projects/heartbeat/?domain=example.server.domainport=443submit=Submit And still I get IS VULNERABLE results! Does it mean that tests are wrong or the package is not fixed? After a while I have discovered that upgrading openssl package is not enough! It is necessary to upgrade also packages (may be too many): libcrypto1.0.0-udeb libssl-dev libssl-doc libssl1.0.0 libssl1.0.0-dbg IT SHOULD BE WRITTEN IN THE ADVISORY Alternatively (better) openssl package should require newer versions of necessary libraries. You need to udpate libssl1.0.0, it has always been written in the advisory. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744183: libmovit2 and libmovit1: error when trying to install together
Package: libmovit1,libmovit2 Version: libmovit1/1.0.3-1 Version: libmovit2/1.1-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-04-11 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Extracting templates from packages: 93% Extracting templates from packages: 100% Preconfiguring packages ... Selecting previously unselected package libdrm2:amd64. (Reading database ... 10937 files and directories currently installed.) Preparing to unpack .../libdrm2_2.4.52-1_amd64.deb ... Unpacking libdrm2:amd64 (2.4.52-1) ... Selecting previously unselected package libgomp1:amd64. Preparing to unpack .../libgomp1_4.8.2-19_amd64.deb ... Unpacking libgomp1:amd64 (4.8.2-19) ... Selecting previously unselected package libfftw3-double3:amd64. Preparing to unpack .../libfftw3-double3_3.3.4-1_amd64.deb ... Unpacking libfftw3-double3:amd64 (3.3.4-1) ... Selecting previously unselected package libglapi-mesa:amd64. Preparing to unpack .../libglapi-mesa_10.1.0-5_amd64.deb ... Unpacking libglapi-mesa:amd64 (10.1.0-5) ... Selecting previously unselected package libxau6:amd64. Preparing to unpack .../libxau6_1%3a1.0.8-1_amd64.deb ... Unpacking libxau6:amd64 (1:1.0.8-1) ... Selecting previously unselected package libxdmcp6:amd64. Preparing to unpack .../libxdmcp6_1%3a1.1.1-1_amd64.deb ... Unpacking libxdmcp6:amd64 (1:1.1.1-1) ... Selecting previously unselected package libxcb1:amd64. Preparing to unpack .../libxcb1_1.10-2_amd64.deb ... Unpacking libxcb1:amd64 (1.10-2) ... Selecting previously unselected package libx11-data. Preparing to unpack .../libx11-data_2%3a1.6.2-1_all.deb ... Unpacking libx11-data (2:1.6.2-1) ... Selecting previously unselected package libx11-6:amd64. Preparing to unpack .../libx11-6_2%3a1.6.2-1_amd64.deb ... Unpacking libx11-6:amd64 (2:1.6.2-1) ... Selecting previously unselected package libx11-xcb1:amd64. Preparing to unpack .../libx11-xcb1_2%3a1.6.2-1_amd64.deb ... Unpacking libx11-xcb1:amd64 (2:1.6.2-1) ... Selecting previously unselected package libxcb-dri2-0:amd64. Preparing to unpack .../libxcb-dri2-0_1.10-2_amd64.deb ... Unpacking libxcb-dri2-0:amd64 (1.10-2) ... Selecting previously unselected package libxcb-dri3-0:amd64. Preparing to unpack .../libxcb-dri3-0_1.10-2_amd64.deb ... Unpacking libxcb-dri3-0:amd64 (1.10-2) ... Selecting previously unselected package libxcb-glx0:amd64. Preparing to unpack .../libxcb-glx0_1.10-2_amd64.deb ... Unpacking libxcb-glx0:amd64 (1.10-2) ... Selecting previously unselected package libxcb-present0:amd64. Preparing to unpack .../libxcb-present0_1.10-2_amd64.deb ... Unpacking libxcb-present0:amd64 (1.10-2) ... Selecting previously unselected package libxcb-sync1:amd64. Preparing to unpack .../libxcb-sync1_1.10-2_amd64.deb ... Unpacking libxcb-sync1:amd64 (1.10-2) ... Selecting previously unselected package libxfixes3:amd64. Preparing to unpack .../libxfixes3_1%3a5.0.1-1_amd64.deb ... Unpacking libxfixes3:amd64 (1:5.0.1-1) ... Selecting previously unselected package libxdamage1:amd64. Preparing to unpack .../libxdamage1_1%3a1.1.4-1_amd64.deb ... Unpacking libxdamage1:amd64 (1:1.1.4-1) ... Selecting previously unselected package libxext6:amd64. Preparing to unpack .../libxext6_2%3a1.3.2-1_amd64.deb ... Unpacking libxext6:amd64 (2:1.3.2-1) ... Selecting previously unselected package libxshmfence1:amd64. Preparing to unpack .../libxshmfence1_1.1-2_amd64.deb ... Unpacking libxshmfence1:amd64 (1.1-2) ... Selecting previously unselected package libxxf86vm1:amd64. Preparing to unpack .../libxxf86vm1_1%3a1.1.3-1_amd64.deb ... Unpacking libxxf86vm1:amd64 (1:1.1.3-1) ... Selecting previously unselected package libgl1-mesa-glx:amd64. Preparing to unpack .../libgl1-mesa-glx_10.1.0-5_amd64.deb ... Unpacking libgl1-mesa-glx:amd64 (10.1.0-5) ... Selecting previously unselected package libxi6:amd64. Preparing to unpack .../libxi6_2%3a1.7.2-1_amd64.deb ... Unpacking libxi6:amd64 (2:1.7.2-1) ... Selecting previously unselected package x11-common. Preparing to unpack .../x11-common_1%3a7.7+7_all.deb ... Unpacking x11-common (1:7.7+7) ... Selecting previously unselected package libice6:amd64. Preparing to unpack .../libice6_2%3a1.0.8-2_amd64.deb ... Unpacking libice6:amd64 (2:1.0.8-2) ... Selecting previously unselected package libsm6:amd64. Preparing to unpack .../libsm6_2%3a1.2.1-2_amd64.deb ... Unpacking libsm6:amd64 (2:1.2.1-2) ... Selecting previously unselected package libxt6:amd64. Preparing to unpack .../libxt6_1%3a1.1.4-1_amd64.deb ... Unpacking libxt6:amd64 (1:1.1.4-1) ... Selecting previously unselected package libxmu6:amd64. Preparing to unpack .../libxmu6_2%3a1.1.1-1_amd64.deb ... Unpacking libxmu6:amd64 (2:1.1.1-1) ... Selecting previously unselected package libglew1.10:amd64. Preparing to unpack .../libglew1.10_1.10.0-3_amd64.deb ... Unpacking libglew1.10:amd64 (1.10.0-3)
Bug#744184: erlang-common-test: ct_run can't find jquery
Package: erlang-common-test
Version: 1:16.b.3.1-dfsg-1~bpo70+1
Severity: important
ct_run -dir . give me the next error:
Eshell V5.10.4 (abort with ^G)
(ct@localhost)1 ERROR! Priv file
/usr/lib/erlang/lib/common_test-1.7.4/priv/jquery-latest.js could not be
copied to /home/lego/work/csv.erl/csv/test/jquery-latest.js. Reason: enoent
Test run crashed! This could be an internal error - please report!
{could_not_start_process,ct_logs,
{priv_file_error,/home/lego/work/csv.erl/csv/test/jquery-latest.js}}
There is no jquery-latest.js in /usr/lib/erlang/lib/common_test-1.7.4, but it
exist in /usr/lib/erlang/lib/common-test-1.7.4 .
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 3.10.33-my (SMP w/8 CPU cores; PREEMPT)
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 erlang-common-test depends on:
ii erlang-base 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-crypto 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-debugger 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-inets 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-runtime-tools 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-snmp 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-ssh1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-test-server1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-tools 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-webtool1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-xmerl 1:16.b.3.1-dfsg-1~bpo70+1
ii libc6 2.13-38+deb7u1
ii libjs-jquery 1.7.2+dfsg-1
ii libjs-jquery-tablesorter 6-1
erlang-common-test recommends no packages.
Versions of packages erlang-common-test suggests:
ii erlang 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-doc 1:16.b.3.1-dfsg-1~bpo70+1
ii erlang-manpages 1:15.b.1-dfsg-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#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
In article
20140411024540.25679.92521.reportbug__44887.6658724204$1397184506$gmane$o...@stoneboat.aleph1.co.uk
you wrote:
This patch is very dim. I feel that one should be able to at least
move this test into one place instead of having 6 instances to
update. But I started messing with that and it simply made me forget to
file at least this basic, working verison.
diff -Nru
pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
pkg-kde-tools-0.15.13+arm64/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
---
pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
2014-02-23 12:09:30.0 +
+++
pkg-kde-tools-0.15.13+arm64/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
2014-04-06 01:42:19.0 +
@@ -161,7 +161,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/) ?
m : j;
+return ($arch =~
/^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? m
: j;
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::ssize_t;
@@ -294,7 +294,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /(arm|sh4)/) ? 'f' : 'd';
+return ($arch =~ /(arm|armel|armhf|sh4)/) ? 'f' : 'd';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst;
Most of the changes in the patch change non anchored regexps to anchored ones
to match the full arch name except the last one, that seems to be matching
arm64, while it shouldn't, right?
Happy hacking,
--
The sooner you start to code, the longer the program will take. -- Roy Carlson
Saludos /\/\ /\ `/
signature.asc
Description: Digital signature
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
Package: ubuntu-dev-tools Version: 0.143 I was seeing this error when trying to run syncpackage: $ syncpackage -d sid -r trusty-proposed resiprocate Traceback (most recent call last): File /usr/bin/syncpackage, line 37, in module from ubuntutools.archive import (DebianSourcePackage, UbuntuSourcePackage, File /usr/lib/python2.7/dist-packages/ubuntutools/archive.py, line 34, in module import urllib2 File /usr/lib/python2.7/urllib2.py, line 94, in module import httplib File /usr/lib/python2.7/httplib.py, line 79, in module import mimetools File /usr/lib/python2.7/mimetools.py, line 11, in module import rfc822 ValueError: bad marshal data (string ref out of range) I refreshed my Python install with this command: # apt-get install --reinstall python2.7 and then syncpackage was working again. Google also reveals other people have had this problem with import httplib: https://groups.google.com/forum/#!topic/weewx-user/u7RdWzgwETo so maybe it needs further analysis. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744119: RFP: libonion -- lightweight and easy to use HTTP server library
Control: reassign -1 wnpp Control: retitle -1 RFP: libonion -- lightweight and easy to use HTTP server library On Jo, 10 apr 14, 14:07:07, David Moreno Montero wrote: Package: libonion, libonion-dev, libonion-tools, libonion-examples Severity: wishlist I'm the developer of libonion, a C HTTP server library with bindings for C++. I would love to see it packaged for Debian. It has a working debian directory that packages all needed files. https://github.com/davidmoreno/onion License is both GPLv2+ and Apache2 for the main library. AGPLv3 for the examples and tools. --David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com -- 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#744074: [Pkg-openssl-devel] Bug#744074: openssl : upgrade starts disabled services
On Wed, Apr 09, 2014 at 09:26:47PM CEST, Kurt Roeckx k...@roeckx.be said: On Wed, Apr 09, 2014 at 08:50:57PM +0200, Erwan David wrote: Package: openssl Version: 1.0.1g-2 Severity: normal When upgrading to 1.0.1g2, bind9 was started. However, since I switched recently to nsd, this service is disabled (through update-rc.d) Upgrade should not start disabled services. The restart is using invoke-rc.d, so should behave properly. So it is for another reason that it restarted bind... Sorry, I think you may close the bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658254: rdnssd does not support DNSSL
Hello, Upstream is a 1.0.3, and has this bug fixed. Debian is still on 1.0.1 (from three years ago!) even in Sid. I know; I am upstream. But unfortunately I never find time to update the package and I lack an upload sponsor. Consequently, I put the package for adoption a while already, and requested help yet earlier. Can we have a new version, please? It would really help if someone with time and upload privileges would adopt it. -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744131: [Pkg-tcltk-devel] Bug#744131: tk8.6: green should not be a synonym for dark green
severity 744131 wishlist tags 744131 + wontfix thanks Hi Hashem. On Thu, Apr 10, 2014 at 6:29 PM, Hashem Nasarat has...@riseup.net wrote: Dear Maintainer, I noticed recently that the background branch color in gitk became hard to read when using gitk in Debian. This color is hard to read for anyone, but could be a serious hinderance for those with vision trouble. As far as I know, this change of the green color definition is deliberate. The new green color matches the one used in web. So, I will not revert it back. If you think that this color is unsuitable for an application, you'll have to change the application. Tk 8.6 offers 'lime' color as a replacement for '#00ff00', Tk 8.5 or earlier don't know about 'lime', but both can use 'green1'. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744184: erlang-common-test: ct_run can't find jquery
severity 744184 minor thanks Hi Oleg, On Fri, Apr 11, 2014 at 11:26 AM, Oleg lego12...@yandex.ru wrote: Version: 1:16.b.3.1-dfsg-1~bpo70+1 It's a backported package, so the bug hardly deserves to be important. ct_run -dir . give me the next error: Eshell V5.10.4 (abort with ^G) (ct@localhost)1 ERROR! Priv file /usr/lib/erlang/lib/common_test-1.7.4/priv/jquery-latest.js could not be copied to /home/lego/work/csv.erl/csv/test/jquery-latest.js. Reason: enoent Test run crashed! This could be an internal error - please report! Yes, this was the bug which is already fixed in unstable and testing. I'll upload the fix to backports shortly. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744186: RFP: pose -- PalmOS Emulator
Package: wnpp Severity: wishlist *Portion of readme.txt:Palm OS Emulator is an application that emulates the hardware for mostPalm Computing Platform Hardware devices (e.g., Pilot, PalmPilot, PalmIII, Palm V, Palm VII, etc.). The Emulator runs on most standarddesktop computers, includes those running Windows 95, Windows 98,Windows NT 4.0, Windows 2000, Mac OS 8.6, Mac OS 9.x, Mac OS X, andseveral flavors of Unix. With the Palm OS Emulator, you can emulate the functions of a Palm hardware device, including running the built-in application, as well as installing and running 3rd party applications.* Source found at http://www.zophar.net/linux/palm.html License: GPL Key dependency: FLTK -- 「女のこが天使じゃない 魔物が半分FIFTY」 ジャングルはいつもハレのちグゥ
Bug#744187: xulrunner-24.0-dbg: dependencies on nss and nspr not needed when LESS_SYSTEM_LIBS
Package: xulrunner-24.0-dbg Version: 24.4.0esr-1~deb7u1 Severity: minor Hi Mike, Just noticed that debian/control.in is missing a LESS_SYSTEM_LIBS wrapping around xulrunner-24.0-dbg's dependencies on libnss3-dbg and libnspr4-dbg. Since the local copies are used, those deps are not needed. Thanks in advance. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743883: Is it realy fixed?
On 11 April 2014 08:40, Jerzy Sobczyk j.sobc...@elka.pw.edu.pl wrote: [...] After a while I have discovered that upgrading openssl package is not enough! It is necessary to upgrade also packages (may be too many): All users are urged to upgrade their openssl packages (*especially libssl1.0.0*) and restart applications as soon as possible. [emphasis is mine] We did mention it. -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744184: erlang-common-test: ct_run can't find jquery
On Fri, Apr 11, 2014 at 11:47:14AM +0400, Sergei Golovan wrote: It's a backported package, so the bug hardly deserves to be important. No problem, but i chose this severity from variants reportbug offered to me. Since i can't use erlang-common-test package with this bug i chose: 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. This is not seems to be a cosmetic error: 7 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. Yes, this was the bug which is already fixed in unstable and testing. I'll upload the fix to backports shortly. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
On 11/04/14 09:57, Stefano Rivera wrote: Hi Daniel (2014.04.11_09:33:41_+0200) File /usr/lib/python2.7/mimetools.py, line 11, in module import rfc822 ValueError: bad marshal data (string ref out of range) Looks like a broken .pyc file. Try python -c 'import rfc822' as root? I have already fixed it using apt-get install --reinstall python2.7 How can the pyc file be broken though? While syncpackage is just a development tool, there are many administration tools and even server processes written in Python these days and they can't just intermittently break like this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
Hi Daniel (2014.04.11_09:33:41_+0200) File /usr/lib/python2.7/mimetools.py, line 11, in module import rfc822 ValueError: bad marshal data (string ref out of range) Looks like a broken .pyc file. Try python -c 'import rfc822' as root? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744174: [Pkg-mpd-maintainers] Bug#744174: mpd service runlevels all set to stop on package upgrades
Severity 744174 serious thanks What happens is described in the title... I have mpd set to LSB defaults, but when an mpd package upgrade gets pulled in, the upgrade disregards current settings and mpd's service runlevels are all set to 'stop' causing the mpd init script to be skipped on boot. The temporary fix is then to either start mpd manually or set back to LSB defaults: # update-rc.d mpd defaults I suspected this was the case on upgrade to 0.18.9-1, but with today's upgrade to 0.18.10-1 I was able to 'confirm' the problem... oh dear, you're absolutely right - the preinst is meant to transition away from START_MPD in /etc/default/mpd, but it doesn't work quite like I intended it to on the the upgrade *after* it completed its work. Shame on me! I'll try to upload a fixed package ASAP, marking this bug RC in the meantime. Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744188: debsecan: reports vulnerabilities on packages that are no longer installed
Package: debsecan Version: 0.4.17 Severity: normal In the last run (last night), I got: Date: Fri, 11 Apr 2014 02:03:04 +0200 (CEST) From: daemon dae...@xvii.vinc17.org To: r...@xvii.vinc17.org Subject: Debian security status of xvii Delivered-To: r...@xvii.vinc17.org Security report based on the sid release *** Fixed vulnerabilities CVE-2011-3624 http://security-tracker.debian.org/tracker/CVE-2011-3624 - libruby1.9.1 - ruby1.9.1 [...] But these packages libruby1.9.1 and ruby1.9.1 were no longer installed. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debsecan depends on: ii debconf [debconf-2.0] 1.5.52 ii python 2.7.5-5 ii python-apt 0.9.3.5 Versions of packages debsecan recommends: ii cron3.0pl1-124 ii postfix [mail-transport-agent] 2.11.0-1 debsecan suggests no packages. -- debconf information: debsecan/source: debsecan/mailto: root * debsecan/suite: sid debsecan/report: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744154: pu: package tweepy/1.7.1-2
Hi Miguel, Miguel Landaeta nomad...@debian.org (2014-04-10): Since wheezy release, Twitter has made breaking changes to their APIs and this has broken some packages in the archive like tweepy (e.g. #736174). according to version tracking in the BTS, this isn't fixed yet in testing/unstable; but looking at the source, it is (tweepy/api.py says /1.1, but not docs/api.rst BTW; ditto for the secure change). So please adjust found/fixed versions accordingly, this helps us figure out what to do with pu requests. ;-) Mraw, KiBi. signature.asc Description: Digital signature
Bug#574947: Status and progress
Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. I am looking to see if there's an obvious way to package this. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. Please ask me again, if my explanation is insufficient. Thanks for your help. My primary motivation is to update the package as soon as possible for the majority of the users and then address any issues incrementally. Your explanation is most helpful. Punit -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744171: transition: boost-defaults
Control: forwarded -1 https://release.debian.org/transitions/html/boost1.55.html Steve M. Robbins s...@debian.org (2014-04-10): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition As previously requested on Feb 28 2014 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704032#220): 1.55 has been in testing for a month now and has somewhat better support for recent glibc -- e.g. it doesn't suffer from .#739807 and #739904. I'd like to switch the boost-defaults to 1.55. Julien Cristau today requested that I file a new bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704032#230). Ben file: title = boost-defaults; is_affected = .build-depends ~ /libboost[a-z-]*-dev/ is_good = .depends ~ /libboost[a-z-]*1\.55/; is_bad = .depends ~ /libboost[a-z-]*1\.54/; Since there was an old boost1.54 ben file around, I've reused it, tweaking the versions: title = boost 1.55; is_affected = .build-depends ~ /libboost[0-9\.a-z-]*-dev/; is_good = .depends ~ /libboost[a-z-]*1\.55/; is_bad = .depends ~ /libboost[a-z-]*1\.(4[6-9]|5[0-5])/; notes = #744171; export = false; I'll check the generated file doesn't look crazy after the next crontab run, and commit the ben file then. Mraw, KiBi. signature.asc Description: Digital signature
Bug#744189: pbuilder: fails to --bindmount /home --login
Package: pbuilder Version: 0.215 Severity: normal tglase@tglase:~ $ sudo env DIST=squeeze eatmydata cowbuilder --bindmount /home --login - Copying COW directory forking: rm -rf /var/cache/pbuilder/build//cow.10756 forking: cp -al /var/cache/pbuilder/base.cow-squeeze/ /var/cache/pbuilder/build//cow.10756 I: removed stale ilistfile /var/cache/pbuilder/build//cow.10756/.ilist - Invoking pbuilder forking: pbuilder login --bindmounts /home --buildplace /var/cache/pbuilder/build//cow.10756 --no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.10756 cow-shell W: /home/tglase/.pbuilderrc does not exist I: Running in no-targz mode I: copying local configuration I: mounting /proc filesystem I: mounting /run/shm filesystem I: mounting /dev/pts filesystem I: Mounting /home I: policy-rc.d already exists I: Obtaining the cached apt archive contents I: entering the shell Then, it hangs. ^C kills it, nothing else works. This used to function. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages pbuilder depends on: ii coreutils 8.21-1.1 ii debconf [debconf-2.0] 1.5.52 ii debianutils4.4 ii debootstrap1.0.59 ii dpkg-dev 1.17.6 ii wget 1.15-1 Versions of packages pbuilder recommends: ii devscripts 2.14.1 ii fakeroot1.20-3 ii sudo1.8.9p5-1 Versions of packages pbuilder suggests: ii cowdancer 0.73 pn gdebi-corenone pn pbuilder-uml none -- Configuration Files: /etc/bash_completion.d/pbuilder [Errno 2] No such file or directory: u'/etc/bash_completion.d/pbuilder' -- debconf information excluded -- debsums errors found: debsums: changed file /usr/lib/pbuilder/pbuilder-createbuildenv (from pbuilder package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744190: ITP: libde265 - Open h.265 video codec implementation
Package: wnpp Severity: wishlist Owner: Joachim Bauch ba...@struktur.de * Package name: libde265 Version : 0.5-1 Upstream Author : struktur AG * URL : https://github.com/strukturag/libde265 * License : LGPL Section : libs libde265 is an open source implementation of a HEVC/H.265 video decoder. It contains the library, debug symbols, the development package and a simple player for raw bitstreams. Packaging happens at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libde265.git;a=summary The source package is available on https://mentors.debian.net/package/libde265 Best regards, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545970: Drahý příteli,
Drahý příteli, Jmenuji se Barrister Alfred Morris, jsem prime poradce a finanční organizace zde v Lomé Togo republice, omluvy pro neformální kontakt, ale Vzhledem k naléhavosti situace nebylo jiné cesty, jsem kontaktoval Jste na něco, co bude mít velký zájem / pro Vás přínosem, pokud jde o Poslal jsem tento dopis na vás před měsícem, ale nejsem si jistý, jestli to máš, já jsem neslyšel od Vy, a to je důvod, proč jsem to znovu. Dělám to pro vás nabídnout v souvislosti s smrt, což byl můj klient před jeho smrtí, takže nějaké obrovské množství peněz od 750 dolarů v bance Prosím, pokud jste skutečným vlastníkem této e-mailové adresy, prosím, vrať se ke mně co nejdříve pro další zveřejnění. S pozdravem, Barrister Alfred Morris
Bug#744191: gnome-activity-journal: doesn't start, import error
Package: gnome-activity-journal Version: 0.8.0-2 Severity: important I've installed it today, and after clicking on icon nothing happens. When started from terminal, gives message: Traceback (most recent call last): File /usr/bin/gnome-activity-journal, line 25, in module import gtk File /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py, line 40, in module from gtk import _gtk ImportError: /usr/lib/i386-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Face_GetCharVariantIndex I didin't see any problems related to this on the Web. Best regards Pamela Rojek -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-activity-journal depends on: ii gconf2 3.2.6-2 ii python 2.7.5-5 ii python-cairo1.8.8-1+b2 ii python-dbus 1.2.0-2+b2 ii python-gconf2.28.1+dfsg-1 ii python-gnome2 2.28.1+dfsg-1 ii python-gtk2 2.24.0-3+b1 ii python-support 1.0.15 ii python-xdg 0.25-4 ii zeitgeist-core 0.9.14-2 Versions of packages gnome-activity-journal recommends: ii gstreamer0.10-plugins-base 0.10.36-1.1 ii python-gst0.10 0.10.22-3 ii python-pygments 1.6+dfsg-1 gnome-activity-journal 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#744192: synapse removed from repositories but works fine
Package: synapse Version: 0.2.10-2 Severity: important Dear Maintainer, I used synapse in wheezy, and found it very useful, and also when I updated to jessie. However, when I installed jessie directly, I discovered that synapse was not in the repositories. To get it, I had to add old repositories and install it. There aren't any issues I can find with it, and it is a very useful program, with no good replacement, so it seems that it should still be in the repositories? -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 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 synapse 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-2 ii libfreetype62.5.2-1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libgee2 0.6.8-1 ii libglib2.0-02.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libgtkhotkey1 0.2.1-5 ii libjson-glib-1.0-0 1.0.0-1 ii libnotify4 0.7.6-2 ii libpango1.0-0 1.36.3-1 ii librest-0.7-0 0.7.12-3 ii libsoup2.4-12.46.0-2 ii libunique-1.0-0 1.1.6-4 ii libxml2 2.9.1+dfsg1-3 ii libzeitgeist-1.0-1 0.3.18-1 Versions of packages synapse recommends: ii pastebinit1.4-3 ii zeitgeist 0.9.14-2 ii zeitgeist-core [zeitgeist-extension-fts] 0.9.14-2 synapse 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#744157: [Pkg-xen-devel] Bug#744157: VNC parameters can be set only globally using xl
tags 744157 +fixed-upstream tags 744159 +fixed-upstream tags 744160 +fixed-upstream thanks On Thu, 2014-04-10 at 23:49 +0200, Matyas Koszik wrote: Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Thanks for your reports. xl in 4.1 was a preview (according to upstream). I believe that all of the issues with xl which you have reported are fixed by the current 4.4 release or earlier (e.g 4.2 or 4.3). Therefore I'm tagging them all as such with this one mail to the bug control address. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...
Package: src:linux Version: 3.13.7-1 Severity: normal Hi *, I had to reboot to cleanse my system of running KDE, dbus, etc. again (since KDEPIM didn’t want to “see” new incoming eMails… this used to work better in KDE 3… but offtopic for here), and since reboots heal problems anyway, and since living in Debian sid has lots of library updates under the hood… anyway, I wanted to reboot. I typed “sudo poweroff” as usual on Debian… the system switched to the text console and mostly hung. I tried a few SysRq keys such as ‘w’, ‘l’, ‘e’, ‘f’, ‘m’, ‘t’… but “This SysRq operation is disabled.” – why? (Should I open a separate bugreport for this? This cannot be!) With Alt-SysRq-S+U+S+O I at least got the system off, right? No. After the Sync, Umount, Sync, which worked fine, the Off only made the kernel print the following line in an endless loop, præfixed by the time in brackets (which did change, just fine): [.xxx] handle_exit: unexpected exit_int_info 0x8028 exit_code 0x78 This repeated over and over. I eventuall pulled external power. The system previously had been running for 2 days and a bit, with the same kernel image version. -- Package-specific info: ** Version: Linux version 3.13-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-16) ) #1 SMP Debian 3.13.7-1 (2014-03-25) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.13-1-amd64 root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [7.316208] disk 0, wo:0, o:1, dev:sda2 [7.316209] disk 1, wo:0, o:1, dev:sdb2 [7.331080] md1: unknown partition table [7.343563] device-mapper: uevent: version 1.0.3 [7.343659] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [7.346120] random: lvm urandom read with 77 bits of entropy available [7.357361] bio: create slab bio-1 at 1 [7.501644] PM: Starting manual resume from disk [7.501714] PM: Hibernation image partition 8:17 present [7.501715] PM: Looking for hibernation image. [7.501865] PM: Image not found (code -22) [7.501866] PM: Hibernation image not present or could not be loaded. [7.527331] EXT4-fs (dm-0): orphan cleanup on readonly fs [7.691454] random: nonblocking pool is initialized [7.827108] EXT4-fs (dm-0): 13 orphan inodes deleted [7.827168] EXT4-fs (dm-0): recovery complete [8.132412] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 10.340879] systemd-udevd[402]: starting version 204 [ 11.664792] wmi: Mapper loaded [ 11.684061] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4 [ 11.684137] ACPI: Power Button [PWRB] [ 11.684223] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5 [ 11.684298] ACPI: Power Button [PWRF] [ 11.685584] ACPI: processor limited to max C-state 1 [ 11.841457] parport_pc 00:05: reported by Plug and Play ACPI [ 11.841583] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] [ 11.991571] acpi-cpufreq: overriding BIOS provided _PSD data [ 12.177759] ACPI Warning: 0x0b00-0x0b07 SystemIO conflicts with Region \SOR1 1 (20131115/utaddress-251) [ 12.177954] ACPI Warning: 0x0b00-0x0b07 SystemIO conflicts with Region \SMRG 2 (20131115/utaddress-251) [ 12.178141] ACPI Warning: 0x0b00-0x0b07 SystemIO conflicts with Region \_SB_.PCI0.SBRG.ASOC.SMRG 3 (20131115/utaddress-251) [ 12.178328] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 12.200474] EDAC MC: Ver: 3.0.0 [ 12.201694] MCE: In-kernel MCE decoding enabled. [ 12.202815] AMD64 EDAC driver v3.4.0 [ 12.202922] EDAC amd64: DRAM ECC disabled. [ 12.202997] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. [ 12.202997] Either enable ECC checking or force module loading by setting 'ecc_enable_override'. [ 12.202997] (Note that use of the override may cause unknown side effects.) [ 12.418358] input: PC Speaker as /devices/platform/pcspkr/input/input6 [ 12.484617] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 12.484781] sp5100_tco: PCI Revision ID: 0x3c [ 12.484868] sp5100_tco: failed to find MMIO address, giving up. [ 12.665554] kvm: Nested Virtualization enabled [ 12.665619] kvm: Nested Paging enabled [ 12.776817] input: HDA ATI SB Front Headphone as /devices/pci:00/:00:14.2/sound/card0/input15 [ 12.776995] input: HDA ATI SB Line Out Side as /devices/pci:00/:00:14.2/sound/card0/input14 [ 12.777129] input: HDA ATI SB Line Out CLFE as /devices/pci:00/:00:14.2/sound/card0/input13 [ 12.777262] input: HDA ATI SB Line Out Surround as /devices/pci:00/:00:14.2/sound/card0/input12 [ 12.777395] input: HDA ATI SB Line Out Front as
Bug#744194: openssl: Updating main openssl package should warn about outdated derived packages
Package: openssl Version: 1.0.1g-2 Severity: wishlist Dear Maintainer, when updating my sid system to fix the Heartbleed bug, I only updated the openssl package from 1.0.1f to 1.0.1-g1, but not libssl1.0.0 for example, leaving a number of services initially vulnerable until I noticed my mistake. I may not be the only one who did this mistake, hence I would suggest to either issue a warning that there are remaining outdated packages and suggest to update those as well, or introduce a dependency so that updating openssl requires updating the derived packages, if that's feasible. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssl depends on: ii libc62.18-4 ii libssl1.0.0 1.0.1g-2 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20140325 -- 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#711757: I have the same bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have the same bug. I open main wicd window and add profile with static address. click connect I get the same log and i use watch to confirm it set ip correct watch -n 0.1 'ifconfig eth0; route -n' The wicd set ip successful but disconnect immediately for update message after some trace, i just mark some place to disable disconnect from update state file /usr/share/wicd/daemon/monitor.py #if (state != self.last_state) and (state == misc.NOT_CONNECTED) and \ #(not daemon.GetForcedDisconnect()): # daemon.Disconnect() # Disconnect() sets forced disconnect = True # so we'll revert that # daemon.SetForcedDisconnect(False) after this, work fine now! I can't do better patch because every print in monitor.py won't be show in wicd.log. - -- Thomas, Yu-Chin Tsai National Center for High-Performance Computing Software Technology Division Associate Research Fellow pub 4096R/68CDF01D 2012-08-20 Key fingerprint = 280C 3FF5 2B9F 785C 78CE ABAA A235 AC2F 68CD F01D -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTR7GEAAoJEKI1rC9ozfAdKLkQAKZQahLh9b2YD3G6B74yae/O SYVaEGt9JT3u+DiNvxCmMO5o4emLAgY3aDDbstKlXKioNpm30ow7fW+8OSlEcwUu DkEwc4IPJgbn0OJniOW5SWF35q+FvC3A2ldQhMqkxtcGKQC0ZnK5+kuAfLcf4HHx iesaa1qHLotIOqy++xpMdd9tEFZALE6U+mSPSiDLUXxVunTUo79ZMMt3kqqyfISB 8rwjNTwElduHXU+zGmD+LyF4thXV4fRs1GVubx1XhitBDHmaCR6BJH7CCdcIhWeY fm76ouZ2hTS8eUoriMQDvgARpM9D24FCYase1lWdjdpNKon2pHq7ELGIHsscA8iB JglacA9XItTOjJW3D0nxA7Q6zPCZK1Dv4VBRoJzqYf0Cf4qQdIvHadh+ekcdr62a hUNjQPFRy3WPYRGovBRX6DWGmVGMUAsY6JbX6RC8LxCSpdlcqq1rPSqPVfSQca96 GGfJvy3w2Cr+Zu4dcpIHM2M6fe5bnCwFGhgY+llod86Q/YmKs9EMYgO4pZ3rwtW/ Ciy6387VcEAp3zX6ZiYAI1mXkMCllCMoGrwYMx4CnGqaoF7IKSUFvr3dslswHmA9 TSrBkn9yVu+Z21zbEtJyV0160F2Ti2OykRzN6w2gOdI+OORNrYUPHNFJVr2yl9vI 4A+AKqlFQH9vfd6Frsk5 =q6B0 -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#744195: sanvila please package hello 2.9 :-)
Package: hello Version: 2.8-4 Hola Santiago, Por favor empaca hello 2.9 :-) Saludos, Aníbal signature.asc Description: Digital signature
Bug#739439: Please help with the libav10 transition
On 06/04/14 19:49, Reinhard Tartler wrote: Dear maintainer, I'm writing you because your package is part of the upcoming libav10 transtion, and this bug is blocking its progress, see Julien's reply to my latest inquiry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740210#22 Please note that Julien requests all packages to be fixed before starting this transition. That means that libav10 will not be in unstable before this bug is fixed. Note that according to previous messages in this bug, this particular issue has already been fixed either upstream or a patch fixing this has been attached in a previous message. Therefore, please do not hesitate to fix this bug by uploading a new version of this package with a fix for this bug included to debian/experimental so that you can build-depend against the libav (= 6:10~). If you need help with the patch or have any other questions or concerns, please do not hesitate to address your question to me, to the libav10 transition bug 739...@bugs.debian.org, or the release or pkg-multimedia team. I will do it as soon as I find time, hopefully next week. Thanks, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744196: geany-plugin-debugger: geany crashes when debugging reaches pthread_create
Package: geany-plugin-debugger
Version: 1.23+dfsg-3
Severity: normal
Using the debugger tool, geany crashes when stepping over or into
pthread_create. Try following code:
-
#include stdio.h
#include pthread.h
#include unistd.h
static void *handler(void *data)
{
sleep(5);
return NULL;
}
int main(int argc, char **argv)
{
pthread_t thread_id;
if(pthread_create(thread_id, NULL, handler, NULL) != 0)
{
printf(\pthread_create\ failed\n);
return -1;
}
pthread_join(thread_id, NULL);
return 0;
}
---
strace:
.
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5,
events=POLLIN|POLLPRI}, {fd=18, events=POLLIN}, {fd=12, events=POLLIN}, {fd=8,
events=POLLIN}], 6, 46) = 1 ([{fd=18, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {699381, 983837424}) = 0
write(4, \1\0\0\0\0\0\0\0, 8) = 8
read(18, =thread-created,id=\2\,group-id=..., 1024) = 103
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xf762d66d in g_type_check_is_value_type () from /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0
(gdb) bt
#0 0xf762d66d in g_type_check_is_value_type () from /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0
#1 0xf762faaa in g_value_init () from /usr/lib/i386-linux-
gnu/libgobject-2.0.so.0
#2 0xf7d6566a in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#3 0xf7d75196 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#4 0xf7d67a58 in gtk_tree_model_get_value () from /usr/lib/i386-linux-
gnu/libgtk-x11-2.0.so.0
#5 0xf7d687c2 in gtk_tree_model_get_valist () from /usr/lib/i386-linux-
gnu/libgtk-x11-2.0.so.0
#6 0xf7d689e0 in gtk_tree_model_get () from /usr/lib/i386-linux-
gnu/libgtk-x11-2.0.so.0
#7 0xdf433176 in stree_add_thread () from /usr/lib/i386-linux-
gnu/geany/debugger.so
#8 0xdf42be1b in ?? () from /usr/lib/i386-linux-gnu/geany/debugger.so
#9 0xdf4297a3 in ?? () from /usr/lib/i386-linux-gnu/geany/debugger.so
#10 0xf7574225 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#11 0xf752e1d7 in g_main_context_dispatch () from /lib/i386-linux-
gnu/libglib-2.0.so.0
#12 0xf752e598 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#13 0xf752e89b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#14 0xf7c78e30 in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#15 0x08085e9a in main ()
console output:
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: g_string_free: assertion 'string != NULL'
failed
(geany:20437): GLib-CRITICAL **: Source ID 519 was not found when attempting to
remove it
(geany:20437): GLib-CRITICAL **: g_hash_table_remove_all: assertion 'hash_table
!= NULL' failed
Speicherzugriffsfehler
#:~/Desktop/geany-bug$ close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 3.10.5 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages geany-plugin-debugger depends on:
ii geany [geany-abi-69] 1.23.1+dfsg-1
ii geany-plugins-common 1.23+dfsg-3
ii libc6 2.18-4
ii libcairo2 1.12.16-2
ii libgdk-pixbuf2.0-02.30.6-1
ii libglib2.0-0 2.40.0-2
ii libgtk2.0-0 2.24.23-1
ii libvte9 1:0.28.2-5
geany-plugin-debugger recommends no packages.
geany-plugin-debugger suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Bug#743630: Unchanged in 3.14-trunk-amd64
The kernel changelog for 3.14 doesn't mention the r8169, and so (as expected) the 3.14-trunk-amd64 kernel behaves the same way as rc7. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711581: Ubuntu packages on Launchpad
There has been some disucssion [1] on the Darling mailing list regarding Ubuntu packages for darling and its GNUstep dependencies, and someone seems to have begun implementing them [2, 3] which he claims to be functional, so maybe that could be used as a start. [1] https://groups.google.com/forum/#!topic/darling-project/gL-qGTgtDC4 [2] https://launchpad.net/darling-emu (see the corresponding bzr branches in the Code section) [3] https://launchpad.net/gnustep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744197: ecryptfs-utils: unix_chkpwd should not be used
Package: ecryptfs-utils Severity: important Version: 103-3 Tags: security Hi, ecryptfs-setup-private calls unix_chkpwd, but according to the latter's manpage it should not be called by anything other than libpam-unix. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744198: libpcap0.8: libpcap lacks support for Debian GNU/Hurd
Package: libpcap0.8
Version: 1.5.3-2
Severity: important
Tags: patch
Hello,
Here is a patch to include support in libpcap for Debian GNU/Hurd. Note
that the changes in this patch expect Debian specific changes in the
Hurd packages (most notably, userspace netdde drivers) and shouldn't be
forwarded upstream yet.
Thanks.
-- System Information:
Debian Release: jessie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)
Kernel: GNU-Mach 1.4-486-dbg/Hurd-0.5
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 libpcap0.8 depends on:
ii libc0.32.18-3
ii multiarch-support 2.18-3
libpcap0.8 recommends no packages.
libpcap0.8 suggests no packages.
-- no debconf information
From 0345076badd69b840777fbd3fdf2e0bdd77954db Mon Sep 17 00:00:00 2001
From: Richard Braun rbr...@sceen.net
Date: Thu, 10 Apr 2014 01:26:01 +0200
Subject: [PATCH] Debian GNU/Hurd (with NETDDE) support
---
configure.in | 6 ++
pcap-hurd.c | 255 +++
2 files changed, 261 insertions(+)
create mode 100644 pcap-hurd.c
diff --git a/configure.in b/configure.in
index e53f106..a4433bc 100644
--- a/configure.in
+++ b/configure.in
@@ -324,6 +324,8 @@ elif test -r /usr/include/linux/socket.h ; then
V_PCAP=linux
elif test -r /usr/include/net/raw.h ; then
V_PCAP=snoop
+elif test -r /usr/include/hurd.h ; then
+ V_PCAP=hurd
elif test -r /usr/include/odmi.h ; then
#
# On AIX, the BPF devices might not yet be present - they're
@@ -552,6 +554,10 @@ bpf)
LIBS=$LIBS -lrt
;;
+hurd)
+ LIBS=$LIBS -lrt
+ ;;
+
dag)
V_DEFS=$V_DEFS -DDAG_ONLY
;;
diff --git a/pcap-hurd.c b/pcap-hurd.c
new file mode 100644
index 000..c657388
--- /dev/null
+++ b/pcap-hurd.c
@@ -0,0 +1,255 @@
+#define _GNU_SOURCE
+
+/* XXX Hack not to include the Mach BPF interface */
+#define _DEVICE_BPF_H_
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include fcntl.h
+#include hurd.h
+#include mach.h
+#include time.h
+#include errno.h
+#include stdio.h
+#include stddef.h
+#include stdlib.h
+#include string.h
+#include device/device.h
+#include device/device_types.h
+#include device/net_status.h
+#include net/if_ether.h
+
+#include pcap-int.h
+
+struct pcap_hurd {
+ struct pcap_stat stat;
+ device_t mach_dev;
+ mach_port_t rcv_port;
+};
+
+static struct bpf_insn filter[] = {
+ { NETF_IN | NETF_OUT | NETF_BPF, 0, 0, 0 },
+ { BPF_RET | BPF_K, 0, 0, 1500 },
+};
+
+#define FILTER_COUNT (sizeof(filter) / sizeof(short))
+
+static int
+pcap_read_hurd(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
+{
+ struct net_rcv_msg *msg;
+ struct pcap_hurd *ph;
+ struct pcap_pkthdr h;
+ struct timespec ts;
+ int ret, wirelen, caplen;
+ u_char *pkt;
+ kern_return_t kr;
+
+ ph = p-priv;
+ msg = (struct net_rcv_msg *)p-buffer;
+
+retry:
+ if (p-break_loop) {
+ p-break_loop = 0;
+ return PCAP_ERROR_BREAK;
+ }
+
+ kr = mach_msg(msg-msg_hdr, MACH_RCV_MSG | MACH_RCV_INTERRUPT, 0,
+ p-bufsize, ph-rcv_port, MACH_MSG_TIMEOUT_NONE,
+ MACH_PORT_NULL);
+
+ if (kr) {
+ if (kr == MACH_RCV_INTERRUPTED)
+ goto retry;
+
+ snprintf(p-errbuf, sizeof(p-errbuf), mach_msg: %s,
+ pcap_strerror(kr));
+ return PCAP_ERROR;
+ }
+
+ ph-stat.ps_recv++;
+
+ /* XXX Ethernet support only */
+ wirelen = ETH_HLEN + msg-net_rcv_msg_packet_count
+ - sizeof(struct packet_header);
+ pkt = p-buffer + offsetof(struct net_rcv_msg, packet)
+ + sizeof(struct packet_header) - ETH_HLEN;
+ memmove(pkt, p-buffer + offsetof(struct net_rcv_msg, header),
+ ETH_HLEN);
+
+ caplen = (wirelen p-snapshot) ? p-snapshot : wirelen;
+ ret = bpf_filter(p-fcode.bf_insns, pkt, wirelen, caplen);
+
+ if (!ret)
+ goto out;
+
+ clock_gettime(CLOCK_REALTIME, ts);
+ h.ts.tv_sec = ts.tv_sec;
+ h.ts.tv_usec = ts.tv_nsec / 1000;
+ h.len = wirelen;
+ h.caplen = caplen;
+ callback(user, h, pkt);
+
+out:
+ return 1;
+}
+
+static int
+pcap_inject_hurd(pcap_t *p, const void *buf, size_t size)
+{
+ struct pcap_hurd *ph;
+ kern_return_t kr;
+ int count;
+
+ ph = p-priv;
+ kr = device_write(ph-mach_dev, D_NOWAIT, 0,
+ (io_buf_ptr_t)buf, size, count);
+
+ if (kr) {
+ snprintf(p-errbuf, sizeof(p-errbuf), device_write: %s,
+ pcap_strerror(kr));
+ return -1;
+ }
+
+ return count;
+}
+
+static int
+pcap_stats_hurd(pcap_t *p, struct pcap_stat *ps)
+{
+ struct pcap_hurd *ph;
+
+ ph = p-priv;
+ *ps = ph-stat;
+ return 0;
+}
+
+static void
+pcap_cleanup_hurd(pcap_t *p)
+{
+ struct pcap_hurd *ph;
+
+ ph = p-priv;
+
+ if (ph-rcv_port != MACH_PORT_NULL) {
+ mach_port_deallocate(mach_task_self(), ph-rcv_port);
+ ph-rcv_port = MACH_PORT_NULL;
+ }
+
+ if (ph-mach_dev != MACH_PORT_NULL) {
+ device_close(ph-mach_dev);
+ ph-mach_dev = MACH_PORT_NULL;
+ }
+
+ pcap_cleanup_live_common(p);
+}
+
+static int
+pcap_activate_hurd(pcap_t *p)
+{
+ struct pcap_hurd *ph;
+ mach_port_t master;
+ kern_return_t kr;
+
+ ph =
Bug#737515: dictionaries-common-dev: dh_aspell
On Thu, Apr 10, 2014 at 05:50:15PM +0200, Andreas Beckmann wrote:
On 2014-04-10 17:40, Agustin Martin wrote:
However, postrm cannot rely on anything in dependencies, there is no
warranty on removal ordering. So, script is not available and not run if
dictionaries-common is removed first (which can happen) and those dirs are
left behind. This is something I am trying to fix in new -dev debhelper
snippets allowing for explicit removal of those dirs if empty.
can't you do this cleanup already from somedict.postrm remove (instead
of somedict.postrm purge)?
It is already done at postrm removal stage. However, I now notice that when
the removal script in first snippet is run, even if there is a single
installed dict, /var/lib/{a,i}spell still has some contents that will be
removed later by the second snippet, and thus the dir is not removed. I have
to think about reversing debhelper snippets ordering.
During removal the dependencies are all
satisfied (including the package owning the directory), only at purge
time they are not.
Note that unless something has been changed recently, this may not be true.
See message http://bugs.debian.org/504880#106, from Ian Jackson. One should
better not rely on dependencies being installed at postrm.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744199: FTBFS on kfreebsd-*
Package: varnish Version: 4.0.0-1 Severity: serious Tags: upstream Forwarded: https://www.varnish-cache.org/trac/ticket/1476 Varnish 4.0.0-1 fails to build on kfreebsd-amd64 and kfreebsd-i386. This bug tracks the issue in the upstream issue tracker. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-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 Versions of packages varnish depends on: ii adduser 3.113+nmu3 ii gcc 4:4.8.2-2 ii init-system-helpers 1.18 ii libc6 2.18-4 ii libc6-dev [libc-dev] 2.18-4 ii libedit2 3.1-20140213-1 ii libjemalloc1 3.5.1-2 ii libncurses5 5.9+20140118-1 ii libpcre3 1:8.31-2 ii libtinfo5 5.9+20140118-1 pn libvarnishapi1none varnish recommends no packages. Versions of packages varnish suggests: pn varnish-doc none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733352: help needed for #733352
On 04/11/2014 12:29 AM, Diane Trout wrote: On Thursday, April 10, 2014 15:30:21 Alex Mestiashvili wrote: Dear mentors, I would greatly appreciate if somebody would help with the #733352, I've spent a couple of hours trying to resolve the issue but my cpp skills are rather poor. Thank you, Alex The patch below deals with one of the compile errors. I don't know if just hiding the const modifier is better than pushing const-ness further into tophat. Unfortunately the next const error I get is even worse. Const-ness seems to get flipped between appendValue and trying to create a seqan::Gaps... Diane diff --git a/src/segment_juncs.cpp b/src/segment_juncs.cpp index e3acc46..d73e0d6 100644 --- a/src/segment_juncs.cpp +++ b/src/segment_juncs.cpp @@ -2056,8 +2056,8 @@ void juncs_from_ref_segs(RefSequenceTable rt, MotifMap ims; -seqan::DnaStringReverseComplement rev_donor_dinuc(donor_dinuc); -seqan::DnaStringReverseComplement rev_acceptor_dinuc(acceptor_dinuc); +seqan::DnaStringReverseComplement rev_donor_dinuc(const_castDnaString(donor_dinuc)); +seqan::DnaStringReverseComplement rev_acceptor_dinuc(const_castDnaString(acceptor_dinuc)); if (talkative) fprintf(stderr, Collecting potential splice sites in islands\n); Hi Diane, Cool, thank you a lot, we are one step further! Still I think that the upstream should try to fix it or we should reintroduce back SeqAn-1.3. Best regards, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744200: RFS: mapserver/6.4.1-3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package mapserver Package name: mapserver Version : 6.4.1-3 Upstream Author : The MapServer team URL : http://www.mapserver.org/ License : MIT Section : devel It builds those binary packages: cgi-mapserver - CGI executable for MapServer libmapscript-perl - Perl MapServer module libmapscript-ruby - Transitional dummy package for ruby-mapscript libmapscript-ruby1.8 - Transitional package from libmapscript-ruby1.8 to ruby-mapscript libmapscript-ruby1.9.1 - Transitional package from libmapscript-ruby1.9.1 to ruby-mapscrip libmapserver1 - Shared library for MapServer libmapserver1-dev - Shared library development files for MapServer mapserver-bin - MapServer utilities mapserver-doc - documentation for MapServer php5-mapscript - php5-cgi module for MapServer python-mapscript - Python library for MapServer ruby-mapscript - MapServer library for Ruby To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mapserver Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mapserver/mapserver_6.4.1-3.dsc More information about MapServer can be obtained from http://www.mapserver.org/. Changes since the last upload: * Also build mapscript for Java. Thanks Ezequiel Lara Gómez for the patch. (closes: #740351) * Add lintian override for incompatible-java-bytecode-format. * Don't install ruby mapscript for Ruby 1.9, only built for 2.x now. * Drop patched FindRuby.cmake, build depend on the cmake version containing the updated module. Regards, Sebastiaan Couwenberg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743965: [Pkg-utopia-maintainers] Bug#743965: network-manager: vpnc (through dispatcher) stopped working with latest NM update
On 11. April 2014 09:09:07 MESZ, Ritesh Raj Sarraf r...@debian.org wrote: On 04/10/2014 06:39 AM, Michael Biebl wrote: In case you want logs, I have made it available at: http://people.debian.org/~rrs/tmp/nm-vpn-bug-743965.txt What am I supposed to see here? Please be more specific about the problems you are having. Reverting back to the old version, there's no problem. Is this data not enough ? Not really, no The logs show that it was vpnc that was terminated. When an event is processed through dispatcher, how does NM track the event's exit status ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739208: Please help with the libav10 transition
On Thu, Apr 10, 2014 at 11:49:32PM -0400, Jerome Charaoui wrote:
Le 2014-04-07 07:59, Reinhard Tartler a écrit :
On Mon, Apr 7, 2014 at 7:26 AM, Jerome Charaoui jer...@riseup.net wrote:
tags -fixed-upstream
thanks
Unfortunately the pull request referenced in this bug has been rejected
upstream, see
https://bitbucket.org/acoustid/acoustid-fingerprinter/pull-request/3/fix-build-with-upcoming-libav-10-release/diff#comment-1276875
Well, upstream wants to remove the problematic part completely, which
seems like a good thing. However, since this is not done yet, I would
suggest applying the proposed patches to the debian packages
nevertheless, because they are not wrong and can be dropped with the
next upstream release when the problematic patch has been removed.
Can you do that, please? Also, please tell me if there is anything I
can assist you with.
Alright, it's done.
As I don't have upload rights yet, I've placed the updated package on
mentors, see http://mentors.debian.net/package/acoustid-fingerprinter
If you could review and sponsor if everything checks out, that'd be
appreciated.
The package looks good (i.e. it builds with both libav9 and 10), so I uploaded
it. You may want to consider joining the Debian Multimedia team [0] if you need
sponsoring for future uploads.
Cheers
[0] https://wiki.debian.org/DebianMultimedia
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#744201: installation-reports: successful install of jessie - one problem, and other minor suggestions
Package: installation-reports Severity: minor Tags: d-i Dear Maintainer, It was an ultimately successful install, although there were some problems, that I will explain below. Boot method: USB Image version: http://cdimage.debian.org/cdimage/jessie_di_alpha_1/amd64/iso-cd /debian-jessie-DI-a1-amd64-CD-1.iso Date: 10/04/2014 Machine: Samsung RV520 Laptop Processor: Intel® Core™ i3-2330M CPU @ 2.20GHz × 4 Memory: 3.8 GiB (RAM) Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/mapper/zdeb--vg-root ext4 472253728 106291900 341949644 24% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 794076 3924790152 1% /run tmpfs tmpfs 1985188 368 1984820 1% /dev/shm tmpfs tmpfs 1985188 0 1985188 0% /sys/fs/cgroup tmpfs tmpfs 10240048102352 1% /run/user tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/sda1 ext2233191 27794192956 13% /boot Base System Installation Checklist: All ok: Initial boot, Detect network card, Configure network, Detect CD, Load installer modules, Detect hard drives, Partition hard drives, Install base system, Clock/timezone setup, User/password setup, Install tasks, Install boot loader, Overall install - all worked fine. Comments/Problems: 1. It wasn't clear what desktop I was going to get. I was reinstalling Jessie, and so assumed that I would get what had been the default desktop, gnome. As it turned out, I got xfce, and had to manually install many programs, which took a lot more time than I had anticipated. An easy solution to this might be that in tasksel, next to Debian Desktop Environment, it could have which one it is in brackets (or even somehow have a way to change your choice there), or just make it clear with the CDs, which one you are using. All the other issues are much more minor: 2. When asking about installing grub, the default should be the drive that you installed the operating system on. It gave the offer of the usb I was installing it from, which seems unlikely, but without making it obvious which one most people might prefer. I chose the right one, but I think I remember installing debian a year or so ago and accidentally selecting the wrong one. 3.To make the process of installing easier, it would be better if there was just one long period of waiting, so you can go away and leave it, rather than several where you have to come back and answer questions. The long waits that I experienced were erasing data (I know most people don't have this), then installing the base system, then selecting and installing software. Perhaps this would involve the installer multitasking, by loading things in the background, but it needn't have to. It could work by fairly near the beginning, most of the common questions could be asked, and this would create a preseed file, that would allow most people to leave the install after that, and come back later when it is finished - only having to ask more part way through in unusual circumstances. This would make it much easier. 4. On the initial start up of the usb, the top option was install, with graphical install below that. I think graphical should be default, as that is a lot easier for many people, especially those who might get put off by the command line. If this fails, it could fall back to non-graphical. People who prefer non-graphical normally know that enough to choose it, whereas people who prefer graphical are more likely to just go for install, as they don't realise what it means. -- Package-specific info: Boot method: Image version: Date: Date and time of the install Machine: Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
Control: reassign -1 python2.7 Hi Daniel (2014.04.11_10:02:21_+0200) How can the pyc file be broken though? I think this has been fixed in python2.7 2.7.5-5. I'm guessing from the ubuntu-dev-tools version that you're using wheezy, which doesn't have the patch. While syncpackage is just a development tool, there are many administration tools and even server processes written in Python these days and they can't just intermittently break like this. Right. Not an ubuntu-dev-tools bug. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726434: Processed: Re: Bug#726434: debian-installer: Time zone Busingen is missing ü umlaut
On Fri, Apr 11, 2014 at 01:26:53AM +0200, Wolfgang Schweer wrote: On Mon, Dec 30, 2013 at 12:07:51AM +0100, Thiemo Nagel wrote: In which language have you done the installation? Busingen is correctly translated to Büsingen including in English and German, except in Danish, Basque, French, Italian, Portuguese and Brasilian. Strange. I thought I was installing in German. I'll try to reproduce the issue during the next days and let you know. Installation in German (d-i jessie alpha1): First a hint is shown, that the translation isn't complete. Then I'm prompted to choose between: Europe/Berlin (most locations) Europe/Busingen Both alternatives seem to be untranslated. If 'dpkg-reconfigure tzdata' is executed in the installed system, the correct choices 'Europa' and 'Büsingen' show up. The reported error is due to a missing entry in tzsetup/debian/common.templates.in, I guess. diff --git a/debian/common.templates.in b/debian/common.templates.in index a68cab6..54b0d6e 100644 --- a/debian/common.templates.in +++ b/debian/common.templates.in @@ -86,6 +86,14 @@ __Choices: Santiago, Easter Island Default: America/Santiago Description: zone +Template: tzsetup/country/DE +Type: select +# :sl3: +Choices-C: Europe/Berlin, Europe/Busingen +__Choices: Berlin, Busingen +Default: Europe/Berlin +Description: location + Template: tzsetup/country/EC Type: select # :sl3: --- Without this patch (attached), 'dpkg-buildpackage -us -uc' spits out a warning to manually review the DE template... Wolfgang diff --git a/debian/common.templates.in b/debian/common.templates.in index a68cab6..54b0d6e 100644 --- a/debian/common.templates.in +++ b/debian/common.templates.in @@ -86,6 +86,14 @@ __Choices: Santiago, Easter Island Default: America/Santiago Description: zone +Template: tzsetup/country/DE +Type: select +# :sl3: +Choices-C: Europe/Berlin, Europe/Busingen +__Choices: Berlin, Busingen +Default: Europe/Berlin +Description: location + Template: tzsetup/country/EC Type: select # :sl3: signature.asc Description: Digital signature
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
On 11/04/14 12:09, Stefano Rivera wrote: Control: reassign -1 python2.7 Hi Daniel (2014.04.11_10:02:21_+0200) How can the pyc file be broken though? I think this has been fixed in python2.7 2.7.5-5. I'm guessing from the ubuntu-dev-tools version that you're using wheezy, which doesn't have the patch. While syncpackage is just a development tool, there are many administration tools and even server processes written in Python these days and they can't just intermittently break like this. Right. Not an ubuntu-dev-tools bug. Agreed - but I thought it would be the better place to file the bug report in case other people come across it while running syncpackage, now it will hopefully appear in the search results -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
So the aim is to have a mapping from sitekeys to actual project
directories containing the generated HTML.
That's right.
Ok. Am I correct in understanding that the actual system cgi script is
not provided by global but it is to be created by the user or system
administrator.
At first, you need to get the CGI scripts by executing htags, and copy
them to the system cgi area. It is required only once.
(The scripts above will become static files in the future.)
$ htags -f ... # in any place
# cp HTML/cgi-bin/*pl /usr/local/apache2/cgi-bin # required only once
#
# From now on, normal operation
#
$ cd usr/local/src/grep-2.9
$ gtags
$ htags -f --system-cgi=prj1 # 'prj1' is embeded in the form
$ cat /usr/local/var/gtags/sitekeys/prj1
/usr/local/src/grep-2.9/HTML
$ _
[CGI program]
+---
|if (key is embeded) {
| Get key = 'prj1'
| Read /usr/local/var/gtags/sitekeys/prj1
| = /usr/local/src/grep-2.9/HTML
| chdir /usr/local/src/grep-2.9/HTML
|}
|Do the job.
I am looking to see if there's an obvious way to package this. I might
resort to turning this feature off in the first update and then add it
to the package as I understand better what is needed on the packaging
side.
I agree. But I think it is no problem on as is basis, because the use
of this feature is very difficult. I am responsible about it.
It seems that you do not need to take responsibility for it.
Shigio
--
Shigio YAMAGUCHI shi...@gnu.org
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#744195: sanvila please package hello 2.9 :-)
On Fri, 11 Apr 2014, Aníbal Monsalve Salazar wrote: Package: hello Version: 2.8-4 Hola Santiago, Por favor empaca hello 2.9 :-) Hello Aníbal. Thanks for the reminder. For this release I was planning to rename hello to hello-traditional and hello-debhelper to hello. I'm working on it now, and it is a lot easier than I thought. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736973: nftables RFS resend
[ resend ] Dear mentors, I am looking for a sponsor for my package nftables * Package name: nftables Version : 0.099+git20140120-1 Upstream Author : Patric McHardy ka...@trash.net * URL : http://netfilter.org/projects/nftables/index.html * License : GPL-2 Section : net It builds those binary packages: nftables - Program to control packet filtering rules by Netfilter project To access further information about this package, please visit the following URL: http://mentors.debian.net/package/nftables Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/nftables/nftables_0.099+git20140120-1.dsc A few notes: * nftables kernel support is included with Linux 3.13. Already in Debian. * One of the nftables build-dep is libnftnl. Already in Debian. * this is the first mainstream release of nftables. * the first RFS was for nftables 0.100, but I was actually packaging 0.099 with some additional upstream commits. The version is now fixed. Regards, Arturo Borrero Gonzalez -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Steve Langasek writes (Bug#741573: Two menu systems): ... - What *I* want is for the TC to take a principled stand on the point that the policy manual exists to describe distribution-wide integration policies, instead of taking a there's more than one way to do it easy way out. Taken to its logical conclusion, this suggests that we should throw Python out of the archive because Perl does much of the same tasks. My view is that the trad and desktop menus serve different functions for different sets of users. They are superficially similar but for the reasons I have explained merging them doesn't make sense. Over the lifetime of this disagreement, I have repeatedly heard claims that the Debian menu system should not be exposed at all in e.g. the GNOME desktop because it's full of junk (paraphrased). But it is this very comprehensiveness which makes the menu valuable to other users (such as Matthew Vernon who has posted earlier in this thread). Now it might be possible to have one file format and some kind of filtering approach so that users who want to see a comprehensive menu can have one, and users who want a more aggressively curated menu see a subset. But there are other differences between the two menu systems: they tend to be preferred by different groups of people who use different menu consumers, with different capabilities and restrictions. Even leaving aside differences of preference in categorisation, the categorisation of a comprehensive menu requires a different approach to the categorisation of smaller menu. The two communities seem even to have a different view about what should go in the name of a menu entry. Desktop environment folks seem to prefer to emphasise descriptions of the functionality (image viewer) whereas in the trad menu the names of programs are more prominent. So I think even if these two systems used identical technology, you would still end up with either two parallel sets of menu entry files, or one set of files containing two parallel sets of metadata (two titles, two categorisations, different filtering information, etc.) Under these circumstances it doesn't seem sensible to me to try to enforce a merger, even from a technical point of view. (Of course we could have only one set of metadata and invite a battle between the two camps to make the one menu look like they think it ought to be, which would be even worse.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731839: ITA: alberta
Control: retitle -1 ITA: libalberta2 (alberta) Control: owner -1 ! Control: owner 742013 ! I plan to adopt ALBERTA as a reverse dependency of dune-grid. There is already a new alberta source package[1] that I plan to upload once I got a response to [2] and [3] is fixed in unstable. Ansgar [1] Because calling alberta-3.0.0 libalberta2 is not nice ;) [2] https://bugs.debian.org/742013#12 [3] https://bugs.debian.org/744031 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Stuart Prescott writes (Bug#741573: Two menu systems): Ian Jackson wrote: I think you are perfectly entitled to let the people who care about the Debian menu take care of that testing. As others have pointed out, that's a level a lot lower in everyone's current understanding of what should means in the context of policy. This may not be what was intended by the policy authors, but I think the average maintainer reads should as something that *they* are supposed to do unless they have a good technical reason. As Russ has pointed out, that is certainly how it is presented to new maintainers in our mentors process and there is an expectation there that the maintainer (not some other 3rd party) is will ensure that their packages conform to the million little shoulds in policy. Policy already lists may as the word to use for things that are optional. To me, Ian's statement above sounds a lot like a suggestion that packages *may* provide trad menu files, not *should* provide. The problem with may is that it suggests that there can be situations where it is better not to provide a trad menu entry even in cases where the policy on trad menu entries currently says that one should. It implies that a judgement needs to be made between two equally good options. I don't imagine you're proposing changing the wording of the sections of policy on doc-base entries, manpages, etc. to may. If we need to distinguish situations where we expect the maintainer to normally do the work before uploading, and ones where we don't necessarily, perhaps we need a new wording. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740861: booting an lxc guest hangs at startpar unless .legacy-bootordering
[chrysn]
hello petter,
Hi.
i was not sure where in rc the invocation is exactly, but i replaced
startpar with an `exec strace -o/startpar.strace /sbin/startpar.straced
$@` /bin/sh-script, and got the attached output.
Great. Most useful to get an idea what it is waiting for. Here is
what I believe are relevant parts of the strace:
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=@/com/ubuntu/upstart}, 22) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, \0\0\0\0\0\0\0\0\0\0\0\0, [12]) = 0
close(3)= 0
socket(PF_FILE, SOCK_SEQPACKET|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
bind(3, {sa_family=AF_FILE, path=@/com/ubuntu/upstart_startpar_bridge}, 38)
= 0
listen(3, 128) = 0
getuid()= 0
open(/etc/init.d/.depend.boot, O_RDONLY|O_NOATIME) = 4
[...]
pselect6(0, NULL, NULL, NULL, {0, 0}, {~[HUP INT QUIT TERM CHLD RTMIN], 8}) =
0 (Timeout)
pselect6(4, [3], NULL, NULL, NULL, {~[HUP INT QUIT TERM CHLD RTMIN], 8}
The pselect6() is waiting for file descriptor 3, which is a AF_FILE
socket connected to the name /com/ubuntu/upstart_startpar_bridge,
making me believe this hang is related to the upstart bridge code.
Not quite sure what is going on, but at least a starting point. Hope
someone have time to look into this, as I do not know when I will find
time to try to debug it myself.
--
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#744202: fusionforge-plugin-scmgit: User repositories creation problem inside private projects
Package: fusionforge-plugin-scmgit Version: 5.2.3-1 Severity: normal fatal: Could not change back to '/root': Permission denied fatal: Not a git repository: '/var/lib/gforge/chroot/scmrepos/git/testgit/users/obergix.git' Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Dear Maintainer, I've created a project with a private git repo, i.e. where only members have read (and write) access. Personnal repo creation cronjobs fail with something like : # /usr/share/gforge/cronjobs/create_scm_repos.php Initialized empty shared Git repository in /tmp/testgitn-XL9Q7v.git/ PHP Warning: fopen(/var/lib/gforge/chroot/scmrepos/git/testgit/users/obergix.git/hooks/post-update): failed to open stream: No such file or directory in /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 298 PHP Warning: fwrite() expects parameter 1 to be resource, boolean given in /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 299 PHP Warning: fclose() expects parameter 1 to be resource, boolean given in /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 300 I believe the git clone command should be changed from : git clone --bare $main_repo $repodir to cd $repodir; git clone --bare $main_repo . Hope this helps. Best regards, -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
Control: tags -1 pending I finally found out how to solve this bug. The message install: cannot stat '*.so*': No such file or directory is a red haring. It was also there in the original builds. One of the problems with the build system is that the scripts don't have a set -e so failures are not stopping the build process. I will commit two patches to git shortly. One is to set -e in the relevant build script to find the real root cause of this FTBFS. And second a simple change in the path in the build scripts to let the build scripts as they are used now run properly. Graham I think you want to take it from there and verify that 0.5.9 works properly. After you verified that, we can upload. After that we will work on making the whole build process of doublecmd better, maybe by changing/fixing lazarus, but that needs further investigation. Paul signature.asc Description: OpenPGP digital signature
Bug#744203: olsrd startup script does not detach from terminal
Package: olsrd
Version: 0.6.6.1-1
Severity: important
Tags: ipv6
Dear Maintainer,
trying to start olserd in the debian way with service olsrd start the
terminal is not released (I don't know if this is the correct word) and the
script does not detach.
If you press Ctrl-C olsrd stops and you need to put the in background with
Ctrl-Z (or at the end of command line above) to use it.
I tried to put also -nofork option at the end of /etc/default/olsrd (see
above) but nothing changed.
=/etc/default/olsrd
# Defaults for olsrd initscript
# sourced by /etc/init.d/olsrd
# installed at /etc/default/olsrd by the maintainer scripts
#
# Uncomment the next line run olsrd automatically at startup
#
START_OLSRD=YES
#
# Uncomment the next line to force-configure the wifi interface to be setup
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd
# is started.
#
#SETUP_ADHOC=YES
#
# debuglevel from 1 (=quiet) to 9 (=max debug)
# for running from init.d 0 is recommended
#
DEBUGLEVEL=0
#
# Specify the network interfaces that olsrd will run on, this will most likely
# be your wifi interface.
#
MESH_IF=eth0.2
#
# The wifi channel to setup using olsrd-adhoc-setup
#
channel=5
#
# The SSID for the mesh network to connect to using olsrd-adhoc-setup
#
ssid=commotionwireless.net
#
# The BSSID for the mesh network to connect to using olsrd-adhoc-setup
#
bssid=02:ca:ff:ee:ba:be
#
# command-line options
#
DAEMON_OPTS=-i $MESH_IF -d $DEBUGLEVEL -f /etc/olsrd/olsrd.conf -nofork
=/etc/default/olsrd
-- System Information:
Debian Release: 7.4
APT prefers stable
APT policy: (900, 'stable'), (850, 'testing'), (500, 'stable-updates')
Architecture: i386 (i686)
Kernel: Linux 3.13-1-486
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages olsrd depends on:
ii libc6 2.18-4
Versions of packages olsrd recommends:
ii olsrd-plugins 0.6.6.1-1
olsrd suggests no packages.
-- Configuration Files:
/etc/default/olsrd changed:
START_OLSRD=YES
DEBUGLEVEL=0
MESH_IF=eth0.2
channel=5
ssid=commotionwireless.net
bssid=02:ca:ff:ee:ba:be
DAEMON_OPTS=-i $MESH_IF -d $DEBUGLEVEL -f /etc/olsrd/olsrd.conf -nofork
/etc/olsrd/olsrd.conf changed:
DebugLevel 0
IpVersion 4
Pollrate 0.025
FIBMetric flat
UseNiit no
SmartGateway no
Hna4
{
10.150.8.0 255.255.255.0
}
UseHysteresis no
TcRedundancy 2
MprCoverage 7
LinkQualityLevel 2
LinkQualityAlgorithmetx_ff
LinkQualityAging 0.05
LinkQualityFishEye 1
LoadPlugin olsrd_txtinfo.so.0.1
{
PlParam port 2006
PlParam Accept 0.0.0.0
}
LoadPlugin olsrd_mdns.so.1.0.1
{
PlParam NonOlsrIf eth0
PlParam MDNS_TTL 20
PlParam TTL_Check true
PlParam Network_ID 2
#PlParam FilteredHost 192.168.0.1
}
InterfaceDefaults {
HelloInterval 3.0
HelloValidityTime 125.0
TcInterval 2.0
TcValidityTime 500.0
MidInterval 25.0
MidValidityTime 500.0
HnaInterval 10.0
HnaValidityTime 125.0
}
Interface eth0.2
{
Mode mesh
# LinkQualityMult 192.168.0.1 0.5
# LinkQualityMult default 0.8
}
-- 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#683120: RFS: yadifa/1.0.3-1 [ITP]
On 04/09/2014 09:00 PM, Christian Kastner wrote:
Oh, I missed something here: you are using the substitution variable
${Description}, but you are not setting it anywhere, which results in
half-empty descriptions (see the output in
debian/libdns*/DEBIAN/control). See deb-substvars(5).
Again, thanks for the review.
I had missed to add that, but now it's there and consistently used for
all packages. All other items (Vcs, Priority) have been addressed as well.
Now let's see, if this package can find a sponsor, then I can approach
the other suggestions (I already fear that half a dozen packages are not
saying: 'please review and sponsor me').
Regards,
Markus
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
Hi Daniel (2014.04.11_12:12:57_+0200) Agreed - but I thought it would be the better place to file the bug report in case other people come across it while running syncpackage, now it will hopefully appear in the search results As you said, this affects every Python app in Debian. I think it's unlikely to affect another u-d-t user. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744018: Wordpress 3.8.2 fixes two vulnerabilities [CVE-2014-0165 CVE-2014-0166]
On Wed, Apr 09, 2014 at 04:43:06PM +0200, Maximiliano Curia wrote: Would it be possible to have this issue fixed in stable? It's getting worked on. The fixes went to the security team a few minutes ago. old-stable too, if you care about that too. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740509: confirm
I can confirm this for jessie and package version 10.0+ds1-1. This is rather annoying, because at the moment the FreeBSD 9 kernel is removed on upgrade and you have no running network afterwards making reinstall older packages over network impossible. I run the 32 bit version in VMware player on Debian Linux. Kernel (dmesg) says device em0 is present and it shows the correct MAC address. Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 11:31 AM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Sweeping it under the run isn't my intention. I agree we need to resolve the issue. I'd appreciate your input on how it can be fixed properly. Punit Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743885: [Pkg-octave-devel] Bug#743885: octave: Octave triggers an assertion in Mesa
On Tue, Apr 08, 2014 at 12:07:18PM -0400, Mike Miller wrote: On Mon, Apr 7, 2014 at 23:51:46 +0200, Thomas Weber wrote: I am filing the bug right now in the hope that someone has an idea on how to continue with this - I have no clue whatsoever about Mesa. I am unable to reproduce on my laptop with Intel integrated graphics, and I'm using the same i965 driver that your backtrace lists. I don't know much about mesa either, but it could be that this is hardware dependent since the assertion seems to be coming specifically from the i965 driver. Do you have a different video card you can test on? I am running Debian unstable only on my laptop (Lenovo T61). I might be able to test it on some other hardware, but that would require quite an investment of time (installing Debian, while keeping my 2.5 year old from helping Daddy :)). And I am lacking time already. Any difference when you run the test with LIBGL_ALWAYS_INDIRECT=y in your environment? Yes, my X server crashes! So kids, don't try this at home. I see this listed in the mesa upstream bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=36193 I saw this too, but considered it unrelated as it mentioned VmWare. Hmm, maybe I should add myself to the bug report, as I can reproduce it with 100% reliability. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744146: libalien-sdl-perl: depends on libsdl-gfx1.2-4
You're right. I'm going to remove the hardcoded deps on libs in libalien-sdl- perl. 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#744205: logcheck-database: rule for dhcp
Package: logcheck-database
Version: 1.3.15
Severity: normal
Dear Maintainer,
isc-dhcp-server startup message now refers to https url:
s{For info, please visit http://www}{For info, please visit https://www}
-- 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/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- Configuration Files:
[deleted - my user can't read them, and I didn't run reportbug as root ...]
-- 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#744146: Pending fixes for bugs in the libalien-sdl-perl package
tag 744146 + pending thanks Some bugs in the libalien-sdl-perl package are closed in revision 37c7cca497109ca763aa10f8fef771273ef3c229 in branch 'master' by Dominique Dumont The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libalien-sdl-perl.git;a=commitdiff;h=37c7cca Commit message: control: removed hard-coded dependencies on lib packages (Closes: #744146) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736309: libnetfilter-queue serious bug, #736309
Hi Alexandr,
Bug #736309:
libnetfilter-queue-{dev, dbg}: unhandled symlink to directory conversion:
/usr/share/doc/PACKAGE
is marked as serious, and is causing several packages (in my cast,
suricata and nfqueue-bindings) to be scheduled for autoremove.
Do you plan to upload a fixed version ?
Thanks,
Pierre
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744206: linux-image-3.2.0-4-amd64: add 'bc' as a build dependancy
Package: src:linux Version: 3.2.54-2 Justification: fails to build from source (but built successfully in the past) Severity: serious Dear Maintainer, *** Please consider answering these questions, where appropriate *** 'bc' is now a build-time dependancy of the linux kernel. As this isn't marked as a dependancy of build-essential or any of the normal build-chain tools, it should be added to the debian/control for kernel src packages. Building the kernel on a host without bc will result in an error. The first of which is: AS arch/x86/vdso/vdso32/sysenter.o CC kernel/irq_work.o CC arch/x86/vdso/vdso32-setup.o BC kernel/timeconst.h /bin/sh: 1: bc: not found make[2]: *** [kernel/timeconst.h] Error 127 make[1]: *** [kernel] Error 2 *** End of the template - remove these lines *** -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/my-root ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: * not needed ** Model information ** Loaded modules: ** USB devices: -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (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 linux-image-3.2.0-4-amd64 depends on: ii debconf [debconf-2.0] 1.5.49 ii initramfs-tools [linux-initramfs-tool] 0.109.1 ii kmod9-3 ii linux-base 3.5 ii module-init-tools 9-3 Versions of packages linux-image-3.2.0-4-amd64 recommends: pn firmware-linux-free none Versions of packages linux-image-3.2.0-4-amd64 suggests: pn debian-kernel-handbook none ii grub-pc 1.99-27+deb7u2 pn linux-doc-3.2 none Versions of packages linux-image-3.2.0-4-amd64 is related to: -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744207: cmake: FTBFS on hppa
Package: cmake Version: 2.8.12.1-1.1+b2 Severity: serious Justification: fails to build from source (but built successfully in the past) See: http://buildd.debian-ports.org/status/fetch.php?pkg=cmakearch=hppaver=2.8.12.1-1.2stamp=1397193614 It looks like the freetype bug isn't fixed. -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.14.0+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages cmake depends on: ii cmake-data2.8.12.1-1.1 ii libarchive13 3.1.2-8 ii libc6 2.18-4+b1 ii libcurl3 7.36.0-1+b1 ii libexpat1 2.1.0-4+b1 ii libgcc4 4.8.2-19 ii libstdc++64.8.2-19 ii procps1:3.3.9-3 ii zlib1g1:1.2.8.dfsg-1+b1 Versions of packages cmake recommends: ii gcc 4:4.8.2-3 ii make 3.81-8.3+b1 Versions of packages cmake suggests: pn codeblocks none pn eclipse 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#599972: argus: FTBFS on mips*: cp: cannot stat `./bin/argus': No such file or directory
Hello,
Instead of statically linking,
we could replace the private libpcap function pcap_offline_read
with the proper pcap_dispatch function.
A similar issue is reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545595
The patch that include this change is attached.
Regards,
Dejan
--- argus-3.0.0.orig/argus/ArgusSource.c 2008-03-17 15:00:51.0 +
+++ argus-3.0.0/argus/ArgusSource.c 2014-04-11 12:12:36.0 +
@@ -2209,7 +2209,7 @@
} else {
for (i = 0; i src-ArgusInterfaces; i++) {
src-ArgusThisIndex = i;
-pcap_offline_read (src-ArgusInterface[i].ArgusPd, src-eNflag,
+pcap_dispatch (src-ArgusInterface[i].ArgusPd, src-eNflag,
src-ArgusInterface[i].ArgusCallBack, (u_char *) src);
}
}
Bug#744205: update
Actually there's more changed than that, sorry. The full line in question: Apr 11 23:42:05 jet dhcpd: For info, please visit https://www.isc.org/software/dhcp/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744208: Replace the dependency on libcommons-collections-java
Package: biojava3-live Severity: normal Hi, libcommons-collections3-java is a drop in replacement of libcommons-collections-java which is going to be removed. Could you please update the dependency? Thank you, Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736309: libnetfilter-queue serious bug, #736309
On Fri, 11 Apr 2014, Pierre Chifflier wrote:
Hi Alexandr,
Bug #736309:
libnetfilter-queue-{dev, dbg}: unhandled symlink to directory conversion:
/usr/share/doc/PACKAGE
is marked as serious, and is causing several packages (in my cast,
suricata and nfqueue-bindings) to be scheduled for autoremove.
Do you plan to upload a fixed version ?
As soon as I find time to fix it.
Patches are of course appreciated.
Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744209: Replace the dependency on libcommons-collections-java
Package: alien-hunter Severity: normal Hi, libcommons-collections3-java is a drop in replacement of libcommons-collections-java which is going to be removed. Could you please update the dependency? Thank you, Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Steve == Steve Langasek vor...@debian.org writes: Steve On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote: Thanks for bringing this issue back to the question that was brought to the TC. The discussion so far on this bug has focused on discussing what the right menu policy is for Debian. That, however was not the question that was brought to the TC. Steve It is my understanding that this is exactly the question that Steve has been referred to the TC, because the default policy Steve process only works when there is a consensus - and there is Steve not a consensus here. It's my understanding of whether there is a consensus was in debate. Russ believed (and made a call) that there was a consensus. If the TC looks at the discussion and concludes that no, nope not a consensus there, then I'll be entirely happy with the sort of discussions the TC is happening now. Interestingly, from some side comments Ian has made I actually suspect he's looked enough that he at least has come to the conclusion that no, not a consensus here, but he's never said that. I'd feel a lot happier if some TC members would actually state opinions on whether as Bill claimed there are substantial non-addressed issues brought up in the policy process. If so, then deciding on the base issue makes sense. If, as Russ claimed, a consensus was reached in a properly conducted policy process, then I strongly disagree with the approach the TC is taking. I think it creates significant harm for the project as a whole when the TC does not generally respect the processes and work of the rest of the project. In this particular instance it's really frustrating to those who spent a long time in the policy discussion and who believed they had reached a conclusion. Having been in similar situations in the past it is frustrating when someone comes into review things and does not respect the time and energy. Why should I participate in discussions in the future trying to find and build a compromise if those discussions will ultimately be overruled by a body who will not work with them? It tends to create feelings of frustration and powerlessness rather than feelings of pride and ownership when we think about our work. Respecting the time and energy doesn't mean agreeing with the result. It does mean taking the time to understand the result. Having been in similar situations I felt a lot better when my work was reviewed and someone came along, carefully considered the discussion and concluded that we hadn't actually reached a consensus. At least they respected our work enough to evaluate it. We all participate enough in technical work that we know we'll be wrong. Wrong is OK; not worth being listened to promotes veryp negative feelings. So, if you've reviewed this enough to support Bill's claim that there isn't a consensus because there are substantial objections raised in the discussions and not addressed, then please say that. If you have not reviewed things sufficiently to make that conclusion, then I ask you and the rest of the TC to take sufficient steps that such a review happen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735833: Bug#739598: pystache not migrating to testing due to FTBFS
On 04/11/2014 12:56 AM, Kouhei Maeda wrote: Hi, I have fixed and have uploaded. I was to understand that not the command of all, that it may be added only to the loop statement, my understanding correct? Yes, you got it correct. http://mentors.debian.net/debian/pool/main/p/pystache/pystache_0.5.3-4.dsc Package is sponsored. Thanks a lot for your contribution to Debian! :) 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#742498: Communication with Debian team
Hi Narcis, As you can read at the minutes: http://davical.dhits.nl/index.php?title=Community_Support We propose you to maintain the communication with the Debian team about their repositories with DAViCal. up to now, there is no Debian team around DAViCal except for Andrew, who is a Debian Developer (DD) and the sole maintainer of the davical and awl Debian packages. From what I can see, the Debian packaging for davical and awl is maintained directly in the upstream repository's master branch, in the debian/ directory. So my idea is that you, the new DAViCal team, maintain the Debian packaging in your upstream repo (just like Andrew did in the past), build and test new Debian packages, and then give me a shout so that I can review your changes and upload the updated package to the Debian archive. I can do some mentoring regarding Debian packaging, but I'd prefer if I can leave the main responsibility with you. ANDREW: assuming your agreement, could you state (preferably in a signed email to #742498) that you're ok with having your Debian packages awl and davical taken over / co-maintained by the upstream DAViCal team? Florian smime.p7s Description: S/MIME cryptographic signature
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote: On Fri, Apr 11, 2014 at 11:31 AM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. Which is why I say something equivalent. This was the best that Shigio and I could come up with together 15 years ago, to meet the needs of doing this in a way that was suitable for the distro. I'd like to think that if anything there would be Better ways to do this today, given the number of web-appy type things that also exist. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. Well, your first reply to my query was I don't use this, so I could just turn it off. And you were still suggesting that as an option. The equation is pretty simple really - either we solve the problem(s) that makes this unsuitable for release with the distro, or it remains unsuitable for release with the distro. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? Well ... no. That doesn't make any sense at all. The cgi scripts run with the privilege of the web server. Which means an audited copy of that needs to be installed and enabled by someone with the privilege to decide whether or not that is acceptable. And someone with similar privilege needs to decide what files it will be allowed to access. Which means all of this needs to: a) Not be generated on the fly, so that the sysadmin can actually audit it, and know that what they audited is what is running. b) Not be world writable. Which is effectively what you'd be doing if you let 'non-static' content run executables from ~pub_html with elevated privilege. None of this is rocket science to do. It just requires some acceptance that sane security practices are actually important, and need to be designed in from the beginning, not handwaved away as too hard. But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Sweeping it under the run isn't my intention. I agree we need to resolve the issue. I'd appreciate your input on how it can be fixed properly. If it isn't your intention, that's great, but that wasn't what your words kept saying :) I, and others, have said many times what is needed to do this sanely, and the constraints above should not be that hard to satisfy. What has so far proved impossible has been convincing Shigio that chmod 777 is not an acceptable substitute for this. And I don't really know what else I can say anymore that might change that. Shigio, please reconsider. We have people prepared to spend time on this. Let's use that to do this properly
Bug#744204: gdb: Upgrade 7.7 for ppc64el enablements and add patch
Hello, 2014-04-11 13:47 GMT+02:00 Frederc Bonnard fre...@linux.vnet.ibm.com: the current version of gdb in debian unstable is not new enough to support the new architecture ppc64el. Some enablements has been done upstream which would be welcome and we are providing a patch to complete support of ppc64le. The debdiff provided includes : - minor changes to the debian packaging so that it can apply on gdb 7.7 tarball and take into account ppc64el arch : arch added, some man pages are found in a different place now, tests have been changed to not stop build when some fails - refreshing of patches and removal of not needed patches - addition of ppc64el patch on top of gdb 7.7 : ppc64el.diff by Ulrich Weigand Thanks very much! I'll consider those for upcoming package release. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744210: (no subject)
Package: installation-reports : Xorg -configure do not give good graphical screen. Severity: normal Dear Maintainer, *** 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)? I did not seen the graphic screen after installing, just a white area at the bottom of the screen and a black area at the top, so screen is : 2/3 white, 1/3 black, so i boot on netinst CD in rescue mode using yaboot.( C key hold on, then type rescue in yaboot screen ), then i execute a shell in dev/sde3 . I see a blue screen with a grey line at the bottom, then I type sudo apt-get install xserver-xorg-video-ati, then i reboot. No graphical screen. I type sudo apt-get install --reinstall xserver-xorg-video-ati, then i reboot. No graphical screen. I type sudo apt-get install --reinstall xserver-xorg, then i reboot. No graphical screen. I just understood reading the outcomes that i have do was useless. I reboot and type sudo aptitude update, then sudo aptitude safe-upgrade, sudo aptitude full upgrade, then i type startx, i just see very quickly : file 'I don't remember the name' is missing, then a black screen, then a window with a message : Oh mince ! Quelque chose s'est mal passé. Un problème est survenu et le système ne peut pas se récupérer.Déconnectez-vous et et essayez à nouveau. Fermer la session then i reboot and go to /var/log and read syslog with less utilitary. I read many of things, so after a moment i'am just concentrated only on ERROR messages. I read carefully this : platform r128_cce.0: firmware: agent aborted loading r128/r128_cce.bin (not found?) [drm: r128_do_init_cce] *ERROR* Failed to load firmware! [drm: r128_cce_stop] *ERROR* called with no initialization I was thinking about ati-rage128. I have read on internet about Xorg server configuration, then i type cd /etc/X11 and i see that file /etc/X11/xorg.conf and directory /etc/X11/xorg.cond.d/ are missing in my system. Internet says : type Xorg -configure, then i do so. Extract of the outcome : X. Org X server 1.12.4 log file of this operation : /var/lo/Xorg.0.log list of video drivers : ati tdfx s3 chips sisusb r128 radeon mga sis mach64 trident s3virge nouveau savage fbdev (++) Using config file: /xorg.conf.new ( ) 2 Symbols equal inside previous parenthesis Using system config directory /usr/share/X11/Xorg.conf.d Number of created screens does not match number of detected devices. Configuration failed. Server terminated with error (2). Closing log file. End of extract. because english isn't my language, i do not understand english sentences at the first time, then i make useles things like sudo apt-get install --reinstall xserver-xorg-video-r128. Then i reboot. No result. Then i type service gdm start. Outcome : gdm inconnu ( unkwown) then i type cd /etc/X11 cp /xorg.conf.new xorg.conf mkdir xorg.conf.d so I have now xorg.conf file and directory xorg.conf.d in /etc/X11 . Then i reboot. No graphical screen. I read on Internet and understood what I must edit manually /etc/X11/xorg.conf for mouse, keyboard device and for screen device. I will do so when i wil have very well understood this. * What was the outcome of this action? * What outcome did you expect instead? I thinked that process of Xorg config was automatic, but it was'nt. But life is'nt also automatic so ... -- Package-specific info: Boot method: CD netinst Image version: debian-7.4.0-powerpc-netinst.iso Date: Date and time of the install Machine: PowerMac G4 Gigabit Ethernet �2 x 450 MHz Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=7 (wheezy) - installer build 20130613+deb7u1+b2 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a:
Bug#741573: Two menu systems
Sam Hartman writes (Bug#741573: Two menu systems): If, as Russ claimed, a consensus was reached in a properly conducted policy process, then I strongly disagree with the approach the TC is taking. I think it creates significant harm for the project as a whole when the TC does not generally respect the processes and work of the rest of the project. It is part of the job of the TC to resolve disputes about the content of technical policy. We do that not simply by observing whether some proper process was followed. We do it by examining the issue on the merits. Respecting the time and energy doesn't mean agreeing with the result. It does mean taking the time to understand the result. I have read the entire bug log. It is mostly based on that reading that I have come to the view I now hold. So, if you've reviewed this enough to support Bill's claim that there isn't a consensus because there are substantial objections raised in the discussions and not addressed, then please say that. If you have not reviewed things sufficiently to make that conclusion, then I ask you and the rest of the TC to take sufficient steps that such a review happen. It is not the job of the TC to decide whether there was or was not consensus. It is the job of the TC to decide in cases of dispute what the best technical approach is. It is clear that there is a dispute here; a dispute which has been referred to the TC. That means that it is the TC's job now to decide on the merits. Having read the bug log I disagree with the policy change that was made (and then reverted). I disagree with it for the reasons stated by Bill and for reasons based on my own analysis of the situation as I have set out in this thread. I disagree with the change on substantive grounds, not on the grounds of any procedural complaint. I disagree with the policy change despite the substantive arguments made in the bug log - arguments which I have, obviously, read and considered. If the TC looks at the discussion and concludes that no, nope not a consensus there, then I'll be entirely happy with the sort of discussions the TC is happening now. In deciding what the contents of the policy should be, it is not necessary or desirable for the TC to consider whether there was consensus at the time the policy change was committed (or, for that matter, reverted). Having been in similar situations I felt a lot better when my work was reviewed and someone came along, carefully considered the discussion and concluded that we hadn't actually reached a consensus. At least they respected our work enough to evaluate it. We all participate enough in technical work that we know we'll be wrong. Wrong is OK; not worth being listened to promotes veryp negative feelings. The question of consensus, or lack of it, is irrelevant. Listening to the arguments, and evaluating the proposals on their merits, is exactly what we are doing. So, if you've reviewed this enough to support Bill's claim that there isn't a consensus because there are substantial objections raised in the discussions and not addressed, then please say that. You seem to be using a strange definition of consensus that suggests a consensus might exist despite objections, if those objections have been addressed (to the satisfaction of some participants but not to the satisfaction of the objectors). But, this is not relevant to the TC so there is no need to say more about it. Ultimately you seem to be seeking a remedy for what you see as a process violation. The TC is not going to help you with that. As I say, it is quite common for disputes to end up at the TC after one or both sides have escalated to questionable actions. In these situations the TC will try to decide on the underlying technical issue, rather than seeking to judge people's past actions. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744211: pyparted: Please support Python 3
Package: pyparted
Version: 3.6-6
Severity: normal
Tags: patch
Please provide a Python 3 binding of pyparted. Building 3.6 with Python 3
support caused a build failure. The upstream changelog showed changes
regarding Python 3. I therefore updated the package to the latest release
(3.10) and was able to successfully build a Python 3 module. A working patch is
attched. The patch just covers the diff for the debian directory.
diff --git a/debian/changelog b/debian/changelog
index caa9156..40572fa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pyparted (3.10-1) UNRELEASED; urgency=medium
+
+ * New upstream release.
+ * Switch to pybuild.
+ * Add Python 3 support.
+
+ -- Benjamin Drung benjamin.dr...@profitbricks.com Fri, 11 Apr 2014 14:56:24 +0200
+
pyparted (3.6-6) unstable; urgency=low
[ Tim Gardner ]
diff --git a/debian/control b/debian/control
index 270e807..6406487 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,10 @@ Section: python
Priority: optional
Maintainer: Parted Maintainer Team parted-maintain...@lists.alioth.debian.org
Uploaders: Luca Falavigna dktrkr...@debian.org, Colin Watson cjwat...@debian.org
-Build-Depends: debhelper (= 7.0.50~), python-all-dev (= 2.6.6-13~), python-all-dbg (= 2.6.6-13~), pkg-config, libparted0-dev (= 2.3), dh-autoreconf
+Build-Depends: debhelper (= 7.0.50~), python-all-dev (= 2.6.6-13~), python-all-dbg (= 2.6.6-13~), pkg-config, libparted0-dev (= 2.3), python3-all-dev, python3-all-dbg
Standards-Version: 3.9.2
X-Python-Version: = 2.6
+X-Python3-Version: = 3.0
Homepage: http://fedorahosted.org/pyparted/
Vcs-Git: git://git.debian.org/git/parted/debian/pyparted.git
Vcs-Browser: http://git.debian.org/?p=parted/debian/pyparted.git
@@ -32,3 +33,14 @@ Description: Python interface for libparted - Debugging symbols
library for disk partitioning and file system manipulation.
.
This package contains debugging symbols.
+
+Package: python3-parted
+Architecture: any
+Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Provides: ${python3:Provides}
+Description: Python 3 interface for libparted
+ pyparted is a set of Python modules that provide Python programmers an
+ interface to libparted (http://www.gnu.org/software/parted), the GNU parted
+ library for disk partitioning and file system manipulation.
+ .
+ This package contains Python 3 extension itself.
diff --git a/debian/patches/py26.patch b/debian/patches/py26.patch
deleted file mode 100644
index 2bc2667..000
--- a/debian/patches/py26.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Description: Enable support for python2.6
-Author: Luca Falavigna dktrkr...@debian.org
-Bug: http://bugs.debian.org/642545
-Forwarded: not-needed
-
-Index: pyparted/configure.ac
-===
pyparted.orig/configure.ac 2011-09-24 01:05:14.616973338 +0200
-+++ pyparted/configure.ac 2011-09-24 01:07:24.116977306 +0200
-@@ -19,7 +19,7 @@
- dnl Red Hat Author(s): David Cantrell dcantr...@redhat.com
-
- m4_define(libparted_required_version, 2.3)
--m4_define(python_required_version, 2.7)
-+m4_define(python_required_version, 2.6)
-
- AC_PREREQ(2.59)
- AC_INIT([pyparted], [3.6], [pyparted-de...@redhat.com])
diff --git a/debian/patches/series b/debian/patches/series
index f9703da..74ae2f7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1 @@
-py26.patch
no-last-flag-check.patch
diff --git a/debian/rules b/debian/rules
index e4527af..df987a7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,36 +1,6 @@
#!/usr/bin/make -f
-PYTHONS := $(shell pyversions -vr debian/control)
+export PYBUILD_NAME=parted
%:
- dh $@ --with python2,autoreconf
-
-clean:
- rm -fr build
- dh $@
-
-override_dh_auto_configure:
- set -e; for pyvers in ${PYTHONS}; do \
- mkdir -p build/py$$pyvers; cp -Rl `ls . | grep -v build | grep -v debian` build/py$$pyvers;\
- (cd build/py$$pyvers ./configure --prefix=/usr PYTHON=/usr/bin/python$$pyvers); \
- mkdir -p build/py$$pyvers-dbg; cp -Rl `ls . | grep -v build | grep -v debian` build/py$$pyvers-dbg; \
- (cd build/py$$pyvers-dbg ./configure --prefix=/usr PYTHON=/usr/bin/python$$pyvers-dbg CFLAGS=-g -ggdb ); \
- done
-
-override_dh_auto_build:
- set -e; for pyvers in ${PYTHONS}; do \
- $(MAKE) -C build/py$$pyvers/; \
- $(MAKE) -C build/py$$pyvers-dbg/; \
- done
-
-override_dh_auto_install:
- set -e; for pyvers in ${PYTHONS}; do \
- $(MAKE) -C build/py$$pyvers/ install DESTDIR=$(CURDIR)/debian/python-parted; \
- $(MAKE) -C build/py$$pyvers-dbg/ install DESTDIR=$(CURDIR)/debian/python-parted-dbg; \
- (cd $(CURDIR)/debian/python-parted-dbg/usr/lib/python$$pyvers/*-packages mv _pedmodule.so _pedmodule_d.so); \
- done
- find $(CURDIR)/debian/python-parted -name *.la -delete
- find $(CURDIR)/debian/python-parted-dbg -name *parted -exec rm -fr {} +
-
-override_dh_strip:
- dh_strip --dbg-package=python-parted-dbg -X_pedmodule_d.so
+ dh $@ --buildsystem pybuild --with python2,python3
Bug#744213: CVE-2013-4544: vmxnet3: lack of data validation coming from guest
Source: qemu Version: 1.4.0~rc0+dfsg-1exp Severity: grave Tags: security upstream patch jessie sid There's a security hole reported for vmxnet3 device as emulated by qemu. This is a vmware network device. The vulnerability has been assigned CVE-2013-4544. The device has been introduced in qemu version 1.4, so older debian releases are not affected. The impact is somewhat low still, since only guests using vmxnet3 device are affected, which should not be many. Upstream maintainer has a patchset for this issue: http://thread.gmane.org/gmane.comp.emulators.qemu/265562 Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
Package: libopenconnect2
Version: 5.03-1
Severity: important
Tags: patch upstream
X-Debbugs-CC: openconnect-de...@lists.infradead.org
The changes in gnutls.c from v5.01 to v5.02 concerning support of CA
certificates from PKCS#11 tokens (with GnuTLS 3.2.7+) break functionality
in openconnect at least if compiled with GnuTLS 2.12.x. Therefore, it also
affects libopenconnect2 (= 5.02-1) in Ubuntu 14.04LTS.
I have tried to investigate on this issue with GDB and have come as far as
to gnutls.c:1517 where err is not the return value of any call to
gnutls_pkcs11_get_raw_issuer() or gnutls_x509_crt_import() within the
code guarded by
#if defined(HAVE_P11KIT) defined(HAVE_GNUTLS_PKCS11_GET_RAW_ISSUER)
if compiled with GnuTLS 2.12.x as in Debian and Ubuntu Linux.
So I thought to shift the lines 1517-1518 if (err) break; upwards to
its original position, but then it crashes in gnutls.c:1522 invoking
function gnutls_x509_crt_check_issuer(). Finally, I have given up and,
although I know this is far from being smart, I reverted all changes in
gnutls.c to v5.01 which works perfectly for me. The patch for reverting
changes in gnutls.c is attached.
Could you please find a smarter fix or at least apply the given patch
temporarily.
Thank you in advance!
Thomas Uhle--- openconnect-5.03/gnutls.c 2014-02-03 14:11:19 +0100
+++ openconnect-5.01/gnutls.c 2014-04-10 14:10:52 +0200
@@ -499,7 +499,8 @@ static int assign_privkey(struct opencon
gnutls_privkey_t pkey,
gnutls_x509_crt_t *certs,
unsigned int nr_certs,
- uint8_t *free_certs)
+ gnutls_x509_crt_t *extra_certs,
+ unsigned int nr_extra_certs)
{
int i;
@@ -507,21 +508,28 @@ static int assign_privkey(struct opencon
if (!vpninfo-my_certs)
return GNUTLS_E_MEMORY_ERROR;
- vpninfo-free_my_certs = gnutls_malloc(nr_certs);
- if (vpninfo-free_my_certs) {
- gnutls_free(vpninfo-my_certs);
- vpninfo-my_certs = NULL;
- return GNUTLS_E_MEMORY_ERROR;
- }
-
- memcpy(vpninfo-free_my_certs, free_certs, nr_certs);
memcpy(vpninfo-my_certs, certs, nr_certs * sizeof(*certs));
vpninfo-nr_my_certs = nr_certs;
/* We are *keeping* the certs, unlike in GnuTLS 3 where our caller
can free them after gnutls_certificate_set_key() has been called.
- So wipe the 'free_certs' array. */
- memset(free_certs, 0, nr_certs);
+ So first wipe the 'certs' array (which is either 'cert' or
+ 'supporting_certs' in load_certificate())... */
+ memset(certs, 0, nr_certs * sizeof(*certs));
+
+ /* ... and then also zero out the entries in extra_certs[] that
+ correspond to the certs that we're stealing.
+ We know certs[0] was already stolen by the load_certificate()
+ function so we might as well start at certs[1]. */
+ for (i = 1; i nr_certs; i++) {
+ int j;
+ for (j = 0; j nr_extra_certs; j++) {
+ if (vpninfo-my_certs[i] == extra_certs[j]) {
+extra_certs[j] = NULL;
+break;
+ }
+ }
+ }
gnutls_certificate_set_retrieve_function(vpninfo-https_cred,
gtls_cert_cb);
@@ -539,7 +547,8 @@ static int assign_privkey(struct opencon
gnutls_privkey_t pkey,
gnutls_x509_crt_t *certs,
unsigned int nr_certs,
- uint8_t *free_certs)
+ gnutls_x509_crt_t *extra_certs,
+ unsigned int nr_extra_certs)
{
gnutls_pcert_st *pcerts = calloc(nr_certs, sizeof(*pcerts));
int i, err;
@@ -891,7 +900,7 @@ static int load_certificate(struct openc
gnutls_x509_crt_t last_cert, cert = NULL;
gnutls_x509_crt_t *extra_certs = NULL, *supporting_certs = NULL;
unsigned int nr_supporting_certs = 0, nr_extra_certs = 0;
- uint8_t *free_supporting_certs = NULL;
+ unsigned int certs_to_free = 0; /* How many of supporting_certs */
int err; /* GnuTLS error */
int ret;
int i;
@@ -1002,12 +1011,6 @@ static int load_certificate(struct openc
else if (!ret) {
if (nr_supporting_certs) {
cert = supporting_certs[0];
-free_supporting_certs = gnutls_malloc(nr_supporting_certs);
-if (!free_supporting_certs) {
- ret = -ENOMEM;
- goto out;
-}
-memset(free_supporting_certs, 1, nr_supporting_certs);
goto got_key;
}
vpn_progress(vpninfo, PRG_ERR,
@@ -1428,35 +1431,19 @@ static int load_certificate(struct openc
choose the _right_ one. (RT#1942)
Pick the right ones for ourselves and add them manually. */
- /* We may have already got a bunch of certs from PKCS#12
- file. Remember how many need to be freed when we're done,
- since we'll expand the supporting_certs array with more
- from the cafile and extra_certs[] array if we can, and
- those extra certs must not be freed (twice). */
- if (!nr_supporting_certs) {
- supporting_certs = gnutls_malloc(sizeof(*supporting_certs));
- if (!supporting_certs) {
- vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
- ret = -ENOMEM;
- goto out;
- }
- supporting_certs[0] = cert;
- nr_supporting_certs = 1;
-
- free_supporting_certs = gnutls_malloc(1);
- if
Bug#741573: Two menu systems
Ian == Ian Jackson ijack...@chiark.greenend.org.uk writes: So, if you've reviewed this enough to support Bill's claim that there isn't a consensus because there are substantial objections raised in the discussions and not addressed, then please say that. If you have not reviewed things sufficiently to make that conclusion, then I ask you and the rest of the TC to take sufficient steps that such a review happen. Ian It is not the job of the TC to decide whether there was or was Ian not consensus. It is the job of the TC to decide in cases of Ian dispute what the best technical approach is. There are many factors the TC can use to decide what technical policy to set and whether to set technical policy. I'm disappointed when I hear you describe such a narrow interpretation for what you want the TC to do, because as I've explained such a narrow interpretation is vin my opinion very harmful to the project. I'm quite confident the TC has the constitutional authority to do what I'm suggesting. However at this point we're repeating ourselves. I understand you that the TC has the authority to do as you propose and that you believe that's the best course of action. On that point we disagree in the strongest possible terms. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
