Bug#786857: python-dolfin: fails to import
Package: python-dolfin
Version: 1.5.0-2
Severity: grave
Justification: renders package unusable
The dolfin python package fails to import:
$ python
Python 2.7.10rc1 (default, May 11 2015, 04:32:37)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dolfin import *
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/dolfin/__init__.py", line 16, in
from . import cpp
File "/usr/lib/python2.7/dist-packages/dolfin/cpp/__init__.py", line 42, in
exec("from . import %s" % module_name)
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/dolfin/cpp/common.py", line 110, in
__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]])))
ValueError: invalid literal for int() with base 10: 'a'
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python-dolfin depends on:
ii libamd2.3.11:4.2.1-3
ii libatlas3-base [liblapack.so.3]3.10.2-7
ii libblas3 [libblas.so.3]1.2.20110419-10
ii libboost-filesystem1.55.0 1.55.0+dfsg-3
ii libboost-iostreams1.55.0 1.55.0+dfsg-3
ii libboost-program-options1.55.0 1.55.0+dfsg-3
ii libboost-system1.55.0 1.55.0+dfsg-3
ii libboost-thread1.55.0 1.55.0+dfsg-3
ii libc6 2.19-18
ii libcamd2.3.1 1:4.2.1-3
ii libccolamd2.8.01:4.2.1-3
ii libcholmod2.1.21:4.2.1-3
ii libcolamd2.8.0 1:4.2.1-3
ii libdolfin-dev 1.5.0-2
ii libdolfin1.5 1.5.0-2
ii libgcc11:5.1.1-7
ii libgfortran3 5.1.1-7
ii libgomp1 5.1.1-7
ii libhdf5-openmpi-8 1.8.13+docs-15
ii libhwloc5 1.10.1-1
ii liblapack3 [liblapack.so.3]3.5.0-4
ii libopenblas-base [liblapack.so.3] 0.2.14-1
ii libopenmpi1.6 1.6.5-9.2
ii libpetsc3.4.2 3.4.2.dfsg1-8.1+b1
ii libpython2.7 2.7.10~rc1-1
ii libqtcore4 4:4.8.6+git155-g716fbae+dfsg-2
ii libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2
ii libslepc3.4.2 3.4.2.dfsg-2+b1
ii libstdc++6 5.1.1-7
ii libumfpack5.6.21:4.2.1-3
ii libvtk5.8 5.8.0-17.5
ii libvtk5.8-qt4 5.8.0-17.5
ii libxml22.9.2+dfsg1-3
ii python 2.7.9-1
ii python-ffc 1.5.0-3
ii python-instant 1.5.0-1
ii python-netcdf 2.9.4-3
ii python-numpy [python-numpy-abi9] 1:1.8.2-2
ii python-ply 3.4-5
ii python-six 1.9.0-3
ii python-sympy 0.7.5-4
ii python-ufl 1.5.0-1
pn python:any
ii swig 2.0.12-1
ii zlib1g 1:1.2.8.dfsg-2+b1
python-dolfin recommends no packages.
Versions of packages python-dolfin suggests:
ii dolfin-doc 1.5.0-2
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786856: jessie-pu: package systemd/215-17+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I just uploaded systemd 215-17+deb8u1 to stable, with essentially the
same contents/fixes as in 215-18 to unstable [1].
Annotated changelog:
| [ Michael Biebl ]
| * manager: Pass correct errno to strerror(), have_ask_password contains
|negative error values which have to be negated when being passed to
|strerror().
This is a leftover from a pre-jessie release team review, during that
this little error got spotted. It just affects correct error message
reporting. I can search the reference to that where it was
reviewed/ack'ed if you care, but I suppose it's straightforward
enough.
| [ Martin Pitt ]
| * Revert upstream commit 743970d which immediately SIGKILLs units during
|shutdown. This leads to problems like bash not being able to write its
|history, mosh not saving its state, and similar failed cleanup actions.
|(Closes: #784720, LP: #1448259)
Requested by Henrique and Niels, and quite a severe data loss
condition.
| * write_net_rules: Escape '{' and '}' characters as well, to make this work
|with busybox grep. Thanks Faidon Liambotis! (Closes: #765577)
RC bug with minimally invasive fix. (Aside from the jessie-ignore
RC bug #780650 which will be fixed with 220-1, this is the only
current RC bug)
| * debian/gbp.conf: Point to jessie branch.
git-buildpackage bureaucracy, no impact on builds or the binaries.
debdiff is attached. It should be quite obvious which hunk applies to
which change, but please don't hesitate to ask.
Thanks,
Martin
[1] https://tracker.debian.org/news/685999
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
diff -Nru systemd-215/debian/changelog systemd-215/debian/changelog
--- systemd-215/debian/changelog2015-04-16 17:26:58.0 +0200
+++ systemd-215/debian/changelog2015-05-26 07:56:09.0 +0200
@@ -1,3 +1,21 @@
+systemd (215-17+deb8u1) stable; urgency=medium
+
+ [ Michael Biebl ]
+ * manager: Pass correct errno to strerror(), have_ask_password contains
+negative error values which have to be negated when being passed to
+strerror().
+
+ [ Martin Pitt ]
+ * Revert upstream commit 743970d which immediately SIGKILLs units during
+shutdown. This leads to problems like bash not being able to write its
+history, mosh not saving its state, and similar failed cleanup actions.
+(Closes: #784720, LP: #1448259)
+ * write_net_rules: Escape '{' and '}' characters as well, to make this work
+with busybox grep. Thanks Faidon Liambotis! (Closes: #765577)
+ * debian/gbp.conf: Point to jessie branch.
+
+ -- Martin Pitt Tue, 26 May 2015 07:55:44 +0200
+
systemd (215-17) unstable; urgency=high
* cryptsetup: Implement offset and skip options. (Closes: #751707,
diff -Nru systemd-215/debian/extra/write_net_rules
systemd-215/debian/extra/write_net_rules
--- systemd-215/debian/extra/write_net_rules2015-04-16 17:26:58.0
+0200
+++ systemd-215/debian/extra/write_net_rules2015-05-26 07:56:09.0
+0200
@@ -118,7 +118,7 @@
match="$match, KERNEL==\"$basename*\""
# build a regular expression that matches the new rule that we want to write
-new_rule_pattern=$(echo "^SUBSYSTEM==\"net\", ACTION==\"add\"$match" | sed -re
's/([\?\*])/\\\1/g')
+new_rule_pattern=$(echo "^SUBSYSTEM==\"net\", ACTION==\"add\"$match" | sed -re
's/([\?\*\{\}])/\\\1/g')
# Double check if the new rule has already been written. This happens if
# multiple add events are generated before the script returns and udevd
diff -Nru systemd-215/debian/gbp.conf systemd-215/debian/gbp.conf
--- systemd-215/debian/gbp.conf 2015-04-16 17:26:58.0 +0200
+++ systemd-215/debian/gbp.conf 2015-05-26 07:56:09.0 +0200
@@ -1,4 +1,4 @@
[DEFAULT]
pristine-tar = True
patch-numbers = False
-debian-branch = master
+debian-branch = jessie
diff -Nru
systemd-215/debian/patches/manager-pass-correct-errno-to-strerror.patch
systemd-215/debian/patches/manager-pass-correct-errno-to-strerror.patch
--- systemd-215/debian/patches/manager-pass-correct-errno-to-strerror.patch
1970-01-01 01:00:00.0 +0100
+++ systemd-215/debian/patches/manager-pass-correct-errno-to-strerror.patch
2015-05-26 07:56:09.0 +0200
@@ -0,0 +1,27 @@
+From 6d025bafdb9a3317fac014bdf19acf09256a1531 Mon Sep 17 00:00:00 2001
+From: Michael Biebl
+Date: Thu, 16 Apr 2015 13:56:28 +0200
+Subject: [PATCH] manager: pass correct errno to strerror()
+
+have_ask_password contains negative error values which have to be
+negated when being passed to strerror().
+---
+ src/core/manager.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/manager.c b/src/core/manager.c
+index 47e23ba..06ef376 100644
+--- a/src/core/manager.c
b/src/core/manager.c
+@@ -241,7 +241,7 @@ static int
manager_dispatch_ask_passw
Bug#786850: gcc-4.9: AddressSanitizer fails with pthread_cond_init
Erik de Castro Lopo wrote: > Package: gcc-4.9 > Version: 4.9.2-16 > Severity: normal Same problem with gcc-4.9.2-18 from unstable. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785627: Mayavi2 maintenance [python-mne is marked for autoremoval from testing]
Hi, the RC bug #785627 did not received any response and according to its rdepends mayavi2 affects several packages in Debian science which should be hit by the same autoremoval. There are other open bugs against mayavi2 which seem not hard to fix and it is lagging begin upstream. Do we want to starte a Debian Science effort to upgrade this package? (I'm personally not available for such thing for about four weeks - otherwise I would have done something myself.) We should check whether python-apps team has ACLs set to enable commits of non-team members. Otherwise it might be sensible to move the package to Debian Science Git. Kind regards Andreas. - Forwarded message from Debian testing autoremoval watch - Date: Tue, 26 May 2015 04:39:03 + From: Debian testing autoremoval watch To: python-...@packages.debian.org Subject: python-mne is marked for autoremoval from testing python-mne 0.8.6+dfsg-2 is marked for autoremoval from testing on 2015-07-01 It (build-)depends on packages with these RC bugs: 785627: mayavi2: malicious dynamic python interpreter lookup via "/usr/bin/env python" in main executable ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging - End forwarded message - -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786853: clang-3.7: Link error with -fsanitize=address
Erik de Castro Lopo wrote: > Possible packaging error? Very similar error if I try to use -fsanitize=address with armhf with clang-3.5 and clang-3.6. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786855: squid3: doesn't start with adaptation_access option
Package: squid3
Version: 3.4.8-6
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate
***
* What led up to the situation?
> Squid works correctly without c-icap.
> I installed c-icap server and I add to squid.conf the following
lines :
>
> icap_enable on
> icap_service service_avi_req reqmod_precache
icap://localhost:1344/virus_scan bypass=off
> icap_service service_avi_resp respmod_precache
icap://localhost:1344/virus_scan bypass=on
> adaptation_access service_avi_req allow all
> adaptation_access service_avi_resp allow all
* What exactly did you do (or not do) that was effective (or
ineffective)?
> c-icap server is up and running
>
> ● c-icap.service - LSB: c-icap Server
> Loaded: loaded (/etc/init.d/c-icap)
> Active: active (running) since Tue 2015-05-26 08:03:58 CEST;
34min ago
> CGroup: /system.slice/c-icap.service
> ├─591 /usr/bin/c-icap
> ├─593 /usr/bin/c-icap
> ├─594 /usr/bin/c-icap
> └─595 /usr/bin/c-icap
>
> c-icap listen on 1344
>
> netstat -nap | grep -i "c-icap"
> tcp0 0 0.0.0.0:13440.0.0.0:*
LISTEN 591/c-icap
>
> c-icap seems to work fine
>
> c-icap-client -f /bin/ls -s
"srv_clamav?allow204=on&force=on&sizelimit=off&mode=simple"
> ICAP server:localhost, ip:127.0.0.1, port:1344
>
> No modification needed (Allow 204 response)
* What was the outcome of this action?
> "squid3 -k parse" output :
> 2015/05/26 08:21:14| Processing: icap_enable on
> 2015/05/26 08:21:14| Processing: icap_service service_avi_req
reqmod_precache icap://localhost:1344/virus_scan bypass=off
> 2015/05/26 08:21:14| Processing: icap_service service_avi_resp
respmod_precache icap://localhost:1344/virus_scan bypass=on
> 2015/05/26 08:21:14| Processing: adaptation_access service_avi_req
allow all
> 2015/05/26 08:21:14| Processing: adaptation_access service_avi_resp
allow all
> Aborted
>
> "/var/log/squid3/cache.log" output :
> 2015/05/26 08:14:09 kid1| Squid Cache (Version 3.4.8): Exiting
normally.
> 2015/05/26 08:14:09 kid1| assertion failed: mem.cc:282: "size ==
StrPoolsAttrs[i].obj_size"
> 2015/05/26 08:14:09| assertion failed: mem.cc:282: "size ==
StrPoolsAttrs[i].obj_size"
> 2015/05/26 08:21:14| assertion failed: mem.cc:282: "size ==
StrPoolsAttrs[i].obj_size"
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages squid3 depends on:
ii adduser 3.113+nmu3
ii libc62.19-18
ii libcap2 1:2.24-8
ii libcomerr2 1.42.12-1.1
ii libdb5.3 5.3.28-9
ii libecap2 0.2.0-3
ii libexpat12.1.0-6+b3
ii libgcc1 1:4.9.2-10
ii libgssapi-krb5-2 1.12.1+dfsg-19
ii libk5crypto3 1.12.1+dfsg-19
ii libkrb5-31.12.1+dfsg-19
ii libldap-2.4-22.4.40+dfsg-1
ii libltdl7 2.4.2-1.11
ii libnetfilter-conntrack3 1.0.4-1
ii libnettle4 2.7.1-5
ii libpam0g 1.1.8-3.1
ii libsasl2-2 2.1.26.dfsg1-13
ii libstdc++6 4.9.2-10
ii libxml2 2.9.1+dfsg1-5
ii logrotate3.8.7-1+b1
ii lsb-base 4.1+Debian13+nmu1
ii netbase 5.3
ii squid3-common3.4.8-6
squid3 recommends no packages.
Versions of packages squid3 suggests:
pn resolvconf
pn smbclient
pn squid-cgi
ii squid-purge 3.4.8-6
ii squidclient 3.4.8-6
pn ufw
pn winbindd
-- Configuration Files:
/etc/squid3/squid.conf changed:
pid_filename /var/run/squid3.pid
http_port 3128
icp_port 0
snmp_port 3401
ftp_user anonymous@anonymous.anonymous
icon_directory /usr/share/squid3/icons
mime_table /usr/share/squid3/mime.conf
coredump_dir /var/spool/squid3
cache_effective_user proxy
cache_dir ufs /var/spool/squid3 1024 16 256
cache_mem 256 MB
cache_mgr c...@pasubiogroup.it
hierarchy_stoplist cgi-bin ?
refresh_pattern ^ftp: 144020% 10080
refresh_pattern ^gopher:14400% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
logformat customFormat %ts.%03tu %tg | %un %>A %>a | %la %lp %Sh/%h | %rm %ru %rv %mt %03>Hs %{Referer}>h | %st %st | %tr %dt |
"%{User-Agent}>h" "%{Server}http://go.microsoft.com/fwlink
Bug#771677: Segmentation fault during detect
Tags: patch fixed-upstream -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786375: about gRPC packaging
On Mon, May 25, 2015 at 12:56:51PM +0200, László Böszörményi (GCS) wrote: > Hi Andrew, > > On Thu, May 21, 2015 at 1:20 PM, Andrew Pollock wrote: > > I don't mind you joining in. I'm doing the work on Github, as I'm trying to > > help the gRPC guys maintain it themselves to some degree (I work for > > Google). > OK, good plan. I assume you don't work at the same place where gRPC > is being developed. It means the packaging will be refreshed in their > tree from time to time, right? > > > https://github.com/grpc/grpc/pull/1696 is what I've done so far. If you can > > help get protobuf3 into experimental, I can flesh the package out more > > there. > As I see, it was merged. As such, I add my changes over yours. > > > In my next pull request, I can add you as an Uploader. > Thanks. How to go on from now? May I get commit access to your tree > or just send pull requests? Just done the latter. I'm very new at using Github, so for the time being, maybe just send pull requests to me. Longer term, once we've agreed on how we're doing things, I'd recommend just sending pull requests to the upstream grpc repository. signature.asc Description: Digital signature
Bug#786854: Incorrect quote handling breaks "--rsync-path" option in rsync_long_args
tag 786854 + fixed-upstream patch
found 786854 1.3.1-4
found 786854 1.3.1-6
found 786854 1.3.1-7
thanks
Hi again,
It looks like this was fixed upstream by this change:
https://github.com/rsnapshot/sourceforge-issues/issues/23
I confirmed that the latest version of upstream rsnapshot (from the
GitHub repo) does not have the problem.
I've attached a patch that applies the fix to the latest version of the
Debian package, and confirmed it fixed the issue. It is also available
in a git repo for convenience:
https://github.com/ocf/rsnapshot/commit/81e1f15f53017a99aeb5ab4fb7f314797bff1faf
Hope this is helpful -- I'd be more than happy to help with testing of
any changes!
Many thanks, and happy Monday!
Chris
>From 2a4f78351d9dcedad6e1780429452b0eb3472b59 Mon Sep 17 00:00:00 2001
From: Chris Kuehl
Date: Mon, 25 May 2015 22:38:41 -0700
Subject: [PATCH] Fix handling of rsync_long_args
---
debian/changelog | 7 +++
debian/patches/20_split_long_args_remove_quotes.diff | 19 +++
debian/patches/series| 1 +
3 files changed, 27 insertions(+)
create mode 100644 debian/patches/20_split_long_args_remove_quotes.diff
diff --git a/debian/changelog b/debian/changelog
index 60633b3..24b22cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+rsnapshot (1.3.1-7ocf1) UNRELEASED; urgency=medium
+
+ * Add debian/patches/20_split_long_args_remove_quotes.diff to fix handling on
+rsync_long_args.
+
+ -- Chris Kuehl Mon, 25 May 2015 22:18:54 -0700
+
rsnapshot (1.3.1-7) unstable; urgency=medium
* Remove obsolete conffiles anacron scripts (Closes: #767124)
diff --git a/debian/patches/20_split_long_args_remove_quotes.diff b/debian/patches/20_split_long_args_remove_quotes.diff
new file mode 100644
index 000..695b535
--- /dev/null
+++ b/debian/patches/20_split_long_args_remove_quotes.diff
@@ -0,0 +1,19 @@
+From: Matt McCutchen
+Subject: Implement quote removal in split_long_args_with_quotes
+Forwarded: yes, https://github.com/rsnapshot/rsnapshot/pull/23
+Bug-Debian: https://bugs.debian.org/786854
+
+--- a/rsnapshot-program.pl
b/rsnapshot-program.pl
+@@ -3778,8 +3778,9 @@
+ # in quotes and got a close quote
+ } elsif($thischar eq $inquotes) {
+ $inquotes = '';
+-}
+- $stack[-1] .= $thischar;
++} else {
++ $stack[-1] .= $thischar;
++ }
+ }
+ if($inquotes) {
+ print_err("Unbalanced quotes in $argname", 1);
diff --git a/debian/patches/series b/debian/patches/series
index b1b69f1..4a9fb12 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -14,3 +14,4 @@
17_linux_lvm_cmd_lvremove_silenced.diff
18_rsnapreport_rsync_output.diff
19_cmd_postexec_umount.diff
+20_split_long_args_remove_quotes.diff
--
1.9.1
Bug#786840: dpkg-gensymbols seems to ignore #include directives
Control: forcemerge -1 785937 On Tue, 2015-05-26 at 00:58:13 +0200, Matthias Klose wrote: > Package: dpkg-dev > Version: 1.18.0 > Severity: serious > seen when building python3.5 in unstable: > > dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see > diff output below > dpkg-gensymbols: warning: debian/libpython3.5/DEBIAN/symbols doesn't match > completely debian/libpython3.5.symbols > --- debian/libpython3.5.symbols (libpython3.5_3.5.0~b1-1_amd64) > +++ dpkg-gensymbols49ZYTa 2015-05-25 22:52:29.084129787 + > @@ -1,4 +1,1622 @@ > libpython3.5m.so.1.0 libpython3.5 #MINVER# > -#include "libpython.symbols" > + PyAST_Check@Base 3.5.0~b1 > + PyAST_Compile@Base 3.5.0~b1 > + PyAST_CompileEx@Base 3.5.0~b1 > + PyAST_CompileObject@Base 3.5.0~b1 > + PyAST_FromNode@Base 3.5.0~b1 > + PyAST_FromNodeObject@Base 3.5.0~b1 > + PyAST_Validate@Base 3.5.0~b1 > + PyAST_mod2obj@Base 3.5.0~b1 > + PyAST_obj2mod@Base 3.5.0~b1 > [...] > > apparently the include directive is ignored, and all symbols in the included > files are marked as missing. downgrading to 1.17.25 fixes this issue. this > causes build failures for packages calling dpkg-gensymbols with -c2 or higher. This is the same issue as the one previously reported, I think I'll just revert the change and upload later today, as there's many other instances that might make it break besides the ones already fixed now. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786269: [Python-modules-team] Bug#786269: tvdb-api: deprecation of python-support
Ciao Sandro, 2015-05-22 4:50 GMT+02:00 Sandro Tosi : > already fixed in SVN, waiting for python-requests-cache to be > processed out of NEW to upload. python-requests-cache has been processed from NEW. -- Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786223: *** GMX Spamverdacht *** Bug#786223: psignifit3: deprecation of python-support
Hi Valentin, 2015-05-26 0:51 GMT+02:00 Valentin Haenel : > I (we) no longer have the resources to maintain this package. What are > the steps required for removing it from Debian? Feel free to report a bug against ftp.debian.org asking for its removal. If you prefer, I could handle this for you. -- Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760003: transition: qt-gstreamer
Finally. It appears I fixed the symbols files issues with telepathy-qt and libkpeople Do I need to do anything to get the the child packages to try to rebuild? Diane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786854: Incorrect quote handling breaks "--rsync-path" option in rsync_long_args
Subject: rsnapshot: Incorrect quote handling breaks "--rsync-path" option in rsync_long_args Package: rsnapshot Version: 1.3.1-7 Severity: normal Tags: upstream Hi maintainer, rsnapshot on jessie and sid (versions 1.3.1-4, 1.3.1-6, and 1.3.1-7) appear to handle quotes in rsync_long_args incorrectly, preventing passing arguments like: --rsync-path="sudo rsync" ...which makes many backup scenarios much harder. I have attached an rsnapshot.conf which exhibits the problem. For simplicity of testing, it tries to use --rsync-path="env rsync". To test, change the backup point at the bottom to some server you have access to and run `rsnapshot -v -c rsnapshot.conf sync`. Output should be similar to: $ rsnapshot -vc rsnapshot.conf sync echo 4160 > /tmp/rsnapshot.pid /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \ --rsync-path="env rsync" --rsh=/usr/bin/ssh ckuehl@supernova:~/bin \ /tmp/backup/.sync/test/ zsh:1: command not found: env rsync rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1] rsnapshot encountered an error! The program was invoked with these options: /usr/bin/rsnapshot -vc rsnapshot.conf sync ERROR: /usr/bin/rsync returned 12 while processing ckuehl@supernova:~/bin touch /tmp/backup/.sync/ rm -f /tmp/rsnapshot.pid The "zsh:1: command not found: env rsync" suggests over-quoting (the same appears when using bash or dash as the shell). The test case works fine in wheezy (version 1.3.1-3). Many thanks! Chris -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-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 Init: systemd (via /run/systemd/system) Versions of packages rsnapshot depends on: ii liblchown-perl 1.01-2+b1 ii logrotate 3.8.7-2 ii perl5.20.2-6 ii rsync 3.1.1-3 Versions of packages rsnapshot recommends: ii openssh-client [ssh-client] 1:6.7p1-6 rsnapshot suggests no packages. -- no debconf information config_version 1.2 cmd_cp /bin/cp cmd_rm /bin/rm cmd_rsync /usr/bin/rsync cmd_ssh /usr/bin/ssh cmd_logger /usr/bin/logger rsync_long_args --delete --numeric-ids --relative --delete-excluded --rsync-path="env rsync" sync_first 1 lockfile/tmp/rsnapshot.pid # backup root directory snapshot_root /tmp/backup/ # backup intervals (must be in ascending order) retain daily 7 retain weekly 4 retain monthly 6 # backup points/scripts backup ckuehl@supernova:~/bin test/
Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names
Hi! On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote: > On 20 May 2015 at 09:24, Guillem Jover wrote: > > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote: > >> Package: libdpkg-perl > >> Version: 1.17.25ubuntu1 > >> Severity: normal > >> Upstream git now produces shared libraries and dpkg-shlibdeps > >> complains noisily when processing them: > >> > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: > >> 002884d8 R_X86_64_64 > >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0088 > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: > >> 002884f0 R_X86_64_64 > >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0090 > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: > >> 00288858 R_X86_64_64 > >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: > >> 00288940 R_X86_64_64 > >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string > >> > >> I suppose a few regexp tweaks are required. > > > > This would imply changing the regexes to match on column basis or very > > strict amount of spaces, because there are valid cases where a version > > node or the visibility markers might or not be present, which seems a > > bit more flaky, although I doubt the objdump output format has changed > > for a long time, but we'd have to verify that. > > Yeah, the patch I wrote yesterday (at > http://paste.ubuntu.com/11232233/) checks for the number of spaces > indicated by an absent version. A bit fragile but I don't suppose > this is very likely to change. Parsing the ELF would be better but > obviously a bunch of work (Go has a nice ELF library :-), doesn't > support versions though). As mentioned above, we'd need to check if this has changed in the past, and if so how long ago. W/o having checked deeply, I think the patch can be simplified, by just changing the regex to cover the different cases. But I'm still uncertain if it is a good idea, given that it has the potential to break existing stuff. It would be nice if the unit test would cover versions longer than the normal space padding, and the visibility attributes. > > In any case, there's several things that come to mind why on first > > thought this might seem like not an entirely good idea anyway (w/o > > having never actually looked deep into Go in any serious way): > > > > - Is the ABI (for each supported arch) specified as part of the > > language, or is it an implementation detail? > > Oh very much an implementation detail at this point. Ok. > > + If the latter, it means this might allow linking incompatible > > objects, which is one of the reasons C++ does not specify the > > mangling rules. > > - Do the symbol names interop with GCC Go? > > I don't know for sure about the names, but there is no chance of the > native toolchain and gccgo directly interoperating anyway: the native > toolchain does not follow the platform ABI. But if the symbols match then users might end up linking both, which might become run-time errors instead of link-time ones? This would not seem ideal. Or is there something else to guarantee no mixups? > > - How would this handle ABI changes in the future if the symbols are > > not mangled? > > At least in the medium term, there is not going to be anywhere near as > much ABI stability over time with a Go library compared to a C or even > C++ library. A new compiler version implies a new ABI version, for > example. Hmm, so what would be the point of shared libraries then? If a new compiler version implies a new ABI version, then that will require rebuilding the world, with flag-day transitions, and automatic SOVERSION bumps or Conflicts or similar. I'm also not seeing how it could provide a stable ABI w/o some kind of mangling, or at lest some ABI namespaceing or tagging? > > - How would this handle interop with languages that do not support > > spaces? Can you specify to export to a specific language so that > > it gets symbols mangled for that? Or do you need something else > > like manually specifying the symbols in asm, or something like > > FFI? > > Go and other code can not interoperate directly (see above comments > about not following ABI). There is a thing (cgo) that generates code > to support thunking between the two worlds, and you can make it > generate symbols that conform to C's expectations. > Besides that, the symbols that end up containing spaces are not the > sort of things that other languages want to access, it's mostly stuff > like the data for a type. Right, I realized that after sending my reply, when I actually peeked at the spec for what were valid identifiers. :) > > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote: > >> It seems that ELF symbol names can contain any characters,
Bug#786853: clang-3.7: Link error with -fsanitize=address
Package: clang-3.7 Version: 1:3.7~svn230892-1 Severity: normal Dear Maintainer, Compiling a simple "Hello world" style program with -fsanitize=address resukts in: $ clang-3.7 -Wall -fsanitize=address program.c -o program /usr/bin/ld: cannot find /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/ libclang_rt.asan-arm.a: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) It seems that that clang expects /usr/lib/llvm-3.7/lib/clang/3.7.0/linux/ to exist, but it doesn't. Possible packaging error? Cheers, Erik -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 3.10.72+ (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages clang-3.7 depends on: ii binutils 2.25-7 ii libc62.19-18 ii libc6-dev2.19-18 ii libclang-common-3.7-dev 1:3.7~svn230892-1 ii libclang1-3.71:3.7~svn230892-1 ii libedit2 3.1-20150325-1 ii libffi6 3.2.1-2 ii libgcc-4.9-dev 4.9.2-18 ii libgcc1 1:5.1.1-7 ii libllvm3.7 1:3.7~svn230892-1 ii libobjc-4.9-dev 4.9.2-18 ii libstdc++-4.9-dev4.9.2-18 ii libstdc++6 5.1.1-7 ii libtinfo55.9+20140913-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages clang-3.7 recommends: ii llvm-3.7-dev 1:3.7~svn230892-1 ii python2.7.9-1 Versions of packages clang-3.7 suggests: pn clang-3.7-doc pn gnustep pn gnustep-devel -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786852: quiterss: Program segfaults on selecting rss feed or news
Package: quiterss Version: 0.17.7+dfsg-1 Severity: normal Dear Maintainer, QuiteRss segfaults while selecting the news feed from list or trying to view the newsfeed message. Program received signal SIGSEGV, Segmentation fault. 0x1e3bbff8 in WebCore::QualifiedName::deref() () at /build/qtwebkit- d2Y274/qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Atomics.cpp:75 75 /build/qtwebkit-d2Y274/qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Atomics.cpp: no such file or directory. Also Program received signal SIGILL, Illegal instruction. 0x168629d0 in ?? () from /usr/lib/powerpc-linux-gnu/libcrypto.so.1.0.0 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages quiterss depends on: ii libc6 2.19-18 ii libgcc11:5.1.1-5 ii libphonon4 4:4.8.0-5 ii libqt4-network 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql-sqlite 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-xml 4:4.8.6+git155-g716fbae+dfsg-2 ii libqtcore4 4:4.8.6+git155-g716fbae+dfsg-2 ii libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2 ii libqtwebkit4 2.3.4.dfsg-3 ii libsqlite3-0 3.8.10.2-1 ii libstdc++6 5.1.1-5 ii phonon 4:4.8.0-5 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#786851: maildrop: reformime -r8 is supposed to convert Q-P to 8bit
Package: maildrop Version: 2.7.1-3 Severity: important Dear Maintainer, Wanted to use script /usr/local/bin/mimetidy.sh to check email is readable: #!/bin/sh exec 3>&1 [ $(reformime -r8 | tee /dev/fd/3 | wc -L) -le 80 ] Also tried processessing email with reformime -r8
Bug#724934: Libsdl2-mixer-2.0-0 not installable in multiarch env
Hi Zed, On Sun, Sep 29, 2013 at 08:46:44PM +0200, Felix Geyer wrote: > Reassign bug to libmodplug as that's the package that needs to be > converted to multiarch for libsdl2-mixer to be co-installable on > multiple architectures. Is there any chance this could be fixed soon? Or should I just NMU with François Gouget's patch? Regards, Stephen signature.asc Description: Digital signature
Bug#784709: issue with os-prober
On Mon, 2015-05-25 at 22:09 +0200, Jérôme Kieffer wrote: > # uname -a ... > # fdisk -l /dev/sdb ... > # blkid /dev/sdb? ... > /dev/sdb4: PTTYPE="dos" PARTUUID="9a2578f7-04" ... > The extended partition looks different from the other, but the result > of blkid under 3.2 is the same as 3.16. Yep, as explained by upstream, this bug in os-prober is due to a new feature in blkid from newer util-linux versions where it can now get info from partition tables as well as filesystems, so it succeeds getting information from the partition but the returned information does not contain the filesystem type so it returns an empty string. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784709#44 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#784709: when would blkid success but not filesystem type?
On Thu, 21 May 2015 13:07:35 +0200 Karel Zak wrote: > The option '-s' does not affect return code ... we have information > about all (including empty) partitions! Ok, I see. Sounds like the proposed patch is appropriate then. https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;filename=0001-Fix-by-forcing-fs-type-to-not-detected-if-not-named.patch;att=1;bug=784709 > Note that my recommendation is to use lsblk, for example: That has the same issue: $ sudo lsblk --noheading --output FSTYPE /dev/sda2 ; echo $? 0 I think for our purposes we would need --nodeps too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#786448: [ITR] templates://neurodebian/{neurodebian.templates}
Dear Debian maintainer, The Debian internationalisation team and the Debian English localisation team will soon begin the review of the debconf templates used in neurodebian. This review takes place for all packages that use debconf to interact with users and its aims are: - to improve the use of English in all debconf templates; - to make the wording of debconf templates more consistent; - to encourage more translations of templates. Even if your first language is English, this process is likely to help track down typos or errors, and improve consistency between the debconf templates of your package and that of other packages in the distribution. The process involves both debian-l10n-english contributors and Debian translators. The details of the process are given in http://wiki.debian.org/I18n/SmithDebconfReviewProcess. I will act as the coordinator of this activity for neurodebian. The first step of the process is to review the debconf source template file(s) of neurodebian. This review will start on Friday, May 29, 2015, or as soon as you acknowledge this mail with an agreement for us to carry out this process. All parts of the process will be carried out in close collaboration with you, and, unless you explicitly ask for it, no upload nor NMU will happen for neurodebian. If you approve this process, please let us know by replying to this mail. If some work in progress on your side would conflict with such a rewrite (such as adding or removing debconf templates), please say so, and we will defer the review to later in the development cycle. Thank you for your attention. -- signature.asc Description: Digital signature
Bug#786850: gcc-4.9: AddressSanitizer fails with pthread_cond_init
Package: gcc-4.9
Version: 4.9.2-16
Severity: normal
Dear Maintainer,
Trivial C program:
#include
#include
int main (void)
{ pthread_cond_t cond;
pthread_cond_init(&cond, NULL);
return 0;
}
Above works correctly when compiled and run (even under Valgrind) as:
gcc -Wall cond_init.c -o cond_init && valgrind ./cond_init
on both x86_64/linux and armhf/linux.
However, then compiled with -fsanitize=address as:
gcc -Wall -fsanitize=address cond_init.c -o cond_init && ./cond_init
it works correctly on x86_64/linux but gets a SIGSEGV on armhf/linux:
ASAN:SIGSEGV
=
==23193==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x
sp 0xbeffefb0 bp 0x T0)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==23193==ABORTING
Apparently this was a problem in gcc-4.8
https://code.google.com/p/address-sanitizer/issues/detail?id=297
but I'm using the Debian gcc-4.9 package.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: armhf (armv7l)
Kernel: Linux 3.10.72+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gcc-4.9 depends on:
ii binutils2.25-7
ii cpp-4.9 4.9.2-16
ii gcc-4.9-base4.9.2-16
ii libc6 2.19-18
ii libcloog-isl4 0.18.3-1
ii libgcc-4.9-dev 4.9.2-16
ii libgmp102:6.0.0+dfsg-6
ii libisl130.14-2
ii libmpc3 1.0.3-1
ii libmpfr43.1.2-3
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages gcc-4.9 recommends:
ii libc6-dev 2.19-18
Versions of packages gcc-4.9 suggests:
pn gcc-4.9-doc
pn gcc-4.9-locales
pn libasan1-dbg
pn libatomic1-dbg
pn libcilkrts5-dbg
pn libgcc1-dbg
pn libgomp1-dbg
pn libitm1-dbg
pn liblsan0-dbg
pn libquadmath-dbg
pn libtsan0-dbg
pn libubsan0-dbg
-- 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#784709: when would blkid success but not filesystem type?
On Tue, 2015-05-26 at 12:21 +0800, Paul Wise wrote: > On Thu, 21 May 2015 13:07:35 +0200 Karel Zak wrote: > > > The option '-s' does not affect return code ... we have information > > about all (including empty) partitions! > > Ok, I see. Sounds like the proposed patch is appropriate then. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;filename=0001-Fix-by-forcing-fs-type-to-not-detected-if-not-named.patch;att=1;bug=784709 Actually the code in question already contains a code path for when blkid returns success but an empty string. Needs more investigation. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#784241: [BTS#784241] templates://ooniprobe/{templates} : Final update for English review
Dear Debian maintainer,
On Friday, May 08, 2015, I notified you of the beginning of a review process
concerning debconf templates for ooniprobe.
The debian-l10n-english contributors have now reviewed these templates,
and the final proposed changes are attached to this update to the
original bug report.
Please review the suggested changes, and if you have any
objections, let me know in the next 3 days.
However, please try to avoid uploading ooniprobe with these changes
right now.
The second phase of this process will begin on Friday, May 29, 2015, when I will
coordinate updates to translations of debconf templates.
The existing translators will be notified of the changes: they will
receive an updated PO file for their language.
Simultaneously, a general call for new translations will be sent to
the debian-i18n mailing list.
Both these calls for translations will request updates to be sent as
individual bug reports. That will probably trigger a lot of bug
reports against your package, but these should be easier to deal with.
The call for translation updates and new translations will run until
about Friday, June 19, 2015. Please avoid uploading a package with fixed or
changed
debconf templates and/or translation updates in the meantime. Of
course, other changes are safe.
Please note that this is an approximative delay, which depends on my
own availability to process this work and is influenced by the fact
that I simultaneously work on many packages.
Around Saturday, June 20, 2015, I will contact you again and will send a final
patch
summarizing all the updates (changes to debconf templates,
updates to debconf translations and new debconf translations).
Again, thanks for your attention and cooperation.
--
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: ooniprobe/run-cronjob
Type: boolean
Default: false
_Description: Run ooniprobe daily?
ooniprobe can be configured to run a set of basic network tests on a daily
basis. This will test the current network for signs of surveillance and
censorship, and send the results to the main OONI collector through the Tor
network.
.
If you choose this option, a daily cron job will run network tests as the
"Debian-ooni" user.
.
You should be aware that running OONI may break the terms of service of your
ISP
or be legally questionable in your country. The software will attempt to
connect
to web services that may be banned, using web censorship circumvention methods
such as Tor. The OONI project will publish data submitted by probes, possibly
including your IP address or other identifying information. In addition, your
use of OONI will be clear to anybody who has access to your computer, and to
anybody who can monitor your Internet connection (such as your employer, ISP,
or
government).
.
For more information on the risks associated with running ooniprobe, see
/usr/share/doc/ooniprobe/RISKS.
Source: ooniprobe
Maintainer: Jérémy Bobbio
Uploaders: Iain R. Learmonth
Section: net
Priority: extra
Build-Depends: debhelper (>= 9),
dh-python,
po-debconf,
python-all (>= 2.6.6-3~),
python-docutils (>= 0.9.1),
python-geoip (>= 0.2.5),
python-ipaddr (>= 2.1.10),
python-mock,
python-openssl (>= 0.13),
python-scapy (>= 2.2),
python-setuptools,
python-twisted (>= 12.2.0),
python-txsocksx,
python-txtorcon (>= 0.7),
python-yaml (>= 3.10),
python-zope.interface (>= 3.6),
tor
Standards-Version: 3.9.6
X-Python-Version: >= 2.7
Vcs-Git: git://anonscm.debian.org/collab-maint/ooniprobe.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/ooniprobe.git
Homepage: https://ooni.torproject.org/
Package: ooniprobe
Architecture: all
Depends: ${misc:Depends}, ${python:Depends},
adduser,
tor,
geoip-database
Recommends: python-dumbnet, python-pypcap
Suggests: geoip-database-contrib, obfsproxy
Description: probe for the Open Observatory of Network Interference (OONI)
OONI, the Open Observatory of Network Interference, is a global observation
network which aims to collect high quality data using open methodologies
and free software to share observations and data about the various types,
methods, and amounts of network tampering in the world.
.
ooniprobe is a program to probe a network and collect data for the OONI
project. It will test the current network for signs of surveillance and
censorship.
--- ooniprobe.old/debian/templates 2015-05-04 15:01:02.594609802 +0200
+++ ooniprobe/debian/templa
Bug#785092: [DDTP] - Translation- files not updated since Jessie release?
Quoting Felipe Augusto van de Wiel (faw) (f...@funlabs.org): > > Indeed all the new translations don't show up in https://packages.debian.org > > although they do appear as translated in the DDTP database on > > ddtp.debian.net. > > When a stable release happens, there's a change required on some of > the scripts that integrate with ftp-master. I would imagine nobody > had the time to do it yet (or remembered). > > I will try to take a look at it later today and get it fixed. We have daily meaningless "arf arf" messages that are received at debian-l10n-de...@lists.alioth.debian.org mail addresse. Martijn tried to have a look at this (see debian-l10n-devel mailing list archive)and I reported #785092 signature.asc Description: Digital signature
Bug#786369: debian-installer: Updates for cubox-i/wandboard with u-boot 2015.04+
On 2015-05-24, Cyril Brulebois wrote: >> The version of u-boot in experimental requires some changes for >> debian-installer to generate appropriate u-boot images. ... >> The update to debian-installer and u-boot 2015.04+ uploaded to >> unstable should be coordinated to minimize the time that the daily >> builds for armhf fail... >> >> Let me know how you'd like me to proceed! > > Feel free to upload u-boot at any time, and ping this bug when you've > done so, so that I (or someone else) can push that patch to master. Uploaded 2015.04+dfsg1-2 to unstable, with one more change required to fix PandaBoard, updated patch: diff --git a/build/boot/arm/u-boot-image-config b/build/boot/arm/u-boot-image-config index 7e59b38..4d81b9d 100644 --- a/build/boot/arm/u-boot-image-config +++ b/build/boot/arm/u-boot-image-config @@ -5,12 +5,12 @@ # # Images from u-boot-imx MX53LOCO /usr/lib/u-boot/mx53loco/u-boot.imx 2 -MX6_Cubox-i /usr/lib/u-boot/mx6_cubox-i/SPL 2 /usr/lib/u-boot/mx6_cubox-i/u-boot.img 84 -Wandboard_Quad /usr/lib/u-boot/wandboard_quad/u-boot.imx 2 +MX6_Cubox-i /usr/lib/u-boot/mx6cuboxi/SPL 2 /usr/lib/u-boot/mx6cuboxi/u-boot.img 138 +Wandboard /usr/lib/u-boot/wandboard/SPL 2 /usr/lib/u-boot/wandboard/u-boot.img 138 # # Images from u-boot-omap BeagleBoneBlack /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/am335x_boneblack/u-boot.img 768 -PandaBoard /usr/lib/u-boot/omap4_panda/MLO 256 /usr/lib/u-boot/omap4_panda/u-boot.bin 768 +PandaBoard /usr/lib/u-boot/omap4_panda/MLO 256 /usr/lib/u-boot/omap4_panda/u-boot.img 768 # # Images from u-boot-sunxi A10-OLinuXino-Lime /usr/lib/u-boot/A10-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 16 live well, vagrant signature.asc Description: PGP signature
Bug#786369: debian-installer: Updates for cubox-i/wandboard with u-boot 2015.04+
On 2015-05-25, Cyril Brulebois wrote: > Vagrant Cascadian (2015-05-24): >> On 2015-05-24, Cyril Brulebois wrote: >> > Vagrant Cascadian (2015-05-20): >> >> The version of u-boot in experimental requires some changes for >> >> debian-installer to generate appropriate u-boot images. ... >> Both hummingboard and cubox-i use the new mx6cuboxi u-boot target, not >> sure where exactly to document that. They're nearly identical hardware, >> largely differing in physical form-factor; cubox-i is crammed into a >> tiny cube, hummingboard is your more typical dev board (in fact, >> virtually identical footprint to the raspberry pi). > > Sorry, I was a bit lazy yesterday… > > Now that I've looked at board/solidrun/mx6cuboxi/mx6cuboxi.c it seems > one is supposed to distinguish between boards by toying with GPIOs > (mx6cuboxi.c in u-boot), so nothing for d-i to worry about, as long as > the user picks the right bits for the relevant device (e.g. the right > SD-Card concatenateable images)? Exactly. > This means this list (including board → devices mapping) should be kept > uptodate: > > https://www.debian.org/releases/jessie/armhf/ch02s01.html#armhf-armmp-supported-platforms > > Does that make sense, or did I just lose myself in (h)arm-land? None of these changes apply to jessie yet; they're all targeted at stretch so far. That page also only lists the information about the kernel, not u-boot or the SD-card images... might require some restructuring to get more specific about the images available. live well, vagrant signature.asc Description: PGP signature
Bug#786849: a2p: "elelse"?
Package: perl
Version: 5.20.2-6
File: /usr/bin/a2p
$ cat w.awk
{
gsub(/[A-Za-z_:]/, "");
if(sub(/.*,-1,-1$/, "NO SERVICE")){}else{sub(/../, "")};
# if(zz != L){print substr($2,0,5), zz; L = zz;}
}
$ a2p w.awk
#!/usr/bin/perl
eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
if $running_under_some_shell;
# this emulates #! processing on NIH machines.
# (remove #! line above if indigestible)
eval '$'.$1.'$2;' while $ARGV[0] =~ /^([A-Za-z_0-9]+=)(.*)/ && shift;
# process any FOO=bar switches
while (<>) {
s/[A-Za-z_:]//g;
if (s/.*,-1,-1$/NO SERVICE/) {
;
}
elelse {
s/..//;
}
# if(zz != L){print substr($2,0,5), zz; L = zz;}
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786848: If a cell phone that has not been turned on is plugged into USB...
Package: udev Version: 219-10 If a cell phone that has not been turned on is plugged into USB, and then we boot linux, one will get in over and over in journalctl -f: 5月 26 10:07:45 jidanni3 systemd-udevd[179]: error opening USB device 'descriptors' file 5月 26 10:07:50 jidanni3 kernel: usb 2-4.1: new high-speed USB device number 29 using ehci-pci 5月 26 10:07:50 jidanni3 kernel: usb 2-4.1: New USB device found, idVendor=0e8d, idProduct=2000 5月 26 10:07:50 jidanni3 kernel: usb 2-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 5月 26 10:07:50 jidanni3 kernel: usb 2-4.1: Product: MT65xx Preloader 5月 26 10:07:50 jidanni3 kernel: usb 2-4.1: Manufacturer: MediaTek 5月 26 10:07:50 jidanni3 kernel: cdc_acm 2-4.1:1.1: ttyACM0: USB ACM device 5月 26 10:07:53 jidanni3 kernel: usb 2-4.1: USB disconnect, device number 29 5月 26 10:07:53 jidanni3 systemd-udevd[179]: error opening USB device 'descriptors' file 5月 26 10:08:00 jidanni3 kernel: usb 2-4.1: new high-speed USB device number 30 using ehci-pci 5月 26 10:08:00 jidanni3 kernel: usb 2-4.1: New USB device found, idVendor=0e8d, idProduct=2000 5月 26 10:08:00 jidanni3 kernel: usb 2-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 5月 26 10:08:00 jidanni3 kernel: usb 2-4.1: Product: MT65xx Preloader 5月 26 10:08:00 jidanni3 kernel: usb 2-4.1: Manufacturer: MediaTek 5月 26 10:08:00 jidanni3 kernel: cdc_acm 2-4.1:1.1: ttyACM0: USB ACM device 5月 26 10:08:03 jidanni3 kernel: usb 2-4.1: USB disconnect, device number 30 The problem only goes away when we turn on the cellphone: 5月 26 10:10:32 jidanni3 systemd-udevd[179]: error opening USB device 'descriptors' file 5月 26 10:10:40 jidanni3 kernel: usb 2-4.1: new high-speed USB device number 48 using ehci-pci 5月 26 10:10:40 jidanni3 kernel: usb 2-4.1: New USB device found, idVendor=0e8d, idProduct=2000 5月 26 10:10:40 jidanni3 kernel: usb 2-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 5月 26 10:10:40 jidanni3 kernel: usb 2-4.1: Product: MT65xx Preloader 5月 26 10:10:40 jidanni3 kernel: usb 2-4.1: Manufacturer: MediaTek 5月 26 10:10:40 jidanni3 kernel: cdc_acm 2-4.1:1.1: ttyACM0: USB ACM device 5月 26 10:10:43 jidanni3 kernel: usb 2-4.1: USB disconnect, device number 48 5月 26 10:10:43 jidanni3 systemd-udevd[179]: error opening USB device 'descriptors' file 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: new high-speed USB device number 49 using ehci-pci 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: New USB device found, idVendor=0bb4, idProduct=0c03 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: Product: MT65xx Android Phone 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: Manufacturer: MediaTek 5月 26 10:10:55 jidanni3 kernel: usb 2-4.1: SerialNumber: 0123456789ABCDEF 5月 26 10:10:55 jidanni3 kernel: usb-storage 2-4.1:1.0: USB Mass Storage device detected 5月 26 10:10:55 jidanni3 kernel: scsi host5: usb-storage 2-4.1:1.0 5月 26 10:10:56 jidanni3 kernel: scsi 5:0:0:0: Direct-Access Linux File-CD Gadget PQ: 0 ANSI: 2 5月 26 10:10:56 jidanni3 kernel: scsi 5:0:0:1: Direct-Access Linux File-CD Gadget PQ: 0 ANSI: 2 5月 26 10:10:56 jidanni3 kernel: sd 5:0:0:0: Attached scsi generic sg4 type 0 5月 26 10:10:56 jidanni3 kernel: sd 5:0:0:1: Attached scsi generic sg5 type 0 5月 26 10:10:56 jidanni3 kernel: sd 5:0:0:0: [sde] Attached SCSI removable disk 5月 26 10:10:56 jidanni3 kernel: sd 5:0:0:1: [sdf] Attached SCSI removable disk 5月 26 10:10:56 jidanni3 systemd-udevd[179]: error: /dev/sdf: No medium found 5月 26 10:10:56 jidanni3 systemd-udevd[179]: error: /dev/sde: No medium found 5月 26 10:10:56 jidanni3 systemd-udevd[179]: error: /dev/sdf: No medium found 5月 26 10:10:56 jidanni3 systemd-udevd[179]: error: /dev/sde: No medium found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786367: flash-kernel: support BeagleBone Black with u-boot 2015.04+
Vagrant Cascadian (2015-05-25):
> On 2015-05-25, Cyril Brulebois wrote:
> > Thanks, pushed the following commit for it:
> > https://anonscm.debian.org/cgit/d-i/flash-kernel.git/commit/?id=c585656
> >
> > and uploaded afterwards.
>
> Apparently I only tested the submitted patch with the *new* version, but
> not backwards compatibility with the u-boot version in jessie, and it
> fails to boot with that version due to a typo. The following patch fixes
> this:
>
>
> diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
> index 31ee618..ddfee6b 100644
> --- a/bootscript/bootscr.beaglebone
> +++ b/bootscript/bootscr.beaglebone
> @@ -11,8 +11,9 @@ then
> fi
>
> if test "${devtype}" = ""
> - setenv device mmc
> then
> + setenv device mmc
> +else
># use device provided by distro_bootcmd
>setenv device "${devtype}"
> fi
>
> Sorry for the trouble!
>
>
> live well,
> vagrant
Eww, I focused a bit too much on the settings being moved around and not
on actual syntax… Sorry I didn't catch it. Pushed & upload 3.40; thanks
for reporting back so quickly!
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#786367: flash-kernel: support BeagleBone Black with u-boot 2015.04+
On 2015-05-25, Cyril Brulebois wrote:
> Ian Campbell (2015-05-25):
>> On Mon, 2015-05-25 at 03:37 +0200, Cyril Brulebois wrote:
>> > Uploading now looks good to me, but I don't want to stomp on anyone's
>> > toes. Ian, are you fine with my uploading a new version with these
>> > changes?
>>
>> Sure, go ahead.
>
> Thanks, pushed the following commit for it:
> https://anonscm.debian.org/cgit/d-i/flash-kernel.git/commit/?id=c585656
>
> and uploaded afterwards.
Apparently I only tested the submitted patch with the *new* version, but
not backwards compatibility with the u-boot version in jessie, and it
fails to boot with that version due to a typo. The following patch fixes
this:
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index 31ee618..ddfee6b 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -11,8 +11,9 @@ then
fi
if test "${devtype}" = ""
- setenv device mmc
then
+ setenv device mmc
+else
# use device provided by distro_bootcmd
setenv device "${devtype}"
fi
Sorry for the trouble!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#786847: brasero: Brasero does not run
Package: brasero Version: 3.11.4-1.1 Severity: important poul@localhost:~$ brasero *** Error in `brasero': double free or corruption (!prev): 0x027b8f20 *** -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages brasero depends on: ii brasero-common 3.11.4-1.1 ii gnome-icon-theme3.12.0-1 ii gstreamer1.0-plugins-base 1.4.4-2 ii gvfs1.22.2-1 ii libatk1.0-0 2.14.0-1 ii libbrasero-media3-1 3.11.4-1.1 ii libc6 2.19-18 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgstreamer-plugins-base1.0-0 1.4.4-2 ii libgstreamer1.0-0 1.4.4-2 ii libgtk-3-0 3.14.5-1 ii libice6 2:1.0.9-1+b1 ii libnautilus-extension1a 3.14.1-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libsm6 2:1.2.2-1+b1 ii libtotem-plparser18 3.10.3-1 ii libtracker-sparql-1.0-0 1.2.4-2 ii libxml2 2.9.1+dfsg1-5 Versions of packages brasero recommends: ii brasero-cdrkit 3.11.4-1.1 ii yelp3.14.1-1 Versions of packages brasero suggests: pn libdvdcss2 pn tracker ii vcdimager 0.7.24+dfsg-0.2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786846: alt-ergo: [PATCH] please make the build reproducible - set build date
Package: alt-ergo Version: 0.99.1+dfsg1-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! While working on the "reproducible builds" effort [1], we have noticed that alt-ergo could not be built reproducibly. The attached patch removes extra timestamps from the build system, helping us to work in make the build reproducible. Notes: * 0003-allow-set-build-date.patch: is a quilt patch. * debian-rules.patch: is a patch for the debian directory file. [1]: https://wiki.debian.org/ReproducibleBuilds -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Description: Allow set the build date This patch moves the date command used for set the build date to a variable, allowing set the build date externally. Author: Juan Picca Last-Update: 2015-05-25 --- --- a/Makefile.users +++ b/Makefile.users @@ -1,4 +1,5 @@ ARCH = $(shell uname -m) +BUILD_DATE = $(shell LANG=en_US; date) VERSION=0.99.1 @@ -157,7 +158,7 @@ endif src/util/version.ml: config.status @echo "let version = \""$(VERSION)"\"" >> src/util/version.ml - @echo "let date = \""`LANG=en_US; date`"\"" >> src/util/version.ml + @echo "let date = \""$(BUILD_DATE)"\"" >> src/util/version.ml @echo "let bindir = \""$(BINDIR)"\"" >> src/util/version.ml @echo "let libdir = \""$(LIBDIR)"\"" >> src/util/version.ml @echo "let pluginsdir = \""$(PLUGINSDIR)"\"" >> src/util/version.ml diff -ruNp alt-ergo-0.99.1+dfsg1.old/debian/rules alt-ergo-0.99.1+dfsg1/debian/rules --- alt-ergo-0.99.1+dfsg1.old/debian/rules 2015-05-04 14:05:56.0 -0300 +++ alt-ergo-0.99.1+dfsg1/debian/rules 2015-05-25 11:32:50.114651077 -0300 @@ -3,10 +3,13 @@ #export DH_VERBOSE=1 +LAST_CHANGE=$(shell dpkg-parsechangelog -S Date) +BUILD_DATE=$(shell LC_ALL=C date -u "+%B %d, %Y" -d "$(LAST_CHANGE)") + include /usr/share/ocaml/ocamlvars.mk override_dh_auto_build: - $(MAKE) all gui + $(MAKE) all gui BUILD_DATE="$(BUILD_DATE)" override_dh_auto_install: $(MAKE) DESTDIR=debian/tmp install install-gui
Bug#786783: ufraw: CVE-2015-3885: input sanitization flaw leading to buffer overflow
[Cc:ing other related bugs, to get other maintainers' opinions] On Mon, 25 May 2015 16:40:00 +0200, Salvatore Bonaccorso said: > CVE-2015-3885[0]: | Integer overflow in the ljpeg_start function in > dcraw 7.00 and earlier | allows remote attackers to cause a denial of > service (crash) via a | crafted image, which triggers a buffer > overflow, related to the len | variable. The patch from rawstudio and libraw is easy enough to port over, being a one-line change, but I'd like a second opinion. The patch just changes the type of len from int to ushort. However, len is only ever set to len = (data[2] << 8 | data[3]) - 2 and so will always be less than 0x1, so I don't see how len can overflow with >= 32-bit ints. I can see how it could cause problems with a signed 16-bit int, but unless I'm missing something, it shouldn't affect Debian in any way, since all our arch's are >= 32-bits. Is that correct, or is my assessment wrong? -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786843: Acknowledgement (O: rdd)
As a complementary information, the 2.0.7 version builds and works fine. Eriberto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784678: closed by Alberto Garcia (Bug#784678: fixed in grilo-plugins 0.2.14-1)
Am 26.05.2015 um 02:51 schrieb Alberto Garcia: > On Tue, May 26, 2015 at 12:47:48AM +0200, Michael Biebl wrote: > >> So if you don't mind the additional upload, which re-enables vala >> support, I'd proceed with the packages you currently have in >> experimental and upload them to unstable now. > > Ok, doing it now. > Thanks a lot, Berto! -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#785065: vdso32 fails to built on ppc64el
Control: retitle -1 ppc64el kernel build requires multilib compiler Control: severity -1 normal Thanks for restoring support for 32-bit code generation. I recognise it's not something you really want to support, so I'm leaving the kernel bug open but changing the title/severity accordingly. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#784678: closed by Alberto Garcia (Bug#784678: fixed in grilo-plugins 0.2.14-1)
On Tue, May 26, 2015 at 12:47:48AM +0200, Michael Biebl wrote: > So if you don't mind the additional upload, which re-enables vala > support, I'd proceed with the packages you currently have in > experimental and upload them to unstable now. Ok, doing it now. > I'll ping you, as soon as vala 0.28 is ready, then. Thanks! Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786845: mandos: fails to start upon initial install
Package: mandos Version: 1.6.9-1 Severity: important Dear Maintainer, Upon installing mandos after a fresh jessie install, the service fails to start: # systemctl -l status mandos.service ● mandos.service - Server of encrypted passwords to Mandos clients Loaded: loaded (/lib/systemd/system/mandos.service; disabled) Active: failed (Result: start-limit) since Mon 2015-05-25 16:56:02 PDT; 4min 53s ago Docs: man:intro(8mandos) man:mandos(8) Main PID: 2041 (code=exited, status=1/FAILURE) May 25 16:56:02 server systemd[1]: mandos.service: main process exited, code=exited, status=1/FAILURE May 25 16:56:02 server systemd[1]: Unit mandos.service entered failed state. May 25 16:56:02 server systemd[1]: mandos.service start request repeated too quickly, refusing to start. May 25 16:56:02 server systemd[1]: Failed to start Server of encrypted passwords to Mandos clients. May 25 16:56:02 server systemd[1]: Unit mandos.service entered failed state. Here are some further relevant logs: May 25 16:56:01 server mandos[2015]: Traceback (most recent call last): May 25 16:56:01 server mandos[2015]: File "/usr/sbin/mandos", line 2883, in May 25 16:56:01 server mandos[2015]: main() May 25 16:56:01 server mandos[2015]: File "/usr/sbin/mandos", line 2536, in main May 25 16:56:01 server mandos[2015]: bus, do_not_queue=True) May 25 16:56:01 server mandos[2015]: File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 131, in __new__ May 25 16:56:01 server mandos[2015]: retval = bus.request_name(name, name_flags) May 25 16:56:01 server mandos[2015]: File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 303, in request_name May 25 16:56:01 server mandos[2015]: 'su', (name, flags)) May 25 16:56:01 server mandos[2015]: File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking May 25 16:56:01 server mandos[2015]: message, timeout) May 25 16:56:01 server mandos[2015]: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.5" is not allowed to own the service "se.recompile.Mandos" due to security policies in the configuration file May 25 16:56:01 server systemd[1]: mandos.service: main process exited, code=exited, status=1/FAILURE May 25 16:56:01 server systemd[1]: Unit mandos.service entered failed state. I don't fully understand why this fails. Perhaps dbus.service needs to be reloaded for the new mandos policies from /etc/dbus-1/system.d/mandos.conf to take effect? Upon rebooting, the service still does not start, but now for a different reason: it is not enabled. # systemctl status mandos.service ● mandos.service - Server of encrypted passwords to Mandos clients Loaded: loaded (/lib/systemd/system/mandos.service; disabled) Active: inactive (dead) Docs: man:intro(8mandos) man:mandos(8) The service can, however, be started manually: # systemctl start mandos.service # systemctl -l status mandos.service ● mandos.service - Server of encrypted passwords to Mandos clients Loaded: loaded (/lib/systemd/system/mandos.service; disabled) Active: active (running) since Mon 2015-05-25 17:17:06 PDT; 12s ago Docs: man:intro(8mandos) man:mandos(8) Main PID: 878 (mandos) CGroup: /system.slice/mandos.service ├─878 /usr/bin/python2.7 /usr/sbin/mandos --foreground └─883 /usr/bin/python2.7 /usr/sbin/mandos --foreground May 25 17:17:06 server mandos[878]: Mandos [878]: WARNING: Could not load persistent state: No such file or directory May 25 17:17:06 server mandos[878]: Mandos [878]: WARNING: No clients defined The service is still disabled, however, and must be enabled manually if it is to be started automatically on future boots: # systemctl enable mandos.service I see that mandos.service has: [Install] WantedBy=multi-user.target ...so I would have expected the service to be enabled upon install. Perhaps it is only disabled because it failed to start when it was first installed? Regards. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mandos depends on: ii adduser 3.113+nmu3 ii avahi-daemon 0.6.31-5 ii gnupg 1.4.18-7 ii initscripts 2.88dsf-59 ii python2.7.9-1 ii python-avahi [python2.7-avahi]0.6.31-5 ii python-dbus [python2.7-dbus] 1.2.0-2+b3 ii python-gnutls [python2.7-gnutls] 2.0.1-2 ii python-gobject3.14.0-1 ii python-gobject-2 [python2.7-gobject] 2.28.6-12+b1 ii python-urwid [python2.7-urwid]1.2.1-2+b1 ii python2.7
Bug#786436: ncurses FTBFS: configure loops
- Original Message - | From: "Sven Joachim" | To: "Helmut Grohne" | Cc: "Thomas Dickey" , 786...@bugs.debian.org | Sent: Monday, May 25, 2015 8:31:29 AM | Subject: Bug#786436: ncurses FTBFS: configure loops | | Am 25.05.2015 um 13:43 schrieb Helmut Grohne: | | > On Mon, May 25, 2015 at 01:37:17PM +0200, Sven Joachim wrote: | >> Since the pkg-config files are only created at "make | >> install.libs", we | >> currently need to install the library into a temporary location. | >> I've | >> come up with the following patch: | >> | >> --8<---cut here---start->8--- | >> diff --git a/debian/rules b/debian/rules | >> index a52135b..c3b7d6e 100755 | >> --- a/debian/rules | >> +++ b/debian/rules | >> @@ -275,8 +275,9 @@ $(wobjdir-32)/config.status: | >> config.guess-stamp | >> | >> $(objdir-test)/config.status: build-wide config.guess-stamp | >>test -d $(objdir-test) || mkdir $(objdir-test) | >> - cd $(objdir-test) && CFLAGS="$(CFLAGS)" $(srcdir)/test/configure | >> \ | >> - $(CONFARGS-TEST) | >> + cd $(objdir-test) && CFLAGS="$(CFLAGS)" \ | >> + | >> PKG_CONFIG_LIBDIR=$(wobjdir)/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig | >> \ | >> + $(srcdir)/test/configure $(CONFARGS-TEST) | >> | >> build-arch build-indep: build | >> | >> @@ -308,8 +309,7 @@ build-debug: $(objdir-debug)/config.status | >> build-wide: $(wobjdir)/config.status | >>cd $(wobjdir) && $(MAKE) | >># needed for building the examples | >> - mv $(wobjdir)/lib/libncursesw.so | >> $(wobjdir)/lib/libncursesw.so.saved | >> - echo "INPUT(libncursesw.so.5 -ltinfo)" > | >> $(wobjdir)/lib/libncursesw.so | >> + $(MAKE) -C $(wobjdir) DESTDIR=$(wobjdir) install.libs | >>touch $@ | >> | >> build-wide-static: $(wobjdir-static)/config.status | >> --8<---cut here---end--->8--- | > | > If ncurses uses any external pkg-config files, then this patch | > breaks | > cross building, because the pkg-config cross wrapper only sets | > PKG_CONFIG_LIBDIR when it is unset. | > | > Given that libgpm-dev does not ship a .pc file, it seems likely | > that | > this is not the case. | | It surely is not, but the cross build is broken anyway: | | , | | checking for specific curses-directory... | | /tmp/ncurses-5.9+20150516/obj-wide | | checking for specified curses library type... ncursesw | | checking for multibyte character support... yes | | checking pkg-config for ncursesw... yes | | checking if the ncursesw package files work... configure: error: | | cannot run test program while cross compiling | ` | | Sounds like something for Thomas to look at. This (cannot run...) at least is a problem in something I have changed recently. The apparent cause of the infinite loop (seen here by disabling the pkg-config and ncurses*-config checks) is a while-loop in CF_ADD_INCDIR, which has been (it seems) waiting since 2007 for someone to notice a problem... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637871: This bug can be closed since it's no longer valid.
Agreed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786844: xjdic: Multiple buffer overflows
Package: xjdic
Version: 24-9
Severity: normal
Tags: upstream patch
[ Although buffer overflows are often regarded as security bugs, I'm
filing this bug with normal severity, on the advice of the security
team. ]
There are several possible buffer overflows throughout the xjdic code
(at least in the client). The easiest one to trigger is by reading from
/dev/null:
$ xjdic_sa < /dev/null > /dev/null
*** buffer overflow detected ***: /usr/bin/xjdic_sa terminated
[...]
This is due to xjdic usually not checking getchar() for EOF (if not
storing its return value outright in an unsigned char), thus appending
it to its output buffer in an infinite loop.
The one that prompted me to file this bug report occurs when reading a
romaji string of 10 kana or more: simply typing "@aa" will crash
the client. (Only romaji is affected; inputting kana directly works
fine.) This is due to tempout[] being woefully short at 80 bytes; I'm
attaching a patch that pushes that limit far enough for any EDICT entry.
(This isn't an actual fix; the client will still crash, only it will
take an unusually long input string for this to happen.)
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.16.0-4-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 9b78d4ecf5a589a7bcd1d22da6b952df99e2be88 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Bri=C3=A8re?=
Date: Tue, 19 May 2015 19:04:46 -0400
Subject: [PATCH] Allocate enough space for romaji input strings of up to 50
kana
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Various buffer overflows will occur once a romaji input string goes over
a certain length. This patch does not actually fix the problem, but
merely pushes that limit beyond 50 kana, which is the length of the
largest string[1] found in EDICT so far.
[1] プログラムせいぎょしきおよびキーボードせいぎょしきのアドレスしていかのうなきおくいきをもつけいさんき
---
xjdfrontend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xjdfrontend.c b/xjdfrontend.c
index 92ec03d..800afe1 100644
--- a/xjdfrontend.c
+++ b/xjdfrontend.c
@@ -98,7 +98,7 @@ int extlen,extjdxlen;
unsigned char kmodes[2][10] = {"ON","OFF"};
unsigned char kmodes_r[2][10] = {"OFF","ON"};
unsigned long chline,chpos,it;
-unsigned char strfilt[10],tempout[80];
+unsigned char strfilt[10],tempout[256];
unsigned char KSname[50] = {"kanjstroke"};
unsigned char RKname[50] = {"radkfile"};
unsigned char Rname[50] = {"radicals.tm"};
@@ -115,7 +115,7 @@ int jiver = 14; /*The last time the index structure changed was Version1.4*/
unsigned char sver[] = {SVER};
unsigned char fbuff[512],KLine[KFBUFFSIZE],karray[KANJARRAYSIZE][5];
unsigned char LogLine[200];
-unsigned char ksch[50],ktarg[50];
+unsigned char ksch[128],ktarg[128];
/* The following Help table has "~" to force spaces */
unsigned char Help[40][81] = {
"\n~~XJDIC USAGE SUMMARY ",
--
2.1.4
Bug#786843: O: rdd
Package: wnpp Severity: normal I am orphaning this package, considering these reasons: 1. The current versions (3.x) are several grave issues: * Do not build twice. * There is a suicidal Makefile that removes essential files. * There are several mistakes from upstream in source code, doing this package not reliable to forensics activities. 2. There are some similar programs packaged in Debian. 3. The upstream development appears dead. The last release was in 2011 and there are bugs opened. 4. The upstream is unresponsive. Thanks, Eriberto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786530: pcre3: enable jit again on ppc64el
I've also discovered this issue, coincidentally at almost exactly the same time. I can confirm both the problem, and that dropping no_jit_ppc64el.patch fixes the issue. Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#786842: ITP: ruby-molinillo -- generic dependency resolution algorithm implementation
Package: wnpp Severity: wishlist Owner: Christian Hofstaedtler * Package name: ruby-molinillo Version : 0.2.3 Upstream Author : Samuel E. Giddins * URL : https://github.com/CocoaPods/Molinillo * License : Expat Programming Lang: Ruby Description : generic dependency resolution algorithm implementation Implements a generic dependency resolver as commonly found in package managers. (Needed as a dependency for bundler.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786744: jessie-pu: package libvncserver/0.9.9+dfsg-6.1
On 05/25/2015 07:47 PM, Adam D. Barratt wrote:
> Please attach the full source debdiff for a package prepared and
> tested on jessie.
Debdiff is attached.
> The meta-data for that bug claims that the bug still affects unstable.
> Given that it appears to be fixed in the package you uploaded yesterday
I just uploaded afterwards, yes.
> (and indeed had previously uploaded to experimental), I'm unclear as to
> why that is. Looking at the changelog, I'm also confused as to why
> neither of the changelogs for the 0.9.10 uploads even mentions that you
> had applied the patch.
>
Sorry I messed up with the changelog and forgot some changes (including
this patch). I fixed it in the git repo.
http://anonscm.debian.org/cgit/collab-maint/libvncserver.git/commit/?id=b33c231b67ef69cd3e65c8c10f5cf214e8f54fa1
diff -Nru libvncserver-0.9.9+dfsg/debian/changelog libvncserver-0.9.9+dfsg/debian/changelog
--- libvncserver-0.9.9+dfsg/debian/changelog 2015-05-26 01:08:32.0 +0200
+++ libvncserver-0.9.9+dfsg/debian/changelog 2015-05-26 01:20:43.0 +0200
@@ -1,3 +1,9 @@
+libvncserver (0.9.9+dfsg-6.2) stable; urgency=medium
+
+ * added patch for libgcrypt init before use (Closes: #782570)
+
+ -- Peter Spiess-Knafl Tue, 26 May 2015 01:19:44 +0200
+
libvncserver (0.9.9+dfsg-6.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libvncserver-0.9.9+dfsg/debian/patches/0004-init-libgcrypt-before-use.patch libvncserver-0.9.9+dfsg/debian/patches/0004-init-libgcrypt-before-use.patch
--- libvncserver-0.9.9+dfsg/debian/patches/0004-init-libgcrypt-before-use.patch 1970-01-01 01:00:00.0 +0100
+++ libvncserver-0.9.9+dfsg/debian/patches/0004-init-libgcrypt-before-use.patch 2015-05-26 01:17:08.0 +0200
@@ -0,0 +1,29 @@
+From: Peter Spiess-Knafl
+Date: Wed, 4 Feb 2015 13:20:39 +0100
+Subject: init libgcrypt before use
+
+---
+ libvncclient/rfbproto.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
+index f653850..aa74c23 100644
+--- a/libvncclient/rfbproto.c
b/libvncclient/rfbproto.c
+@@ -857,6 +857,16 @@ HandleARDAuth(rfbClient *client)
+ rfbCredential *cred = NULL;
+ rfbBool result = FALSE;
+
++ if (!gcry_control(GCRYCTL_INITIALIZATION_FINISHED_P))
++ {
++/* Application did not initialize gcrypt, so we should */
++if (!gcry_check_version(GCRYPT_VERSION))
++{
++ /* Older version of libgcrypt is installed on system than compiled against */
++ rfbClientLog("libgcrypt version mismatch.\n");
++}
++ }
++
+ while (1)
+ {
+ if (!ReadFromRFBServer(client, (char *)gen, 2))
diff -Nru libvncserver-0.9.9+dfsg/debian/patches/series libvncserver-0.9.9+dfsg/debian/patches/series
--- libvncserver-0.9.9+dfsg/debian/patches/series 2015-05-26 01:08:32.0 +0200
+++ libvncserver-0.9.9+dfsg/debian/patches/series 2015-05-26 01:17:42.0 +0200
@@ -10,3 +10,4 @@
CVE-2015-6053.patch
CVE-2014-6054.patch
CVE-2014-6055.patch
+0004-init-libgcrypt-before-use.patch
Bug#786784: python-urllib3: AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
On 25 May 2015 at 16:11, Daniele Tricoli wrote: > Are you using the packaged version on urllib3? If yes there is something > really strange since I patched it as explained here: Sorry for the bogus bug report (I already closed it as invalid) - it turned out Python was picking up an older install of urllib3 on this system, which still had 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#786841: generate_or_update_gem_to_package_data: undefined method `invert' for false:FalseClass (NoMethodError)
Package: gem2deb Version: 0.16 Severity: normal I've been observing the following error while running `gem2deb molinillo`: - molinillo doesn't seem to exist. Let's try to download it with 'gem fetch molinillo' gem fetch molinillo Downloaded molinillo-0.2.3 -- Creating source tarball from molinillo-0.2.3.gem ... tar xfm /home/ch/Debian/pkg-ruby-extras/molinillo-0.2.3.gem "tar xzfm data.tar.gz" "zcat metadata.gz > metadata.yml" tar czf /home/ch/Debian/pkg-ruby-extras/molinillo-0.2.3.tar.gz molinillo-0.2.3 -- Successfully created ./molinillo-0.2.3.tar.gz -- Creating Debian source package from ./molinillo-0.2.3.tar.gz ... /usr/lib/ruby/vendor_ruby/gem2deb/dh_make_ruby.rb:145:in `generate_or_update_gem_to_package_data': undefined method `invert' for false:FalseClass (NoMethodError) from /usr/lib/ruby/vendor_ruby/gem2deb/dh_make_ruby.rb:64:in `initialize' from /usr/bin/gem2deb:96:in `new' from /usr/bin/gem2deb:96:in `' - A bit of debugging suggests that this happens because my apt-file cache was empty, and then apt-file search returns an empty result, yielding an invalid YAML file (after the sed processing), causing YAML.load on dh_make_ruby.rb:145 to return false. Maybe a check for false or a too-small cache file could be added in generate_or_update_gem_to_package_data. AFAICT, the version in jessie is also affected by this. Best, C. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gem2deb depends on: ii build-essential 11.7 ii debhelper9.20150101 ii devscripts 2.15.3 ii gem2deb-test-runner 0.16 ii perl 5.20.2-3 ii python3-debian 0.1.27 ii ruby 1:2.1.5+1 ii ruby-all-dev 1:2.1.5+1 ii ruby-setup 3.4.1-7 Versions of packages gem2deb recommends: ii apt-file 2.5.4 gem2deb 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#786840: dpkg-gensymbols seems to ignore #include directives
Package: dpkg-dev Version: 1.18.0 Severity: serious seen when building python3.5 in unstable: dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libpython3.5/DEBIAN/symbols doesn't match completely debian/libpython3.5.symbols --- debian/libpython3.5.symbols (libpython3.5_3.5.0~b1-1_amd64) +++ dpkg-gensymbols49ZYTa 2015-05-25 22:52:29.084129787 + @@ -1,4 +1,1622 @@ libpython3.5m.so.1.0 libpython3.5 #MINVER# -#include "libpython.symbols" + PyAST_Check@Base 3.5.0~b1 + PyAST_Compile@Base 3.5.0~b1 + PyAST_CompileEx@Base 3.5.0~b1 + PyAST_CompileObject@Base 3.5.0~b1 + PyAST_FromNode@Base 3.5.0~b1 + PyAST_FromNodeObject@Base 3.5.0~b1 + PyAST_Validate@Base 3.5.0~b1 + PyAST_mod2obj@Base 3.5.0~b1 + PyAST_obj2mod@Base 3.5.0~b1 [...] apparently the include directive is ignored, and all symbols in the included files are marked as missing. downgrading to 1.17.25 fixes this issue. this causes build failures for packages calling dpkg-gensymbols with -c2 or higher. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784678: closed by Alberto Garcia (Bug#784678: fixed in grilo-plugins 0.2.14-1)
Am 25.05.2015 um 20:57 schrieb Alberto Garcia: > On Mon, May 25, 2015 at 04:38:31PM +0200, Michael Biebl wrote: > >> I see. In the changelog of grilo 0.2.12-1 you wrote, that you >> disabled vala support for now. Is that an option for the unstable >> upload? > > I don't know who's using the vala files (probably no one), but if > anyone is then there's a problem. According to dak, these are the reverse dependencies of rygel: gnome-control-center: libgrilo-0.2-dev (>= 0.2.6) gnome-music: libgrilo-0.2-dev (>= 0.2.6) gnome-online-miners: libgrilo-0.2-dev (>= 0.2.6) gnome-photos: libgrilo-0.2-dev (>= 0.2.6) grilo-plugins: libgrilo-0.2-dev (>= 0.2.11) rhythmbox: libgrilo-0.2-dev (>= 0.2.0) totem: libgrilo-0.2-dev (>= 0.2.10) None of those packages uses valac afaics, so (temporarily) disabling vala support in grilo should be fine. >> valac 0.28 will have to go through NEW, so can take a couple of >> days. If possible, I wouldn't entangle the two, and simply make >> a followup upload, re-enabled vala support once 0.28 is ready in >> unstable. >> >> Does that sound ok? > > If a couple of days == 2 days then I can just wait. If it can take > longer I can do it as you suggest. Is this blocking anything else? The libmediaart transition is ongoing and it's always good to finish a library transition early, so it doesn't get entangled with other transitions. I can't promise, that I actually get around to updating valac to 0.28 in two days. So if you don't mind the additional upload, which re-enables vala support, I'd proceed with the packages you currently have in experimental and upload them to unstable now. I'll ping you, as soon as vala 0.28 is ready, then. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#784678: closed by Alberto Garcia (Bug#784678: fixed in grilo-plugins 0.2.14-1)
Am 26.05.2015 um 00:47 schrieb Michael Biebl: > Am 25.05.2015 um 20:57 schrieb Alberto Garcia: >> I don't know who's using the vala files (probably no one), but if >> anyone is then there's a problem. > > According to dak, these are the reverse dependencies of rygel: reverse deps of grilo, of course -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#786839: libguard-perl: test failures with perl 5.22
Source: libguard-perl Version: 1.022-2 Severity: important User: debian-p...@lists.debian.og Usertags: perl-5.22-transition Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=96919 Tags: fixed-upstream This package FTBFS with perl 5.22: Test Summary Report --- t/02_error.t(Wstat: 0 Tests: 8 Failed: 2) Failed tests: 7-8 Files=4, Tests=21, 1 wallclock secs ( 0.07 usr 0.04 sys + 0.17 cusr 0.03 csys = 0.31 CPU) Result: FAIL This is fixed upstream in 1.023. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764204: apt-cache calls fcntl() on 65536 FDs
On Mon, May 25, 2015 at 04:58:38PM +0200, Julian Andres Klode wrote: > 2015-05-25 16:22 GMT+02:00 Sebastian Boehm : > > On 25 May 2015 at 15:32, Julian Andres Klode wrote: > >> I don't really see the performance issue here, though. I don't know > >> why the submitter thinks that there is a performance issue here. The > >> closing takes a few milliseconds. An apt-cache show runs in 0.040s > >> here, and has never taken longer for me. > > > > on my fastest machine, a single apt-cache show takes 0.06s on Jessie. > > However, the same apt-cache show takes less than 0.006s on Wheezy. > > > > For a single run on a fast machine, this isn't too bad, but on a slow > > machine this really hurts a lot. When running docker on my laptop, a > > single apt-cache show takes about 2.7 seconds on jessie, whereas it > > took only 1.4 seconds on wheezy. > > > > Jessie: > > > > root@b49835d0cc64:~# time apt-cache show mg > /dev/null > > real 0m2.708s > > user 0m1.830s > > sys 0m0.850s > > > > Wheezy: > > > > root@df40952198bb:~# time apt-cache show mg > /dev/null > > real 0m1.441s > > user 0m1.260s > > sys 0m0.190s > > Those seem to be uncached or on compressed indices, and thus not > relevant for this bug. Also, Wheezy has more packages and therefore more data than Jessie. That takes more time to parse and work with of course. Some improvements will be made (or were made already) for Stretch in experimental, but I wouldn't be surprised too much if by the time Stretch releases the improvements are eaten up by new stuff… Pro-Tip: Lookup how big /var/cache/apt/pkgcache.bin is in bytes. Add a few megabytes and round it up. Set the value you calculated this way in a config file as value for APT::Cache-Start. Read more about the value itself and how to set it in 'man apt.conf'. (The default is ~20MB which is very close to a minimal setup. Its not a silver bullet, but if we talk about millisecond improvements…) Running some apt command as root (or at least apt-cache gencaches) before doing a lot of operations as 'normal' user can be a huge timesafe btw. 2 seconds sounds like a (at least partially) bad cache as even my 6 years old armel system (a sheevaplug) does it in less than half a second with a good one… > > Even the 0.06s are quite noticeable when using tools such as Chef, > > which produce one apt-cache call per package check. On my fastest > > machine, checking the status for ~70 packages used to take > > approximately 400ms on wheezy, but takes more than four seconds with > > jessie. Obviously the situation is much worse with docker and on > > slower systems. > > > >> So I'd prefer to just close this, as it's not worth the extra effort > >> to read out /proc/self/fd. > > > > How about using the O_CLOEXEC flag when opening files? > > We do, AFAIK. It's hard to believe, but apt code predates the O_CLOEXEC by ~ a decade. It's also not so much what apt code does, but what code does who uses libapt. Interesting is e.g. our FileFd. The fds it opens aren't opened with this flag and I don't think we could just do it as this might break users. A first step would be to let it grow an option to set this flag… (Not that we would use it everywhere, but its usage is increasing steadily compared to more 'manual' ways of opening files as transparent (de)compression is kinda handy to have, even if the code who made that happen is a bit insane^Wcomplex…) > I'm wondering a bit because show only does about 38 fcntl() calls for > me, it does not seem to ForkExec() here at all (and I don't know why > it should do that at all). Asking for the (foreign) architectures dpkg supports is using ForkExec and is probably happening in close to every command. Haven't checked through (apt does this since wheezy through, so this can't be a regression in jessie). [It explains Michael Hale's "solution" through as this autodetection isn't run if the list is set manually. Also, as Ubuntu is activating M-A by default parsing only one arch is faster than parsing two… Parsing none with a good cache would be a lot better of course…] > Anyway, I fixed this in > http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=870a2b6d683e58c0584bbd3614a76cf25a055928 > to use /proc/self/fd where available. This brings us down to 0.72 ms > in my optimal test case. (Frankly I would be happy if we could drop this code entirely, but that is going to be a lot of busy work for questionable benefit so I am not going to cry "here". I would tag it newcomer, but I don't thing the experience working on this would be very nice, so I don't.) Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#786838: libdevel-size-perl: test failures with perl 5.22
Source: libdevel-size-perl Version: 0.79-2 Severity: important User: debian-p...@lists.debian.og Usertags: perl-5.22-transition Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102909 Tags: fixed-upstream This package FTBFS with perl 5.22: Test Summary Report --- t/globs.t (Wstat: 256 Tests: 44 Failed: 1) Failed test: 44 Non-zero exit status: 1 t/pvbm.t(Wstat: 0 Tests: 2 Failed: 0) TODO passed: 2 Files=9, Tests=194, 1 wallclock secs ( 0.11 usr 0.09 sys + 0.66 cusr 0.11 cs ys = 0.97 CPU) Result: FAIL This is fixed upstream in 0.80. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786837: libb-utils-perl: test failures with perl 5.22
Source: libb-utils-perl Version: 0.25-1 Severity: important User: debian-p...@lists.debian.og Usertags: perl-5.22-transition Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=100508 Tags: fixed-upstream This package FTBFS with perl 5.22: # Failed test 'walkoptree_simple lines of t/utils/40walk.t' # at t/utils/40walk.t line 20. # Structures begin differing at: # $got->[3] = '17' # $expected->[3] = '18' # Looks like you failed 1 test of 2. t/utils/40walk.t not ok 1 - walkoptree_simple lines of t/utils/40walk.t This is fixed upstream in 0.26. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786836: packaging not yet ready for mass/stable usage
Source: rustc Version: 1.0.0+dfsg1-1 Severity: serious Even though Rust recently reached the 1.0 milestone, compiler and ecosystem packaging still has to reach a "ready for the masses" status. As some bits are still missing (cargo, external libs) and other still under discussion (dynlibs, lang-extensions), this bug is left open in order to avoid a premature migration to testing. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773131: Quick update
tag 773131 + pending thanks On Mon, May 25, 2015 at 02:59:12PM -0300, Miguel Landaeta wrote: > unblock 773131 by 780230 784173 > thanks I'm tagging this bug as pending since I already completed the packaging tasks to upload 1.7.19-1. I'll wait for the missing dependency in sid to upload it to experimental. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution
I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].
That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...
On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
> On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
>
> > a) getting the name of the cryptdev that the password request
> > corresponds to currently involves parsing the prompt message
> > ("Please enter passphrase for disk %s!") which is obviously not a
> > real solution...
> >
> > This issue is fixable with minor upstream changes, e.g. by extending
> > the PasswordAgent protocol to add "Subsystem=cryptsetup" and
> > "Target=" entries to the "ask." file.
>
> I'd be fine with adding a field "Id=" or so, which then is filled by an
> identifier of some kind be the cryptsetup tool that is useful to
> identify the device to query things on. for example:
> "Id=cryptsetup:/dev/sda5" or so could be one way how this could be
> filled in. We wouldn't enfoce any kind of syntax on this, just suggest
> some common sense so that people choose identifiers that are unlikely to
> clash with other subsystems, and somewhat reasonable to read...
... and I ran into a problem with this, because in practise this field
can look like:
Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/
for a crypttab line like:
cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups
luks,keyscript=/usr/bin/kxc-cryptsetup
because it comes from the "name", which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596
So a password agent _still_ needs to resort to brittle parsing of the
"Id" field in order to find the corresponding crypttab entry.
Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?
That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.
In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.
> > b) the password agent implementation in systemd doesn't seem to
> > handle binary strings (i.e. strings with '\0'), as can be seen by
> > calls to e.g. "strlen()"...
> >
> > Whether making it binary safe would be a major change or not is
> > something I haven't researched yet but it seems like a change that
> > should be generally useful upstream...
>
> I'd be OK with this, as discussed at FOSDEM, and I see you already
> posted a ptach for this.
Has this been merged?
Is it safe for a password agent to write content with \0 back to the
socket?
Thanks!
Alberto
[1]: In case it helps anyone else, I added the "initramfs" option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786758: doomsday: segfault on startup
On Mon, May 25, 2015 at 05:11:10PM -0400, Michael Gilbert wrote: > On Mon, May 25, 2015 at 6:16 AM, Adam Borowski wrote: > > When trying to start doomsday, it pops up a dialog which says: > > .[ Doomsday Engine ] > > App init failed: > > "[NotFoundError] (Record::subrecord) Subrecord 'alert' not found" > > ` > > then crashes with a segmentation fault. > > This seems to be an incompatibility with persist.pack files from older > versions. > > If you backup ~/.doomsday/runtime/persist.pack to somewhere else, does > that work around the problem? Yes, it helped, no crash. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786835: spice-gtk: Please enable smartcard support
Source: spice-gtk Version: 0.25-1 Severity: wishlist Tags: patch Hi, Now that libcacard is built, it would be nice to enable smartcard support in spice-gtk. Cheers, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru spice-gtk-0.26/debian/control spice-gtk-0.26/debian/control --- spice-gtk-0.26/debian/control 2014-11-12 07:39:44.0 +0100 +++ spice-gtk-0.26/debian/control 2015-05-25 23:45:44.0 +0200 @@ -32,6 +32,7 @@ libdbus-glib-1-dev, libopus-dev, libsoup2.4-dev, + libcacard-dev (>= 0.1.2), Standards-Version: 3.9.6 X-Python-Version: >= 2.5 Homepage: http://www.spice-space.org/ diff -Nru spice-gtk-0.26/debian/rules spice-gtk-0.26/debian/rules --- spice-gtk-0.26/debian/rules 2014-11-12 07:36:31.0 +0100 +++ spice-gtk-0.26/debian/rules 2015-05-25 23:45:32.0 +0200 @@ -30,7 +30,7 @@ cp .version .tarball-version build-gtk2/ cd build-gtk2 && autoreconf cd build-gtk2 && ./configure --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \ - --enable-smartcard=no --with-gtk=2.0 --disable-static \ + --enable-smartcard=yes --with-gtk=2.0 --disable-static \ --enable-introspection --enable-vala --disable-celt051 \ --enable-usbredir=yes --enable-polkit=yes --enable-dbus=yes \ --with-usb-acl-helper-dir=/usr/lib/spice-gtk @@ -43,7 +43,7 @@ cp .version .tarball-version build-gtk3/ cd build-gtk3 && autoreconf cd build-gtk3 && ./configure --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \ - --enable-smartcard=no --with-gtk=3.0 --disable-static \ + --enable-smartcard=yes --with-gtk=3.0 --disable-static \ --enable-introspection --enable-vala --disable-celt051 \ --enable-usbredir=yes --enable-polkit=yes --enable-dbus=yes \ --with-usb-acl-helper-dir=/usr/lib/spice-gtk
Bug#786832: software speech not working on installation CD on this machine
Hi, I'm adding debian-accessibility@ to the loop, since I can't really look into this bug report right now. Maybe they'll be able to shed some light (full bug report quoted below). Mraw, KiBi. Al Sten-Clanton (2015-05-25): > package: installation-reports > > booted up from 64-bit netinst CD > found at https://www.debian.org/distrib/ > > date: Monday, 25 May 2015 (morning, Eastern daylight savings > > machine: custom-built, Intel processor, 64-bit, 8GB > > partitions: not relevant here, since no install attempted > > output of dmesg, lspci, lsmod, and amixer: apended as instructed in 5.4.3 > > problem description: > I made several attempts to bring up Speakup's software speech when booting > the CD. It was hard to tell when to type "s" to bring it up, since I did > not get the second beep that occurs when I boot up the Debian live CD and > that I heard on the other machine I tested with. > > I used alt-f2 to get to another console, as mentioned in the installation > guide. I tried raising volume and unmuting the sound card using amixer, but > this id not work. I know that terminal worked because the poweroff command > shut down the machine. > > I tested the same CD on our other computer and did get speech output. > > I note that I have been able to use a Debian Jessie live CD by first > bringing up Orca, though I first find it useful to raise the volume via > Gnome's sound settings. I can then bring up Speakup by going into the > graphical terminal and using the relevant commands. However, I cannot get > Speakup with the live CD when booting it up by using the command described > for software speech in the installation guide. > > This machine now runs Arch Linux, so I was able to run dmesg, lspci, lsmod, > and amixer, as mentioned above. I shall apend the resulting output to this > text. I hope that all of this will be the information you need to help me > with this problem. Thank you! > > > > dmesg > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > [0.00] Linux version 4.0.4-1-ARCH (builduser@tobias) (gcc version > 5.1.0 (GCC) ) #1 SMP PREEMPT Mon May 18 06:43:19 CEST 2015 > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-linux > root=UUID=d880c072-b967-4b19-bcd5-23d7a8e4c27d rw quiet > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable > [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] > reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] > reserved > [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable > [0.00] BIOS-e820: [mem 0x2000-0x201f] > reserved > [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable > [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] > reserved > [0.00] BIOS-e820: [mem 0x40005000-0xd99cdfff] usable > [0.00] BIOS-e820: [mem 0xd99ce000-0xda132fff] > reserved > [0.00] BIOS-e820: [mem 0xda133000-0xda3b2fff] ACPI > NVS > [0.00] BIOS-e820: [mem 0xda3b3000-0xda3b7fff] ACPI > data > [0.00] BIOS-e820: [mem 0xda3b8000-0xda3fafff] ACPI > NVS > [0.00] BIOS-e820: [mem 0xda3fb000-0xdacb8fff] usable > [0.00] BIOS-e820: [mem 0xdacb9000-0xdafdbfff] > reserved > [0.00] BIOS-e820: [mem 0xdafdc000-0xdaff] usable > [0.00] BIOS-e820: [mem 0xdb80-0xdf9f] > reserved > [0.00] BIOS-e820: [mem 0xf800-0xfbff] > reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] > reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] > reserved > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] > reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] > reserved > [0.00] BIOS-e820: [mem 0xff00-0x] > reserved > [0.00] BIOS-e820: [mem 0x0001-0x00021f5f] usable > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.7 present. > [0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by > O.E.M./Z77-DS3H, BIOS F6 05/31/2012 > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable > [0.00] AGP: No AGP bridge found > [0.00] e820: last_pfn = 0x21f600 max_arch_pfn = 0x4 > [0.00] MTRR default type: uncachable > [0.00] MTRR fixed ranges enabled: > [0.00] 0-9 write-back > [0.00] A-B uncachable > [0.00] C-C write-protect > [0.00
Bug#786834: gnome-maps: segfault when looking for a destination
Package: gnome-maps Version: 3.14.1.2-1 Severity: important Dear Maintainer, When I search for a place (ex:Mons), the application looks for the place and when it's about to display the results, it crashes. I see this in the terminal : (gnome-maps:4539): GLib-CRITICAL **: g_ascii_strtod: assertion 'nptr != NULL' failed -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-maps depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii geoclue-2.0 2.1.10-2 ii gir1.2-champlain-0.120.12.9-1 ii gir1.2-clutter-1.0 1.20.0-1 ii gir1.2-cogl-1.0 1.18.2-3 ii gir1.2-gdkpixbuf-2.0 2.31.1-2+b1 ii gir1.2-geocodeglib-1.0 3.14.0-1 ii gir1.2-glib-2.0 1.42.0-2.2 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-gtkchamplain-0.12 0.12.9-1 ii gir1.2-gtkclutter-1.01.6.0-1 ii gjs 1.42.0-1 ii libc62.19-18 ii libgirepository-1.0-11.42.0-2.2 ii libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1 ii libglib2.0-0 2.42.1-1 gnome-maps recommends no packages. gnome-maps 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#786833: spice: Please enable smartcard support
Source: spice Version: 0.12.5-1 Severity: wishlist Tags: patch Hi, Would be nice if you could enable the smartcard support now that libcacard is packaged Cheers, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru spice-0.12.5/debian/control spice-0.12.5/debian/control --- spice-0.12.5/debian/control 2014-05-23 17:56:48.0 +0200 +++ spice-0.12.5/debian/control 2015-05-25 23:29:03.0 +0200 @@ -22,6 +22,7 @@ libxinerama-dev, python-pyparsing, libglib2.0-dev (>= 2.22~), + libcacard-dev (>= 0.1.2), Standards-Version: 3.9.4 Homepage: http://spice-space.org/ Vcs-Git: git://anonscm.debian.org/collab-maint/spice.git diff -Nru spice-0.12.5/debian/rules spice-0.12.5/debian/rules --- spice-0.12.5/debian/rules 2014-05-23 17:56:48.0 +0200 +++ spice-0.12.5/debian/rules 2015-05-25 23:28:48.0 +0200 @@ -5,7 +5,7 @@ override_dh_auto_configure: dh_auto_configure -- --disable-celt051 --disable-silent-rules \ - --disable-smartcard --enable-client + --enable-smartcard --enable-client override_dh_strip: dh_strip -plibspice-server1 --dbg-package=libspice-server1-dbg
Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
Am 25.05.2015 um 22:46 schrieb Hugh Pumphrey: When I upgraded to jessie, this all stopped working. (Simpler USB storage devices, e.g. cheap thumb drives, carried on working as normal.) Poking about the internet, I became suspicious of usb-modeswitch and tried un-installing it --- fortunately, nothing seemed to depend on it. My phone's USB mass storage immediately began to work as it had in wheezy. There has been indeed a change in usb_modeswitch to catch all Huawei *modems* with one udev rule. Now it looks like we need to exclude smartphones from that rule. For this we need some more information. Would you be so kind to run the following command on the command line while the phone is connected in storage mode? lsusb -v -d 12d1: (You get the full USB ID of your phone by running just "lsusb") If this succeeded, reply here with the full output of the command. Thanks! BTW, you don't have to uninstall usb_modeswitch. Just edit /etc/usb_modeswitch.conf and set "DisableSwitching" to "1". Regards, Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786832: software speech not working on installation CD on this machine
package: installation-reports booted up from 64-bit netinst CD found at https://www.debian.org/distrib/ date: Monday, 25 May 2015 (morning, Eastern daylight savings machine: custom-built, Intel processor, 64-bit, 8GB partitions: not relevant here, since no install attempted output of dmesg, lspci, lsmod, and amixer: apended as instructed in 5.4.3 problem description: I made several attempts to bring up Speakup's software speech when booting the CD. It was hard to tell when to type "s" to bring it up, since I did not get the second beep that occurs when I boot up the Debian live CD and that I heard on the other machine I tested with. I used alt-f2 to get to another console, as mentioned in the installation guide. I tried raising volume and unmuting the sound card using amixer, but this id not work. I know that terminal worked because the poweroff command shut down the machine. I tested the same CD on our other computer and did get speech output. I note that I have been able to use a Debian Jessie live CD by first bringing up Orca, though I first find it useful to raise the volume via Gnome's sound settings. I can then bring up Speakup by going into the graphical terminal and using the relevant commands. However, I cannot get Speakup with the live CD when booting it up by using the command described for software speech in the installation guide. This machine now runs Arch Linux, so I was able to run dmesg, lspci, lsmod, and amixer, as mentioned above. I shall apend the resulting output to this text. I hope that all of this will be the information you need to help me with this problem. Thank you! dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.4-1-ARCH (builduser@tobias) (gcc version 5.1.0 (GCC) ) #1 SMP PREEMPT Mon May 18 06:43:19 CEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=d880c072-b967-4b19-bcd5-23d7a8e4c27d rw quiet [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved [0.00] BIOS-e820: [mem 0x40005000-0xd99cdfff] usable [0.00] BIOS-e820: [mem 0xd99ce000-0xda132fff] reserved [0.00] BIOS-e820: [mem 0xda133000-0xda3b2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xda3b3000-0xda3b7fff] ACPI data [0.00] BIOS-e820: [mem 0xda3b8000-0xda3fafff] ACPI NVS [0.00] BIOS-e820: [mem 0xda3fb000-0xdacb8fff] usable [0.00] BIOS-e820: [mem 0xdacb9000-0xdafdbfff] reserved [0.00] BIOS-e820: [mem 0xdafdc000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb80-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021f5f] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77-DS3H, BIOS F6 05/31/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x21f600 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask E write-back [0.00] 1 base 2 mask FE000 write-back [0.00] 2 base 0E000 mask FE000 uncachable [0.00] 3 base 0DC00 mask FFC00 uncachable [0.00] 4 base
Bug#784924: transition: openconnect
On Mon, May 25, 2015 at 10:24:39 +0200, Emilio Pozuelo Monfort wrote: > So the two rdeps can just be binNMU'ed, right? If so, please go ahead and > upload > openconnect to unstable. I am able to rebuild the versions of both rdeps in unstable against a local experimental sbuild chroot, so yes I believe so. Uploaded to unstable, thanks, -- mike signature.asc Description: Digital signature
Bug#786830: wheezy-pu: package debian-security-support
Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu Hi, it has been requested multiple times to also provide debian-security-support for wheezy. All the data relevant for wheezy is already present in the version in unstable, so this boils down to a simple rebuild. I've tested the package on a wheezy system. May I upload? The debdiff against what's in sid is the following: Cheers, Moritz diff -Nru debian-security-support-2015.04.04/debian/changelog debian-security-support-2015.04.04~deb7u1/debian/changelog --- debian-security-support-2015.04.04/debian/changelog 2015-04-06 16:59:22.0 + +++ debian-security-support-2015.04.04~deb7u1/debian/changelog 2015-05-25 21:11:44.0 + @@ -1,3 +1,9 @@ +debian-security-support (2015.04.04~deb7u1) wheezy; urgency=low + + * Rebuild for wheezy + + -- Moritz Muehlenhoff Mon, 25 May 2015 20:59:17 + + debian-security-support (2015.04.04) unstable; urgency=high -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786829: Nautilus: Sorting problem
Package: nautilus Version: 3.14.1-2 Severity: normal In nautilus when you view folder with jpeg and cr2, sorting by type does not working. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nautilus depends on: ii desktop-file-utils 0.22-1 ii gsettings-desktop-schemas 3.14.1-1 ii gvfs 1.22.2-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-18 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libexempi3 2.2.1-2 ii libexif12 0.6.21-2 ii libgail-3-03.14.5-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libglib2.0-data2.42.1-1 ii libgnome-desktop-3-10 3.14.1-1 ii libgtk-3-0 3.14.5-1 ii libnautilus-extension1a3.14.1-2 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libselinux12.3-2 ii libtracker-sparql-1.0-01.2.4-2 ii libx11-6 2:1.6.2-3 ii libxml22.9.1+dfsg1-5 ii nautilus-data 3.14.1-2 ii shared-mime-info 1.3-1 Versions of packages nautilus recommends: ii eject 2.1.5+deb1+cvs20081104-13.1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-sushi3.12.0-2+b1 ii gvfs-backends 1.22.2-1 ii librsvg2-common2.40.5-1 Versions of packages nautilus suggests: ii brasero 3.11.4-1.1 ii eog 3.14.1-1 ii evince [pdf-viewer] 3.14.1-2 ii totem3.14.0-2 ii tracker 1.2.4-2 ii xdg-user-dirs0.15-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786831: null ptr using inkscape 0.91
Package: gtk2-engines-qtcurve
Severity: important
Tags: patch upstream
Inkscape is unusable using qtcurve theme
looks at this report:
https://github.com/QtCurve/qtcurve-gtk2/issues/3
attached patch fixed the problem for me
Regards
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gtk2-engines-qtcurve depends on:
ii libc62.19-18
ii libcairo21.14.2-2
ii libgdk-pixbuf2.0-0 2.31.4-1
ii libglib2.0-0 2.44.1-1
ii libgtk2.0-0 2.24.25-3
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libx11-6 2:1.6.3-1
Versions of packages gtk2-engines-qtcurve recommends:
pn kde-style-qtcurve
gtk2-engines-qtcurve suggests no packages.
--- a/style/qtcurve.c.orig 2015-05-25 19:56:19.015463431 +0200
+++ b/style/qtcurve.c 2015-05-25 19:57:04.623464515 +0200
@@ -389,7 +389,7 @@
drawWindowBgnd(cr, style, NULL, window, widget, x, y, width, height);
else if(!(GTK_APP_JAVA==qtSettings.app && widget && GTK_IS_LABEL(widget)))
{
-if(GTK_STATE_PRELIGHT==state && !opts.crHighlight && 0==strcmp(detail, "checkbutton"))
+if(GTK_STATE_PRELIGHT==state && !opts.crHighlight && (detail && (0==strcmp(detail, "checkbutton"
;
else
parent_class->draw_flat_box(style, window, state, shadow, area, widget, detail, x, y, width, height);
Bug#786758: doomsday: segfault on startup
On Mon, May 25, 2015 at 6:16 AM, Adam Borowski wrote: > When trying to start doomsday, it pops up a dialog which says: > .[ Doomsday Engine ] > App init failed: > "[NotFoundError] (Record::subrecord) Subrecord 'alert' not found" > ` > then crashes with a segmentation fault. This seems to be an incompatibility with persist.pack files from older versions. If you backup ~/.doomsday/runtime/persist.pack to somewhere else, does that work around the problem? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786828: qemu-launcher: should not depend on "qemu" metapackage
Package: qemu-launcher Version: 1.8.0~pre0-1 Severity: normal Most people do not have the need for the whole host of qemu-system-* packages. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786740: apt-listbugs: Get errors while trying to download bugs E: Input/output error @ io_fillbuf - fd:0
On Mon, 25 May 2015 09:26:50 +0530 shirish शिरीष wrote: [...] > At times apt-listbugs doesn't download the bugs and errors out. [...] Hello shirish, thanks for your bug report. I have also experienced some sporadic error when querying the BTS with apt-listbugs in the last few days. Mainly yesterday and today (in the morning only), I would say. But now everything seems to be back to normal. I suspect that the issue was due to some server-side problem, since it seems to have vanished without changing anything in apt-listbugs. Do you still experience this issue? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpwJXgeq06cy.pgp Description: PGP signature
Bug#786827: ghostscript: ps2pdf hangs while gv displays the file OK.
Package: ghostscript Version: 9.06~dfsg-2 Severity: normal Dear Maintainer, ps2pdf hangs for me with this postscript file when simply run as: $ ps2pdf test.ps no output is ever generated, except a file in /tmp that slowly grows in size (probably indefinitely), that I found by 'strace' of 'gs' process. $ gv test.ps shows file just fine. The ps2pdf actually runs: /usr/bin/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr -sOutputFile=test.pdf -P- -dSAFER -dCompatibilityLevel=1.4 -c .setpdfwrite -f test.ps that hangs when run manually as well. Changing -sDEVICE to =X11 instead of =pdfwrite and removing -dNOPAUSE displays the output on the screen just fine. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ghostscript depends on: ii debconf [debconf-2.0] 1.5.56 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.2 ii libc6 2.19-18 ii libgs9 9.06~dfsg-2 ghostscript recommends no packages. Versions of packages ghostscript suggests: ii ghostscript-x 9.06~dfsg-2 -- debconf-show failed test.ps Description: PostScript document
Bug#774074: dh-make-perl: Recursive option does not check version of existing packages
As per: https://rt.cpan.org/Ticket/Display.html?id=104676 I have shipped DPKG-Parse-0.02-TRIAL to the cpan. Please let me know if this contains the desired fix, or if more changes are needed, and I can do a stable 0.03 release. Karen Etheridge et...@cpan.org
Bug#786819: netsurf: FTBFS with libgdk-pixbuf2.0-dev 2.31.4-1: gtk/window.c:55:14: error: unknown type name 'GdkPixdata'
Control: tags -1 + patch
On 2015-05-25 22:12:07, Sebastian Ramacher wrote:
> Source: netsurf
> Version: 3.2+dfsg-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Tags: stretch sid
>
> netsurf FTBFS if built against libgdk-píxbuf2.0-dev 2.31.4-1 which is
> currently
> in unstable:
> | COMPILE: gtk/window.c
> | gtk/window.c:55:14: error: unknown type name 'GdkPixdata'
> | extern const GdkPixdata menu_cursor_pixdata;
> | ^
> | gtk/window.c: In function 'nsgtk_create_menu_cursor':
> | gtk/window.c:1057:2: warning: implicit declaration of function
> 'gdk_pixbuf_from_pixdata' [-Wimplicit-function-declaration]
> | pixbuf = gdk_pixbuf_from_pixdata(&menu_cursor_pixdata, FALSE, NULL);
> | ^
> | gtk/window.c:1057:2: warning: nested extern declaration of
> 'gdk_pixbuf_from_pixdata' [-Wnested-externs]
> | gtk/window.c:1057:9: warning: assignment makes pointer from integer without
> a cast
> | pixbuf = gdk_pixbuf_from_pixdata(&menu_cursor_pixdata, FALSE, NULL);
> | ^
This issue is almost fixed upstream in [1]. In addition to this change, the
generated file also needs another include. A debdiff fixing this bug is
attached.
Cheers
[1]
http://source.netsurf-browser.org/netsurf.git/commit/?id=a29e9589f6bd54e258805bef367528a18d7b0c2b
--
Sebastian Ramacher
diff -Nru netsurf-3.2+dfsg/debian/changelog netsurf-3.2+dfsg/debian/changelog
--- netsurf-3.2+dfsg/debian/changelog 2014-08-29 23:59:03.0 +0200
+++ netsurf-3.2+dfsg/debian/changelog 2015-05-25 22:52:12.0 +0200
@@ -1,3 +1,11 @@
+netsurf (3.2+dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/change-how-gdk-image.patch: Fix build against
+libgdk-pixbuf2.0-dev 2.31.4. (Closes: #786819)
+
+ -- Sebastian Ramacher Mon, 25 May 2015 22:25:10 +0200
+
netsurf (3.2+dfsg-2) unstable; urgency=medium
* Do not build with javascript support on s390x
diff -Nru netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch
netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch
--- netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch 1970-01-01
01:00:00.0 +0100
+++ netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch 2015-05-25
22:54:14.0 +0200
@@ -0,0 +1,49 @@
+Description: Change how GDK image resources are compiled in
+ The compiled in image resources were being created as a structure in a
+ generated c source file. The generation of this file caused constness
+ warning as a guint8 * was initialised from a const char array.
+ .
+ This changes the generation and use of these compiled in resources to
+ use the raw inline form as suggested by the documentation removing the
+ const warning.
+ .
+ In addition to the changes from a29e9589f6bd54e258805bef367528a18d7b0c2b, the
+ include in the generated file is changed to glib.h.
+Origin: upstream,
+
http://source.netsurf-browser.org/netsurf.git/commit/?id=a29e9589f6bd54e258805bef367528a18d7b0c2b
+Bug-Debian: https://bugs.debian.org/786819
+Last-Update: 2015-05-25
+
+--- a/netsurf/gtk/Makefile.target
b/netsurf/gtk/Makefile.target
+@@ -90,8 +90,8 @@
+ S_PIXBUF += $(2)
+
+ $(2): $(1)
+- $(Q)echo "#include " > $(2)
+- $(Q)gdk-pixbuf-csource --extern --struct --name=$(3) $(1) >> $(2) || \
++ $(Q)echo "#include " > $(2)
++ $(Q)gdk-pixbuf-csource --extern --raw --name=$(3) $(1) >> $(2) || \
+ ( rm -f $(2) && false )
+
+ endef
+--- a/netsurf/gtk/window.c
b/netsurf/gtk/window.c
+@@ -52,7 +52,7 @@
+ #define CONNECT(obj, sig, callback, ptr) \
+ g_signal_connect(G_OBJECT(obj), (sig), G_CALLBACK(callback), (ptr))
+
+-extern const GdkPixdata menu_cursor_pixdata;
++extern const guint8 *menu_cursor_pixdata;
+
+ struct gui_window {
+ /** The gtk scaffold object containing menu, buttons, url bar, [tabs],
+@@ -1054,7 +1054,7 @@
+ {
+ GdkCursor *cursor = NULL;
+ GdkPixbuf *pixbuf;
+- pixbuf = gdk_pixbuf_from_pixdata(&menu_cursor_pixdata, FALSE, NULL);
++ pixbuf = gdk_pixbuf_new_from_inline(-1, menu_cursor_pixdata, FALSE,
NULL);
+ cursor = gdk_cursor_new_from_pixbuf(gdk_display_get_default(), pixbuf,
0, 3);
+ g_object_unref (pixbuf);
+
diff -Nru netsurf-3.2+dfsg/debian/patches/series
netsurf-3.2+dfsg/debian/patches/series
--- netsurf-3.2+dfsg/debian/patches/series 2014-08-20 10:59:40.0
+0200
+++ netsurf-3.2+dfsg/debian/patches/series 2015-05-25 22:33:13.0
+0200
@@ -1,2 +1,3 @@
set-netsurf-config.patch
change-install-binary-targets
+change-how-gdk-image.patch
signature.asc
Description: Digital signature
Bug#786826: easychem: [INTL:nl] Dutch po file for the easychem package
Package: easychem Severity: wishlist Tags: l10n patch Dear Maintainer, == Please find attached the Dutch po file for the easychem package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po/nl.po" in your package build tree. === If this suits you, I am in favour of this translation being pushed upstream, so that as much users as possible can benefit from it. -- Cheers, Frans === http://www.frans-spiesschaert.homenet.org http://home.base.be/vt6362833/ nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#786825: usb-modeswitch: Interferes with mass storage mode of HuaWei Y300
Package: usb-modeswitch Severity: normal Dear Maintainer, I usually transfer files to and from my Android phone (HuaWei Y300) by putting it into mass storage mode. In wheezy, this worked seamlessly: the internal storage and the phone's SD card would just appear in KDE's file manager. When I upgraded to jessie, this all stopped working. (Simpler USB storage devices, e.g. cheap thumb drives, carried on working as normal.) Poking about the internet, I became suspicious of usb-modeswitch and tried un-installing it --- fortunately, nothing seemed to depend on it. My phone's USB mass storage immediately began to work as it had in wheezy. In a sense I hesitate to report this because I am perfectly happy now I have un-installed usb-modeswitch --- I am partly doing this in case anyone else in the same situation finds this work-around useful. But maybe there is some poor sap who needs to use USB mass storage on a phone similar to mine, but who also has some other device that needs the magic that usb-modeswitch does. The phone runs Android 4.1.1, btw. I hear rumours that newer versions of Android don't even have mass-storage mode, so this may be a problem that will just go away with the passage of time. Best wishes Hugh Pumphrey -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages usb-modeswitch depends on: ii dpkg 1.17.25 ii libc62.19-18 pn libjim0debian2 ii libusb-0.1-4 2:0.1.12-25 pn usb-modeswitch-data usb-modeswitch recommends no packages. Versions of packages usb-modeswitch suggests: pn comgt pn wvdial -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#496894: add a default Subject to the "Reply" link in the web interface
Please, can someone commit the patch or comment it or fix it? Thanks! -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#458939: allow search engines to index http://bugs.debian.org
So, now in 2015, is it still necessary to block some bots and some URLs or should everything be opened or should this bug be closed or...? Just a "ping" :-). -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760003: transition: qt-gstreamer
On Monday, May 25, 2015 19:02:18 Emilio Pozuelo Monfort wrote: > On 22/05/15 08:45, Diane Trout wrote: > > Hello, > > > > I managed to fix most of the architectures for telepathy-qt. Unfortunately > > armel still has a symbols issue I'll have to try and fix tomorrow > > Not sure if you saw it, but your attempt to fix it didn't work. Unfortunately yes, I'm now on -6. > > > I also realized I made another mistake -- I forgot that there was a SONAME > > change for two of the dependencies, libkpeople and ktp-common-internals, > > so > > not only can I not upload them (because I'm a DM), they'll also sit in NEW > > for a while blocking the rest of kde-telepathy from being built > > correctly. > Those were accepted. Unfortunately libkpeople is failing on many arches with > symbol mismatches. > Drat I misinterpreted the FTBFS I'll work on kpeople too. Diane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620460: no way to see what bugs I'm sub scr ibed to
This is a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362710 . -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764204: apt-cache calls fcntl() on 65536 FDs
2015-05-25 21:25 GMT+02:00 Sebastian Boehm : > Hi, > > On 25 May 2015 at 16:58, Julian Andres Klode wrote: >> Those seem to be uncached or on compressed indices, and thus not >> relevant for this bug. > > fair enough. Still, even with cached and uncompressed indices a single > apt-cache show takes about 1.6 seconds on jessie and about 1.2 seconds > on wheezy. My slowest machine has 0.9 seconds on the first run, and 0.09 on all subsequent ones, once the indices have been read into the kernel's cache. > >>> How about using the O_CLOEXEC flag when opening files? >> >> We do, AFAIK. > > Wouldn't that render the fcntl calls superfluous? Also I can't find > any relevant occurences of O_CLOEXEC in the codebase (apart from one > in pkgDPkgPM::StartPtyMagic). Right, sorry, we do not really use O_CLOEXEC, we use FD_CLOEXEC on descriptors we open, by calling SetCloseExec(). Anyway, apart from the race with that, there might be some open fds we have inherited and code using libapt-pkg might open other fds, so it's a good idea to set FD_CLOEXEC anyway. > >> I'm wondering a bit because show only does about 38 fcntl() calls for >> me, it does not seem to ForkExec() here at all (and I don't know why >> it should do that at all). > > Interesting. You haven't set your Apt::ARCHITECTURES to a single arch > by any chance, have you? No, it's multi-arch. > >> I just tested the closing call, and it took about 4 ms (or 10-12 in >> jessie) for the program to start up, call fcntl() on the 65533 file >> descriptors, and exit. I cannot believe that this is the major >> performance difference you are experiencing between wheezy and jessie. >> >> Anyway, I fixed this in >> http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=870a2b6d683e58c0584bbd3614a76cf25a055928 >> to use /proc/self/fd where available. This brings us down to 0.72 ms >> in my optimal test case. > > While this version is still a bit slower than the one in wheezy, it is > significantly faster than the one currently in jessie: > > Most recent git version: > ~ # time apt-cache show mg > /dev/null > apt-cache policy mg > /dev/null 0.01s user 0.00s system 51% cpu 0.015 total > > apt 1.0.9.8 (jessie): > ~ # time apt-cache show mg > /dev/null > apt-cache show mg > /dev/null 0.01s user 0.04s system 92% cpu 0.061 total > > On the docker instance on my laptop with uncompressed indices I'm down > from 2.2s to 1.4s. All in all a noticeable improvement. It might have been significantly faster in the previous commit because the sysconf() was moved out of the loop (released in 1.0.9.10), but using /proc/self/fd sped it up even further. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786823: mongodb: FTBFS at least on on linux-amd64 and hurd-386
Source: mongodb Version: 2.4.10-5 Severity: important Usertags: linux hurd Hello, When trying to build mongodb on GNU/Hurd with the latest versions of python2.7 (2.7.10~rc1-1) and python-mongodb (3.0.1-1) the build failed with: /usr/bin/python .../mongodb/mongodb-2.4.10/buildscripts/smoke.py --with-cleanbb --smoke-db-prefix .../mongodb/mongodb-2.4.10/debian/tmp-test test Traceback (most recent call last): File ".../mongodb/mongodb-2.4.10/buildscripts/smoke.py", line 52, in from pymongo import Connection ImportError: cannot import name Connection scons: *** [smoke] Error 1 scons: building terminated because of errors. debian/rules:45: recipe for target 'override_dh_auto_test' failed Doing the same test-build on linux-amd64 with python2.7 (2.7.8-7) showed the same error. The problematic package could be python-mongodb (the build was done 76 days ago, but no log exits for the linux-amd64 build). However, I'm reporting the FTBFS for mongodb, that is easily changed. Looking at the linux-i386 build log shows that the python-pymongo package used for the build was 2.7.2-1, and python2.7 (2.7.9-2). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782814: transition: libvncserver
On 2015-05-23 13:15:39, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 08/05/15 11:30, Emilio Pozuelo Monfort wrote: > > On 07/05/15 19:50, Peter Spiess-Knafl wrote: > >> Hi! > >> > >> I finally tested all rdepends. They all build out of the box with the > >> new libvnc package on experimental. > > > > Great. But let's wait a bit until some of the ongoing transitions are > > finished, > > as otherwise they would get entangled. > > It's ok now. Please go ahead and upload to unstable. The binNMU for netsurf failed due to a change in libgdk-pixbuf2.0-dev (#786819) Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#786821: ITP: libodb-qt -- Qt ODB runtime library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: libodb-qt Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for PostgreSQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the Qt profile library. The Qt profile provides support for persisting Qt smart pointers, containers, and value types with the ODB system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786822: libvncserver-dev: arch-dependent files in "Multi-Arch: same" package
Package: libvncserver-dev Version: 0.9.10+dfsg-2 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libvncserver-dev is marked as "Multi-Arch: same", but the following files are architecture-dependent: /usr/include/rfb/rfbconfig.h /usr/include/rfb/rfbint.h An example diff between amd64 and mips is attached. -- Jakub Wilk diff -ur libvncserver-dev_0.9.10+dfsg-2_amd64/usr/include/rfb/rfbconfig.h libvncserver-dev_0.9.10+dfsg-2_mips/usr/include/rfb/rfbconfig.h --- libvncserver-dev_0.9.10+dfsg-2_amd64/usr/include/rfb/rfbconfig.h 2015-05-25 10:03:25.0 +0200 +++ libvncserver-dev_0.9.10+dfsg-2_mips/usr/include/rfb/rfbconfig.h 2015-05-25 13:31:49.0 +0200 @@ -430,7 +430,7 @@ # endif #else # ifndef WORDS_BIGENDIAN -/* # undef WORDS_BIGENDIAN */ +# define WORDS_BIGENDIAN 1 # endif #endif diff -ur libvncserver-dev_0.9.10+dfsg-2_amd64/usr/include/rfb/rfbint.h libvncserver-dev_0.9.10+dfsg-2_mips/usr/include/rfb/rfbint.h --- libvncserver-dev_0.9.10+dfsg-2_amd64/usr/include/rfb/rfbint.h 2015-05-25 10:03:25.0 +0200 +++ libvncserver-dev_0.9.10+dfsg-2_mips/usr/include/rfb/rfbint.h 2015-05-25 13:31:49.0 +0200 @@ -2,7 +2,7 @@ #define _LIBVNCSERVER_RFB_RFBINT_H 1 #ifndef _GENERATED_STDINT_H #define _GENERATED_STDINT_H "libvncserver 0.9.10" -/* generated using gnu compiler gcc (Debian 4.9.2-10) 4.9.2 */ +/* generated using gnu compiler gcc (Debian 4.9.2-18) 4.9.2 */ #define _STDINT_HAVE_STDINT_H 1 #include #endif
Bug#785305: [pkg-cli-apps-team] Bug#785305: keepass2: option to lock workspace on suspend does not work
forwarded 785305 https://sourceforge.net/p/keepass/bugs/1378/ kthxbye On Mon, May 25, 2015 at 12:10:22PM +0200, Peter Spiess-Knafl wrote: > On 05/25/2015 12:02 PM, Chow Loong Jin wrote: > > On Mon, May 25, 2015 at 11:13:02AM +0200, Peter Spiess-Knafl wrote: > >> Hi! > >> > >> Is there any progress on this bug? I really loose Keepass2 a lot and I > >> saw that is marked for removal because of this bug. > >> > >> Can I help you somehow? Has it been forwared to upstream yet? > > > > Odd, isn't this the role of GNOME, rather than Keepass2? I'm on Ubuntu and > > my > > screen is locked when going into sleep mode under normal circumstances. This > > is without using Keepass2. > > > > I think there is a misunderstanding of the word "workspace". An opened > keepass file is also called "workspace". Hmm. I just poked at the keepass2 source code, and it looks like it depends on Windows-based system events (SessionEnding, SessionSwitch, and PowerModeChanged) which aren't implemented in Mono: https://github.com/mono/mono/blob/master/mcs/class/System/Microsoft.Win32/SystemEvents.cs#L127 ...and while looking for the upstream bug tracer, I just found an upstream bug: https://sourceforge.net/p/keepass/bugs/1378/ -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#786820: ITP: libodb-boost -- Boost ODB runtime library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: libodb-boost Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for PostgreSQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the Boost ODB profile library. The Boost profile provides support for persisting Boost smart pointers, containers, and value types with the ODB system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786819: netsurf: FTBFS with libgdk-pixbuf2.0-dev 2.31.4-1: gtk/window.c:55:14: error: unknown type name 'GdkPixdata'
Source: netsurf Version: 3.2+dfsg-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: stretch sid netsurf FTBFS if built against libgdk-píxbuf2.0-dev 2.31.4-1 which is currently in unstable: | COMPILE: gtk/window.c | gtk/window.c:55:14: error: unknown type name 'GdkPixdata' | extern const GdkPixdata menu_cursor_pixdata; | ^ | gtk/window.c: In function 'nsgtk_create_menu_cursor': | gtk/window.c:1057:2: warning: implicit declaration of function 'gdk_pixbuf_from_pixdata' [-Wimplicit-function-declaration] | pixbuf = gdk_pixbuf_from_pixdata(&menu_cursor_pixdata, FALSE, NULL); | ^ | gtk/window.c:1057:2: warning: nested extern declaration of 'gdk_pixbuf_from_pixdata' [-Wnested-externs] | gtk/window.c:1057:9: warning: assignment makes pointer from integer without a cast | pixbuf = gdk_pixbuf_from_pixdata(&menu_cursor_pixdata, FALSE, NULL); | ^ For the full log see https://buildd.debian.org/status/fetch.php?pkg=netsurf&arch=amd64&ver=3.2+dfsg-2+b2&stamp=1432571606 Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#784709: issue with os-prober
On Thu, 21 May 2015 12:14:15 +0800 Paul Wise wrote: > On Wed, 20 May 2015 14:59:04 +0200 Jérôme Kieffer wrote: > > > jerome@patagonia:~$ sudo blkid -o value -s TYPE /dev/sdb4 > > jerome@patagonia:~$ echo $? > > 0 > > That is strange, what about just this? > > sudo blkid /dev/sdb4 ; echo $? Dear Paul, # uname -a Linux patagonia 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux # fdisk -l /dev/sdb Disque /dev/sdb : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0x9a2578f7 Device Boot StartEndSectors Size Id Type /dev/sdb1 63 33575849 33575787 16G 82 Linux swap / Solaris /dev/sdb2 33575850 243304424 209728575 100G 83 Linux /dev/sdb3243304425 453032999 209728575 100G 83 Linux /dev/sdb4453033000 3907024064 3453991065 1,6T 5 Extended /dev/sdb5453033063 557905319 104872257 50G 83 Linux /dev/sdb6557905383 662777639 104872257 50G 83 Linux /dev/sdb766203 767649959 104872257 50G 83 Linux /dev/sdb8767650023 872522279 104872257 50G 83 Linux /dev/sdb9872522343 1082250854 209728512 100G 83 Linux /dev/sdb10 1082250918 3907024064 2824773147 1,3T 83 Linux # blkid /dev/sdb? /dev/sdb1: LABEL="Swap2T" UUID="b3de0b2e-9092-4d08-af8d-09fefe8e9735" TYPE="swap" PARTUUID="9a2578f7-01" /dev/sdb2: LABEL="Win" UUID="78d417f1-a097-4cf3-9218-32a621f78c68" TYPE="ext4" PARTUUID="9a2578f7-02" /dev/sdb3: LABEL="Root" UUID="9b3d9c65-6ba2-425f-bc5a-729cb6098165" TYPE="ext4" PARTUUID="9a2578f7-03" /dev/sdb4: PTTYPE="dos" PARTUUID="9a2578f7-04" /dev/sdb5: LABEL="UsrLocal" UUID="dee401ac-fa36-44a5-9463-2571f8f52a84" TYPE="ext4" PARTUUID="9a2578f7-05" /dev/sdb6: LABEL="Var" UUID="e49c7936-3e39-4644-b025-e943172cd218" TYPE="ext4" PARTUUID="9a2578f7-06" /dev/sdb7: LABEL="Backup" UUID="251f4ed5-6114-4f19-b9c7-060eb82ececb" TYPE="ext4" PARTUUID="9a2578f7-07" /dev/sdb8: LABEL="Opt" UUID="8c0395c2-c9da-4ffc-a1a1-08851774182e" TYPE="ext4" PARTUUID="9a2578f7-08" /dev/sdb9: LABEL="Big" UUID="deab5b7f-fb85-4f0d-95ed-84d37180162d" TYPE="ext4" PARTUUID="9a2578f7-09" The extended partition looks different from the other, but the result of blkid under 3.2 is the same as 3.16. Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757557:
Patch taken from ubuntu attached
diff -Nru redshift-1.10/debian/changelog redshift-1.10/debian/changelog
--- redshift-1.10/debian/changelog 2015-05-24 21:18:57.0 +1000
+++ redshift-1.10/debian/changelog 2015-05-26 05:56:13.0 +1000
@@ -1,3 +1,12 @@
+redshift (1.10-2) UNRELEASED; urgency=medium
+
+ * debian/control: Created transitional package for gtk-redshift →
redshift-gtk
+ * debian/gtk-redshift.* files renamed to redshift-gtk.*.
+ * debian/redshift-gtk.links: Created to make transitional symlink from old
+name to new.
+
+ -- Jackson Doak Tue, 26 May 2015 05:48:34 +1000
+
redshift (1.10-1) unstable; urgency=medium
* [56e5b64] Imported Upstream version 1.10 (Closes: #786638)
diff -Nru redshift-1.10/debian/control redshift-1.10/debian/control
--- redshift-1.10/debian/control2015-05-24 21:14:50.0 +1000
+++ redshift-1.10/debian/control2015-05-26 05:55:00.0 +1000
@@ -22,15 +22,24 @@
.
This package provides the base program.
-Package: gtk-redshift
+Package: redshift-gtk
Architecture: all
Depends: redshift (>= ${source:Version}), ${misc:Depends}, ${python3:Depends},
python-gtk2, python3-xdg, gir1.2-appindicator3-0.1, python3-gi
Recommends: at-spi2-core
+Replaces: gtk-redshift (<< 1.10-1~)
+Breaks: gtk-redshift (<< 1.10-1~)
Description: Adjusts the color temperature of your screen with GTK+ integration
The color temperature is set according to the position of the sun. A
different color temperature is set during night and daytime. During
twilight and early morning, the color temperature transitions smoothly
from night to daytime temperature to allow your eyes to slowly
adapt.
+
+Package: gtk-redshift
+Depends: redshift-gtk, ${misc:Depends}
+Architecture: all
+Description: transitional dummy package
+ This is a transitional dummy package for redshift-gtk. It can safely be
+ removed.
.
This package provides GTK+ integration.
diff -Nru redshift-1.10/debian/gtk-redshift.docs
redshift-1.10/debian/gtk-redshift.docs
--- redshift-1.10/debian/gtk-redshift.docs 2014-08-01 04:59:13.0
+1000
+++ redshift-1.10/debian/gtk-redshift.docs 1970-01-01 10:00:00.0
+1000
@@ -1,2 +0,0 @@
-README
-debian/README.Debian
diff -Nru redshift-1.10/debian/gtk-redshift.install
redshift-1.10/debian/gtk-redshift.install
--- redshift-1.10/debian/gtk-redshift.install 2014-08-01 05:02:15.0
+1000
+++ redshift-1.10/debian/gtk-redshift.install 1970-01-01 10:00:00.0
+1000
@@ -1,4 +0,0 @@
-usr/bin/redshift-gtk
-usr/lib/python*
-usr/share/icons
-usr/share/applications/
diff -Nru redshift-1.10/debian/gtk-redshift.manpages
redshift-1.10/debian/gtk-redshift.manpages
--- redshift-1.10/debian/gtk-redshift.manpages 2014-08-01 05:02:32.0
+1000
+++ redshift-1.10/debian/gtk-redshift.manpages 1970-01-01 10:00:00.0
+1000
@@ -1 +0,0 @@
-debian/redshift-gtk.1
diff -Nru redshift-1.10/debian/gtk-redshift.menu
redshift-1.10/debian/gtk-redshift.menu
--- redshift-1.10/debian/gtk-redshift.menu 2014-08-01 05:02:32.0
+1000
+++ redshift-1.10/debian/gtk-redshift.menu 1970-01-01 10:00:00.0
+1000
@@ -1,5 +0,0 @@
-?package(gtk-redshift): \
- needs="X11" \
- section="Games/Toys" \
- title="Redshift" \
- command="redshift-gtk"
diff -Nru redshift-1.10/debian/redshift-gtk.docs
redshift-1.10/debian/redshift-gtk.docs
--- redshift-1.10/debian/redshift-gtk.docs 1970-01-01 10:00:00.0
+1000
+++ redshift-1.10/debian/redshift-gtk.docs 2014-08-01 04:59:13.0
+1000
@@ -0,0 +1,2 @@
+README
+debian/README.Debian
diff -Nru redshift-1.10/debian/redshift-gtk.install
redshift-1.10/debian/redshift-gtk.install
--- redshift-1.10/debian/redshift-gtk.install 1970-01-01 10:00:00.0
+1000
+++ redshift-1.10/debian/redshift-gtk.install 2014-08-01 05:02:15.0
+1000
@@ -0,0 +1,4 @@
+usr/bin/redshift-gtk
+usr/lib/python*
+usr/share/icons
+usr/share/applications/
diff -Nru redshift-1.10/debian/redshift-gtk.links
redshift-1.10/debian/redshift-gtk.links
--- redshift-1.10/debian/redshift-gtk.links 1970-01-01 10:00:00.0
+1000
+++ redshift-1.10/debian/redshift-gtk.links 2014-11-06 02:39:25.0
+1100
@@ -0,0 +1 @@
+usr/bin/redshift-gtk usr/bin/gtk-redshift
diff -Nru redshift-1.10/debian/redshift-gtk.manpages
redshift-1.10/debian/redshift-gtk.manpages
--- redshift-1.10/debian/redshift-gtk.manpages 1970-01-01 10:00:00.0
+1000
+++ redshift-1.10/debian/redshift-gtk.manpages 2014-08-01 05:02:32.0
+1000
@@ -0,0 +1 @@
+debian/redshift-gtk.1
diff -Nru redshift-1.10/debian/redshift-gtk.menu
redshift-1.10/debian/redshift-gtk.menu
--- redshift-1.10/debian/redshift-gtk.menu 1970-01-01 10:00:00.0
+1000
+++ redshift-1.10/debian/redshift-gtk.menu 2014-08-01 05:02:32.0
+1000
@@ -0,0 +1,5 @@
+?package(gtk-redshift): \
+ needs="X11" \
+ section="Games/Toys" \
+ title="Redshift"
Bug#786818: Use X-Python3-Version instead of XS-Python-Version
package: redshift version: 1.10-1 severity: wishlist X-Python3-Version is the current preferred way to record the required python3 version. Please switch to it. diff -Nru redshift-1.10/debian/control redshift-1.10/debian/control --- redshift-1.10/debian/control 2015-05-24 21:14:50.0 +1000 +++ redshift-1.10/debian/control 2015-05-26 05:48:24.0 +1000 @@ -4,7 +4,7 @@ Maintainer: Ritesh Raj Sarraf Uploaders: Franziska Lichtblau Build-Depends: debhelper (>= 7.0.50~), autotools-dev (>= 20100122.1~), pkg-config (>= 0.25), dpkg-dev (>= 1.16.1~), libxcb-randr0-dev, libxxf86vm-dev, libgconf2-dev, python3, libxext-dev, libgeoclue-dev, libdrm-dev, intltool -XS-Python-Version: >= 3.0 +X-Python3-Version: >= 3.2 Standards-Version: 3.9.3 Vcs-Git: git://anonscm.debian.org/users/rhalina-guest/redshift.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/rhalina-guest/redshift.git
Bug#786817: yash: fieldsplitting data corruption
Package: yash
Version: 2.36-1
Severity: critical
When doing field-splitting, fields starting with backslashes are
corrupted: starting from the 2nd field, they have their initial
backslashes removed. Only the first field is left intact.
Given a default $IFS:
testfn() {
printf '%s\n' "$@"
}
VAR='\o\ne \t\wo \th\r\ee \fo\ur'
testfn $VAR
Got output:
\o\ne
t\wo
th\r\ee
fo\ur
Expected ouput (produced on every POSIX shell except yash):
\o\ne
\t\wo
\th\r\ee
\fo\ur
Clearly, this sort of data corruption is a critical security problem.
Lack of data integrity is just the beginning. Removal of backslashes
might defeat quoting/escaping of critical data and lead to the execution
of arbitrary commands. For instance, what if some script feeds the
result of improper fieldsplitting to "eval"?
Upstream fixed the bug in SVN after my report:
http://osdn.jp/projects/yash/scm/svn/commits/3298
But the author does not treat it with urgency and has neither announced
the bug nor patched/updated/withdrawn the release version, which clearly
should not be used with a bug like this. So Debian should issue a patch
for its packaged version in the meantime.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786816: xserver-xorg-video-radeon: Leaving X (suspend, switch to VT) scrambles the desktop colours
Package: xserver-xorg-video-radeon Version: 1:7.5.0-1 Severity: normal Dear Maintainer, Using X on a Thinkpad T60, just upgraded to Debian 8. Previous versions worked fine for suspend/resume/switch to VT and back Now switching out of the desktop does something I can only describe as "change RGB for GBR or similar". Black/white remains perfectly legible, but colours are shifted into a different colour in such a way that the screen is mostly not legible -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Aug 2 2010 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2564976 Feb 11 01:23 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mes
Bug#786815: please add alternate dependency on cron-daemon
Package: logcheck
Severity: minor
Tags: patch
Currently logcheck only depends on cron but systemd-cron only Provides:
cron-daemon but not cron.
So these 2 can't be used together.
diff --git a/debian/control b/debian/control
index 808dec5..33a76bb 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Homepage: http://www.logcheck.org/
Package: logcheck
Architecture: all
-Depends: adduser, default-mta | mail-transport-agent, cron, rsyslog |
system-log-daemon, mime-construct, logtail (>= 1.2.59), lockfile-progs,
${misc:Depends}
+Depends: adduser, default-mta | mail-transport-agent, cron | cron-daemon,
rsyslog | system-log-daemon, mime-construct, logtail (>= 1.2.59),
lockfile-progs, ${misc:Depends}
Recommends: logcheck-database (>= ${source:Version})
Suggests: syslog-summary
Description: mails anomalies in the system logfiles to the administrator
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786814: RFS: arrayfire/3.0~beta-1 [ITP] -- High performance library for parallel computing
Package: sponsorship-requests Severity: wishlist Dear Mentors, I am looking for a sponsor for the following source package: * Package name: arrayfire Version : 3.0~beta Upstream Author : ArrayFire Development Group * URL : http://arrayfire.com/ * License : BSD-3-Clause Programming Lang: C++ Description : High performance library for parallel computing It builds the following binary packages: libarrayfire-cpu3 -- Shared library (CPU backend) libarrayfire-cpu3-dbg -- Debug symbols for CPU backend shlib libarrayfire-cpu-dev -- Development files for CPU backend shlib libarrayfire-doc -- Doxygen documentation Comments: * The OpenCL backend requires dependencies which are not yet available in Debian, namely the clBLAS and clFFT libraries. Packaging work is in progress for both and I intend to update the package with this backend later, once these dependencies are uploaded. * The test suite is voluntarily disabled for now, because upstream strictly requires the download of both gtest and additional assets via submodules. I intend to discuss this issue with upstream and aim at having some sort of offline test suite available in a future update. This source package is maintained by the Debian Science Team and can be checked out at: https://anonscm.debian.org/cgit/debian-science/packages/arrayfire.git The binary packages can be built with the following command: gbp buildpackage --git-upstream-tag=upstream/3.0_beta \ --git-upstream-branch=master \ --git-debian-branch=debian/experimental \ --git-no-pristine-tar I intend to seek sponsorship through the Sponsoring of Blends initiative. Best regards, Ghislain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786756: Acknowledgement (geoclue-2.0: provide development headers)
Hello, geoclue2 should be especially configured to allow applications to request the location. Add something like that in : [redshift] allowed=true system=false users= https://wiki.archlinux.org/index.php/Redshift#Failed_to_run_Redshift_due_to_geoclue2 I'm not 100% sure if there is an other way to do so without modifying the config. I would also suggest you to disable the old geoclue support, I really would like to remove the package from the archive. Cheers, Laurent Bigonville Le Mon, 25 May 2015 16:22:19 +0530, Ritesh Raj Sarraf a écrit : > Control: retitle -1 "GeoClue 2 not accessible by normal user over the > bus" > > > Okay. There's no need for any headers. Hence retitled accordingly. > > But can you guys please shed some light on who is currently consuming > geoclue2 ? > > > From what I investigated so far, it registers on the system bus, but > no one is allowed to invoke its methods. > > As my normal user creds, I tried to invoke the dbus methods and it > timed out. But as per the dbus policy for geoclue, it states that > such method invocation should be allowed. > > > Second, redshift for example, is using the o.f.GeoClue2.Location path, > where as Debian's geoclue2 is providing o.f.GeoClue2.Client.Location > path. Is it expected ? > > > > > On Monday 25 May 2015 03:42 PM, Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > > > This is an automatically generated reply to let you know your > > message has been received. > > > > Your message is being forwarded to the package maintainers and other > > interested parties for their attention; they will reply in due > > course. > > > > Your message has been sent to the package maintainer(s): > > Laurent Bigonville > > > > If you wish to submit further information on this problem, please > > send it to 786...@bugs.debian.org. > > > > Please do not send mail to ow...@bugs.debian.org unless you wish > > to report a problem with the Bug-tracking system. > > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764204: apt-cache calls fcntl() on 65536 FDs
Hi, On 25 May 2015 at 16:58, Julian Andres Klode wrote: > Those seem to be uncached or on compressed indices, and thus not > relevant for this bug. fair enough. Still, even with cached and uncompressed indices a single apt-cache show takes about 1.6 seconds on jessie and about 1.2 seconds on wheezy. >> How about using the O_CLOEXEC flag when opening files? > > We do, AFAIK. Wouldn't that render the fcntl calls superfluous? Also I can't find any relevant occurences of O_CLOEXEC in the codebase (apart from one in pkgDPkgPM::StartPtyMagic). > I'm wondering a bit because show only does about 38 fcntl() calls for > me, it does not seem to ForkExec() here at all (and I don't know why > it should do that at all). Interesting. You haven't set your Apt::ARCHITECTURES to a single arch by any chance, have you? > I just tested the closing call, and it took about 4 ms (or 10-12 in > jessie) for the program to start up, call fcntl() on the 65533 file > descriptors, and exit. I cannot believe that this is the major > performance difference you are experiencing between wheezy and jessie. > > Anyway, I fixed this in > http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=870a2b6d683e58c0584bbd3614a76cf25a055928 > to use /proc/self/fd where available. This brings us down to 0.72 ms > in my optimal test case. While this version is still a bit slower than the one in wheezy, it is significantly faster than the one currently in jessie: Most recent git version: ~ # time apt-cache show mg > /dev/null apt-cache policy mg > /dev/null 0.01s user 0.00s system 51% cpu 0.015 total apt 1.0.9.8 (jessie): ~ # time apt-cache show mg > /dev/null apt-cache show mg > /dev/null 0.01s user 0.04s system 92% cpu 0.061 total On the docker instance on my laptop with uncompressed indices I'm down from 2.2s to 1.4s. All in all a noticeable improvement. Thank you for the quick response; next time I'll make sure to start testing in time for the stable release. Best, Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786813: still wants to use /var/run
Package: bind9 Version: 1:9.9.5.dfsg-9 Severity: normal the source is configured with --localstatedir=/var, which causes bind to try writing to /var/run. The following configuration directives are needed in named.conf.options to make error messages vanish from the log on startup: session-keyfile "/run/named/session.key"; pid-file "/run/named/named.pid"; Without those, bind tries writing the session-keyfile to /var/run/named/session.key and tries to create /run/named for a pidfile which is then not written since in the systemd world, bind gets started with -f which does not create a pidfile. This is not a problem in a non-chrooted environment since /var/run/named exists in such environments. In a chroot, /var/run does not necessarily exist. If the configure script has a --rundir option, it should be explicitly set to /run. If it does not, the options given above should be part of the configuration. Greetings Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
