Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)
Hi Shayan, more pinging the bug to extend the period the package stays in testing but in case you might have any temporary results for this issue feel free to post these here. Kind regards, Andreas. On Sat, Sep 21, 2019 at 07:05:27PM +0200, Andreas Tille wrote: > Hi Shayan, > > On Sat, Sep 21, 2019 at 05:23:49PM +0100, Shayan Doust wrote: > > This is new territory - I have spent some time looking at this and so far I > > could only reproduce all of what was already mentioned above. > > It might become time consuming. > > > I will later go more in-depth and try using mem profiling / debugging and > > some trial and error to try figure out why this gets a segmentation fault > > because this issue is really annoying and needs rectifying. > > In any case yes. While I guess the program is not used in really security > relevant context you can never know and this kind of crash is a security > issue (besides the fact that it just does not the job its supposed to do). > > Thanks for working at this > > Andreas. > > -- > http://fam-tille.de > -- http://fam-tille.de
Bug#941467: fixed in samba 2:4.11.0+dfsg-7
Le jeudi 3 octobre 2019, Jeremy Bicha a écrit : > Control: reopen 941467 > > Oops, it looks like this fix didn't work either. Argh! At least ldb is now fixed. > > https://buildd.debian.org/status/package.php?p=samba > > Thanks, > Jeremy > -- Mathieu
Bug#941628: ITP: fasttext -- Library for efficient learning of word representations and sentence classification
Package: wnpp Severity: wishlist * Package name: fasttext Version : 0.9.1 Upstream Author : 2016-present, Facebook, Inc. * URL : https://github.com/facebookresearch/fastText * License : BSD-3-Clause Programming Lang: C++ Description : Library for efficient learning of word representations and sentence classification fastText is a library for efficient learning of word representations and sentence classification, which refers subword information to enrich word vectors.
Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation
(re-sent due to incorrect CC address in last post) Hi NOKUBI, Thank you for working on this. Although it may sound boring or even frustrating, data used for training machine learning models, or pre-trained machine learning models should be carefully dealt with. Your copyright file is not complete https://bitbucket.org/tsuchm/pkg-sentencepiece/src/master/debian/copyright at least one file in data/ directory are not apache-2.0 licensed: https://github.com/google/sentencepiece/blob/master/data/botchan.txt#L1-L12 https://github.com/google/sentencepiece/blob/master/data/Scripts.txt#L1-L13 and I'm wondering whether the Japanese poetry book is free: (I don't speak Japanese but from the "Chinese characters" within the text I guess it's a poetry book) https://raw.githubusercontent.com/google/sentencepiece/master/data/wagahaiwa_nekodearu.txt as its publisher is 青空文庫. Please confirm the copyright information for this book and its DFSG compliance. When there are DFSG-incompatible stuff in a source package, a common practice in Debian is to strip those components from the original tarballs and prefix the version string with +dfsg. However, data-driven applications could become useless when the training data was removed... This is an awkward difficulty, or say conflict in practice between free software world and the academical machine learning (computational linguistics) community. Besides, the packaging of tensorflow is stalled, as it's difficult to tame the 4.5 million lines of code without a usable build system. For a long time the users (including myself) have to (somewhat) depend on third party ecosystems until the day Google started to rethink about distribution integration (basically hopeless). Apart from the science team, you are welcome to join the deep learning team as well: https://salsa.debian.org/deeplearning-team (it's an informal team) On 2019-10-03 02:37, NOKUBI Takatsugu wrote: > On Wed, 02 Oct 2019 14:52:23 +0900, > Kentaro Hayashi wrote: >> * Vcs : https://salsa.debian.org/debian/sentencepiece > > It contains tensorflow binding, so I think it will be good to belong > with Debian Science Team. > > I, hayashi-san, and tsuchiya-san sent requests to join the team. > tsuchiya-san also maintained it himself, so I'll merge them into > the salsa repository. > > https://bitbucket.org/tsuchm/pkg-sentencepiece/src/master/
Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation
Hi NOKUBI, Thank you for working on this. Although it may sound boring or even frustrating, data used for training machine learning models, or pre-trained machine learning models should be carefully dealt with. Your copyright file is not complete https://bitbucket.org/tsuchm/pkg-sentencepiece/src/master/debian/copyright at least one file in data/ directory are not apache-2.0 licensed: https://github.com/google/sentencepiece/blob/master/data/botchan.txt#L1-L12 https://github.com/google/sentencepiece/blob/master/data/Scripts.txt#L1-L13 and I'm wondering whether the Japanese poetry book is free: (I don't speak Japanese but from the "Chinese characters" within the text I guess it's a poetry book) https://raw.githubusercontent.com/google/sentencepiece/master/data/wagahaiwa_nekodearu.txt as its publisher is 青空文庫. Please confirm the copyright information for this book and its DFSG compliance. When there are DFSG-incompatible stuff in a source package, a common practice in Debian is to strip those components from the original tarballs and prefix the version string with +dfsg. However, data-driven applications could become useless when the training data was removed... This is an awkward difficulty, or say conflict in practice between free software world and the academical machine learning (computational linguistics) community. Besides, the packaging of tensorflow is stalled, as it's difficult to tame the 4.5 million lines of code without a usable build system. For a long time the users (including myself) have to (somewhat) depend on third party ecosystems until the day Google started to rethink about distribution integration (basically hopeless). Apart from the science team, you are welcome to join the deep learning team as well: https://salsa.debian.org/deeplearning-team (it's an informal team) On 2019-10-03 02:37, NOKUBI Takatsugu wrote: > On Wed, 02 Oct 2019 14:52:23 +0900, > Kentaro Hayashi wrote: >> * Vcs : https://salsa.debian.org/debian/sentencepiece > > It contains tensorflow binding, so I think it will be good to belong > with Debian Science Team. > > I, hayashi-san, and tsuchiya-san sent requests to join the team. > tsuchiya-san also maintained it himself, so I'll merge them into > the salsa repository. > > https://bitbucket.org/tsuchm/pkg-sentencepiece/src/master/
Bug#941627: ITP: grub-btrfs -- provides grub entries for btrfs snapshots (boot environments/restore points)
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Control: block -1 by #840248 Package name: grub-btrfs Version : 4.1 Upstream Author : Antynea URL : https://github.com/Antynea/grub-btrfs License : GPL-3+ Programming Lang: bash Description : GRUB entries for btrfs snapshots (boot environments/restore points) Grub-btrfs generates grub entries for btrfs snapshots, thus making it easy to roll back to a known-good state. Other operating systems call this functionality "system restore points" or "boot environments" (aka: BEs). This package supports booting from manual snapshots stored in a predefined location, and appears to also support snapper (it seems the snapper support may be buggy in the v4.1 release). At present, snapshots must be the read-write type, but it should be possible to extend this software to the following from an initramfs: make a rw BE from a ro snapshot during the premount stage. I've been waiting for this software to mature for a couple of years before filing an ITP, and it looks like it's finally ready to validate. I've blocked this ITP by "debian-installer: Add btrfs subvolume setting for snapshot" because I do not believe that this package is useful until a default Debian installation using btrfs provides separation between rootfs and user data. That said, I believe that it is appropriate to work on it in the experimental suite. It is probably most useful for people who want to track sid, but with insurance against having to back out of an upgrade when they don't have any free time. Ideally I'd like to form a btrfs-task force to work on related issues and maintain this package there, but as of yet no one has shown interest in such a team. If you are interested, please speak up! I will need a sponsor for the initial upload. Regards, Nicholas
Bug#941626: Needs additional information for apparmor and the use of "sysvinit"
Package: haveged Version: 1.9.1-7 Severity: important Dear Maintainer, * What led up to the situation? No haveged process was reported by "ps ax" (seen after switching from default "systemd" to "sysvinit"). * What exactly did you do (or not do) that was effective (or ineffective)? Issued "invoke-rc.d haveged start" * What was the outcome of this action? No file named /run/haveged.pid. Message in the syslog, see Debian bug #911604. This bug should be visible in the "Bug Reports" page!!! (And not yet archieved). * What outcome did you expect instead? The version for buster must have the added information as reported in the mentioned bug report (put in the main file /etc/apparmor.d/usr.sbin.haveged) The date of first line in that file should be updated (is the same for buster as for testing) -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages haveged depends on: ii libc6 2.28-10 ii libhavege1 1.9.1-7 ii lsb-base10.2019051400 haveged recommends no packages. Versions of packages haveged suggests: ii apparmor 2.13.2-10 -- Configuration Files: /etc/init.d/haveged changed [not included] -- no debconf information -- Bjarni I. Gislason
Bug#941625: saned: Pid file is not removed when the package is purged
Package: sane-utils Version: Severity: minor Dear Maintainer, * What led up to the situation? Purging the package "sane-utils". * What exactly did you do (or not do) that was effective (or ineffective)? Looking later into the directory "/run/" * What was the outcome of this action? Saw the file "sane.pid" containing the process number 2404, which did not exist (as expected) in the output of "ps ax". * What outcome did you expect instead? No "sane.pid" file in the "/run" directory -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages sane-utils depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libc6 2.28-10 pn libieee1284-3 ii libjpeg62-turbo1:1.5.2-2+b1 ii libpng16-161.6.36-6 pn libsane ii libsystemd0241-7~deb10u1 ii libusb-1.0-0 2:1.0.22-2 ii lsb-base 10.2019051400 ii update-inetd 4.49 sane-utils recommends no packages. Versions of packages sane-utils suggests: pn avahi-daemon pn unpaper -- Bjarni I. Gislason
Bug#531855: strace -f mishandling of raise(SIGSTOP) in child
Control: tags -1 +fixed-upstream A ptrace API extension called PTRACE_SEIZE has been implemented to fix this issue. It's available in strace since version 4.8.
Bug#459820: strace: Shows wrong system call
Control: tags -1 +upstream A ptrace API extension called PTRACE_GET_SYSCALL_INFO has been implemented to fix this longstanding issue. Both strace >= 4.26 and linux kernel >= 5.3 are required to make the fix available. -- ldv
Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation
On Wed, 02 Oct 2019 14:52:23 +0900, Kentaro Hayashi wrote: > * Vcs : https://salsa.debian.org/debian/sentencepiece It contains tensorflow binding, so I think it will be good to belong with Debian Science Team. I, hayashi-san, and tsuchiya-san sent requests to join the team. tsuchiya-san also maintained it himself, so I'll merge them into the salsa repository. https://bitbucket.org/tsuchm/pkg-sentencepiece/src/master/
Bug#692915: strace: Add an option to prevent constant interpretation
Control: tags -1 +upstream Starting with version 4.23, strace implements -X option that specifies format for printing named constants and flags.
Bug#153679: strace: Should support backgrounding
Control: tags -1 +upstream strace implements -D option (run tracer process as a detached grandchild), it's documented since strace 4.6.
Bug#176376: strace: -z option doesn't work properly
Control: tags -1 +upstream The -z option is properly implemented since strace 5.2.
Bug#929715: strace: FTBFS: failure in lstat tests
Control: tags -1 +upstream Fixed upstream by commit v5.3-13-gf51a9396b.
Bug#939860: ITP: sentencepiece/0.1.83
Current status updates: RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941569 is done, gets a feedback, found a sponsor(@knok) and a collabolator (@tsuchm). Regards,
Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation
Hi, Thank you for reviewing. It is very helpful. On Wed, 2 Oct 2019 23:13:45 +0200 Adam Borowski wrote: > On Wed, Oct 02, 2019 at 02:52:23PM +0900, Kentaro Hayashi wrote: > > * Package name: sentencepiece > >Version : 0.1.83+dfsg-1 > >Upstream Author : Google Inc. > > * URL : https://github.com/google/sentencepiece snip > Hi! > The runtime library package (ie, libsentencepiece) should have soname > appended. This might be not a big change, but amending this later would > require a trip through NEW, thus let's get it right from the start. > > The watch file also should mangle the version, to include +dfsg. > > It is inappropriate to make lintian overrides for real bugs (like a lack of > manpage). You are not required to fix everything immediately -- heck, there > are many bugs that don't get fixed ever -- but that's not a valid use for > overrides. They're for false positives. > > But overall, the package seems almost ready. I could find a sponsor personally (@knok) and a collabolator(@tsuchm), so I'll fix above issues with them. Thanks!!! Regards,
Bug#941624: Recommending ibus breaks fcitx
Package: gnome-shell Version: 3.34.0-2 Severity: important I've been using fcitx as the default Chinese input method for decades. Recommending ibus simply breaks everything for me. Oct 03 01:23:57 Macadamia fcitx.desktop[2905]: (ERROR-10874 ime.c:432) fcitx-keyboard-in-kan-kagapa already exists Oct 03 01:23:57 Macadamia fcitx.desktop[2905]: (ERROR-10874 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists Oct 03 01:23:57 Macadamia fcitx.desktop[2905]: (ERROR-10874 ime.c:432) fcitx-keyboard-cm-mmuock already exists Oct 03 01:23:57 Macadamia fcitx.desktop[2905]: (ERROR-10874 xim.c:239) Start XIM error. Another XIM daemon named ibus is running? Oct 03 01:23:57 Macadamia fcitx.desktop[2905]: (ERROR-10874 instance.c:443) Exiting. ^ ibus (which I never use) was already running, so fcitx won't start. Please revert 220 * debian/control.in: Recommends ibus, gnome-shell tried to start for years 221 now, ibus is required to input emoji these days. (Closes: #815050) Or find a better solution, e.g. Recommends: ibus | fcitx |
Bug#941623: RM: xenwatch -- RoQA; unmaintained, depends on libgtk-vnc-1.0-0
Package: ftp.debian.org X-Debbugs-Cc: xenwa...@packages.debian.org Please remove xenwatch from Debian. xenwatch was orphaned a decade ago and hasn't had an upstream release since then. It is currently blocking the upload of gtk-vnc 1.0.0 because the new version of gtk-vnc drops the old gtk2 bindings (libgtk-vnc-1.0-0). xenwatch is the only package in Debian to depend on the gtk2 library. I've never used xenwatch, but I believe there are alternative maintained apps in Debian like virt-manager, virt-viewer, and gnome-boxes. Orphan bug: https://bugs.debian.org/540593 https://gitlab.gnome.org/GNOME/gtk-vnc/blob/master/NEWS Thanks, Jeremy Bicha
Bug#941622: man-db: man(1) manpage does not mention MAN_DISABLE_SECCOMP=1 environment variable
Package: man-db Version: 2.8.5-2 Severity: normal Dear Maintainer, man1/man.1.gz manpage should document all enviroment variables it uses. It includes: - MAN_DISABLE_SECCOMP=1 - PIPELINE_DEBUG=1 Those are usually only used for debugging, but so is MAN_KEEP_STDERR, which is correctly documented in man(1) manpage. Having them undocumented/unmentioned makes a life much more complicated for casual bug reporter, and sysadmins trying to troubleshoot apparmor/seccomp related bugs. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii groff-base 1.22.4-3 ii libc6 2.28-10 ii libgdbm6 1.18.1-4 ii libpipeline1 1.5.1-2 ii libseccomp22.4.1-2~bpo10+1 ii zlib1g 1:1.2.11.dfsg-1 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor 2.13.2-10 ii chromium [www-browser] 76.0.3809.100-1~deb10u1 ii elinks [www-browser] 0.13~20190125-3 ii firefox-esr [www-browser] 60.9.0esr-1~deb10u1 ii groff 1.22.4-3 ii less 487-0.1+b1 ii lynx [www-browser] 2.8.9rel.1-3 ii surf [www-browser] 2.0+git20181009-4 ii w3m [www-browser] 0.5.3-37 -- Configuration Files: /etc/apparmor.d/usr.bin.man changed [not included] /etc/manpath.config changed [not included] -- debconf information excluded
Bug#933548: transition: gnome-desktop3
On Wed, Oct 2, 2019 at 3:00 PM Paul Gevers wrote: > If my view of things is > up-to-date and correct, it's the last piece of the puzzle There are also several autopkgtest failures triggered by glib2.0 and gobject-introspection. Jeremy
Bug#941467: fixed in samba 2:4.11.0+dfsg-7
Control: reopen 941467 Oops, it looks like this fix didn't work either. https://buildd.debian.org/status/package.php?p=samba Thanks, Jeremy
Bug#941621: Mention where to find the standard perm_map for seinfoflow
Package: setools Version: 4.2.2-1+b1 Severity: wishlist Maybe it would be helpful to mention in the man page of seinfoflow where to find the standard permission map. (It is at /var/lib/sepolgen/perm_map in package python3-sepolgen) --- seinfoflow.1.bak2019-10-03 01:54:49.426056708 +0200 +++ seinfoflow.12019-10-03 02:01:27.382966149 +0200 @@ -18,6 +18,11 @@ If no policy file is provided, \fBseinfoflow\fR will search for the policy running on the current system. If no policy can be found, \fBseinfoflow\fR will print an error message and exit. +.SH PERMISSION MAP +.PP +A file containing mappings of object permissions for object classes. These mappings are the basis on how to compute the infoflow between types. +On Debian a standard permission map can be found when the package \fBpython3-sepolgen\fR is installed at \fI/var/lib/sepolgen/perm_map\fR. + .SH OPTIONS .SS Analysis Settings .IP "-p POLICY"
Bug#941620: RFS: gedit-plugin-copy-file-path/0.5.0 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gedit-plugin-copy-file-path": * Package name: gedit-plugin-copy-file-path Version : 0.5.0 Upstream Author : Willian Gustavo Veiga * URL : https://github.com/willianveiga/gedit-copy-file-path/pull/3/files * License : GPL3 * Vcs : https://github.com/willianveiga/gedit-copy-file-path.git Regards, -- Willian Gustavo Veiga
Bug#820153: rfcmarkup is deprecated
rfcmarkup has been deprecated upstream, and will be replaced by rfc2html, which can be found by svn at: https://svn.tools.ietf.org/svn/src/rfc2html/trunk If we want something like this in debian, it should probably be rfc2html instead of rfcmarkup, which is why i'm closing #820153. --dkg signature.asc Description: PGP signature
Bug#941559: libxvidcore4: immediately crashes on amd64 since binNMU
Hi, On 02/10/2019 11:47, Fabian Greffrath wrote: > Hi James, > > Am 02.10.2019 01:45, schrieb James Cowgill: >> Indeed readelf contains some non-executable program headers in >> 2:1.3.5-1+b1 which do not appear in 2:1.3.5-1 in buster. The >> ".rotext" section sounds suspicious. > > indeed, the check_cpu_feature() function is defined in > src/utils/x86_asm/cpuid.asm [1] which includes src/nasm.inc, which in > turn declares a .rotext section [2] for any other output format than > macho32 and macho64. > > It would probably be the best patch this to simply declare a .text > section for all output formats. The question remains, however, why this > is an issue now but not when xvidcore_2:1.3.5-1 was uploaded? I had a play around and I think this is caused by the "-z separate-code" option being enabled by default in binutils >= 2.31. With that option binutils will put "text" and "rodata" into different segments. Previously it bundled both of those (along with any other read only data) into a single executable segment. Second bullet point in the announcement: https://sourceware.org/ml/binutils/2018-07/msg00213.html In theory that also means the bug affects buster if the package is ever rebuilt / updated there. James signature.asc Description: OpenPGP digital signature
Bug#941619: ruby-odbc: ODBC dlopen regression in Debian 10
Package: ruby-odbc
Version: 0.8-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
Simple execution of Ruby (2.5) on Buster (Debian-10) fails with;
server:~/work/misc/tools/tdutils$ ./dump-customer-list.rb | grep -i hulu
Traceback (most recent call last):
6: from ./dump-customer-list.rb:7:in `'
5: from /home/abrahmbhatt/work/misc/tools/tdutils/td-customers.rb:33:in
`load'
4: from /home/abrahmbhatt/work/misc/libs/ruby/makeTdConnection.rb:6:in
`makeTdConnection'
3: from /usr/lib/ruby/vendor_ruby/dbi.rb:137:in `connect'
2: from /usr/lib/ruby/vendor_ruby/dbi/handles/driver.rb:33:in `connect'
1: from /usr/lib/ruby/vendor_ruby/dbd/odbc/driver.rb:15:in `connect'
/usr/lib/ruby/vendor_ruby/dbd/odbc/driver.rb:36:in `rescue in connect': INTERN
(0) [RubyODBC]Cannot allocate SQLHENV (DBI::DatabaseError)
server:~/work/misc/tools/tdutils$ ruby -v
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux-gnu]
server:~/work/misc/tools/tdutils$
/usr/include/ruby-2.5.0/ruby/ruby.h:2197:12: error: invalid operands to binary
/ (have int and char *)
((vari)/(!fmt[ofs] || rb_scan_args_bad_format(fmt)))
^~~~
And pages and pages more errors. That first one at least appears to have been
fixed as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889025
ruby-odbc: FTBFS with ruby2.5: invalid operands to binary / (have 'char *' and
'char *')
Subject: Bug#889025: fixed in ruby-odbc 0.8-1
However, as noted by https://rubygems.org/gems/rdbi-driver-odbc/versions/0.1.2:
0.1.2 - December 15, 2010 (6 KB)
0.1.1 - December 14, 2010 (6 KB)
0.1.0 - December 08, 2010 (5.5 KB)
RUNTIME DEPENDENCIES (2):
rdbi ~> 0.9
ruby-odbc = 0.2
That's hardcoded an unfixed version of ruby-odbc. The upstream project:
https://github.com/semmons99/rdbi-driver-odbc
... appears to have become moribund in 2011. There's only one Issue, open or
closed, and no sign of any fix.
With Google's help, we trial-and-errored our way to:
server:~/download/rdbi-driver-odbc$ git diff
diff --git a/Rakefile b/Rakefile
index 5180ca5..067f31d 100644
--- a/Rakefile
+++ b/Rakefile
@@ -27,8 +27,8 @@ rescue LoadError
end
begin
- require 'rake/gempackagetask'
- Rake::GemPackageTask.new(gemspec) do |pkg|
+ require 'rubygems/package_task'
+ Gem::PackageTask.new(gemspec) do |pkg|
pkg.gem_spec = gemspec
end
task :gem => :gemspec
@@ -45,3 +45,7 @@ desc "Validate the gemspec"
task :gemspec do
gemspec.validate
end
+
+task :default => :gem do
+ puts "generated latest version"
+end
diff --git a/lib/rdbi/driver/odbc.rb b/lib/rdbi/driver/odbc.rb
index 29ab15e..f1b5338 100644
--- a/lib/rdbi/driver/odbc.rb
+++ b/lib/rdbi/driver/odbc.rb
@@ -1,6 +1,6 @@
require 'rdbi'
require 'rubygems'
-gem 'ruby-odbc', '= 0.4'
+gem 'ruby-odbc', '>= 0.4'
require 'odbc'
require 'time'
diff --git a/rdbi-driver-odbc.gemspec b/rdbi-driver-odbc.gemspec
index dafc3ad..ca635ee 100644
--- a/rdbi-driver-odbc.gemspec
+++ b/rdbi-driver-odbc.gemspec
@@ -1,6 +1,6 @@
Gem::Specification.new do |s|
s.name= "rdbi-driver-odbc"
- s.version = "0.1.2"
+ s.version = "0.1.2.77"
s.platform= Gem::Platform::RUBY
s.authors = ["Shane Emmons"]
s.email = "semmon...@gmail.com"
@@ -11,7 +11,7 @@ Gem::Specification.new do |s|
s.required_rubygems_version = ">= 1.3.6"
s.add_dependency "rdbi", "~> 1"
- s.add_dependency "ruby-odbc", "= 0.4"
+ s.add_dependency "ruby-odbc", ">= 0.4"
s.add_development_dependency "rdbi-dbrc", "~> 0.1"
s.add_development_dependency "rspec", "~> 2"
server:~/download/rdbi-driver-odbc$
... which was enough to get "rake" to agree to make a gem. That installed
seamlessly. This was then enough to try to use it:
server:~/work/misc/libs/ruby$ bk diffs
= CommonDbi.rb 1.1 vs edited =
--- 1.1/libs/ruby/CommonDbi.rb2013-06-24 21:37:30 -07:00
+++ edited/libs/ruby/CommonDbi.rb2019-09-30 16:24:04 -07:00
@@ -2,5 +2,5 @@
$PREVIOUS_VERBOSE = $VERBOSE
$VERBOSE = false
-require "dbi"
+require "rdbi-driver-odbc"
$VERBOSE = $PREVIOUS_VERBOSE
= makeTdConnection.rb 1.8 vs edited =
--- 1.8/libs/ruby/makeTdConnection.rb2013-06-24 21:37:30 -07:00
+++ edited/libs/ruby/makeTdConnection.rb2019-09-30 16:23:45 -07:00
@@ -3,7 +3,7 @@
require "CommonDbi"
def makeTdConnection()
-return DBI.connect("dbi:ODBC:TestDirector", "devTDdb", "devtest")
+return RDBI.connect(:ODBC, :db => "TestDirector", :user => "devTDdb",
:password => )
end
if __FILE__ == $0
server:~/work/misc/libs/ruby$
... which promptly failed with the same error we had from the old stuff:
server:~/work/misc/libs/ruby$ ./makeTdConnection.rb
/var/lib/gems/2.5.0/gems/rdbi-1.1.0/lib/rdbi/types.rb:178: warning: constant
::Fixnum is deprecated
Traceback (most recent call last):
7: from ./makeTdConnection.rb:10:in
Bug#941618: torus-trooper: fails to start with "undefined symbol" error
Package: torus-trooper Version: 0.22.dfsg1-12 Severity: important Dear Maintainer, I've just installed the game and tried to launch it from the terminal: I got the following error message: torus-trooper: symbol lookup error: torus-trooper: undefined symbol: _D4core4stdc5errno5errnoFNbNdNiNeZ Rebuilding in sbuild fixed the issue for me. Does it mean that the package needs a binNMU? Cheers -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 torus-trooper depends on: ii libbulletml0v5 0.0.6-7 ii libc6 2.29-2 ii libgcc1 1:9.2.1-8 ii libgl1 1.1.0-1+b1 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libgphobos769.2.1-8 ii libsdl-mixer1.2 1.2.12-16 ii libsdl1.2debian 1.2.15+dfsg2-5 ii torus-trooper-data 0.22.dfsg1-12 torus-trooper recommends no packages. torus-trooper suggests no packages. -- no debconf information
Bug#941616: codelite: Should codelite be removed from Debian?
Source: codelite Version: 12.0+dfsg-1 Severity: normal I think it's time to remove the codelite package: * orphaned for more than 2.5 years with no expressions of interest in adoption * package is currently uninstallable (in unstable and probably testing too) and so RC buggy * has no reverse dependencies (according to dak rm) * there's a newer upstream version, but it's a rather complex package to update to a new upstream as a QA upload * a blocker for the current wxwidgets3.0-gtk3 transition, but upstream's changelog for 13.0 includes "Make CodeLite compile and run against GTK3" so updating to a new upstream seems likely to be required * upstream offer "unofficial" packages built for debian stretch and buster If there are no objections within two weeks, I'll turn this into an RM bug. Cheers, Olly
Bug#941617: stretch-pu: package publicsuffix/20190925.1705-0+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Control: affects -1 src:publicsuffix Please consider an update to publicsuffix in debian stretch. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in stretch is attached. This proposed release is also available at the "publicsuffix_debian/20190925.1705-0+deb9u1" tag on the "debian/stretch" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to stretch. ../publicsuffix_20190415.1030-0+deb9u1_20190925.1705-0+deb9u1.debdiff.gz Description: Binary data
Bug#941615: buster-pu: package publicsuffix/20190925.1705-0+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Control: affects -1 src:publicsuffix Please consider an update to publicsuffix in debian buster. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in buster is attached. This proposed release is also available at the "publicsuffix_debian/20190925.1705-0+deb10u1" tag on the "debian/buster" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to buster. ../publicsuffix_20190904.1802-0+deb10u1_20190925.1705-0+deb10u1.debdiff.gz Description: Binary data
Bug#940461: mailscripts: please adopt imap-dl
On Wed 2019-10-02 17:01:18 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> Thanks for this report. Do you want to recommend a specific behavior >> for imap-dl in this login failure case? it sounds frustrating! > > I guess just a consistently formatted error message and an exit code? OK, this should be available on the imap-dl branch of https://salsa.debian.org/dkg/mailscripts if you want to try it from there (commit ID 6159111cbb9e7b76830a4449a74d96961df4a7b9). Thanks for the feedback, --dkg signature.asc Description: PGP signature
Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation
On Wed, Oct 02, 2019 at 02:52:23PM +0900, Kentaro Hayashi wrote: > * Package name: sentencepiece >Version : 0.1.83+dfsg-1 >Upstream Author : Google Inc. > * URL : https://github.com/google/sentencepiece > It builds those binary packages: > > libsentencepiece-dev - Development package for libsentencepiece > libsentencepiece - Unsupervised text tokenizer for Neural Network-based > text generation > sentencepiece-tools - Utility package for SentencePiece Hi! The runtime library package (ie, libsentencepiece) should have soname appended. This might be not a big change, but amending this later would require a trip through NEW, thus let's get it right from the start. The watch file also should mangle the version, to include +dfsg. It is inappropriate to make lintian overrides for real bugs (like a lack of manpage). You are not required to fix everything immediately -- heck, there are many bugs that don't get fixed ever -- but that's not a valid use for overrides. They're for false positives. But overall, the package seems almost ready. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#941574: debian-edu-config: should add post-up code to /etc/network/interfaces eth0 entry at installation time
On Wed, Oct 02, 2019 at 11:12:03AM +, Holger Levsen wrote: > I think you have the metadata partly wrong, as the Debian Edu 10.1 > installation media contains d-e-c 2.10.65+deb10u1, so that we now need > to send 'found 941574 2.10.65+deb10u1' to mark this bug found in both > versions. (And which you could have avoided by using 'Version: > 2.10.65+deb10u1' for this bug in the first place, as then the BTS also > marks the bug as found in all following versions.) Thanks for the explanation. > Is that correct? (Or were you testing bullseye media?) Originally found this while testing buster media, afterwards tested bullseye netinst iso, then tested the fix to work for both stable and testing. > Assuming it's correct, I've cherry-picked your patch (thanks!) into the buster > branch and also fixed the meta-data. Please shout^wfix if I'm wrong. ;) Thanks, that's great! Wolfgang signature.asc Description: PGP signature
Bug#939845:
On 2019-10-02 19:25, Daniel Kahn Gillmor wrote: If anyone has any clearer diagnostics about what version of wireguard introduced the errors for the older kernels, or (even better) what specific change seems to cause the incompatibility, then that might be useful for further debugging. I actually found wireguard-dkms_0.0.20190123-1_all.deb on the affected server indicating that I'd previously manually installed and used it. Trying to compile it fails with the same error, making me think that the problem cause is somewhere outside of Wireguard itself. - Michel
Bug#940690: nvidia-kernel-dkms: build fails with kernel built with different gcc version
On Thu, 19 Sep 2019 12:07:54 +0200 Andreas Beckmann wrote: > Control: tag -1 wontfix > > On 19/09/2019 05.52, Celejar wrote: > > Build fails on a Sid system, with gcc symlinked to gcc-9, running a > > kernel built on a Buster system with gcc-8. Based on make.log and the > > The kernel headers store information which compiler was used to build > the kernel, and this compiler is used for the out-of-tree modules, too. > In your case the kernel was built with (unversioned) 'gcc' and that will > be used for the out-of-tree modules, too, even if the symlink now points > elsewhere. (Official Debian kernels are built with versioned compiler > binaries (e.g. gcc-8, gcc-9) only, and the headers have dependencies on > the corresponding packages, to avoid mismatches if the default compiler > changes. (The kernel compiler is usually switched independently from the > default system compiler.) > > Therefore: Always build custom kernels with versioned compilers. Ah, thanks. Just one question: how do I do that, and where is this documented, either in the Debian kernel handbook or in general kernel build guides? I can't find an option within the kernel config system for versioned compilers. Do I need to use environment variables? Celejar
Bug#941614: /usr/share/clang/scan-build-8/bin/scan-build: scan-build fails to find scan-view
Package: clang-tools-8
Version: 1:8.0.1-3+b1
Severity: normal
File: /usr/share/clang/scan-build-8/bin/scan-build
Control: affects -1 src:wireguard
I'm running scan-build as part of "make check" in src/ of the
wireguard package. It terminates with this message:
Use of uninitialized value $ScanView in exec at /usr/bin/scan-build line
1920.
Can't exec "": No such file or directory at /usr/bin/scan-build line 1920.
As far as i can tell, this is due to weird path shenanigans:
1917 my $ScanView = Cwd::realpath("$RealBin/scan-view");
1918 if (! -x $ScanView) { $ScanView = "scan-view"; }
1919 if (! -x $ScanView) { $ScanView =
Cwd::realpath("$RealBin/../../scan-view/bin/scan-view"); }
1920 exec $ScanView, "$Options{OutputDir}";
Note that debian puts these binaries in places that don't necessarily
line up with the above due to injected version numbers:
0 dkg@alice:~$ for x in build view; do printf '%s: %s\n' scan-$x $(readlink -f
$(which scan-$x) ); done
scan-build: /usr/share/clang/scan-build-8/bin/scan-build
scan-view: /usr/share/clang/scan-view-8/bin/scan-view
0 dkg@alice:~$
Can't it just search in $PATH?
Thanks for maintaining clang-tools in debian!
--dkg
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages clang-tools-8 depends on:
ii clang-8 1:8.0.1-3+b1
ii libc62.29-2
ii libclang1-8 1:8.0.1-3+b1
ii libgcc1 1:9.2.1-8
ii libllvm8 1:8.0.1-3+b1
ii libstdc++6 9.2.1-8
ii python3 3.7.3-1
clang-tools-8 recommends no packages.
clang-tools-8 suggests no packages.
-- no debconf information
Bug#941611: linux-image-5.2.0-2-amd64: Kernel 5.2 has terrible performance under load
Control: tags -1 + moreinfo Hi James, On Wed, Oct 02, 2019 at 12:04:47PM -0700, James Bottomley wrote: > Package: src:linux > Version: 5.2.9-2 > Severity: important > Tags: upstream > > Dear Maintainer, > > Linux Kernel 5.2 is completely unusable on most of my systems. The problem > seems to be something to do with memory compaction causing intervals where > the system becomes unresponsive. > > This is definitely an upstream issue (my laptop running the upstream > kernel is displaying the problem as well) so this bug is really just a > warning not to deploy the 5.2 kernel until a fix is found. If so, could you point where it was reported upstream so we can set accorrdingly where it has been forwarded to? Regards, Salvatore
Bug#940461: mailscripts: please adopt imap-dl
Daniel Kahn Gillmor writes: > > Thanks for this report. Do you want to recommend a specific behavior > for imap-dl in this login failure case? it sounds frustrating! > > --dkg I guess just a consistently formatted error message and an exit code? d
Bug#936764: jhbuild: Python2 removal in sid/bullseye
On Mon, 30 Sep 2019 00:00:01 +0200 Christoph Reiter wrote: > On Sun, Sep 29, 2019 at 11:38 PM Jeremy Bicha wrote: > > It's easier to package from a tarball release than to do a git > > snapshot, so I will probably wait for a 3.35 release to package the > > new py3 jhbuild. > > OK, I'll create a release next week. Done: https://download.gnome.org/sources/jhbuild/3.35/
Bug#941613: RM: ruby-simple-form/3.2.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi Stable release managers, [X-Debbugs-CC to Antonio Terceiro] Please remove ruby-simple-form on the next stretch point release. It was back in #923847 removed in unstable, has no reverse dependencies and apart of the removal reasons there has now as well CVE-2019-16676. https://github.com/plataformatec/simple_form/security/advisories/GHSA-r74q-gxcg-73hx Given it is unused, instead of going ahead of either trying to fix that or mark it as no-dsa and defer a fix via a point release it might make sense to just remove it on next point release time. Regards, Salvatore
Bug#930037: irssi + mosh: badly rendered status lines
Control: forwarded -1 https://github.com/mobile-shell/mosh/issues/1064 On 2019-08-02 18:25 +0200, Jakub Wilk wrote: > Control: reassign -1 mosh 1.3.2-2.1 > Control: affects -1 + irssi > > This happens because mosh doesn't implement the repetition operator > (see bug #933053). Thanks. Meanwhile it has also been reported upstream. Cheers, Sven
Bug#941467: [Pkg-samba-maint] Bug#941467: fixed in samba 2:4.11.0+dfsg-6
Le mer. 2 oct. 2019 à 21:12, Paul Gevers a écrit : > > Control: reopen 941467 > > On Tue, 01 Oct 2019 21:07:24 + Mathieu Parent > wrote: > > samba (2:4.11.0+dfsg-6) unstable; urgency=medium > > . > >* Do not run waf configure in parallel. Fix FTBFS on arm (Closes: > > #941467) > > Apparently this wasn't enough to fix the failures, as armel, armhf and > mipsel still FTBFS. Only armel and armhf were affected by this FTBFS. And this is fixed in -7 (I forgot about make lazy vars). > Additionally mips64el and ppc64el now have an > unfulfilled Build-Depends. This is the remaining blocker in the > gnome-desktop3/mutter/evolution-data-server transition. Yes. This is also in progress (ldb 2:2.0.7-3 is coming soon). Regards -- Mathieu Parent
Bug#941612: libretro-gambatte FTCBFS: does not pass cross tools to make
Source: libretro-gambatte Version: 0.5.0+git20160522+dfsg1-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs libretro-gambatte fails to cross build from source, because it does not pass cross tools to make. The easiest way of fixing that is using dh_auto_build. Please consider applying the attached patch. Helmut diff --minimal -Nru libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog --- libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog 2019-03-03 01:06:24.0 +0100 +++ libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog 2019-10-02 21:26:06.0 +0200 @@ -1,3 +1,10 @@ +libretro-gambatte (0.5.0+git20160522+dfsg1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Wed, 02 Oct 2019 21:26:06 +0200 + libretro-gambatte (0.5.0+git20160522+dfsg1-2) unstable; urgency=medium * Team upload diff --minimal -Nru libretro-gambatte-0.5.0+git20160522+dfsg1/debian/rules libretro-gambatte-0.5.0+git20160522+dfsg1/debian/rules --- libretro-gambatte-0.5.0+git20160522+dfsg1/debian/rules 2019-03-03 01:06:24.0 +0100 +++ libretro-gambatte-0.5.0+git20160522+dfsg1/debian/rules 2019-10-02 21:26:06.0 +0200 @@ -12,7 +12,7 @@ dh $@ override_dh_auto_build: - $(MAKE) -C libgambatte/ -f Makefile.libretro $(PLATFORM) + dh_auto_build --buildsystem=makefile --sourcedirectory=libgambatte/ -- -f Makefile.libretro $(PLATFORM) override_dh_auto_clean: $(MAKE) -C libgambatte/ -f Makefile.libretro clean
Bug#768963: Confirmation: crash with " free(): invalid pointer
I attatch the error output. Regards Johann -- J.H. Spies - Tel. 021-982 2694 / 082 782 0336 / 021-808 4699(w) Posbus 4668, Tygervallei 7536 "My brethren, count it all joy when ye fall into divers temptations; Knowing this, that the trying of your faith worketh patience." James 1:2,3 free(): invalid pointer Stacktrace: at <0x> at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipCreateBitmapFromFile (string,intptr&) [0xb] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0 at System.Drawing.Bitmap..ctor (string,bool) [0x0002b] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0 at System.Drawing.Bitmap..ctor (string) [0x0] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0 at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap..ctor (string) [0x00019] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0 at System.Windows.Forms.FSEntry.SetImage () [0x00013] in <0e1823914d7643eeaf1207febb083a4a>:0 at System.Windows.Forms.MWFFileView/ThumbnailCreator.MakeThumbnails () [0x00050] in <0e1823914d7643eeaf1207febb083a4a>:0 at System.Threading.ThreadHelper.ThreadStart_Context (object) [0x00017] in :0 at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x0008d] in :0 at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x0] in :0 at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) [0x00031] in :0 at System.Threading.ThreadHelper.ThreadStart () [0xb] in :0 at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004d] in :0 /proc/self/maps: 41853000-41a81000 rwxp 00:00 0 41a8c000-41b3c000 rwxp 00:00 0 55b62f84c000-55b62f877000 r--p fe:00 1441229 /usr/bin/mono-sgen 55b62f877000-55b62fb6c000 r-xp 0002b000 fe:00 1441229 /usr/bin/mono-sgen 55b62fb6c000-55b62fc9b000 r--p 0032 fe:00 1441229 /usr/bin/mono-sgen 55b62fc9c000-55b62fca2000 r--p 0044f000 fe:00 1441229 /usr/bin/mono-sgen 55b62fca2000-55b62fca8000 rw-p 00455000 fe:00 1441229 /usr/bin/mono-sgen 55b62fca8000-55b62fd39000 rw-p 00:00 0 55b6301df000-55b631333000 rw-p 00:00 0 [heap] 7f3eec00-7f3eec021000 rw-p 00:00 0 7f3eec021000-7f3ef000 ---p 00:00 0 7f3ef000-7f3ef0021000 rw-p 00:00 0 7f3ef0021000-7f3ef400 ---p 00:00 0 7f3ef400-7f3ef446e000 rw-p 00:00 0 7f3ef446e000-7f3ef800 ---p 00:00 0 7f3ef800-7f3ef8046000 rw-p 00:00 0 7f3ef8046000-7f3efc00 ---p 00:00 0 7f3efc00-7f3efc025000 rw-p 00:00 0 7f3efc025000-7f3f ---p 00:00 0 7f3f-7f3f00021000 rw-p 00:00 0 7f3f00021000-7f3f0400 ---p 00:00 0 7f3f06ef8000-7f3f06f78000 rw-p 00:00 0 7f3f06f7c000-7f3f06ffc000 rw-p 00:00 0 7f3f06ffd000-7f3f071fd000 rw-s 00:05 1736765 /SYSV (deleted) 7f3f071fd000-7f3f071fe000 ---p 00:00 0 Memory around native instruction pointer (0x7f3f1775a081): 0x7f3f1775a071 d2 4c 89 ce bf 02 00 00 00 b8 0e 00 00 00 0f 05 .L.. 0x7f3f1775a081 48 8b 84 24 08 01 00 00 64 48 33 04 25 28 00 00 H..$dH3.%(.. 0x7f3f1775a091 00 75 20 44 89 c0 48 81 c4 18 01 00 00 c3 90 48 .u D..HH 0x7f3f1775a0a1 8b 15 c9 ed 17 00 f7 d8 41 b8 ff ff ff ff 64 89 A.d. Native stacktrace: /usr/bin/cli(+0x123acd) [0x55b62f96facd] /usr/bin/cli(+0x123dd7) [0x55b62f96fdd7] /usr/bin/cli(+0xbbf1a) [0x55b62f907f1a] /lib/x86_64-linux-gnu/libpthread.so.0(+0x13510) [0x7f3f1790d510] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141) [0x7f3f1775a081] /lib/x86_64-linux-gnu/libc.so.6(abort+0x121) [0x7f3f17745535] /lib/x86_64-linux-gnu/libc.so.6(+0x7bdb8) [0x7f3f1779bdb8] /lib/x86_64-linux-gnu/libc.so.6(+0x8248a) [0x7f3f177a248a] /lib/x86_64-linux-gnu/libc.so.6(+0x83bfc) [0x7f3f177a3bfc] /lib/x86_64-linux-gnu/libtiff.so.5(TIFFRGBAImageEnd+0x12) [0x7f3f0f3c2c12] /usr/lib/libgdiplus.so.0(+0x43666) [0x7f3f1704a666] /usr/lib/libgdiplus.so.0(GdipLoadImageFromFile+0x24d) [0x7f3f1702c3ad] /usr/lib/libgdiplus.so.0(GdipCreateBitmapFromFile+0x9) [0x7f3f17019109] [0x41b385c6] Pkilling 0x7f3f075fe700 from 0x7f3f077ff700 Pkilling 0x7f3f0c483700 from 0x7f3f077ff700 Pkilling 0x7f3f1771b780 from 0x7f3f077ff700 Pkilling 0x7f3f07dfe700 from 0x7f3f077ff700 Pkilling 0x7f3f172eb700 from 0x7f3f077ff700 Pkilling 0x7f3f073fd700 from 0x7f3f077ff700 Pkilling 0x7f3f0c282700 from 0x7f3f077ff700 Pkilling 0x7f3f07fff700 from 0x7f3f077ff700 Entering thread summarizer pause from 0x7f3f077ff700
Bug#768963: Confirmation: crash with " free(): invalid pointer
Package: keepass2 Version: 2.43+dfsg-1 Followup-For: Bug #768963 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Trying to locate a key file using the file dialog. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? keepass2 crashed. * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepass2 depends on: ii libgcrypt20 1.8.5-2 ii libmono-corlib4.5-cil5.18.0.240+dfsg-5 ii libmono-system-drawing4.0-cil5.18.0.240+dfsg-5 ii libmono-system-security4.0-cil 5.18.0.240+dfsg-5 ii libmono-system-windows-forms4.0-cil 5.18.0.240+dfsg-5 ii libmono-system-xml4.0-cil5.18.0.240+dfsg-5 ii libmono-system4.0-cil5.18.0.240+dfsg-5 ii libx11-6 2:1.6.8-1 ii mono-runtime 5.18.0.240+dfsg-5 Versions of packages keepass2 recommends: ii xsel 1.2.0+git9bfc13d.20180109-3 Versions of packages keepass2 suggests: pn keepass2-doc pn mono-dmcs pn xdotool -- no debconf information
Bug#939845:
On Wed 2019-10-02 16:05:06 +0800, Aron Xu wrote: > I tried more to reproduce this bug, the problem only affect linux > 4.19.0-0.bpo.4 and 4.19.0-0.bpo.5 (while I haven't tried earlier bpo > versions), and does not affect 4.9 or 4.19.0-0.bpo.6 From Michel Meyers messages in this thread, it looks like it also impacts 4.19.0-2. I agree that the simplest fix for people today is to ensure that they've upgraded to 4.19.0-6 or later (or 4.19.0-0.bpo.6 or later, if still on stretch). If anyone has any clearer diagnostics about what version of wireguard introduced the errors for the older kernels, or (even better) what specific change seems to cause the incompatibility, then that might be useful for further debugging. Sorry that i haven't had the time to dig into it further, but i appreciate the ongoing reports. --dkg signature.asc Description: PGP signature
Bug#940461: mailscripts: please adopt imap-dl
On Tue 2019-10-01 10:21:31 -0300, David Bremner wrote: > Here's the log about size mismatches. The only thing that jumps out at > me is that it looks like the size mismatch doesn't get larger for big > messages, so more like an additive error than multiplicative. hm, only the first mismatch is reported individually, the rest are summarized at the end: > WARNING:root:17 size mismatches out of 17 messages (mismatches in bytes: mean > -8012.647059, stddev 147436.474857) So all messages have mismatched sizes, and the standard deviation of the mismatches themselves is so large that it seems likely that there are errors in both directions (smaller reported size than fetched size, and also larger reported size than fetched size). It looks to me like the Microsoft server is simply confused, ugh. I wonder whether this is something already known and reported somewhere? I never know how to record bugs with Microsoft products :/ --dkg signature.asc Description: PGP signature
Bug#940461: mailscripts: please adopt imap-dl
On Tue 2019-10-01 08:40:21 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>> ok, in v2 of this patch, imap-dl will accept options.on_size_mismatch,
>> which can be either "exception" or "warn" or "none".
>>
>> If you could set it to "warn" and try it out again, and show me the
>> statistics it produces, i'd be interested in seeing it.
>
> There seems to be no consistent amount of extra bytes, but every message
> has some. I'll try to remember to grab a log, but right now I can't
> because o365 is failing to recognize my password. This happened with
> intermittendly with getmail also, so I don't think it's an imap-dl
> bug. Note that imap-dl could handle this more gracefully:
>
> INFO:root:pulling from config file /home/bremner/.getmail/getmailrc
> Traceback (most recent call last):
> File "/home/bremner/.config/scripts/imap-dl", line 221, in
> pull_msgs(confname)
> File "/home/bremner/.config/scripts/imap-dl", line 119, in pull_msgs
> conf.get('retriever', 'password'))
> File "/usr/lib/python3.7/imaplib.py", line 598, in login
> raise self.error(dat[-1])
> imaplib.error: b'LOGIN failed.'
Thanks for this report. Do you want to recommend a specific behavior
for imap-dl in this login failure case? it sounds frustrating!
--dkg
signature.asc
Description: PGP signature
Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder
On Mon, Sep 30, 2019 at 12:51:33PM -0400, Daniel wrote: > Dear Lennart, > > I hope that when one opens a "whishlist bug" at least there is a chance to > have a confrontation. > > The main point I want to address is when you do a "smart installation" it is > supposed to perform a clean installation hence the only folder that must to > be untouched is "/home". The same concept when you have "/" and "/home" in > separated partitions and you perform a clean installation. I think that is > pretty trivial, the smart parts are: > > * the installer is able to check for a previous Debian installation before > to begin the process; > > * and in case it founds a previous installation, the installer, is able to > perform a fresh installation without overwriting the "/home" folder. Well I believe you have the option to not format a mountpoint during the install already, so at least that part should be pretty easy. > I can confirm that ElementaryOS and POP!_OS, that share the same installer, > can do that. Well hopefully someone will try to contribute that then. I suspect the main thing is finding someone that wants to implement it and do the work to add it and maintain it. > Last point I want touch is about the swap partition. With the SSD and the OS > able to boot in a bunch of seconds the hibernation doesn't make any sense > today. For example I have 16GB of ram, based on the standard rules I should > use at least 1.5x of the ram if not the double. It means that I should use > 32GB just to hibernate my session, no way... With the SSD disks the lesser > you write on the disk the better, I put just 2GB of swap-file and > "swappiness" at 1 and the swap is never used and I didn't waste 30GB of > space. Only advantage to huibernation is not having to close all the things you are working on and opening them again after the next boot. I do find hibernation takes too long with a lot of ram and hence never do it myself. :) > To conclude I think I elaborated everything clearly, I see a lot of benefits > and improvement with the suggestions I gave to Debian, I also think that are > pretty trivial to implement. I don't want introduce a Windows behavior of > "reinstall when it broken", but back to time when I hadn't a fast internet > connection it was faster download the full ISO and performing a fresh > installation rather than doing a "dist-upgrade". I remember upgrades over dial up. Still did not make me want to go download full iso images elsewhere. It could do it while I slept. Things have gotten a lot bigger since then though. I have seen people keep a subset mirror of Debian on a USB drive that they would update with rsync once in a while at work, and bring home to use for upgrades where the connection was slow. Still in place upgrades of course, not using the installer. > The bottom line is with a smart installer you don't need to separate your > disk(s) in partitions but you can throw everything in "/" including the > "swap" as swap-file that you can modify freely based on your needs (if you > can't live without hibernation[1]). There is also a dynamic swap manager > available on Debian as well: https://github.com/Tookmund/Swapspace -- Len Sorensen
Bug#575149: gcalcli: Cannot add entries to non-default calendars
Package: gcalcli Version: 4.2.0-1 Followup-For: Bug #575149 Dear Maintainer, The bug still exists in 4.2.0-1. The patch I attached to my 20 June message still fixes it. Thanks, -- Nik -- System Information: Debian Release: bullseye/sid APT prefers precise-updates APT policy: (990, 'precise-updates'), (990, 'precise-security'), (990, 'precise-backports'), (990, 'precise'), (500, 'xenial-updates'), (500, 'xenial'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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/bash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages gcalcli depends on: ii python33.7.3-1 ii python3-dateutil 2.6.1-1 ii python3-googleapi 1.5.5-1 ii python3-httplib2 0.9.2+dfsg-1 ii python3-oauth2client 4.1.2-3 ii python3-parsedatetime 2.4-2 ii python3-six1.10.0-4 Versions of packages gcalcli recommends: ii python3-vobject 0.9.6.1-0.1 gcalcli suggests no packages. -- no debconf information
Bug#941611: linux-image-5.2.0-2-amd64: Kernel 5.2 has terrible performance under load
Package: src:linux Version: 5.2.9-2 Severity: important Tags: upstream Dear Maintainer, Linux Kernel 5.2 is completely unusable on most of my systems. The problem seems to be something to do with memory compaction causing intervals where the system becomes unresponsive. This is definitely an upstream issue (my laptop running the upstream kernel is displaying the problem as well) so this bug is really just a warning not to deploy the 5.2 kernel until a fix is found. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: product_name: product_version: chassis_vendor: chassis_version: bios_vendor: Intel Corp. bios_version: BX97510J.86A.1209.2006.0601.1340 board_vendor: Intel Corporation board_name: D975XBX board_version: AAD27094-305 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82975X Memory Controller Hub [8086:277c] Subsystem: Intel Corporation 82975X Memory Controller Hub [8086:5842] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: i82975x_edac 00:01.0 PCI bridge [0604]: Intel Corporation 82975X PCI Express Root Port [8086:277d] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Intel Corporation 82975X PCI Express Root Port [8086:] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s, Exit Latency L0s <256ns ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #0, PowerLimit 75.000W; Interlock- NoCompl- SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Off, PwrInd On, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed+ WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [140 v1] Root Complex Link Desc: PortNumber=02 ComponentID=01 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: fed19000 Link1: Desc: TargetPort=03 TargetComponent=01 AssocRCRB- LinkType=Config LinkValid+ Addr: 00:03.0 CfgSpace=00018000 Kernel driver in use: pcieport 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 01) Subsystem: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:0417] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort-
Bug#941467: fixed in samba 2:4.11.0+dfsg-6
Control: reopen 941467 On Tue, 01 Oct 2019 21:07:24 + Mathieu Parent wrote: > samba (2:4.11.0+dfsg-6) unstable; urgency=medium > . >* Do not run waf configure in parallel. Fix FTBFS on arm (Closes: #941467) Apparently this wasn't enough to fix the failures, as armel, armhf and mipsel still FTBFS. Additionally mips64el and ppc64el now have an unfulfilled Build-Depends. This is the remaining blocker in the gnome-desktop3/mutter/evolution-data-server transition. Paul signature.asc Description: OpenPGP digital signature
Bug#933548: transition: gnome-desktop3
Hi, On 02-10-2019 03:31, Jeremy Bicha wrote: > https://bugs.debian.org/933573 has a patch for eweouz If somebody could please do an upload that fixes eweouz, that would be great, than we don't need to resort to removal. If my view of things is up-to-date and correct, it's the last piece of the puzzle together with the samba situation (assuming LO will just build on mips64el). Paul signature.asc Description: OpenPGP digital signature
Bug#863118: confvar module for devscripts
> > Confvar only unsets the variables matching the list (or regex) > > expected by the devscript tool. > > devscripts.conf(5) requires this behaviour. > > Confvar does not modify HOME, or any unrelated setting. > Hmm, I could have sworn environment was inherited before, perhaps I > have broken it with my changes. I was wrong. devscripts.conf does not require to ignore values from the environment, but currently, scripts do. > It looks like `compgen -A variable` or `compgen -v` can output the > names of all bash variables, if you then loop through all the variables > printing both the name and value (NUL separated) then you can just pass I prefer to keep `set` because bashisms would break debsign.sh. > out all variable names and values and then match them on the Perl side. For the record, Confvar.pm was already doing this. However, while implementing your idea below, I have found that only outputting the modified settings is more simple. The full list of shell variables is only parsed when satisfying debuild and rmadison special requirements. > This could even mean that the bash script can be converted to a static > script file instead of a generated script embedded in Perl. Personally > I quite dislike code where one language is embedded in another. That is obviously a better design, thanks for the idea! I have updated the pull request.
Bug#941610: [Pkg-giraffe-maintainers] Bug#941610: kopano-server crashes
Hi, On Wed, Oct 02, 2019 at 08:16:03PM +0200, Roel van Meer wrote: > Package: kopano-server > Version: 8.7.0-3 > Severity: normal > > Dear Maintainer, > > while running Kopano, I'm experiencing kopano-server crashes. At the > time of the crash, there are no emails being delivered via Postfix, nor > are there entries in the Apache access log that point to usage of Z-push > or Kopano Webapp. Also, during that time nothing is logged in the > gateway log, ical log, or any other Kopano logs. So I cannot point to a > probable cause. > Please note that I have seen these crashes on at least four of our > systems so far. They seem to happen once every two weeks, on average. > > If there's anything I can do to help getting this fixed, please let me > know. Is is segfaulting? If so installing the -dbgsym package and systemd-coredump might get us a backtrace. Cheers, -- Guido > > Kind regards, Roel > > > -- System Information: > Debian Release: 10.1 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages kopano-server depends on: > ii dbconfig-common 2.0.11+deb10u1 > ii debconf [debconf-2.0] 1.5.71 > ii init-system-helpers 1.56+nmu1 > ii kopano-common 8.7.0-3 > ii kopano-libs 8.7.0-3 > ii libc6 2.28-10 > ii libcom-err2 1.44.5-1+deb10u2 > ii libgcc1 1:8.3.0-6 > ii libgnutls30 3.6.7-4 > ii libgsoap-2.8.75 2.8.75-1 > ii libgssapi-krb5-21.17-3 > ii libicu6363.1-6 > ii libk5crypto31.17-3 > ii libkrb5-3 1.17-3 > ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 > ii libmariadb3 1:10.3.17-0+deb10u1 > ii libpam0g1.3.1-5 > ii libssl1.1 1.1.1d-0+deb10u1 > ii libstdc++6 8.3.0-6 > ii lsb-base10.2019051400 > ii mariadb-client 1:10.3.17-0+deb10u1 > ii mariadb-client-10.3 [virtual-mysql-client] 1:10.3.17-0+deb10u1 > ii zlib1g 1:1.2.11.dfsg-1 > > Versions of packages kopano-server recommends: > ii mariadb-server 1:10.3.17-0+deb10u1 > > kopano-server suggests no packages. > > -- Logged in kopano server log: > Fatal error detected. Please report all following information. > Application kopano-server version: 8.7.0 > OS: Linux, release: 4.19.0-6-amd64, version: #1 SMP Debian 4.19.67-2 > (2019-08-28), hardware: x86_64 > Thread name: z-s: 163.172.10 > Peak RSS: 50556 > Pid 11672 caught SIGSEGV (11), traceback: > Backtrace: > #0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x490f0) [0x7f08e96a20f0] > #1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x333fd) [0x7f08e968c3fd] > #2. > /usr/lib/x86_64-linux-gnu/libkcutil.so.0(_ZN2KC23generic_sigsegv_handlerEPNS_8ECLoggerEPKcS3_iPK9siginfo_tPKv+0x1a1) > [0x7f08e968c681] > #3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f08e6ae0730] > #4. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_want+0) [0x7f08e6ca3ea0] > #5. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_error+0x48) > [0x7f08e6ca3ef8] > #6. /usr/lib/x86_64-linux-gnu/libgsoapssl++-2.8.75.so(soap_ssl_error+0x18c) > [0x7f08e92be04c] > #7. /usr/sbin/kopano-server(+0x15347) [0x561a23e7c347] > #8. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x3ab2b) [0x7f08e9693b2b] > #9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f08e6ad5fa3] > #10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f08e66e54cf] > Signal errno: Success, signal code: 1 > Sender pid: 40, sender uid: 0, si_status: 0 > Signal value: 0, faulting address: 0x28 > When reporting this traceback, please include Linux distribution name (and > version), system architecture and Kopano version. > > -- Backtrace with gdb and debugsymbols installed > (gdb) bt > #0 raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x7f08e968c74f in KC::generic_sigsegv_handler (lpLogger= out>, app_name=, version_string=0x561a23e7e2d5 "8.7.0", > signr=11, si=0x7f08da2e96b0, uc=) at > ../../common/ECLogger.cpp:994 > #2 > #3 SSL_want (s=s@entry=0x0) at ../ssl/ssl_lib.c:4189 > #4 0x7f08e6ca3ef8 in SSL_get_error (s=0x0, i=) at > ../ssl/ssl_lib.c:3505 > #5 0x7f08e92be04c in soap_ssl_error (soap=soap@entry=0x561a272e2000, > ret=ret@entry=0, err=err@entry=0) at stdsoap2_ssl_cpp.cpp:4170 > #6
Bug#929102: "show" command doesn't reveal apt-mark effects
reassign 929102 apt found 929102 1.8.4 retitle 929102 apt-mark lies with uninstalled packages thanks > "SJ" == Sven Joachim writes: SJ> For packages which are not installed I can reproduce the behavior, but SJ> in that case it is actually apt-mark which is lying to you because it SJ> does not write anything to /var/lib/apt/extended_states. Yes. Please somebody fix the bug/lying for uninstalled packages.
Bug#941526: gnutls28: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Control: tags -1 pending On 2019-10-01 Steve Langasek wrote: > Package: gnutls28 > Version: 3.6.9-5 > Severity: serious > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu eoan ubuntu-patch > Dear maintainers, > The texlive-generic-recommended transitional package has been dropped from > texlive-base in sid. Please update your build-dependency to > texlive-plain-generic instead. [...] Hello Steve, fixed in 3.6.10-2, stuck in NEW. cu Andreas
Bug#941360: fwupd: Failed to activate service: timed out
On 2019-09-30 at 19:53:03, mario.limoncie...@dell.com wrote: > Here is a fix for it. I believe it's because of a clash with fwupd-refresh > and fwupd specifically in systemd 242 and newer. > > https://github.com/fwupd/fwupd/commit/dc7e7c3808d564d5769b2845dbd66a3651f72e07 Looks like it worked. I manually applied this on my machine and haven't seen the messages in 2 days. Francois -- https://fmarier.org/
Bug#771424: R mysteriously injured by horizontal bars in xterm -title
Control: tags -1 moreinfo unreproducible On 2014-12-14 19:08 -0500, Thomas Dickey wrote: > On Fri, Nov 28, 2014 at 12:59:53AM +0800, 積丹尼 Dan Jacobson wrote: >> Package: xterm >> Version: 312-1 >> File: /usr/bin/xterm >> >> This gives me a strip of letters across the top of the screen with the >> 'R' mysteriously injured by horizontal bars, >> $ set $(perl -e 'print chr $_ for ord q/!/.. ord q/~/'); xterm -title $@ -e >> read >> -title RR shows the same problem. >> I am running under icewm. > > I don't see this with the Debian 8 beta (using icewm and xterm). Neither do I, not now and not back in 2014. > Perhaps it depends on available fonts or locale... Dan, do you still have this problem? If so, please send a screenshot. Cheers, Sven
Bug#933501: aptitude cannot search for packages newer than in the archive
Control: merge 902536 -1 On 2019-07-31 04:24 +0800, 積丹尼 Dan Jacobson wrote: > Package: aptitude > Version: 0.8.11-7 > Severity: wishlist > > Consider the case > # set libffi6 > # apt-cache policy $@ > libffi6: > Installed: 3.3~20160224-1 > Candidate: 3.3~20160224-1 > Version table: > *** 3.3~20160224-1 100 > 100 /var/lib/dpkg/status > 3.2.1-9 500 > 500 http://opensource.nchc.org.tw/debian unstable/main i386 Packages > # apt-show-versions|grep newer > libffi6:i386 3.3~20160224-1 newer than version in archive > # aptitude --verbose show $@|egrep Version\|State > Version: 3.3~20160224-1 > State: installed > Version: 3.2.1-9 > State: installed (3.3~20160224-1), upgrade available (3.2.1-9) > > Actually technically that should be downgrade, not upgrade.* > > But my main point is there is no search pattern to detect it. > not ~U, not ~o, etc. Probably no combination either. This has been noticed before in #902536, by you. Sorry, I don't have a good suggestion, but would like to learn if there is any. Cheers, Sven
Bug#941610: kopano-server crashes
Package: kopano-server Version: 8.7.0-3 Severity: normal Dear Maintainer, while running Kopano, I'm experiencing kopano-server crashes. At the time of the crash, there are no emails being delivered via Postfix, nor are there entries in the Apache access log that point to usage of Z-push or Kopano Webapp. Also, during that time nothing is logged in the gateway log, ical log, or any other Kopano logs. So I cannot point to a probable cause. Please note that I have seen these crashes on at least four of our systems so far. They seem to happen once every two weeks, on average. If there's anything I can do to help getting this fixed, please let me know. Kind regards, Roel -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages kopano-server depends on: ii dbconfig-common 2.0.11+deb10u1 ii debconf [debconf-2.0] 1.5.71 ii init-system-helpers 1.56+nmu1 ii kopano-common 8.7.0-3 ii kopano-libs 8.7.0-3 ii libc6 2.28-10 ii libcom-err2 1.44.5-1+deb10u2 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libgsoap-2.8.75 2.8.75-1 ii libgssapi-krb5-21.17-3 ii libicu6363.1-6 ii libk5crypto31.17-3 ii libkrb5-3 1.17-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii libmariadb3 1:10.3.17-0+deb10u1 ii libpam0g1.3.1-5 ii libssl1.1 1.1.1d-0+deb10u1 ii libstdc++6 8.3.0-6 ii lsb-base10.2019051400 ii mariadb-client 1:10.3.17-0+deb10u1 ii mariadb-client-10.3 [virtual-mysql-client] 1:10.3.17-0+deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages kopano-server recommends: ii mariadb-server 1:10.3.17-0+deb10u1 kopano-server suggests no packages. -- Logged in kopano server log: Fatal error detected. Please report all following information. Application kopano-server version: 8.7.0 OS: Linux, release: 4.19.0-6-amd64, version: #1 SMP Debian 4.19.67-2 (2019-08-28), hardware: x86_64 Thread name: z-s: 163.172.10 Peak RSS: 50556 Pid 11672 caught SIGSEGV (11), traceback: Backtrace: #0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x490f0) [0x7f08e96a20f0] #1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x333fd) [0x7f08e968c3fd] #2. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(_ZN2KC23generic_sigsegv_handlerEPNS_8ECLoggerEPKcS3_iPK9siginfo_tPKv+0x1a1) [0x7f08e968c681] #3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f08e6ae0730] #4. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_want+0) [0x7f08e6ca3ea0] #5. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_error+0x48) [0x7f08e6ca3ef8] #6. /usr/lib/x86_64-linux-gnu/libgsoapssl++-2.8.75.so(soap_ssl_error+0x18c) [0x7f08e92be04c] #7. /usr/sbin/kopano-server(+0x15347) [0x561a23e7c347] #8. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x3ab2b) [0x7f08e9693b2b] #9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f08e6ad5fa3] #10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f08e66e54cf] Signal errno: Success, signal code: 1 Sender pid: 40, sender uid: 0, si_status: 0 Signal value: 0, faulting address: 0x28 When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version. -- Backtrace with gdb and debugsymbols installed (gdb) bt #0 raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f08e968c74f in KC::generic_sigsegv_handler (lpLogger=, app_name=, version_string=0x561a23e7e2d5 "8.7.0", signr=11, si=0x7f08da2e96b0, uc=) at ../../common/ECLogger.cpp:994 #2 #3 SSL_want (s=s@entry=0x0) at ../ssl/ssl_lib.c:4189 #4 0x7f08e6ca3ef8 in SSL_get_error (s=0x0, i=) at ../ssl/ssl_lib.c:3505 #5 0x7f08e92be04c in soap_ssl_error (soap=soap@entry=0x561a272e2000, ret=ret@entry=0, err=err@entry=0) at stdsoap2_ssl_cpp.cpp:4170 #6 0x561a23e7c347 in WORKITEM::run (this=0x561a269f50a0) at ../../provider/server/ECThreadManager.cpp:130 #7 0x7f08e9693b2b in KC::ECThreadPool::threadFunc (lpVoid=0x561a257c4398) at ../../common/ECThreadPool.cpp:208 #8 0x7f08e6ad5fa3 in start_thread (arg=) at pthread_create.c:486 #9 0x7f08e66e54cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Bug#941609: network-manager: generates world-{read,execut}able secret_key file (in buster)
Package: network-manager
Version: 1.14.6-2
src/nm-core-utils.c has:
2896 } else if (!nm_utils_file_set_contents (SECRET_KEY_FILE,
2897 (const char *)
new_content,
2898 len,
2899 0077,
2900 )) {
Fixed in 1.20.4-1 (sid):
2698 } else if (!nm_utils_file_set_contents (SECRET_KEY_FILE,
2699 (const char *)
new_content,
2700 len,
2701 0600,
2702 )) {
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
**
Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**
Bug#929102: "show" command doesn't reveal apt-mark effects
Control: tags -1 moreinfo On 2019-05-17 14:54 +0800, 積丹尼 Dan Jacobson wrote: > Package: aptitude > Version: 0.8.11-7 > > Even though using apt-mark affects aptitude's decision making, but there > is no way to detect it via the "show" command. > > # aptitude show gcc-9-base|sum > 11672 1 > # apt-mark hold gcc-9-base > gcc-9-base set on hold. > # aptitude show gcc-9-base|sum > 11672 1 > # aptitude - show gcc-9-base|sum > 11672 1 Is the package gcc-9-base actually installed? If yes, I cannot reproduce this: , | # aptitude show gcc-9-base | grep ^State | State: installed | # apt-mark hold gcc-9-base | gcc-9-base set on hold. | # aptitude show gcc-9-base | grep ^State | State: installed [held] ` For packages which are not installed I can reproduce the behavior, but in that case it is actually apt-mark which is lying to you because it does not write anything to /var/lib/apt/extended_states. Cheers, Sven
Bug#941608: ITP: panflute -- Idiomatic Python interface for writing Pandoc filters
Package: wnpp Severity: wishlist Owner: Branen Salmon * Package name: python3-panflute Version : 1.11.3 Upstream Author : Sergio Correia * URL : http://scorreia.com/software/panflute/ * License : BSD Programming Lang: Python Description : Idiomatic Python interface for writing Pandoc filters Panflute is a Python package that provides a Pythonic interface to the Pandoc filter API. It targets a similar niche as python3-pandocfilters, but has a more Python-idiomatic API, which I've found to be substantially more pleasant and similarly expressive. This will be my first Debian package, and I figured I'd get the packaging done before I asked around about maintenance arrangements. Maintaining it with the Python Modules Team would make the most sense, so I'll reach out to them once I have packaging for them to evaluate.
Bug#941607: RM: proteinortho [arm64 armel armhf i386 mips64el mipsel ppc64el s390x] -- ANAIS; b-d on sse2-only diamond-aligner
Package: ftp.debian.org Please remove proteinortho on these architectures. It build-depends on diamond-aligner which is now only built on amd64, see bug #916370.
Bug#940961: aptitude: upgrade of apt is not smooth
Control: forcemerge 95 -1 Am 22.09.2019 um 14:39 schrieb Oswald Buddenhagen: > Package: aptitude > Version: 0.8.12-1 > Severity: normal > > while upgrading apt from within aptitude, i got this error: > > [...] > Setting up libapt-pkg5.0:amd64 (1.8.4) ... > (Reading database ... 316101 files and directories currently installed.) > Preparing to unpack .../libapt-inst2.0_1.8.4_amd64.deb ... > Unpacking libapt-inst2.0:amd64 (1.8.4) over (1.8.3) ... > Preparing to unpack .../archives/apt_1.8.4_amd64.deb ... > Unpacking apt (1.8.4) over (1.8.3) ... > dpkg: error: dpkg frontend lock is locked by another process This appears to be the same problem as #95. Quoting dpkg maintainer Guillem Jover: > This is a problem with aptitude, which I'm told has not been modified > to make use of the new frontend locks, so it suffers from the > historical race conditions when more than one frontend are running > concurrently. Cheers, Sven
Bug#901309: Internal Error, No file name for exim4-config:amd64
Control: reassign -1 apt Control: merge 670920 -1 On 2018-06-11 16:47 +0800, 積丹尼 Dan Jacobson wrote: > Package: aptitude > Version: 0.8.10-9 > > # aptitude search exim4-config > Cr exim4-config > # aptitude reinstall exim4-config > The following packages will be REINSTALLED: > exim4-config > ... > E: Internal Error, No file name for exim4-config:amd64 This message actually comes from libapt-pkg. For more details, please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670920#10. Cheers, Sven
Bug#922709: vmdb2: variable for rootfs caching is incorrectly documented
tags 922709 + confirmed,pending thanks I can confirm this issue has been fixed in Lars' repository, and will be uploaded when a new version is released.
Bug#941550: glib2.0: intermittent test failure: mimeapps test segfaults
On Wed, 02 Oct 2019 at 12:12:06 +0100, Simon McVittie wrote: > On Tue, 01 Oct 2019 at 23:07:13 +0100, Simon McVittie wrote: > > glib2.0 2.62.0-2 failed tests a couple of times on s390x, with a > > segmentation fault running gio/tests/mimeapps.c. > > This also happened on amd64 This can be reproduced by running the test in a loop: meson test --repeat=1000 --gdb -C ~/tmp/build/glib/debug -v mimeapps (This is in upstream GLib, not in a Debian package, if that matters. The equivalent build directory in the Debian package is debian/build/deb.) Looks like maybe a use-after-free, or a conflict between threads? Thread 2 (Thread 0x777cc700 (LWP 15468)): #0 __strrchr_avx2 () at ../sysdeps/x86_64/multiarch/strrchr-avx2.S:87 #1 0x77ed3655 in g_path_get_dirname (file_name=0x3131313131313131 ) at ../../../../../../home/smcv/src/glib/glib/gfileutils.c:2441 #2 0x77cfd5db in desktop_file_dir_get_alternative_dir (dir=0x555859f0) at ../../../../../../home/smcv/src/glib/gio/gdesktopappinfo.c:193 #3 0x77cfd694 in desktop_file_dir_changed (monitor=0x5558b8b0, file=0x555838c0, other_file=0x0, event_type=G_FILE_MONITOR_EVENT_DELETED, user_data=0x555859f0) at ../../../../../../home/smcv/src/glib/gio/gdesktopappinfo.c:241 #4 0x77ca973b in _g_cclosure_marshal_VOID__OBJECT_OBJECT_ENUMv (closure=0x5557d930, return_value=0x0, instance=0x5558b8b0, args=0x777cbac8, marshal_data=0x0, n_params=3, param_types=0x55575b50) at ../../../../../../home/smcv/src/glib/gio/gmarshal-internal.c:1380 #5 0x77e43354 in _g_closure_invoke_va (closure=0x5557d930, return_value=0x0, instance=0x5558b8b0, args=0x777cbac8, n_params=3, param_types=0x55575b50) at ../../../../../../home/smcv/src/glib/gobject/gclosure.c:873 #6 0x77e5f35d in g_signal_emit_valist (instance=0x5558b8b0, signal_id=2, detail=0, var_args=0x777cbac8) at ../../../../../../home/smcv/src/glib/gobject/gsignal.c:3310 #7 0x77e605a7 in g_signal_emit (instance=0x5558b8b0, signal_id=2, detail=0) at ../../../../../../home/smcv/src/glib/gobject/gsignal.c:3457 #8 0x77c964c0 in g_file_monitor_emit_event (monitor=0x5558b8b0, child=0x555838c0, other_file=0x0, event_type=G_FILE_MONITOR_EVENT_DELETED) at ../../../../../../home/smcv/src/glib/gio/gfilemonitor.c:294 #9 0x77d933d0 in g_file_monitor_source_dispatch (source=0x555803d0, callback=0x0, user_data=0x0) at ../../../../../../home/smcv/src/glib/gio/glocalfilemonitor.c:560 #10 0x77ee99b8 in g_main_dispatch (context=0x555776f0) at ../../../../../../home/smcv/src/glib/glib/gmain.c:3180 #11 0x77eea815 in g_main_context_dispatch (context=0x555776f0) at ../../../../../../home/smcv/src/glib/glib/gmain.c:3845 #12 0x77eea9f9 in g_main_context_iterate (context=0x555776f0, block=1, dispatch=1, self=0x55577800) at ../../../../../../home/smcv/src/glib/glib/gmain.c:3918 #13 0x77eeaabd in g_main_context_iteration (context=0x555776f0, may_block=1) at ../../../../../../home/smcv/src/glib/glib/gmain.c:3979 #14 0x77eec8b6 in glib_worker_main (data=0x0) at ../../../../../../home/smcv/src/glib/glib/gmain.c:5859 #15 0x77f1c392 in g_thread_proxy (data=0x55577800) at ../../../../../../home/smcv/src/glib/glib/gthread.c:805 #16 0x77998fb7 in start_thread (arg=) at pthread_create.c:486 #17 0x77b212ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x777cdc80 (LWP 15464)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x77f47a0b in g_mutex_lock_slowpath (mutex=0x77e2d300 ) at ../../../../../../home/smcv/src/glib/glib/gthread-posix.c:1340 #2 0x77f47aaf in g_mutex_lock (mutex=0x77e2d300 ) at ../../../../../../home/smcv/src/glib/glib/gthread-posix.c:1364 #3 0x77cff7ff in desktop_file_dirs_lock () at ../../../../../../home/smcv/src/glib/gio/gdesktopappinfo.c:1486 #4 0x77d05123 in g_app_info_get_default_for_type (content_type=0xa8c0 "image/bmp", must_support_uris=0) at ../../../../../../home/smcv/src/glib/gio/gdesktopappinfo.c:4310 #5 0x86b7 in test_mime_default_last_used (fixture=0x5557de60, test_data=0x0) at ../../../../../../home/smcv/src/glib/gio/tests/mimeapps.c:510 #6 0x77f18ffc in test_case_run (tc=0x5556dac0) at ../../../../../../home/smcv/src/glib/glib/gtestutils.c:2633 #7 0x77f193b8 in g_test_run_suite_internal (suite=0x5556c860, path=0x0) at ../../../../../../home/smcv/src/glib/glib/gtestutils.c:2721 #8 0x77f19461 in g_test_run_suite_internal (suite=0x5556c840, path=0x0) at ../../../../../../home/smcv/src/glib/glib/gtestutils.c:2733 #9 0x77f19461 in g_test_run_suite_internal (suite=0x5556c820, path=0x0) at ../../../../../../home/smcv/src/glib/glib/gtestutils.c:2733 #10 0x77f19678 in g_test_run_suite
Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python
On Wed, Oct 02, 2019 at 11:27:26AM -0400, Sandro Tosi wrote:
> in the long description, i would also mention that this module uses
> dill to serialize objects (which is a tremendous advantage over plain
> multiprocessing)
Just commited:
$ git diff HEAD^
diff --git a/debian/control b/debian/control
index a1020c2..0d42fbe 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Depends: ${python3:Depends},
python3-dill (>= 0.3.1)
Description: better multiprocessing and multithreading in Python
Multiprocess is a fork of multiprocessing, and is developed as part of
- pathos.
+ pathos. It uses dill to serialize objects.
.
Multiprocessing is a package for the Python language which supports the
spawning of processes using the API of the standard library's threading
Is this OK for you or do you have a better suggestion?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python
On Wed, 2019-10-02 at 19:14 +0200, Andreas Tille wrote: > On Wed, Oct 02, 2019 at 04:00:49PM +0100, Ben Hutchings wrote: > > On Wed, 2019-10-02 at 05:26 +0200, Andreas Tille wrote: > > > Multiprocess is a fork of multiprocessing, and is developed as part of > > > pathos. > > > . > > > Multiprocessing is a package for the Python language which supports the > > > spawning of processes using the API of the standard library's threading > > > module. multiprocessing has been distributed in the Python standard > > > library. > > [...] > > > > The package description needs to make a much clearer distinction > > between the original multiprocessing module and this fork. > > Hmmm, I wonder whether you could make some suggestion how to make it > much clearer. I've thought the first sentence would be clear enought - > but any patch is welcome. No, that's not my job. You could ask on debian-l10n-english. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python
On Wed, Oct 02, 2019 at 04:00:49PM +0100, Ben Hutchings wrote: > On Wed, 2019-10-02 at 05:26 +0200, Andreas Tille wrote: > > Multiprocess is a fork of multiprocessing, and is developed as part of > > pathos. > > . > > Multiprocessing is a package for the Python language which supports the > > spawning of processes using the API of the standard library's threading > > module. multiprocessing has been distributed in the Python standard > > library. > [...] > > The package description needs to make a much clearer distinction > between the original multiprocessing module and this fork. Hmmm, I wonder whether you could make some suggestion how to make it much clearer. I've thought the first sentence would be clear enought - but any patch is welcome. Kind regards Andreas. -- http://fam-tille.de
Bug#941603: udev: bond interface does not inherit mac address of a slave
On 02/10/2019 19:36, Michael Biebl wrote: Could you file this upstream at https://github.com/systemd/systemd/issues and report back with the bug number? Sorry, but I can't, because I did not test it with the pure upstream sources. Moreover, I do not see this issue on Ubuntu 19.10 udev: Installed: 242-6ubuntu1 Candidate: 242-6ubuntu1 Version table: *** 242-6ubuntu1 500 500 http://ru.archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status So I guess there is something about Debian-specific patches/configuration. -- Alexandra N. Kossovsky OKTET Labs (http://www.oktetlabs.ru/)
Bug#941603: udev: bond interface does not inherit mac address of a slave
Am 02.10.19 um 18:50 schrieb Alexandra N. Kossovsky: > On 02/10/2019 19:36, Michael Biebl wrote: >> Could you file this upstream at >> https://github.com/systemd/systemd/issues and report back with the bug >> number? > > Sorry, but I can't, because I did not test it with the pure upstream > sources. > > Moreover, I do not see this issue on Ubuntu 19.10 > udev: > Installed: 242-6ubuntu1 > Candidate: 242-6ubuntu1 > Version table: > *** 242-6ubuntu1 500 > 500 http://ru.archive.ubuntu.com/ubuntu eoan/main amd64 Packages > 100 /var/lib/dpkg/status > > So I guess there is something about Debian-specific patches/configuration. > We are pretty close to upstream and don't ship any Debian specific patches which would modify that behaviour [1] So it should be safe to file this upstream. [1] https://salsa.debian.org/systemd-team/systemd/tree/master/debian/patches/debian -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#941597: linux-image-5.2.0-0.bpo.2-arm64: Raspberry Pi 3B+: does not shut down (regression against buster)
On Wed, 2 Oct 2019, Thorsten Glaser wrote: > With the backports kernel, a Raspberry Pi 3B+ cannot be shut down The messages when poweroff’ing: Will now halt. I: executing reboot "-d" "-f" "-i" "-p" "-h" regardless of check results. [ 5182.389595] kvm: exiting hardware virtualization [ 5182.398772] reboot: System halted bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#941603: udev: bond interface does not inherit mac address of a slave
Am 02.10.19 um 18:01 schrieb Alexandra N. Kossovsky: > Package: udev > Version: 242-7 > Severity: normal > > When I create a bonding interface on an older Debian system, it > naturally inherits one of the slave's mac address. With new Debian > testing (systemd=242-7) the bonding interface gets a strange MAC > address. > > The issue is, if I connect 2 Debian systems with a bonding interface, > then the 2 ends of the link has the same MAC address, and it all breaks. > > I tried to downgrade systemd to Debian buster version 241-7~deb10u1, and > it did not help (systemd, libsystemd0, libpam-systemd, systemd-coredump > packages). Then I downgraded udev as well (udev, libudev1, libudev-dev, > libudev1:i386, libudev-dev:i386 packages). Bonding interfaces got > different MAC addresses and started to work properly. > > > I.e. it is a regression in udev. which assigns some strange MAC address > to a just-created bonding interface; with a high chance that the > addresses of 2 link ends are the same. > > > To reproduce: > sudo ip link add bond0 type bond mode 1 > cat /sys/devices/virtual/net/bond0/addr_assign_type > ip li li dev bond0 > > I expect to see NET_ADDR_RANDOM=1 as the addr_assign_type, and different > MAC addresses on different systems as a result of the "ip" command. > With the last udev, I see NET_ADDR_SET=3 as the addr_assign_type, and > the same MAC address on both ends of my bond link. Thanks for your bug report. Could you file this upstream at https://github.com/systemd/systemd/issues and report back with the bug number? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#941606: RFS: dwarves/1.15-2
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.15-2 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.15-2.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.15-2) unstable; urgency=low * Fix hardening-no-bindnow. * Fix debian-watch-uses-insecure-uri. * Fix debian-watch-does-not-check-gpg-signature. * Fix priority-extra-is-replaced-by-priority-optional. * Revert to dwarves-dbgsym for tests execution but skip the test if it's not installable (i.e. on transition to testing). -- Domenico Andreoli Mon, 23 Sep 2019 18:21:35 +0200 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#941605: Please split installed tests into separate package
Package: rtkit Version: 0.12-4 Severity: wishlist Hi, I think /usr/libexec/installed-tests /usr/libexec/installed-tests/rtkit /usr/libexec/installed-tests/rtkit/rtkit-test should be split into a separate binary package, like rtkit-tests. Regards, Michael -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rtkit depends on: ii adduser 3.118 ii dbus 1.12.16-2 ii libc62.29-2 ii libcap2 1:2.25-2 ii libdbus-1-3 1.12.16-2 ii libsystemd0 243-2 ii policykit-1 0.105-26 rtkit recommends no packages. rtkit suggests no packages. -- no debconf information
Bug#941604: rollup 0.56 transition: rainbow.js build fails with 'Unknown option found: moduleName, dest'
Package: rainbow.js version: 2.1.4+ds-1 severity: important rainbow.js fails with rollup 0.56 currently in experimental. Please update your package to work with rollup 0.56. The error message is, NODE_PATH=debian/node_modules gulp pack [16:17:26] Local gulp not found in /<> [16:17:26] Try running: npm install gulp [16:17:26] Using globally installed gulp [16:17:27] Using gulpfile /<>/gulpfile.js [16:17:27] Starting 'pack'... The following options have been renamed — please update your config: entry -> input Unknown option found: moduleName, dest. Allowed keys: input, legacy, treeshake, acorn, acornInjectPlugins, context, moduleContext, plugins, onwarn, watch, cache, preferConst, experimentalDynamicImport, experimentalCodeSplitting, preserveSymlinks, entry, external, extend, amd, banner, footer, intro, format, outro, sourcemap, sourcemapFile, name, globals, interop, legacy, freeze, indent, strict, noConflict, paths, exports, file, dir, pureExternalModules [16:17:27] 'pack' errored after 229 ms [16:17:27] Error: You must supply output.name for UMD bundles at Object.error [as default] (/usr/share/nodejs/rollup/src/utils/error.js:10:15) at umd (/usr/share/nodejs/rollup/src/finalisers/umd.js:30:24) at /usr/share/nodejs/rollup/src/Chunk.js:585:27 at process._tickCallback (internal/process/next_tick.js:68:7) I tried to fix it, but I could not.
Bug#941603: udev: bond interface does not inherit mac address of a slave
Package: udev Version: 242-7 Severity: normal When I create a bonding interface on an older Debian system, it naturally inherits one of the slave's mac address. With new Debian testing (systemd=242-7) the bonding interface gets a strange MAC address. The issue is, if I connect 2 Debian systems with a bonding interface, then the 2 ends of the link has the same MAC address, and it all breaks. I tried to downgrade systemd to Debian buster version 241-7~deb10u1, and it did not help (systemd, libsystemd0, libpam-systemd, systemd-coredump packages). Then I downgraded udev as well (udev, libudev1, libudev-dev, libudev1:i386, libudev-dev:i386 packages). Bonding interfaces got different MAC addresses and started to work properly. I.e. it is a regression in udev. which assigns some strange MAC address to a just-created bonding interface; with a high chance that the addresses of 2 link ends are the same. To reproduce: sudo ip link add bond0 type bond mode 1 cat /sys/devices/virtual/net/bond0/addr_assign_type ip li li dev bond0 I expect to see NET_ADDR_RANDOM=1 as the addr_assign_type, and different MAC addresses on different systems as a result of the "ip" command. With the last udev, I see NET_ADDR_SET=3 as the addr_assign_type, and the same MAC address on both ends of my bond link. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable'), (200, 'experimental'), (30, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages udev depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libacl1 2.2.53-5 ii libblkid1 2.34-0.1 ii libc6 2.29-2 ii libkmod2 26-3 ii libselinux1 2.9-2+b2 ii libudev1 242-7 ii systemd-sysv 242-7 ii util-linux2.34-0.1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 242-7 -- debconf information: udev/reboot_needed: udev/title/upgrade: udev/new_kernel_needed: false udev/sysfs_deprecated_incompatibility: -- Alexandra N. Kossovsky OKTET Labs (http://www.oktetlabs.ru/)
Bug#940839: Same bug with 2.4.4
Same situation here with openshot 2.4.4 from debian sid. I have an intel gpu.
Bug#930634: [Pkg-javascript-devel] Bug#930634: Bug#930634: Bug#930634: Build failures with rollup 0.56
On Mon, 30 Sep 2019 19:49:38 +0530 Pirate Praveen wrote: > The following fail (18/77 reverse build dependencies), but should work > after adding the required plugin as build dependency. > > leaflet leaflet-markercluster node-d3 node-immutable-tuple > node-magic-string node-mocha node-react node-rollup-plugin-babel > node-rollup-plugin-commonjs node-rollup-plugin-json > node-rollup-plugin-node-resolve node-rollup-plugin-replace > node-rollup-plugin-string node-rollup-plugin-typescript node-tippex > node-uri-js popper.js rainbow.js twitter-bootstrap4 > Except the following packages, all have been fixed in unstable. Patches in BTS: leaflet leaflet-markercluster Not sure if it is worth fixing the unstable version as experimental has a new version: node-mocha Needs converting to proper uscan based components: node-react Ready in experimental: node-rollup-plugin-commonjs Already broken with rc bugs: node-rollup-plugin-typescript Blocked by node-typescript regression: node-uri-js Ready for review: popper.js twitter-bootstrap4 Someone working on it: rainbow.js So once node-typescript regression is fixed, I will upload rolup 0.56.3 to unstable. signature.asc Description: OpenPGP digital signature
Bug#941601: rollup 0.56 transition: Add node-rollup-plugin-json to build depends and fix 'format is now output.format' error
Package: leaflet-markercluster Version: 1.4.1~dfsg-6 Severity: important Control: tags -1 patch It needs the following changes, diff --git a/debian/control b/debian/control index 341cd23..09dc90e 100644 --- a/debian/control +++ b/debian/control @@ -12,6 +12,7 @@ Build-Depends: pigz, rename, rollup, + node-rollup-plugin-json, sassc, uglifyjs (>= 3), Standards-Version: 4.3.0 and it still fails, NODE_ENV=release rollup --config build/rollup-config.js (!) Some options have been renamed https://gist.github.com/Rich-Harris/d472c50732dab03efeb37472b08a3f32 entry is now input moduleName is now output.name sourceMap is now output.sourcemap format is now output.format banner is now output.banner dest is now output.file src/index.js → dist/leaflet.markercluster-src.js... [!] Error: You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'es', 'iife' or 'umd' https://rollupjs.org/#format-f-output-format- Error: You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'es', 'iife' or 'umd' at Object.error [as default] (/usr/share/nodejs/rollup/src/utils/error.js:10:15) at checkOutputOptions (/usr/share/nodejs/rollup/src/rollup/index.js:37:24) at normalizeOptions (/usr/share/nodejs/rollup/src/rollup/index.js:95:21) at generate (/usr/share/nodejs/rollup/src/rollup/index.js:99:41) at Object.write (/usr/share/nodejs/rollup/src/rollup/index.js:131:32) at /usr/share/nodejs/rollup/bin/src/run/build.js:49:27 at next (/usr/share/nodejs/rollup/src/utils/promise.js:7:32) at /usr/share/nodejs/rollup/src/utils/promise.js:10:53 at process._tickCallback (internal/process/next_tick.js:68:7) at Function.Module.runMain (internal/modules/cjs/loader.js:834:11) After rollup configuration if fixed, I get an error with uglifyjs uglifyjs --compress --mangle \ --source-map "base='/<>/debian/js',content='dist/leaflet.markercluster-src.js.map',url='leaflet.markercluster.min.js.map'" \ --output debian/js/leaflet.markercluster.min.js \ -- dist/leaflet.markercluster-src.js ERROR: No element indexed by 0 at ArraySet_at [as at] (/usr/share/nodejs/source-map/lib/array-set.js:109:9) at BasicSourceMapConsumer.SourceMapConsumer_originalPositionFor [as originalPositionFor] (/usr/share/nodejs/source-map/lib/source-map-consumer.js:673:30) at Object.add (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :12216:32) at eval (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :3921:32) at Array.forEach () at OutputStream.flush_mappings (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :3920:18) at Object.print (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :4025:29) at eval (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :4847:16) at doit (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :4356:13) at AST_Var.eval (eval at (/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :4363:13) This was fixed by switching to uglifyjs.terser. Entire change is here https://salsa.debian.org/js-team/leaflet-markercluster/merge_requests/1
Bug#941602: O: tstools -- set of tools for reporting on and manipulating MPEG data
Package: wnpp Severity: normal The previous maintainer of tstools, Lorenzo Granai , wishes no longer be the maintainer. Therefor, I orphan this package now. If you want to be the new maintainer, please take it -- see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. This package has an inactive upstream on GitHub and its latest source code has been reflected in the most recent QA upload. Please feel free to take over package maintainership and I can help sponsor your new upload if you need any help. Some information about the package: Package: tstools Version: 1.13~git20151030-1 Installed-Size: 4456 Maintainer: Debian QA Group Architecture: amd64 Depends: libc6 (>= 2.29) Description-en: set of tools for reporting on and manipulating MPEG data TStools is a set of cross-platform command line tools for working with MPEG data. . The emphasis is on relatively simple tools which concentrate on MPEG (H.264 and H.262) data packaged according to H.222 (i.e., TS or PS), with a particular interest in checking for conformance. . Transport Stream (TS) is typically used for distribution of cable and satellite data. Program Stream (PS) is typically used to store data on DVDs. . The tools are focussed on: * Quick reporting of useful data (tsinfo, stream_type) * Giving a quick overview of the entities in the stream (esdots, psdots) * Reporting on TS packets (tsreport) or ES units/frames/fields (esreport) * Simple manipulation of stream data (es2ts, esfilter, esreverse, esmerge, ts2es) * Streaming of data, possibly with introduced errors (tsplay) Description-md5: 6c79162540231386d8d6d53dccab79a0 Homepage: https://github.com/kynesim/tstools Tag: implemented-in::c, interface::commandline, role::program, works-with::video Section: utils Priority: optional Filename: pool/main/t/tstools/tstools_1.13~git20151030-1_amd64.deb Size: 471304 MD5sum: d10eab0a246ac25f016208ccdac3f25c SHA256: 138b055c6aadd27830b2b619a66ee6d0f473b0b3cb294cf79557bbed6662a929 Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#941600: kio leads to a crash of kinit (SIGSEGV)
Package: kio Version: 5.62.1-1 Severity: normal Dear Maintainer, After installing the latest updates for kinit and kio, I received constant crashes of kinit. After a bit of investigation, it turned out, that this is a known bug of kio: https://bugs.kde.org/show_bug.cgi?id=408797 A patch is already available upstream, but not in a release of KDE Frameworks yet: https://cgit.kde.org/kio.git/commit/?id=2c379fecccbf5e2c0b20a93c843c009f2f597318 Applying these patch to kio fixes the issue for me. Best, Andreas -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (900, 'oldstable'), (799, 'oldoldstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kio depends on: ii libacl1 2.2.53-5 ii libc6 2.29-2 ii libgcc1 1:9.2.1-8 ii libgssapi-krb5-2 1.17-6 ii libkf5archive55.62.0-1 ii libkf5authcore5 5.62.0-1 ii libkf5codecs5 5.62.0-1 ii libkf5completion5 5.62.0-1 ii libkf5configcore5 5.62.0-1 ii libkf5configwidgets5 5.62.0-1 ii libkf5coreaddons5 5.62.0-1 ii libkf5dbusaddons5 5.62.0-1 ii libkf5doctools5 5.62.0-1 ii libkf5i18n5 5.62.0-1 ii libkf5itemviews5 5.62.0-1 ii libkf5kiocore55.62.1-1 ii libkf5kiontlm55.62.1-1 ii libkf5kiowidgets5 5.62.1-1 ii libkf5notifications5 5.62.0-1 ii libkf5service-bin 5.62.0-1 ii libkf5service55.62.0-1 ii libkf5solid5 5.62.0-2 ii libkf5textwidgets55.62.0-1 ii libkf5wallet-bin 5.62.0-1 ii libkf5wallet5 5.62.0-1 ii libkf5widgetsaddons5 5.62.0-1 ii libkf5windowsystem5 5.62.0-2 ii libqt5core5a 5.11.3+dfsg1-4 ii libqt5dbus5 5.11.3+dfsg1-4 ii libqt5gui55.11.3+dfsg1-4 ii libqt5network55.11.3+dfsg1-4 ii libqt5script5 5.11.3+dfsg-3 ii libqt5widgets55.11.3+dfsg1-4 ii libqt5x11extras5 5.11.3-2 ii libqt5xml55.11.3+dfsg1-4 ii libstdc++69.2.1-8 ii libxml2 2.9.4+dfsg1-7+b3 ii libxslt1.11.1.32-2.1 kio recommends no packages. kio suggests no packages. -- no debconf information
Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python
> * Package name: multiprocess > Version : 0.70.9 > Upstream Author : California Institute of Technology. > * URL : https://github.com/uqfoundation/multiprocess > * License : BSD-3-clause > Programming Lang: C > Description : better multiprocessing and multithreading in Python in the long description, i would also mention that this module uses dill to serialize objects (which is a tremendous advantage over plain multiprocessing) -- 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#941599: ITP: altair -- Declarative Visualization in Python
Package: wnpp Severity: wishlist Owner: "Santiago Ruano Rincón" * Package name: altair Version : 3.2.0 Upstream Author : Jake Vanderplas, Brian Granger, the UW Interactive Data Lab, et al. * URL : https://altair-viz.github.io/ * License : BSD-3-Clause Programming Lang: Python Description : Declarative Visualization in Python Altair is a declarative statistical visualization library for Python, based on Vega [1] (A Visualization Grammar) and Vega-Lite [2]. [1] https://vega.github.io/vega/ [2] https://vega.github.io/vega-lite/ It would be great to maintain altair inside the Python Modules Team. signature.asc Description: PGP signature
Bug#941542: [Pkg-electronics-devel] Bug#941542: ngspice: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Control: tags -1 + pending Hello Steve, Am 01.10.19 um 23:33 schrieb Steve Langasek: > Dear maintainers, > > The texlive-generic-recommended transitional package has been dropped from > texlive-base in sid. Please update your build-dependency to > texlive-plain-generic instead. thanks for the diff. I applied your modification. I wasn't aware of this change. -- Regards Carsten Schoenert
Bug#941598: Add node-rollup-pugin-json as build dependency (required for rollup 0.56.3)
Package: leaflet Version: 1.5.1~dfsg-1 Severity: important The following patch fixes build with rollup 0.56.3-1 (currently in experimental). This version will be uploaded to unstable soon. diff --git a/debian/control b/debian/control index 16b443d9..6b047ad6 100644 --- a/debian/control +++ b/debian/control @@ -13,6 +13,7 @@ Build-Depends: pigz, rename, rollup, + node-rollup-plugin-json Standards-Version: 4.4.0 Vcs-Browser: https://salsa.debian.org/js-team/leaflet Vcs-Git: https://salsa.debian.org/js-team/leaflet.git
Bug#941597: linux-image-5.2.0-0.bpo.2-arm64: Raspberry Pi 3B+: does not shut down (regression against buster)
Package: src:linux Version: 5.2.9-2~bpo10+1 Severity: normal With the backports kernel, a Raspberry Pi 3B+ cannot be shut down or rebooted; the buster kernel manages that (but does not have sound). I’ve captured the last couple of lines on the screen: the first two are from sysvinit, three kernel ones follow: Will now restart. I: executing reboot "-d" "-f" "-i" regardless of check results. [ 1168.343056] kvm: exiting hardware virtualization [ 1168.352199] reboot: Restarting system [ 1168.358391] Reboot failed -- System halted Note I have the following firmware package installed: ii raspi3-firmware 1.20190215-1+deb10u1 arm64Raspberry Pi 2 and 3 GPU firmware and bootloaders I know unstable carries a later one, but that’s not in backports. Not sure whether that would make a difference. Currently, the kernel is the only backports package I have installed. -- Package-specific info: ** Version: Linux version 5.2.0-0.bpo.2-arm64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.2.9-2~bpo10+1 (2019-08-25) ** Command line: bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0xa5e576b6 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:E5:76:B6 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=ttyS0,115200 console=tty0 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=128M rootwait ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [5.053654] dwc2 3f98.usb: irq 41, io mem 0x3f98 [5.059640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.02 [5.065497] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [5.071349] usb usb1: Product: DWC OTG Controller [5.077130] usb usb1: Manufacturer: Linux 5.2.0-0.bpo.2-arm64 dwc2_hsotg [5.082902] usb usb1: SerialNumber: 3f98.usb [5.089579] hub 1-0:1.0: USB hub found [5.095483] hub 1-0:1.0: 1 port detected [5.495140] usb 1-1: new high-speed USB device number 2 using dwc2 [5.713780] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3 [5.719700] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [5.727468] hub 1-1:1.0: USB hub found [5.733423] hub 1-1:1.0: 4 ports detected [5.746030] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [6.027120] usb 1-1.1: new high-speed USB device number 3 using dwc2 [6.049550] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [6.131504] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3 [6.137581] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [6.144425] hub 1-1.1:1.0: USB hub found [6.150479] hub 1-1.1:1.0: 3 ports detected [6.443150] usb 1-1.1.2: new low-speed USB device number 4 using dwc2 [6.561074] usb 1-1.1.2: New USB device found, idVendor=1241, idProduct=1177, bcdDevice= 2.70 [6.567077] usb 1-1.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [6.655174] usb 1-1.1.3: new low-speed USB device number 5 using dwc2 [6.764926] usb 1-1.1.3: New USB device found, idVendor=413c, idProduct=2106, bcdDevice= 1.01 [6.771086] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [6.777081] usb 1-1.1.3: Product: Dell QuietKey Keyboard [6.782996] usb 1-1.1.3: Manufacturer: DELL [7.011214] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 [7.119877] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=7800, bcdDevice= 3.00 [7.125885] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [7.262851] random: crng init done [7.381018] systemd-udevd[357]: Network interface NamePolicy= disabled on kernel command line, ignoring. [8.250758] vchiq: module is from the staging directory, the quality is unknown, you have been warned. [8.273456] vchiq: vchiq_init_state: slot_zero = fa164383 [8.316841] bcm2835-rng 3f104000.rng: hwrng registered [8.380910] systemd-udevd[374]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. [8.589125] hidraw: raw HID events driver (C) Jiri Kosina [8.614860] libphy: Fixed MDIO Bus: probed [8.700164] usbcore: registered new interface driver usbhid [8.707013] usbhid: USB HID core driver [8.919856] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No External EEPROM. Setting MAC Speed [8.928383] libphy: lan78xx-mdiobus: probed [9.113656] media: Linux media interface: v0.10 [9.174565] usbcore: registered new interface driver lan78xx [9.237491] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [9.245368] usbcore: registered new
Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog
control: tag -1 +moreinfo Hello, On Tue 01 Oct 2019 at 04:21PM +02, Mattia Rizzolo wrote: > On Tue, Oct 01, 2019 at 07:14:08AM -0700, Sean Whitton wrote: >> Hmm, this was deliberate because the additional documentation doesn't >> require anyone to make changes to their packages. >> >> Could you explain why you want it in the upgrading checklist? > > because it's a new thing, and it helps those people that don't follow > closely enough to know that there is a new thing. So if at some point > any given package start to need some "reboot required" information, > everybody who read once the checklist know that there already is a > policy/standard for that. Well, it's new to the Policy Manual, but it's certainly not new in the archive. > Like you document in the checklist addition to the virtual packages: > also those don't require any change to existing packages, it's just > there for everybody to know that starting from that version they can > make use of that new thing. Okay. From your point of view, if we started to add a summary of d/changelog entries which are /not/ accounted for by the upgrading checklist to the d-d-a e-mail, would that be sufficient? Or do you think this stuff has to be in the upgrading checklist? -- Sean Whitton signature.asc Description: PGP signature
Bug#941596: Pull ubuntu patches for architectures support
Package: src:ltrace Version: 0.7.3-6.1 -- Dear maintainer, Ubuntu added several patches in 0.7.3-6.1ubuntu1 that add support amongst other for ppc64el, armhf, arm64. Would they be worth dragging ? Regards, F. pgpJj_sxEbk2S.pgp Description: PGP signature
Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python
On Wed, 2019-10-02 at 05:26 +0200, Andreas Tille wrote: > Package: wnpp > Severity: wishlist > Owner: Andreas Tille > > * Package name: multiprocess > Version : 0.70.9 > Upstream Author : California Institute of Technology. > * URL : https://github.com/uqfoundation/multiprocess > * License : BSD-3-clause > Programming Lang: C > Description : better multiprocessing and multithreading in Python > Multiprocess is a fork of multiprocessing, and is developed as part of > pathos. > . > Multiprocessing is a package for the Python language which supports the > spawning of processes using the API of the standard library's threading > module. multiprocessing has been distributed in the Python standard library. [...] The package description needs to make a much clearer distinction between the original multiprocessing module and this fork. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#941591: binutils FTBFS: makeinfo failure
> binutils fails to build from source in unstable on amd64. A build log > ends as follows: Most probably a bug in texinfo 6.7.0.dfsg.2-2 which uses the XS parser, which seems to be incomplete. 6.7.0.dfsg.2-3 is already uploaded and in sid which switches back to the Perl parser, this should fix all the problems here. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#941594: ITP: node-chai-as-promised -- Extends Chai with assertions about promises
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name : node-chai-as-promised Version : 7.1.1 Upstream Author : Domenic Denicola * URL : https://github.com/domenic/chai-as-promised * License : WTFPL Programming Lang: JavaScript Description : Extends Chai with assertions about promises Chai as Promised extends Chai with a fluent language for asserting facts about promises. chai-as-promised is a dependency of sequelize, which I intend to package eventually. Remark: This package is to be maintained with Debian Javascript Maintainers at https://salsa.debian.org/js-team/node-chai-as-promised
Bug#941595: allow logs in ~/.irssi/irclogs
Package: apparmor-profiles-extra
Severity: wishlist
Tags: patch
It's common to store irc logs in ~/.irssi/irclogs. Even though
upstream suggests the default is ~/irclogs, that breaks all sorts of
expectations (like that programs shouldn't store random files in the
home directory).
(Arguably, even ~/.irssi should be in ~/.config, but that's besides
the point.)
This patch fixes the problem for me:
--- /etc/apparmor.d/usr.bin.irssi.dpkg-dist 2019-02-25 09:34:49.0
-0500
+++ /etc/apparmor.d/usr.bin.irssi 2017-07-01 14:05:39.211383678 -0400
@@ -41,9 +41,10 @@
owner @{HOME}/.irssi/*.theme wk,
# http://www.irssi.org/documentation/startup states that ~/irclogs is the
- # default location for logs.
- owner @{HOME}/irclogs/ r,
- owner @{HOME}/irclogs/** rwk,
+ # default location for logs. Also allow the common configuration of logging
+ # inside the .irssi directory.
+ owner @{HOME}/{.irssi/,}irclogs/ r,
+ owner @{HOME}/{.irssi/,}irclogs/** rwk,
# for fnotify
owner @{HOME}/.irssi/fnotify rwk,
-- System Information:
Debian Release: 10.1
APT prefers stable
APT policy: (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apparmor-profiles-extra depends on:
ii apparmor 2.13.2-10
apparmor-profiles-extra recommends no packages.
apparmor-profiles-extra suggests no packages.
Bug#941593: libpam-x2go FTCBFS: abuses AC_CHECK_FILES
Source: libpam-x2go Version: 0.0.2.0-2 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs libpam-x2go fails to cross build from source, because m4/gtest.m4 abuses AC_CHECK_FILES. It uses the macro to check for files on the build system, while it is meant for checking files on the host system. Please use a plain test -e for the former. Please consider applying the attached patch. Helmut --- libpam-x2go-0.0.2.0.orig/m4/gtest.m4 +++ libpam-x2go-0.0.2.0/m4/gtest.m4 @@ -49,8 +49,7 @@ AC_LANG_POP - AC_CHECK_FILES([$GTEST_SOURCE/src/gtest-all.cc] - [$GTEST_SOURCE/src/gtest_main.cc], + AS_IF([test -e "$GTEST_SOURCE/src/gtest-all.cc" || test -e "$GTEST_SOURCE/src/gtest_main.cc"], [have_gtest_source=yes], [have_gtest_source=no])
Bug#941592: plasma-discover FTBFS: dh_install: Cannot find (any matches for) "etc/dbus-1/system.d/org.kde.discover.libsnapclient.conf" (tried in ., debian/tmp)
Source: plasma-discover Version: 5.14.5.1-1 Severity: serious Tags: ftbfs plasma-discover fails to build from source in sbuild on amd64. A build ends with: | make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' |dh_install -O--buildsystem=kf5 | dh_install: Cannot find (any matches for) "etc/dbus-1/system.d/org.kde.discover.libsnapclient.conf" (tried in ., debian/tmp) | | dh_install: plasma-discover-backend-snap missing files: etc/dbus-1/system.d/org.kde.discover.libsnapclient.conf | dh_install: missing files, aborting | make: *** [debian/rules:12: binary] Error 255 | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Reproducible by reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/plasma-discover_5.14.5.1-1.rbuild.log.gz Helmut
Bug#941591: binutils FTBFS: makeinfo failure
Source: binutils Version: 2.32.51.20190909-1 Severity: serious Tags: ftbfs binutils fails to build from source in unstable on amd64. A build log ends as follows: | restore=: && backupdir=".am$$" && \ | rm -rf $backupdir && mkdir $backupdir && \ | if (makeinfo --split-size=500 --split-size=500 --version) >/dev/null 2>&1; then \ | for f in as.info as.info-[0-9] as.info-[0-9][0-9] as.i[0-9] as.i[0-9][0-9]; do \ | if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ | done; \ | else :; fi && \ | if makeinfo --split-size=500 --split-size=500 -I "../../../gas/doc" -I "../../../gas/../libiberty" -I "../../../gas/../bfd/doc" -I ../../bfd/doc -I ../../../gas/doc \ | -o as.info `test -f 'as.texi' || echo '../../../gas/doc/'`as.texi; \ | then \ | rc=0; \ | else \ | rc=$?; \ | $restore $backupdir/* `echo "./as.info" | sed 's|[^/]*$||'`; \ | fi; \ | rm -rf $backupdir; exit $rc | touch as.1 | perl ../../../gas/doc/../../etc/texi2pod.pl -I "../../../gas/doc" -I "../../../gas/../libiberty" -I "../../../gas/../bfd/doc" -I ../../bfd/doc -Dman < ../../../gas/doc/as.texi > as.pod | (pod2man --center="GNU Development Tools" --release="binutils-2.32.51" --section=1 as.pod | \ | sed -e '/^.if n .na/d' > as.1.T$$ && \ | mv -f as.1.T$$ as.1) || \ | (rm -f as.1.T$$ && exit 1) | rm -f as.pod | as.texi:37: bad name for @ifset | as.texi:46: bad name for @ifset | as.texi:651: warning: @include should only appear at the beginning of a line | as.texi:651: warning: @include should not appear in @table | as.texi:657: warning: @item should not appear in @table | as.texi:657: @item outside of table or list | as.texi:954: warning: @item should not appear in @table | as.texi:954: @item outside of table or list | as.texi:968: warning: @item should not appear in @table | as.texi:968: @item outside of table or list | as.texi:1059: warning: @cindex should only appear at the beginning of a line | as.texi:1059: warning: @cindex should not appear in @table | as.texi:1070: warning: @cindex should only appear at the beginning of a line | as.texi:1070: warning: @cindex should not appear in @table | as.texi:1257: warning: @item should not appear in @table | as.texi:1257: @item outside of table or list | as.texi:1376: warning: @item should not appear in @table | as.texi:1376: @item outside of table or list | as.texi:1377: warning: @itemx should not begin @table | as.texi:1400: warning: @item should not appear in @table | as.texi:1400: @item outside of table or list | as.texi:1417: warning: @item should not appear in @table | as.texi:1417: @item outside of table or list | as.texi:1715: warning: @item should not appear in @table | as.texi:1715: @item outside of table or list | as.texi:1716: warning: @itemx should not begin @table | as.texi:1834: warning: @item should not appear in @table | as.texi:1834: @item outside of table or list | as.texi:1835: warning: @itemx should not begin @table | as.texi:1939: warning: @item should not appear in @table | as.texi:1939: @item outside of table or list | as.texi:2504: warning: @item should not appear in @table | as.texi:2504: @item outside of table or list | as.texi:7185: warning: @item should not appear in @table | as.texi:7185: @item outside of table or list | as.texi:7186: warning: @itemx should not begin @table | as.texi:7670: bad name for @ifset | c-alpha.texi:43: warning: @cindex should only appear at the beginning of a line | c-alpha.texi:43: warning: @cindex should not appear in @table | c-csky.texi:151: warning: @cindex should only appear at the beginning of a line | c-csky.texi:151: warning: @cindex should not appear in @table | as.texi:7885: bad name for @ifset | c-i386.texi:57: warning: @cindex should only appear at the beginning of a line | c-i386.texi:57: warning: @cindex should not appear in @table | c-ppc.texi:39: warning: @item should not appear in @table | c-ppc.texi:39: @item outside of table or list | c-tilegx.texi:30: warning: @cindex should only appear at the beginning of a line | c-tilegx.texi:30: warning: @cindex should not appear in @table | c-visium.texi:33: warning: @cindex should only appear at the beginning of a line | c-visium.texi:33: warning: @cindex should not appear in @table | make[5]: *** [Makefile:507: as.info] Error 1 | make[5]: Leaving directory '/<>/builddir-single/gas/doc' | make[4]: *** [Makefile:1274: all-recursive] Error 1 | make[4]: Leaving directory '/<>/builddir-single/gas' | make[3]: *** [Makefile:816: all] Error 2 | make[3]: Leaving directory '/<>/builddir-single/gas' | make[2]: *** [Makefile:4902: all-gas] Error 2 | make[2]: Leaving directory '/<>/builddir-single' | make[1]: *** [Makefile:852: all] Error 2 | make[1]: Leaving directory '/<>/builddir-single' | make: *** [debian/rules:647: stamps/build-single] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Likely this is some kind of regression in makeinfo. tex maintainers Cced. Helmut
