Bug#875997: RFS: jclicmoodle/3.0.1 (package already in Debian from 2009)
Package: sponsorship-requests Severity: normal Hi, jclicmoodle is an add-on for moodle: allows you to run jclic [0] on moodle. Now, moodle is locked in sid due to lack of stable maintenance [1]. Even so, moodle has been updated 3 times this year. Meanwhile, I think it is necessary to continue updating jclicmoodle pending the unlocking of moodle. Regards! I. De Marchi [0] https://packages.qa.debian.org/j/jclic.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747084
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Quoting Cyril Brulebois (k...@debian.org): > It seems there were no functional changes between both versions, only > translation updates plus an extra CHANGES file (which looks like the > last changelog entry). BTW, Christian, a git push seems to be missing. I confirm: this last upload was just a rebuild to include a few updated translations, at least theoretically. I just made the git push which I apparently forgot to do (still happens from time to time, grrr). signature.asc Description: PGP signature
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Hi, GSR (2017-09-17): > Package: console-setup > Version: 1.167 > Severity: normal > > Updated from 166 to 167 and when verifying changes in /etc/ noticed > there was only one change, in console-setup/cached_setup_keyboard.sh: > > ---8<--- > -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' > +loadkeys '/tmp/tmpkbd.31u83e' > '/dev/null' > --->8--- > > File in /tmp/, named tmpkbd and with (random) extension that looks > like one from mktemp? And before it was a file in /etc/ with > understable name? Suspicious. > > Running the script by hand returns the obvious "cannot open file > /tmp/tmpkbd.31u83e" while calling the other version of loadkeys > invocation works fine. > > Prediction is that in next boot it will complain too and require > manually calling with the proper kmap file. > > Also while tracking the calls for boot sequence, found that usage line > for /etc/init.d/keyboard-setup.sh and console-setup.sh forgot the .sh > extension (two mount*.sh forgot the extension too, but that would be > for another report). Most scripts properly report their name with .sh > and one even just uses $0 so it reacts automatically to however it was > called. Minor cosmetic details. It seems there were no functional changes between both versions, only translation updates plus an extra CHANGES file (which looks like the last changelog entry). BTW, Christian, a git push seems to be missing. If you want to check the behaviour, see $savekbdfile and $TMPFILE in the setupcon script. KiBi. signature.asc Description: PGP signature
Bug#745305: python-landslide: Typo in package description: "generates an"
On Sat, 16 Sep 2017 19:20:16 +0200 Andrew Shadura wrote: > The package description is correct. The choice of a/an in English is > according to the pronunciation, not spelling. HTML5 is pronounced "aitch > tee em el five" (note this is a standard pronunciation, in some dialects > H is pronounced haitch), so the choice of "an" is not incorrect. I would like to point out that no matter what the choice of a/an is, the words before it should be "can generate" not "can generates". -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#875996: ftp.debian.org: add more tags to lintian autoreject list
Package: ftp.debian.org Severity: wishlist I suggest adding these tags to the lintian autoreject lists: fatal: https://lintian.debian.org/tags/bad-version-in-relation.html https://lintian.debian.org/tags/bad-provided-package-name.html https://lintian.debian.org/tags/bad-distribution-in-changes-file.html https://lintian.debian.org/tags/bad-section-in-changes-file.html https://lintian.debian.org/tags/bad-urgency-in-changes-file.html nonfatal: https://lintian.debian.org/tags/bad-permissions-for-ali-file.html https://lintian.debian.org/tags/bad-permissions-for-etc-cron.d-script.html https://lintian.debian.org/tags/bad-permissions-for-etc-emacs-script.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#807787: wiki.debian.org: warnings from the rotate-logs script
On Thu, 2017-09-14 at 22:06 -0400, James Montgomery wrote: > I came across this bug report using 'how-can-i-help --old --show > newcomer' and am having trouble reproducing in isolation. I would like > to request a log sample to further, and more accurately, investigate. Thanks for you interest in helping with the Debian wiki! Here is the output from the problematic part of the script, with added logdate debugging to make it more obvious where the issue is: Splitting up event-log-TEMP: logdate 1433471906044661433635204430807 gmtime(1433471906044661392216497848320) too large at /srv/wiki.debian.org/bin/rotate-logs line 117, <$fh_in> line 1. gmtime(1433471906044661392216497848320) failed at /srv/wiki.debian.org/bin/rotate-logs line 117, <$fh_in> line 1. Use of uninitialized value $year in addition (+) at /srv/wiki.debian.org/bin/rotate-logs line 119, <$fh_in> line 1. Use of uninitialized value $mon in addition (+) at /srv/wiki.debian.org/bin/rotate-logs line 119, <$fh_in> line 1. event-log-CURRENT: 27342430 lines 27342430 total Splitting up event-log-TEMP: logdate 1505621750678650 event-log-CURRENT: 76 lines 76 total Here is a sample of the event log, with the private data removed: 1505622178372608VIEWPAGE pagename=...&HTTP_USER_AGENT=...&REMOTE_ADDR=... If I grep the event log for the logdate listed above, I get this: 1433471906044661433635204430807 VIEWPAGE pagename=...&HTTP_USER_AGENT=...&HTTP_REFERER=...&REMOTE_ADDR=... I also noticed another line with the very long timestamp: 1438244879888341438473603006892 VIEWPAGE pagename=...&HTTP_USER_AGENT=...&HTTP_REFERER=...&REMOTE_ADDR=... Hopefully the data above helps to resolve this, while getting this data I noticed that this bug has resulted in a very large log file. > I am assuming this bug still persists Correct. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#869395: #869395 cinnamon-common: Dependency of gettext needed
I just hit this bug as well. Any chance we can get this fixed in a stable point release? Adding the missing dependency should be pretty benign.
Bug#875995: sump-logicanalyzer: missing B-D: ant
Source: sump-logicanalyzer Version: 0.8-1 Severity: serious Justification: fails to build from source Hi, sump-logicanalyzer cannot be built in experimental any more: fakeroot debian/rules clean dh clean dh: Compatibility levels before 9 are deprecated (level 8 in use) dh_auto_clean dh_auto_clean: Compatibility levels before 9 are deprecated (level 8 in use) debian/rules override_dh_clean make[1]: Entering directory '/build/sump-logicanalyzer-0.8' cd client && ant clean /bin/sh: 1: ant: not found debian/rules:19: recipe for target 'override_dh_clean' failed make[1]: *** [override_dh_clean] Error 127 make[1]: Leaving directory '/build/sump-logicanalyzer-0.8' debian/rules:13: recipe for target 'clean' failed make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 Cheers, Andreas sump-logicanalyzer_0.8-1.log.gz Description: application/gzip
Bug#875994: stretch-pu: package flickcurl/1.26-2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi.
Could you please consider the attached changes to flickcurl to fix
#875800? If so, I will prepare an upload.
Thanks.
Kumar
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IN:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
Kumar Appaiah
>From a5cc2a5d2fc7074f50fbaa772232b6e0fea7ce89 Mon Sep 17 00:00:00 2001
From: Dave Beckett
Date: Sun, 25 Jan 2015 15:44:27 -0800
Subject: [PATCH] Make form use/free api saner and prevent double free. Fixes
Issue #28
---
src/common.c | 31 +--
src/flickcurl_internal.h | 2 +-
src/oauth.c | 34 ++
3 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/src/common.c b/src/common.c
index 1fcc67d..348c78f 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1516,14 +1516,18 @@ flickcurl_invoke_get_content(flickcurl *fc, size_t* size_p)
}
+/*
+ * INTERNAL - free a form.
+ */
void
-flickcurl_free_form(char **form, int count)
+flickcurl_free_form(char **form)
{
if(!form)
return;
/* free content which is the first key */
- free(form[0]);
+ if(form[0])
+free(form[0]);
free(form);
}
@@ -1537,10 +1541,16 @@ flickcurl_free_form(char **form, int count)
* INTERNAL - decoded content from current request as HTTP FORM and return fields
*
* NOTE: The result may be an empty array with just two NULL
-* terminating pointers if there are no fields.
+* terminating pointers if there are no fields or no content.
+*
+* If @count_p is not NULL, *@count_p is set to the number of pairs of
+* fields.
+*
+* Index 0 is used to store the raw content.
+*
+* Return value: NULL on failure or an array of [char* field name,
+* char* field value] starting at index 1, terminated by a NULL pair.
*
-* Return value: array of [char* field name, char* field value] with
-* NULL pair terminating or NULL on failure
*/
char**
flickcurl_invoke_get_form_content(flickcurl *fc, int* count_p)
@@ -1562,21 +1572,24 @@ flickcurl_invoke_get_form_content(flickcurl *fc, int* count_p)
count++; /* counting separators so need +1 for number of contents */
}
- /* Allocate count + 1 sized array of char* (key, value) pointers
+ /* Allocate 1+ count + 1 sized array of char* (key, value) pointers
* The last pair are always (NULL, NULL).
*
* The pointers are into the 'content' buffer which is kept around
* and owned by this array and stored in form[0].
*/
- form = (char**)calloc(2*(count + 1), sizeof(char*));
+ form = (char**)calloc(1 + 2*(count + 1), sizeof(char*));
if(!form) {
if(content)
free(content);
return NULL;
}
+ /* the form owns the content array */
+ form[0] = content;
+
if(content) {
-for(p = content, i = 0; *p; p++) {
+for(p = content, i = 1; *p; p++) {
char *start = p;
while(*p && *p != '&' && *p != '=')
@@ -1590,8 +1603,6 @@ flickcurl_invoke_get_form_content(flickcurl *fc, int* count_p)
}
form[i++] = NULL;
form[i] = NULL;
-
-free(content);
}
if(count_p)
diff --git a/src/flickcurl_internal.h b/src/flickcurl_internal.h
index 4904341..3082978 100644
--- a/src/flickcurl_internal.h
+++ b/src/flickcurl_internal.h
@@ -119,7 +119,7 @@ xmlDocPtr flickcurl_invoke(flickcurl *fc);
char* flickcurl_invoke_get_content(flickcurl *fc, size_t* size_p);
/* Invoke URI prepared above and get back 'count' key/values */
char** flickcurl_invoke_get_form_content(flickcurl *fc, int* count_p);
-void flickcurl_free_form(char **form, int count);
+void flickcurl_free_form(char **form);
/* args.c */
void flickcurl_free_arg(flickcurl_arg *arg);
diff --git a/src/oauth.c b/src/oauth.c
index d1f649e..8ac4e3c 100644
--- a/src/oauth.c
+++ b/src/oauth.c
@@ -741,11 +741,12 @@ flickcurl_oauth_create_request_token(flickcurl* fc, const char* callback)
uri, count);
#endif
- for(i = 0; i < (2 * count); i += 2) {
-if(!strcmp(form[i], "oauth_token")) {
- request_token = form[i+1];
-} else if(!strcmp(form[i], "oauth_token_secret")) {
- request_token_secret = form[i+1];
+ for(i = 0; i < count; i++) {
+int offset = 1 + (2 * i);
+if(!strcmp(form[offset], "oauth_token")) {
+ request_token = form[offset+1];
+} else if(!strcmp(form[offset], "oauth_token_secret")) {
+ request_token_secret = form[offset+1];
}
}
@@ -771,7 +772,7 @@ flickcurl_oauth_create_request_token(flickcurl* fc, const char* callback)
tidy:
if(form)
-flickcurl_free_form(form, count);
+flickcurl_free_form(form);
return rc;
}
@@
Bug#875993: yamcha: FTBFS with GCC 7
Package: yamcha Version: 0.33-1 Severity: serious Justification: fails to build from source (but built successfully in the past) yamcha cannot be built any longer in experimental: In file included from param.cpp:32:0: param.cpp: In member function 'bool YamCha::Param::open(const char*, const YamCha::Option*)': ../config.h:76:17: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] #define PACKAGE "yamcha" ^ param.cpp:186:14: note: in expansion of macro 'PACKAGE' ptr[0] = PACKAGE; ^~~ feature_index.cpp: In member function 'bool YamCha::FeatureIndex::setFeature(const string&, int)': feature_index.cpp:150:62: error: no matching function for call to 'make_pair(const int&, const int&)' feature_set.insert (std::make_pair ( *rit, *cit ) ); ^ In file included from /usr/include/c++/7/utility:70:0, from /usr/include/c++/7/tuple:38, from /usr/include/c++/7/functional:54, from feature_index.cpp:23: /usr/include/c++/7/bits/stl_pair.h:519:5: note: candidate: template constexpr std::pair::__type, typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _ T2&&) make_pair(_T1&& __x, _T2&& __y) ^ /usr/include/c++/7/bits/stl_pair.h:519:5: note: template argument deduction/substitution failed: feature_index.cpp:150:51: note: cannot convert 'rit.std::_Rb_tree_const_iterator::operator*()' (type 'const int') to type 'int&&' feature_set.insert (std::make_pair ( *rit, *cit ) ); ^~~~ feature_index.cpp:154:66: error: no matching function for call to 'make_pair(const int&, const int&)' bow_feature_set.insert (std::make_pair ( *rit, *cit ) ); ^ In file included from /usr/include/c++/7/utility:70:0, from /usr/include/c++/7/tuple:38, from /usr/include/c++/7/functional:54, from feature_index.cpp:23: /usr/include/c++/7/bits/stl_pair.h:519:5: note: candidate: template constexpr std::pair::__type, typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _ T2&&) ... Andreas yamcha_0.33-1.log.gz Description: application/gzip
Bug#875991: fast5: FTBFS: debian/python-fast5-bin/usr/bin/ is not a directory
Source: fast5 Version: 0.6.2-4 Severity: serious Justification: fails to build from source (but built successfully in the past) Greetings. Builds of fast5 covering only its architecture-dependent binary packages (as on the autobuilders, or with dpkg-buildpackage -B) have been failing: dh_install mv debian/python-fast5/usr/bin/* debian/python-fast5-bin/usr/bin/ mv: target 'debian/python-fast5-bin/usr/bin/' is not a directory debian/rules:36: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 1 make[1]: Leaving directory '/<>' debian/rules:16: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 Splitting override_dh_install into -arch and -indep variants can be helpful in general, but could be problematic here when building all the binary packages if the -arch target runs first. Instead, I suppose you'll want to conditionalize these mv commands on the existence of debian/python-fast5-bin, and likewise conditionalize the sed commands on the existence of debian/libfast5-dev. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#875992: haskell-lens: unsatisfiable B-D: libghc-vector-dev (< 0.12) but 0.12.0.1-1 is to be installed
Source: haskell-lens Version: 4.15.1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) haskell-lens connot be built in sid any more, blocking the ongoing ghc transition. Andreas
Bug#875917: retro-gtk: FTBFS: linux/input-event-codes.h: No such file or directory
Jeremy Bicha writes: > Yeah, I did that in git several hours ago but it wasn't important > enough for me to bother doing a new upload just for that: Great, thanks! Sorry for forgetting to check Alioth before reporting the issue. > I did not file a bug upstream but you're welcome to do that if you > like. The new includes is part of a new feature to allow configuring > gamepads, joysticks or whatever in gnome-games-app. I don't know a > cross-platform way to do that. I suppose it might be possible to do something with libusb, but I don't have details. You could also consider disabling just that one feature on non-Linux architectures. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#875916: gnome-software: FTBFS on non-Linux: Native dependency 'gudev-1.0' not found
Michael Biebl writes: > Can you please in the future usertag such arch/kfreebsd/hurd specific > issues so the show up on the radar of the porters. Sure; thanks for reminding me about those usertags. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#875990: reproducible: i/o issues with profitbricks-build2-i386 since stretch upgrade
Package: jenkins.debian.org Severity: normal It looks like after the upgrade to stretch (late june/early july), two of the i386 builders, profitbricks-build2-i386 and profitbricks-build12-i386 suddenly developed large i/o issues. You can see this on the munin graphs for the year, where the blue i/o wait spikes: https://jenkins.debian.net/munin/debian.net/profitbricks-build2-i386.debian.net/cpu.html https://jenkins.debian.net/munin/debian.net/profitbricks-build12-i386.debian.net/cpu.html Comparing this to the other i386 builders, where there is no huge spike in i/o wait: https://jenkins.debian.net/munin/debian.net/profitbricks-build6-i386.debian.net/cpu.html https://jenkins.debian.net/munin/debian.net/profitbricks-build16-i386.debian.net/cpu.html I suspect this is reducing the i386 builds per day significantly, averaging only ~1200 in the last 3 months. My *hunch* is that build2 and build12 are running a PAE kernel with more than 8GB of ram, and affected by this kernel bug (introduced in linux ~4.2, possibly): https://bugzilla.kernel.org/show_bug.cgi?id=196157 https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118 Reducing the ram of the affected builders to 8GB and having more PAE builders with lighter workloads might be a workaround that would get better performance... while still testing 32/64-bit kernel variation. Alternately, switching to only amd64 kernels might also fix the issue, though wouldn't test 32/64-bit kernel variations. Running a linux 4.1 kernel from snapshot.debian.org might be another way to test the issue, even if not running long-term. live well, vagrant signature.asc Description: PGP signature
Bug#867033: this problem's additional Information/
additional error screen shot it's seem to be vmnet driver problem. 2017-07-04 14:58 GMT+09:00 이강우(KangWoo Lee) : > Physical Machine : ESXi on HP microserver N54L > VM : Debian 9 clean & minimal installation (only ssh & basic packages) > > > I tested it under different conditions, but it did not occur in other > environments. > > In the same conditions, changing the physical equipment to another > equipment did not cause any problems. > > >
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Package: console-setup Version: 1.167 Severity: normal Updated from 166 to 167 and when verifying changes in /etc/ noticed there was only one change, in console-setup/cached_setup_keyboard.sh: ---8<--- -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' +loadkeys '/tmp/tmpkbd.31u83e' > '/dev/null' --->8--- File in /tmp/, named tmpkbd and with (random) extension that looks like one from mktemp? And before it was a file in /etc/ with understable name? Suspicious. Running the script by hand returns the obvious "cannot open file /tmp/tmpkbd.31u83e" while calling the other version of loadkeys invocation works fine. Prediction is that in next boot it will complain too and require manually calling with the proper kmap file. Also while tracking the calls for boot sequence, found that usage line for /etc/init.d/keyboard-setup.sh and console-setup.sh forgot the .sh extension (two mount*.sh forgot the extension too, but that would be for another report). Most scripts properly report their name with .sh and one even just uses $0 so it reacts automatically to however it was called. Minor cosmetic details. Thanks, GSR -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages console-setup depends on: ii console-setup-linux 1.167 ii debconf 1.5.62 ii keyboard-configuration 1.167 ii xkb-data2.5.1-3 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.24-17 ii lsb-base 9.20170808 Versions of packages keyboard-configuration depends on: ii debconf 1.5.62 ii liblocale-gettext-perl 1.07-3+b3 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.49 ii initscripts 2.88dsf-59.9 ii kbd 1.15.5-1 ii keyboard-configuration 1.167 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center ii kbd 1.15.5-1 -- debconf information: keyboard-configuration/store_defaults_in_debconf_db: true * keyboard-configuration/altgr: Right Alt (AltGr) console-setup/use_system_font: * console-setup/fontface47: Fixed keyboard-configuration/layoutcode: es keyboard-configuration/xkb-keymap: es console-setup/codesetcode: Lat15 keyboard-configuration/other: keyboard-configuration/layout: console-setup/framebuffer_only: keyboard-configuration/unsupported_layout: true console-setup/fontsize-text47: 8x16 console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages * console-setup/fontsize-fb47: 8x16 keyboard-configuration/toggle: No toggling keyboard-configuration/switch: No temporary switch * keyboard-configuration/compose: Menu key keyboard-configuration/optionscode: lv3:ralt_switch,compose:menu,terminate:ctrl_alt_bksp keyboard-configuration/modelcode: pc105 keyboard-configuration/variantcode: keyboard-configuration/unsupported_config_options: true console-setup/guess_font: * keyboard-configuration/model: Generic 105-key (Intl) PC debian-installer/console-setup-udeb/title: * keyboard-configuration/variant: Spanish console-setup/store_defaults_in_debconf_db: true keyboard-configuration/unsupported_options: true * keyboard-configuration/ctrl_alt_bksp: true console-setup/charmap47: UTF-8 console-setup/fontsize: 8x16 keyboard-configuration/unsupported_config_layout: true
Bug#875988: libedit-dev: Ships man page that conflicts with the GNU History Library's man page
Package: libedit-dev Version: 3.1-20170329-1 Severity: normal Dear Maintainer, libedit-dev ships a man page that includes the function name "history" in its name section[1] making man to resolve the EDITLINE(3) man page instead of HISTORY(3) the GNU History Library man page. Here is the output of "man -k history": Date::Manip::History (3pm) - Twenty years and still going strong editline (3edit) - line editor, history and tokenization functions el_deletestr (3) - line editor, history and tokenization functions el_end (3) - line editor, history and tokenization functions el_get (3) - line editor, history and tokenization functions el_getc (3) - line editor, history and tokenization functions el_gets (3) - line editor, history and tokenization functions el_init (3) - line editor, history and tokenization functions el_init_fd (3) - line editor, history and tokenization functions el_insertstr (3) - line editor, history and tokenization functions el_line (3) - line editor, history and tokenization functions el_parse (3) - line editor, history and tokenization functions el_push (3) - line editor, history and tokenization functions el_reset (3) - line editor, history and tokenization functions el_resize (3)- line editor, history and tokenization functions el_set (3) - line editor, history and tokenization functions el_source (3)- line editor, history and tokenization functions el_wdeletestr (3)- line editor, history and tokenization functions el_wget (3) - line editor, history and tokenization functions el_wgetc (3) - line editor, history and tokenization functions el_wgets (3) - line editor, history and tokenization functions el_winsertstr (3)- line editor, history and tokenization functions el_wline (3) - line editor, history and tokenization functions el_wparse (3)- line editor, history and tokenization functions el_wpush (3) - line editor, history and tokenization functions el_wset (3) - line editor, history and tokenization functions history (3) - line editor, history and tokenization functions history (3readline) - GNU History Library history_end (3) - line editor, history and tokenization functions history_init (3) - line editor, history and tokenization functions history_w (3)- line editor, history and tokenization functions history_wend (3) - line editor, history and tokenization functions history_winit (3)- line editor, history and tokenization functions latex-git-log (1)- Generates the version history of a git project as LaTeX source code. pam_pwhistory (8)- PAM module to remember last passwords roff (7) - concepts and history of roff typesetting tok_end (3) - line editor, history and tokenization functions tok_init (3) - line editor, history and tokenization functions tok_line (3) - line editor, history and tokenization functions tok_reset (3)- line editor, history and tokenization functions tok_str (3) - line editor, history and tokenization functions tok_wend (3) - line editor, history and tokenization functions tok_winit (3)- line editor, history and tokenization functions tok_wline (3)- line editor, history and tokenization functions tok_wreset (3) - line editor, history and tokenization functions tok_wstr (3) - line editor, history and tokenization functions XDeviceTimeCoord (3) - get device motion history XDisplayMotionBufferSize (3) - send events and pointer motion history structure XGetDeviceMotionEvents (3) - get device motion history XGetMotionEvents (3) - send events and pointer motion history structure XSendEvent (3) - send events and pointer motion history structure XTimeCoord (3) - send events and pointer motion history structure [1]: https://sources.debian.net/src/libedit/3.1-20170329-1/doc/editline.3.roff/#L63 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_GT.utf8, LC_CTYPE=es_GT.utf8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libedit-dev depends on: ii libbsd-dev 0.8.6-2 ii libedit2 3.1-20170329-1 ii libncurses5-dev 6.0+20170902-1 ii libtinfo-dev 6.0+20170902-1 libedit-dev recommends no packages. libedit-dev suggests no packages. -- debconf-show failed Regards, Josue Ortega
Bug#874693: Is this still an issue?
I see that gjs 1.50 has been released. Is this bug still applicable?
Bug#875135: [qgis] Future Qt4 removal from Buster
Control: tags -1 upstream On 09/09/2017 11:01 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4 QGIS 3.x will support Qt5, and the Debian package will switch away from Qt4 when the QGIS 3.4.4 LTR is released [0], or sooner if the Qt4 removal demands it. [0] http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#875720: [ktorrent]
Package: ktorrent Version: 5.1.0-2 --- Please enter the report below this line. --- I confirm this bug which also prevents me from using a private tracker. May I suggest changing severity to "important" as it might be a main stopper? Regards, Antonio --- System information. --- Architecture: Kernel: Linux 4.12.0-1-amd64 Debian Release: buster/sid 900 testing ftp.es.debian.org 500 stable update.devolo.com 500 stable kxstudio.linuxaudio.org 500 stable download.videolan.org 500 stable dl.google.com 500 sid linux.dropbox.com 500 lucid ppa.launchpad.net 100 oldoldstablesecurity.debian.org 100 oldoldstableftp.es.debian.org --- Package information. --- Depends (Version) | Installed ===-+- == kio | 5.37.0-2 libc6 (>= 2.14) | libgcc1 (>= 1:3.0) | libgeoip1 | libkf5archive5 (>= 4.96.0) | libkf5completion5 (>= 4.97.0) | libkf5configcore5 (>= 4.98.0) | libkf5configgui5(>= 4.97.0) | libkf5configwidgets5(>= 4.96.0) | libkf5coreaddons5 (>= 5.16.0) | libkf5crash5(>= 5.15.0) | libkf5dbusaddons5 (>= 4.99.0) | libkf5dnssd5(>= 4.96.0) | libkf5i18n5 (>= 4.97.0) | libkf5iconthemes5 (>= 4.96.0) | libkf5itemviews5(>= 4.96.0) | libkf5kcmutils5 (>= 4.96.0) | libkf5kiocore5 (>= 4.96.0) | libkf5kiofilewidgets5 (>= 4.96.0) | libkf5kiowidgets5 (>= 4.96.0) | libkf5krosscore5(>= 4.96.0) | libkf5notifications5(>= 4.96.0) | libkf5notifyconfig5 (>= 4.96.0) | libkf5parts5(>= 4.96.0) | libkf5plotting5 (>= 4.96.0) | libkf5service-bin | libkf5service5(>= 5.4.0+git20141113.1055+15.04) | libkf5syndication5(>= 15.07.90) | libkf5textwidgets5 (>= 5.0.0) | libkf5torrent6 (>= 2.1) | libkf5webkit5 (>= 4.96.0) | libkf5widgetsaddons5(>= 4.96.0) | libkf5windowsystem5 (>= 4.96.0) | libkf5xmlgui5 (>= 4.98.0) | libphonon4qt5-4(>= 4:4.8.0) | libqt5core5a(>= 5.9.0~beta) | libqt5dbus5 (>= 5.7.0) | libqt5gui5 (>= 5.8.0) | libqt5network5 (>= 5.7.0) | libqt5webkit5 (>= 5.6.0~rc) | libqt5widgets5 (>= 5.7.0) | libqt5xml5 (>= 5.7.0) | libstdc++6 (>= 5.2) | libtag1v5 (>= 1.9.1-2.2~) | phonon4qt5 | ktorrent-data (= 5.1.0-2) | libktorrent-l10n| Package's Recommends field is empty. Suggests(Version) | Installed =-+-=== krosspython | geoip-database| 20170831-1
Bug#872620: anarchism: add Suggests: fortune-anarchism
All solved, package is on mentors Holger :) thanks Samuel Henrique
Bug#875954: there should be patch somewhere...
Unwelcome comment from the peanut gallery: Ondrej closed a great many bugs improperly, including some of mine. They were not fixed or addressed and he didn't ask the reporters if they were still an issue. He just closed them because he wanted to be able to put "Debian maintainer" on his resume or something. On 09/16/2017 10:23 AM, Willi Mann wrote: Hi, according to the previous maintainer, this bug was fixed in version 0.75.0-15. However, I never verified that (I reported the bug back then) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812235 Bye Willi
Bug#875987: ITP: node-babel-plugin-transform-decorators-legacy -- Compile class and object decorators to ES5 (legacy)
Package: wnpp Severity: wishlist Owner: Daniel Ring X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-babel-plugin-transform-decorators-legacy Version : 1.3.4 Upstream Author : Logan Smyth * URL : https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy#readme * License : Expat Programming Lang: JavaScript Description : Compile class and object decorators to ES5 (legacy) A plugin for Babel 6 that (mostly) replicates the old decorator behavior from Babel 5. Babel is a JavaScript compiler to use next generation JavaScript, today. ES2015 and beyond: Babel has support for the latest version of JavaScript through syntax transformers. These plugins allow you to use new syntax, right now without waiting for browser support. Note: This library is in contrib because it needs node-babel from contrib to build. Node.js is an event-based server-side JavaScript engine.
Bug#875986: pam: Typo or pointless check in securetty patch
Source: pam
Version: 1.1.8-3.6
Severity: normal
Hi maintainers,
When looking for some strange behaviour pam_unix, I came across a possible typo
in the securetty patch [1]. I'll highlight the relevant parts of the code
below.
if (isdigit(uttyname[0])) {
snprintf(ptname, sizeof(ptname), "pts/%s", uttyname);
} else {
ptname[0] = '\0';
}
This means that either:
1) uttyname starts with a digit and ptname is "pts/$uttyname".
2) utty name does not start with a digit and ptsname is "".
Then there is:
retval = 1;
while ((fgets(ttyfileline,sizeof(ttyfileline)-1, ttyfile) != NULL)
&& retval) {
if(ttyfileline[strlen(ttyfileline) - 1] == '\n')
ttyfileline[strlen(ttyfileline) - 1] = '\0';
retval = ( strcmp(ttyfileline,uttyname)
&& (!ptname[0] || strcmp(ptname, uttyname)) );
}
And in particular, this part of the check:
(!ptname[0] || strcmp(ptname, uttyname))
In case 1) above, ptname is not empty and ptname can never equal uttyname, so
this resolves to (false || non-zero) == true. In case 2) above, this resolves
to (true || whatever) == true. Hence, I believe this part of the check just
means && true and could be omitted.
But more likely, there's a typo in this line and it should have read:
(!ptname[0] || strcmp(ptname, ttyfileline))
This would check each line from the securetty file against both uttyname and
ptname, instead of just against uttyname.
I'm not sure if the ptname part is actually needed at all, since this code
seems to work just fine without it for /dev/pts devices (but perhaps not in all
cases, I'm not sure what forms uttyname can have).
[1]:
https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid/view/head:/debian/patches-applied/054_pam_security_abstract_securetty_handling#L162
Gr.
Matthijs
Bug#875985: lintian: Allow Testsuite: autopkgtest-pkg-octave
Package: lintian Version: 2.5.52 Severity: normal Dear Maintainer, Version 0.10 of autodep8 has support for Octave packages. Please, add autopkgtest-pkg-octave to the list of known test suites. Also, please change the description of tag unknown-testsuite. It contains now: The dsc file sets Testsuite to a value other than autopkgtest, the only one allowed. This field is most probably copied by dpkg-source from Testsuite in debian/control. but autopkgtest is not the only value allowed. Thanks, Rafael Laboissière -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental'), (550, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.28-5 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1 ii dpkg 1.18.22 ii file 1:5.29-3 ii gettext 0.19.8.1-2 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b2 ii libdpkg-perl 1.18.22 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.94-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.24 [libdigest-sha-perl] 5.24.1-1 ii libperl5.26 [libdigest-sha-perl] 5.26.0-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.63-2+b2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.26.0-5 ii t1utils 1.40-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.22 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.46-1 -- no debconf information
Bug#866338: New version 4.0.0
Hello, On 29.06.2017 00:26, Craig Andrews wrote: > Source: cppformat > Version: 3.0.1+ds-1 > > Version 4.0.0 of libfmt has been released - can you please release new > packages for it? (libfmt4-dev, libfmt4-doc, etc) > > https://github.com/fmtlib/fmt/releases/tag/4.0.0 Thank you for the report. The work is in progress to package it. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#875690: Fixed in FreeXL 1.0.4
Hi Salvatore,
On 09/13/2017 07:27 PM, Bas Couwenberg wrote:
> Should be fixed in the new upstream release:
>
> https://groups.google.com/forum/m/#!topic/spatialite-users/Wpj62XSzcZY
>
> I'm not able to work on this until I return from VAC.
I've cherry-picked the changes from 1.0.4 and prepared updates for
stretch, jessie & wheezy. The changes are available in git, and the
debdiffs are attached.
* https://anonscm.debian.org/cgit/pkg-grass/freexl.git/log/?h=stretch
* https://anonscm.debian.org/cgit/pkg-grass/freexl.git/log/?h=jessie
* https://anonscm.debian.org/cgit/pkg-grass/freexl.git/log/?h=wheezy
Are these OK to upload?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
diff -Nru freexl-1.0.0b/debian/changelog freexl-1.0.0b/debian/changelog
--- freexl-1.0.0b/debian/changelog 2015-11-13 11:39:37.0 +0100
+++ freexl-1.0.0b/debian/changelog 2017-09-16 23:26:04.0 +0200
@@ -1,3 +1,10 @@
+freexl (1.0.0b-1+deb7u4) wheezy-security; urgency=high
+
+ * Add upstream patch to fix CVE-2017-2923 & CVE-2017-2924.
+(closes: #875690, #875691)
+
+ -- Bas Couwenberg Sat, 16 Sep 2017 23:26:04 +0200
+
freexl (1.0.0b-1+deb7u3) wheezy-security; urgency=high
* Add patch to fix regression introduced by afl-vulnerabilitities.patch.
diff -Nru freexl-1.0.0b/debian/patches/CVE-2017-2923_CVE-2017-2924.patch
freexl-1.0.0b/debian/patches/CVE-2017-2923_CVE-2017-2924.patch
--- freexl-1.0.0b/debian/patches/CVE-2017-2923_CVE-2017-2924.patch
1970-01-01 01:00:00.0 +0100
+++ freexl-1.0.0b/debian/patches/CVE-2017-2923_CVE-2017-2924.patch
2017-09-16 23:26:04.0 +0200
@@ -0,0 +1,317 @@
+Description: fixing a security issue - Cisco TALOS-2017-430 and TALOS-2017-431
+ CVE-2017-2923 & CVE-2017-2924
+Author: Alessandro Furieri
+Origin: https://www.gaia-gis.it/fossil/freexl/ci/40c17539ea56f0d8
+Bug-Debian: https://bugs.debian.org/875690
+https://bugs.debian.org/875691
+
+--- a/src/freexl.c
b/src/freexl.c
+@@ -935,6 +935,21 @@ set_sst_value (biff_workbook * workbook,
+ return FREEXL_OK;
+ }
+
++static size_t
++xls_fread (size_t bufsz, void *buf, size_t size, size_t nmemb, FILE * fl)
++{
++/*
++/ Sandro 2017-09-07
++/ secure version of "fread" checking against buffer overflows
++/---
++/ expected to fix the issue reported by
++/ Cisco [TALOS-2017-431]
++*/
++if ((size * nmemb) > bufsz)
++ return 0;
++return fread (buf, size, nmemb, fl);
++}
++
+ static fat_chain *
+ alloc_fat_chain (int swap, unsigned short sector_shift,
+unsigned int directory_start)
+@@ -1377,7 +1392,8 @@ read_fat_sector (FILE * xls, fat_chain *
+ max_fat = 128;
+
+ /* reading a FAT sector */
+-if (fread (buf, 1, chain->sector_size, xls) != chain->sector_size)
++if (xls_fread (sizeof (buf), buf, 1, chain->sector_size, xls) !=
++ chain->sector_size)
+ return FREEXL_CFBF_READ_ERROR;
+
+ for (i_fat = 0; i_fat < max_fat; i_fat++)
+@@ -1419,7 +1435,8 @@ read_difat_sectors (FILE * xls, fat_chai
+ if (fseek (xls, where, SEEK_SET) != 0)
+ return FREEXL_CFBF_SEEK_ERROR;
+ /* reading a DIFAT sector */
+-if (fread (&difat, 1, chain->sector_size, xls) != chain->sector_size)
++if (xls_fread (sizeof (difat), &difat, 1, chain->sector_size, xls) !=
++chain->sector_size)
+ return FREEXL_CFBF_READ_ERROR;
+ blocks++;
+ if (chain->swap)
+@@ -1480,7 +1497,8 @@ read_miniFAT_sectors (FILE * xls, fat_ch
+ unsigned char *p_buf = buf;
+ block++;
+ /* reading a miniFAT sector */
+-if (fread (&buf, 1, chain->sector_size, xls) != chain->sector_size)
++if (xls_fread (sizeof (buf), &buf, 1, chain->sector_size, xls) !=
++chain->sector_size)
+ return FREEXL_CFBF_READ_ERROR;
+ for (i_fat = 0; i_fat < max_fat; i_fat++)
+ {
+@@ -1508,7 +1526,7 @@ read_cfbf_header (biff_workbook * workbo
+ int ret;
+ unsigned char *p_fat = header.fat_sector_map;
+
+-if (fread (&header, 1, 512, workbook->xls) != 512)
++if (xls_fread (sizeof (header), &header, 1, 512, workbook->xls) != 512)
+ {
+ *err_code = FREEXL_CFBF_READ_ERROR;
+ return NULL;
+@@ -1654,8 +1672,9 @@ read_mini_stream (biff_workbook * workbo
+ *errcode = FREEXL_CFBF_SEEK_ERROR;
+ return 0;
+ }
+-if (fread (buf, 1, workbook->fat->sector_size, workbook->xls) !=
+-workbook->fat->sector_size)
++if (xls_fread
++(sizeof (buf), buf, 1, workbook->fat->sector_size,
++ workbook->xls) != workbook->fat->sector_size)
+ {
+ *errcode = FREEXL_CFBF_READ_ERROR;
+ return 0;
+@@ -1987,7 +2006,7 @@ legacy_emergency_dimension (biff_workboo
+ /* looping on BIFF records */
+ if (!first)
+
Bug#875964: lintian: please warn about files in /usr/lib/pythonX.Y/dist-packages/tests/__init__.py
On Sat, Sep 16, 2017 at 10:08:12PM +0100, Chris Lamb wrote: > > ISTR there is a already a tag for those kind of files > > Hm, I can't seem to find such a tag. Were you thinking of > "manpage-has-overly-generic-name"? oh indeed I might have misremembered that one. So I suppose this bug is to be considered a whishlist to add either a overly-generic-filename or python-module-has-overly-generic-name or something like that, I'll leave that choice to the implementer :) FTR, currently these are the only files with 'dist-packages/tests' (none has a 'dist-pakcages/test/': python-azure: /usr/lib/python2.7/dist-packages/tests/__init__.py python-azure: /usr/lib/python2.7/dist-packages/tests/test_mgmt_containerinstance.py python-azure: /usr/lib/python2.7/dist-packages/tests/test_mgmt_media.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/__init__.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/__init__.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/__init__.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/apps.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/models.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/settings.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/test_decorators.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/test_django_models.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/test_django_storage.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/test_django_util.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/django_util/test_views.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test__appengine_ndb.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_appengine.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_devshell.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_dictionary_storage.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_flask_util.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_gce.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_keyring_storage.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_locked_file.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_metadata.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_multiprocess_file_storage.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_multistore_file.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_sqlalchemy.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/contrib/test_xsrfutil.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/http_mock.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test__helpers.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test__pure_python_crypt.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test__pycrypto_crypt.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_client.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_clientsecrets.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_crypt.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_file.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_jwt.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_service_account.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_tools.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_transport.py python-oauth2client: /usr/lib/python2.7/dist-packages/tests/test_util.py Both of them gained said an RC bug by anbe about it, and indeed I also believe both of them installs those files by error. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#849077: Please adjust the BTS version tracking info
On Sat, 9 Sep 2017 19:17:12 +0200 Francesco Poli wrote: > On Sat, 1 Jul 2017 23:32:28 +0200 Francesco Poli wrote: > > > Dear Debian wpasupplicant Maintainers, > > I noticed that these 3 RC bugs (#849122, #849077, #849875) are marked > > as found in wpa/2.6-2, which is now superseded by versions with epoch 2. > > What seems to have happened (please correct me, if I am wrong) is that > > the upstream version 2.4 was reintroduced into unstable (with epoch 2) > > and then migrated to stretch (before the stretch release as stable). > > > > Hence, I would say that those three bugs only affect experimental and > > are not in stretch, buster or sid. > > > > Could you please confirm that these 3 bugs should be marked as fixed in > > wpa/2:2.4-1 and found in wpa/2:2.6-4 ? > > > > Thanks for your time! > > Bye. > > Hello again, > could you please reply to my question? > > Again, thanks for your time. Ping? -- 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 pgp4VxSUJLP8w.pgp Description: PGP signature
Bug#875813: rsync: missed "Number of deleted files"
On Sat 16 Sep 2017, Max wrote: > Ok, the problem happens only with sshdroid (android ssh server application). > With other pc clients everything ok :) > > well, is it a bug of rsync or of sshdroid? You could try using strace on the rsync process to see if it actually does emit the missing line; if so, rsync can hardly be held to blame. It would be a curiously specific error in sshdroid though. Am I to understand that you are running rsync on an android system and connecting to it via this sshdroid? Might it then not be a problem in the rsync running on the android, that it does not pass this info? Please test it yourself with rsync running on debian at both ends, I'm confident that then there it no problem, and hence there's nothing Debian can do to fix this. Paul
Bug#729956: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote: > I was assuming it's because there's a cyclic dependency between pandas > and statsmodels (needed for pandas unit tests), and statsmodels was > also broken by the fpectl problem. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875805 > > My solution was to use build-profiles to flag the test dependency with > !nocheck Looking at python3-skimage-lib (which also requires a rebuild), it seems that the package failed to pass some tests. Bug #868582 even includes a patch to update to 0.13 [and disables some test failures].
Bug#729956: Python 3 Statsmodels & Pandas
On Sat, 2017-09-16 at 22:59 +0200, Yuri D'Elia wrote:
> On Sat, Sep 16 2017, Diane Trout wrote:
> > python3-pandas: Pandas is not installable
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
>
> I would have expected the rebuild of python packages affected by the
> fpectl extension with a transition, but it doesn't seem to be the
> case?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874253
>
> More Breaks where added to {python,python3}-stdlib itself, but there
> are
> still packages which didn't rebuild.
I was assuming it's because there's a cyclic dependency between pandas
and statsmodels (needed for pandas unit tests), and statsmodels was
also broken by the fpectl problem.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875805
My solution was to use build-profiles to flag the test dependency with
!nocheck
(The diff of the control file changes, though I forgot to add python3-
statsmodels.)
I have a few rules changes too, but I need to separate the changes into
different commits.
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: python
Priority: optional
Maintainer: NeuroDebian Team
Uploaders: Yaroslav Halchenko , Michael Hanke <
michael.hanke@g
mail.com>
-Build-Depends: debhelper (>= 7.0.50),
+Build-Depends: debhelper (>= 10),
python-all-dev (>= 2.5),
python-setuptools,
cython,
@@ -11,12 +11,11 @@ Build-Depends: debhelper (>= 7.0.50),
python-scipy,
python-tz,
python-tables [!m68k !sh4 !x32],
- python-sphinx (>= 1.0~),
- python-nbsphinx,
- python-nose,
- python-pytest,
+ python-sphinx (>= 1.0~) ,
+ python-nbsphinx ,
+ python-nose ,
+ python-pytest ,
python-matplotlib [!hurd-i386],
- python-tk,
python-openpyxl, python-xlwt, python-xlrd,
python-bs4,
python-html5lib,
@@ -29,11 +28,10 @@ Build-Depends: debhelper (>= 7.0.50),
python3-numpy (>= 1:1.7~), python3-dateutil,
python3-scipy,
python3-tz,
- python3-sphinx (>= 1.0~),
- python3-nose,
- python3-pytest,
+ python3-sphinx (>= 1.0~) ,
+ python3-nose ,
+ python3-pytest ,
python3-matplotlib [!hurd-i386]| python-matplotlib (<<
1.2.0~) [!hurd-i386],
- python3-tk,
python3-bs4,
python3-six,
python3-lxml,
@@ -42,15 +40,15 @@ Build-Depends: debhelper (>= 7.0.50),
xvfb, xauth, xclip,
Build-Depends-Indep:
ipython (>= 0.12) | ipython2x | ipython1x,
- python-statsmodels [!arm64 !ppc64el !sparc64 !mips64el !ppc64
!sparc64 !sh4],
+ python-statsmodels [!arm64 !ppc64el !sparc64 !mips64el !ppc64
!sparc64 !sh4] ,
Bug#875984: minetest-mod-homedecor: Fails to load: missing dependency on homedecor_i18n
Package: minetest-mod-homedecor Version: 0.4.16-1 Severity: normal Dear Maintainer, I've installed minetest and a few mods including minetest-mod-homedecor on a clean computer; starting a world where homedecor is enabled now leads to the following errors: ERROR[Main]: mod "building_blocks" has unsatisfied dependencies: "homedecor_i18n" ERROR[Main]: mod "chains" has unsatisfied dependencies: "homedecor" ERROR[Main]: mod "computer" has unsatisfied dependencies: "homedecor_i18n" ERROR[Main]: mod "fake_fire" has unsatisfied dependencies: "homedecor" ERROR[Main]: mod "homedecor" has unsatisfied dependencies: "unifieddyes" "homedecor_i18n" "building_blocks" ERROR[Main]: mod "inbox" has unsatisfied dependencies: "homedecor_i18n" ERROR[Main]: mod "itemframes" has unsatisfied dependencies: "homedecor_i18n" ERROR[Main]: mod "lavalamp" has unsatisfied dependencies: "homedecor_i18n" "unifieddyes" ERROR[Main]: mod "lrfurn" has unsatisfied dependencies: "homedecor_i18n" "unifieddyes" ERROR[Main]: mod "plasmascreen" has unsatisfied dependencies: "homedecor" I can't seem to find homedecor_i18n among the available mods in the configuration screen. (please ignore the mentions of unifieddyes: this was a test world with just homedecor configured, but I tried enabling unifieddyes and it does not solve the issue). Thanks in advance -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages minetest-mod-homedecor depends on: ii minetest 0.4.16+repack-4 ii minetest-mod-unifieddyes 0.4.15-1 ii minetest-server 0.4.16+repack-4 minetest-mod-homedecor recommends no packages. minetest-mod-homedecor suggests no packages. -- no debconf information
Bug#875964: lintian: please warn about files in /usr/lib/pythonX.Y/dist-packages/tests/__init__.py
Hi Mattia, > ISTR there is a already a tag for those kind of files Hm, I can't seem to find such a tag. Were you thinking of "manpage-has-overly-generic-name"? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#729956: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote:
> python3-pandas: Pandas is not installable
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
I would have expected the rebuild of python packages affected by the
fpectl extension with a transition, but it doesn't seem to be the case?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874253
More Breaks where added to {python,python3}-stdlib itself, but there are
still packages which didn't rebuild.
Bug#875983: puppet-module-puppetlabs-apache: CVE-2017-2299: Possible TLS trust misconfiguration
Source: puppet-module-puppetlabs-apache Version: 1.1.1-1 Severity: important Tags: security upstream patch Hi, the following vulnerability was published for puppet-module-puppetlabs-apache. CVE-2017-2299[0]: | Versions of the puppetlabs-apache module prior to 1.11.1 and 2.1.0 | make it very easy to accidentally misconfigure TLS trust. If you | specify the `ssl_ca` parameter but do not specify the `ssl_certs_dir` | parameter, a default will be provided for the `ssl_certs_dir` that | will trust certificates from any of the system-trusted certificate | authorities. This did not affect FreeBSD. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-2299 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2299 [1] https://puppet.com/security/cve/CVE-2017-2299 [2] https://github.com/puppetlabs/puppetlabs-apache/commit/7bb35c2293c12ce52329a4391fe1f20389efef06 Regards, Salvatore
Bug#875281: diffoscope: AssertionError (presenters/html/html.py:623:output_difference)
found 875281 85 thanks > AssertionError (presenters/html/html.py:623:output_difference) Not sure it's helpful at all, but from: https://tests.reproducible-builds.org/debian/rbuild/buster/arm64/systemtap_3.1-2.rbuild.log diffoscope 85 was used. Tagging bug to match. (NB. arm64, not amd64; that confused me for a bit when I could not reproduce locally...) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#729956: Python 3 Statsmodels & Pandas
Hi, Just wanted to give a progress report I was able to build a python 3 version of statsmodels, however I wasn't able to build it against the version of pandas in sid because pandas can't be installed. python3-pandas: Pandas is not installable https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723 I tried rebuilding to get around the cython issue, but then I had some timezone related unit test failures. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875807 Unfortunately upstream's test environments don't replicate it https://github.com/pandas-dev/pandas/issues/17533 Looks like the tests pass with conda packages but not Debian packages. I don't know why yet. Diane
Bug#874521: fwupd segfaults at start
Currently, this bug is keeping fwupd 0.9.7 from migrating to testing. Is this crash new with fwupd 0.9 or can you also reproduce it with testing's 0.8.2-2? Also, if you aren't subscribed to the bug, see Mario's response at https://bugs.debian.org/874521 Thanks, Jeremy Bicha
Bug#875982: RM: obsolete with current Perl?
Package: libsub-current-perl Version: 0.03-2 Severity: serious Justification: obsolete with perl >= 5.16.0 libsub-current-perl 0.03 added a note to its POD explaining that from perl 5.16.0, the built-in __SUB__ can be used instead via the pragma use feature 'current_sub'; libsub-current-perl has no reverse dependencies and an extremely low popcon (7 installs, 0 votes currently). It would appear that it is obsolete and can be removed from Debian.
Bug#868073: bioperl-run: FTBFS: t/Bowtie.t failure
control: forwarded -1 https://github.com/bioperl/bioperl-run/issues/52 control: tags -1 upstream I have forwarded the issue upstream. I think the issue occures since there is no such executable bowtie-align any more. The executables that are shipped with bowtie are named bowtie-align-l or bowtie-align-s. I personally have no idea which one is the right one to run the test. Any hint from the Debian Med team which one would be right would surely help. Kind regards Andreas. -- http://fam-tille.de
Bug#875981: sbuild: creation of wheezy chroot fails with segfault
Hi For completeness, the mentioned kernel change is the following: linux (4.10~rc6-1~exp1) experimental; urgency=medium [...] * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE (Closes: #852620). This breaks (e)glibc versions < 2.14 and dietlibc versions < 0.33. It can be reverted using the kernel parameter: vsyscall=emulate [...] -- Ben Hutchings Tue, 31 Jan 2017 15:33:20 + Regards, Salvatore
Bug#875961: Workaround: use wireshark-gtk
I have found a workaround: I used wireshark-gtk I installed wireshark-gtk with apt-get install wireshark-gtk I can capture with wireshark-gtk both when I start the program as root, and when I start the program as my own user, which is a member of the group wireshark.
Bug#875974: libarchive13: out-of-bounds read in archive_read_format_rar_read_header()
Hi On Sat, Sep 16, 2017 at 09:35:31PM +0200, Salvatore Bonaccorso wrote: > Hi > > This should be fixed upstream with > > https://github.com/libarchive/libarchive/commit/5562545b5562f6d12a4ef991fae158bf4ccf92b6 Additional reference, the mentioned OSS-Fuzz issue is https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=573 Regards, Salvatore
Bug#875981: sbuild: creation of wheezy chroot fails with segfault
Package: sbuild Version: 0.73.0-4 Severity: wishlist I was trying to create a wheezy box, and it crashed. # sbuild-createchroot --include=eatmydata,ccache,gnupg \ wheezy /srv/chroot/wheezy-amd64-sbuild http://deb.debian.org/debian ... I: Extracting xz-utils... I: Extracting zlib1g... I: Installing core packages... W: Failure trying to run: chroot /srv/chroot/wheezy-amd64-sbuild dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb W: See /srv/chroot/wheezy-amd64-sbuild/debootstrap/debootstrap.log for details E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 268, line 4. # tail /srv/chroot/wheezy-amd64-sbuild/debootstrap/debootstrap.log Saving to: '/srv/chroot/wheezy-amd64-sbuild//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb' 0K .. .. .. .. .. 58% 714K 0s 50K .. .. .. .100% 2.16M=0.09s 2017-09-16 12:15:02 (992 KB/s) - '/srv/chroot/wheezy-amd64-sbuild//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb' saved [87392/87392] dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing description dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing architecture Segmentation fault But the same thing worked fine in a stretch vm. After a bit of confusion, followed by some help on #debian-devel, it looks like this may be because my kernel was too new for wheezy. 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux Assuming so, and if there's some reasonable way for sbuild to detect this situation, it'd be nice if sbuild could just tell me why that's never going to work. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#875974: libarchive13: out-of-bounds read in archive_read_format_rar_read_header()
Hi This should be fixed upstream with https://github.com/libarchive/libarchive/commit/5562545b5562f6d12a4ef991fae158bf4ccf92b6 Regards, Salvatore
Bug#495795: dropbear: please provide the scp binary
Control: block -1 by 875979 On Mon, 05 Sep 2016 at 15:15:46 +0300, Mert Dirik wrote: > I know you've wanted to get some suggestions last year but this bug > report, which is only followed by a couple users like me who were > affected from the lack of scp, is not really the right place for > getting answer to the questions you have in your mind. My humble > suggestion is you should talk to OpenSSH maintainers on how to proceed > with it and maybe consult debian-devel for policy related questions or > best practices. In fact the ‘scp.c’ found in the Dropbear source package comes from OpenSSH with minor modifications, so it makes little sense to ship a second version the scp binary. After discussion with upstream and the OpenSSH maintainers, we agreed on a solution: 1. ship OpenSSH's /usr/bin/scp in a dedicated binary package (unlike /usr/bin/ssh it only depends on libc6), cf. #875979; 2. make dbclient(1) accept (as no-op) the options passed by scp(1) to avoid warnings: `-x -oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes`; and 3. for the client part, ship a `dbscp` shell wrapper invoking scp(1) with dbclient(1) as SSH client. See https://lists.debian.org/debian-ssh/2017/07/msg00019.html for details. -- Guilhem. signature.asc Description: PGP signature
Bug#875980: kodi-pvr-vuplus: PVR addon not compatible with Kodi from same Debian release
Package: kodi-pvr-vuplus Version: 2.4.4+git20160820-2 Severity: grave Justification: renders package unusable Dear Maintainer, The Vuplus PVR addon can be installed, configured and generally works until next Kodi start. After next Kodi start a message box comes up stating that the Vu+/Enigma Client Addon is not compatible with this Kodi version and the Addon is automatically deactivated. That behaviour finally renders the Addon and so complete Debian package unusable. The current upstream version of the addon is 3.5.1. BR Marko Log entry is 19:03:19.917 T:139766167123712 NOTICE: ADDON: pvr.vuplus version 2.4.4 is incompatible -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kodi-pvr-vuplus depends on: pn kodi-api-pvr ii libc6 2.24-11+deb9u1 ii libgcc11:6.3.0-18 ii libkodiplatform16 17.1.0-1 ii libp8-platform22.1.0.1+dfsg1-1 ii libstdc++6 6.3.0-18 ii libtinyxml2.6.2v5 2.6.2-4 kodi-pvr-vuplus recommends no packages. kodi-pvr-vuplus suggests no packages. -- no debconf information
Bug#875975: kmod FTBFS: subprocess.CalledProcessError: Command '['/usr/bin/pkg-config', '--variable=prefix', 'glib-2.0']' returned non-zero exit status 1
Control: reassign -1 gtk-doc/1.26-1
Control: affects -1 kmod
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=787768
Hi,
On 16/09/17 20:42, Helmut Grohne wrote:
> Source: kmod
> Version: 24-1
> Severity: serious
>
> kmod fails to build from source in unstable. The tail of the build log
> is:
>
> | cd html && gtkdoc-mkhtml $mkhtml_options
> --path=/<>/build-deb/../libkmod/docs/doc
> --path=/<>/build-deb/libkmod/docs/doc libkmod ../libkmod-docs.xml
> | Computing chunks...
> | Writing libkmod-libkmod.html for refentry(libkmod-libkmod)
> | Writing libkmod-libkmod-list.html for refentry(libkmod-libkmod-list)
> | Writing libkmod-libkmod-config.html for refentry(libkmod-libkmod-config)
> | Writing libkmod-libkmod-module.html for refentry(libkmod-libkmod-module)
> | Writing libkmod-libkmod-loaded.html for refentry(libkmod-libkmod-loaded)
> | Writing ch01.html for chapter
> | Writing api-index-full.html for index(api-index-full)
> | Writing index.html for book(index)
> | Writing libkmod.devhelp2 for book(index)
> | gtkdoc-fixxref --module=libkmod --module-dir=html
> --html-dir=/usr/share/gtk-doc/html
> | Package glib-2.0 was not found in the pkg-config search path.
> | Perhaps you should add the directory containing `glib-2.0.pc'
> | to the PKG_CONFIG_PATH environment variable
> | No package 'glib-2.0' found
> | Traceback (most recent call last):
> | File "/usr/bin/gtkdoc-fixxref", line 57, in
> | fixxref.Run(options)
> | File "/usr/share/gtk-doc/python/gtkdoc/fixxref.py", line 74, in Run
> | dir = common.GetModuleDocDir('glib-2.0')
> | File "/usr/share/gtk-doc/python/gtkdoc/common.py", line 104, in
> GetModuleDocDir
> | path = subprocess.check_output([config.pkg_config, '--variable=prefix',
> module_name], universal_newlines=True)
> | File "/usr/lib/python2.7/subprocess.py", line 219, in check_output
> | raise CalledProcessError(retcode, cmd, output=output)
> | subprocess.CalledProcessError: Command '['/usr/bin/pkg-config',
> '--variable=prefix', 'glib-2.0']' returned non-zero exit status 1
> | Makefile:667: recipe for target 'html-build.stamp' failed
> | make[3]: *** [html-build.stamp] Error 1
> | Makefile:2117: recipe for target 'all-recursive' failed
> | make[2]: *** [all-recursive] Error 1
> | Makefile:1170: recipe for target 'all' failed
> | make[1]: *** [all] Error 2
> | make[1]: Leaving directory '/<>/build-deb'
> | debian/rules:78: recipe for target '.stamp-build' failed
> | make: *** [.stamp-build] Error 2
> | dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
>
> The timing of the failure strongly suggests a relation to the
> gtk-doc/1.26-1 upload. Please reassign if appropriate.
Yes, this is a regression in gtk-doc 1.26. The old version handled missing
glib-2.0.pc, but the new version is using python which is stricter. I have
forwarded this upstream.
Cheers,
Emilio
Bug#875979: openssh-client: Please ship /usr/bin/scp in its own binary package
Package: openssh-client Version: 1:7.5p1-10 Severity: wishlist Hi there, OpenSSH's scp(1) binary can be used in client mode in combination with other SSH clients, or in sink mode in combination with another server. /usr/bin/scp is only linked against libc6, but to install it along with a more lightweight SSH server/client (Drobear for instance, cf. #495795) one currently needs to install openssh-client, which pulls 10.3MiB in 8 dependencies on a clean sid chroot, hence can be a blocker on small or embedded systems. Please consider shipping /usr/bin/scp in its own binary package instead; as per Colin's mail from debian-ssh@l.d.o [0]: > Package: openssh-client > Depends: openssh-scp > > Package: openssh-scp > Recommends: openssh-client | ssh-client > Breaks: openssh-client (<< first-version-without-scp) > Replaces: openssh-client (<< first-version-without-scp) Thanks for maintainer OpenSSH in Debian! -- Guilhem. [0] https://lists.debian.org/debian-ssh/2017/07/msg00019.html signature.asc Description: PGP signature
Bug#875978: ITP: diff-hl-el -- highlight uncommitted changes using VC
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: diff-hl-el Version : 1.8.4 Upstream Author : Dmitry Gutov * URL or Web page : https://github.com/dgutov/diff-hl URL : https://elpa.gnu.org/packages/diff-hl.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : highlight uncommitted changes using VC The package provides a `diff-hl-mode' Emacs mode, which highlights uncommitted changes on the side of the window (using the fringe, by default), and allows you to jump between the hunks and revert them selectively.
Bug#875977: libhdf5-100: Performs unaligned accesses on sparc64
Package: libhdf5-100
Version: 1.10.0-patch1+docs-3
Tags: upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org, Ghislain Vaillant
Control: affects -1 src:h5py
Hi,
Currently libhdf5-100 performs unaligned memory accesses on sparc64 in
certain cases, and this is causing the latest version of h5py to FTBFS
due to the test suite being killed with SIGBUS when doing vlen-related
tests (the tests in question being new in the latest upstream version).
On investigating, there are two issues:
1. NO_ALIGNMENT_RESTRICTIONS is being defined on sparc64. GCC is
sufficiently smart to notice that the test program run when
configuring is performing unaligned accesses, and so instead of
using the usual multi-byte load instructions (which require the
address to be aligned), it expands it out into individual byte
loads, and therefore the test actually succeeds. This is only
because GCC can statically determine that the address is unaligned,
and therefore tries to be helpful (since it knows using multi-byte
loads will never work), whereas for a general address it will assume
the address is aligned and emit a single multi-byte load.
Adding in a few volatile qualifiers in the important places ensures
that GCC can no longer statically prove the relevant addresses are
unaligned, and therefore it uses the normal multi-byte load
instructions and the test program will crash, so configure knows not
to define NO_ALIGNMENT_RESTRICTIONS.
2. Even with that fixed, H5T_vlen_reclaim_recurse needs fixing to
ensure it doesn't perform unaligned accesses when not supported.
With the attached patch, h5py's test suite now passes again. Please feel
free to forward this patch upstream if you deem it acceptable.
Regards,
James
--- a/config/cmake/ConversionTests.c
+++ b/config/cmake/ConversionTests.c
@@ -237,13 +237,13 @@ main ()
char *chp = "beefs";
char **chpp = malloc (2 * sizeof (char *));
-char **chpp2;
+char * volatile *chpp2;
hvl_t vl = { 12345, (void *) chp };
hvl_t *vlp;
-hvl_t *vlp2;
+hvl_t * volatile vlp2;
memcpy ((void *) ((char *) chpp + 1), &chp, sizeof (char *));
-chpp2 = (char **) ((char *) chpp + 1);
+chpp2 = (char * volatile *) (chpp + 1);
if (strcmp (*chpp2, chp)) {
free (chpp);
return 1;
@@ -252,7 +252,7 @@ main ()
vlp = malloc (2 * sizeof (hvl_t));
memcpy ((void *) ((char *) vlp + 1), &vl, sizeof (hvl_t));
-vlp2 = (hvl_t *) ((char *) vlp + 1);
+vlp2 = (hvl_t * volatile) ((char *) vlp + 1);
if (vlp2->len != vl.len || vlp2->p != vl.p) {
free (vlp);
return 1;
--- a/configure.ac
+++ b/configure.ac
@@ -3372,13 +3372,13 @@ AC_RUN_IFELSE([
], [
char *chp = "beefs";
char **chpp = malloc (2 * sizeof (char *));
-char **chpp2;
+char * volatile *chpp2;
hvl_t vl = { 12345, (void *) chp };
hvl_t *vlp;
-hvl_t *vlp2;
+hvl_t * volatile vlp2;
memcpy ((void *) ((char *) chpp + 1), &chp, sizeof (char *));
-chpp2 = (char **) ((char *) chpp + 1);
+chpp2 = (char * volatile *) (chpp + 1);
if (strcmp (*chpp2, chp)) {
free (chpp);
return 1;
@@ -3387,7 +3387,7 @@ AC_RUN_IFELSE([
vlp = malloc (2 * sizeof (hvl_t));
memcpy ((void *) ((char *) vlp + 1), &vl, sizeof (hvl_t));
-vlp2 = (hvl_t *) ((char *) vlp + 1);
+vlp2 = (hvl_t * volatile) ((char *) vlp + 1);
if (vlp2->len != vl.len || vlp2->p != vl.p) {
free (vlp);
return 1;
--- a/src/H5Tvlen.c
+++ b/src/H5Tvlen.c
@@ -1052,35 +1052,64 @@ H5T_vlen_reclaim_recurse(void *elem, con
case H5T_VLEN:
/* Recurse on the VL information if it's VL, compound, enum or
array, then free VL sequence */
if(dt->shared->u.vlen.type == H5T_VLEN_SEQUENCE) {
+void *p;
+size_t len;
+#ifdef H5_NO_ALIGNMENT_RESTRICTIONS
hvl_t *vl = (hvl_t *)elem;/* Temp. ptr to the vl info */
+p = vl->p;
+len = vl->len;
+#else
+hvl_t vl; /* The vl info */
+HDmemcpy(&vl, elem, sizeof(hvl_t));
+p = vl.p;
+len = vl.len;
+#endif
/* Check if there is anything actually in this sequence */
-if(vl->len!=0) {
+if(len!=0) {
/* Recurse if it's VL, array, enum or compound */
if(H5T_IS_COMPLEX(dt->shared->parent->shared->type)) {
void *off; /* offset of field */
/* Calculate the offset of each array element and
recurse on it */
-while(vl->len > 0) {
-off = ((uint8_t *)vl->p) + (vl->len - 1) *
dt->shared->parent->shared->size;
-
Bug#875959: vidia-graphics-drivers: port nvidia-prime from Ubuntu
On Sat, 2017-09-16 at 18:07 +0300, Vincas Dargis wrote: > I have tried (naively) `nvidia-prime` Ubuntu package installed in > Debian Testing, but it does not work: > > sudo prime-select nvidia > Info: the current GL alternatives in use are: [None, None] > Info: the current EGL alternatives in use are: [None, None] > Error: the installed packages do not support PRIME > Error: nvidia mode can't be enabled Hi, Personally speaking I'm not a super fan of nvidia-prime. I think power saving on a laptop is a very important concern, and the UIX of forcing a reboot/restart of X is really not very user friendly. Given I'm not going to use it, I cannot personally commit to maintain it properly if it were to be uploaded. Having said that, if anybody would like to commit to maintain and support the package I'm very happy to discuss sponsorship and provide help in that regard. Volunteers are always welcome :-) Hopefully one day, before I retire, Nvidia will provide a supported dynamic offload functionality... There is at least talk of a server side glvnd-like implementation, so there's hope. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#875976: luajit: Please enable mips64el packages
Source: luajit Version: 2.1.0~beta3+dfsg-2 Severity: normal libluajit-5.1-dev and libluajit-5.1-2 are currently missing mips64el in their Architecture list. I was able to successfully build the package on eller.d.o, modulo a new symbol. Is there anything preventing this from being enabled? ... dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libluajit-5.1-2/DEBIAN/symbols doesn't match completely debian/libluajit-5.1-2.symbols --- debian/libluajit-5.1-2.symbols (libluajit-5.1-2_2.1.0~beta3+dfsg-2.1_mips64el) +++ dpkg-gensymbolsBvCE33 2017-09-16 18:38:24.810880241 + @@ -1,4 +1,5 @@ libluajit-5.1.so.2 libluajit-5.1-2 #MINVER# + ccall_copy_struct@Base 2.1.0~beta3+dfsg-2.1 luaJIT_profile_dumpstack@Base 2.1.0~beta1+dfsg luaJIT_profile_start@Base 2.1.0~beta1+dfsg luaJIT_profile_stop@Base 2.1.0~beta1+dfsg dh_makeshlibs: failing due to earlier errors debian/rules:12: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 ┌─(2017-09-16 18:39:12) └[(sid_mips64el-dchroot)jamessan@eller] 0 % find debian/libluajit-5.1-dev debian/libluajit-5.1-dev debian/libluajit-5.1-dev/usr debian/libluajit-5.1-dev/usr/lib debian/libluajit-5.1-dev/usr/lib/mips64el-linux-gnuabi64 debian/libluajit-5.1-dev/usr/lib/mips64el-linux-gnuabi64/pkgconfig debian/libluajit-5.1-dev/usr/lib/mips64el-linux-gnuabi64/pkgconfig/luajit.pc debian/libluajit-5.1-dev/usr/lib/mips64el-linux-gnuabi64/libluajit-5.1.a debian/libluajit-5.1-dev/usr/lib/mips64el-linux-gnuabi64/libluajit-5.1.so debian/libluajit-5.1-dev/usr/include debian/libluajit-5.1-dev/usr/include/luajit-2.1 debian/libluajit-5.1-dev/usr/include/luajit-2.1/lua.h debian/libluajit-5.1-dev/usr/include/luajit-2.1/lua.hpp debian/libluajit-5.1-dev/usr/include/luajit-2.1/luaconf.h debian/libluajit-5.1-dev/usr/include/luajit-2.1/lualib.h debian/libluajit-5.1-dev/usr/include/luajit-2.1/lauxlib.h debian/libluajit-5.1-dev/usr/include/luajit-2.1/luajit.h debian/libluajit-5.1-dev/usr/share debian/libluajit-5.1-dev/usr/share/doc debian/libluajit-5.1-dev/usr/share/doc/libluajit-5.1-dev debian/libluajit-5.1-dev/usr/share/doc/libluajit-5.1-dev/changelog.Debian.gz debian/libluajit-5.1-dev/usr/share/doc/libluajit-5.1-dev/copyright -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#875975: kmod FTBFS: subprocess.CalledProcessError: Command '['/usr/bin/pkg-config', '--variable=prefix', 'glib-2.0']' returned non-zero exit status 1
Source: kmod
Version: 24-1
Severity: serious
kmod fails to build from source in unstable. The tail of the build log
is:
| cd html && gtkdoc-mkhtml $mkhtml_options
--path=/<>/build-deb/../libkmod/docs/doc
--path=/<>/build-deb/libkmod/docs/doc libkmod ../libkmod-docs.xml
| Computing chunks...
| Writing libkmod-libkmod.html for refentry(libkmod-libkmod)
| Writing libkmod-libkmod-list.html for refentry(libkmod-libkmod-list)
| Writing libkmod-libkmod-config.html for refentry(libkmod-libkmod-config)
| Writing libkmod-libkmod-module.html for refentry(libkmod-libkmod-module)
| Writing libkmod-libkmod-loaded.html for refentry(libkmod-libkmod-loaded)
| Writing ch01.html for chapter
| Writing api-index-full.html for index(api-index-full)
| Writing index.html for book(index)
| Writing libkmod.devhelp2 for book(index)
| gtkdoc-fixxref --module=libkmod --module-dir=html
--html-dir=/usr/share/gtk-doc/html
| Package glib-2.0 was not found in the pkg-config search path.
| Perhaps you should add the directory containing `glib-2.0.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'glib-2.0' found
| Traceback (most recent call last):
| File "/usr/bin/gtkdoc-fixxref", line 57, in
| fixxref.Run(options)
| File "/usr/share/gtk-doc/python/gtkdoc/fixxref.py", line 74, in Run
| dir = common.GetModuleDocDir('glib-2.0')
| File "/usr/share/gtk-doc/python/gtkdoc/common.py", line 104, in
GetModuleDocDir
| path = subprocess.check_output([config.pkg_config, '--variable=prefix',
module_name], universal_newlines=True)
| File "/usr/lib/python2.7/subprocess.py", line 219, in check_output
| raise CalledProcessError(retcode, cmd, output=output)
| subprocess.CalledProcessError: Command '['/usr/bin/pkg-config',
'--variable=prefix', 'glib-2.0']' returned non-zero exit status 1
| Makefile:667: recipe for target 'html-build.stamp' failed
| make[3]: *** [html-build.stamp] Error 1
| Makefile:2117: recipe for target 'all-recursive' failed
| make[2]: *** [all-recursive] Error 1
| Makefile:1170: recipe for target 'all' failed
| make[1]: *** [all] Error 2
| make[1]: Leaving directory '/<>/build-deb'
| debian/rules:78: recipe for target '.stamp-build' failed
| make: *** [.stamp-build] Error 2
| dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
The timing of the failure strongly suggests a relation to the
gtk-doc/1.26-1 upload. Please reassign if appropriate.
Helmut
Bug#873459: RFS: python-singa/1.1.1-1 [ITP]
On Mon, Aug 28, 2017 at 09:12:17AM +0800, Moaz Reyad wrote: > > I am looking for a sponsor for my package "python-singa" > > dget -x > https://mentors.debian.net/debian/pool/main/p/python-singa/python-singa_1.1.1-1.dsc Hi Moaz, your orig.tar.gz seems to contain the complete git history from upstream, which doesn't seem to useful. I suggest redoing the orig without the .git subdirectory. Kind Regards Andreas -- PGP-encrypted mails preferred PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624 signature.asc Description: PGP signature
Bug#875955: cme check dpkg warns on amd64 about unknown Build-Depends: libcam-dev [kfreebsd-any]
Hi,
> Don't worry,
"Don't worry" is not easy to implement near the end of a release week. {:)
> your packages are up to date :-)
Indeed:
/var/cache/apt/archives/libconfig-model-dpkg-perl_2.098_all.deb.deb
Sorry for the wrong Version header.
Have a nice day :)
Thomas
Bug#875974: libarchive13: out-of-bounds read in archive_read_format_rar_read_header()
Package: libarchive13 Version: 3.2.2-3.1 $ valgrind --quiet -- bsdtar -xf oob.rar ==1880== Invalid read of size 1 ==1880==at 0x4832FF0: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==1880==by 0x489B5E0: memcpy (string3.h:53) ==1880==by 0x489B5E0: read_header (archive_read_support_format_rar.c:1577) ==1880==by 0x489C347: archive_read_format_rar_read_header (archive_read_support_format_rar.c:932) ==1880==by 0x4873A54: _archive_read_next_header2 (archive_read.c:649) ==1880==by 0x4873B5B: _archive_read_next_header (archive_read.c:687) ==1880==by 0x10D384: read_archive (read.c:261) ==1880==by 0x10DCAC: tar_mode_x (read.c:112) ==1880==by 0x10C2BB: main (bsdtar.c:809) ==1880== Address 0x6ca726a is 0 bytes after a block of size 98 alloc'd ==1880==at 0x482E1FC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==1880==by 0x4830520: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==1880==by 0x489B451: read_header (archive_read_support_format_rar.c:1423) ==1880==by 0x489C347: archive_read_format_rar_read_header (archive_read_support_format_rar.c:932) ==1880==by 0x4873A54: _archive_read_next_header2 (archive_read.c:649) ==1880==by 0x4873B5B: _archive_read_next_header (archive_read.c:687) ==1880==by 0x10D384: read_archive (read.c:261) ==1880==by 0x10DCAC: tar_mode_x (read.c:112) ==1880==by 0x10C2BB: main (bsdtar.c:809) ==1880== bsdtar: Unknown file attributes from RAR file's host OS bsdtar: Error exit delayed from previous errors. Found using American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ -- System Information: Architecture: i386 Versions of packages libarchive13 depends on: ii libacl1 2.2.52-3+b1 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-17 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.3 ii liblzo2-2 2.08-1.2+b2 ii libnettle6 3.3-2 ii libxml2 2.9.4+dfsg1-4 ii zlib1g 1:1.2.8.dfsg-5 -- Jakub Wilk oob.rar Description: application/rar
Bug#875861: reproducible-check: uses full status json file instead of restricted one that hides unstable-only issues
tags 875861 + pending thanks Fixed in Git: https://anonscm.debian.org/git/collab-maint/devscripts.git/commit/?id=1ae5cf6dbd18c00bbe3061ce0017f03374f98d1b Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#823104: monkeysign: Twice confused by package description
Hi, so here's my take at improving the description, based on the current description in stretch: (I believe some lines are too long now, but left them as such for the sake of a better diff.) $ cat description.new Description-en: OpenPGP key signing and exchange for humans monkeysign is project to overhaul the OpenPGP keysigning experience and bring it closer to something that most primates can understand. . To achieve that it makes use of cheap digital cameras and the type of bar code known as a QRcode to provide a human-friendly yet still-secure keysigning experience. . No more reciting tedious strings of hexadecimal characters. And, you can build a little rogue's gallery of the people that you have met and exchanged keys with! . Monkeysign is also the name of it's commandline signing software, a caff replacement. Monkeyscan is the graphical user interface that scans qrcodes. $ diff -Nur description.orig description.new --- description.orig2017-09-16 19:49:45.21600 +0200 +++ description.new 2017-09-16 19:50:52.96500 +0200 @@ -1,8 +1,8 @@ Description-en: OpenPGP key signing and exchange for humans - monkeysign is a tool to overhaul the OpenPGP keysigning experience + monkeysign is a project to overhaul the OpenPGP keysigning experience and bring it closer to something that most primates can understand. . - The project makes use of cheap digital cameras and the type of bar + To achieve that it makes use of cheap digital cameras and the type of bar code known as a QRcode to provide a human-friendly yet still-secure keysigning experience. . @@ -10,6 +10,6 @@ can build a little rogue's gallery of the people that you have met and exchanged keys with! . - Monkeysign is the commandline signing software, a caff + Monkeysign is also the name of it's commandline signing software, a caff replacement. Monkeyscan is the graphical user interface that scans qrcodes. I'm not entirely happy with the last paragraph, mostly because the first three paragraphs make it sound like monkeyscan can do much more than just scanning. But maybe it cannot? (Also the third paragraph is still "out of style": the other paragraphs describe what monkeysign is, while this one is different: the first sentence has no subject, while the second one clearly and suddenly addresses the reader, you!) -- cheers, Holger signature.asc Description: Digital signature
Bug#875955: cme check dpkg warns on amd64 about unknown Build-Depends: libcam-dev [kfreebsd-any]
On Saturday, 16 September 2017 15:54:37 CEST you wrote:
> A bit astounding is the version number output of my cme copy:
>
> $ cme --version
> cme (App::Cme) version 1.022 (/usr/bin/cme)
>
> tracker.debian.org says it should be at least 2.098.
Don't worry, your packages are up to date :-)
cme is the CLI part of a Perl program that loads 2 libraries:
- Config::Model which is the core framework
- Config::Model::Dpkg which describes dpkg model is a way understandable by
Config::Model
These 3 parts are delivered on Debian with the following 3 packages:
$ dpkg -l cme libconfig-model{,-dpkg}-perl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++--===-===-=
ii cme 1.022-1 all Check
or edit configuration data with Config::Model
ii libconfig-model-dpkg-perl2.098 all editor
for Dpkg source files with validation
ii libconfig-model-perl 2.108-1 all module
for describing and editing configuration data
All the best
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#869714: NMU diff
Just uploaded this NMU to incoming. Fix tested and working on pettersson for buster live images. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Bug#875955: cme check dpkg warns on amd64 about unknown Build-Depends: libcam-dev [kfreebsd-any]
Note to self: May be I could add a check in cme so that madison is used (online debian server) to check package that are not known in the cache. (the arch restriction on the dependency is a good hint to search elsewhere than in the cache).
Bug#875973: RFS: glogic/2.6-3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "glogic" * Package name: glogic Version : 2.6-3 Upstream Author : Koichi Akabe * URL : https://launchpad.net/glogic * License : GPL-3 Section : electronics It builds those binary packages: glogic - graphical logic circuit simulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/glogic Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/glogic/glogic_2.6-3.dsc The package is also on git https://anonscm.debian.org/git/collab-maint/glogic.git Changes since the last upload: * New maintainer (Closes: #864582). + Changed Maintainer field in debian/control file. + Add copyright information for debian files in debian/copyright file. * Add Vcs-Browser and Vcs-Git on debian/control file. * Standards version 4.1.0. + Bumped compat level and debhelper to 10. * Aplied patch write by Jakob Haufe (Closes: #782557 LP: #1422501 LP: #1459027). * Aplied patch for add Keywords field to data/glogic.desktop.in file. * Aplied two patch to erase external HTML link. Regards, Innocent De Marchi
Bug#775490: Packaging looks hard
Hi, I had a look : it is now up to 2.3.2, and in the github repository, I see that in the libs/ directory there are quite a few things that really should be *external* deps. Some we have in Debian already ; but there is also: - glog, the google logging module ; - hoedown, "a revived sundown", a Markdown parser ; - libmv, which is "Extracted from Blender git repository under the intern/ folder" - libtess, a general polygon tesselation library ; - openFX_extensions, which is just two files and from the authors of Natron ; - openMVG, which are patched source files of another project ; - qhttpserver/http-parser, an asynchronous HTTP parser ; - qhttpserver, whose readme says it's not actively maintained and points a nicer project to use. So I think packaging this is quite hard. Snark on irc.debian.org
Bug#875972: cloudprint-service: cloudprintd.service should start after network-online.target
Package: cloudprint-service
Version: 0.14-8
Severity: normal
Dear Maintainer,
Since cloudprintd requires a working network connection and DNS
resolver, the systemd service file should declare After (and probably
Wants) of network-online.service. Although fa8d97e adds
network.service, this will be insufficient as it has little effect
during startup. For a full explanation, see:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#conceptsinsystemd
https://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
https://unix.stackexchange.com/q/126009
For reference, currently the service can be started before a network
connection is configured, resulting in errors such as the following:
Sep 16 09:48:05 servername cloudprintd[249]: Traceback (most recent call last):
Sep 16 09:48:05 servername cloudprintd[249]: File "/usr/sbin/cloudprintd",
line 11, in
Sep 16 09:48:05 servername cloudprintd[249]:
load_entry_point('cloudprint==0.14', 'console_scripts', 'cloudprint-cmd')()
Sep 16 09:48:05 servername cloudprintd[249]: File
"/usr/share/cloudprint/cloudprint/cloudprint.py", line 611, in main
Sep 16 09:48:05 servername cloudprintd[249]: auth.load()
Sep 16 09:48:05 servername cloudprintd[249]: File
"/usr/share/cloudprint/cloudprint/cloudprint.py", line 187, in load
Sep 16 09:48:05 servername cloudprintd[249]: self.refresh()
Sep 16 09:48:05 servername cloudprintd[249]: File
"/usr/share/cloudprint/cloudprint/cloudprint.py", line 169, in refresh
Sep 16 09:48:05 servername cloudprintd[249]: 'refresh_token':
self.refresh_token,
Sep 16 09:48:05 servername cloudprintd[249]: File
"/usr/lib/python2.7/dist-packages/requests/api.py", line 110, in post
Sep 16 09:48:05 servername cloudprintd[249]: return request('post', url,
data=data, json=json, **kwargs)
Sep 16 09:48:05 servername cloudprintd[249]: File
"/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
Sep 16 09:48:06 servername cloudprintd[249]: return
session.request(method=method, url=url, **kwargs)
Sep 16 09:48:06 servername cloudprintd[249]: File
"/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
Sep 16 09:48:06 servername cloudprintd[249]: resp = self.send(prep,
**send_kwargs)
Sep 16 09:48:06 servername cloudprintd[249]: File
"/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
Sep 16 09:48:06 servername cloudprintd[249]: r = adapter.send(request,
**kwargs)
Sep 16 09:48:06 servername cloudprintd[249]: File
"/usr/lib/python2.7/dist-packages/requests/adapters.py", line 487, in send
Sep 16 09:48:06 servername cloudprintd[249]: raise ConnectionError(e,
request=request)
Sep 16 09:48:06 servername cloudprintd[249]:
requests.exceptions.ConnectionError:
HTTPSConnectionPool(host='accounts.google.com', port=443): Max retries exceeded
with url: /o/oauth2/token (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3]
Temporary failure in name resolution',))
Sep 16 09:48:07 servername systemd[1]: cloudprintd.service: Main process
exited, code=exited, status=1/FAILURE
Sep 16 09:48:07 servername systemd[1]: cloudprintd.service: Unit entered failed
state.
Sep 16 09:48:07 servername systemd[1]: cloudprintd.service: Failed with result
'exit-code'.
Sep 16 10:19:52 servername systemd[1]: cloudprintd.service: Service hold-off
time over, scheduling restart.
Thanks,
Kevin
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-kevinoid1 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cloudprint-service depends on:
ii cloudprint 0.14-8
ii init-system-helpers 1.49
ii systemd 234-3
cloudprint-service recommends no packages.
cloudprint-service suggests no packages.
Bug#875887: reproducible-check: reporting some packages twice
tags 875887 + pending thanks Fixed in Git: https://anonscm.debian.org/git/collab-maint/devscripts.git/commit/?id=77064b0120ea4b1d701b9fc989701b1f19e7f643 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#875954: there should be patch somewhere...
Hi, according to the previous maintainer, this bug was fixed in version 0.75.0-15. However, I never verified that (I reported the bug back then) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812235 Bye Willi
Bug#875683: nvidia-graphics-drivers: libGL.so.1 missing with libglvnd libs
On Fri, 2017-09-15 at 02:45 +0200, Andreas Beckmann wrote: > On 15.09.2017 01:30, Luca Boccassi wrote: > > > Is it because libgl1-glvnd-nvidia-glx declares a conflict with > > > libgl1, > > > which libgl1-mesa-glx provides perhaps? > > That's the most likely case. > > I tried a hack (r7481) s.t. this should now work with mesa 13 in > testing. Some provides are disabled, so lib*-glvnd-nvidia* won't work > as > a substitute for the corresponding package from src:libglvnd. Thanks, this works on Stretch now. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#875396: haskell-vector: FTBFS on any-i386
Hello, Samuel Thibault, on lun. 11 sept. 2017 10:02:12 +0200, wrote: > In case you have not noticed, the haskell-vector fails the tests on i386 > ports (at least i386 and hurd-i386 failed, kfreebsd-i386 hasn't tried > yet). This is confirmed on kfreebsd-i386. Samuel
Bug#875971: Notifications window of 1px size
Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Mte90 To: Debian Bug Tracking System Package: plasma-framework Subject: plasma-framework: Notification of 1 px Message-ID: <150558100454.20611.15198692896007951365.reportbug@siduction> X-Mailer: reportbug 7.1.7 Date: Sat, 16 Sep 2017 18:56:44 +0200 X-Debbugs-Cc: Happening on KDE 5.37.0 but is already fixed on KDE 5.38.0 https://bugs.kde.org/show_bug.cgi?id=382340 Package: plasma-framework Version: 5.37.0-2 Severity: minor Tags: upstream Notification of 1px on KDE 5.37.0 fixed on 5.38.0 https://bugs.kde.org/show_bug.cgi?id=382340 -- System Information: Distributor ID: Ubuntu Description: Ubuntu, and definitely not Arch Linux Release: rolling Codename: sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.2-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages plasma-framework depends on: ii kio 5.37.0-2 ii kpackagetool5 5.37.0-2 ii libc6 2.24-17 ii libegl1-mesa 17.2.0-2 ii libgl1 0.2.999+git20170802-4 ii libgl1-mesa-glx 17.2.0-2 ii libkf5activities5 5.37.0-2 ii libkf5calendarevents5 5.37.0-2 ii libkf5configcore5 5.37.0-2 ii libkf5configgui5 5.37.0-2 ii libkf5coreaddons5 5.37.0-2 ii libkf5declarative5 5.37.0-2 ii libkf5i18n5 5.37.0-2 ii libkf5iconthemes5 5.37.0-2 ii libkf5kiocore5 5.37.0-2 ii libkf5kiowidgets5 5.37.0-2 ii libkf5notifications5 5.37.0-2 ii libkf5package5 5.37.0-2 ii libkf5plasma5 5.37.0-2 ii libkf5plasmaquick5 5.37.0-2 ii libkf5quickaddons5 5.37.0-2 ii libkf5widgetsaddons5 5.37.0-2 ii libkf5windowsystem5 5.37.0-2 ii libkf5xmlgui5 5.37.0-2 ii libqt5core5a 5.9.1+dfsg-9 ii libqt5gui5 5.9.1+dfsg-9 ii libqt5qml5 5.9.1-6 ii libqt5quick5 5.9.1-6 ii libqt5widgets5 5.9.1+dfsg-9 ii libqt5x11extras5 5.9.1-2+b1 ii libstdc++6 7.2.0-5 ii libx11-6 2:1.6.4-3 ii libxcb-composite0 1.12-1 ii libxcb-damage0 1.12-1 ii libxcb1 1.12-1 ii qml-module-org-kde-kconfig 5.37.0-2 ii qml-module-org-kde-kquickcontrols 5.37.0-2 ii qml-module-org-kde-kquickcontrolsaddons 5.37.0-2 ii qml-module-qtqml-models2 5.9.1-6 ii qml-module-qtquick-controls 5.9.1-2 ii qml-module-qtquick-controls2 5.9.1-3 ii qml-module-qtquick-templates2 5.9.1-3 plasma-framework recommends no packages. plasma-framework suggests no packages. -- no debconf information
Bug#823104: monkeysign: Twice confused by package description
On 2017-09-16 16:54:38, Holger Levsen wrote: > On Sat, Sep 16, 2017 at 12:35:53PM -0400, Antoine Beaupré wrote: >> Monkeysign is the project as a whole, and it has both a commandline >> interface and graphical interface. > > I see. That's a rather unfortunate naming decision, but at least I get it now. > (Using one name for two things is seldom a good idea…) > >> So it is assumed primates can use one or the other at least. > > btw, this is also slightly insulting: if one doesnt understand monkeysign one > is more stupid than a monkey. I'm not so sure I want to give this software > to people learning GPG or having trouble with it… I think you are being insulting to primates, personally. :p Besides, humans *are* primates... Keep in mind that "monkeysign" is named after "monkeysphere" which has a whole narrative around social studies of actual monkeys and they way they interact, and what that implies on human social relations as well. >> there's an issue open to merge the two binaries. [...] > > I think than it's better to wait for this and then fix the description, should > be much easier at that time! well, it's a hard fix to make at the software level :p >> keep in mind the description includes the goals of the project, which >> may or may not be completed... > > ah. Probably better to remove them from ethe description then, or clearly > mark them as (uncompleted) goals. again, i'd welcome an actual patch here... thanks a. -- A lot of people never use their initiative because no-one told them to. - Bansky
Bug#875440: Debian mirror debian.mur.at: out-of-date
Hi, debian.mur.at is up and current again. Please close the bug :) Cheers, -- \\ j.hofmueller DI-FR 10 bis 16 Uhr || TU-FR 10am to 4pm \\ phone: +43 (0)316 - 821 451 55 \\ mur.at Network Operation Center signature.asc Description: This is a digitally signed message part
Bug#853559: mozjs24: ftbfs with GCC-7
https://github.com/uhulinux/ub-dev/commit/22ddd3bb42c4b8fb43f7c7263acf86900ea97b2c -- R.
Bug#823104: monkeysign: Twice confused by package description
On Sat, Sep 16, 2017 at 12:35:53PM -0400, Antoine Beaupré wrote: > Monkeysign is the project as a whole, and it has both a commandline > interface and graphical interface. I see. That's a rather unfortunate naming decision, but at least I get it now. (Using one name for two things is seldom a good idea…) > So it is assumed primates can use one or the other at least. btw, this is also slightly insulting: if one doesnt understand monkeysign one is more stupid than a monkey. I'm not so sure I want to give this software to people learning GPG or having trouble with it… > there's an issue open to merge the two binaries. [...] I think than it's better to wait for this and then fix the description, should be much easier at that time! > keep in mind the description includes the goals of the project, which > may or may not be completed... ah. Probably better to remove them from ethe description then, or clearly mark them as (uncompleted) goals. -- cheers, Holger signature.asc Description: Digital signature
Bug#875945: fixed in at-spi2-core 2.26.0-2
Hello, Jeremy Bicha, on sam. 16 sept. 2017 11:31:48 -0400, wrote: > I added the dependency because it was required for at-spi2-core to > build when I packaged 2.25.90 or .91 but the dependency was correctly > made optional again before 2.26.0 with this commit: > > https://git.gnome.org/browse/at-spi2-core/commit/?id=aa3a11a1dece493 Yes, but this is bogus :) We don't want to disable xkb support, we just want to avoid the spurious dependency on xkbcommon, because xkb support is not there, but in libX11. Samuel
Bug#875970: ruby-fog-aws: FTBFS in experimental - test failures
Source: ruby-fog-aws Version: 1.4.1-1 Severity: serious Justification: fails to build from source Hi, the last upload of ruby-fog-aws to experimental did FTBFS: https://buildd.debian.org/status/fetch.php?pkg=ruby-fog-aws&arch=all&ver=1.4.1-1&stamp=1505064095&raw=0 ++ Compute::AWS | parsers | describe_images (compute, aws, parser) + AWS::EFS | file systems (aws, efs) tests/requests/efs/file_system_tests.rb success AWS::EFS | file systems (aws, efs) - has proper format tests/requests/efs/file_system_tests.rb undefined method `group_id' for nil:NilClass (NoMethodError) tests/requests/efs/file_system_tests.rb:84:in `block (3 levels) in ' tests/helpers/formats_helper.rb:92:in `block in formats' /usr/lib/ruby/vendor_ruby/shindo.rb:140:in `instance_eval' /usr/lib/ruby/vendor_ruby/shindo.rb:140:in `assert' /usr/lib/ruby/vendor_ruby/shindo.rb:116:in `test' tests/helpers/formats_helper.rb:85:in `formats' tests/requests/efs/file_system_tests.rb:82:in `block (2 levels) in ' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `instance_eval' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `tests' tests/requests/efs/file_system_tests.rb:6:in `block in ' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `instance_eval' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `tests' /usr/lib/ruby/vendor_ruby/shindo.rb:38:in `initialize' /usr/lib/ruby/vendor_ruby/shindo.rb:13:in `new' /usr/lib/ruby/vendor_ruby/shindo.rb:13:in `tests' tests/requests/efs/file_system_tests.rb:1:in `' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:61:in `load' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:61:in `block (2 levels) in run_in_thread' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:58:in `each' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:58:in `block in run_in_thread' ++ tests/requests/efs/file_system_tests.rb undefined method `group_id' for nil:NilClass (NoMethodError) tests/requests/efs/file_system_tests.rb:98:in `block (3 levels) in ' /usr/lib/ruby/vendor_ruby/fog/core/wait_for.rb:7:in `block in wait_for' /usr/lib/ruby/vendor_ruby/fog/core/wait_for.rb:6:in `loop' /usr/lib/ruby/vendor_ruby/fog/core/wait_for.rb:6:in `wait_for' tests/requests/efs/file_system_tests.rb:98:in `block (2 levels) in ' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `instance_eval' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `tests' tests/requests/efs/file_system_tests.rb:6:in `block in ' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `instance_eval' /usr/lib/ruby/vendor_ruby/shindo.rb:79:in `tests' /usr/lib/ruby/vendor_ruby/shindo.rb:38:in `initialize' /usr/lib/ruby/vendor_ruby/shindo.rb:13:in `new' /usr/lib/ruby/vendor_ruby/shindo.rb:13:in `tests' tests/requests/efs/file_system_tests.rb:1:in `' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:61:in `load' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:61:in `block (2 levels) in run_in_thread' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:58:in `each' /usr/lib/ruby/vendor_ruby/shindo/bin.rb:58:in `block in run_in_thread' An error occurred outside of a test rake aborted! Command failed with status (1): [export FOG_MOCK=true && shindont...] /<>/Rakefile:7:in `block in ' Tasks: TOP => test (See full trace by running task with --trace) debian/rules:18: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 Andreas
Bug#823104: monkeysign: Twice confused by package description
On 2017-09-16 16:10:13, Holger Levsen wrote: > Hi anarcat, > > sorry for not replying earlier… > > On Thu, Sep 01, 2016 at 02:46:40PM -0400, anarcat wrote: >> > I've read the package description and while I like the funny tone, I >> > also find it confusing for two reasons: >> > >> > 1.) >> > >> > monkeysign is a tool to overhaul the OpenPGP keysigning experience >> > and bring it closer to something that most primates can understand. >> > [...] >> > Monkeysign is the commandline signing software. >> > >> > -> most primates can't understand commandline software?! >> >> That is correct. What do you find find confusing here? > > how a command line tool is something most primates can understand. I thought > we > agreed most don't. Monkeysign is the project as a whole, and it has both a commandline interface and graphical interface. So it is assumed primates can use one or the other at least. >> > 2.) >> > >> > The project makes use of cheap digital cameras and the type of bar >> > code known as a QRcode to provide a human-friendly yet still-secure >> > keysigning experience. >> > [...] >> > Monkeysign is the commandline signing software, a caff >> > replacement. >> > >> > -> is it a caff replacement or does it rely on QRcodes? >> >> It's funny that you quote only the first sentence of that paragraph, the >> full paragraph is: >> >> Monkeysign is the commandline signing software, a caff >> replacement. Monkeyscan is the graphical user interface that scans >> qrcodes. >> >> So Monkeysign is the caff replacement, and monkeyscan is the GUI. > > yes, but the first two paragraphs are confusing: the very first word > of the description is "monkeysign" but now I believe it's used for both > monkeysign and monkeyscan(?). The 2nd paragraph OTOH seems to be about > monkeyscan(?) while it hasnt been mentioned yet. The 3rd paragraph > is probably about monkeyscan as well - this is totally unclear. there's an issue open to merge the two binaries. I just haven't figured out how best to do that right now, and i mostly use the commandline binary for now. keep in mind the description includes the goals of the project, which may or may not be completed... >> I would appreciate a suggestion on how to phrase this better. With the >> above, I am not sure I can find a proper formulation that would be >> satisfactory. > > better now? well, can you provide a patch or some more explicit wording? >> > Also it might be appropriate to explain that monkeysign is a >> > commandline tool, just like caff or pius… (and that only monkeyscan >> > does all the monkey QR stuff and therefore has a gui… >> Again, I felt that the last paragraph did exactly that. > > can one use monkeysign without monkeyscan? the other way round? yes, both. a. -- People in glass houses shouldn't throw stones. People in glass cities shouldn't fire missiles. - Bansky
Bug#875969: libopenshot: FTBFS: Timeline_Tests.cpp:158:1: error: Failure in Timeline_Check_Two_Track_Video
Package: libopenshot Version: 0.1.7+ds1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, libopenshot FTBFS on amd64 with test failures: https://buildd.debian.org/status/fetch.php?pkg=libopenshot&arch=amd64&ver=0.1.7%2Bds1-1%2Bb1&stamp=1502819536&raw=0 RUNNING ALL TESTS [AudioData @ 0x7ffc51a8b0a0] invalid NULL pointer for src[0] [AudioData @ 0x7fe633ffe630] invalid NULL pointer for src[0] [AudioData @ 0x7fe633ffe630] invalid NULL pointer for src[0] [AudioData @ 0x7ffc51a8ba40] invalid NULL pointer for src[0] [AudioData @ 0x7fe633ffe450] invalid NULL pointer for src[0] [AudioData @ 0x7ffc51a8ba40] invalid NULL pointer for src[0] [AudioData @ 0x7ffc51a8ba40] invalid NULL pointer for src[0] [libvpx @ 0x5634b47db880] v1.6.1 [webm @ 0x5634b45be660] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead. [webm @ 0x5634b45be660] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [webm @ 0x5634b45be660] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead. [webm @ 0x5634b45be660] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [AudioData @ 0x7fe633ffe630] invalid NULL pointer for src[0] [AudioData @ 0x7fe6337fd630] invalid NULL pointer for src[0] [AudioData @ 0x7fe6037fd450] invalid NULL pointer for src[0] [AudioData @ 0x7fe602ffc450] invalid NULL pointer for src[0] /<>/libopenshot-0.1.7+ds1/tests/Timeline_Tests.cpp:158:1: error: Failure in Timeline_Check_Two_Track_Video: Expected 23 but was 0 /<>/libopenshot-0.1.7+ds1/tests/Timeline_Tests.cpp:159:1: error: Failure in Timeline_Check_Two_Track_Video: Expected 190 but was 0 libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile FAILURE: 1 out of 79 tests failed (2 failures). Test time: 8.28 seconds. Andreas
Bug#875804: RFS: robocut/1.0.11-1-- Control program for Graphtec cutting plotters
On Thu, Sep 14, 2017 at 12:10:01PM -0400, Markus Schulz wrote: > > I am looking for a sponsor for my package "robocut": Hello Markus, I'm not a DD so can't sponsor your package, but here's a review: - Please consider using a dep5-style copyright file (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) - Please check if your package complies to the current version of the Debian Policy, which is version 4.1.0 (https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt) - There's an empty debian/robocut.menu file, it should be removed Cheers, Andreas -- PGP-encrypted mails preferred PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624 signature.asc Description: PGP signature
Bug#868804: xrdp: doesn't show the session after loggin with Xorg
After a lot of fruitless tinkering at the Linux end I came up with a pair of RDP files, one working and the other not. (After translation from UTF-8) the difference is: $ diff -u broken.txt working.txt --- broken.txt 2017-09-16 16:47:55.076161839 +0100 +++ working.txt 2017-09-16 16:47:58.500101132 +0100 @@ -1,48 +1,48 @@ screen mode id:i:2 use multimon:i:0 desktopwidth:i:1920 desktopheight:i:1200 session bpp:i:32 winposstr:s:0,1,334,51,1705,1038 compression:i:1 keyboardhook:i:2 audiocapturemode:i:0 videoplaybackmode:i:1 -connection type:i:6 +connection type:i:5 networkautodetect:i:0 bandwidthautodetect:i:1 displayconnectionbar:i:1 enableworkspacereconnect:i:0 disable wallpaper:i:0 allow font smoothing:i:1 allow desktop composition:i:1 disable full window drag:i:0 disable menu anims:i:0 disable themes:i:0 disable cursor setting:i:0 bitmapcachepersistenable:i:1 full address:s:wampoon.anjou.terraraq.org.uk audiomode:i:0 redirectprinters:i:1 redirectcomports:i:0 redirectsmartcards:i:1 redirectclipboard:i:1 redirectposdevices:i:0 autoreconnection enabled:i:1 authentication level:i:2 prompt for credentials:i:0 negotiate security layer:i:1 remoteapplicationmode:i:0 alternate shell:s: shell working directory:s: gatewayhostname:s: gatewayusagemethod:i:4 gatewaycredentialssource:i:4 gatewayprofileusagemethod:i:0 promptcredentialonce:i:0 use redirection server name:i:0 rdgiskdcproxy:i:0 kdcproxyname:s: gatewaybrokeringtype:i:0 drivestoredirect:s: username:s:richard https://technet.microsoft.com/en-us/library/gg607280(v=ws.10).aspx describes the connection types. 5 is 'WAN (10 Mbps or higher with high latency)' and 6 is 'LAN (10 Mbps or higher)'. (My actually connectivity is entirely local: I am connecting from Windows 10 to a Hyper-V VM running Debian, all on the same physical hardware.) Whether this is the same problem anyone else has, I don't know! ttfn/rjk
Bug#875968: RM: golang-eclipse-paho-dev [all] -- RoQA; NBS; now provided by golang-github-eclipse-paho.mqtt.golang-dev
Package: ftp.debian.org Severity: normal * package golang-eclipse-paho-dev in version 0.9.1+git20151201-1 is no longer built from source - suggested command: dak rm -m "[auto-cruft] no longer built from source" -s unstable -a all -p -R -b golang-eclipse-paho-dev - broken Build-Depends: fuji: golang-eclipse-paho-dev That B-D is not broken since the renamed package still provides the old name: Package: golang-github-eclipse-paho.mqtt.golang-dev Source: golang-eclipse-paho Version: 1.1.0-1 Installed-Size: 239 Maintainer: Debian Go Packaging Team Architecture: all Replaces: golang-eclipse-paho-dev Provides: golang-eclipse-paho-dev ... Andreas
Bug#875967: publicsuffix: FTBFS - UnicodeDecodeError during tests
Source: publicsuffix Version: 20170828.2009-1 Severity: serious Justification: fails to build from source Hi, the last upload of publicsuffix did FTBFS: https://buildd.debian.org/status/fetch.php?pkg=publicsuffix&arch=all&ver=20170828.2009-1&stamp=1504820937&raw=0 dpkg-buildpackage: info: source package publicsuffix dpkg-buildpackage: info: source version 20170828.2009-1 dpkg-buildpackage: info: source distribution unstable dpkg-source --before-build publicsuffix-20170828.2009 fakeroot debian/rules clean dh clean dh_auto_clean dh_autoreconf_clean dh_clean debian/rules build-indep dh build-indep dh_update_autotools_config -i dh_autoreconf -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>' dh_auto_build make -j4 make[2]: Entering directory '/<>' cd linter;\ ./pslint_selftest.sh; \ ./pslint.py ../public_suffix_list.dat; test_allowedchars: OK test_dots: OK test_duplicate: OK test_exception: OK test_punycode: OK test_section1: OK test_section2: OK test_section3: OK test_section4: OK test_spaces: OK test_wildcard: OK make[2]: Leaving directory '/<>' TZ=UTC touch -t 201708282009 public_suffix_list.dat psl-make-dafsa --input-format=psl --output-format=binary public_suffix_list.dat public_suffix_list.dafsa Traceback (most recent call last): File "/usr/bin/psl-make-dafsa", line 695, in sys.exit(main()) File "/usr/bin/psl-make-dafsa", line 689, in main outfile.write(converter(parser(infile, utf_mode, codecs), utf_mode, codecs)) File "/usr/bin/psl-make-dafsa", line 559, in parse_psl for line in infile: File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8046: ordinal not in range(128) debian/rules:14: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' debian/rules:5: recipe for target 'build-indep' failed make: *** [build-indep] Error 2 dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 Build finished at 2017-09-07T21:48:55Z Andreas
Bug#823104: monkeysign: Twice confused by package description
Hi anarcat, sorry for not replying earlier… On Thu, Sep 01, 2016 at 02:46:40PM -0400, anarcat wrote: > > I've read the package description and while I like the funny tone, I > > also find it confusing for two reasons: > > > > 1.) > > > > monkeysign is a tool to overhaul the OpenPGP keysigning experience > > and bring it closer to something that most primates can understand. > > [...] > > Monkeysign is the commandline signing software. > > > > -> most primates can't understand commandline software?! > > That is correct. What do you find find confusing here? how a command line tool is something most primates can understand. I thought we agreed most don't. > > 2.) > > > > The project makes use of cheap digital cameras and the type of bar > > code known as a QRcode to provide a human-friendly yet still-secure > > keysigning experience. > > [...] > > Monkeysign is the commandline signing software, a caff > > replacement. > > > > -> is it a caff replacement or does it rely on QRcodes? > > It's funny that you quote only the first sentence of that paragraph, the > full paragraph is: > > Monkeysign is the commandline signing software, a caff > replacement. Monkeyscan is the graphical user interface that scans > qrcodes. > > So Monkeysign is the caff replacement, and monkeyscan is the GUI. yes, but the first two paragraphs are confusing: the very first word of the description is "monkeysign" but now I believe it's used for both monkeysign and monkeyscan(?). The 2nd paragraph OTOH seems to be about monkeyscan(?) while it hasnt been mentioned yet. The 3rd paragraph is probably about monkeyscan as well - this is totally unclear. > I would appreciate a suggestion on how to phrase this better. With the > above, I am not sure I can find a proper formulation that would be > satisfactory. better now? > > Also it might be appropriate to explain that monkeysign is a > > commandline tool, just like caff or pius… (and that only monkeyscan > > does all the monkey QR stuff and therefore has a gui… > Again, I felt that the last paragraph did exactly that. can one use monkeysign without monkeyscan? the other way round? -- cheers, Holger signature.asc Description: Digital signature
Bug#875966: libarchive13: out-of-bounds read in archive_read_format_iso9660_read_header()
Package: libarchive13 Version: 3.2.2-3.1 $ gzip -d oob.iso.gz $ valgrind --quiet -- bsdtar -xOf oob.iso ==2945== Invalid read of size 1 ==2945==at 0x4891EAA: parse_file_info (archive_read_support_format_iso9660.c:1767) ==2945==by 0x48934D7: choose_volume (archive_read_support_format_iso9660.c:1115) ==2945==by 0x48934D7: archive_read_format_iso9660_read_header (archive_read_support_format_iso9660.c:1181) ==2945==by 0x4873A54: _archive_read_next_header2 (archive_read.c:649) ==2945==by 0x4873B5B: _archive_read_next_header (archive_read.c:687) ==2945==by 0x10D384: read_archive (read.c:261) ==2945==by 0x10DCAC: tar_mode_x (read.c:112) ==2945==by 0x10C2BB: main (bsdtar.c:809) ==2945== Address 0x6ca56c8 is 0 bytes after a block of size 65,536 alloc'd ==2945==at 0x482E2BC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2945==by 0x487ABEC: file_open (archive_read_open_filename.c:358) ==2945==by 0x4874DE9: archive_read_open1 (archive_read.c:479) ==2945==by 0x487B0F6: archive_read_open_filenames (archive_read_open_filename.c:152) ==2945==by 0x487B18C: archive_read_open_filename (archive_read_open_filename.c:109) ==2945==by 0x10D321: read_archive (read.c:223) ==2945==by 0x10DCAC: tar_mode_x (read.c:112) ==2945==by 0x10C2BB: main (bsdtar.c:809) ... Found using American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ -- System Information: Architecture: i386 Versions of packages libarchive13 depends on: ii libacl1 2.2.52-3+b1 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-17 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.3 ii liblzo2-2 2.08-1.2+b2 ii libnettle6 3.3-2 ii libxml2 2.9.4+dfsg1-4 ii zlib1g 1:1.2.8.dfsg-5 -- Jakub Wilk oob.iso.gz Description: application/gzip
Bug#875965: ruby-net-ssh: FTBFS - test failures
Source: ruby-net-ssh Version: 1:4.2.0-1 Severity: serious Justification: fails to build from source Hi, the last upload of ruby-net-ssh does FTBFS: https://buildd.debian.org/status/fetch.php?pkg=ruby-net-ssh&arch=all&ver=1%3A4.2.0-1&stamp=1505233484&raw=0 ┌──┐ │ Run tests for ruby2.3 from debian/ruby-tests.rake│ └──┘ RUBYLIB=/<>/debian/ruby-net-ssh/usr/lib/ruby/vendor_ruby:. GEM_PATH=debian/ruby-net-ssh/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all ruby2.3 -S rake -f debian/ruby-tests.rake /usr/bin/ruby2.3 -w "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_all.rb" "test/test_buffer.rb" "test/test_buffered_io.rb" "test/test_config.rb" "test/test_key_factory.rb" "test/test_known_hosts.rb" "test/test_proxy_jump.rb" -v /<>/test/transport/test_session.rb:305:in `': uninitialized constant Transport::TestSession::Logger (NameError) from /<>/test/transport/test_session.rb:15:in `' from /<>/test/transport/test_session.rb:13:in `' from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /<>/test/test_all.rb:11:in `block (2 levels) in ' from /<>/test/test_all.rb:11:in `each' from /<>/test/test_all.rb:11:in `block in ' from /<>/test/test_all.rb:3:in `chdir' from /<>/test/test_all.rb:3:in `' from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:15:in `block in ' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:4:in `select' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:4:in `' rake aborted! Command failed with status (1): [ruby -w "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_all.rb" "test/test_buffer.rb" "test/test_buffered_io.rb" "test/test_config.rb" "test/test_key_factory.rb" "test/test_known_hosts.rb" "test/test_proxy_jump.rb" -v] Tasks: TOP => default (See full trace by running task with --trace) ERROR: Test "ruby2.3" failed. Exiting. dh_auto_install: dh_ruby --install /<>/debian/ruby-net-ssh returned exit code 1 debian/rules:6: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 1 Andreas
Bug#875925: hdf5: interaction with nfs changed between jessie and stretch
Hi Frédéric, pi...@synchrotron-soleil.fr a écrit le 16/09/2017 à 07:25 : > Source: hdf5 > Version: 1.10.0-patch1+docs-3 > Severity: important > > Dear Maintainer, > > after upgrading my system from jessie to stretch, I could not read anymore my > hdf5 files located on > our nfs filesystem. > > I have an error like this > > Can not flock ... > > looking at the nfs documentation, I could find flock in the local_lock > options which is set to > "none" on my system. > > Since I red that some of these options can create conflict between lock > mechanism. > And because I am not the only one accessing these files (other system are > CentOS 5, 6). > I would like your opinion on the best way to solve this issue. Well, honestly I'm not at ease at all with file locking over NFS. Would you mind forwarding this question to upstream [1]? [1] h...@hdfgroup.org As I understand it, you should experience the very same problem using flock(1) shell command on these files. Is that correct? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#780202: gnome: Gnome freezes when click on "Activities" button
Package: gnome-core Version: 1:3.22+4 Followup-For: Bug #780202 I have the exact same situation running latest gnome. The thing is happenning in Wayland and Xorg no matter which I choose on a login screen. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-core depends on: ii adwaita-icon-theme3.26.0-1 ii at-spi2-core 2.26.0-1 ii baobab3.26.0-1 ii caribou 0.4.21-1+b1 ii chrome-gnome-shell9-1 ii chromium 60.0.3112.78-1 ii dconf-cli 0.26.0-2+b1 ii dconf-gsettings-backend 0.26.0-2+b1 ii eog 3.25.92-1 ii evince3.25.92-1 ii evolution-data-server 3.26.0-1 ii firefox 55.0.3-1 ii fonts-cantarell 0.0.25-2 ii gdm3 3.26.0-1 ii gedit 3.22.1-1 ii gkbd-capplet 3.26.0-2 ii glib-networking 2.54.0-1 ii gnome-backgrounds 3.26.1-1 ii gnome-bluetooth 3.26.1-1 ii gnome-calculator 3.25.92-1 ii gnome-characters 3.24.0-1 ii gnome-contacts3.25.4-1 ii gnome-control-center 1:3.24.3-1+b1 ii gnome-disk-utility3.26.0-1 ii gnome-font-viewer 3.25.90-1 ii gnome-keyring 3.20.1-1 ii gnome-logs3.26.0-1 ii gnome-menus 3.13.3-9 ii gnome-online-accounts 3.26.0-1 ii gnome-online-miners 3.26.0-1 ii gnome-session 3.26.0-1 ii gnome-settings-daemon 3.24.3-1 ii gnome-shell 3.22.3-3 ii gnome-shell-extensions3.22.2-2 ii gnome-software3.26.0-2 ii gnome-sushi 3.24.0-1 ii gnome-system-monitor 3.26.0-1 ii gnome-terminal3.26.0-1 ii gnome-themes-standard 3.22.3-1 ii gnome-user-guide 3.26.0-1 ii gnome-user-share 3.18.3-2 ii gsettings-desktop-schemas 3.24.1-1 ii gstreamer1.0-packagekit 1.1.6-2 ii gstreamer1.0-plugins-base 1.12.2-1 ii gstreamer1.0-plugins-good 1.12.2-1 ii gstreamer1.0-pulseaudio 1.12.2-1 ii gvfs-backends 1.30.4-1+b1 ii gvfs-bin 1.30.4-1+b1 ii gvfs-fuse 1.30.4-1+b1 ii libatk-adaptor2.26.0-1 ii libcanberra-pulse 0.30-3 ii libcaribou-gtk-module 0.4.21-1+b1 ii libcaribou-gtk3-module0.4.21-1+b1 ii libpam-gnome-keyring 3.20.1-1 ii libproxy1-plugin-gsettings0.4.14-3 ii nautilus 3.26.0-1 ii pulseaudio11.0-2 ii sound-theme-freedesktop 0.8-1 ii system-config-printer-common 1.5.9-2 ii system-config-printer-udev1.5.9-2 ii totem 3.26.0-1 ii tracker 2.0.0-3 ii vino 3.22.0-1 ii yelp 3.22.0-1 ii zenity3.24.0-1 Versions of packages gnome-core recommends: ii anacron 2.3-24 ii libproxy1-plugin-networkmanager 0.4.14-3 ii network-manager-gnome1.8.2-1 Versions of packages gnome-core suggests: pn gnome -- no debconf information
Bug#875945: fixed in at-spi2-core 2.26.0-2
I'm attaching a different way of fixing this issue. I added the dependency because it was required for at-spi2-core to build when I packaged 2.25.90 or .91 but the dependency was correctly made optional again before 2.26.0 with this commit: https://git.gnome.org/browse/at-spi2-core/commit/?id=aa3a11a1dece493 Thanks, Jeremy Bicha From 5ad4d7ed515f8bea31631ccca300a75dfcd793af Mon Sep 17 00:00:00 2001 From: Jeremy Bicha Date: Sat, 16 Sep 2017 11:22:30 -0400 Subject: [PATCH] Alternate fix for libxkbcommon linking issue --- debian/control | 2 -- debian/patches/avoid_xkb_dep | 19 --- debian/patches/series| 1 - 3 files changed, 22 deletions(-) delete mode 100644 debian/patches/avoid_xkb_dep diff --git a/debian/control b/debian/control index 3ffada4..e6d6a03 100644 --- a/debian/control +++ b/debian/control @@ -10,8 +10,6 @@ Build-Depends: debhelper (>= 9.20150628), dh-autoreconf, dbus, libdbus-1-dev, libglib2.0-dev, - libxkbcommon-x11-dev, - libxkbcommon-dev, libxtst-dev, libgirepository1.0-dev, intltool, gtk-doc-tools (>= 1.09), diff --git a/debian/patches/avoid_xkb_dep b/debian/patches/avoid_xkb_dep deleted file mode 100644 index e1cbb73..000 --- a/debian/patches/avoid_xkb_dep +++ /dev/null @@ -1,19 +0,0 @@ -reported on https://bugzilla.gnome.org/show_bug.cgi?id=787756 - - configure.ac |4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - a/configure.ac -+++ b/configure.ac -@@ -109,8 +109,8 @@ AS_IF([test "x$enable_x11" = xno], [ - # XKB (optional) - PKG_CHECK_MODULES(XKB, [xkbcommon-x11], [ - AC_DEFINE(HAVE_XKB, 1, [Define to use XKB]) -- X11_CFLAGS="$X11_CFLAGS $XKB_CFLAGS" -- X11_LIBS="$X11_LIBS $XKB_LIBS" -+ #X11_CFLAGS="$X11_CFLAGS $XKB_CFLAGS" -+ #X11_LIBS="$X11_LIBS $XKB_LIBS" - ], [:]) - ]) - diff --git a/debian/patches/series b/debian/patches/series index 2b38357..54237f3 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1 @@ at-spi-by-default -avoid_xkb_dep -- 2.14.1
Bug#875964: lintian: please warn about files in /usr/lib/pythonX.Y/dist-packages/tests/__init__.py
Package: lintian Version: 2.5.52 See https://bugs.debian.org/875962 I believe lintian should warn about these (and ISTR there is a already a tag for those kind of files). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#875963: python-azure: ships /usr/lib/python2.7/dist-packages/tests/__init__.py
Package: python-azure Version: 20170915+git-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, /usr/lib/python2.7/dist-packages/test/__init__.py is a way too generic name that shouldn't be used by any python module, since it can easily lead to file conflicts between packages (that is how I noticed it). cheers, Andreas
Bug#875962: python-oauth2client: ships /usr/lib/python2.7/dist-packages/tests/__init__.py
Package: python-oauth2client Version: 3.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, /usr/lib/python2.7/dist-packages/test/__init__.py is a way too generic name that shouldn't be used by any python module, since it can easily lead to file conflicts between packages (that is how I noticed it). cheers, Andreas
Bug#875813: rsync: missed "Number of deleted files"
Ok, the problem happens only with sshdroid (android ssh server application). With other pc clients everything ok :) well, is it a bug of rsync or of sshdroid? thanks Max On 09/14/2017 09:38 PM, Paul Slootman wrote: On Thu 14 Sep 2017, Max wrote: sshpass -p $PASS rsync --timeout=30 --bwlimit=$SPEED --log-file=$LOGFILE --stats --delete --size-only -vrz "/data" -e ssh root@$IP:data/ 2> /tmp/rsync-error >> $EXTLOG cat $EXTLOG Number of files: 1 (dir: 1) Number of created files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 35 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 74 Total bytes received: 53 sent 74 bytes received 53 bytes 254.00 bytes/sec total size is 0 speedup is 0.00 Thanks. Unfortunately I still cannot reproduce this: $ mkdir /tmp/data $ sshpass -p $PASS rsync --timeout=30 --bwlimit=10 --log-file=/tmp/rsync-log --stats --delete --size-only -vrz /tmp/data -e ssh root@localhost:data/ 2> /tmp/rsync-error >> /tmp/rsync-stdout $ cat /tmp/rsync-stdout sending incremental file list created directory data data/ Number of files: 1 (dir: 1) Number of created files: 1 (dir: 1) Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 55 Total bytes received: 54 sent 55 bytes received 54 bytes 72.67 bytes/sec total size is 0 speedup is 0.00 Rerunning the command (to match your output of the directory already being created) gives: Number of files: 1 (dir: 1) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 52 Total bytes received: 28 sent 52 bytes received 28 bytes 160.00 bytes/sec total size is 0 speedup is 0.00 Does the stderr or the log-file contain anything relevant? Paul -- Max
Bug#875922: perl: Please add arm64ilp32 support for bootstrapping/crossing
On 2017-09-16 15:36 +0300, Niko Tyni wrote: > On Sat, Sep 16, 2017 at 10:48:42AM +0100, Wookey wrote: > > On 2017-09-16 10:43 +0300, Niko Tyni wrote: > > > > (I can still include them in sid, but they aren't going to be functional > > > there as-is...) > > > > Yes. I filed this because it's how I got it done initially. I'll generate an > > update for the current perl version for you to ship with the package. > > > > (I'll be re-doing the bootstrap in unstable shortly). > > Okay, cool. It's nice to have the history so I'll import both once > you provide the 5.26 one. > > OOI are you hand-crafting these from existing ones or did you run > Configure natively? There isn't a native to run it on yet, so I'm hand-crafting from existing invariants, other arches and compiler outputs. There may be bugs - I have more checks to do. I now have a filesystem (perl was the last piece), so as soon as I get a kernel I hope to be able to run some native tests next week, including a perl config generation. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#875960: libarchive13: out-of-bounds read in lha_read_data_none()
Package: libarchive13 Version: 3.2.2-3.1 bsdtar crashes on the attached LHA file: $ bsdtar -xOf oob.lha Segmentation fault Valgrind says it's an out-of-bounds read when computing CRC: Invalid read of size 2 at 0x4894AA6: lha_crc16.part.6 (archive_read_support_format_lha.c:1739) by 0x4897727: lha_crc16 (archive_read_support_format_lha.c:1701) by 0x4897727: lha_read_data_none (archive_read_support_format_lha.c:1429) by 0x4897727: archive_read_format_lha_read_data (archive_read_support_format_lha.c:1390) by 0x4875B8C: archive_read_data_into_fd (archive_read_data_into_fd.c:101) by 0x10D5BB: read_archive (read.c:369) by 0x10DCAC: tar_mode_x (read.c:112) by 0x10C2BB: main (bsdtar.c:809) Address 0x6ca56ce is 6 bytes after a block of size 65,536 alloc'd at 0x482E2BC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by 0x487ABEC: file_open (archive_read_open_filename.c:358) by 0x4874DE9: archive_read_open1 (archive_read.c:479) by 0x487B0F6: archive_read_open_filenames (archive_read_open_filename.c:152) by 0x487B18C: archive_read_open_filename (archive_read_open_filename.c:109) by 0x10D321: read_archive (read.c:223) by 0x10DCAC: tar_mode_x (read.c:112) by 0x10C2BB: main (bsdtar.c:809) Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0x73B4000 at 0x4894ABC: lha_crc16.part.6 (archive_read_support_format_lha.c:1740) by 0x4897727: lha_crc16 (archive_read_support_format_lha.c:1701) by 0x4897727: lha_read_data_none (archive_read_support_format_lha.c:1429) by 0x4897727: archive_read_format_lha_read_data (archive_read_support_format_lha.c:1390) by 0x4875B8C: archive_read_data_into_fd (archive_read_data_into_fd.c:101) by 0x10D5BB: read_archive (read.c:369) by 0x10DCAC: tar_mode_x (read.c:112) by 0x10C2BB: main (bsdtar.c:809) Found using American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ -- System Information: Architecture: i386 Versions of packages libarchive13 depends on: ii libacl1 2.2.52-3+b1 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-17 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.3 ii liblzo2-2 2.08-1.2+b2 ii libnettle6 3.3-2 ii libxml2 2.9.4+dfsg1-4 ii zlib1g 1:1.2.8.dfsg-5 -- Jakub Wilk oob.lha Description: application/lha
Bug#875959: vidia-graphics-drivers: port nvidia-prime from Ubuntu
I have tried (naively) `nvidia-prime` Ubuntu package installed in Debian Testing, but it does not work: sudo prime-select nvidia Info: the current GL alternatives in use are: [None, None] Info: the current EGL alternatives in use are: [None, None] Error: the installed packages do not support PRIME Error: nvidia mode can't be enabled
Bug#875929: acetoneiso: should it be removed from Debian
Hi Mattia, The program is dead upstream and I have been maintainting (the bare minimum) on my own. I just saw that some months ago, people from Redhat ported it to Qt5. I'll see what I can get from there, in order to include in a new upload. For these reasons, I would prefer if the package is not removed for now, in order to have enough time to fix the issues. Kind regards, Nikos -- =Do- N.AND
Bug#875961: wireshark: Capture is disabled and filter selection dropdown is red
Package: wireshark Version: 2.2.6+g32dac6a-2 Severity: important Dear Maintainer, What led up to the situation: Installing wireshark and trying to use it to capture tcp/ip traffic. What exactly did I do: 1. Installed wireshark with "apt-get install wireshark" 2. Answered "Yes" to the question whether members of the wireshark group should be allowed to run wireshark 3. Started wireshark as root, received the following warning dialog on startup: Lua: error during loading [string "/usr/share/wireshark/init.lua"]: 44: dofile has been disabled due to running wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running wireshark as an unprivleged user 4. Clicked OK in the dialog 5. The menu entry Capture->Start was disabled 6. Selected menu entry Capture->Options... 7. The "Start" button was disabled 8. Selecting something in the filter dropdown caused the dropdown to turn red, and the "Start" button was disabled 9. Clicked the "Manage Interfaces" button, all interfaces were selected in the "Manage Interfaces (as superuser)" dialog 10. Stopped wireshark started as root 11. Added my regular user to the group wireshark with "adduser sb wireshark" 12. Started wireshark as my own user 13. The behaviour was the same as for root, ie. the menu "Capture->Start" was disabled, the "Start" button was disabled in the dialog opened by "Capture->Options...", and the filter selec dropdown turned red when a filter was selected 14. Logged out of the MATE desktop and logged in again 15. Started wireshark as my own user 16. The behaviour was the same as before logging out and back in, ie. the menu "Capture->Start" was disabled, the "Start" button was disabled in the dialog opened by "Capture->Options...", and the filter selec dropdown turned red when a filter was selected 17. Typed "newgroup wireshark" in a command line window running as my regular user 18. Started wireshark from the window I had typed "newgroup" in 19. The behaviour was the same as in my previous attempts at starting wireshark, ie. the menu "Capture->Start" was disabled, the "Start" button was disabled in the dialog opened by "Capture->Options...", and the filter selec dropdown turned red when a filter was selected The outcome of the described action: I was unable to capture tcp/ip traffic with wireshark Expected outcome: I had expected to be able to start wireshark, either as root or as my own user, to be able to capture network traffic for debugging. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wireshark depends on: ii wireshark-qt 2.2.6+g32dac6a-2 wireshark recommends no packages. wireshark suggests no packages. -- no debconf information
Bug#875813: rsync: missed "Number of deleted files"
what else can I do? I tried delete-during, delete-before, etc same problem Max On 09/14/2017 09:38 PM, Paul Slootman wrote: On Thu 14 Sep 2017, Max wrote: sshpass -p $PASS rsync --timeout=30 --bwlimit=$SPEED --log-file=$LOGFILE --stats --delete --size-only -vrz "/data" -e ssh root@$IP:data/ 2> /tmp/rsync-error >> $EXTLOG cat $EXTLOG Number of files: 1 (dir: 1) Number of created files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 35 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 74 Total bytes received: 53 sent 74 bytes received 53 bytes 254.00 bytes/sec total size is 0 speedup is 0.00 Thanks. Unfortunately I still cannot reproduce this: $ mkdir /tmp/data $ sshpass -p $PASS rsync --timeout=30 --bwlimit=10 --log-file=/tmp/rsync-log --stats --delete --size-only -vrz /tmp/data -e ssh root@localhost:data/ 2> /tmp/rsync-error >> /tmp/rsync-stdout $ cat /tmp/rsync-stdout sending incremental file list created directory data data/ Number of files: 1 (dir: 1) Number of created files: 1 (dir: 1) Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 55 Total bytes received: 54 sent 55 bytes received 54 bytes 72.67 bytes/sec total size is 0 speedup is 0.00 Rerunning the command (to match your output of the directory already being created) gives: Number of files: 1 (dir: 1) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 52 Total bytes received: 28 sent 52 bytes received 28 bytes 160.00 bytes/sec total size is 0 speedup is 0.00 Does the stderr or the log-file contain anything relevant? Paul -- Max
