Bug#505857: debian-watch-file-should-mangle-version doesn't detect dversionmangle=auto
Version: 2.5.113 Hi, Lintian also doesn't detect dversionmangle=auto in debian/watch and reports a warning for this (see [2]). Thanks, Bertrand [2] https://salsa.debian.org/games-team/7kaa/blob/master/debian/watch
Bug#914031: (no subject)
The first issue is fixed upstream [0] and is part of the just release v3.21. The patch to fix the second [1] was rejected though. Which means this can be closed. [0] https://source.winehq.org/git/wine.git/commitdiff/2dfff7e63c4fc6f97e83df448a2c2b8c4b9eedd5 [1] https://www.winehq.org/pipermail/wine-devel/2018-November/135680.html
Bug#895123: libsdl2-2.0-0: This is normally a bug in some application using the D-Bus library.
Sorry, I assumed the bugtracking system gathered all needed information. The problem appears on x86_64 when linking a -m32 compiled application against system provided libsdl2. On 10/20/18 12:57 PM, Manuel A. Fernandez Montecelo wrote: Control: tags -1 + unreproducible moreinfo Hi, 2018-04-07 10:50 Smirftsch: Package: libsdl2-2.0-0 Version: i386 Severity: important This bug does not contain any description of the problem, can you please provide one? Otherwise this can be closed in a few weeks. Cheers.
Bug#914511: Please enable the "virtio-rng" driver in "cloud" kernels
Package: linux-image-cloud-amd64 Version: 4.18+99 The "HW_RANDOM_VIRTIO" configuration setting is not currently enabled in the "cloud" flavour of kernel images. KVM virtual machines set up by virt-manager (and possibly virt-install, I'm not sure) come with a virtual random device like that by default, and would benefit from the driver being available if they need a lot of randomness.
Bug#891294: plasma-discover: Discover->settings->software sources does nothing
Package: plasma-discover Version: 5.14.3-1 Followup-For: Bug #891294 Still present in 5.14.3 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-discover depends on: ii appstream0.12.3-1 ii apt-config-icons 0.12.3-1 ii kio 5.51.0-1 ii libappstreamqt2 0.12.3-1 ii libc62.27-8 ii libkf5attica55.51.0-1 ii libkf5configcore55.51.0-1 ii libkf5configwidgets5 5.51.0-1 ii libkf5coreaddons55.51.0-1 ii libkf5crash5 5.51.0-1 ii libkf5dbusaddons55.51.0-1 ii libkf5i18n5 5.51.0-1 ii libkf5itemmodels55.51.0-1 ii libkf5kiocore5 5.51.0-1 ii libkf5kiowidgets55.51.0-1 ii libkf5newstuffcore5 5.51.0-1 ii libkf5notifications5 5.51.0-1 ii libkf5service-bin5.51.0-1 ii libkf5service5 5.51.0-1 ii libkf5widgetsaddons5 5.51.0-1 ii libkf5xmlgui55.51.0-1 ii libpackagekitqt5-1 1.0.1-1 ii libqt5core5a 5.11.2+dfsg-7 ii libqt5dbus5 5.11.2+dfsg-7 ii libqt5gui5 5.11.2+dfsg-7 ii libqt5network5 5.11.2+dfsg-7 ii libqt5qml5 5.11.2-3 ii libqt5quick5 5.11.2-3 ii libqt5widgets5 5.11.2+dfsg-7 ii libqt5xml5 5.11.2+dfsg-7 ii libstdc++6 8.2.0-10 ii packagekit 1.1.11-1 ii plasma-discover-common 5.14.3-1 ii qml-module-org-kde-kcoreaddons 5.51.0-1 ii qml-module-org-kde-kirigami2 5.51.0-1 ii qml-module-org-kde-kquickcontrols5.51.0-1 ii qml-module-org-kde-kquickcontrolsaddons 5.51.0-1 ii qml-module-org-kde-qqc2desktopstyle 5.51.0-1 ii qml-module-qtquick-dialogs 5.11.2-2 Versions of packages plasma-discover recommends: ii apt-config-icons-large 0.12.3-1 ii software-properties-kde 0.96.20.2-1 Versions of packages plasma-discover suggests: pn apt-config-icons-hidpi pn plasma-discover-backend-flatpak -- no debconf information
Bug#909188: what would the fix for this look like?
Am I imagining right that you're imagining that the startup process is currently Instance : (add account) and you're interpreting that to mean Instance : __ (add a new account) rather than Instance: __ (Add existing account) (which is what it actually is)? In which case startup should ask [add new account] [add existing account] a) then, if you click existing account give you two more options: i) log in by web interface (as normal) ii) log in here then if you choose (i) it sends you to the web browser (as normal) if you choose (ii) it asks you for a username, then password, then (login) (this should be doable with the mastodon API) b) then, if you click 'new account' walk you through the steps of creating a new account, perhaps offering a list of instances, choose a username / accept TOS, etc etc ... Does that sound right?
Bug#914510: [npm] contains unnecessary embedded copies
Package: npm Version: 5.8.0+ds6-2 Severity: normal --- Please enter the report below this line. --- According to this report: https://dedup.debian.net/binary/npm it should be possible to skip embedding of: - node-uuid - node-xdg-basedir - node-uid-number - node-libnpx Additionally cmd-shim and read-cmd-shim are only required on Windows and it should be possible to patch them away. --- System information. --- Architecture: Kernel: Linux 4.18.0-2-amd64 Debian Release: buster/sid 500 testing-debug debug.mirrors.debian.org 500 testing mi.mirror.garr.it 500 stable packages.microsoft.com --- Package information. --- Depends (Version) | Installed ===-+-= nodejs (>= 6.11~) | 8.11.2~dfsg-1 ca-certificates | 20170717 node-abbrev (>= 1.1.1~) | 1.1.1-1 node-ansi-regex (>= 3.0~) | 3.0.0-1 node-ansistyles (>= 0.1.3~) | 0.1.3-1 node-aproba (>= 1.2~) | 1.2.0-1 node-archy(>= 1.0~) | 1.0.0-1 node-cacache (>= 10.0.4~) | 10.0.4-1 node-bluebird (>= 3.5.1~) | 3.5.1+dfsg2-2 node-call-limit (>= 1.1~) | 1.1.0-1 node-chownr (>= 1.0.1~) | 1.1.1-1 node-config-chain (>= 1.1.11~) | 1.1.11-1 node-detect-indent(>= 5.0~) | 5.0.0-1 node-detect-newline (>= 2.1~) | 2.1.0-1 node-editor (>= 1.0~) | 1.0.0-1 node-fs-vacuum (>= 1.2.10~) | 1.2.10-2 node-fs-write-stream-atomic(>= 1.0.10~) | 1.0.10-4 node-glob (>= 7.1.2~) | 7.1.3-1 node-graceful-fs (>= 4.1.11~) | 4.1.11-1 node-has-unicode(>= 2.0.1~) | 2.0.1-2 node-hosted-git-info (>= 2.6~) | 2.7.1-1 node-iferr (>= 0.1.5~) | 1.0.2-1 node-inflight (>= 1.0.6~) | 1.0.6-1 node-inherits (>= 2.0.3~) | 2.0.3-1 node-ini(>= 1.3.5~) | 1.3.5-1 node-npm-package-arg| 6.0.0-2 node-promzard | 0.3.0-1 node-jsonstream (>= 1.3.2~) | 1.3.2-1 node-json-parse-better-errors (>= 1.0.1~) | 1.0.2-2 node-lazy-property(>= 1.0~) | 1.0.0-3 node-libnpx(>= 10.0.1~) | 10.2.0-2 node-lockfile (>= 1.0.3~) | 1.0.4-1 node-lru-cache (>= 4.1.1~) | 4.1.1-2 node-mississippi (>= 3.0~) | 3.0.0-1 node-mkdirp (>= 0.3.3) | 0.5.1-1 node-move-concurrently (>= 1.0.1~) | 1.0.1-2 node-nopt | 3.0.6-3 node-normalize-package-data (>= 2.4~) | 2.4.0-1 node-gyp(>= 3.6.2~) | 3.8.0-1 node-resolve-from (>= 4.0~) | 4.0.0-1 node-encoding | 0.1.12-2 node-errno | 0.1.4-1 node-npmlog (>= 4.1.2~) | 4.1.2-1 node-once (>= 1.4~) | 1.4.0-2 node-opener (>= 1.4.3~) | 1.4.3-1 node-osenv (>= 0.1.5~) | 0.1.5-1 node-path-is-inside (>= 1.0.2~) | 1.0.2-1 node-promise-inflight (>= 1.0.1~) | 1.0.1-1 node-ansi | 0.3.0-2 node-qw (>= 1.0.1~) | 1.0.1-1 node-read (>= 1.0.7~) | 1.0.7-1 node-read-package-json (>= 2.0.13~) | 2.0.13-1 node-request (>= 2.83~) | 2.88.1-2 node-retry (>= 0.10.1~) | 0.10.1-1 node-rimraf (>= 2.6.2~) | 2.6.2-1 node-safe-buffer(>= 5.1.1~) | 5.1.2-1 node-semver (>= 5.5~) | 5.5.1-1 node-sha(>= 2.0.1~) | 2.0.1-1 node-slide (>= 1.1.6~) | 1.1.6-2 node-sorted-object (>= 2.0.1~) | 2.0.1-1 node-from2 | 2.3.0-1 node-stream-iterate | 1.2.0-4 node-ssri (>= 5.2.4~) | 5.2.4-2 node-strip-ansi (>= 4.0~) | 4.0.0-1 node-tar (>= 4.4~) | 4.4.6+ds1-3 node-text-table (>= 0.2~) | 0.2.0-2 node-uid-number (>= 0.0.6~) | 0.0.6-1 node-unique-filename (>= 1.1~) | 1.1.0+ds-2 node-unpipe (>= 1.0~) | 1.0.0-1 node-boxen (>= 1.2.1~) | 1.2.2-1 node-import-lazy| 3.0.0.REALLY.2.1.0-1 node-is-npm (>= 1.0~) |
Bug#914509: [request] contains unnecessary embedded copy of node-uuid
Package: request Version: 2.88.1-2 Severity: normal --- Please enter the report below this line. --- This package contains an embedded copy of node-uuid 3.3.2 which is unnecessary now that we have it in the archive: https://packages.debian.org/sid/node-uuid The embedded copy should be removed and a dependency on node-uuid added. --- System information. --- Architecture: Kernel: Linux 4.18.0-2-amd64 Debian Release: buster/sid 500 testing-debug debug.mirrors.debian.org 500 testing mi.mirror.garr.it 500 stable packages.microsoft.com --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#909186: fix
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
This patch fixes the issue without the use of external tools like
xfvb-run or whatever, by taking the code that does --help and quits
moving it before the initialization of the Gtk stuff, which seems to
work.
Incidentally, this is one thing that is keeping tootle from building
reproducibly, so this is a reproducibility bug.
makes it no longer check for xorg BEFORE --help
--- a/src/Application.vala
+++ b/src/Application.vala
@@ -41,8 +41,7 @@
}
public static int main (string[] args) {
-Gtk.init (ref args);
-
+
try {
var opt_context = new OptionContext ("- Options");
opt_context.add_main_entries (app_options, null);
@@ -51,12 +50,16 @@
catch (GLib.OptionError e) {
warning (e.message);
}
+
+Gtk.init (ref args);
+
app = new Application ();
return app.run (args);
}
protected override void startup () {
+
base.startup ();
Granite.Services.Logger.DisplayLevel = Granite.Services.LogLevel.INFO;
Bug#856128:
Hi, The upstream author of CUPS-PDF recently agreed to publish package signatures for future releases. While I share the sentiment of the reporting party, the specific point regarding CUPS-PDF may be moot. Thank you! Kind regards, Felix Lechner
Bug#914508: tootle: Startup error is confusing if your web browser is broken
Package: tootle
Version: 0.2.0-1
Severity: normal
Tags: patch
Dear Maintainer,
Scenario: you have a web browser installed, but GLib does not know about it.
(For example, elinks.)
1) You start tootle
2) enter in the instance name
3) hit connect
what happens:
4) an error message comes up, "Operation not supported"
and in the console (which most tootle users may not know is there) there is a
error message printed.
what should happen:
The user should be told how to actually get the information tootle needs in
order to work (ie the API key)
This patch adds a error dialog box so that when you try to connect, you are
told to visit a website,
which gets you a API key, so you can continue using tootle.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tootle depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.30.1-1
ii elementary-xfce-icon-theme 0.13.1-1
ii libc62.27-8
ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6
ii libgee-0.8-2 0.20.1-1
ii libglib2.0-0 2.58.1-2
ii libgranite5 5.2.1-1
ii libgtk-3-0 3.24.1-2
ii libjson-glib-1.0-0 1.4.4-1
ii libsoup2.4-1 2.64.1-3
tootle recommends no packages.
tootle suggests no packages.
-- no debconf information
tells user what they need to do next in case web browser problems
--- a/src/Desktop.vala
+++ b/src/Desktop.vala
@@ -8,7 +8,16 @@
catch (GLib.Error e){
warning ("Can't open %s: %s", uri, e.message);
app.error (_("Error"), e.message);
+ /*
+This happens if you don't have a web browser installed where
+Gtk can see it.
+ */
+ if (e.message == "Operation not supported")
+ {
+ app.error (_("Go to the following in a web browser:\n\n"+uri),"");
+ }
}
+
}
// Copy a string to the clipboard
Bug#914507: tootle: lots of compiler warnings
Package: tootle
Version: 0.2.0-1
Severity: minor
Tags: patch
Dear Maintainer,
When debugging an entirely unrelated problem (wait for it), I got annoyed at
the
compiler warnings and wrote some code to deal with all 20 of them.
There's 4 main types of warnings this patch will fix:
1) Asynchronous calls that were being invoked in an obsolete way - they were
implicitly invoking
'begin', made this call explicit
2) Some code was throwing exceptions (at least as far as the compiler was
concerned), and was not catching
it. Wrote some exception try/catch blocks to catch them. Was kind of strict
in terms of erroring
out instead of warning when this happened - if it turns out these exceptions
come out in practice, though
the scope of the exceptions and whether or not they are error/warnings would be
the first thing to check.
So far I haven't triggered them.
3) Some code would never be executed, as it occurs after the program is shut
down. Removed it.
4) (probably the most contentious) some code was using obsolete APIs, changed
or removed it.
Previously:
../../src/Widgets/ImageToggleButton.vala:18.9-18.26: warning:
Gtk.Button.set_focus_on_click has been deprecated since 3.20
../../src/Html.vala:4.24-4.74: warning: unhandled error `GLib.RegexError'
var all_tags = new Regex("<(.|\n)*?>", RegexCompileFlags.CASELESS);
^^^
../../src/Html.vala:5.16-5.51: warning: unhandled error `GLib.RegexError'
return all_tags.replace(content, -1, 0, "");
../../src/Html.vala:16.27-16.98: warning: unhandled error `GLib.RegexError'
var html_params = new Regex("(class|target|rel)=\"(.|\n)*?\"",
RegexCompileFlags.CASELESS);
../../src/Html.vala:17.26-17.64: warning: unhandled error `GLib.RegexError'
var simplified = html_params.replace(divided, -1, 0, "");
^^^
../../src/Notificator.vala:118.9-118.45: warning: unhandled error `GLib.Error'
parser.load_from_data (sanitized, -1);
^
../../src/Notificator.vala:85.9-85.39: warning: unhandled error `GLib.Error'
parser.load_from_data (msg, -1);
^^^
../../src/Notificator.vala:63.9-63.13: warning: implicit .begin is deprecated
../../src/Watchlist.vala:98.13-98.29: warning: implicit .begin is deprecated
../../src/InstanceAccount.vala:36.9-36.25: warning: implicit .begin is
deprecated
../../src/ImageCache.vala:120.30-120.91: warning: unhandled error `GLib.Error'
var pixbuf = new Gdk.Pixbuf.from_stream_at_scale (stream, size,
size, true);
^^
../../src/Network.vala:129.26-129.87: warning: unhandled error `GLib.Error'
var pixbuf = new Gdk.Pixbuf.from_stream_at_scale (stream, size,
size, true);
^^
../../src/Views/TimelineView.vala:175.9-175.25: warning: implicit .begin is
deprecated
../../src/Dialogs/NewAccountDialog.vala:128.24-128.42: warning: unhandled error
`GLib.Error'
var root = network.parse (msg);
^^^
../../src/Network.vala:150.26-150.60: warning: unhandled error `GLib.Error'
var pixbuf = new Gdk.Pixbuf.from_stream (stream);
^^^
../../src/Network.vala:171.26-171.87: warning: unhandled error `GLib.Error'
var pixbuf = new Gdk.Pixbuf.from_stream_at_scale (stream, size,
size, true);
^^
../../src/Widgets/AttachmentWidget.vala:95.28-95.47: warning: unhandled error
`GLib.Error'
var root = network.parse (mess);
../../src/Dialogs/PostDialog.vala:40.23-40.37: warning:
Gtk.Dialog.get_action_area has been deprecated since 3.12
../../src/Dialogs/PostDialog.vala:42.9-42.23: warning:
Gtk.Dialog.get_action_area has been deprecated since 3.12
../../src/Widgets/AttachmentWidget.vala:105.13-105.98: warning: unreachable
code detected
app.error (_("File read error"), _("Can't read file %s: %s").printf
(uri, e.message));
^^
Compilation succeeded - 20 warning(s)
Now: there's no more warnings.
This is my first hand at vala, so hopefully this helps and is sensible...
Jeff Cliff
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8
Bug#914506: python3-wget: Unneeded depends on python-urllib3
Package: python3-wget
Version: 3.2-1
Severity: normal
python3-wget has the following in it's Depends:
Depends: python-urllib3, ${misc:Depends}, ${python3:Depends}
Unfortunately, python-urllib3 is both wrong and unnecessary. It is wrong
because a python3 package needs to depend on the python3 version (e.g.
python3-urllib3) and unnecessary because the package works fine using the
urllib that comes with python3.6 (done is an only slightly out of date
unstable chroot):
Python 3.6.7 (default, Oct 21 2018, 08:08:16)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wget
>>> url = 'http://www.kitterman.com/debian/qscintilla2_2.10.4+dfsg.orig.tar.gz'
>>> filename = wget.download(url)
100%
[..]
2772679 / 2772679>>>
>>> print(filename
... )
qscintilla2_2.10.4+dfsg.orig.tar.gz
The solution is to just drop it:
Depends: ${misc:Depends}, ${python3:Depends}
Bug#913153: img2pdf fixed
Dear Johannes,
On Nov 24 2018, josch wrote:
> img2pdf (0.3.2-1) unstable; urgency=medium
>
>* new upstream release
> - fixed PNG handling (closes: #913153)
>
> -- Johannes 'josch' Schauer Fri, 23 Nov 2018 18:23:26
> +0100
Thank you very much for having this fix uploaded to the archive.
Thanks once again,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#914159: Is not working
Hi,
Thanks for the response.
I've tested installing ruby-gpgme 2.0.13 as you suggested. Here's the
relevant log:
kanade:~# dpkg -i ruby-gpgme_2.0.13-1_amd64.deb
dpkg: warning: downgrading ruby-gpgme from 2.0.16-1+b1 to 2.0.13-1
(Reading database ... 210214 files and directories currently installed.)
Preparing to unpack ruby-gpgme_2.0.13-1_amd64.deb ...
Unpacking ruby-gpgme (2.0.13-1) over (2.0.16-1+b1) ...
Setting up ruby-gpgme (2.0.13-1) ...
Processing triggers for gitlab (11.3.10+dfsg-2) ...
Could not find gem 'gpgme' in any of the gem sources listed in your Gemfile.
#
# Failed to detect gitlab dependencies; if you are in the middle of an #
# upgrade, this is probably fine, there will be another attempt later. #
# #
# If you are NOT in the middle of an upgrade, there is probably a real #
# issue. Please report a bug. #
#
kanade:~# dpkg -l | grep gpgme
ii libgpgme11:amd64
1.12.0-4 amd64GPGME - GnuPG Made Easy
(library)
ii ruby-gpgme
2.0.13-1 amd64Ruby GPGME binding
Without restarting gitlab, I've tested to add the key. Here's the log:
Started POST "/profile/gpg_keys" for x.x.x.x at 2018-11-24 04:06:14 +0100
Processing by Profiles::GpgKeysController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]",
"gpg_key"=>"[FILTERED]"}
[ActiveJob] Enqueued ActionMailer::DeliveryJob (Job ID:
9dbc484b-d75d-453f-99e9-48f8600477b8) to Sidekiq(mailers) with arguments:
"Notify", "new_gpg_key_email", "deliver_now", 8
Redirected to https://git.example.com/profile/gpg_keys
Completed 302 Found in 564ms (ActiveRecord: 33.9ms)
[ActiveJob] [ActionMailer::DeliveryJob]
[9dbc484b-d75d-453f-99e9-48f8600477b8] Performing ActionMailer::DeliveryJob
from Sidekiq(mailers) with arguments: "Notify", "new_gpg_key_email",
"deliver_now", 8
Started GET "/profile/gpg_keys" for x.x.x.x at 2018-11-24 04:06:15 +0100
Processing by Profiles::GpgKeysController#index as HTML
Completed 200 OK in 205ms (Views: 190.8ms | ActiveRecord: 3.1ms)
Restarting gitlab fails because gem change. Log message (from syslog)
Nov 24 04:07:33 kanade systemd[1]: Stopped Gitlab Workhorse handles slow
HTTP requests for Gitlab..
Nov 24 04:07:33 kanade systemd[1]: Stopped Gitlab mailroom Worker.
Nov 24 04:07:33 kanade systemd[1]: Stopping GitLab Unicorn Server...
Nov 24 04:07:34 kanade systemd[1]: Stopped GitLab Unicorn Server.
Nov 24 04:07:34 kanade systemd[1]: gitlab-unicorn.service: Ignoring invalid
environment assignment 'for i in $(grep -v '#'
/etc/gitlab/gitlab-debian.conf | cut -d=-f 1)': /etc/default/gitlab
Nov 24 04:07:34 kanade systemd[1]: gitlab-unicorn.service: Ignoring invalid
environment assignment 'export app_user=${gitlab_user}': /etc/default/gitlab
Nov 24 04:07:34 kanade systemd[1]: Started GitLab Unicorn Server.
Nov 24 04:07:34 kanade systemd[1]: Started Gitlab mailroom Worker.
Nov 24 04:07:34 kanade systemd[1]: Started Gitlab Workhorse handles slow
HTTP requests for Gitlab..
Nov 24 04:07:34 kanade gitlab-workhorse[1771]:
time="2018-11-24T04:07:34+01:00" level=info msg=Starting
version="gitlab-workhorse (unknown version)"
Nov 24 04:07:34 kanade gitlab-sidekiq[32419]: 2018-11-24T03:07:34.384Z
32419 TID-2nzlbozz3 INFO: Pausing to allow workers to finish...
Nov 24 04:07:34 kanade gitlab-unicorn[1766]:
/usr/lib/ruby/vendor_ruby/bundler/resolver.rb:289:in `block in
verify_gemfile_dependencies_are_found!': Could not find gem 'gpgme' in any
of the gem sources listed in your Gemfile. (Bundler::$
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/resolver.rb:257:in `each'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/resolver.rb:257:in
`verify_gemfile_dependencies_are_found!'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/resolver.rb:48:in `start'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/resolver.rb:22:in `resolve'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/definition.rb:257:in `resolve'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/definition.rb:170:in `specs'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/definition.rb:237:in `specs_for'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/definition.rb:226:in `requested_specs'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/runtime.rb:108:in `block in
definition_method'
Nov 24 04:07:34 kanade gitlab-unicorn[1766]: #011from
/usr/lib/ruby/vendor_ruby/bundler/runtime.rb:20:in `setup'
Nov 24
Bug#914505: linux: reference to netfilter chain not removed on rule replacement, subsequently system hangs
Source: linux
Version: 4.18.20-1
Severity: important
Tags: upstream
Hi.
Possibly the following may be also partially iptables (i.e. the userland tool)
fault.
I'm using fail2ban with some custom usage mode, which is that the hook-rule
for fail2ban's change isn't just appended somehwere, but an inserted at just
the right point in my iptables rules (loaded at boot by netfilter-persistent).
This looks e.g. like the following in terms of rules:
...
-A INPUT--in-interface lo -m comment --comment "f2b-hook-sshd"
-A INPUT--destination 0.ssh.srv.localhost --protocol tcp -m tcp
--destination-port ssh --syn -j ACCEPT
...
(where the first rule servers as a dummy rule)
And an /etc/fail2ban/action.d/iptables-multiport.conf which looks like:
...
actionstart = -N f2b-
-A f2b- -j
rulenum="$( -L --line-numbers | grep '/\*
f2b-hook- \*/' | cut -d ' ' -f 1 )"
-R "${rulenum}" -p -m multiport
--dports -j f2b-
...
actionstop = rulenum="$( -L --line-numbers | grep
f2b- | cut -d ' ' -f 1 )"
-R "${rulenum}" --in-interface lo -m comment
--comment f2b-hook-
-F f2b-
-X f2b-
...
So far so good.
When fail2ban starts I get something like this:
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
DROP all -- anywhere anywhere state
INVALID,UNTRACKED
f2b-sshd tcp -- anywhere anywhere multiport dports
ssh
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
...
Chain f2b-sshd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Everything fine.
But now:
1) Replacing the rule that causes the reference to f2b-sshd doesn't clear the
reference.
Now when I stop fail2ban it will do something like:
iptables -R INPUT 5 --in-interface lo -m comment --comment f2b-hook-
i.e. bringing me back the original dummy rule, but here some error happens on
either
iptable or the kernel or both:
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
DROP all -- anywhere anywhere state
INVALID,UNTRACKED
all -- anywhere anywhere /* f2b-hook-ssh */
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
...
Chain f2b-sshd (1 references)
target prot opt source destination
The dummy rule in INPUT brought back, the chain f2b-sshd is flushed but left
back
with reference set to 1, which is obviously wrong, as the rule no longer
references the queue.
This also happens when just calling the iptables commands manually.
It does not happen when e.g. deleting the rules (iptables -D) as fail2ban would
do per default.
If I repeat this multiple times, I can make the references even count up, e.g.:
Chain f2b-sshd (2 references)
target prot opt source destination
2) The kernel is now in state from which it cannot recover,...
it seems.
It doesn't seem possible to be possible to get the broken chain
away... including when I deleted the rule that was replaced (better
said its replacement).
When I try to start from scratch with e.g.
# iptables-restore < /etc/iptables/rules.v4
The process hangs and I get a:
Nov 24 03:00:01 heisenberg kernel: [ 9857.115308] [ cut here
]
Nov 24 03:00:01 heisenberg kernel: [ 9857.115320] kernel BUG at
/build/linux-iActNR/linux-4.18.10/net/netfilter/nf_tables_api.c:1364!
Nov 24 03:00:01 heisenberg kernel: [ 9857.115367] invalid opcode: [#1] SMP
PTI
Nov 24 03:00:01 heisenberg kernel: [ 9857.115379] CPU: 3 PID: 17642 Comm:
iptables-restor Not tainted 4.18.0-2-amd64 #1 Debian 4.18.10-2
Nov 24 03:00:01 heisenberg kernel: [ 9857.115382] Hardware name: FUJITSU
LIFEBOOK U757/FJNB2A5, BIOS Version 1.21 03/19/2018
Nov 24 03:00:01 heisenberg kernel: [ 9857.115412] RIP:
0010:nf_tables_chain_destroy.isra.48+0x95/0xa0 [nf_tables]
Nov 24 03:00:01 heisenberg kernel: [ 9857.115414] Code: 51 bf ab d8 48 8b 7b 58
e8 78 5b b3 d8 48 89 ef 5b 5d e9 6e 5b b3 d8 48 8b 7b 58 e8 65 5b b3 d8 48 89
df 5b 5d e9 5b 5b b3 d8 <0f> 0b 0f 0b eb 9c 0f 1f 44 00 00 0f 1f 44 00 00 53 48
8b 07 8b 90
Nov 24 03:00:01 heisenberg kernel: [ 9857.115450] RSP: 0018:a6c70aaf3998
EFLAGS: 00010202
Nov 24 03:00:01 heisenberg kernel: [
Bug#914504: enigmail: asks to trust EVIL32 key
Package: enigmail Version: 2:2.0.8-5~deb9u1 Severity: normal Tags: upstream Hi, there is an EVIL32 key for my name, which I have in my keyring as untrusted, and I don't have the secret key for it. Enigmail occasionally pops up requests to assign ultimate trust to this key. The 32 bit keyid is the same as my regular key, which would be default for signing. Simon -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-8-amd64 (SMP w/8 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: sysvinit (via /sbin/init) Versions of packages enigmail depends on: ii gnupg 2.1.18-8~deb9u3 ii gnupg-agent2.1.18-8~deb9u3 ii icedove1:60.3.0-1~deb9u1 ii thunderbird [icedove] 1:60.3.0-1~deb9u1 Versions of packages enigmail recommends: ii pinentry-gtk2 [pinentry-x11] 1.0.0-2 enigmail suggests no packages. -- no debconf information
Bug#913859: [PATCH] build: only enable backtrace(3) in maintainer mode
From: Andreas Henriksson
Using backtrace() is of no use when building with PIE (which most
distro compilers do by default) and prevents catching the coredump
for later retracing, which is needed since distros usually don't
install debug symbols by default either.
This patch thus only enables backtrace() when --enable-maintainer-mode
is passed and also tries to explicitly disable PIE.
---
configure.ac| 12 ++--
src/backtrace.c | 2 +-
src/backtrace.h | 2 +-
src/main.c | 2 +-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8deb53a..ba88871 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,8 +80,16 @@ AC_DEFINE_UNQUOTED(WIRED_STORAGEDIR, "${wired_storagedir}",
AC_CHECK_HEADERS(linux/types.h linux/if_alg.h)
-AC_CHECK_HEADERS_ONCE(execinfo.h)
-AC_CHECK_LIB(execinfo, backtrace)
+# In maintainer mode: try to build with application backtrace and disable PIE.
+if (test "${USE_MAINTAINER_MODE}" = yes) then
+ AC_SEARCH_LIBS([backtrace], [execinfo],
+ [
+ AC_DEFINE([HAVE_BACKTRACE], [1],
+ [Define to 1 if you have backtrace(3).])
+ CFLAGS="$CFLAGS -fno-PIE"
+ LDFLAGS="$LDFLAGS -no-pie"
+ ])
+fi
AC_ARG_ENABLE([daemon], AC_HELP_STRING([--disable-daemon],
[don't install iwd system daemon]),
diff --git a/src/backtrace.c b/src/backtrace.c
index f7732a6..b9e1bbf 100644
--- a/src/backtrace.c
+++ b/src/backtrace.c
@@ -27,7 +27,7 @@
#define _GNU_SOURCE
#include
-#ifdef HAVE_EXECINFO_H
+#ifdef HAVE_BACKTRACE
#include
#include
#include
diff --git a/src/backtrace.h b/src/backtrace.h
index 829ba02..51d4efe 100644
--- a/src/backtrace.h
+++ b/src/backtrace.h
@@ -19,7 +19,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
-#ifdef HAVE_EXECINFO_H
+#ifdef HAVE_BACKTRACE
void __iwd_backtrace_init();
void __iwd_backtrace_print(unsigned int offset);
#endif
diff --git a/src/main.c b/src/main.c
index 8035fa0..e0ccbef 100644
--- a/src/main.c
+++ b/src/main.c
@@ -445,7 +445,7 @@ int main(int argc, char *argv[])
if (debugopt)
l_debug_enable(debugopt);
-#ifdef HAVE_EXECINFO_H
+#ifdef HAVE_BACKTRACE
__iwd_backtrace_init();
#endif
--
2.19.2
Bug#914159: Problem still present
On 2018, നവംബർ 24 3:02:56 AM IST, "David López Zajara" wrote: >The problem is still present on Gitlab 11.3.10 > One possibility I can think of is ruby-gpgme version. Upstream has 2.0.13 and we have 2.0.16. Ideally it should not be a problem, but may be some deprecated api was removed. Try an older version from http://snapshot.debian.org/binary/ruby-gpgme/ if that does not fix, we got to ask upstream by opening an issue (mention it is Debian native package in the issue). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Hi Hans! On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg wrote: You didn't share any part of your logging. Can you share a part of dmesg logging that shows Oops in it? Here it is, attached to this message. Previously I didn't attached it because to me it looks substantially the same as the one I attached in the opening message of this bug (#913119). If a task hangs while doing disk IO, it might cause messages like these in dmesg: INFO: task kthxbye:1157 blocked for more than 120 seconds. Not tainted blah #1 Debian someversion [...] These are 'just' informational messages. The process will still wait until it can continue. A kernel Oops is something really different. It usually means that some data structures or code to be executed are corrupt and there's a real problem going on, it's not just stalled and waiting. Thank you very much for this explanation: I didn't know this difference and indeed I realized that I didn't know what a oops really is. Cesare. [16192.174787] INFO: task mdX_raid1:221 blocked for more than 120 seconds. [16192.174792] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174793] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174795] mdX_raid1 D0 221 2 0x8000 [16192.174798] Call Trace: [16192.174808] ? __schedule+0x2b7/0x880 [16192.174811] schedule+0x28/0x80 [16192.174819] md_super_wait+0x6e/0xa0 [md_mod] [16192.174824] ? finish_wait+0x80/0x80 [16192.174828] md_update_sb.part.65+0x408/0x840 [md_mod] [16192.174833] md_check_recovery+0x4ab/0x570 [md_mod] [16192.174837] raid1d+0x5c/0x890 [raid1] [16192.174840] ? lock_timer_base+0x67/0x80 [16192.174842] ? try_to_del_timer_sync+0x4d/0x80 [16192.174844] ? del_timer_sync+0x35/0x40 [16192.174847] ? schedule_timeout+0x181/0x380 [16192.174851] ? md_rdev_init+0xb0/0xb0 [md_mod] [16192.174855] ? md_thread+0x122/0x160 [md_mod] [16192.174857] ? handle_read_error+0x4f0/0x4f0 [raid1] [16192.174860] md_thread+0x122/0x160 [md_mod] [16192.174863] ? finish_wait+0x80/0x80 [16192.174865] kthread+0x113/0x130 [16192.174867] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174869] ret_from_fork+0x35/0x40 [16192.174872] INFO: task jbd2/dm-4-8:294 blocked for more than 120 seconds. [16192.174874] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174875] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174876] jbd2/dm-4-8 D0 294 2 0x8000 [16192.174878] Call Trace: [16192.174881] ? __schedule+0x2b7/0x880 [16192.174882] ? __switch_to_asm+0x40/0x70 [16192.174883] ? __switch_to_asm+0x34/0x70 [16192.174886] ? bit_wait+0x50/0x50 [16192.174888] schedule+0x28/0x80 [16192.174890] io_schedule+0x12/0x40 [16192.174892] bit_wait_io+0xd/0x50 [16192.174894] __wait_on_bit+0x44/0x80 [16192.174896] out_of_line_wait_on_bit+0x91/0xb0 [16192.174899] ? init_wait_var_entry+0x40/0x40 [16192.174905] jbd2_journal_commit_transaction+0x1036/0x1810 [jbd2] [16192.174907] ? __switch_to_asm+0x40/0x70 [16192.174908] ? __switch_to_asm+0x34/0x70 [16192.174909] ? __switch_to_asm+0x40/0x70 [16192.174911] ? __switch_to_asm+0x34/0x70 [16192.174913] ? __switch_to_asm+0x40/0x70 [16192.174917] ? kjournald2+0xbd/0x270 [jbd2] [16192.174921] kjournald2+0xbd/0x270 [jbd2] [16192.174923] ? finish_wait+0x80/0x80 [16192.174927] ? commit_timeout+0x10/0x10 [jbd2] [16192.174928] kthread+0x113/0x130 [16192.174930] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174931] ret_from_fork+0x35/0x40 [16192.174938] INFO: task mdX_raid1:603 blocked for more than 120 seconds. [16192.174939] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174941] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174942] mdX_raid1 D0 603 2 0x8000 [16192.174944] Call Trace: [16192.174946] ? __schedule+0x2b7/0x880 [16192.174948] schedule+0x28/0x80 [16192.174952] md_super_wait+0x6e/0xa0 [md_mod] [16192.174955] ? finish_wait+0x80/0x80 [16192.174959] md_update_sb.part.65+0x408/0x840 [md_mod] [16192.174963] md_check_recovery+0x4ab/0x570 [md_mod] [16192.174966] raid1d+0x5c/0x890 [raid1] [16192.174967] ? lock_timer_base+0x67/0x80 [16192.174969] ? try_to_del_timer_sync+0x4d/0x80 [16192.174971] ? del_timer_sync+0x35/0x40 [16192.174973] ? schedule_timeout+0x181/0x380 [16192.174977] ? md_rdev_init+0xb0/0xb0 [md_mod] [16192.174981] ? md_thread+0x122/0x160 [md_mod] [16192.174983] ? handle_read_error+0x4f0/0x4f0 [raid1] [16192.174986] md_thread+0x122/0x160 [md_mod] [16192.174989] ? finish_wait+0x80/0x80 [16192.174990] kthread+0x113/0x130 [16192.174992] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174994] ret_from_fork+0x35/0x40 [16192.174997] INFO: task jbd2/dm-9-8:667 blocked for more than 120 seconds. [16192.174998] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.175000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.175001]
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Hi, On 11/24/18 12:42 AM, Cesare Leonardi wrote: > Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). > > This morning I've tryed to boot this new kernel version, removing the > workaround given by the following kernel parameters: > scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 > > The system showed disk hangs in less than 5 hours, and, as in previous > 4.17 and 4.18, normal disk activities was restored after some minutes, > without apparent data loss. I experienced two hangs before rebooting, > but one of them didn't produce an oops in dmesg. It was not the first > time I saw an hang without oops: maybe those that can recover in less > than 120 seconds, doesn't produce oopses in dmesg? You didn't share any part of your logging. Can you share a part of dmesg logging that shows Oops in it? If a task hangs while doing disk IO, it might cause messages like these in dmesg: INFO: task kthxbye:1157 blocked for more than 120 seconds. Not tainted blah #1 Debian someversion [...] These are 'just' informational messages. The process will still wait until it can continue. A kernel Oops is something really different. It usually means that some data structures or code to be executed are corrupt and there's a real problem going on, it's not just stalled and waiting. > And just to be clear, it doesn't seem a bug related to LVM but more > precisely to various types (all?) of LVM RAID. In fact my notebook disk > uses LVM linear volumes and never showed those hangs and oopses. Have fun, Hans
Bug#914503: RM: plexus-cdc -- ROM; No longer used, replaced by plexus-component-metadata
Package: ftp.debian.org Severity: normal Hi, Please remove the plexus-cdc package. It is no longer used and along plexus-maven-plugin it has been replaced by libplexus-component-metadata-java. Thank you, Emmanuel Bourg
Bug#914502: RM: plexus-maven-plugin -- ROM; No longer used, replaced by plexus-component-metadata
Package: ftp.debian.org Severity: normal Hi, Please remove the plexus-maven-plugin package. It's no longer used and has been replaced by libplexus-component-metadata-java from src:plexus-containers. Thank you, Emmanuel Bourg
Bug#914501: base64_encode(): two-byte out-of-bounds stack write
Package: ssh-agent-filter
Version: 0.2-1
Severity: important
Tags: upstream fixed-upstream pending jessie stretch buster sid
A two-byte out-of-bounds stack write has been found in base64_encode().
Quoting relevant parts of the conversation with the security team:
21.11.18 20:21 Timo Weingärtner:
> while developing a new feature for ssh-agent-filter I noticed an error
> interpreting nettle's API documentation I made when I first wrote an
> adjacent function (right in the beginning; every version in Debian is
> affected).
>
> The problem is BASE64_ENCODE_LENGTH() returning the size of the encoded
> string without the padding added in the finalization step. If the
> programmer forgets to take BASE64_ENCODE_FINAL_LENGTH into account this can
> result in up to two bytes with value '=' being written past the end of the
> buffer.
>
> I was not able to crash ssh-agent-filter on my amd64 machine, so I guess the
> bug is hidden by alignment on the stack.
23.11.18 15:00 Timo Weingärtner:
> The strings to be base64-encoded (there is no decoding) is from the user's
> ssh-agent and — if confirmation is used — strings from a remote attacker
> (the same user or root on a machine the user connected to via (af)ssh) might
> get encoded. Encoded strings are compared against, output to terminal in
> debug mode or to the user via ssh-askpass in confirmation mode.
>
> Incoming connections are handled in threads, so the entire filter process
> might crash, resulting in DoS.
>
> The data written past the end of the buffer is always the same ('='); the
> attacker can only influence the number of extra bytes written (string length
> % 3). I don't really know about the exact stack layout and alignment on
> neither amd64 nor other archs, but if the stack grows downward these bytes
> would get written into the base64_ctx, unused space because of alignment,
> or the canary.
23.11.18 20:15 Moritz Mühlenhoff:
> Thanks for the summary. This sounds all quite limited impact-wise and sounds
> like a perfect candidate for a targeted fix via stable-proposed-updates. Do
> you agree? If so, let's open a a in the BTS which can then be closed with
> the upload to unstable (and also serves as a good reference for the stable
> update).
signature.asc
Description: This is a digitally signed message part.
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). This morning I've tryed to boot this new kernel version, removing the workaround given by the following kernel parameters: scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 The system showed disk hangs in less than 5 hours, and, as in previous 4.17 and 4.18, normal disk activities was restored after some minutes, without apparent data loss. I experienced two hangs before rebooting, but one of them didn't produce an oops in dmesg. It was not the first time I saw an hang without oops: maybe those that can recover in less than 120 seconds, doesn't produce oopses in dmesg? And just to be clear, it doesn't seem a bug related to LVM but more precisely to various types (all?) of LVM RAID. In fact my notebook disk uses LVM linear volumes and never showed those hangs and oopses. Cesare.
Bug#914500: lintian: False positive package-contains-documentation-outside-usr-share-doc for file readMesh_off.m
Package: lintian Version: Severity: normal When checking package octave-geometry, Lintian issues the warning package-contains-documentation-outside-usr-share-doc for file usr/share/octave/packages/geometry-3.0.0/meshes3d/readMesh_off.m It seems that the following regex in file data/files/documentation-file-regex: ^readme(?:first)? is too permissive. Best, Rafael
Bug#914498: libocct-doc: Using search form attempts to download search.php instead of searching
Package: libocct-doc Version: 7.3.0+dfsg1-4 Severity: minor Dear Maintainer, When accessing the HTML documentation, there is a search form in the top-right of the page. Attempting to use this search form results in a download prompt for the file "search.php" instead of executing a search of the documentation. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libocct-doc depends on: ii libjs-mathjax 2.7.4+dfsg-1 libocct-doc recommends no packages. libocct-doc suggests no packages. -- no debconf information
Bug#914499: RFS: wxmaxima/18.11.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxmaxima" * Package name: wxmaxima Version : 18.11.0-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : math It builds those binary packages: wxmaxima - GUI for the computer algebra system Maxima wxMaxima is a powerful (and nowadays even fast) graphical user interface for maxima, a program that can solve any numerical task, but is specialized in symbolic maths. One example on what it does would be: (%i1) frm:a^3+b^3=c^3; (frm) b^3+a^3=c^3 (%i2) solve(frm,a); (%o2) [a=((sqrt(3)*%i-1)*(c^3-b^3)^(1/3))/2,a=-((sqrt(3)*%i+1)*(c^3-b^3)^(1/3))/2,a=(c^3-b^3)^(1/3)] To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wxmaxima Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_18.11.0-1.dsc More information about wxmaxima can be obtained from http://wxmaxima-developers.github.io/wxmaxima/. Changes since the last upload: * New upstream release that drastically improves the drawing speed, provides a better lisp mode, improves the loop of the program and fixes many bugs Regards, Gunter.
Bug#914492: libc0.1-dev: Has Linux-only mremap in headers on non-Linux
Hello, Kurt Roeckx, le ven. 23 nov. 2018 22:24:11 +0100, a ecrit: > On kfreebsd-* and hurd I'm getting a linker failure that mremap() > doesn't exist. It exists in sys/mman.h. Well, having it in a header does not imply it is actually available. Samuel
Bug#914488: git breaks xandikos autopkgtest
Jelmer Vernooij wrote: > Add patch 01_sigterm_handler: don't install broken sigterm handler. > Closes: #903854, #914488 Thanks! That was fast.
Bug#914497: RM: tomcat7 -- ROM; No longer used
Package: ftp.debian.org Severity: normal Hi, Please remove the src:tomcat7 package. It only builds the libservlet3.0-java package but it is no longer used, it has been replaced by libservlet3.1-java. Thank you, Emmanuel Bourg
Bug#906115: Bug #906115: gnucash: Crash when press key on new entry in accout
Hello Michael Ott,
I just tried to reproduce this crash.
You were really using the gtk+3.0 packages from experimental at that time?
> Aug 14 13:49:22 king-coder13 kernel: [16027.866859] gnucash[22985]:
> segfault at f0 ip 7f76d6ba7952 sp 7ffcb1fd9198
> error 4 in libgdk-3.so.0.2301.0[7f76d6b88000+81000]
>From the limited information of the kernel log line I just can
guess the error was a null pointer dereference
in _gdk_window_has_impl.
(gdb) disassemble _gdk_window_has_impl
Dump of assembler code for function _gdk_window_has_impl:
0x7fcb833b2950 <+0>: xor%eax,%eax
0x7fcb833b2952 <+2>: cmp%rdi,0xf0(%rdi)
0x7fcb833b2959 <+9>: sete %al
0x7fcb833b295c <+12>:retq
End of assembler dump.
(gdb) list 660,665
660
661 static gboolean
662 gdk_window_has_impl (GdkWindow *window)
663 {
664 return window->impl_window == window;
665 }
(gdb) list _gdk_window_has_impl
674
675 gboolean
676 _gdk_window_has_impl (GdkWindow *window)
677 {
678 return gdk_window_has_impl (window);
679 }
Is this issue still visible?
If yes it would be a great help if a complete backtrace could be added.
A good information would be just to run it that way:
gdb -q -ex run -ex bt -ex detach -ex quit --args gnucash
Another way would be to install a core dump collector like systemd-coredump
and execute something like this:
coredumpctl list
coredumpctl gdb
Even better when debug symbols are installed like described in [1].
Kind regards,
Bernhard
[1] https://wiki.debian.org/HowToGetABacktrace
Bug#803197: SOGo isn't the only victim, cups breaks as well
On Fri, Nov 23, 2018 at 10:31:58PM +0100, Lukas Kramer wrote: *bump* What are the chances of this patch landing in debian buster? Thanks for the ping. I have no time to work on Debian in the next few weeks but I'll try to follow up during my upcoming vacation. Can't make any promises one way or the other right now, sorry.
Bug#914488: git breaks xandikos autopkgtest
On Fri, Nov 23, 2018 at 12:34:24PM -0800, jrnie...@gmail.com wrote: > The xandikos autopkgtest is either flaky or is experiencing a regression > with the Git update 2.19.1 -> 2.19.2. The litmus test times out[1]. > > Known issue? Anything I can do to help track it down? I'd be very surprised if this is related to the Git update. Digging a little bit further, this appears to be due to the wonky way that signals are handled in python and so in some cases SIGTERM just appears to end up printing the SystemExit traceback rather than actually exiting. Fix coming up. -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#914469: sudo: Truncated sudo(8) man page
Sven Joachim writes: > This has also been reported upstream today. A fix is at > https://www.sudo.ws/repos/sudo/rev/7ddfb74781a1. Thanks. I'll have an updated package uploaded shortly. Bdale signature.asc Description: PGP signature
Bug#914490: ifupdown: networking.service timeout due to /dev/crng initalization?
I'm not sure why I didn't see this before, but it seems to be a "known problem". Searching for "wpa_supplicant crng" yields some helpful information. e.g.: https://forums.gentoo.org/viewtopic-t-1081710-start-0.html Proposed solution to gentoo: "To solve this, one should merge sys-apps/rng-tools and add rngd to sysinit boot level to utilize hardware rng." Uhm...not quite sure how to translate that into "debian". But one part is obvious: apt-get install rng-tools but that "failed" in the install because this device doesn't export a HW Random Number Generator. :/ ... Selecting previously unselected package rng-tools. (Reading database ... 35727 files and directories currently installed.) Preparing to unpack .../rng-tools_2-unofficial-mt.14-1+b2_amd64.deb ... Unpacking rng-tools (2-unofficial-mt.14-1+b2) ... Setting up rng-tools (2-unofficial-mt.14-1+b2) ... Job for rng-tools.service failed because the control process exited with error code. See "systemctl status rng-tools.service" and "journalctl -xe" for details. invoke-rc.d: initscript rng-tools, action "start" failed. ● rng-tools.service Loaded: loaded (/etc/init.d/rng-tools; generated) Active: failed (Result: exit-code) since Fri 2018-11-23 14:02:41 PST; 9ms ago Docs: man:systemd-sysv-generator(8) Process: 1398 ExecStart=/etc/init.d/rng-tools start (code=exited, status=1/FAILURE) Nov 23 14:02:41 stoke systemd[1]: Starting rng-tools.service... Nov 23 14:02:41 stoke rng-tools[1398]: Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device inode not found) Nov 23 14:02:41 stoke rng-tools[1398]: /etc/init.d/rng-tools: Cannot find a hardware RNG device to use. Nov 23 14:02:41 stoke systemd[1]: rng-tools.service: Control process exited, code=exited status=1 Nov 23 14:02:41 stoke systemd[1]: rng-tools.service: Failed with result 'exit-code'. Nov 23 14:02:41 stoke systemd[1]: Failed to start rng-tools.service. Processing triggers for systemd (239-13) ... Processing triggers for man-db (2.8.4-3) ... Anyway, My guess is this report should be assigned to wpa_supplicant, not ifupdown package. On Fri, Nov 23, 2018 at 12:57 PM Grant Grundler wrote: > > Package: ifupdown > Version: 0.8.32 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set > LC_CTYPE to default locale: No such file or directory > locale: Cannot set LC_MESSAGES to default locale: No such file or directory > locale: Cannot set LC_ALL to default locale: No such file or directory > ANSI_X3.4-1968), LANGUAGE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to > default locale: No such file or directory > locale: Cannot set LC_MESSAGES to default locale: No such file or directory > locale: Cannot set LC_ALL to default locale: No such file or directory > ANSI_X3.4-1968) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages ifupdown depends on: > ii adduser 3.118 > ii iproute2 4.18.0-2 > ii libc6 2.27-8 > ii lsb-base 9.20170808 > > Versions of packages ifupdown recommends: > ii isc-dhcp-client [dhcp-client] 4.3.5-4+b1 > > Versions of packages ifupdown suggests: > pn ppp > pn rdnssd > > -- Configuration Files: > /etc/default/networking changed [not included] > > > Note: Two NICs: PCIe r8169 configured statically and PCIe ath9k configured > via dhclient > > # cat /etc/network/interfaces > source /etc/network/interfaces.d/* > > # The loopback network interface > auto lo > iface lo inet loopback > > auto enp1s0 > iface enp1s0 inet static > address 192.168.100.1/24 > > auto wlp2s0 > iface wlp2s0 inet dhcp > wpa-ssid kroleks warren > wpa-psk PASSWORD > > enp1s0 is configured but networking.service times out (5 minutes). > But after logging in from console, networking comes up in < 20 seconds > by running: > systemctl stop networking.service > systemctl start networking.service > > I've looked at a bunch of other ifupdown reports and this one seems the > closest: > #832074 networking.service: Start operation timed out > > One theory presented in this bug is "problem with ifupdown <-> dhclient > interaction". > > My theory is dependency on /dev/crng since running the same commands > later works fine. I installed ifupdown2 and that suceeded after 7-8 > minutes (no timeout?!!!). > > Here is directly related snippets of daemon.log from the last run with >
Bug#914476: flint-arb FTCBFS: ./configure needs to be told, about crossing
Hi, I pushed the proposed changes to salsa, and uploaded a new 2.15.1-2 to experimental. jpuydt on irc.debian.org
Bug#914283: [libboost-context-dev] Provide ucontext_t alternative build
Hi, Il 21/11/18 14:53, Bogdan Vatra ha scritto: > It will be great if debian provides also an ucontext_t alternative build > (libboost-ucontext-dev ?) which replaces fcontext_t and enables the usage of > address & thread sanitizers. I tend to agree this might be useful, also to provide an implementation of context on architectures not supported by fcontext_t. But also keep in mind that ucontext_t is much slower. Also, it must be checked that this does not introduce other kind of problems that could slow the release, and on top of that I am not sure I will have the time to work on that. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914494: sysvinit-utils: pidof behavior changed with omit option -o
I can confirm this bugs exists. It was introduced in the 2.92 version of
pidof by way of a typo. The parameter passed to -o is ignored.
A patch is attached which corrects the behaviour.
My suggestion is for this patch to be applied in the Debian package
against 2.92 (which was just released) and it'll be fixed upstream in
the 2.93 release at some point in the future.
Jesse
On 11/23/18 5:26 PM, Alex Andreotti wrote:
> Package: sysvinit-utils
> Version: 2.92~beta-1
> Severity: normal
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> I'm using a script that when start kills all the script with the same name
> but itself,
> the syntax was:
>
> pidof -o $$ -x script.sh
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> I did an apt upgrade today that installed sysvinit-utils_2.92~beta-1_amd64,
> my older version
> in /var/cache/apt/archives was sysvinit-utils_2.88dsf-59.11_amd64 (Oct 14),
> the behavior
> change should be in between.
>
> If I use a shell `sh script.sh` or `zsh script.sh` it works, but
> `./script.sh` directly doesn't,
> my /bin/sh link to dash, I don't think is relevant...
>
> As a work around I use a for loop and compare with $$.
>
>
> -- 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.18.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages sysvinit-utils depends on:
> ii init-system-helpers 1.56
> ii libc62.27-8
> ii util-linux 2.32.1-0.2
>
> sysvinit-utils recommends no packages.
>
> sysvinit-utils suggests no packages.
>
> -- no debconf information
>
>
diff --git a/src/killall5.c b/src/killall5.c
index 27b5778..25b333e 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -1006,7 +1006,7 @@ int main_pidof(int argc, char **argv)
if ((token = getenv("PIDOF_NETFS")) && (strcmp(token,"no") != 0))
flags |= PIDOF_NETFS;
- while ((opt = getopt(argc,argv,"qhcof:sxn")) != EOF) switch (opt) {
+ while ((opt = getopt(argc,argv,"qhco:f:sxn")) != EOF) switch (opt) {
case '?':
nsyslog(LOG_ERR,"invalid options on command line!\n");
closelog();
Bug#914496: gitlab-shell: Fail on gitlab-shell on git push
Package: gitlab-shell Version: 8.3.3+dfsg-1 Severity: grave Justification: renders package unusable Doing a git push on a repository connected to gitlab, I receive this error: BloudFire:repository maqui$ git push origin /usr/share/gitlab-shell/bin/gitlab-shell:10:in `require_relative': cannot load such file -- /usr/share/gitlab-shell/bin/gitlab_init (LoadError) from /usr/share/gitlab-shell/bin/gitlab-shell:10:in `' fatal: No se pudo leer del repositorio remoto. Testing on gitlab server, the file gitlab_init does not exist on this repository. They are a gitlab_init.rb on /usr/lib/ruby/vendor_ruby folder. With this fail, gitlab is unusable, because I cannot commit to the repository or download from it. Thanks, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.23--grs-ipv6-64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968), LANGUAGE=en_GB:en (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gitlab-shell depends on: ii libc6 2.27-8 ii ruby 1:2.5.1 gitlab-shell recommends no packages. gitlab-shell suggests no packages. -- debconf-show failed
Bug#914159: Problem still present
The problem is still present on Gitlab 11.3.10 https://maqui.darkbolt.net/ Linux registered user ~#363219 PGP keys avaiables at KeyServ. ID: 0x4233E9F2 Los hombres somos esclavos de la historia
Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
On Thu, Nov 22, 2018 at 02:14:13PM +0100, Guillem Jover wrote:
> Having an explicit check for the symbols stuff would be nice, but I
> think it's besides the point. In the same way epochs in upstream
> version are problematic, dashes in upstream versions are too IMO.
Since a few Policy revisions epochs (well, colons actually) are
forbidden in the upstream part of a version string.
And IIRC the reasoning was very similar to the dashes you are talking
about in this bug: confusion for human, and easy for programs to get
them wrong (think about people .split(':') or version string forgetting
to limit the split to 1, same for the dashes...).
--
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#803197: [Pkg-openldap-devel] Bug#803197: SOGo isn't the only victim, cups breaks as well
On Sun, 10 Jun 2018 08:51:47 -0700 Ryan Tandy wrote: > Thanks for the followup. Yes, fixing it as a Debian patch is probably > the best path for now, and maybe trying upstream again at a later date. > To a certain extent it's easier here because we have a more homogeneous > platform than upstream does. *bump* What are the chances of this patch landing in debian buster?
Bug#914495: linux-image-4.18.0-3-amd64: does not boot here
Package: src:linux Version: 4.18.20-1 Severity: critical Justification: breaks the whole system Dear Maintainers, linux-image-4.18.0-3-amd64 does not boot on this computer. After grub shortly cursor is blinking upper left (when usually the initrd is deflating and systemd starts). After that nothing happens. HDD LED does not signalling activity. Display stays dark, no messages appear with GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0 systemd.show_status=1" set. initrd has been rebuild manually before rebooting with dpkg-reconfigure linux-image-... as i get used to. Booting linux-image-4.18.0-2-amd64 instead solves the issue. Since the issue happens very early in boot process debugging is quit difficult. Assistance with further debugging is required if you need additional informations. kind regards, Thilo -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: TOSHIBA product_name: Satellite L300 product_version: PSLB8E-12T018GR chassis_vendor: Chassis Manufacturer chassis_version: Chassis Version bios_vendor: INSYDE bios_version: 1.80 board_vendor: TOSHIBA board_name: Portable PC board_version: Base Board Version ** Network interface configuration: auto lo iface lo inet loopback address 127.0.0.1 netmask 255.0.0.0 iface ethernet inet static network 192.168.10.0 gateway 192.168.10.1 broadcast 192.168.10.255 netmask 255.255.255.0 dns-nameservers 127.0.0.1 allow-hotplug eth0 iface eth0 inet static inherits ethernet address 192.168.10.4 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Toshiba America Info Systems Mobile 4 Series Chipset Memory Controller Hub [1179:ff66] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Toshiba America Info Systems Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems 82801I (ICH9 Family) USB UHCI Controller [1179:ff66] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems 82801I (ICH9 Family) USB UHCI Controller [1179:ff66] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) (prog-if 20 [EHCI]) Subsystem: Toshiba America Info Systems 82801I (ICH9 Family) USB2 EHCI Controller [1179:ff66] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) Subsystem: Toshiba America Info Systems 82801I (ICH9 Family) HD Audio Controller [1179:ff66] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]:
Bug#914494: sysvinit-utils: pidof behavior changed with omit option -o
Package: sysvinit-utils Version: 2.92~beta-1 Severity: normal Dear Maintainer, * What led up to the situation? I'm using a script that when start kills all the script with the same name but itself, the syntax was: pidof -o $$ -x script.sh * What exactly did you do (or not do) that was effective (or ineffective)? I did an apt upgrade today that installed sysvinit-utils_2.92~beta-1_amd64, my older version in /var/cache/apt/archives was sysvinit-utils_2.88dsf-59.11_amd64 (Oct 14), the behavior change should be in between. If I use a shell `sh script.sh` or `zsh script.sh` it works, but `./script.sh` directly doesn't, my /bin/sh link to dash, I don't think is relevant... As a work around I use a for loop and compare with $$. -- 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.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sysvinit-utils depends on: ii init-system-helpers 1.56 ii libc62.27-8 ii util-linux 2.32.1-0.2 sysvinit-utils recommends no packages. sysvinit-utils suggests no packages. -- no debconf information
Bug#914493: libfclib0: hard codes library dependency
Package: libfclib0
Version: 3.0.0+dfsg-1
Severity: serious
Control: block 913837 by -1
Dear maintainer,
your source package has this:
Package: libfclib0
Architecture: any
Multi-Arch: same
Section: libs
Depends: ${misc:Depends},
${shlibs:Depends},
libhdf5-100,
libsuitesparse-dev (>= 1:5.1.2)
This is no good in at least two ways:
* you hardcode a depdency on libhdf5-100, which made me notice this,
since now there is a transition going on to libhdf5-103. the shlibs
mechanism finds the depedency just fine (and if it didn't it would be
a different bug in this package anyway), so please just plain drop
this.
* there is a depedency on a development package. That's plain
worrisome, why would you need that?? I suppose you just wanted a
depdency on suitparse, and the shlibs mechanism perfectly finds
libcxsparse3 already, so there shouldn't be any need for that, I
hope.
--
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#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
tags 914271 - pending tags 914271 + moreinfo forwarded 914271 https://salsa.debian.org/lintian/lintian/merge_requests/72 thanks Hi Guillem et al., > > I then suggest two things: I've reverted this below, pending further discussion here: https://salsa.debian.org/lintian/lintian/commit/ce3c85c83af1db9ed1c159d7043ecd01544e0c95 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
On 23/11/2018 22:02, Guilhem Moulin wrote: > On Fri, 23 Nov 2018 at 21:41:42 +0100, Mikhail Morfikov wrote: >> On 23/11/2018 20:37, Guilhem Moulin wrote: >>> Did you also add a loop to wait for the block device holding the LUKS >>> header? Since the device is discovered asynchronously you need to wait >>> for it in order to eliminate the race. >> >> What exactly should I add? > > Something along the lines (you might want to add a timeout too) of > > DEVICE=/path/to/block/device > if [ ! -b "$DEVICE" ]; then > echo "Waiting for device..." >&2 > until [ -b "$DEVICE" ]; do > sleep 1 > done > fi > > mount -t ext4 -o ro "$DEVICE" /boot > That actually worked! I took just one pass to detect the device. All errors I had even before, now disappeared, and everything works as it should now. Thank you for fixing this. :) signature.asc Description: OpenPGP digital signature
Bug#914492: libc0.1-dev: Has Linux-only mremap in headers on non-Linux
Source: glibc Version: 2.25-2 Hi, On kfreebsd-* and hurd I'm getting a linker failure that mremap() doesn't exist. It exists in sys/mman.h. Kurt
Bug#911084: Bug #911084: sagemath crashes as cantor backend
Dear Maintainer, hello Kinky Nekoboi,
just tried to reproduce this issue and there is really a crash.
In a minimal buster amd64 qemu VM,
with installed cantor and cantor-backend-sage packages.
Then follow these steps:
- start cantor
- select Sage backend
- enter in the field below the "Session 1" tab marked with ">>>":
plot(cos, (-5,5))
- press "Evaluate Worksheet"
The actual crash happens in cantor_sagebackend.so.
There the version of sagemath is tried to be retrieved by
executing "/usr/bin/sage -v".
Unfortunately this outputs just an error message, therefore
is nothing read from stdinput. In the console the output
"found version: ()" from line 472 is visible.
This empty line is processed then by a regular expression
and that is expected to return results on index 1 and 2.
benutzer@debian:~$ /usr/bin/sage -v
/usr/bin/sage: line 16: /src/bin/sage-version.sh: No such file or directory
(gdb) list sagesession.cpp:462,500
462 bool SageSession::updateSageVersion()
463 {
464 QProcess get_sage_version;
465
get_sage_version.setProgram(SageSettings::self()->path().toLocalFile());
466
get_sage_version.setArguments(QStringList()<&2
else
. "$0-env" >&2
fi
...
Attached patch moves the sourcing of sage-env above the call to sage_version.
With that applied cantor successfully can draw and show that plot command.
But I really cannot estimate what else that could break elsewhere.
I think both issues deserve to be tracked separately:
- cantor_sagebackend.so should be more robust against the output of
/usr/bin/sage
- /usr/bin/sage should report its version
Kind regards,
Bernhard
(gdb) bt
#0 0x7f97c94617ac in QString::toIntegral_helper (base=10, ok=0x0,
len=, data=) at
../../include/QtCore/../../src/corelib/tools/qstring.h:895
#1 QString::toInt (this=, ok=ok@entry=0x0, base=base@entry=10)
at tools/qstring.cpp:7078
#2 0x7f97c005007d in SageSession::updateSageVersion() () at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:115
#3 0x7f97c00503f1 in SageSession::login() () at
./src/backends/sage/sagesession.cpp:119
#4 0x7f97b0042621 in Worksheet::loginToSession
(this=this@entry=0x55b0052087f0) at ./src/worksheet.cpp:93
#5 0x7f97b0042c10 in Worksheet::evaluate() () at ./src/worksheet.cpp:457
#6 0x7f97b00387d2 in CantorPart::evaluateOrInterrupt() () at
./src/cantor_part.cpp:529
#7 0x7f97b00767ed in CantorPart::qt_static_metacall (_o=,
_id=, _a=, _c=) at
./obj-x86_64-linux-gnu/src/cantorpart_autogen/EWIEGA46WW/moc_cantor_part.cpp:207
#8 0x7f97c95bb28b in QMetaObject::activate(QObject*, int, int, void**) ()
at kernel/qobject.cpp:3771
#9 0x7f97c95bb8a7 in QMetaObject::activate
(sender=sender@entry=0x55b00525e970, m=m@entry=0x7f97ca3d1840
, local_signal_index=local_signal_index@entry=1,
argv=argv@entry=0x7ffdca3ab9d0) at kernel/qobject.cpp:3633
#10 0x7f97c9f01ee2 in QAction::triggered (this=this@entry=0x55b00525e970,
_t1=) at .moc/moc_qaction.cpp:376
#11 0x7f97c9f044f0 in QAction::activate (this=0x55b00525e970,
event=) at kernel/qaction.cpp:1166
#12 0x7f97c9fefc8d in QAbstractButtonPrivate::click (this=0x55b0053538b0)
at widgets/qabstractbutton.cpp:397
#13 0x7f97c9fefec5 in QAbstractButton::mouseReleaseEvent
(this=0x55b0053533a0, e=0x7ffdca3abea0) at widgets/qabstractbutton.cpp:1011
#14 0x7f97ca0d9c0a in QToolButton::mouseReleaseEvent (this=,
e=) at widgets/qtoolbutton.cpp:622
#15 0x7f97c9f467c8 in QWidget::event (this=0x55b0053533a0,
event=0x7ffdca3abea0) at kernel/qwidget.cpp:8925
#16 0x7f97c9ff1103 in QAbstractButton::event
(this=this@entry=0x55b0053533a0, e=e@entry=0x7ffdca3abea0) at
widgets/qabstractbutton.cpp:968
#17 0x7f97ca0d9cb3 in QToolButton::event (this=0x55b0053533a0,
event=0x7ffdca3abea0) at widgets/qtoolbutton.cpp:985
#18 0x7f97c9f08491 in QApplicationPrivate::notify_helper
(this=this@entry=0x55b004f5e380, receiver=receiver@entry=0x55b0053533a0,
e=e@entry=0x7ffdca3abea0) at kernel/qapplication.cpp:3727
#19 0x7f97c9f0fd18 in QApplication::notify(QObject*, QEvent*) () at
kernel/qapplication.cpp:3203
#20 0x7f97c9592039 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#21 0x7f97c9f0f019 in QCoreApplication::sendEvent (event=,
receiver=) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#22 QApplicationPrivate::sendMouseEvent
(receiver=receiver@entry=0x55b0053533a0, event=event@entry=0x7ffdca3abea0,
alienWidget=alienWidget@entry=0x55b0053533a0, nativeWidget=0x55b004fa5610,
buttonDown=buttonDown@entry=0x7f97ca400870 ,
lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:2695
#23 0x7f97c9f61304 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at
/usr/include/c++/8/bits/atomic_base.h:390
#24 0x7f97c9f63e8e in
Bug#914265: xkeycaps 2.47-4.1+deb9u1 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: xkeycaps Version: 2.47-4.1+deb9u1 Explanation: prevent segfault in commands.c when more than 8 keysyms per key are present
Bug#913525: linux 4.9.135-1 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian . Thanks for your contribution! Upload details == Package: linux Version: 4.9.135-1 Explanation: new upstream release
Bug#914491: linux-image-4.18.0-3-amd64: Please revert the STIBP patch from 4.18.20
Package: linux-image-4.18.0-3-amd64 Version: 4.18.20-1 Severity: normal Dear Maintainer, The recently uploaded 4.18.20 kernel package has the STIBP patch in it that has been reverted from the 4.9.140, 4.14.83, and 4.19.4 kernels upstream. There will never been an official revert for 4.18 because its now EOL. I was wondering if you could revert it in the Debian kernel package. If 4.19.4+ is about to be uploaded anyway then there is probably no reason to re-upload another 4.18.20 package with this commit removed. The patch in question is named "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation" and was added in 4.18.19. $ uname -a Linux doge 4.18.0-3-amd64 #1 SMP Debian 4.18.20-1 (2018-11-21) x86_64 GNU/Linux $ sudo dmesg | grep STIBP [0.132001] Spectre V2 : Spectre v2 cross-process SMT mitigation: Enabling STIBP $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline, IBPB, IBRS_FW, STIBP ^ -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages linux-image-4.18.0-3-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-3-amd64 recommends: ii apparmor 2.13.1-3+b1 ii firmware-linux-free 3.4 ii irqbalance 1.5.0-0.1 Versions of packages linux-image-4.18.0-3-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.02+dfsg1-8 pn linux-doc-4.18
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
On Fri, 23 Nov 2018 at 21:41:42 +0100, Mikhail Morfikov wrote: > On 23/11/2018 20:37, Guilhem Moulin wrote: >> Did you also add a loop to wait for the block device holding the LUKS >> header? Since the device is discovered asynchronously you need to wait >> for it in order to eliminate the race. > > What exactly should I add? Something along the lines (you might want to add a timeout too) of DEVICE=/path/to/block/device if [ ! -b "$DEVICE" ]; then echo "Waiting for device..." >&2 until [ -b "$DEVICE" ]; do sleep 1 done fi mount -t ext4 -o ro "$DEVICE" /boot -- Guilhem. signature.asc Description: PGP signature
Bug#914490: ifupdown: networking.service timeout due to /dev/crng initalization?
Package: ifupdown Version: 0.8.32 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968), LANGUAGE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 4.18.0-2 ii libc6 2.27-8 ii lsb-base 9.20170808 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.5-4+b1 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- Configuration Files: /etc/default/networking changed [not included] Note: Two NICs: PCIe r8169 configured statically and PCIe ath9k configured via dhclient # cat /etc/network/interfaces source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto enp1s0 iface enp1s0 inet static address 192.168.100.1/24 auto wlp2s0 iface wlp2s0 inet dhcp wpa-ssid kroleks warren wpa-psk PASSWORD enp1s0 is configured but networking.service times out (5 minutes). But after logging in from console, networking comes up in < 20 seconds by running: systemctl stop networking.service systemctl start networking.service I've looked at a bunch of other ifupdown reports and this one seems the closest: #832074 networking.service: Start operation timed out One theory presented in this bug is "problem with ifupdown <-> dhclient interaction". My theory is dependency on /dev/crng since running the same commands later works fine. I installed ifupdown2 and that suceeded after 7-8 minutes (no timeout?!!!). Here is directly related snippets of daemon.log from the last run with ifupdown2 installed: Nov 22 23:39:35 stoke systemd[1]: Starting ifupdown2 networking initialization... ... Nov 22 23:39:35 stoke systemd[1]: Started Load/Save RF Kill Switch Status. ... Nov 22 23:39:35 stoke wpa_supplicant[302]: Successfully initialized wpa_supplicant Nov 22 23:39:35 stoke networking[308]: networking: Configuring network interfaces Nov 22 23:39:36 stoke wpa_supplicant[425]: Successfully initialized wpa_supplicant Nov 22 23:47:15 stoke dhclient[446]: DHCPREQUEST of 192.168.86.23 on wlp2s0 to 255.255.255.255 port 67 Nov 22 23:47:18 stoke wpa_supplicant[437]: wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: SME: Trying to authenticate with f4:f2:6d:a9:1d:91 (SSID='kroleks warren' freq=5745 MHz) Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: Trying to associate with f4:f2:6d:a9:1d:91 (SSID='kroleks warren' freq=5745 MHz) Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: Associated with f4:f2:6d:a9:1d:91 Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: WPA: Key negotiation completed with f4:f2:6d:a9:1d:91 [PTK=CCMP GTK=CCMP] Nov 22 23:47:19 stoke wpa_supplicant[437]: wlp2s0: CTRL-EVENT-CONNECTED - Connection to f4:f2:6d:a9:1d:91 completed [id=0 id_str=] Nov 22 23:47:21 stoke dhclient[446]: DHCPREQUEST of 192.168.86.23 on wlp2s0 to 255.255.255.255 port 67 Nov 22 23:47:21 stoke dhclient[446]: DHCPACK of 192.168.86.23 from 192.168.86.1 Nov 22 23:47:21 stoke dhclient[446]: bound to 192.168.86.23 -- renewal in 36571 seconds. Nov 22 23:47:21 stoke systemd[1]: Started ifupdown2 networking initialization. Nov 22 23:47:21 stoke systemd[1]: Reached target Network. OBVIOUS QUESTION: What caused 7:39 delay between wpa_supplicant successfully starting and sending out DHCPREQUEST? I suspect if I had increased the networking.service timeout to 10 minutes, it likely would have "succeeded" as well. Around the same time, kern.log has: ... Nov 22 23:39:36 stoke kernel: [5.026394] r8169 :01:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw Nov 22 23:39:36 stoke kernel: [5.098167] r8169
Bug#906057: linphone: Linphone "cannot start transport on port 5060, maybe this port is already used" although it is not.
I use linphone on stretch as my one and only telephone. So far, I did not encounter this problem. I suggest to downgrade this issue to "important", because it seems to affect only few users.
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
On 23/11/2018 20:37, Guilhem Moulin wrote: > Did you also add a loop to wait for the block device holding the LUKS > header? Since the device is discovered asynchronously you need to wait > for it in order to eliminate the race. What exactly should I add? signature.asc Description: OpenPGP digital signature
Bug#911793: Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2
Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo: > Hi, > > so, if you don't particularly mind, I'm happy to just take the least > and fix all the involved packages here, so src:vtk7 I just uploaded vtk7, I knew where to look because I did the changes that made the libraries go away, and the python thing was not so difficult after all. > and src:gdcm (and rebuilding fw4spl). At the very least, I'm going > to rename libvtkgdcm2.8 to something else; thinking about > libvtkgdcm2.8a (libvtk7gdcm2.8 would be somewhat against policy, as > it wouldn't match the SONAME anymore, and I don't really like to > change a library's SONAME without coordingation with upstream). Thanks, btw: Mathieu (who proposed the libvtk7gdcm) is actually upstream. > I'd hope the "both vtk6 and vtk7 were loaded in memory" is not so > relevant... after all they are different libraries, they shouldn't > mess with each other that much (there chances of it, but…). The problem is that vtk6 and vtk7 share many symbols, so linking both into the same executable is likely to create problems. [...] > Gert: you mention you gave up on symbols, but at least in gdcm's > changelog I don't see anything about that. Had you had troubles > there as well? TBH I never tried with gdcm, I think I started to upload the package when it was already at version 2.4 and I didn't even note that there is a script for the symbols there (which points at 2.2). When I started packaging some of my software (mia) that has lots of templates I just noted that getting symbols right there is kind of an infinite task because each arch would need its own file because of templates that on 64 bit use some types that are not available, and were not instanciated on 32 bit systems. Maybe the tools are better now, but at that time (2012) it was all kind of wired. > What I would welcome your help with is explaining the camitk FTBFS on > i386. Just had as peek, my guess is that this will help: ifeq ($(DEB_BUILD_ARCH),i386) export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store endif The same was needed for ITK because they write tests with floating point values apparently comparing with high accuracy, and on i386 optimizations can lead to the used of intermediate 80 bit floating point values that then result in test failures because the references were tuned for 64 bit floating point values. Adding above flag makes sure that intermediate results are not keps in these 80 bit FPU registers. Best, Gert
Bug#914471: linphone: new upstream 4.1.1
Please merge with #892325, thanks!
Bug#914489: nagios-nrpe-plugin: SSL connections to "old" (as in Jessie) nagios-nrpe-server(s) broken
Package: nagios-nrpe-plugin Version: 3.2.1-1~bpo9+1 Severity: important Hi, After updating nagios-nrpe-plugin in my monitoring host to 3.2.1-1~bpo9+1 most of my monitored instances fail to be checked. AFAICT only those running Stretch continue to work. The error from the new nagios-nrpe-plugin is as follows: Nov 23 21:08:29 check_nrpe: Error: (!log_opts) Could not complete SSL handshake with A.B.C.D: dh key too small I tried disabling Anonymous Diffie Hellman with '-d 0' but in that case it also fails to contact remote hosts with: Nov 23 21:08:34 check_nrpe: Error: (!log_opts) Could not complete SSL handshake with A.B.C.D: sslv3 alert handshake failure I could not find a combination of -d/-S/-2 that made possible to check nagios-nrpe-server from Jessie or previous releases. This is a major showstopper, since upgrading a monitoring host show not force someone to update *all* their monitored hosts. And -2 is of no use if it cannot check 2.x nagios-nrpe-servers. Please fix this for Buster, or at least include a huge warning before this hits those upgrading to Buster. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nagios-nrpe-plugin depends on: ii libc6 2.24-11+deb9u3 ii libssl1.1 1.1.0f-3+deb9u2 nagios-nrpe-plugin recommends no packages. nagios-nrpe-plugin suggests no packages. -- no debconf information
Bug#914488: git breaks xandikos autopkgtest
Package: xandikos Version: 0.0.11-1 X-Debbugs-Cc: debian...@lists.debian.org, g...@packages.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update The xandikos autopkgtest is either flaky or is experiencing a regression with the Git update 2.19.1 -> 2.19.2. The litmus test times out[1]. Known issue? Anything I can do to help track it down? [1] https://ci.debian.net/data/autopkgtest/testing/amd64/x/xandikos/1365618/log.gz: 127.0.0.1 - - [23/Nov/2018 06:27:41] "MKCOL /litmus/mkcolbody HTTP/1.1" 415 40 Traceback (most recent call last): File "/usr/lib/python3.6/wsgiref/handlers.py", line 138, in run self.finish_response() File "/usr/lib/python3.6/wsgiref/handlers.py", line 180, in finish_response self.write(data) File "/usr/lib/python3.6/wsgiref/handlers.py", line 279, in write self._write(data) File "/usr/lib/python3.6/wsgiref/handlers.py", line 453, in _write result = self.stdout.write(data) File "/usr/lib/python3.6/socketserver.py", line 800, in write self._sock.sendall(b) File "/usr/lib/python3/dist-packages/xandikos/web.py", line 1062, in handle_sigterm sys.exit(0) SystemExit: 0 + cat /tmp/tmp.eLbieYSHTl + wait 4050 autopkgtest [09:14:20]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest-lxc.cvzz263o/downtmp/build.xi9/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest-lxc.cvzz263o/downtmp/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.cvzz263o/downtmp/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod +x /tmp/autopkgtest-lxc.cvzz263o/downtmp/build.xi9/src/debian/tests/litmus; touch /tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-stdout /tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-stderr; /tmp/autopkgtest-lxc.cvzz263o/downtmp/build.xi9/src/debian/tests/litmus 2> >(tee -a /tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.cvzz263o/downtmp/litmus-stdout);" (kind: test) autopkgtest [09:14:20]: test litmus: ---] autopkgtest [09:14:20]: test litmus: - - - - - - - - - - results - - - - - - - - - - litmus FAIL timed out
Bug#913715: Bug #913715: simulide: terminates with segfault sometimes, when trying to undo changes
Hello, Thanks you very much for the suggestions! I tried running the program with again with gdb and got a backtrace of the crash. Below is output of all threads(thread apply all bt). A more comprehensive output (thread apply all bt full) is available at: https://paste.debian.net/?show=1053004 What I did: 1. Added Arduino AVR Board 2. Connected components LED, resistor and ground to pin 4 on the Arduino. 5V rail and ground is also directly connect to the board 3. Loaded firmware 4. Started simulation 5. Stopped simulation 6. Started simulation 7. Moved components 5V rail and ground. 8. Used [Ctrl+Z] to undo the move 9. Program Segfaults Hope this information is helpful. Kind regards, Nils Jarle Haugen AvrProcessor::loadFirmware Avr Init: atmega328 true qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 12494, resource id: 29360513, major code: 40 (TranslateCoords), minor code: 0 [Thread 0x7fffd7fff700 (LWP 17080) exited] Thread 1 "simulide" received signal SIGSEGV, Segmentation fault. 0x555d209a in ?? () (gdb) thread apply all bt Thread 5 (Thread 0x7fffddbf4700 (LWP 12443)): #0 0x764c5e6c in futex_wait_cancelable (private=out>, expected=0, futex_word=0x55c81520) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x764c5e6c in __pthread_cond_wait_common (abstime=0x0, mutex=0x55c814d0, cond=0x55c814f8) at pthread_cond_wait.c:502 #2 0x764c5e6c in __pthread_cond_wait (cond=0x55c814f8, mutex=0x55c814d0) at pthread_cond_wait.c:655 #3 0x7fffde2b0e2b in () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #4 0x7fffde2b0b57 in () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #5 0x764bff2a in start_thread (arg=0x7fffddbf4700) at pthread_create.c:463 #6 0x760bfedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7fffdf8f2700 (LWP 12442)): #0 0x764c5e6c in futex_wait_cancelable (private=out>, expected=0, futex_word=0x55c3ef64) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x764c5e6c in __pthread_cond_wait_common (abstime=0x0, mutex=0x55c3ef10, cond=0x55c3ef38) at pthread_cond_wait.c:502 #2 0x764c5e6c in __pthread_cond_wait (cond=0x55c3ef38, mutex=0x55c3ef10) at pthread_cond_wait.c:655 #3 0x7659c44b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x77443c05 in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #5 0x7659bc97 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x764bff2a in start_thread (arg=0x7fffdf8f2700) at pthread_create.c:463 #7 0x760bfedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fffe67fb700 (LWP 12441)): #0 0x760b5739 in __GI___poll (fds=0x7fffe00195c0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x75100e46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x75100f6c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x76795d13 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x76742d0b in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x765920c6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fffedfb0545 in () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x7659bc97 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x764bff2a in start_thread (arg=0x7fffe67fb700) at pthread_create.c:463 #9 0x760bfedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7fffed52e700 (LWP 12440)): #0 0x760b5739 in __GI___poll (fds=0x7fffed52d9f8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x72f82cf7 in () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x72f8491a in xcb_wait_for_event () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7fffee073519 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x7659bc97 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x764bff2a in start_thread (arg=0x7fffed52e700) at pthread_create.c:463 #6 0x760bfedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7fffee565f80 (LWP 12435)): #0 0x555d209a in () #1 0x555d5c1e in () #2 0x555d7397 in () #3 0x555d08bc in () #4 0x5563eae6 in () #5 0x556379ff in () #6 0x555bbf30 in () #7 0x555bd7bd in () #8 0x555c0f9e in () #9 0x555c5230 in () #10 0x77541567 in QGraphicsScene::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #11 0x77231491 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at
Bug#914487: chromium: nonfree unrar code
Package: chromium Version: 70.0.3538.67-2 Severity: serious Justification: Policy 2.1 Chromium contains nonfree code from unrar, located at third_party/unrar.
Bug#597899: Please do confirm
Good day, I am Mr.Kossi Dodji from the Republic of Togo and I know it will be surprised to receive this email and it will sound odd to you but I have confidence in you. please do confirm the receipt of this email then I will give you the details why I contacted you first. Regards Mr. Kossi Dodji kossi.022do...@gmail.com
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
On Fri, 23 Nov 2018 at 19:12:30 +0100, Mikhail Morfikov wrote: >> cryptsetup-initramfs' ‘cryptroot’ is run (last) is local-top, so before >> your own script. So ‘cryptroot’ is bound to fail after trying to open >> the device a couple of times. Please move your script to local-top, and >> maybe add a loop to make it block when the device is not present. > I moved the script to local-top/ and now I'm unable to unlock the system > container. I tried 15 times, and it can't detect the USB device. Did you also add a loop to wait for the block device holding the LUKS header? Since the device is discovered asynchronously you need to wait for it in order to eliminate the race. > So something has been changed somewhere. Yes, the check for header presence, as written previously. Since 2:2.0.3-2 it's (incorrectly) done in the password prompt loop, which eats more time hence is more likely to hit the ‘rootdelay’ timeout. But I maintain that the local-block logic is racy in the first place. Since you need your USB device to unlock the root device, you need to make sure it's available before ‘cryptroot’ is run. Again, in both < and ≥2:2.0.3-2, ‘cryptroot’ is run a first time (at local-top stage) — and fails to unlock the root device, then a second time (at local-block stage) — and also fails to create the root device, then your script mounts /boot, and finally ‘cryptroot’ is run again — and this time not bound to fail. In <2:2.0.3-2 the header presence check caused the first two executions to fail *early*; in ≥2:2.0.3-2 the first two executions each issue 3x (configurable with ‘tries=’) dummy passwords prompts hence don't fail so quickly. Assuming that the script would fail early was problematic: it might take time to run — whether it succeeds to unlock the root device or not — because there are a whole bunch of other available devices to unlock (resume devices, devices holding /usr, etc.) -- Guilhem. signature.asc Description: PGP signature
Bug#914486: libsdl2-ttf FTCBFS: uses the wrong pkg-config
Source: libsdl2-ttf Version: 2.0.14+dfsg1-3 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap The patch for fixing #892441 in 2.0.14+dfsg1-3 uses the wrong pkg-config and that makes libsdl2-ttf fail to cross build. My attached patch fixes that. Please consider applying it. Helmut --- libsdl2-ttf-2.0.14+dfsg1.orig/configure.in +++ libsdl2-ttf-2.0.14+dfsg1/configure.in @@ -109,7 +109,7 @@ FREETYPE_CONFIG=$freetype_prefix/bin/freetype-config fi fi -AC_PATH_PROG(FREETYPE_CONFIG, pkg-config, no) +AC_PATH_TOOL(FREETYPE_CONFIG, pkg-config, no) no_freetype="" if test "$FREETYPE_CONFIG" = "no" ; then AC_MSG_ERROR([
Bug#914485: funtools FTCBFS: wrongly calls mklib
Source: funtools Version: 1.4.7-3 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Ole, thank you for fixing #882357. That made debugging funtools quite a bit easier. I fear that the fix is insufficient though. When the mklib script calls the linker and the linker fails, mklib reports success and the build continues. That's unfortunate, but I'm not sure whether it still violates the policy. In any case, your fix enabled me to look at the actual cross compilation issue. The Makefile.in passes CC and CXX to mklib. However, mklib does not inspect those variables. Passing them is completely useless. Rather it wants the compiler as a -linker flag. The attached patch fixes that and thus makes funtools cross buildable. It does not fix the error reporting in mklib. Please consider applying it. Helmut --- funtools-1.4.7.orig/Makefile.in +++ funtools-1.4.7/Makefile.in @@ -232,8 +232,7 @@ shlib: sublib $(LIBOBJS) rm -rf $(PACKAGE)tmp; mkdir $(PACKAGE)tmp (cd $(PACKAGE)tmp && ar x ../$(LIB)) - CC='$(CC)' CXX=$(CXX) \ - ./mklib -o $(PACKAGE) -ldl $(WCS_LIBS) -lm -lz `LC_ALL=C ls $(PACKAGE)tmp/*.o` + ./mklib -linker $(CC) -o $(PACKAGE) -ldl $(WCS_LIBS) -lm -lz `LC_ALL=C ls $(PACKAGE)tmp/*.o` rm -rf $(PACKAGE)tmp mainlib: $(MAINLIBOBJS) funmainlib.o lex.calc.o @@ -244,8 +243,7 @@ shmainlib: mainlib rm -rf $(PACKAGE)tmp; mkdir $(PACKAGE)tmp (cd $(PACKAGE)tmp && ar x ../lib$(PACKAGE)MainLib.a) - CC='$(CC)' CXX='$(CXX)' \ - ./mklib -o $(PACKAGE)MainLib -L. -lfuntools `LC_ALL=C ls $(PACKAGE)tmp/*.o` + ./mklib -linker $(CC) -o $(PACKAGE)MainLib -L. -lfuntools `LC_ALL=C ls $(PACKAGE)tmp/*.o` rm -rf $(PACKAGE)tmp tclfun: $(LIB) tclmainlib.o tclfun.o @@ -255,8 +253,7 @@ shtclfun: tclfun rm -rf $(PACKAGE)tmp; mkdir $(PACKAGE)tmp (cd $(PACKAGE)tmp && ar x ../libtclfun.a) - CC='$(CC)' CXX='$(CXX)' \ - ./mklib -o tclfun -L. -lfuntools `LC_ALL=C ls $(PACKAGE)tmp/*.o` $(TCL_LIBS) + ./mklib -linker $(CC) -o tclfun -L. -lfuntools `LC_ALL=C ls $(PACKAGE)tmp/*.o` $(TCL_LIBS) rm -rf $(PACKAGE)tmp test -r pkgIndex.tcl && mv pkgIndex.tcl pkgIndex.tcl-old SHLIB=libtclfun.so; \
Bug#914484: blender: segv on OpenColorIO -> YAML::detail::node_data::get
Package: blender Version: 2.79.b+dfsg0-4+b1 Severity: normal Dear Maintainer, * What led up to the situation? trying to run blender * What was the outcome of this action? systemd-coredump[7871]: Process 7864 (blender) of user 1000 dumped core. note: I upgraded the nvidia driver from experimental some day ago (in order to get cuda working with ffmpeg) but blender was still working, and I did few system upgrade recently. A coredump gdb backtrace log attached. -- 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.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blender depends on: ii blender-data 2.79.b+dfsg0-4 ii fonts-dejavu 2.37-1 pn libavcodec58 ii libavdevice58 7:4.0.3-1 ii libavformat58 7:4.0.3-1 ii libavutil56 7:4.0.3-1 ii libboost-atomic1.67.0 1.67.0-10 ii libboost-chrono1.67.0 1.67.0-10 ii libboost-date-time1.67.0 1.67.0-10 ii libboost-filesystem1.67.0 1.67.0-10 ii libboost-iostreams1.67.0 1.67.0-10 ii libboost-locale1.67.0 1.67.0-10 ii libboost-regex1.67.0 1.67.0-10 ii libboost-system1.67.0 1.67.0-10 ii libboost-thread1.67.0 1.67.0-10 ii libc6 2.27-8 ii libfftw3-double3 3.3.8-2 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-9 ii libgl11.1.0-1 ii libglew2.12.1.0-2 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libgomp1 8.2.0-9 ii libilmbase23 2.2.1-2 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2 ii libjemalloc1 3.6.0-11 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopenal11:1.19.1-1 ii libopencolorio1v5 1.1.0~dfsg0-2 ii libopenexr23 2.2.1-4 ii libopenimageio1.8 1.8.15~dfsg0-1+b1 ii libopenjp2-7 2.3.0-1 ii libopenvdb5.0 5.0.0-2 ii libpcre3 2:8.39-11 ii libpng16-16 1.6.34-2 ii libpython3.6 3.6.7-1 ii libsndfile1 1.0.28-4 ii libspnav0 0.2.3-1 ii libstdc++68.2.0-9 ii libswscale5 7:4.0.3-1 ii libtbb2 2017~U7-8 ii libtiff5 4.0.10-3 ii libx11-6 2:1.6.7-1 ii libxfixes31:5.0.3-1 ii libxi62:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b2 ii libxxf86vm1 1:1.1.4-1+b2 ii python3 3.6.7-1 ii zlib1g1:1.2.11.dfsg-1 blender recommends no packages. blender suggests no packages. -- no debconf information PID: 7864 (blender) UID: 1000 (alex) GID: 1000 (alex) Signal: 11 (SEGV) Timestamp: Fri 2018-11-23 20:08:42 CET (19s ago) Command Line: blender Executable: /usr/bin/blender Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (alex) Boot ID: 69c5b102150f4313a80b0a25e798c7f3 Machine ID: 6cbd0c550e6a4ab981e041a13ba68e48 Hostname: hellspawn Storage: /var/lib/systemd/coredump/core.blender.1000.69c5b102150f4313a80b0a25e798c7f3.7864.154300012200.lz4 Message: Process 7864 (blender) of user 1000 dumped core. Stack trace of thread 7864: #0 0x7f54886495e2 _ZNK4YAML6detail9node_data3getINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEPNS0_4nodeERKT_N5boost10shared_ptrINS0_13memory_holderEEE (libOpenColorIO.so.1) #1 0x7f5488642b1d load (libOpenColorIO.so.1) #2 0x7f548864669d _ZNK11OpenColorIO2v18OCIOYaml4openERSiRNSt3tr110shared_ptrINS0_6ConfigEEEPKc (libOpenColorIO.so.1) #3 0x7f54885bfa63 _ZN11OpenColorIO2v16Config14CreateFromFileEPKc (libOpenColorIO.so.1) #4 0x55c9fac5837f _ZN8OCIOImpl20configCreateFromFileEPKc (blender) #5 0x55c9f9bfcd3a colormanagement_init (blender) #6 0x55c9f91dcfe2 main (blender) #7
Bug#911868: Fix soon
Please push the fix soon. Every time I install or remove something, all day long, I get this warning.
Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)
> > > Why don't you talk to the kernel team about adding a module > > > parameter > > > enable this, rather than packaging a fragile hack? > > > > thanks for the pointer. Do you think about something like the > > attached patch? Would you recommend a post in debian-kernel@l.d.o > > about it or better a salsa merge request? > > I'd prefer a merge request. please see https://salsa.debian.org/kernel-team/linux/merge_requests/73 thanks and kind regards Nicolas -- epost: nico...@fjasle.eu gpg key: 7d970932 55a0ce7f ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2
Hi, so, if you don't particularly mind, I'm happy to just take the least and fix all the involved packages here, so src:vtk7 and src:gdcm (and rebuilding fw4spl). At the very least, I'm going to rename libvtkgdcm2.8 to something else; thinking about libvtkgdcm2.8a (libvtk7gdcm2.8 would be somewhat against policy, as it wouldn't match the SONAME anymore, and I don't really like to change a library's SONAME without coordingation with upstream). On Fri, Nov 23, 2018 at 04:30:16PM +0100, Emmanuel Promayon wrote: > So I suppose the problem is in vtk7 nah, that's just an unrelated breakage for which a patch is even already available.. > 1) gdcm 2.8.7-2 moved to python3 (probably because a move from python2 to > python3 was required) which I think triggered the choice of moving from vtk6 > to vtk7 (which probably made more sense, as I presume vtk6 is also on its > way out of buster). My gut feeling is that the culprit is more the vtk6→vtk7 change rathe than the py2→py3, but it's not relevant. > 2) When gdcm 2.8.7-2 arrived in sid, it generated a SegFaults during camitk > 4.1.2-1 as camitk 4.1.2-1 was still based on vtk6, and loading any camitk > executable meant that both vtk6 and vtk7 were loaded in memory. I'd hope the "both vtk6 and vtk7 were loaded in memory" is not so relevant... after all they are different libraries, they shouldn't mess with each other that much (there chances of it, but…). > 4) gdcm 2.8.7-5 then fixed the double dependency to vtk6 and vtk7 but camitk > 4.1.2-2 was not rebuilt against it, therefore generating the initial error > that triggered bug #911793 the camitk that is currently in unstable is built against gdcm 2.8.7-5, which should have been a fine version. So does camitk really segfault with the current libvtkgdcm2.8? > 5) vtk7 (which was updated in the meantime) seems to have now some missing > libraries and as hdf5 is broken as well camitk 4.1.2-2 can not be rebuilt > yet It needs a rebuild against hdf5, blocked by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914347 but a patch is already available, so.. > On a side discussion: > Does the fact that I moved the dependency of camitk from vtk6 in 4.1.2-1 to > vtk7 in 4.1.2-2 might generate another ABI break? If this is the case, I > will take any advice regarding how to specify this properly! I will check this out. > I will also welcome any information/documentation about how to track the > symbol. TBH, I got kinda tired at writing stuff about how to properly deal with symbols every now and then, so I'll probably just go ahead and commit something. Gert: you mention you gave up on symbols, but at least in gdcm's changelog I don't see anything about that. Had you had troubles there as well? What I would welcome your help with is explaining the camitk FTBFS on i386. -- 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#910469: fdupes 1.61 kernel panic segfaults version 1.51 is ok amd+intel 64bit
control: severity -1 minor control: tags -1 +moreinfo On Sat, Oct 6, 2018 at 3:15 PM Linuxonlinehelp wrote: > Package: fdupes > Version: 1.51-1 > Severity: important > Tags: lfs I think you need to provide a bit more information than that, else i'm afraid i'm gonna have to close this bug report. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#914477: Acknowledgement (rspamd: autopkgtest is flaky)
The difference between a good and bad test seems to be how many processes are running. Maybe it needs to wait longer before running the test, or retry with some timeout.
Bug#914481: [bank] python3-pylxd: Python3-pylxd is not Python3 compatible
Package: python3-pylxd
Version: 2.0.0~b1-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Trying to interact with LXD with a Python3 program, I thought I'd try
pylxd, but I don't think this package has been tested under Python3.
# export LXD_DIR=""
# python3
from pylxd import client
c = client.Client()
FAIL
# export LXD_DIR=/var/snap/lxd/common/lxd
# python3
from pylxd import client
c = client.Client()
FAIL
The following patches at lest let me do a few things, but I don't have
time to go through all the code.
--- client.py.orig 2018-11-23 11:41:31.959501342 -0700
+++ client.py 2018-11-23 11:47:29.315413276 -0700
@@ -111,11 +111,11 @@
else:
if 'LXD_DIR' in os.environ:
path = os.path.join(
-os.environ.get['LXD_DIR'], 'unix.socket')
+os.environ.get('LXD_DIR'), 'unix.socket')
else:
path = '/var/lib/lxd/unix.socket'
self.api = _APINode('http+unix://{}'.format(
-urllib.quote(path, safe='')))
+urllib.parse.quote(path, safe='')))
self.api = self.api[version]
self.containers = self.Containers(self)
--- container.py.orig 2018-11-23 11:49:13.620723578 -0700
+++ container.py2018-11-23 11:49:20.761360981 -0700
@@ -70,7 +70,7 @@
def __init__(self, **kwargs):
super(Container, self).__init__()
-for key, value in kwargs.iteritems():
+for key, value in kwargs.items():
setattr(self, key, value)
def reload(self):
-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/12 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 python3-pylxd depends on:
ii python3 3.5.3-1
ii python3-babel2.3.4+dfsg.1-2
ii python3-dateutil 2.5.3-2
ii python3-openssl 16.2.0-1
ii python3-pbr 1.10.0-1
ii python3-requests 2.12.4-1
ii python3-requests-unixsocket 0.1.5-3
ii python3-six 1.10.0-3
python3-pylxd recommends no packages.
python3-pylxd suggests no packages.
-- no debconf information
Bug#914480: fltk1.1 FTCBFS: uses the wrong pkg-config
Source: fltk1.1 Version: 1.1.10-24 Tags: patch User: helm...@debian.org Usertags: rebootstrap After fixing #892341, fltk1.1 uses the wrong pkg-config. The attached patch fixes that up, but it still doesn't make fltk1.1 cross buildable. It'll continue to fail running the fluid tool. Please consider applying it nonetheless. Helmut diff --minimal -Nru fltk1.1-1.1.10/debian/changelog fltk1.1-1.1.10/debian/changelog --- fltk1.1-1.1.10/debian/changelog 2018-03-13 01:59:37.0 +0100 +++ fltk1.1-1.1.10/debian/changelog 2018-11-23 20:02:37.0 +0100 @@ -1,3 +1,10 @@ +fltk1.1 (1.1.10-25.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix usage of wrong pkg-config. (Closes: #-1) + + -- Helmut Grohne Fri, 23 Nov 2018 20:02:37 +0100 + fltk1.1 (1.1.10-25) unstable; urgency=medium * debian/rules (override_dh_auto_build-indep): Cover more subdirectories diff --minimal -Nru fltk1.1-1.1.10/debian/rules fltk1.1-1.1.10/debian/rules --- fltk1.1-1.1.10/debian/rules 2018-03-13 01:28:48.0 +0100 +++ fltk1.1-1.1.10/debian/rules 2018-11-23 20:02:35.0 +0100 @@ -10,8 +10,7 @@ XCFLAGS = -Wall -Wunused -Wno-format-y2k -fPIE -fno-strict-aliasing -DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) -DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +include /usr/share/dpkg/architecture.mk libdir = /usr/lib/$(DEB_HOST_MULTIARCH) GAMES = blocks checkers sudoku EXTRA_MFLAGS = OPTIM="$(CFLAGS) $(XCFLAGS)" STRIP=@: @@ -21,7 +20,7 @@ override_dh_auto_configure: mv fltk.spec fltk.spec.saved - dh_auto_configure -- FTCONFIG="/usr/bin/pkg-config freetype2" \ + dh_auto_configure -- FTCONFIG="/usr/bin/$(DEB_HOST_GNU_TYPE)-pkg-config freetype2" \ DSOFLAGS="$(filter-out -fPIE -pie,$(LDFLAGS))" \ --enable-shared --enable-threads --enable-xft \ --enable-xinerama --without-links --libdir=$(libdir) \
Bug#914418: apt: Foreign packages that depend on "all" arch packages won't install
Control: forcemerge 910732 -1 On Fri, Nov 23, 2018 at 09:57:46AM +0100, Julian Andres Klode wrote: > On Fri, Nov 23, 2018 at 07:16:43PM +1030, John Pearson wrote: > > Attempting to install a foreign arch package that depends on an "all" > > architecture package fails, as apt looks for a copy of the "all" arch > > package that is explicitly built for the same arch as the package I'm > > installing. > > That's not a bug. Architecture: all packages need to explicitly declare > that they are usable by foreign architectures by setting Multi-Arch: foreign. > > > The following packages have unmet dependencies: > > vim-tiny:i386 : Depends: vim-common:i386 (= 2:8.0.0197-4+deb9u1) but it > > is not installable > > E: Unable to correct problems, you have held broken packages. > > vim-common is not Multi-Arch: foreign. Thanks for the analysis. It's already fixed in git, but various upstream issues are blocking an upload. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#914479: sdl-ttf2.0 FTCBFS: uses the wrong pkg-config
Source: sdl-ttf2.0 Version: 2.0.11-5 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap sdl-ttf2.0 fails to cross build from source, because it uses the wrong pkg-config. It is a regression introduced in 2.0.11-5 for fixing #892435. The attached patch fixes it. Helmut --- sdl-ttf2.0-2.0.11.orig/configure.in +++ sdl-ttf2.0-2.0.11/configure.in @@ -113,7 +113,7 @@ FREETYPE_CONFIG=$freetype_prefix/bin/freetype-config fi fi -AC_PATH_PROG(FREETYPE_CONFIG, pkg-config, no) +AC_PATH_TOOL(FREETYPE_CONFIG, pkg-config, no) no_freetype="" if test "$FREETYPE_CONFIG" = "no" ; then AC_MSG_ERROR([
Bug#914478: document when --remove equals --purge and when it doesn't
Package: dpkg Version: 1.19.2 Severity: minor File: /usr/share/man/man1/dpkg.1.gz After: -r, --remove package...|-a|--pending Remove an installed package. This removes everything except conffiles, which may avoid having to reconfigure the package if it is reinstalled later (conffiles are configuration files that are listed in the DEBIAN/conffiles control file). Important to please add: "If there is no DEBIAN/conffiles control file, then --remove is exactly equivalent to --purge." Else users will wonder why some dpkg --remove $@ && dpkg --purge $@ will succeed, and some will fail. Especially as you also say -P, --purge package...|-a|--pending Purge an installed or already removed package.
Bug#914477: rspamd: autopkgtest is flaky
Source: rspamd Version: 1.8.1-2 Severity: impotant Hi, It seems the autopkgtest randomly fails, see: https://ci.debian.net/packages/r/rspamd/testing/amd64/ Kurt
Bug#914476: flint-arb FTCBFS: ./configure needs to be told about crossing
Source: flint-arb Version: 1:2.14.0-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap flint-arb fails to cross build from source. Nothing tells its ./configure about cross compilation, so it misses dependencies while building for the wrong architecture. The attached patch adds the most important flags and while the value passed for --build is not exactly what it needs, it seems to be good enough for a couple of architectures. Please consider applying it. Helmut diff --minimal -Nru flint-arb-2.14.0/debian/changelog flint-arb-2.14.0/debian/changelog --- flint-arb-2.14.0/debian/changelog 2018-09-26 20:25:16.0 +0200 +++ flint-arb-2.14.0/debian/changelog 2018-11-23 19:41:26.0 +0100 @@ -1,3 +1,10 @@ +flint-arb (1:2.14.0-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Tell ./configure about cross compiling. (Closes: #-1) + + -- Helmut Grohne Fri, 23 Nov 2018 19:41:26 +0100 + flint-arb (1:2.14.0-4) unstable; urgency=medium * Team upload. diff --minimal -Nru flint-arb-2.14.0/debian/rules flint-arb-2.14.0/debian/rules --- flint-arb-2.14.0/debian/rules 2018-09-26 20:25:16.0 +0200 +++ flint-arb-2.14.0/debian/rules 2018-11-23 19:41:17.0 +0100 @@ -9,11 +9,16 @@ %: dh $@ +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +include /usr/share/dpkg/buildtools.mk +CONFIGURE_FLAGS = --build=$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS) CC=$(CC) CXX=$(CXX) AR=$(AR) +endif + # upstream Makefile has only CFLAGS, not CPPFLAGS and not even CXXFLAGS, so # inject flags using configure. let's hope CFLAGS will always be good enough # even for $(CXX) override_dh_auto_configure: - ./configure --prefix=/usr --disable-static --with-flint=/usr CFLAGS='$(CPPFLAGS) $(CFLAGS)' + ./configure --prefix=/usr --disable-static --with-flint=/usr CFLAGS='$(CPPFLAGS) $(CFLAGS)' $(CONFIGURE_FLAGS) sed -i Makefile -e "s/libarb/libflint-arb/g" sed -i Makefile -e "s/-larb/-lflint-arb/g" sed -i Makefile -e "s|LIBDIR=lib|LIBDIR=lib/$(DEB_HOST_MULTIARCH)|g"
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
> cryptsetup-initramfs' ‘cryptroot’ is run (last) is local-top, so before > your own script. So ‘cryptroot’ is bound to fail after trying to open > the device a couple of times. Please move your script to local-top, and > maybe add a loop to make it block when the device is not present. I moved the script to local-top/ and now I'm unable to unlock the system container. I tried 15 times, and it can't detect the USB device. > I don't think it was ever working as it should. It was working well. I even wrote this HowTo: https://gist.github.com/morfikov/0bd574817143d0239c5a0e1259613b7d Based on what they told me here: https://lists.debian.org/debian-kernel/2018/03/msg00121.html So something has been changed somewhere. signature.asc Description: OpenPGP digital signature
Bug#473996: promptconfaction should offer vimdiff too
[Adding guil...@debian.org to CC] [Adding 473...@bugs.debian.org to CC] Hi Paul, > In order for this bug not to sit idle for yet another five years, > attached is my attempt at a patch. Alas, I don't think that this will merged simply because it hard- codes vimdiff. I tried applying one of the configurable variants of patch from: https://bugs.debian.org/120152#16 ... with some success but I am a little bit unsure about the approach and, of course, that code is now extremely old, crusty and as you can see it had some issues after review. Guillem, would you be amenable to applying any configurable patch if one was to magically appear? If so, would you have any other requirements or objections, either philosophically and technically? Knowing the answers there here the next step here I think, or we should just mark all of these bugs as wontfix with a suitable justification to ameliorate any frustration. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914475: stretch-pu: package pdns/4.0.3-1+deb9u3
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Managers,
pdns/4.0.3-1+deb9u3 would fix two important and two not-high-prio
security bugs:
* #898255: CVE-2018-1046 in dnsreplay (pdns-tools)
* #913163: CVE-2018-10851 (pdns)
* #889798: MySQL queries with stored procedures fail
* #911659: ldap, lua, opendbx backends don't actually find zones
I've been in contact with security@ about the CVEs.
debdiff below. The submitter for #889798 says the new package fixes
their problem.
Thanks,
Chris
diff -Nru pdns-4.0.3/debian/changelog pdns-4.0.3/debian/changelog
--- pdns-4.0.3/debian/changelog 2017-11-27 22:02:24.0 +
+++ pdns-4.0.3/debian/changelog 2018-11-10 13:36:22.0 +
@@ -1,3 +1,13 @@
+pdns (4.0.3-1+deb9u3) stretch; urgency=medium
+
+ * Fix (security) bugs, partially using upstream patches:
+* CVE-2018-1046 in dnsreplay (Closes: #898255)
+* CVE-2018-10851 (Closes: #913163)
+* MySQL queries with stored procedures (Closes: #889798)
+* ldap, lua, opendbx backend not finding domains (Closes: #911659)
+
+ -- Christian Hofstaedtler Sat, 10 Nov 2018 13:36:22 +
+
pdns (4.0.3-1+deb9u2) stretch; urgency=medium
* Add upstream patch fixing security issue:
diff -Nru
pdns-4.0.3/debian/patches/889798-auth-Always-bind-the-results-array-after-executing-a.patch
pdns-4.0.3/debian/patches/889798-auth-Always-bind-the-results-array-after-executing-a.patch
---
pdns-4.0.3/debian/patches/889798-auth-Always-bind-the-results-array-after-executing-a.patch
1970-01-01 00:00:00.0 +
+++
pdns-4.0.3/debian/patches/889798-auth-Always-bind-the-results-array-after-executing-a.patch
2018-11-10 13:36:22.0 +
@@ -0,0 +1,71 @@
+From 4fd90e75d47d6ec43d10c94ea260b08e50806442 Mon Sep 17 00:00:00 2001
+From: Remi Gacogne
+Date: Tue, 2 Jan 2018 17:03:47 +0100
+Subject: [PATCH] auth: Always bind the results array after executing a
+ statement
+
+We will reuse the same array most of the time, but it turns out that
+calling mysql_stmt_next_result() followed by mysql_stmt_store_result()
+invalidates the existing binding (the first one sets stmt->bind_result_done
+to false, causing the second to reset the existing binding).
+---
+ modules/gmysqlbackend/smysql.cc | 31 +++
+ 1 file changed, 19 insertions(+), 12 deletions(-)
+
+diff --git a/modules/gmysqlbackend/smysql.cc b/modules/gmysqlbackend/smysql.cc
+index aab16daf9..8a2a5092a 100644
+--- a/modules/gmysqlbackend/smysql.cc
b/modules/gmysqlbackend/smysql.cc
+@@ -182,7 +182,7 @@ public:
+ // prepare for result
+ d_resnum = mysql_stmt_num_rows(d_stmt);
+
+- if (d_resnum>0 && d_res_bind == NULL) {
++ if (d_resnum > 0 && d_res_bind == nullptr) {
+ MYSQL_RES* meta = mysql_stmt_result_metadata(d_stmt);
+ d_fnum = static_cast(mysql_num_fields(meta)); // ensure correct
number of fields
+ d_res_bind = new MYSQL_BIND[d_fnum];
+@@ -201,12 +201,17 @@ public:
+ }
+
+ mysql_free_result(meta);
+-
+-if ((err = mysql_stmt_bind_result(d_stmt, d_res_bind))) {
+- string error(mysql_stmt_error(d_stmt));
+- releaseStatement();
+- throw SSqlException("Could not bind parameters to mysql statement:
" + d_query + string(": ") + error);
+-}
++ }
++
++ /* we need to bind the results array again because a call to
mysql_stmt_next_result() followed
++ by a call to mysql_stmt_store_result() might have invalidated it
(the first one sets
++ stmt->bind_result_done to false, causing the second to reset the
existing binding),
++ and we can't bind it right after the call to
mysql_stmt_store_result() if it returned
++ no rows, because then the statement 'contains no metadata' */
++ if (d_res_bind != nullptr && (err = mysql_stmt_bind_result(d_stmt,
d_res_bind))) {
++string error(mysql_stmt_error(d_stmt));
++releaseStatement();
++throw SSqlException("Could not bind parameters to mysql statement: "
+ d_query + string(": ") + error);
+ }
+ }
+
+@@ -252,13 +259,13 @@ public:
+ if ((err = mysql_stmt_store_result(d_stmt))) {
+ string error(mysql_stmt_error(d_stmt));
+ releaseStatement();
+- throw SSqlException("Could not store mysql statement: " + d_query +
string(": ") + error);
++ throw SSqlException("Could not store mysql statement while
processing additional sets: " + d_query + string(": ") + error);
+ }
+ d_resnum = mysql_stmt_num_rows(d_stmt);
+ // XXX: For some reason mysql_stmt_result_metadata returns NULL here,
so we cannot
+ // ensure row field count matches first result set.
+-if (d_resnum>0) { // ignore empty result set
+- if ((err = mysql_stmt_bind_result(d_stmt, d_res_bind))) {
++if (d_resnum > 0) { // ignore empty result set
++
Bug#914474: sphinx-testing: Please update to v0.8.1 which is compatible with Sphinx 1.8
Package: python3-sphinx-testing Version: 0.7.2-0.1 Severity: important User: python-modules-t...@lists.alioth.debian.org Usertags: sphinx1.8 Dear maintainer, Please update sphinx-testing to the latest upstream version. It fixes compatibility issues with the latest Sphinx: https://github.com/sphinx-doc/sphinx-testing/issues/8 and https://github.com/sphinx-doc/sphinx-testing/issues/9. I will be happy to NMU it if you don’t mind. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2
Hello, Am Freitag, den 23.11.2018, 16:30 +0100 schrieb Emmanuel Promayon: > Dear all > > Thank to Paul for your answers about the autoremoval and explanation > about the ABI problem. It seems that Adrian Bunk's triage message in > 909120 (added blocking bug(s) of 909120: 911793) did push the > autoremoval for another month (thanks to Adrian as well, as that's > exactly what is happening). > > Thank you to Mattia for finding the ABI problem and to Matthieu for > his comments. > > Thank you to Gert for the explanation about vtk7 (by the way do you > have any idea about the possible future introduction of vtk8 or > vtk9?). The problem is that I moved to a different work which is rather unrelated to using VTK, so my personal interest there is quite limited. There was also some discussion of actually using paraview as a vehicle to also bring in the VTK libraries, because paraview has them bundled and it seems to be difficult to unbundle them. > You are right about camitk-imp and camitk-config: they are not > linked > with gdcm. When camitk-imp or camitk-config are run they load some > plugins (e.g. the dicom plugin) that itself is linked with gdcm. > Running ldd on one of the pluging get the similar missing vtk > symbols and so. So I suppose the problem is in vtk7 I found the problem with the missing libraries, it was indeed something I messed up when I removed the QT dependency on armhf/armel. > > From what I can understand (sorry in advance for any approximation > or stating the obvious): > 1) gdcm 2.8.7-2 moved to python3 (probably because a move from > python2 to python3 was required) which I think triggered the choice > of moving from vtk6 to vtk7 (which probably made more sense, as I > presume vtk6 is also on its way out of buster). AFAIK vtk6 doesn't support python3 at all, and the general idea is to at least minimize the use of vtk6, only provide the libraries, but let vtk7+ provide the language bindings. It will not be possible to remove it completely because of the switch to OpenGL 3.2 in vtk7 which breaks a number of reverse dependecies (ginkgocadx and maybe also itksnap). > 2) When gdcm 2.8.7-2 arrived in sid, it generated a SegFaults > during camitk 4.1.2-1 as camitk 4.1.2-1 was still based on vtk6, and > loading any camitk executable meant that both vtk6 and vtk7 were > loaded in memory. This is where I messed up a bit, because I didn't expect that vtkgdcm would export symbols from vtk, and I didn't check the reverse dependencies because I was only focused on python3 (and there inveselius), but this is independend from camitk pulling in two versions of vtkm, even if vtkgdcm would not export VTK symbols then this would still have been a problem. > 3) camitk 4.1.2-2 introduced a patch so that it only depends on vtk7 > (and like gdcm 2.8.7 without changing the upstream source version). > 4) gdcm 2.8.7-5 then fixed the double dependency to vtk6 and vtk7 > but camitk 4.1.2-2 was not rebuilt against it, therefore generating > the initial error that triggered bug #911793 > 5) vtk7 (which was updated in the meantime) seems to have now some > missing libraries and as hdf5 is broken as well camitk 4.1.2-2 can > not be rebuilt yet I'm noit so sure about the inbetween parts, but the last step is correct. I just have to check the pytjon problem, and then I should be able to upload a new vtk7 version. > > Let me know if there is anything I can do to help. > > On a side discussion: > Does the fact that I moved the dependency of camitk from vtk6 in > 4.1.2-1 to vtk7 in 4.1.2-2 might generate another ABI break? AFAICS camitk is a leaf package, so there shouldn't be any ABI break possible. > If this is the case, I will take any advice regarding how to specify > this properly! I will also welcome any information/documentation > about how to track the symbol. I tried to tdo this once, but with C++ libraries and templates it was not quite streightforward, so I gave up on it. Best, Gert
Bug#911542: ledgersmb 1.6.6+ds-2: Please update package po/pl.po debconf file
> Thu Nov 22 2018 12:34:04 PM EST from "Łukasz" > Subject: Re: ledgersmb 1.6.6+ds-2: Please update >package po/pl.po debconf file > > 22.11.2018 09:17, Robert James Clay wrote: > > >>Please send the updated file to me, or submit it as a wishlist bug against >>ledgersmb. The deadline for receiving the updated translation is Thu, 6 >>December 2018 19:51:03 -0400. >> > I tried to update it. I hope it is correct. > > Best regards, > Łukasz Dulny > > > Very much appreciated! I've imported the updated file into the packaging repository and will include it in the next new package release. Thanks! pl.po.gz Description: application/gzip
Bug#914469: sudo: Truncated sudo(8) man page
Control: forwarded -1 https://bugzilla.sudo.ws/show_bug.cgi?id=861 On 2018-11-23 18:26 +0100, Guillem Jover wrote: > Package: sudo > Version: 1.8.26-1 > Severity: normal > > Hi! > > The sudo(8) man page appears to be truncated, as it has no content > after the -A option. This has also been reported upstream today. A fix is at https://www.sudo.ws/repos/sudo/rev/7ddfb74781a1. Cheers, Sven
Bug#914473: RFS: pentobi/16.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pentobi". * Package name: pentobi Version : 16.1-1 Upstream Author : Markus Enzenberger * URL : https://pentobi.sourceforge.io * License : GPLv3+ Section : games It builds those binary packages: pentobi - clone of the strategy board game Blokus pentobi-kde-thumbnailer - clone of the strategy board game Blokus - KDE thumbnailer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pentobi Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pentobi/pentobi_16.1-1.dsc This is the Git repository: https://salsa.debian.org/games-team/pentobi Changes since the last upload: * New upstream release. * Declare compliance with Policy 4.2.1. - Do not rename NEWS to changelog; that has been deprecated. * Add new Build-Depends. * Add Depends on required qml-module-* packages. * Export QT_SELECT to avoid "could not find a Qt installation of ''". * The help files and game resources are now bundled into the executable. - d/pentobi.install: Removed usr/share/games and usr/share/help. - d/pentobi.doc-base.*: Removed. * d/pentobi-kde-thumbnailer.install: Update metainfo filename. * Re-add "Enhances: konqueror" for -kde-thumbnailer because that has become true again. Regards, Juhani
Bug#914457: [Pkg-nagios-devel] Bug#914457: icingacli: any command issued to icingacli rise an exception
Control: tags -1 upstream pending This issue is caused by PHP 7.3, see: https://bugs.php.net/bug.php?id=76753 I've added a patch to fix the issues in the icingaweb2 code, and a new upload to unstable will follow shortly. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#913645: Oldstable also affected
Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: > Hi, > >> I have however not yet tested what happens if you start thunderbird >> aftter the upgrade and close it right away (i.e. not trying to sign >> anything but also not entering the master password). I will try to test >> this later but now I need a working mail client. >> > > I also tested this variant now: > > 1. Have berkeley DB based profile that works fine with thunderbird 52 in > Jessie > 2. Upgrade thunderbird > 3. Start thunderbird > 4. Close it without doing anything (I am not prompted for the master > password) > 5. Start thunderbird again > > Expected results: > Either key3.db is still there or I am getting prompted for a master > password during step 4. > > Actual results: > Everything under "Your certificates" and "People" in the Certificate > Manager gone, all saved passwords gone. > > So the problem we encountered did not only wipe private keys, but also > certificates of other people I already corresponded with AND stored > passwords. thanks for testing this, I'm unable to this as I don't use any of these features. > How should reporting with upstream be handled? Should I take care of it > myself or would you like to forward it? I'd prefer if you could do the interaction with upstream as I only would act as a man in the middle. And I haven't much time to work on Thunderbird now. Please give a note back about the upstream bug number so we can add a forwarding to this issue. Thanks! -- Regards Carsten Schoenert
Bug#914472: dracut module 09-console-setup is a regression against 10i18n genuine module.
Package: dracut Version: 040+1-1 up to latest Severity: wishlist Dear Maintainer, * What led up to the situation? => I'm SystemImager developper, and my dracut module requires i18n (same mobule across all linux distro flavors, usefull when an emergency shell is triggered) * What exactly did you do (or not do) that was effective (or ineffective)? => Trying to port my module to debian raised an error: can't install my module because it depends on i18n one. => The primitive 09-console-setup is a regression as it doesn't allow end user to configure console via cmdline parameters. The primitive module provides no hook to parse some specific parameters like rd.vconsole.keymap (or font or any other parameters) => the primitive 09-console-setup doesn't install the following binaries (stty, setfont, loadkeys, kbd_mode) that can be very usefull to end user when an emergency shell is triggered * What was the outcome of this action? => Can't build systemimager initrd.img imager. Need to add a specific module-setup.sh for my module when built on debian, also need to add some conditions in many hooks to handle this regression and do stuffs myself. * What outcome did you expect instead? => At least SOMETHING STANDARD: an i18n module that would be optional (present in dracut debian package thus, but that wouldn't interfere with debianisms), that would require and usedebian PROPRIETARY WITH NO VALUE ADDED 09-console-setup primitive module, that would provides the cmdline parser hook and that would install the common i18n binaries (stty, setfont, loadkeys, kbd_mode) Why by help do you cut down dracut while you could just add you 09-console-setup and have i18n module being made optional and use your module for concistency while keeping ability to take some parameters from cmdline and provide some tools to the user using emergency shell? Sorry fort this somewhat unfriendly report, but as a developper, Debian is the only distro that trigger specific case to handle for no visible benefit. this report is an exaple between many others. Even reporting a bug is far more difficult on this distro as there is no web bugzilla or equivalent. When developping in docker container in a company exchange based with no available SMTP gateway it's just horrible. what's the benefit over a standard web based bug reporting tool? -- System Information: Debian Release: 8.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.125-linuxkit (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages dracut depends on: ii console-setup 1.123 ii cpio 2.11+dfsg-4.1+deb8u1 ii kmod 18-3 ii kpartx 0.5.0-6+deb8u2 ii libc6 2.19-18+deb8u10 ii pkg-config 0.28-1 ii udev 215-17+deb8u8 ii util-linux 2.25.2-6 Versions of packages dracut recommends: ii cryptsetup 2:1.6.6-5 ii dmraid 1.0.0.rc16-5 ii dmsetup 2:1.02.90-2.2+deb8u1 ii lvm22.02.111-2.2+deb8u1 ii mdadm 3.3.2-5+deb8u2 Versions of packages dracut suggests: ii dracut-network 040+1-1 -- no debconf information
Bug#914470: gdc-8: ICE in gdc on call to defaulted alias template parameter that is a delegate literal
Package: gdc-8
Version: 8.2.0-9
Severity: normal
# cat perf_min.d
```
module perf_min;
void run(alias prep = delegate() {})() {
prep();
}
void main() {
run!()();
}
```
$ gdc perf_min.d
perf_min.d: In function ‘run’:
perf_min.d:3:5: internal compiler error: in get_frame_for_symbol, at
d/d-codegen.cc:2161
prep();
^
0x7f626f339b16 __libc_start_main
../csu/libc-start.c:310
$
gcc version 8.2.0 (Debian 8.2.0-9)
For comparison, when compiling using ldc2:
LDC - the LLVM D compiler (1.12.0):
based on DMD v2.082.1 and LLVM 6.0.1
built with LDC - the LLVM D compiler (1.12.0)
Default target: x86_64-pc-linux-gnu
there are no issues, and generate code looks correct.
Thanks.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gdc-8 depends on:
ii g++-8 8.2.0-9
ii gcc-8-base8.2.0-9
ii libc6 2.27-8
ii libgmp10 2:6.1.2+dfsg-3
ii libgphobos-8-dev 8.2.0-9
ii libisl19 0.20-2
ii libmpc3 1.1.0-1
ii libmpfr6 4.0.1-1
ii zlib1g1:1.2.11.dfsg-1
gdc-8 recommends no packages.
gdc-8 suggests no packages.
-- no debconf information
Bug#914471: linphone: new upstream 4.1.1
package: linphone severity: normal Please consider to upgrade to the current upstream version (4.1.1). Kind regards, Jonatan
Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times
Control: retitle -1 cryptsetup-initramfs: user is prompted for password even when the detached header is missing On Fri, 23 Nov 2018 at 17:05:13 +0100, Mikhail Morfikov wrote: > So, to open my laptop, I have to connect the USB device (my phone) > first. In order to make this work, I had to write some script and put > it in the /etc/initramfs-tools/scripts/local-block/mount-boot file. cryptsetup-initramfs' ‘cryptroot’ is run (last) is local-top, so before your own script. So ‘cryptroot’ is bound to fail after trying to open the device a couple of times. Please move your script to local-top, and maybe add a loop to make it block when the device is not present. > So where's the problem? Why it's not working well now, and it was > working in the past? I don't think it was ever working as it should. local-block scripts are called with the name of a local block device to create/unlock/activate (e.g. devices holding /usr). And they are run after local-top scripts, so they can assume that the root device node is present. AFAICT, what happened before is that the loop failed before the password prompt, so cryptroot failed early, and init moved to local-block without root device node. There, since /scripts/local-block/cryptroot doesn't depend on mount-boot, the script was likely run — and failed — another time before mount-boot had a chance to run, and the 3rd run cryptroot can finally succeed. All of this is brittle and racy, and broke when (inadvertently) removed the checks for detached header presence. -- Guilhem. signature.asc Description: PGP signature
Bug#914469: sudo: Truncated sudo(8) man page
Package: sudo Version: 1.8.26-1 Severity: normal Hi! The sudo(8) man page appears to be truncated, as it has no content after the -A option. Thanks, Guillem
Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth
On 23/11/2018 17:48, Guilhem Moulin wrote: > On Fri, 23 Nov 2018 at 17:27:11 +0100, Mikhail Morfikov wrote: >> On 23/11/2018 17:20, Guilhem Moulin wrote: >>> On Fri, 23 Nov 2018 at 17:09:24 +0100, Mikhail Morfikov wrote: Should the script be used when systemd takes care of opening the encrypted containers? Because it doesn't support those scripts. >>> >>> Indeed, but systemd isn't involved at initramfs stage. At this stage >>> unlocking is done by our own scripts from the ‘cryptsetup-initramfs’ >>> package (against which you filed this bug). >> >> So why when plymouth is installed, the system is able to use the kernel >> keyring >> without problems and hence successfully decrypt both of the drives with only >> one >> password? > > Because plymouthd caches them, too. See for instance > https://lists.debian.org/debian-user/2018/08/msg00031.html . > I think I get it now. Basically, what I wanted can't be done (the way I wanted). If I had two encrypted containers (none of them was the system one), I would open them via "systemctl start", and systemd would use the kernel keyring and open both containers with one password. If plymouth caches once typed password, it uses the password multiple times and that's why I don't have to type the password manually again. But in this way plymouth doesn't use the kernel keyring -- that's why the root keyring is empty after unlocking the system container. So, there are 3 different mechanisms (crypttab, systemd, plymouth) and they aren't compatible with each other. So the solution would be to use systemd+plymouth or to disable systemd generator for encrypted devices and use crypttab instead with the keyctl script. I could use either one, but I thought this can be done by using only systemd. signature.asc Description: OpenPGP digital signature
Bug#889798: Bug#913163: (Security) bugs in pdns in stretch
* Moritz Mühlenhoff [181123 14:09]: > On Sat, Nov 10, 2018 at 04:34:48PM +0100, Chris Hofstaedtler wrote: > > Hi everyone, > > > > thanks for reporting bugs against pdns in stretch. > > I intend to upload a new version to stretch to fix those bugs, but I > > cannot test all involved components personally. Please give this > > version a shot: > > @Chris: Was there any test feedback so far? Xan Charbonnet has tested it and gave a positive response (mostly for #889798 I'd imagine). Some more feedback wouldn't hurt. Cheers, Chris
Bug#914467: RM: swt-gtk -- ROM; No longer used, superseded by swt4-gtk
Package: ftp.debian.org Severity: normal Hi, Please remove the swt-gtk package. It's an old version of SWT that was only used for the needs of src:eclipse, and it's about to be removed (#914448). swt4-gtk should now be used instead. Thank you, Emmanuel Bourg
Bug#883245: Thunderbird Not Opening HTTP, HTTPS URLs With Vivaldi
Hi, ftr, the cloned issue is living in 914403. https://bugs.debian.org/914403 Am 23.11.18 um 14:08 schrieb David Campbell: > Carsten, > > Thanks for your thoughtful response! Sorry if in my debugging I rang > the Thunderbird alarm bell. Only later did I realize this was an > AppArmor profile issue. > > Thanks again, > > Best regards, > > David Campbell -- Regards Carsten Schoenert
Bug#914360: Bug #914360: tinc: Random segfault after connection drop
Hello Maximilian, Am 23.11.2018 um 16:58 schrieb Maximilian Stein: > Maybe the connection object ptr c > was free'd or NULL? Yes, I think c was NULL at the time of the crash. Kind regards, Bernhard
