Bug#947449: installation-report: No networking on Olimex Lime2 (Allwinner A20)
Hello, Marek Nečada, le ven. 27 déc. 2019 02:41:17 +0200, a ecrit: > The same problem persists after installation and boot – the > eth0 interface shows up, ethernet connect/disconnect events > show up in dmesg, but the networking does not work in reality. Possible the board needs some non-free firmware? Did you try to install firmware-linux-free? Also, please post how the network board is detected (e.g. the complete dmesg output). Samuel
Bug#947161: transition: libwebsockets
On Thu, Dec 26, 2019 at 9:11 PM Paul Gevers wrote: > On 22-12-2019 10:53, László Böszörményi (GCS) wrote: > > Small transition with four affected packages. Namely ddnet, > > forked-daapd, janus and mosquitto. All build fine with the new > > libwebsocket release in experimental. > > Please go ahead. Uploaded and built on all of our primary and all possible secondary architectures. The binNMUs may start. Thanks, Laszlo/GCS
Bug#939276: xserver-core: Official PRIME Render Offload
reassign 939276 xserver-xorg-core 2:1.20.4-1 fixed 939276 2:1.20.6-1 thanks It looks like the new version is available in unstable now. -- Eldon Koyle
Bug#947457: critical bluestore data corruption
Package: ceph-osd Version: 14.2.4-4 Severity: grave Tags: upstream fixed-upstream A critical bluestore data corruption bug[0][1] affecting OSDs configured with separate db and/or wal devices has been introduced in 14.2.3 and is affecting both 14.2.3 and 14.2.4 upstream releases[2]. This bug has been fixed in upstream version 14.2.5. Fix is simple[4] and can be easily applied/backported to Debian release 14.2.4. [0] https://tracker.ceph.com/issues/42223 [1] https://github.com/ceph/ceph/pull/31621 [2] https://lists.ceph.io/hyperkitty/list/ceph-annou...@ceph.io/message/X6TNSDQK5DVKO6XFJW3DMJAJV63PLDYM/ [3] https://ceph.io/releases/v14-2-5-nautilus-released/ [4] https://github.com/ceph/ceph/commit/117c8b5ca0130e02be98848b6c323812e271af27
Bug#947456: ITP: golang-github-robdimsdale-sanitizer -- Keeps your (logging) sinks clean
Package: wnpp Severity: wishlist Owner: Bradford Boyle X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-robdimsdale-sanitizer Version : 0.0~git20160522.ab2334c-1 Upstream Author : Rob Dimsdale-Zucker * URL : https://github.com/robdimsdale/sanitizer * License : MIT Programming Lang: Go Description : Keeps your (logging) sinks clean sanitizer Keeps your (logging) sinks clean This is a build-dependency for github.com/pivotal-cf/go-pivnet which in turn is a build-dependency for github.com/pivotal-cf/pivnet-cli.
Bug#947455: RFP: cocalc -- CoCalc: Collaborative Calculation in the Cloud
Package: wnpp Severity: wishlist * Package name: cocalc Version : Upstream Author : William Stein wst...@sagemath.com * URL : https://github.com/sagemathinc/cocalc * License : AGPL Programming Lang: python, javascript Description : CoCalc: Collaborative Calculation in the Cloud Collaborative Calculation in the Cloud CoCalc offers collaborative calculation in the cloud. This includes working with the full (scientific) Python stack, SageMath, Julia, R, Octave, and more. It also offers capabilities to author documents in LaTeX, R/knitr or Markdown, storing and organizing files, a web-based Linux Terminal, communication tools like a chat, course management and more.
Bug#946979: any update to having a debian...@lists.debian.org ?
Hi all, This would be good to have so people can know updates or whatever is happening about nodejs or any of the javascript packages without having to scour the tens to hundreds of notifications/packages to get to the interesting discussions which could be shared widely. Looking forward to the new mailing list and see progress being made to nodejs and other packages on which it depends. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#947454: util-linux: su man page is confusing wih regard to - -l and --login
Package: util-linux Version: 2.33.1-0.1 Severity: normal Dear Maintainer, The man page for su says the following: "It is recommended to always use the --login option (instead of its shortcut -)". To me that doesn't make sense, they should be equivalent, and this is confirmed (and adds to the confusion) when I scroll down and the options -, -l, and --login are all listed as doing the exact same things. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.33.1-0.1 ii libaudit1 1:2.8.4-3 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libmount1 2.33.1-0.1 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libsmartcols1 2.33.1-0.1 ii libsystemd0241-7~deb10u2 ii libtinfo6 6.1+20181013-2+deb10u2 ii libudev1 241-7~deb10u2 ii libuuid1 2.33.1-0.1 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 ii util-linux-locales 2.33.1-0.1 -- no debconf information
Bug#947012: mmdebstrap: Extended attributes are lost in tarball
Control: tag -1 + pending Hi Ben, Quoting Benjamin Drung (2019-12-19 14:52:58) > When specifying a tarball as output format, the extended attributes are lost. > This leads to programs like ping fail to run as normal user. > > ``` > mmdebstrap --include=iputils-ping buster buster.tar > mkdir root > sudo tar --xattrs --xattrs-include='*' -C root -xf buster.tar > getcap root/bin/ping > ``` > > Therefore the attached patch will preserve the extended attributes when > generating the tarball. Then getcap will show: > > ``` > root/bin/ping = cap_net_raw+ep > ``` I agree, the created tarball should contain extended attributes. I had already applied the patch you sent me in another mail before this bug report to my local git but only now I realized that it's not working. Indeed one also needs to add --xattrs-include='*' to the tar invocation when creating and extracting a tarball with extended attributes even though the tar documentation says: > By default, when `--xattr' is used, all names are stored in the archive (or > extracted, if using `--extract'). So the patch is actually a bit bigger. I now added a test case because apparently all of this is easy to get wrong and added documentation that the user should add --xattr --xattrs-include='*' when extracting the tarball. Also the tar-in command in guestfish had to receive an xattrs:true. No worries, I already took care of it. Thanks! cheers, josch signature.asc Description: signature
Bug#947453: caja: With the MATE GreenLaguna theme, caja has a "graphical blob" on folder select
Package: caja Version: 1.20.3-1+b1 Severity: normal Dear Maintainer, Using MATE on Debian Stable with the GreenLaguna theme (and the proprietary NVIDIA driver), if I click a folder in the sidebar on the caja file manager, a thing pops up on the top left corner which says the absolute path of the folder. This is annoying, and probably a bug, some kind of graphical glitch -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages caja depends on: ii caja-common 1.20.3-1 ii desktop-file-utils0.23-4 ii gvfs 1.38.1-5 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libcaja-extension11.20.3-1+b1 ii libexempi82.5.0-2 ii libexif12 0.6.21-5.1 ii libgail-3-0 3.24.5-1 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglib2.0-bin2.58.3-2+deb10u2 ii libglib2.0-data 2.58.3-2+deb10u2 ii libgtk-3-03.24.5-1 ii libice6 2:1.0.9-2 ii libmate-desktop-2-17 1.20.4-2 ii libnotify40.7.7-4 ii libpango-1.0-01.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libselinux1 2.8-1+b1 ii libsm62:1.2.3-1 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii mate-desktop 1.20.4-2 ii shared-mime-info 1.10-1 Versions of packages caja recommends: ii gvfs-backends 1.38.1-5 Versions of packages caja suggests: ii engrampa1.20.2-1 pn gstreamer1.0-tools pn meld -- no debconf information
Bug#945681: gvb: diff for NMU version 1.4-1.1
On Thu, Dec 26, 2019 at 04:18:36PM +0100, Pietro Battiston wrote: > Dear Adrian, Dear Pietro, > thank you, I really appreciate. I was planning to fix that packaging > mistake, but as you might have noticed, I have really slow reactions > lately no worries, everyone has sometimes more urgent things in life. > - and then, I still need to go through a sponsor. So if you > prefer, feel free to re-upload the package without delay. Thanks, done. > Pietro cu Adrian
Bug#927302:
Bug#945605: python-neovim: diff for NMU version 0.3.0-1.1
On Mon, Dec 23, 2019 at 12:36:25PM +0200, Adrian Bunk wrote: > I've prepared an NMU for python-neovim (versioned as 0.3.0-1.1) and > uploaded it to DELAYED/15. Please feel free to tell me if I should > cancel it. I've uploaded the new upstream version (0.4.0) which contains these fixes. It's going through NEW though, since I also followed upstream's rename (now src:python-pynvim, python3-pynvim). Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#945185: O: pdf2djvu -- PDF to DjVu converter
Package: wnpp Followup-For: Bug #945185 Hi Daniel, I'd like to maintain pdf2djvu as there is a new upstream version that needs to be updated. If you agree, I will start working on this. Thanks, Woodrow -- Woodrow Shen (Hsieh-Tseng Shen) 4FA0 D159 803F F8B6 34E9 5A38 3970 FE24 7CB6 9685 woodrow.s...@gmail.com signature.asc Description: PGP signature
Bug#947452: RFS: kworkflow/20191112-1 [ITP] -- Inglorious kernel developer workflow scripts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "kworkflow" * Package name: kworkflow Version : 20191112-1 Upstream Author : Rodrigo Siqueira * URL : https://github.com/kworkflow/kworkflow * License : GPL-2+ * Vcs : https://github.com/kworkflow/kworkflow Section : misc It builds those binary packages: kworkflow - Inglorious kernel developer workflow scripts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kworkflow Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kworkflow/kworkflow_20191112-1.dsc Changes since the last upload: * Initial release. Closes: #946781 Regards, -- Rodrigo Carvalho
Bug#943585: ... extreme flickering and ...
Package: kwin-x11 Version: xorg 1:7.7+19 Severity: grave; in this condition, the workstation is unusable. Since updating Debian 10 around 2019-11-01, windows flicker, disappear and reappear with no obvious pattern. A short video at http://easthope.ca/X11antics.mp4 illustrates the behaviour. Also note the white margin on left and right sides. The xrandr settings which worked for several years fail now. In case anyone is interested, the following is from reportbug. Sorry for the long message. This is what reportbug produces. Possible similarities to these bugs are apparent. 656893 Video corruption, toolbar unreadable. 849224 Radeon mentioned. 738106 Flashing display/windows. At present I have no work-around and don't understand X well enought to formulate a theory about the failure. * What led up to the situation? Attempted routine use of Debian 10 workstation. * What exactly did you do (or not do) that was effective (orineffective)? Booted up a Debian 10 woerkstation. Lightdm started an X session authomatically. * What was the outcome of this action? Windows flashing and disappearing and reappearing erratically. The workstation is not useable in any ordinary way. * What outcome did you expect instead? Expected a working workstation. =8~) -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Apr 13 2011 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Mar 5 2019 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV360 [Radeon 9600/X1050 Series] [1002:4152] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) Xorg X server log files on system: -- -rw-r--r-- 1 root root 47132 Apr 2 2016 /var/log/Xorg.1.log -rw-r--r-- 1 root root 71685 Dec 26 14:41 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [89.174] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [89.174] Build Operating System: Linux 4.9.0-8-amd64 i686 Debian [89.174] Current Operating System: Linux dalton 4.19.0-6-686-pae #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) i686 [89.174] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-686-pae root=UUID=ae5f8bf4-b2a2-4b10-8da2-922d9f4e6e91 ro reboot=bios quiet [89.174] Build Date: 05 March 2019 08:11:12PM [89.174] xorg-server 2:1.20.4-1 (https://www.debian.org/support) [89.174] Current version of pixman: 0.36.0 [89.174]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [89.174] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [89.175] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 26 12:49:28 2019 [89.379] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [89.653] (==) No Layout section. Using the first Screen section. [89.653] (==) No screen section available. Using defaults. [89.653] (**) |-->Screen "Default Screen Section" (0) [89.653] (**) | |-->Monitor "" [89.669] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [89.669] (==) Automatically adding devices [89.669] (==) Automatically enabling devices [89.669] (==) Automatically adding GPU devices [89.669] (==) Max clients allowed: 256, resource mask: 0x1f [89.744] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [89.744]Entry deleted from font path. [89.911] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [89.911] (==) ModulePath set to "/usr/lib/xorg/modules" [89.911] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [89.911] (II) Loader magic: 0x6dd740 [89.911] (II) Module ABI versions: [89.911]X.Org ANSI C Emulation: 0.4 [89.911]X.Org Video Driver: 24.0 [89.911]X.Org XInput driver : 24.1 [
Bug#606825: mingw-w64 triplets/ostable
Greetings!
I recently became interested in cross-compiling software from Debian to
Windows. To my delight, I found the gcc-mingw-w64 & mingw-w64-tools
packages already in Debian (thanks Stephen!). However, I see that they
are using a workaround of a /usr/${triplet}/ path, rather than multi-arch.
Then found and read through this bug which hasn't seen an update in 5+
years :( Meanwhile, the Windows world has changed quite a bit in that
time, with Windows 10 being released in 2015, and Windows 7 due to go
EOL on 2020-01-14.
So, how can I best help the effort to get a proper multi-arch
infrastructure in Debian appropriate from cross-building using mingw-w64?
On 9/15/2014 11:46 AM, Guillem Jover wrote:
Hi!
On Tue, 2014-09-09 at 23:28:10 +0200, Stephen Kitt wrote:
On Sat, 30 Aug 2014 15:51:12 +0200, Guillem Jover wrote:
But I just noticed that a proper triplet was accepted in the config.git
repo around 2012 (commit f16804b79ee5a23a9994a1cdc760cd9ba813148a), this
is what config.sub has to say:
$ /usr/share/misc/config.sub mingw64
x86_64-pc-mingw64
$ /usr/share/misc/config.sub x86_64-mingw64
x86_64-pc-mingw64
$ /usr/share/misc/config.sub i686-mingw64
i686-pc-mingw64
So, just one thought, if you are going to end up having to do the work
that would be required to add support for what amounts to the equivalent
of a new triplet, you could as well use a proper triplet, like the one
above?
That triplet was actually added by the MinGW project, not the MinGW-w64
project, and is intended for their putative 64-bit support, whenever that
appears;
Oh wow, even more confusion to the already confusing current situation.
I assume we cannot expect the mingw-w64 and the mingw64 ports to be ABI
compatible? :(
I'll take it up with MinGW-w64 upstream though and see what they make of it.
Thanks, that might help.
Did this conversation happen? Was there any result?
In the end it seems to me that as long as the triplet is officially
supported by config.sub/guess the rest of software should just follow
suit, which as mentioned before is what needs to be done for each and
every new architecture anyway. What might be more time consuming is
hunting down and updating the rest of the affected packages in Debian,
but given that this has been thought to be a partial architecture from
the beginning it should not amount to so many packages (in contrast to
a full fledged architecture, that is).
I think what will be time-consuming is getting the various required patches
into the various upstream projects; there are very few affected packages in
Debian. Unless you mean we should just go our own way, regardless of what
upstream thinks, and use the mingw64 which is already in config.sub and patch
whatever breaks?
Well, not really if that would mean making the situation even worse by
conflating what might end up being upstream projects tripping over
each other's triplets. (Sorry, this was not clear from the aforementioned
commit.)
I'd rather do the work required to get something supported properly in Debian
and by upstream...
Sure.
Thanks,
Guillem
Thanks,
--Joe
Bug#918358: libsane:amd64: Missing permissions for scanner group on usb device
On my Buster machine I can completely reproduce that. However, things are more
complicated. For any somehow newer Epson scanner one needs to install the
vendor drivers from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX
, e.g., like it i the case for my Perfection V37.
While installing the package iscan-data-xx.deb (among others of them),
/lib/udev/60-iscan.rules was generated which is basically a copy of the
60-libsane.rules file of the machine, enriched with some own rules. Once I
installed iscan-data there was the old operating version of 60-libsance.rules
and thus the generated 60-iscan.rules contains the rule to set the ACL right on
the device file.
Thus, until now installing a new version iscan 2.30.4, I noticed nothing,
although I have had updated libsane continuously. But now the dance started.
During installation of iscan-data the (contained and quite naive) post-install
script /usr/lib/iscan-data/make-policy-file tried to generate a new version of
60-iscan.rules but silently failed as the structure of the parsed
60-libsane.conf changed. It copied something, but could not manage to include
alle rules, like the ones about vendor or product ids. And of course no
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
as this was not contained any more.
Of course, I know that it is not Debian's fault if a proprietary script of
Epson fails, however, I think that many people will fall over this and have
then to find and fix TWO interacting failures. As a workaround I now list a
manually created version of 60-iscan.conf to put into /etc/udev/rules.6 which
overrules the not operable version under /lib/...:
ACTION!="add", GOTO="iscan_rules_end"
ENV{DEVTYPE}=="usb_device", GOTO="iscan_create_usb_dev"
SUBSYSTEMS=="scsi", GOTO="iscan_scsi_rules_begin"
SUBSYSTEM=="usb_device", GOTO="iscan_usb_rules_begin"
SUBSYSTEM!="usb_device", GOTO="iscan_usb_rules_end"
# Kernel >= 2.6.22 jumps here
LABEL="iscan_create_usb_dev"
# For Linux >= 2.6.22 without CONFIG_USB_DEVICE_CLASS=y
# If the following rule does not exist on your system yet, uncomment it
# ENV{DEVTYPE}=="usb_device", MODE="0664", OWNER="root", GROUP="root"
# Kernel < 2.6.22 jumps here
LABEL="iscan_usb_rules_begin"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0101", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0102", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0103", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0104", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0105", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0106", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0107", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0108", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0109", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010a", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010b", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010c", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010d", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010e", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="010f", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0110", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0112", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0114", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0116", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0118", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0119", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011a", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011b", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011c", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011d", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011e", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011f", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0120", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0121", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0122", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0126", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0128", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0129", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="012a", ENV{libsane_matched}="yes"
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="012b", ENV{libsane_matched}="yes"
Bug#945524: RFP: container-diff -- Diff Docker containers
On Tue, 26 Nov 2019 19:06:22 +0530 Utkarsh Gupta wrote: Hi Utkarsh, > I had started working on it some days ago. And it needs a couple of > packages to be in Debian first, namely: > github.com/google/go-containerregistry > code.cloudfoundry.org/bytefmt > > That said, I'm working on it; shall take a couple of days but I hope to > get there eventually :) > > > Best, > Utkarsh > I recently merged this bug with 930385 and reached out to to the old owner as they have created the source on salsa.d.o but seemed to have stopped there. Please let me know if I can be of assistance in getting container-diff packaged up :) Regards, James
Bug#947451: libhash-moreutils-perl: can't upgrade
Package: libhash-moreutils-perl Version: 0.06-1 Severity: important apt upgrade gives: Preconfiguring packages ... dpkg: unrecoverable fatal error, aborting: files list file for package 'libhash-moreutils-perl' is missing final newline -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libhash-moreutils-perl depends on: ii perl 5.30.0-9 libhash-moreutils-perl recommends no packages. libhash-moreutils-perl suggests no packages. -- debconf-show failed
Bug#946945: Maybe ruby-unidecode is not necessary at all
Hi, after I've read Matijs' comment I checked if we can use some more recent (and maybe already packaged) unidecoder gem. It seems to me that jekyll-import (again) does not use the gem at all. I cannot find any reference to decode() or the Unidecoder module. Maybe we don't need it at all? Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#947450: geoip-database-contrib: Can't remove or update package
Package: geoip-database-contrib Version: 1.19 Severity: important apt-remove geo-database-contrib gives: Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: geoip-database-contrib 0 upgraded, 0 newly installed, 1 to remove and 118 not upgraded. 1 not fully installed or removed. After this operation, 82.9 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 165828 files and directories currently installed.) Removing geoip-database-contrib (1.19) ... dpkg: error processing package geoip-database-contrib (--remove): installed geoip-database-contrib package post-removal script subprocess was killed by signal (Killed) dpkg: too many errors, stopping Errors were encountered while processing: geoip-database-contrib Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geoip-database-contrib depends on: ii debconf [debconf-2.0] 1.5.73 ii ucf3.0038+nmu1 ii wget 1.20.3-1+b2 geoip-database-contrib recommends no packages. Versions of packages geoip-database-contrib suggests: ii cron [cron-daemon] 3.0pl1-135 -- debconf information: geoip-database-contrib/install-cronjob: true
Bug#947449: installation-report: No networking on Olimex Lime2 (Allwinner A20)
Package: installation-reports Version: 2.71 Severity: important Dear Maintainer, I tried installing debian 10.2 on an Olimex Lime 2 device (Alwinner A20 armhf). Although the ethernet interface was detected, the networking did not work at all – the DHCP network setup failed, so I tried to connect it to a PC and look at the ethernet communication with wireshark, and it seems that no ethernet packets ever leave the device. The same problem persists after installation and boot – the eth0 interface shows up, ethernet connect/disconnect events show up in dmesg, but the networking does not work in reality. I have tried the install also with another A20 device (Lamobo R1) and I had exactly the same problem (none of the 5 detected interfaces worked). Same issue also with the daily builds, so I guess this will be a more general problem related to A20. The networking works fine with Armbian (I tried the image from https://dl.armbian.com/lime2/archive/Armbian_19.11.3_Lime2_buster_current_5.3.9.7z ), but I would prefer vanilla debian. Best regards, Marek Nečada -- Package-specific info: Boot method: Micro SD card Image version: Concatenated image http://ftp.nl.debian.org/debian/dists/buster/main/installer-armhf/current/images/hd-media/SD-card-images/firmware.A20-OLinuXino-Lime2.img.gz and http://ftp.nl.debian.org/debian/dists/buster/main/installer-armhf/current/images/hd-media/SD-card-images/partition.img.gz together with https://cdimage.debian.org/debian-cd/current/armhf/bt-cd/debian-10.2.0-armhf-xfce-CD-1.iso.torrent (ISO image on USB mass storage partition) Date: 26.12.2019 Machine: Olimex Olinuxino A20 (T2-OLinuXino-LIME2-e8Gs16M-IND) Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udev devtmpfs487552 0487552 0% /dev tmpfs tmpfs 101360 1488 99872 2% /run /dev/mmcblk0p2 ext4 14027072 628016 12666796 5% / tmpfs tmpfs 506792 0506792 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 506792 0506792 0% /sys/fs/cgroup /dev/mmcblk0p1 ext2240972 29881198650 14% /boot tmpfs tmpfs 101356 0101356 0% /run/user/0 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Ethernet interface detected, but network configuration failed, it seems that no ethernet packets (incl. DHCP discovery) ever leave the device. The problem persists after boot. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u2" X_INSTALLATION_MEDIUM=hd-media == Installer hardware-summary: == uname -a: Linux lime2 4.19.0-6-armmp #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) armv7l GNU/Linux usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 4.19.0-6-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 4.19.0-6-armmp ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 01: MUSB HDRC host driver [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 4.19.0-6-armmp musb-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 04 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 4.19.0-6-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 04 Device 02: USB3.0-CRW [0bda:0316] usb-list:Level 01 Parent 01 Port 00 Class 00(>ifc ) Subclass 00 Protocol 00
Bug#897660: closed by "Gudjon I. Gudjonsson" (reply to gud...@gudjon.org) (qscintilla2: Please update symbols for riscv64)
Em qui., 26 de dez. de 2019 às 21:57, Debian Bug Tracking System escreveu: > -- Forwarded message -- > From: "Gudjon I. Gudjonsson" > To: 897660-d...@bugs.debian.org > Cc: > Bcc: > Date: Thu, 26 Dec 2019 21:30:06 +0100 > Subject: qscintilla2: Please update symbols for riscv64 > Source: qscintilla2 > Version: 2.11.2+dfsg-5 > > Hi Manuel > > Finally qscintilla2 is built for riscv64 so I'm closing your bug. > I hope your bugs will be fixed faster next time. Thanks a lot! -- Manuel A. Fernandez Montecelo
Bug#946422: silx: autopkgtest regression: pocl error
On 19/12/2019 14.33, Graham Inggs wrote: > On Thu, 19 Dec 2019 at 15:17, Andreas Beckmann wrote: >> I'm suspecting openmpi (that gets loaded by the io import) somehow messes up >> some state, >> causing the lt_*() failures. > > I wonder if this is related to #946986 ? Not sure any more. I "fixed" this in pocl by cherry-picking a few commits from 1.4 that get rid of ltdl and switch to plain libdl. The underlying issues seems to be in LTDL: if OpenMPI4 is loaded, the lt_dlopen() result is inconsistent: * ld_dlopen() returns a non-NULL lt_dlhandle (SUCCESS) * ld_dlerror() returns a non-NULL error string (FAILURE) So did the lt_dlopen() call succeed? silx will now fail with FAIL: test_medfilt (silx.opencl.test.test_medfilt.TestMedianFilter) -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/silx/opencl/test/test_medfilt.py", line 115, in test_medfilt self.assertEqual(r.error, 0, 'Results are correct') AssertionError: 3.4028235e+38 != 0 : Results are correct Andreas
Bug#947148: libltdl7: lt_dlopen() returns handle but lt_dlerror() returns non-NULL with OpenMPI4
Followup-For: Bug #947148
Control: reassign -1 libltdl7 2.4.6-11
Control: retitle -1 libltdl7: lt_dlopen() returns handle but lt_dlerror()
returns non-NULL with OpenMPI4
Hi,
the bug does not manifest with plain dlopen() (see test_dlopen.c), so
this seems to be rather a ltdl problem:
If OpenMPI4 is loaded, attempting to lt_dlopen() some kernel generated
by pocl yields an inconsistent result:
* the returned lt_dlhandle is *not NULL*
* the error string returned by subsequent lt_dlerror() is *not NULL*
Andreas
// mpicc -o test_dlopen test_dlopen.c -ldl
#include
#include
#include
int main(int argc, char **argv)
{
MPI_Init(, );
void * handle = dlopen ("./foo.so", RTLD_NOW | RTLD_LOCAL);
const char * dl_error = dlerror ();
printf("%p %s\n", handle, dl_error ? dl_error : "(null)");
}
Bug#897137: live-build: man -k and apropos don't work in live system
> While this fixes this feature, it bloats the image for a feature that is > seldom used. Seldom used? I think of apropos and man as the most fundamental commands in the Unix ecosystem. They are the first thing I mention, when people ask me about learning (or mastering) the system. Bloat? The last live image I built occupies ~2215 MiB. In it, "tar czf - -C /var/cache/man . | wc -c" prints 421793, less than one fiftieth of one percent of the image size. In a smaller live image with fewer packages, the cost would be even less than 0.4 MiB.
Bug#947448: pyfeed: missing Build-Depends: dh-python
Source: pyfeed Version: 1.0~prerelease-2 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, pyfeed/experimental FTBFS with fakeroot debian/rules clean dh clean --with=python2,python3 dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 13) line 1. BEGIN failed--compilation aborted at (eval 13) line 1. make: *** [debian/rules:35: clean] Error 255 Andreas
Bug#947447: ITP: python3-socketio -- python3 implementation of the Socket.IO realtime client and server
Package: wnpp Severity: wishlist Owner: "Paulo Henrique de Lima Santana (phls)" * Package name: python3-socketio Version : 4.4.0 Upstream Author : Miguel Grinberg * URL : https://github.com/miguelgrinberg/python-socketio * License : MIT/X Programming Lang: Python Description : python3 implementation of the Socket.IO realtime client and server Socket.IO is a transport protocol that enables real-time bidirectional event-based communication between clients (typically, though not always, web browsers) and a server. The official implementations of the client and server components are written in JavaScript. This package provides Python implementations of both, each with standard and asyncio variants. . Client Features: . Can connect to other Socket.IO compliant servers besides the one in this package. Compatible with Python 3.5+. Two versions of the client, one for standard Python and another for asyncio. Uses an event-based architecture implemented with decorators that hides the details of the protocol. Implements HTTP long-polling and WebSocket transports. Automatically reconnects to the server if the connection is dropped. . Server Features: . Can connect to servers running other compliant Socket.IO clients besides the one in this package. Compatible with Python 3.5+. Two versions of the server, one for standard Python and another for asyncio. Supports large number of clients even on modest hardware due to being asynchronous. Can be hosted on any WSGI and ASGI web servers includind Gunicorn, Uvicorn, eventlet and gevent. Can be integrated with WSGI applications written in frameworks such as Flask, Django, etc. Can be integrated with aiohttp, sanic and tornado asyncio applications. Broadcasting of messages to all connected clients, or to subsets of them assigned to rooms. Optional support for multiple servers, connected through a messaging queue such as Redis or RabbitMQ. Send messages to clients from external processes, such as Celery workers or auxiliary scripts. Event-based architecture implemented with decorators that hides the details of the protocol. Support for HTTP long-polling and WebSocket transports. Support for XHR2 and XHR browsers. Support for text and binary messages. Support for gzip and deflate HTTP compression. Configurable CORS responses, to avoid cross-origin problems with browsers.
Bug#946931: [Pkg-kde-extras] Bug#946931: Bug#946931: quassel-core: apparmor denials
Any word on how this worked? Scott K On December 18, 2019 3:00:58 AM UTC, Seth Arnold wrote: >On Wed, Dec 18, 2019 at 02:42:59AM +, Scott Kitterman wrote: >> Can you ask them to try this change: >> >> >https://salsa.debian.org/qt-kde-team/extras/quassel/commit/de4b3bc5fefa3e2928745f24acb18ca4b75599f6 > >Hi Scott, thanks, that was quick :) negative nine days! :) > >I've asked my friend to give it a try. > >Thanks
Bug#947446: libreoffice: ure split lacks proper versioned Breaks+Replaces
Source: libreoffice Version: 1:6.4.0~rc1-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi Rene, the ure package was split recently but this lacks proper versioned Breaks+Replaces in the new packages. This allows for unwanted partial upgrades mixing a pre-split ure package with post-split e.g. libjuh-java which will leave a crippled ure package installed (but apt/dpkg think everything is fine) if libjuh-java gets removed again. Replaces should always be used with a matching Breaks. (Taking away a file from a replaced package "Breaks" that version. Ownership has changed, but the replaced package does not know about it.) The Breaks+Replaces should be versioned unless the replaced package does no longer exist. (The package version that no longer ships the moved file does not need to get replaced) There were some more package splits needeing proper B+R, too. These packages seem to be affected (but I may have missed some), versions according to changelog entries where I found them: missing Breaks+Replaces: ure (<< 1:6.4.0~beta1-1) * libjuh-java * libjurt-java * libridl-java * libunoloader-java missing Breaks+Replaces: libreoffice-java-common (<< 1:6.4.0~beta1-2) * libreoffice-smoketest-data missing Breaks+Replaces: libreoffice-java-common (<< ???) * libunoil-java missing Breaks+Replaces: libreoffice-officebean (<< ???) * libofficebean-java Cheers, Andreas
Bug#947420: mirror submission for mirrors.layerbridge.com
Duplicate of #947418. -- ciao, Marco signature.asc Description: PGP signature
Bug#947419: mirror submission for mirrors.layerbridge.com
Duplicate of #947418. -- ciao, Marco signature.asc Description: PGP signature
Bug#943718: reportbug-gtk is reporting that up-to-date software is out-of-date
Hello Jason, I think you are mistaken in the way version numbers are compared in Debian. Version 7.5.3 is really considered newer than 7.5.3~deb10u1 (beware, it is a tilde, not a dash): # ge = "greater or equal" $ dpkg --compare-versions 7.5.3 ge "7.5.3~deb10u1"; echo $? 0 # means "true" Indeed, according to the Debian Policy [1]: The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: ‘~~’, ‘~~a’, ‘~’, the empty part, ‘a’. Therefore I guess this bugreport can be closed as invalid, but I prefer to let others decide. [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#version Thanks! Best regards -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#947445: ITP: libsharp -- libsharp is a fast spherical harmonic transform library.
Package: wnpp Severity: wishlist Owner: Leo Singer * Package name: libsharp Version : 1.0.0 Upstream Author : Martin Reinecke * URL : https://healpix.sourceforge.io * License : GPL Programming Lang: C++ Description : fast spherical harmonic transform library libsharp is a fast spherical harmonic transform library in C++. It used to be a part of healpix-cxx, but in the latest upstream release of healpix-cxx, has been moved to a separate package.
Bug#947079: Trial for v1. 0
I've done a trial packaging of v1.0 and it seems to work okay for me. See https://salsa.debian.org/bap/lieer.git
Bug#919170: [Piuparts-devel] Bug#919170: Bug#919170: Please update dependency to python3-debianbts
On 26.12.2019 17.11, Holger Levsen wrote: > many thanks, merged and deployed, now this is left: > File > "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/__init__.py", > line 58, in readline > empty = not self._refill() > File > "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/__init__.py", > line 49, in _refill > chunk = chunk.decode() > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 14159: > unexpected end of data This did not happen in my test setup, but I have a theory of what is causing this. Could you check if https://salsa.debian.org/debian/piuparts/merge_requests/18 fixes it?
Bug#947444: flatzinc: ships a copy of minizinc: /usr/share/minizinc/gecode/*
Package: flatzinc Version: 6.2.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Preparing to unpack .../flatzinc_6.2.0-1_amd64.deb ... Unpacking flatzinc (6.2.0-1) over (6.1.0-2+b2) ... dpkg: error processing archive /var/cache/apt/archives/flatzinc_6.2.0-1_amd64.deb (--unpack): trying to overwrite '/usr/share/minizinc/gecode/all_different_int.mzn', which is also in package minizinc 2.1.7+dfsg1-1+b1 Errors were encountered while processing: /var/cache/apt/archives/flatzinc_6.2.0-1_amd64.deb cheers, Andreas minizinc=2.1.7+dfsg1-1+b1_flatzinc=6.2.0-1.gz Description: application/gzip
Bug#947443: nvidia-texture-tools: FTBFS: undefined reference to symbol '_ZN2nv3Fit37computePrincipalComponent_EigenSolverEiPKNS_7Vector4E'
Source: nvidia-texture-tools Version: 2.1.0-git20160229+dfsg-2~exp1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, nvidia-texture-tools/experimental FTBFS in a current sid/experimental environment: https://buildd.debian.org/status/package.php?p=nvidia-texture-tools=experimental [ 90%] Linking CXX executable imperativeapi cd /<>/obj-x86_64-linux-gnu/src/nvtt/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/imperativeapi.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fopenmp -O3 -DNDEBUG -Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/imperativeapi.dir/imperativeapi.cpp.o -o imperativeapi -Wl,-rpath,/<>/obj-x86_64-linux-gnu/src/nvtt:/<>/obj-x86_64-linux-gnu/src/nvimage:/<>/obj-x86_64-linux-gnu/src/nvmath:/<>/obj-x86_64-linux-gnu/src/nvcore ../libnvtt.so.2.1.0 ../../nvimage/libnvimage.so.2.1.0 ../../nvmath/libnvmath.so.2.1.0 ../../../extern/poshlib/libposh.a ../../bc6h/libbc6h.a ../../bc7/libbc7.a ../../nvthread/libnvthread.a ../../nvcore/libnvcore.so.2.1.0 -ldl ../squish/libsquish.a /usr/bin/ld: ../../bc7/libbc7.a(avpcl_mode6.cpp.o): undefined reference to symbol '_ZN2nv3Fit37computePrincipalComponent_EigenSolverEiPKNS_7Vector4E' /usr/bin/ld: ../../nvmath/libnvmath.so.2.1.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[3]: *** [src/nvtt/tests/CMakeFiles/imperativeapi.dir/build.make:96: src/nvtt/tests/imperativeapi] Error 1 This could be related to GCC 9 being the default compiler nowadays. Cheers, Andreas
Bug#947442: buster-pu: package pango1.0/1.42.4-8~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster d-i
User: release.debian@packages.debian.org
Usertags: pu
We've been asked to fix a crash bug (#898960) in buster. Would you
be willing to consider a direct backport of 1.42.4-8 when it has had
some more time in unstable? In addition to a simple crash fix, it
has some improvements to the autopkgtest (which do not affect binary
packages). Diff below.
Or I could drop the autopkgtest changes and do a 1.42.4-7~deb10u2 or
something with just the crash fix, if preferred.
Either way this will need a d-i ack - the graphical installer uses Pango,
via GTK 2.
Thanks,
smcv
diff --git a/debian/changelog b/debian/changelog
index b4c3bf86..ee749e91 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,27 @@
+pango1.0 (1.42.4-8~deb10u1) UNRELEASED; urgency=medium
+
+ * Merge changes from 1.42.4-8 into buster
+- d/gbp.conf, d/control: Set packaging branch to debian/buster
+
+ -- Simon McVittie Thu, 26 Dec 2019 21:30:51 +
+
+pango1.0 (1.42.4-8) unstable; urgency=medium
+
+ * Team upload
+ * d/p/Fix-crash-in-pango_fc_font_key_get_variations-when-key-is.patch:
+Backport crash fix from 1.44.x (Closes: #898960)
+ * d/tests/build: Use correct compiler for proposed autopkgtest
+cross-architecture testing support, based on a patch for clutter-1.0
+by Steve Langasek
+ * d/tests/build: Fix shellcheck warnings
+ * d/tests/build: Remove trailing whitespace
+ * d/tests/build: Fail if using an undefined variable ("unofficial strict
+mode")
+ * d/tests/build: Mark as superficial
+ * d/gbp.conf, d/control: Use debian/unstable, upstream/1.42.x branches
+
+ -- Simon McVittie Thu, 26 Dec 2019 20:19:17 +
+
pango1.0 (1.42.4-7~deb10u1) buster-security; urgency=medium
* Team upload
diff --git a/debian/control b/debian/control
index b97760cc..3d35aa25 100644
--- a/debian/control
+++ b/debian/control
@@ -31,7 +31,7 @@ Build-Depends: debhelper (>= 11),
Build-Depends-Indep: libglib2.0-doc
Standards-Version: 4.3.0
Vcs-Browser: https://salsa.debian.org/gnome-team/pango
-Vcs-Git: https://salsa.debian.org/gnome-team/pango.git
+Vcs-Git: https://salsa.debian.org/gnome-team/pango.git -b debian/buster
Homepage: http://www.pango.org/
Package: libpango1.0-0
diff --git a/debian/control.in b/debian/control.in
index 2fbc8fde..b4b23392 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -27,7 +27,7 @@ Build-Depends: debhelper (>= 11),
Build-Depends-Indep: libglib2.0-doc
Standards-Version: 4.3.0
Vcs-Browser: https://salsa.debian.org/gnome-team/pango
-Vcs-Git: https://salsa.debian.org/gnome-team/pango.git
+Vcs-Git: https://salsa.debian.org/gnome-team/pango.git -b debian/buster
Homepage: http://www.pango.org/
Package: libpango1.0-0
diff --git
a/debian/patches/Fix-crash-in-pango_fc_font_key_get_variations-when-key-is.patch
b/debian/patches/Fix-crash-in-pango_fc_font_key_get_variations-when-key-is.patch
new file mode 100644
index ..70aaf519
--- /dev/null
+++
b/debian/patches/Fix-crash-in-pango_fc_font_key_get_variations-when-key-is.patch
@@ -0,0 +1,36 @@
+From: Carsten Pfeiffer
+Date: Fri, 10 Aug 2018 16:06:20 +0200
+Subject: Fix crash in pango_fc_font_key_get_variations() when key is null
+
+Bug: https://gitlab.gnome.org/GNOME/pango/merge_requests/12
+Bug-Debian: https://bugs.debian.org/898960
+Applied-upstream: 1.43.0, commit:ad92e199f221499c19f22dce7a16e7d770ad3ae7
+---
+ pango/pangofc-shape.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/pango/pangofc-shape.c b/pango/pangofc-shape.c
+index a59ca67..53269d7 100644
+--- a/pango/pangofc-shape.c
b/pango/pangofc-shape.c
+@@ -380,8 +380,10 @@ _pango_fc_shape (PangoFont *font,
+ fc_font->is_hinted ? ft_face->size->metrics.x_ppem : 0,
+ fc_font->is_hinted ? ft_face->size->metrics.y_ppem : 0);
+
+- variations = pango_fc_font_key_get_variations (key);
+- if (variations)
++ if (key)
++ {
++variations = pango_fc_font_key_get_variations (key);
++if (variations)
+ {
+ guint n_variations;
+ hb_variation_t *hb_variations;
+@@ -391,6 +393,7 @@ _pango_fc_shape (PangoFont *font,
+
+ g_free (hb_variations);
+ }
++ }
+
+ hb_buffer = acquire_buffer (_buffer);
+
diff --git a/debian/patches/series b/debian/patches/series
index ef8fe1a0..42457c74 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ Update-Grapheme-Boundary-to-Unicode-11.patch
Update-Word-Boundary-to-Unicode-11.patch
Update-Line-Break-to-Unicode-11.patch
bidi-Be-safer-against-bad-input.patch
+Fix-crash-in-pango_fc_font_key_get_variations-when-key-is.patch
diff --git a/debian/tests/build b/debian/tests/build
old mode 100644
new mode 100755
index a5c92b5f..957286f3
--- a/debian/tests/build
+++ b/debian/tests/build
@@ -4,10 +4,21 @@
# Author: Rafał Cieślak
set -e
+set -u
WORKDIR=$(mktemp -d)
-trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE
Bug#947441: libignition-cmake2-dev: file conflicts with libignition-cmake-dev: /usr/share/ignition/ignition-cmake0/doxygen/*
Package: libignition-cmake2-dev Version: 2.1.1+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libignition-cmake2-dev_2.1.1+dfsg-2_amd64.deb ... Unpacking libignition-cmake2-dev:amd64 (2.1.1+dfsg-2) ... dpkg: error processing archive /var/cache/apt/archives/libignition-cmake2-dev_2.1.1+dfsg-2_amd64.deb (--unpack): trying to overwrite '/usr/share/ignition/ignition-cmake0/doxygen/doxygen.css', which is also in package libignition-cmake-dev:amd64 0.6.1-1+b1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libignition-cmake2-dev_2.1.1+dfsg-2_amd64.deb The following files are shipped by both packages: usr/share/ignition/ignition-cmake0/doxygen/doxygen.css usr/share/ignition/ignition-cmake0/doxygen/dynsections.js usr/share/ignition/ignition-cmake0/doxygen/google_material_icons.css usr/share/ignition/ignition-cmake0/doxygen/ignition_logo.svg usr/share/ignition/ignition-cmake0/doxygen/ignition_logo_white.svg usr/share/ignition/ignition-cmake0/doxygen/material.deep_orange-blue.min.css usr/share/ignition/ignition-cmake0/doxygen/material.js You either need to move them to a different location or add Breaks+Replaces. cheers, Andreas libignition-cmake-dev=0.6.1-1+b1_libignition-cmake2-dev=2.1.1+dfsg-2.log.gz Description: application/gzip
Bug#947440: yamllint: Remove 'Installing yamllint' section in the manpage
Package: yamllint Severity: minor Dear Maintainer, man yamllint contains the doc to install the program on a bunch of OS. As we are on Debian or Ubuntu, we don't need the doc for other OS. It should be removed. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947357: Bug #947357: votebar template fails at parsing some translated files
user www.debian@packages.debian.org usertags 947357 scripts retitle 947357 votebar template fails at parsing some translated files thanks I have noticed that the files not added in the Spanish index were the ones with the translation-check header in the first line. I have moved the translation-check header line below, so the first line is the pagetitle and the second line the status, and then the file is parsed correctly by the votebar template and thus, added to the index. So, I see 2 ways of solving the issue: * Fixing the Perl code in /english/template/debian/votebar.wml so it parses the title and status line wherever they are * Finding a list of the translated files not having the pagetitle and status lines as the first two lines in the file, and fixing them as I did with the Spanish ones, and adding a note to translators in future voting files so they move the translation-check header below (note that copypage.pl places this line at the top of the file). Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#947439: ycmd: Please update to clang-9
Package: ycmd Severity: important Dear Maintainer, Please upgrade to clang 9. ycmd depends on libclang1-7, it should be 9. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947438: RM: llvm-toolchain-7 -- ROM; Less versions of llvm, the better
Package: ftp.debian.org Severity: normal Hello, As we are starting the migration to 9, we should delete -7 now. % ssh mirror.ftp-master.debian.org "dak rm -Rn llvm-toolchain-7" Will remove the following packages from unstable: clang-7 | 1:7.0.1-9+b2 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x [...] python-lldb-7 | 1:7.0.1-9+b2 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el Maintainer: LLVM Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: aiscm: aiscm [amd64] bpftrace: bpftrace [amd64 arm64 ppc64el] flang: flang-7 [amd64 arm64 ppc64el] libflang0d-7 [amd64 arm64 ppc64el] gnat-gps: gnat-gps [amd64 arm64 mips64el ppc64el s390x] ycmd: ycmd # Broken Build-Depends: aiscm: clang-7 libomp-7-dev llvm-7 llvm-7-dev beignet: clang-7 libclang-7-dev llvm-7-dev bpftrace: clang-7 libclang-7-dev llvm-7-dev flang: libomp-7-dev llvm-7 llvm-7-dev llvm-7-tools I will report the bugs. Sylvestre
Bug#947437: flang: Please update to llvm-9
Package: flang Severity: important Dear Maintainer, Please upgrade to llvm 9. 7 isn't maintained and will be removed soon. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947435: beignet: Please update to clang-9
Package: beignet Severity: important Dear Maintainer, Please upgrade to clang 9. 7 isn't maintained and will be removed soon. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947436: bpftrace: Please update to clang-9
Package: bpftrace Severity: important Dear Maintainer, Please upgrade to clang 9. 7 isn't maintained and will be removed soon. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947434: aiscm: Please update to llvm-9
Package: aiscm Severity: important Dear Maintainer, Please upgrade to llvm 9. 7 isn't maintained and will be removed soon. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947433: waitress: CVE-2019-16789
Source: waitress Version: 1.3.1-4 Severity: grave Tags: security upstream Hi, The following vulnerability was published for waitress, filling a distinct bug for that as the already filled #947306 for two other CVEs as this one is only fixed in 1.4.1 upstream. CVE-2019-16789[0]: | In Waitress through version 1.4.0, if a proxy server is used in front | of waitress, an invalid request may be sent by an attacker that | bypasses the front-end and is parsed differently by waitress leading | to a potential for HTTP request smuggling. Specially crafted requests | containing special whitespace characters in the Transfer-Encoding | header would get parsed by Waitress as being a chunked request, but a | front-end server would use the Content-Length instead as the Transfer- | Encoding header is considered invalid due to containing invalid | characters. If a front-end server does HTTP pipelining to a backend | Waitress server this could lead to HTTP request splitting which may | lead to potential cache poisoning or unexpected information | disclosure. This issue is fixed in Waitress 1.4.1 through more strict | HTTP field validation. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-16789 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16789 [1] https://github.com/Pylons/waitress/commit/11d9e138125ad46e951027184b13242a3c1de017 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#947165: transition: llvm-defaults to 9
Le 26/12/2019 à 21:40, Paul Gevers a écrit : Control: tags -1 moreinfo Hi Sylvestre, On 22-12-2019 11:57, Sylvestre Ledru wrote: LLVM 9.0.1 has just been released. I am not planning to spend significant time on the -8 branch. It is therefor time to move to the version 9 Just to get it clear, this is only switching the default from 8 to 9, right? And rebuild packages to depend on -9. What happens if rebuilt packages don't migrate to testing? I'm seeing rust package in the picture Besides rustc, it should not have an impact on rust. and it seems to me that those need some coordination that I am currently not seeing in order to migrate. Side question, will you be taking care of *removing* some branches from unstable/testing as well? It seems to me that we are have a bit too many currently: llvm-toolchain-6.0, llvm-toolchain-7, llvm-toolchain-8 and llvm-toolchain-9 are the ones I know about. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916837 Good point for -7, I forgot to fill it :) Thanks S
Bug#947432: xfce4-terminal: System bell does not work [re-open bug 645422?]
Package: xfce4-terminal Version: 0.8.7.4-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, Neither the audible bell nor the visual bell work. In xterm, visual bell works but not audible bell. The bell is useful in tab completion to alert to more choices/options. Archived bug 645422 looks identical except the fix does not work. ralph@spike3:~$ grep -i bell .config/Terminal/terminalrc MiscBell=TRUE ralph@spike3:~$ grep -i bell .config/xfce4/terminal/terminalrc MiscBell=TRUE MiscBellUrgent=TRUE ralph@spike3:~$ grep -i bell /home/ralph/.inputrc set bell-style true Terminal -> Preferences -> Advanced has checked both Audible Bell and Visual Bell. Did I miss some other setting? Thanks! - -- System Information: Debian Release: 10.2 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-terminal depends on: ii exo-utils 0.12.4-1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libutempter01.1.6-3 ii libvte-2.91-0 0.54.2-2 ii libx11-62:1.6.7-1 ii libxfce4ui-2-0 4.12.1-3 ii libxfce4util7 4.12.1-3 Versions of packages xfce4-terminal recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 xfce4-terminal suggests no packages. -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEJQZ8vK6BnmDiW8fZyAJ5DhtfJxAFAl4FI2YUHHJhbHBoQHJh bHBoa2F0ei5jb20ACgkQyAJ5DhtfJxAj3A//e2CnHIq75oRVQTofhFy3vON9xYs3 sAcAQRaVoTxfyoQdJyHVRNNfBXzNltfhzrcQzz6qEqhIX/h1uytwipSZ5feLWKnC Acv/uBgPrionkyQ7WIIQl7EhF2rXfEc0ex3FKq9ahnLOQrsCl75RUXeFML+Mm0vl 7liLoqQuNt650mLaYBfn00q0zMSOuEjQ3PW/BTNFjVyatX9rvWlChuyU0/04AHRJ MXFid4acZbwoM5iU+85GT/tnb5v/cOLiVCxV4Potc7PF47pm87PG3AXkq1yZEmzu PAImY1OeoKPE+BljcihA5rlwdKlNru1dvEguhVtFyI/Wm1ksXwb+Ge0JprtQtjip f6e4QAasa+HmyJ5LKTBA4HnmMFcZBSo92JAt/htl43qLOuBucvbEcIUcWNF4zvmI +Az34Rtm8Xm2xFf/gOxztGGL+oC99TU8eupPQar6qywCdY9eMjvFCmL9CMbmbxm+ i09TW3YeBKqeD0b+eqRqpfnAz2JPR2sQ+giai5giYLLoHnHqSZEGjvKIjTteXK+/ R2N3DCvZsMLoINLJv6lXHxY0fDr70DxXLeo2GakJjWT2vAcPthQtMK+0cnn6Mx3P XdfutEpLPPz6URx9RwLcbTuNYvhvX9NuAnzlXieKmpO1pHO9oDlGqE4jf95BU1k8 IS5fJghWHdUZYj4= =DV+6 -END PGP SIGNATURE-
Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gobject-introspection/issues/323 On Wed, 20 Feb 2019 at 17:03:43 +0100, Helmut Grohne wrote: > On Sat, Feb 16, 2019 at 05:02:53PM +, Simon McVittie wrote: > > Multiarch-qualified directories under /usr/share don't seem like they make > > much sense: the whole point of the $libdir/$datadir duality is that if > > files need to be different on some architectures, then the files should > > be in $libdir, not in $datadir. > > This is not specific to Debian. It is an upstream problem. The files are > supposed to be architecture-independent, but factually are not. I've started a conversation upstream: see link above. libgirepository1.0-dev is not, practically, multiarch co-installable anyway (because it depends on the gobject-introspection toolset, which is architecture-dependent and I don't think it would be correct to make it Multi-Arch: foreign), so for now my inclination is to revert the addition of Multi-Arch: same to libgirepository1.0-dev. As far as I can see this would not break anything that is not already broken. > > My understanding is that GIR is intended to be a collection of > > machine-readable facts about the source code [...] However, those facts > > are partially derived from inspecting the binary > > Deriving from the binary practically happens by > loading it into some tool. I don't remember the details here, but this > where things break down: The purpose of these GIR files is software > development. Why would you install them for multiple architectures? > Only if you are cross compiling something. But then you load libraries > into some tool, you're faced with an Exec format error. This doesn't > work at all regardless of whether fix the M-A annotations. I think part of the purpose of the GIR XML and the binary typelibs is precisely that you can read it to get facts about the API (and, indirectly, ABI) of a library *without* having to dlopen and inspect the library and its source code yourself, for example to generate Vala language bindings for it. In principle, they ought to be useful when cross-compiling: you can read Foo-1.0.gir and the riscv64 version of Foo-1.0.typelib, and use them to generate code that will run on riscv64. As long as you don't execute that code immediately yourself, you don't actually need to be able to run riscv64 code. I agree that *gathering* that information requires the ability to dlopen the library that you're inspecting; and, yes, that breaks the ability to do "true" cross-compilation (by which I mean compiling for a host architecture whose code you cannot execute, not even with qemu-user-binfmt) of libraries that include their own GObject-Introspection information. > You may ask: How do other distributions solve this? Well, ptxdist and > yocto use qemu for gobject-introspection. I think having library development files coexist for multiple architectures is valuable even if you need to execute host-architecture code to consume them: only being able to cross-compile to architectures whose code you can execute is not as good as being able to do "true" cross-compilation, but it's also better than not being able to cross-compile at all. In particular, multiarch co-installation for amd64 + i386 on an amd64 system is a really useful thing to be able to do. smcv
Bug#947365: transition: libvigraimpex
Control: tags -1 confirmed Hi Andreas, On 25-12-2019 19:29, Andreas Metzler wrote: > libvigraimpex is marked for autoremoval because of the python2 removal. > This is fixed in experimental, the new version features a soname bump. > this should be a small scale transition. I have successfully [1] rebuilt > 3depict enblend-enfuse hugin luminance-hdr saga against -3 in > experimental. Normally we don't want python 2 removal package uploads and transitions mixed, but it seems that python-vigra doesn't have reverse dependencies. Please go ahead in unstable. Paul signature.asc Description: OpenPGP digital signature
Bug#947170: transition: botan
Control: tags -1 confirmed Hi László On 22-12-2019 13:42, László Böszörményi (GCS) wrote: > Small transition of botan, which is already in experimental. Two > packages are affected, namely biboumi and libqtshadowsocks. > The biboumi source builds fine with the new botan release. Please go ahead in unstable. Paul signature.asc Description: OpenPGP digital signature
Bug#947165: transition: llvm-defaults to 9
Control: tags -1 moreinfo Hi Sylvestre, On 22-12-2019 11:57, Sylvestre Ledru wrote: > LLVM 9.0.1 has just been released. I am not planning to spend significant > time on the -8 branch. > It is therefor time to move to the version 9 Just to get it clear, this is only switching the default from 8 to 9, right? What happens if rebuilt packages don't migrate to testing? I'm seeing rust package in the picture and it seems to me that those need some coordination that I am currently not seeing in order to migrate. Side question, will you be taking care of *removing* some branches from unstable/testing as well? It seems to me that we are have a bit too many currently: llvm-toolchain-6.0, llvm-toolchain-7, llvm-toolchain-8 and llvm-toolchain-9 are the ones I know about. Paul
Bug#947430: ITP: r-cran-itertools -- Iterator Tools
Package: wnpp Severity: wishlist Subject: ITP: r-cran-itertools -- Iterator Tools Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-cran-itertools Version : 0.1 Upstream Author : Steve Weston, Hadley Wickham * URL : https://cran.r-project.org/package=itertools * License : GPL-2+ Programming Lang: GNU R Description : Iterator Tools Various tools for creating iterators, many patterned after functions in the Python itertools module, and others patterned after functions in the 'snow' package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-itertools
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Source: xerces-c Version: 3.2.2+debian-1 Severity: important Tags: security upstream Forwarded: https://issues.apache.org/jira/browse/XERCESC-2188 Control: found -1 3.1.4+debian-2+deb9u1 Control: found -1 3.1.4+debian-1 Hi, The following vulnerability was published for xerces-c. There is no upstream fix and only suggested mitigations, at time of writing the bugreport. CVE-2018-1311[0]: | The Apache Xerces-C 3.0.0 to 3.2.2 XML parser contains a use-after- | free error triggered during the scanning of external DTDs. This flaw | has not been addressed in the maintained version of the library and | has no current mitigation other than to disable DTD processing. This | can be accomplished via the DOM using a standard parser feature, or | via SAX using the XERCES_DISABLE_DTD environment variable. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-1311 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1311 [1] https://issues.apache.org/jira/browse/XERCESC-2188 [2] https://xerces.apache.org/xerces-c/secadv/CVE-2018-1311.txt [3] https://marc.info/?l=xerces-c-users=157653840106914=2 Regards, Salvatore
Bug#709862: reportbug: GTK interface crashes on continue from package selection
Hello, Do you still have this issue? Otherwise, can we close it? Thanks! Best regards -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#947429: lintian: Can't use an undefined value as an ARRAY reference at /usr/share/lintian/checks/manpages.pm line 370
Package: lintian Version: 2.42.0 Severity: normal Dear Maintainer, Last version of lintian fails to check resource-agents package with runtime error: https://salsa.debian.org/ha-team/resource-agents/-/jobs/475012 Can't use an undefined value as an ARRAY reference at /usr/share/lintian/checks/manpages.pm line 370. internal error: cannot run manpages check on package binary:resource-agents/1:4.4.0-2/amd64 warning: skipping check of binary:resource-agents/1:4.4.0-2/amd64 I: resource-agents: capitalization-error-in-description apache Apache I: resource-agents: capitalization-error-in-description mysql MySQL I: ldirectord: conflicts-with-version libpils0 (<< 2.0.8-3) I: ldirectord: conflicts-with-version libstonith0 (<< 2.0.8-3) I: ldirectord: conflicts-with-version stonith (<< 2.0.8-3) I: resource-agents: conflicts-with-version cluster-agents (<= 1:1.0.4-1) I: resource-agents: conflicts-with-version resource-agents-dev (<< 1:3.9.6) I: resource-agents: conflicts-with-version rgmanager (<= 3.0.12-2+b1) I: ldirectord: debian-news-entry-uses-asterisk I: resource-agents: debian-news-entry-uses-asterisk I: ldirectord: extended-description-is-probably-too-short I: resource-agents: package-contains-documentation-outside-usr-share-doc usr/share/resource-agents/ocft/README I: resource-agents: package-contains-documentation-outside-usr-share-doc usr/share/resource-agents/ocft/README.zh_CN I: resource-agents: spelling-error-in-manpage usr/share/man/man7/ocf_heartbeat_exportfs.7.gz seperated separated I: resource-agents: unused-override binary-without-manpage usr/sbin/ocft I: resource-agents: unused-override binary-without-manpage usr/sbin/rhev-check.sh I: resource-agents: unused-override binary-without-manpage usr/sbin/sfex_stat P: ldirectord: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: resource-agents: copyright-refers-to-symlink-license usr/share/common-licenses/GPL N: 6 tags overridden (6 warnings) E: Lintian run failed (runtime error) -- Valentin
Bug#947428: tigervnc: CVE-2019-15691 CVE-2019-15692 CVE-2019-15693 CVE-2019-15694 CVE-2019-15695
Source: tigervnc Version: 1.9.0+dfsg-4 Severity: grave Tags: security upstream Control: found -1 1.9.0+dfsg-3 Hi, The following vulnerabilities were published for tigervnc. CVE-2019-15691[0]: | TigerVNC version prior to 1.10.1 is vulnerable to stack use-after- | return, which occurs due to incorrect usage of stack memory in | ZRLEDecoder. If decoding routine would throw an exception, ZRLEDecoder | may try to access stack variable, which has been already freed during | the process of stack unwinding. Exploitation of this vulnerability | could potentially result into remote code execution. This attack | appear to be exploitable via network connectivity. CVE-2019-15692[1]: | TigerVNC version prior to 1.10.1 is vulnerable to heap buffer | overflow. Vulnerability could be triggered from CopyRectDecoder due to | incorrect value checks. Exploitation of this vulnerability could | potentially result into remote code execution. This attack appear to | be exploitable via network connectivity. CVE-2019-15693[2]: | TigerVNC version prior to 1.10.1 is vulnerable to heap buffer | overflow, which occurs in TightDecoder::FilterGradient. Exploitation | of this vulnerability could potentially result into remote code | execution. This attack appear to be exploitable via network | connectivity. CVE-2019-15694[3]: | TigerVNC version prior to 1.10.1 is vulnerable to heap buffer | overflow, which could be triggered from DecodeManager::decodeRect. | Vulnerability occurs due to the signdness error in processing | MemOutStream. Exploitation of this vulnerability could potentially | result into remote code execution. This attack appear to be | exploitable via network connectivity. CVE-2019-15695[4]: | TigerVNC version prior to 1.10.1 is vulnerable to stack buffer | overflow, which could be triggered from CMsgReader::readSetCursor. | This vulnerability occurs due to insufficient sanitization of | PixelFormat. Since remote attacker can choose offset from start of the | buffer to start writing his values, exploitation of this vulnerability | could potentially result into remote code execution. This attack | appear to be exploitable via network connectivity. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-15691 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15691 [1] https://security-tracker.debian.org/tracker/CVE-2019-15692 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15692 [2] https://security-tracker.debian.org/tracker/CVE-2019-15693 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15693 [3] https://security-tracker.debian.org/tracker/CVE-2019-15694 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15694 [4] https://security-tracker.debian.org/tracker/CVE-2019-15695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15695 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947161: transition: libwebsockets
Control: tags -1 confirmed Hi László, On 22-12-2019 10:53, László Böszörményi (GCS) wrote: > Small transition with four affected packages. Namely ddnet, > forked-daapd, janus and mosquitto. All build fine with the new > libwebsocket release in experimental. Please go ahead. Paul signature.asc Description: OpenPGP digital signature
Bug#947427: RFS: ipmitool/1.8.18-9 -- utility for IPMI control with kernel driver or LAN interface (daemon)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ipmitool" Package name: ipmitool Version : 1.8.18-9 Upstream Author : Vernon Mauery URL : https://github.com/ipmitool/ipmitool License : BSD-3-clause Vcs : https://jff.email/cgit/ipmitool.git Section : utils It builds those binary packages: ipmitool - utility for IPMI control with kernel driver or LAN interface (daemon) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ipmitool Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.18-9.dsc or from git https://jff.email/cgit/ipmitool.git/?h=release%2Fdebian%2F1.8.18-9 Changes since the last upload: * debian/ipmitool.maintscript: - Fix syntax (Closes: #947384). * Remove System V init scripts: - Remove debian/ipmitool.ipmievd.init. - Remove debian/ipmitool.lintian-overrides. - Remove debian/ipmitool.postinst. - Rewrite debian/ipmitool.postrm. - Remove debian/ipmitool.prerm. - Remove override_dh_installinit from debian/rules. - Remove init-system-helpers (>> 1.50) from debian/control. - Add rm_conffile /etc/init.d/ipmievd 1.8.18-9~ ipmitool to debian/ipmitool.maintscript. The build with sbuild and pdebuild and the tests with Lintain and Piuparts are ok: +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 131952 Build-Time: 45 Distribution: sid Host Architecture: amd64 Install-Time: 44 Job: /data/entwicklung/linux/debian/ipmitool/ipmitool_1.8.18-9.dsc Lintian: info Machine Architecture: amd64 Package: ipmitool Package-Time: 102 Piuparts: pass Source-Version: 1.8.18-9 Space: 131952 Status: successful Version: 1.8.18-9 Finished at 2019-12-26T19:30:34Z Build needed 00:01:42, 131952k disk space CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#947426: python-pysam ftbfs with htslib 1.10.2
Source: python-pysam Version: 0.15.2+ds-2 Severity: serious Justification: ftbfs Tags: ftbfs sid bullseye Dear maintainer, Your package is part of the htslib 1.10.2 transition. I tried to binNMU your package but it fails to build from source. Please have a look. Paul https://buildd.debian.org/status/package.php?p=python-pysam Tail of log for python-pysam on amd64: 24840 | __pyx_t_12 = PyFloat_FromDouble(__pyx_v_qual); if (unlikely(!__pyx_t_12)) __PYX_ERR(0, 873, __pyx_L1_error) |^~~~ x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-amd64-3.7/pysam/libcvcf.o -L/<>/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -L/<>/.pybuild/cpython3_3.7_pysam/build/pysam -lz -lhts -lchtslib.cpython-37m-x86_64-linux-gnu -lcutils.cpython-37m-x86_64-linux-gnu -o /<>/.pybuild/cpython3_3.7_pysam/build/pysam/libcvcf.cpython-37m-x86_64-linux-gnu.so -Wl,-rpath,$ORIGIN debian/rules override_dh_auto_test make[1]: Entering directory '/<>' cd tests/pysam_data && /usr/bin/make all make[2]: Entering directory '/<>/tests/pysam_data' samtools faidx ex1.fa samtools import ex1.fa.fai ex1.sam.gz ex1.bam make[2]: *** [Makefile:56: ex1.bam] Segmentation fault make[2]: *** Deleting file 'ex1.bam' make[2]: Leaving directory '/<>/tests/pysam_data' make[1]: *** [debian/rules:51: pysam_data.all] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:24: build-arch] Error 2 signature.asc Description: OpenPGP digital signature
Bug#947425: incron crashes in IncronTabEntry::GetSafePath due to use-after-free bug
Package: incron
Version: 0.5.12-1
Severity: grave
Tags: security patch upstream
Hi,
incron crashes for me frequently. As incron runs as root, but is controllable
by users, this bug might be security-relevant, so I'm reporting it a severity
grave and tagging it security. Please downgrade if you can rule out this
concern.
Further investigation shows that the problem is caused by the creation of new
directories within watched paths: these trigger a reload of the inotify watch
target, rendering the old watch structure invalid. Only after the reload,
potential commands are executed. This may require to get path of the event, but
the corresponding pointer is invalid after the reload.
Attached is a patch that extracts the path before the reload, making this
problem disappear for me. Note that the patch assumes that LOOPER is not
defined, which seems to be the case for the Debian package.
Backtrace for reference:
bt full
#0 0x004ba484 in IncronTabEntry::GetSafePath (rPath=) at /usr/include/c++/8/bits/basic_string.h:1046
i = 0
stream =
len = 1919509615
#1 0x004c43f3 in UserTable::OnEvent (this=, rEvt=...) at
inotify-cxx.h:428
px = 40
pW = 0x1fbde40
pE = 0x1fbc920
events = "IN_CREATE,IN_ISDIR"
cmd = "/home/user/autoscripts/imageresize.sh "
cs = "/home/user/autoscripts/imageresize.sh $@/$# $# $%"
pos = 39
oldpos = 0
len =
pid =
#2 0x004c4767 in EventDispatcher::ProcessEvents (this=) at
usertable.cpp:110
pIn = 0x1fc7d24
it = {first = 1702521203, second = 0x1fc0072}
i = 2
pipe = false
evt = {m_uMask = 1073742080, m_uCookie = 0, m_name = "Neuer Ordner",
m_pWatch = 0x1fbde40}
#3 0x004b8650 in main (argc=, argv=) at
icd-main.cpp:458
res =
wm = 10184
in = {m_fd = 6, m_watches = std::map with 2 elements = {[1] =
0xbfc8ab40, [2] = 0xbfc8ab68}, m_paths = std::map with 2 elements = {
["/etc/incron.d"] = 0xbfc8ab40, ["/var/spool/incron"] =
0xbfc8ab68}, m_buf = '\000' ..., m_events = std::deque
with 0 elements}
stw = {m_path = "/etc/incron.d", m_uMask = 10184, m_wd = 1, m_pInotify
= 0xbfc8ab90, m_fEnabled = true}
utw = {m_path = "/var/spool/incron", m_uMask = 10184, m_wd = 2,
m_pInotify = 0xbfc8ab90, m_fEnabled = true}
ed = {m_iPipeFd = 4, m_iMgmtFd = 6, m_pIn = 0xbfc8ab90, m_pSys =
0xbfc8ab40, m_pUser = 0xbfc8ab68, m_maps = std::map with 1 element = {[8] =
0x1fc7d20},
m_size = 3, m_pPoll = 0x1fbe080}
cfg = "/etc/incron.conf"
lckdir = "/var/run"
lckfile = "incrond"
app = {m_path = "/var/run/incrond.pid", m_fLocked = true}
ret = 0
sysBase = "/etc/incron.d"
userBase = "/var/spool/incron"
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 4.19.0-6-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8),
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages incron depends on:
ii adduser 3.118
ii init-system-helpers 1.56+nmu1
ii libc62.28-10
ii libgcc1 1:8.3.0-6
ii libstdc++6 8.3.0-6
ii lsb-base 10.2019051400
incron recommends no packages.
incron suggests no packages.
-- Configuration Files:
/etc/incron.allow [Errno 13] Keine Berechtigung: '/etc/incron.allow'
/etc/incron.deny [Errno 13] Keine Berechtigung: '/etc/incron.deny'
-- no debconf information
diff --git a/usertable.cpp b/usertable.cpp
index 3f1ef4a..bdc7f29 100644
--- a/usertable.cpp
+++ b/usertable.cpp
@@ -370,6 +370,8 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
{
InotifyWatch* pW = rEvt.GetWatch();
IncronTabEntry* pE = FindEntry(pW);
+
+ std::string pWPath = pW->GetPath();
// no entry found - this shouldn't occur
if (pE == NULL)
@@ -422,7 +424,7 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
else {
cmd.append(cs.substr(oldpos, pos-oldpos));
if (cs[px] == '@') { // base path
- cmd.append(IncronTabEntry::GetSafePath(pW->GetPath()));
+ cmd.append(IncronTabEntry::GetSafePath(pWPath));
oldpos = pos + 2;
}
else if (cs[px] == '#') { // file name
Bug#947424: qtltools 1.2+dfsg-1 ftbfs on mipsel
Source: qtltools Version: 1.2+dfsg-1 Severity: serious Justification: ftbfs Tags: ftbfs sid bullseye Dear maintainer, Your last upload failed to build on mipsel. Your package is part of the htslib 1.10.2 transition, but I can't binNMU it on mipsel. Please have a look. Paul https://buildd.debian.org/status/package.php?p=qtltools (I am warned against a big log file, I am restricted in my bandwidth at the moment so I don't copy in the end of the log file). signature.asc Description: OpenPGP digital signature
Bug#947328: FTBFS Not Reproducible in multiple build test envs (sbuild, pbuilder, etc.)
I ran this exact package through a rebuild in an sbuild environment just now, and cannot reproduce your FTBFS. Automated build(s) failed to reproduce this in a pbuilder environment as well. Did you do anything to the package to make it trigger this FTBFS? What Arch and Distro did you build against, in what environment? (Because this doesn't FTBFS from anything I can tell thus far.) Thomas
Bug#947423: kallisto ftbfs with htslib 1.10.2
Source: kallisto Version: 0.46.1+dfsg-1 Severity: serious Justification: ftbfs Tags: ftbfs sid bullseye Dear maintainer, Your package is part of the htslib 1.10.2 transition. I tried to binNMU your package but it fails to build from source. Please have a look. Paul https://buildd.debian.org/status/package.php?p=kallisto Tail of log for kallisto on amd64: 86 | } kstring_t; | ^ [ 66%] Building CXX object src/CMakeFiles/kallisto_core.dir/common.cpp.o cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -I/<>/src -I/usr/include/hdf5/serial -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -o CMakeFiles/kallisto_core.dir/common.cpp.o -c /<>/src/common.cpp [ 71%] Building CXX object src/CMakeFiles/kallisto_core.dir/h5utils.cpp.o cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -I/<>/src -I/usr/include/hdf5/serial -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -o CMakeFiles/kallisto_core.dir/h5utils.cpp.o -c /<>/src/h5utils.cpp make[3]: *** [src/CMakeFiles/kallisto_core.dir/build.make:209: src/CMakeFiles/kallisto_core.dir/ProcessReads.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:131: src/CMakeFiles/kallisto_core.dir/all] Error 2 make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[1]: *** [Makefile:133: all] Error 2 make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' dh_auto_build: cd obj-x86_64-linux-gnu && make -j4 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:14: build-arch] Error 255 signature.asc Description: OpenPGP digital signature
Bug#947422: node-babel depends on itself for build, then updating core-js is blocked
Source: node-babel Severity: important Hi, node-babel depends on itself during build. Then when I try to update it with node-core-js ≥3, I got this: Error: Cannot find module 'core-js/library/fn/get-iterator' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15) at Function.Module._load (internal/modules/cjs/loader.js:562:25) at Module.require (internal/modules/cjs/loader.js:692:17) at require (internal/modules/cjs/helpers.js:25:18) at Object. (/usr/lib/nodejs/babel-runtime/core-js/get-iterator.js:1:31) Then I can not fix babel code source since error comes from an earlier babel. The best should be to find a way to build babel without babel. Else a patched version of babel-runtime could perhaps be embedded. This affects the migration of node-cloneable-readable, node-readable-stream,...
Bug#947421: delly ftbfs with htslib 1.10.2
Source: delly Version: 0.8.1-2 Severity: serious Justification: ftbfs Tags: ftbfs sid bullseye Dear maintainer, Your package is part of the htslib 1.10.2 transition. I tried to binNMU your package but it fails to build from source. Please have a look. Paul https://buildd.debian.org/status/package.php?p=delly Tail of log for delly on amd64: | ~^ src/merge.h:330:24: warning: ignoring return value of ‘int bcf_hdr_set_samples(bcf_hdr_t*, const char*, int)’, declared with attribute warn_unused_result [-Wunused-result] 330 | bcf_hdr_set_samples(hdr[file_c], NULL, false); // Do not read the sample information | ~~~^~ In file included from src/delly.cpp:40: src/merge.h: In function ‘void torali::mergeBCFs(torali::MergeConfig&, const std::vector&)’: src/merge.h:592:16: warning: ignoring return value of ‘int bcf_hdr_write(htsFile*, bcf_hdr_t*)’, declared with attribute warn_unused_result [-Wunused-result] 592 | bcf_hdr_write(fp, hdr_out); | ~^ make[2]: *** [Makefile:61: src/delly] Error 1 make[2]: Leaving directory '/<>' dh_auto_build: make -j4 "INSTALL=install --strip-program=true" "BUILT_PROGRAMS=src/delly src/dpe" returned exit code 2 make[1]: *** [debian/rules:12: override_dh_auto_build] Error 255 make[1]: Leaving directory '/<>' make: *** [debian/rules:9: build-arch] Error 2 signature.asc Description: OpenPGP digital signature
Bug#946405: (no subject)
Hi! I could enter my login/password into nextcloud client with "export LIBGL_ALWAYS_SOFTWARE=1" before launching the client. Thanks. There still are some problems with nautilus integradtion. But now , it is useable. Here are the output of some commands you tell me to post here: lspci|grep VGA 00:05.0 VGA compatible controller: NVIDIA Corporation C51 [GeForce 6150 LE] (rev a2) glxinfo | grep -i -E "GLX_MESA_query_renderer.:" -A5 Extended renderer info (GLX_MESA_query_renderer): Vendor: nouveau (0x10de) Device: NV4E (0x241) Version: 18.3.6 Accelerated: yes Video memory: 54MB It seems that nvidia driver is not installable on buster anymore. :-( Bye. -- Ludovic
Bug#936110: aff4: Python2 removal in sid/bullseye
On Fri, 30 Aug 2019 07:09:56 + Matthias Klose wrote: > Package: src:aff4 > Version: 0.24.post1-4 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html The python3 version of this package is in a new source, pyaff4. This source should be removed since it has no more rdepends now that rekall has been upgraded.. Filed as #947417. Scott K signature.asc Description: This is a digitally signed message part.
Bug#947386: plinth: [INTL:fr] French debconf templates translation
tag 947386 + pending thanks On Thu, 26 Dec 2019 01:39:41 +0100 Jean-Pierre Giraud wrote: > Package: plinth > Severity: wishlist > Tags: patch l10n > > Hi! > > Please find attached the french debconf templates translation, proofread > by the debian-l10n-french mailing list contributors. > > This file should be put as debian/po/fr.po in your package build tree. I have merged this patch. Thanks for updating the translation. -- James signature.asc Description: OpenPGP digital signature
Bug#947419: mirror submission for mirrors.layerbridge.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirrors.layerbridge.com Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Andrei Country: RO Romania Location: Bucharest Sponsor: LayerBridge https://www.layerbridge.com Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirrors.layerbridge.com/debian/project/trace/mirrors.layerbridge.com
Bug#947418: mirror submission for mirrors.layerbridge.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirrors.layerbridge.com Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Andrei Country: RO Romania Location: Bucharest Sponsor: LayerBridge https://www.layerbridge.com Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirrors.layerbridge.com/debian/project/trace/mirrors.layerbridge.com
Bug#942382: dstat in buster given --disk-util option fails to start
Thanks for reporting! Unfortunately this project was discontinued by the original author in 2019 and no contributions upstream were accepted since 2016. So this bug will not be fixed unless somebody completely forks the original project at https://github.com/dagwieers/dstat
Bug#947420: mirror submission for mirrors.layerbridge.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirrors.layerbridge.com Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Andrei Country: RO Romania Location: Bucharest Sponsor: LayerBridge https://www.layerbridge.com Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ Trace Url: http://mirrors.layerbridge.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirrors.layerbridge.com/debian/project/trace/mirrors.layerbridge.com
Bug#947417: RM: aff4 -- RoQA; Obsolete libs (python2), replaced by pyaff4
Package: ftp.debian.org Severity: normal See the discussion in #936110. This is ready to be removed. Scott K
Bug#947416: yamllint: Please move the package under the debian python umbrella
Package: yamllint Severity: wishlist Dear Maintainer, Instead of using the upstream repo, we should use the Python team umbrella. This will simplify the maintenance et get more contributors. Thanks Sylvestre -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#947415: ITP: libtest-nicedump-perl -- module for nice and human readable dumps of objects in tests
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-nicedump-perl Version : 1.0.1 Upstream Author : Gianni Ceccarelli * URL : https://metacpan.org/release/Test-NiceDump * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for nice and human readable dumps of objects in tests Test::NiceDump uses Data::Dump::Filtered and a set of sensible filters to dump test data in a more readable way. For example, DateTime objects get printed in the full ISO 8601 format, and DBIx::Class::Row objects get printed as hashes of their inflated columns. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#947414: ITP: ruby-marginalia -- Attach comments to your ActiveRecord queries
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-de...@lists.debian.org * Package name: ruby-marginalia Version : 1.8.0 Upstream Author : 37signals, LLC * URL : https://github.com/basecamp/marginalia * License : Expat Description : Attach comments to your ActiveRecord queries By default, it adds the application, controller, and action names as a comment at the end of each query. . This helps when searching log files for queries, and seeing where slow queries came from. signature.asc Description: OpenPGP digital signature
Bug#931496: redmine: Missing in Debian Buster
Dear maintainers, > Currently the 4.0.4 version in unstable is working fine but > unfortunately it is blocked from entering testing, which is a > prerequisite for the backport. Redmine 4.0.4 entered testing some time ago; are there any other obstacles that need to be worked out? best regards, Adi Kriegisch signature.asc Description: PGP signature
Bug#947413: linux-image-4.19.0-7-amd64: kernel lockup
Package: src:linux Version: 4.19.87-1 Dear Maintainer, * What led up to the situation? Not sure exactly. Normal operations. I'll include some facts that I suspect might be relevant: Most volumes are mounted with the "discard" option. The I/O operations in question seem to have involved /var, which is ext4, mounted with discard. This looks to me like it *could* be related: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/block?h=v4.19.91=42d72c9d28964fbbaeaa15baf2e7ce418d1c1a0a When this issue happened I was using mq-deadline, I tried switching to bfq in the process of investigating the possible causes. I do not yet have a way to reproduce this behavior. * What was the outcome of this action? Dec 25 07:15:57 be1va kernel: [698773.335359] BUG: unable to handle kernel NULL pointer dereference at 0028 Dec 25 07:15:57 be1va kernel: [698773.338614] PGD 0 P4D 0 Dec 25 07:15:57 be1va kernel: [698773.339537] Oops: [#1] SMP NOPTI Dec 25 07:15:57 be1va kernel: [698773.340914] CPU: 29 PID: 784 Comm: kworker/29:1H Not tainted 4.19.0-7-amd64 #1 Debian 4.19.87-1 Dec 25 07:15:57 be1va kernel: [698773.344187] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Dec 25 07:15:57 be1va kernel: [698773.347903] Workqueue: kblockd blk_mq_run_work_fn Dec 25 07:15:57 be1va kernel: [698773.349978] RIP: 0010:rb_next+0x11/0x50 Dec 25 07:15:57 be1va kernel: [698773.351545] Code: 89 ec 48 89 c5 e9 80 fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 8b 0f 48 39 cf 74 39 48 8b 47 08 48 85 c0 74 22 <48> 8b 50 10 48 85 d2 74 0c 48 89 d0 48 8b 50 10 48 85 d2 75 f4 c3 Dec 25 07:15:57 be1va kernel: [698773.357983] RSP: 0018:a075c73bfdb0 EFLAGS: 00010206 Dec 25 07:15:57 be1va kernel: [698773.359782] RAX: 0018 RBX: 901819663e00 RCX: db8d639239c0 Dec 25 07:15:57 be1va kernel: [698773.362331] RDX: 901819663e68 RSI: 0001 RDI: 90181519ea60 Dec 25 07:15:57 be1va kernel: [698773.364686] RBP: 90181519ea00 R08: R09: 00480020 Dec 25 07:15:57 be1va kernel: [698773.367346] R10: 0015d519e000 R11: R12: 901819663e5c Dec 25 07:15:57 be1va kernel: [698773.369754] R13: 0001 R14: 901819663e10 R15: 90181519d6c0 Dec 25 07:15:57 be1va kernel: [698773.372166] FS: () GS:901827b4() knlGS: Dec 25 07:15:57 be1va kernel: [698773.375158] CS: 0010 DS: ES: CR0: 80050033 Dec 25 07:15:57 be1va kernel: [698773.377238] CR2: 0028 CR3: 0002df80a002 CR4: 00360ee0 Dec 25 07:15:57 be1va kernel: [698773.379495] DR0: DR1: DR2: Dec 25 07:15:57 be1va kernel: [698773.382132] DR3: DR6: fffe0ff0 DR7: 0400 Dec 25 07:15:57 be1va kernel: [698773.384604] Call Trace: Dec 25 07:15:57 be1va kernel: [698773.385590] dd_dispatch_request+0x15f/0x210 Dec 25 07:15:57 be1va kernel: [698773.387083] blk_mq_do_dispatch_sched+0xc7/0x120 Dec 25 07:15:57 be1va kernel: [698773.388752] blk_mq_sched_dispatch_requests+0x11e/0x170 Dec 25 07:15:57 be1va kernel: [698773.390857] __blk_mq_run_hw_queue+0x4e/0xe0 Dec 25 07:15:57 be1va kernel: [698773.392508] process_one_work+0x1a7/0x3a0 Dec 25 07:15:57 be1va kernel: [698773.393888] worker_thread+0x30/0x390 Dec 25 07:15:57 be1va kernel: [698773.395354] ? create_worker+0x1a0/0x1a0 Dec 25 07:15:57 be1va kernel: [698773.396927] kthread+0x112/0x130 Dec 25 07:15:57 be1va kernel: [698773.398221] ? kthread_bind+0x30/0x30 Dec 25 07:15:57 be1va kernel: [698773.399943] ret_from_fork+0x1f/0x40 Dec 25 07:15:57 be1va kernel: [698773.401562] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcc_cpufreq virtio_console virtio_balloon sg joydev serio_raw evdev pcspkr button qemu_fw_cfg ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sd_mod ata_generic virtio_net net_failover virtio_scsi failover crc32c_intel ata_piix uhci_hcd libata ehci_hcd aesni_intel aes_x86_64 virtio_pci crypto_simd scsi_mod usbcore virtio_ring cryptd psmouse glue_helper virtio i2c_piix4 usb_common floppy Dec 25 07:15:57 be1va kernel: [698773.420978] CR2: 0028 Dec 25 07:15:57 be1va kernel: [698773.422326] ---[ end trace a1e4f02f504cc7b4 ]--- Dec 25 07:15:57 be1va kernel: [698773.424075] RIP: 0010:rb_next+0x11/0x50 Dec 25 07:15:57 be1va kernel: [698773.425534] Code: 89 ec 48 89 c5 e9 80 fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 8b 0f 48 39 cf 74 39 48 8b 47 08 48 85 c0 74 22 <48> 8b 50 10 48 85 d2 74 0c 48 89 d0 48 8b 50 10 48 85 d2 75 f4 c3 Dec 25 07:15:57 be1va kernel: [698773.433054] RSP: 0018:a075c73bfdb0 EFLAGS: 00010206 Dec 25 07:15:57 be1va kernel: [698773.434964] RAX: 0018 RBX: 901819663e00 RCX: db8d639239c0
Bug#947412: ITP: mopidy-local -- Mopidy extension for playing music from your local music archive
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: mopidy-local Version : 3.0.0 Upstream Author : Stein Magnus Jodal * URL : https://mopidy.com/ * License : Apache-2.0 Programming Lang: Python Description : Mopidy extension for playing music from your local music archive Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music, and more. You can edit the playlist from any phone, tablet, or computer using a variety of MPD and web clients. This package provides a Mopidy extension extension for playing music from your local music archive. Mopidy-Local builds an index of your archive's metadata ahead of time, and can thus provide features like search. This extension used to be part of the mopidy package, but was extracted to its own extension in Mopidy 3.0. The package will be maintained in the mopidy-team group on Salsa. signature.asc Description: PGP signature
Bug#947411: ITP: mopidy-mpd -- Mopidy extension for controlling Mopidy from MPD clients
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: mopidy-mpd Version : 3.0.0 Upstream Author : Stein Magnus Jodal * URL : https://mopidy.com/ * License : Apache-2.0 Programming Lang: Python Description : Mopidy extension for controlling Mopidy from MPD clients Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music, and more. You can edit the playlist from any phone, tablet, or computer using a variety of MPD and web clients. This package provides a Mopidy extension for controlling Mopidy from MPD clients. This extension used to be part of the mopidy package, but was extracted to its own extension in Mopidy 3.0. The package will be maintained in the mopidy-team group on Salsa. signature.asc Description: PGP signature
Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Tue, Dec 24, 2019 at 10:07:02AM +0100, Andreas Tille wrote: > > python-envisage has not yet been converted to Python3 and seems to be > > required: > > $ mayavi2 > > Traceback (most recent call last): > > File "/usr/bin/mayavi2", line 464, in > > from mayavi.plugins.app import Mayavi, setup_logger > > File "/usr/lib/python3/dist-packages/mayavi/plugins/app.py", line 19, in > > > > from .mayavi_workbench_application import MayaviWorkbenchApplication > > File > > "/usr/lib/python3/dist-packages/mayavi/plugins/mayavi_workbench_application.py", > > line 13, in > > from envisage.ui.workbench.api import WorkbenchApplication > > ModuleNotFoundError: No module named 'envisage' > > That's recorded as TODO item in d/changelog now. FYI, I just worked on converting envisage to python3: https://salsa.debian.org/python-team/modules/python-envisage I asked Dmitry S. to upload it. Scott
Bug#919170: [Piuparts-devel] Bug#919170: Bug#919170: Please update dependency to python3-debianbts
On Thu, Dec 26, 2019 at 03:59:54PM +0100, Nis Martensen wrote: > > TypeError: mynext() takes 1 positional argument but 2 were given > > again, help very welcome! > A new merge request has the next set of fixups: > https://salsa.debian.org/debian/piuparts/merge_requests/17 many thanks, merged and deployed, now this is left: ceback (most recent call last): File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 433, in main() File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 425, in main while m.do_transaction(): File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 268, in do_transaction self._commands[command](command, args) File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 323, in _reserve self._init_db() File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 202, in _init_db self._load_package_database(self._section) File "/srv/piuparts.debian.org/share/piuparts/piuparts-master-backend", line 232, in _load_package_database config.get_arch())) File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/packagesdb.py", line 455, in load_alternate_versions_from_packages_urls pf2.load_packages_urls(urls) File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/packagesdb.py", line 183, in load_packages_urls self._read_file(stream, restrict_packages=restrict_packages) File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/packagesdb.py", line 190, in _read_file headers = rfc822_like_header_parse(input) File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/packagesdb.py", line 53, in rfc822_like_header_parse line = input.readline() File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/__init__.py", line 58, in readline empty = not self._refill() File "/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/__init__.py", line 49, in _refill chunk = chunk.decode() UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 14159: unexpected end of data -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#947410: coinor-cbc: none
Package: coinor-cbc Version: 2.9.9+repack1-2 Severity: wishlist Dear Maintainer, Previous coinor-cbc 2.9.9+repack1-1 was working as expected. Then apt update installed 2.9.9+repack1-2 and this version crashes every time. Tried many input files in .lp and .mps formats. Crashes almost immediately every time. wsl$ cbc queens80.lp -1 was provided for dualBound - valid range is 1e-20 to 1e+12 0 was provided for primalWeight - valid range is 1e-20 to 1e+20 Welcome to the CBC MILP Solver Version: 2.9.9 Build Date: Aug 7 2019 command line - cbc queens80.lp (default strategy 1) CoinLpIO::readLp(): Maximization problem reformulated as minimization Coin0009I Switching back to maximization to get correct duals etc Continuous objective value is 80 - 0.05 seconds Cgl0003I 0 fixed, 0 tightened bounds, 2 strengthened rows, 0 substitutions Cgl0004I processed model has 474 rows, 6400 columns (6400 integer (6400 of which binary)) and 25598 elements Cutoff increment increased from 1e-05 to 0. Segmentation fault (core dumped) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-18362-Microsoft 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: unable to detect Versions of packages coinor-cbc depends on: ii coinor-libcbc3 2.9.9+repack1-2 ii coinor-libcgl1 0.59.10+repack1-2 ii coinor-libclp1 1.17.3+repack1-1 ii coinor-libcoinutils3v5 2.11.3+repack1-1 ii coinor-libosi1v5 0.108.5+repack1-1 ii libblas3 [libblas.so.3] 3.9.0-1 ii libbz2-1.0 1.0.8-2 ii libc62.29-6 ii libgcc1 1:9.2.1-21 ii liblapack3 [liblapack.so.3] 3.9.0-1 ii libstdc++6 9.2.1-21 ii zlib1g 1:1.2.11.dfsg-1+b1 coinor-cbc recommends no packages. coinor-cbc suggests no packages. -- no debconf information
Bug#947396: strace: New upstream release(s) available
On Thu, Dec 26, 2019 at 10:26:06AM +0100, Andreas Henriksson wrote: > Package: strace > Version: 4.26-0.2 > Severity: wishlist > > Dear Maintainer, > > Multiple new upstream releases has been cut since the last update > in Debian. The latest one being 5.4 as of now. [...] > FAIL: strace-DDD > [...] > + run_strace -D -enone -esignal=none ../tracer_ppid_pgid_sid > + > + args=-D -enone -esignal=none ../tracer_ppid_pgid_sid > + ../../strace -o log -D -enone -esignal=none ../tracer_ppid_pgid_sid > + read -r ppid pgid sid > + [ 1321 -eq 1 ] [...] So while looking at this it became clear that this is likely an issue when building under a systemd user slice, where apparently the strace process is not able to reparent itself to be a child of pid1 as the 1321 process is my 'systemd --user' process. I've confirmed this problem does not happen when building outside a systemd user slice, thus I guess we can ignore this issue. Regards, Andreas Henriksson
Bug#947409: RFS: clp/1.17.3+repack1-2 -- Coin-or linear programming solver
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clp" * Package name: clp Version : 1.17.3+repack1-2 Upstream Author : * URL : https://projects.coin-or.org/Clp * License : EPL-1 * Vcs : https://salsa.debian.org/science-team/clp Section : science It builds those binary packages: coinor-clp - Coin-or linear programming solver coinor-libclp1 - Coin-or linear programming solver (shared libraries) coinor-libclp-dev - Coin-or linear programming solver (developer files) coinor-libclp-doc - Coin-or linear programming solver (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/clp Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/clp/clp_1.17.3+repack1-2.dsc Changes since the last upload: * QA upload * Add coinor-libclp-doc.links to remove duplicated files * Set minimum version on runtime-dependencies * Add patch to check for correct architecture New release to fix certain issue with the old one, built and tested on six different architectures this time. Please take a look at the patch to see if it is acceptable. Regards, Håvard
Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function
On Fri, Dec 20, 2019 at 10:24:20PM +0100, Salvatore Bonaccorso wrote: > > And released as DSA 4591-1. Note: The patch was not upstream commited > at point of writing this. And I see Mike did as well release for LTS. > I saw that Mike did updates for jessie (LTS) and wheezy (ELTS). > > > unstable would need an update as well yet. > > > > > Of course. > > Ideally this happen soon, but the RC bug is enough to mark the > 'stable' -> 'testing' regression. Just let me know if any of you can > do it or if you would prefer a NMU with same patch (both approaches > works for me). > I have made an upload to unstable of version 2.1.27+dfsg-2 with the patch that fixes the CVE. > > > Can you later import then the changes in the packaging repository in > > > the appropriate branches? > > > > > I could manage that in the coming days. Unless Ondrej or someone else > > gets to it first. > > Thanks! > As a summary, here is the state of cyrus-sasl2 in the various release and the associated Git branches in Salsa: sid: up to date on master branch, Debian version 2.1.27+dfsg-2 has been uploaded bullseye: waiting on transition of package from sid, no associated branch in Salsa buster: new branch, master-buster*, contains new commit representing Debian version 2.1.27+dfsg-1+deb10u1 stretch: new branch, master-stretch*, contains two (2) new commits representing Debian versions 2.1.27~101-g0780600+dfsg-3 (NMU in 2017 which as not recorded follwing 2.1.27~101-g0780600+dfsg-2) and Debian version 2.1.27~101-g0780600+dfsg-3+deb9u1 with the patch for this CVE jessie: history has diverged; there is already an old commit and tag for Debian version 2.1.26.dfsg1-13+deb8u2 from 2016 which collides with Mike's recent 2.1.26.dfsg1-13+deb8u2 jessie update, so I have not done anything with this wheezy: up to date on existing master-wheezy branch based on Mike's 2.1.25.dfsg1-6+deb7u2 ELTS updates * As far as the new master-buster and master-stretch branches, I only made those branches to record the changes which have already been uploaded. In particular, I did not update debian/gbp.conf to note the new branch names; such a change will be required if we decide to make further revisions along either of the new branches and then build from the Git repository. I have pushed tags for each of the above versions as well (except the jessie version, as noted). I include all of this information so that the cyrus-sasl2 in particular is made aware of all the changes I have pushed. Regards, -Roberto -- Roberto C. Sánchez
Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes
On Thu, Dec 26, 2019 at 03:41:32PM +0100, Marco d'Itri wrote: > OK. One more thing: can I make the names lower case like in the other > numbers files or are they case sensitiv? > AFAIK they're not case sensitive, i.e. these two commands (one lowercase and the other uppercase) work as expected: # ebtables -A FORWARD -p arp -j ACCEPT # ebtables -A FORWARD -p IPv6 -j ACCEPT Listing the rules applied, there's no difference between the lowercase and the uppercase rule (both are listed in uppercase): # ebtables -L FORWARD Bridge table: filter Bridge chain: FORWARD, entries: 2, policy: ACCEPT -p ARP -j ACCEPT -p IPv6 -j ACCEPT But, those protocol names are obtained from ethertypes, if they're "lowercased" in /etc/ethertypes the output differs (now the rules are listed in lowercase): ... -p arp -j ACCEPT -p ipv6 -j ACCEPT So any tool reading from ebtables output can be broken. I think it's better not to put the names in lowercase. Thanks, Alberto
Bug#945681: gvb: diff for NMU version 1.4-1.1
Dear Adrian, thank you, I really appreciate. I was planning to fix that packaging mistake, but as you might have noticed, I have really slow reactions lately - and then, I still need to go through a sponsor. So if you prefer, feel free to re-upload the package without delay. Pietro Il giorno gio, 26/12/2019 alle 15.04 +0200, Adrian Bunk ha scritto: > Control: tags 945681 + patch > Control: tags 945681 + pending > > Dear maintainer, > > I've prepared an NMU for gvb (versioned as 1.4-1.1) and uploaded it > to DELAYED/14. Please feel free to tell me if I should cancel it. > > cu > Adrian
Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager
Hi Markus, Thank you for clarifying the situation. On 2019-12-23 18:24:08, Markus Koschany wrote: Hello Niels, Am 23.12.19 um 15:04 schrieb DebBug: Anyone to chime in? Craig? Markus? There is a bit of confusion here, so I try to explain the situation and how we should proceed. Thank you for filing bug report #947212 to track the security issues in Wordpress. This will help to answer those questions raised by Adam. However there was already #946905 that you could have been used as well. Must have missed that one. You have only recently added me to CC, presumably because I have done IIRC, Craig added you initially, FWIW. some security uploads in the past for Wordpress. I don't know what you have discussed with Craig and if he wants to review your work and sponsor it later. Then you actually don't need to open a sponsorship request on debian-mentors. I yet ignore how the process continues, whether Craig will upload the updated package or someone else. And when. Sponsorship requests are either of severity normal or important. Here it would be ok to use important but the severity is merely an indicator and it doesn't automatically guarantee that a bug is prioritized. Security related bugs like #947212/#946905 are either of severity important or grave. OK. From my perspective, regarding the wordpress issue and being responsible for maintenance of a number of exposed instances, it is *critical* security releases get integrated on short terms' notice. As explained, system and data is at elevated risk in the particular case of wordpress having a considerable share of worldwide CMS instances. This also entails liability in case of data loss and/or successful exploitation of local and/or remote resources. In terms of legal obligation of care of user data, customer data and systems as well as in terms of GDPR. This direct consequence is driving a severity "critical". It is also the reason for my providing an updated debian wordpress package for NMU. I prefer debian packages over upstream packaging and if I'm packaging deb package updates locally I might as well let others profit from it. Version 5.3.2 seems to fix a couple of security vulnerabilities. No CVE has been assigned yet. This version should be uploaded to unstable. My intention. If you want to fix Wordpress in Buster and Stretch as well, then you have to go a different route. The security team is responsible for that. As previously discussed I recommend to base security updates on upstream releases for specific Wordpress branches. https://wordpress.org/download/releases/ Buster should be updated to version 5.0.8 and Stretch to 4.7.16. In both cases you would base your work on the Wordpress packages in Buster and Stretch. The changes to the debian files should be minimal, you would merely rebase existing patches and repack the tarball to make it compliant with the DFSG. Not so much my intention. Basically, not at all, for now. I'm depending on the latest upstream releases so I'm sticking with unstable wordpress packages. In short: Version 5.3.2 -> unstable Did Craig agree with the upload? If there is simply no response because of the holiday season we could do a NMU with a delay of 5 to 10 days. I assume you haven't made any major changes to the package. Well, as detailed above, those delays -- for this particular package -- are inacceptable, at least for me. At that, it's on top of the delay from the point in time upstream released to bug reported. Is there a way to speed up this whole process for future releases? Sure, I locally feed the updated packages to archive mirrors, although I'd prefer not preempting debian package releases. After that: Version 5.0.8 -> buster-security Version 4.7.16 -> stretch-security You can already prepare the packages, then we contact the security team and ask for approval. For the time being, I am time-constraint on provision for unstable. Regards, Markus Thanks again for your explanation and efforts. Have a nice holiday. Cheers Nils signature.asc Description: PGP signature
Bug#937269: peframe: Python2 removal in sid/bullseye
Just an update: Python 3 compatibility is indeed introduced in the latest upstream version, however, that version also adds some new dependencies that would need to be packaged and pass NEW. For example, python-virustotal-api, which has been in NEW for quite some time. I have also looked at adding python-oletools, but that will also need new dependencies of its own. I’ll try work on this eventually, unless someone else is interested and has some spare time. Sascha
Bug#919170: [Piuparts-devel] Bug#919170: Bug#919170: Please update dependency to python3-debianbts
> TypeError: mynext() takes 1 positional argument but 2 were given > > again, help very welcome! A new merge request has the next set of fixups: https://salsa.debian.org/debian/piuparts/merge_requests/17
Bug#947408: new version broken: extra configuration key: smtp-ssl-protocol
Package: rss2email Version: 1:3.11-1 Severity: normal joey@kite:~>r2e run 2019-12-26 10:45:38,240 [ERROR] extra configuration key: smtp-ssl-protocol I had not received any feeds at all since Dec 19th, which seems consistent with the upgrade to this new version getting to my system. My config file contained: smtp-ssl-protocol = SSLv3 I didn't set that; an older version of r2e did. Deleting the line got it working again. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rss2email depends on: ii python3 3.7.5-1 ii python3-feedparser 5.2.1-1 ii python3-html2text 2019.8.11-1 Versions of packages rss2email recommends: ii python3-bs4 4.8.0-2 Versions of packages rss2email suggests: pn esmtp -- no debconf information -- see shy jo
Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes
On Dec 26, Alberto Molina Coballes wrote: > /etc/ethertypes is obtained directly from upstream (ebtables), no > changes are made to its packaging in Debian and I suposse that the > same file has not been modified for years, because ebtables is not > under active development. OK. One more thing: can I make the names lower case like in the other numbers files or are they case sensitiv? -- ciao, Marco signature.asc Description: PGP signature
Bug#900092: Bug#842896: minicom: diff for NMU version 2.7.1-1.1
On Thu, Dec 26, 2019 at 09:06:22 -0500, Boyuan Yang wrote: > > Can you explain, please, why minicom needs to build-depend on > > debhelper > > instead of autotools-dev? > > I was holding the assumption that your package will eventually migrate > to be using dh, in which case build-depends on debhelper is necessary. > It seems that current build scripts in debian/rules indeed does not > need it and autotools-dev would be enough. Please feel free to revert > it or cancel this NMU if you find it necessary. Okay, I'll revert the dependency upon next upload, then. Thanks for the NMU, Martin
Bug#936932: libvigraimpex: Python2 removal in sid/bullseye
Control: block -1 by 947365 On 2019-12-23 Andreas Metzler wrote: [...] > I will do a QA upload. I have opened a request for a transition slot. cu Andreas signature.asc Description: PGP signature
