Bug#940290: q2-types: triangular dependency with q2-types, q2cli
Hi Liubov, On Sun, Sep 15, 2019 at 12:18:45PM +0200, Bill Allombert wrote: > Package: q2-types > Version: 2019.7.0-1 > Severity: important > > Hello Debian Med Packaging Team, > > There is a trianglar dependency between q2-types, q2cli and qiime: > > q2-types :Depends: qiime > q2cli :Depends: qiime > qiime :Depends: q2cli, q2-types > > Complex circular dependencies are known to cause problems during upgrade, so > we > should try to avoid them. I think this can be broken by replacing the Depends by Recommends. IMHO it could be: q2-types: Recommends: qiime q2cli : Recommends: qiime This is the case if neither q2-types or q2cli are totally broken if qiime is not installed (do not import anything from qiime etc.) If this assumption is wrong and both really need qiime to be installed than we should consider qiime: Recommends: q2cli, q2-types What do you think? Kind regards Andreas. -- http://fam-tille.de
Bug#939866: [debian-mysql] Bug#939866: Bug#939866: Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41
Buster PU filed as Bug#940521
Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails
I'm seeing a similar problem here with older nvidia cards. Could you try this? 1. Login with metacity 2. Open a terminal 3. Run: marco --no-composite --replace For me, both metacity and `marco --no-composite` works fine. While the default `marco --composite`, * Crashes Xorg on TNT2 * Doesn't crash but causes tearing and display artifacts in newer cards I think that marco 1.20 started using some driver API which doesn't work in some nouveau cards. Another workaround for me is to use PageFlip Off in xorg.conf, but this hurts performance.
Bug#940544: xrdp doesn't always start at boot (full install)
Package: xrdp Version: 0.9.9-1 Severity: normal Dear Maintainer, * What led up to the situation? Buster install from network, xfce as desktop, xrdp and xorgxrdp installed later (full install automated). I have the problem both on physical server and in VM. * What was the outcome of this action? The service doesn't start, so the server doesn't accept connections Something is perhaps wrong with /run and /var/run according to the logs (below). If I restart the service, all is fine, it's perhaps a race condition. Notice that debian ships a prestart script which creates /var/run/xrdp root@phoenix:~# systemctl status xrdp ● xrdp.service - xrdp daemon Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Tue 2019-09-17 05:04:42 CEST; 1h 51min ago Docs: man:xrdp(8) man:xrdp.ini(5) sept. 17 05:03:11 phoenix systemd[1]: xrdp.service: Can't open PID file /run/xrdp/xrdp.pid (yet?) after start: No such file or directory sept. 17 05:03:12 phoenix systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /var/run/, updating /var/run/xrdp/xrdp.pid → /ru sept. 17 05:03:13 phoenix xrdp[1246]: (1246)(140441694279488)[INFO ] starting xrdp with pid 1246 sept. 17 05:03:13 phoenix xrdp[1246]: (1246)(140441694279488)[INFO ] listening to port 3389 on 0.0.0.0 sept. 17 05:04:42 phoenix systemd[1]: xrdp.service: Start operation timed out. Terminating. sept. 17 05:04:42 phoenix systemd[1]: xrdp.service: Failed with result 'timeout'. sept. 17 05:04:42 phoenix systemd[1]: Stopped xrdp daemon. sept. 17 05:33:12 phoenix systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /var/run/, updating /var/run/xrdp/xrdp.pid → /ru -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/40 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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages xrdp depends on: ii adduser 3.118 ii libc62.28-10 ii libfuse2 2.9.9-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopus0 1.3-1 ii libpam0g 1.3.1-5 ii libssl1.11.1.1c-1 ii libx11-6 2:1.6.7-1 ii libxfixes3 1:5.0.3-1 ii libxrandr2 2:1.5.1-1 ii lsb-base 10.2019051400 ii ssl-cert 1.0.39 Versions of packages xrdp recommends: pn fuse ii xorgxrdp 1:0.2.9-1 Versions of packages xrdp suggests: pn guacamole pn xrdp-pulseaudio-installer Versions of packages xorgxrdp depends on: ii libc6 2.28-10 pn xorg-input-abi-24 ii xserver-xorg-core [xorg-video-abi-24] 2:1.20.4-1 Versions of packages xorgxrdp recommends: ii xorg 1:7.7+19 Versions of packages xrdp is related to: pn vnc-server pn xserver-xorg-legacy -- Configuration Files: /etc/xrdp/sesman.ini changed: ;; See `man 5 sesman.ini` for details [Globals] ListenAddress=127.0.0.1 ListenPort=3350 EnableUserWindowManager=true ; Give in relative path to user's home directory UserWindowManager=startwm.sh ; Give in full path or relative path to /etc/xrdp DefaultWindowManager=startwm.sh ; Give in full path or relative path to /etc/xrdp ReconnectScript=reconnectwm.sh [Security] AllowRootLogin=true MaxLoginRetry=4 TerminalServerUsers=tsusers TerminalServerAdmins=tsadmins ; When AlwaysGroupCheck=false access will be permitted ; if the group TerminalServerUsers is not defined. AlwaysGroupCheck=false [Sessions] ;; X11DisplayOffset - x11 display number offset ; Type: integer ; Default: 10 X11DisplayOffset=50 ;; MaxSessions - maximum number of connections to an xrdp server ; Type: integer ; Default: 0 MaxSessions=50 ;; KillDisconnected - kill disconnected sessions ; Type: boolean ; Default: false ; if 1, true, or yes, kill session after 60 seconds KillDisconnected=true ;; DisconnectedTimeLimit - when to kill idle sessions ; Type: integer ; Default: 0 ; if not zero, the seconds before a disconnected session is killed ; min 60 seconds DisconnectedTimeLimit=300 ;; IdleTimeLimit (specify in second) - wait before disconnect idle sessions ; Type: integer ; Default: 0 ; Set to 0 to disable idle disconnection. IdleTimeLimit=0 ;; Policy - session allocation policy ; Type: enum [ "Default" | "UBD" | "UBI" | "UBC" | "UBDI" | "UBDC" ] ; Default: Xrdp: and Xvnc: ; "UBD" session per ; "UBI" session per ; "UBC" session per ; "UBDI" session per ; "UBDC" session per Policy=Default [Logging] LogFile=xrdp-sesman.log LogLevel=DEBUG EnableSyslog=1 SyslogLevel=DEBUG ; ; Session definitions - startup command-line parameters for each session type ; [Xorg] ; Specify the path of non-suid Xorg executable. It might differ
Bug#940543: blueman: unable to Search again after Stop Discovery (Status: Busy)
Package: blueman
Version: 2.0.8-1
Severity: normal
Hello,
I think I've managed to narrow this down thanks to btmon. Steps to
reproduce:
1. set `sudo btmon` running in a terminal
2. open Devices... window from the applet
3. ensure nothing in range is in pairing mode
4. click Search and wait 10 seconds
btmon output shows "@ MGMT Command: Start Discovery", then "@ MGMT
Command: Stop Discovery" with "Status: Busy". See attached busy.log.
Observe that the bottom left progress bar does not disappear, even if
Cancel Operation is pressed. The Search, Add and Pair buttons are now
greyed out and disabled.
5. close and re-open the Devices window
6. click Search
btmon output only shows "RAW Open" and Close messages, no "Start
Discovery" command, then "Stop Discovery" with "Status: Rejected".
7. remove and re-insert the USB adapter
8. click Search
btmon output once again shows the "Start Discovery" message.
All of this happened pretty reliably regardless of PC USB adapter vs
laptop built-in etc. However, I did occasionally get lucky with the
expected behaviour of "Stop Discovery" with "Status: Success" causing
the progress bar to disappear. See attached success.log. Similarly, if
any device is found in the search, then the discovery stops correctly.
--
Phil Morrell
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (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_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 blueman depends on:
ii bluez 5.50-1
ii bluez-obexd 5.50-1
ii dbus 1.12.16-1
ii dbus-user-session [default-dbus-session-bus] 1.12.16-1
ii dbus-x11 [dbus-session-bus] 1.12.16-1
ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2
ii gir1.2-appindicator3-0.1 0.4.92-7
ii gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii gir1.2-glib-2.0 1.58.3-2
ii gir1.2-gtk-3.03.24.5-1
ii gir1.2-notify-0.7 0.7.7-4
ii gir1.2-pango-1.0 1.42.4-7~deb10u1
ii gnome-icon-theme 3.12.0-3
ii libbluetooth3 5.50-1
ii libc6 2.28-10
ii libglib2.0-0 2.58.3-2+deb10u1
ii libpulse-mainloop-glib0 12.2-4+deb10u1
ii libpython3.7 3.7.3-2
ii librsvg2-common 2.44.10-2.1
ii notification-daemon 3.20.0-4
ii python3 3.7.3-1
ii python3-cairo 1.16.2-1+b1
ii python3-dbus 1.2.8-3
ii python3-gi3.30.4-1
ii python3-gi-cairo 3.30.4-1
ii xfce4-notifyd [notification-daemon] 0.4.3-1
Versions of packages blueman recommends:
ii policykit-1 0.105-25
ii pulseaudio-module-bluetooth 12.2-4+deb10u1
blueman suggests no packages.
-- no debconf information
@ RAW Open: blueman-manager version 2.22 {0x0003}
48.306788
@ RAW Close: blueman-manager {0x0003}
48.306810
@ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0]
48.959032
Address type: 0x07
BR/EDR
LE Public
LE Random
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #126 [hci0]
48.959097
Address: 0E:46:52:F7:DA:D9 (Non-Resolvable)
> HCI Event: Command Complete (0x0e) plen 4 #127 [hci0]
> 49.029551
LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #128 [hci0]
49.029615
Type: Active (0x01)
Interval: 22.500 msec (0x0024)
Window: 11.250 msec (0x0012)
Own address type: Random (0x01)
Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #129 [hci0]
> 49.031547
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #130 [hci0]
49.031601
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #131 [hci0]
> 49.033614
LE Set Scan Enable
Bug#932677: Bug#932679: python-gdal dropped from gdal (3.0.1+dfsg-1~exp3)
block 932679 by 932197 938330 938307 937262 937258 block 932679 by 937145 936503 936704 936285 thanks On 9/17/19 6:05 AM, Sandro Tosi wrote: > thanks for the heads up, but please note python-networkx has still > planty of reverse-dependencies, so we cannot drop that package yet. > please dont drop python-gdal from unstable until it has no rev-deps. I'm sorry, but I cannot wait for that. The python-gdal package won't be re-introduced for GDAL 3 in experimental. Once the gdal transition starts python-gdal will be gone from unstable, and the severity of these bugreports will be increased to serious. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#940542: RFS: assaultcube-data/1.2.0.2.1-3 -- data files and documentation for AssaultCube
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "assaultcube-data" * Package name: assaultcube-data Version : 1.2.0.2.1-3 Upstream Author : Rabid Viper Productions * URL : http://assault.cubers.net * License : Other * Vcs : https://salsa.debian.org/games-team/assaultcube-data Section : non-free/games It builds those binary packages: assaultcube-data - data files and documentation for AssaultCube To access further information about this package, please visit the following URL: https://mentors.debian.net/package/assaultcube-data Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/non-free/a/assaultcube-data/assaultcube-data_1.2.0.2.1-3.dsc Changes since the last upload: * debian/control: + Add Multi-Arch: foreign to all the binary packages. + Changed versioned in breaks/replaces to avoid version conflict. * debian/copyright: + Modified upstream URL in "Source:". * debian/upstream: - Signed non-upstream key removed. + Updated upstream URL information in metadata. * Updated upstream URL in debian/watch. Regards, -- Carlos Donizete Froes [a.k.a coringao]
Bug#932677: Bug#932679: python-gdal dropped from gdal (3.0.1+dfsg-1~exp3)
thanks for the heads up, but please note python-networkx has still planty of reverse-dependencies, so we cannot drop that package yet. please dont drop python-gdal from unstable until it has no rev-deps. thanks! On Fri, Aug 30, 2019 at 4:55 AM Sebastiaan Couwenberg wrote: > > gdal (3.0.1+dfsg-1~exp3) dropped support for Python 2 and no longer > builds python-gdal. > > Your package will break when the transition to gdal 3.x starts. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#760873: [vim-gtk] Incorrect display of ascii glyps (ie. displays 'm' in place of 'g').
On Sun, Mar 08, 2015 at 04:27:21PM +0900, Mattia Dongili wrote: > Hi James, > yes, it's totally related to the font face used: > > $ gvim -u NONE -c 'set guifont=PragmataPro\ 12' > $ > ** (gvim:26280): CRITICAL **: ascii_glyph_table_init: assertion > 'gui.ascii_glyphs->num_glyphs == sizeof(ascii_chars)' failed > > With this particular font all characters are messed up (screenshot > attached). > > Here's a related discussion: > https://groups.google.com/forum/#!topic/vim_dev/0sETSAwe5Wo It looks like Bram included a fix for this problem some time ago (patch 7.4.2214). Could someone confirm whether this now works as expected? Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#939446: buster-pu: package emacs/1:26.1+1-3.2
Rob Browning writes: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: buster > Severity: normal > > emacs (1:26.1+1-3.2+deb10u1) buster; urgency=medium > > * Update the EPLA packaging key (previous key expires 2019-09-23) via > the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911. Add the > old and new keyrings to debian/ and debian/source/include-binaries > since debian/patches/ can't handle git binary diffs. Thanks to Stefan > Monnier for reporting the problem and providing the patch. Just a ping -- if we want the packages be available in at least proposed-updates before the certificate expires, I imagine I might need to upload soon. Unstable and testing should now be OK as the same keyring (more or less the same patch) is in 1:26.1+1-4 which has migrated to bullseye. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#940541: maitreya: Uninstallable due to conflicting dependencies
Source: maitreya Version: 7.0.7-1+b1 Severity: grave Justification: renders package unusable Attempting to install maitreya fails for me using current unstable: $ sudo apt install maitreya Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: maitreya : Depends: libwxsqlite3-3.0-0 but it is not going to be installed E: Unable to correct problems, you have held broken packages. This situation is also currently being reported by DOSE, so doesn't appear to be specific to my machine: https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/maitreya.html#1a95d695ca0f8daa46500bfee6dc4ee7 Pasting that output here for posterity: | Package: maitreya | Scenario: unstable_main | Date: 2019-09-16 05:00:03 | | Architectures: mips64el | | Summary: conflict between libwxsqlite3-3.0-0 and maitreya | | maitreya (7.0.7-1) [PTS] [ctrl] |↓ libwxsqlite3-3.0-0 | | libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl] | maitreya (7.0.7-1) [PTS] [ctrl] | CONFLICT | | Architectures: amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x | | Summary: conflict between libwxsqlite3-3.0-0 and maitreya | | maitreya (7.0.7-1+b1) [PTS] [ctrl] |↓ libwxsqlite3-3.0-0 | | libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl] | maitreya (7.0.7-1+b1) [PTS] [ctrl] | CONFLICT Cheers, Olly
Bug#940538: /usr/bin/policyd-spf: spf policy lookup sometimes fails
reassign -1 python3-spf
It looks like this is a problem in the new pyspf release.
Thanks,
Scott K
On September 17, 2019 1:46:31 AM UTC, adm...@nayr.us wrote:
>Package: postfix-policyd-spf-python
>Version: 2.9.0-4
>Severity: normal
>File: /usr/bin/policyd-spf
>
>Dear Maintainer,
>
> Started seeing this issue on September 8th and started using
> various whitelist entries in
> /etc/postfix-policyd-spf-python/policyd-spf.conf as a
> workaround. Please let me know what other information I can provide.
>
>example syslog output:
>
>*** bug
>2019-09-16T20:27:57.499774-04:00 es postfix/smtpd[30690]: connect from
>a13-8.smtp-out.amazonses.com[54.240.13.8]
>2019-09-16T20:27:57.682675-04:00 es postfix/smtpd[30690]: Anonymous TLS
>connection established from a13-8.smtp-out.amazonses.com[54.240.13.8]:
>TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)
>2019-09-16T20:27:58.608596-04:00 es policyd-spf[30698]: Traceback (most
>recent call last):
>2019-09-16T20:27:58.609222-04:00 es policyd-spf[30698]: File
>"/usr/bin/policyd-spf", line 11, in #012
>load_entry_point('spf-engine==2.9.0', 'console_scripts',
>'policyd-spf')()
>2019-09-16T20:27:58.609793-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf_engine/policyd_spf.py", line 102,
>in main#012peruser, peruserconfigData)
>2019-09-16T20:27:58.610274-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 643, in
>_spfcheck#012mres = mfromquery.check()
>2019-09-16T20:27:58.610699-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 598, in check#012rc =
>self.check1(spf, self.d, 0)
>2019-09-16T20:27:58.611154-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012
>return self.check0(spf, recursion)
>2019-09-16T20:27:58.611679-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 922, in check0#012
>res, code, txt = self.check1(d,arg, recursion + 1)
>2019-09-16T20:27:58.612083-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012
>return self.check0(spf, recursion)
>2019-09-16T20:27:58.612486-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 920, in check0#012d =
>self.dns_spf(arg)
>2019-09-16T20:27:58.612914-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 1162, in dns_spf#012a
>= [t for t in self.dns_txt(domain) if RE_SPF.match(t)]
>2019-09-16T20:27:58.613683-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 1212, in dns_txt#012
>dns_list = self.dns(domainname, rr,ignore_void=ignore_void)
>2019-09-16T20:27:58.614286-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 1356, in dns#012for
>k, v in DNSLookup(name, qtype, self.strict, timeout):
>2019-09-16T20:27:58.615146-04:00 es policyd-spf[30698]: File
>"/usr/lib/python3/dist-packages/spf.py", line 106, in
>DNSLookup_pydns#012if strict > 1:
>2019-09-16T20:27:58.615738-04:00 es policyd-spf[30698]: NameError: name
>'strict' is not defined
>2019-09-16T20:27:58.655288-04:00 es postfix/spawn[30697]: warning:
>command /usr/bin/policyd-spf exit status 1
>2019-09-16T20:27:58.656627-04:00 es postfix/smtpd[30690]: warning:
>premature end-of-input on private/policy-spf while reading input
>attribute name
>2019-09-16T20:28:00.172352-04:00 es policyd-spf[30699]: Traceback (most
>recent call last):
>2019-09-16T20:28:00.172889-04:00 es policyd-spf[30699]: File
>"/usr/bin/policyd-spf", line 11, in #012
>load_entry_point('spf-engine==2.9.0', 'console_scripts',
>'policyd-spf')()
>2019-09-16T20:28:00.173342-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf_engine/policyd_spf.py", line 102,
>in main#012peruser, peruserconfigData)
>2019-09-16T20:28:00.173751-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 643, in
>_spfcheck#012mres = mfromquery.check()
>2019-09-16T20:28:00.174378-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf.py", line 598, in check#012rc =
>self.check1(spf, self.d, 0)
>2019-09-16T20:28:00.174836-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012
>return self.check0(spf, recursion)
>2019-09-16T20:28:00.175274-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf.py", line 922, in check0#012
>res, code, txt = self.check1(d,arg, recursion + 1)
>2019-09-16T20:28:00.175676-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012
>return self.check0(spf, recursion)
>2019-09-16T20:28:00.176209-04:00 es policyd-spf[30699]: File
>"/usr/lib/python3/dist-packages/spf.py", line 920, in check0#012d =
>self.dns_spf(arg)
>2019-09-16T20:28:00.176629-04:00 es policyd-spf[30699]: File
Bug#940540: codelite: Uninstallable due to conflicting dependencies
Source: codelite Version: 12.0+dfsg-1 Severity: grave Justification: renders package unusable Attempting to install codelite fails for me using current unstable: $ sudo apt install codelite Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: codelite : Depends: libwxsqlite3-3.0-0 but it is not going to be installed E: Unable to correct problems, you have held broken packages. This situation is also currently being reported by DOSE, so doesn't appear to be specific to my machine: https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/codelite.html#40d19c199f7ed5a33995d52151783c11 Pasting that output here for posterity: | Package: codelite | Scenario: unstable_main | Date: 2019-09-16 05:00:03 | | Architectures: amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x | | Summary: conflict between libwxsqlite3-3.0-0 and codelite | | codelite (12.0+dfsg-1) [PTS] [ctrl] |↓ libwxsqlite3-3.0-0 | | libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl] | codelite (12.0+dfsg-1) [PTS] [ctrl] | CONFLICT Cheers, Olly
Bug#940539: pdsh has obsolete home page URL
Package: pdsh Version: 2.31-3+b1 Homepage: https://computing.llnl.gov/linux/pdsh.html This gives a 404 "Page not found" error. The Homepage URL should now be https://software.llnl.gov/repo/#/chaos/pdsh, although that is little more than just a link to the github page at: https://github.com/chaos/pdsh It would be nice to have a link to the old documentation pages that used to be on the LLNL site, but I wasn't able to find a replacement for them. BTW, the version of pdsh on github is 2.33 craig -- craig sanders
Bug#935927: debian-science: migrate all python dependencies to their python3 variant
Sandro Tosi writes: > > any update here? if i dont hear anything within a week, i will raise > the severity of this bug to serious. That seems a little ahead of the curve. I'm pretty sure we're months (if not years) away from removing python2. d
Bug#940538: /usr/bin/policyd-spf: spf policy lookup sometimes fails
Package: postfix-policyd-spf-python
Version: 2.9.0-4
Severity: normal
File: /usr/bin/policyd-spf
Dear Maintainer,
Started seeing this issue on September 8th and started using
various whitelist entries in
/etc/postfix-policyd-spf-python/policyd-spf.conf as a
workaround. Please let me know what other information I can provide.
example syslog output:
*** bug
2019-09-16T20:27:57.499774-04:00 es postfix/smtpd[30690]: connect from
a13-8.smtp-out.amazonses.com[54.240.13.8]
2019-09-16T20:27:57.682675-04:00 es postfix/smtpd[30690]: Anonymous TLS
connection established from a13-8.smtp-out.amazonses.com[54.240.13.8]: TLSv1.2
with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)
2019-09-16T20:27:58.608596-04:00 es policyd-spf[30698]: Traceback (most recent
call last):
2019-09-16T20:27:58.609222-04:00 es policyd-spf[30698]: File
"/usr/bin/policyd-spf", line 11, in #012
load_entry_point('spf-engine==2.9.0', 'console_scripts', 'policyd-spf')()
2019-09-16T20:27:58.609793-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf_engine/policyd_spf.py", line 102, in
main#012peruser, peruserconfigData)
2019-09-16T20:27:58.610274-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 643, in
_spfcheck#012mres = mfromquery.check()
2019-09-16T20:27:58.610699-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 598, in check#012rc =
self.check1(spf, self.d, 0)
2019-09-16T20:27:58.611154-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012return
self.check0(spf, recursion)
2019-09-16T20:27:58.611679-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 922, in check0#012res, code,
txt = self.check1(d,arg, recursion + 1)
2019-09-16T20:27:58.612083-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012return
self.check0(spf, recursion)
2019-09-16T20:27:58.612486-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 920, in check0#012d =
self.dns_spf(arg)
2019-09-16T20:27:58.612914-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 1162, in dns_spf#012a = [t
for t in self.dns_txt(domain) if RE_SPF.match(t)]
2019-09-16T20:27:58.613683-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 1212, in dns_txt#012dns_list
= self.dns(domainname, rr,ignore_void=ignore_void)
2019-09-16T20:27:58.614286-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 1356, in dns#012for k, v in
DNSLookup(name, qtype, self.strict, timeout):
2019-09-16T20:27:58.615146-04:00 es policyd-spf[30698]: File
"/usr/lib/python3/dist-packages/spf.py", line 106, in DNSLookup_pydns#012if
strict > 1:
2019-09-16T20:27:58.615738-04:00 es policyd-spf[30698]: NameError: name
'strict' is not defined
2019-09-16T20:27:58.655288-04:00 es postfix/spawn[30697]: warning: command
/usr/bin/policyd-spf exit status 1
2019-09-16T20:27:58.656627-04:00 es postfix/smtpd[30690]: warning: premature
end-of-input on private/policy-spf while reading input attribute name
2019-09-16T20:28:00.172352-04:00 es policyd-spf[30699]: Traceback (most recent
call last):
2019-09-16T20:28:00.172889-04:00 es policyd-spf[30699]: File
"/usr/bin/policyd-spf", line 11, in #012
load_entry_point('spf-engine==2.9.0', 'console_scripts', 'policyd-spf')()
2019-09-16T20:28:00.173342-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf_engine/policyd_spf.py", line 102, in
main#012peruser, peruserconfigData)
2019-09-16T20:28:00.173751-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 643, in
_spfcheck#012mres = mfromquery.check()
2019-09-16T20:28:00.174378-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 598, in check#012rc =
self.check1(spf, self.d, 0)
2019-09-16T20:28:00.174836-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012return
self.check0(spf, recursion)
2019-09-16T20:28:00.175274-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 922, in check0#012res, code,
txt = self.check1(d,arg, recursion + 1)
2019-09-16T20:28:00.175676-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 637, in check1#012return
self.check0(spf, recursion)
2019-09-16T20:28:00.176209-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 920, in check0#012d =
self.dns_spf(arg)
2019-09-16T20:28:00.176629-04:00 es policyd-spf[30699]: File
"/usr/lib/python3/dist-packages/spf.py", line 1162, in dns_spf#012a = [t
for t in self.dns_txt(domain) if RE_SPF.match(t)]
2019-09-16T20:28:00.177045-04:00 es policyd-spf[30699]: File
Bug#940209: info desktop file is missing the additional category 'ConsoleOnly'
Hi Jörg, > Categories=Utility;Documentation;ConsoleOnly; Thanks, added to the git repo, will be in the next upload. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#940537: light-locker: Dark screen except mouse pointer after long delay & screensaver login, xfce, unstable
Package: light-locker Version: 1.8.0-3 Severity: normal Dear Maintainer, I saw several similar bug reports, but none exactly the same. Please let me know if more info' would help. * What led up to the situation? Fresh install Debian 10.1, upgrade to testing, upgrade to unstable. No non free drivers were installed. I believe it was working OK under buster and testing, but broke with unstable. * What exactly did you do (or not do) that was effective (or ineffective)? Sometimes (usually after hours of inactivity) screen display is dark except mouse pointer only, after logging into desktop. Workaround: Alt-Ctrl-Fx to TTY, login and kill lightdm process, restarts display * What was the outcome of this action? Fresh desktop available, but previously running user processes (terminal scripts, browsers, etc) are gone/dead. * What outcome did you expect instead? Login to screensaver; see previous desktop displayed and working. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages light-locker depends on: ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii libc62.29-1 ii libcairo21.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libglib2.0-0 2.60.6-2 ii libgtk-3-0 3.24.11-1 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libsystemd0 242-7 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxss1 1:1.2.3-1 ii lightdm 1.26.0-5 light-locker recommends no packages. light-locker suggests no packages. -- no debconf information
Bug#935927: debian-science: migrate all python dependencies to their python3 variant
On Mon, Sep 16, 2019 at 9:33 PM David Bremner wrote: > > Sandro Tosi writes: > > > > > any update here? if i dont hear anything within a week, i will raise > > the severity of this bug to serious. > > That seems a little ahead of the curve. I'm pretty sure we're months (if > not years) away from removing python2. not necessarily (and the sooner we start the sooner we finish). do you see any blockers in moving the dependencies of debian-science to python3? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#940461: mailscripts: please adopt imap-dl
Daniel Kahn Gillmor writes:
> Thanks for this, David.
>
> On Mon 2019-09-16 10:04:10 -0300, David Bremner wrote:
>> It looks like every message; see attached log. I haven't had a chance to
>> try the patched imap-dl
>
> It looks lke your server is indeed lying about the message size in the
> initial summary.
>
> It clearly says 41997 octets here:
>
>> command FETCH ('1:1', '(UID RFC822.SIZE)') response ['1 (UID 94515
>> RFC822.SIZE 41997)']
>> _parse_imapattrresponse() [_retrieverbases.py:1334] parsing attributes
>> response line 1 (UID 94515 RFC822.SIZE 41997)
>> _parse_imapattrresponse() [_retrieverbases.py:1357] got {'rfc822.size':
>> '41997', 'uid': '94515'}
>
> and then when you go to retrieve it, it gives you only 6294 octets:
>
>
> Can you verify the size of the actual message as delivered?
>
> stat "$(notmuch search --output=files id:87sgowo0w8@tethera.net)"
It's not either, but 6376 with is closer . I can imagine the difference is
headers added
by getmail.
>
> If this is the case, and your server lies, and getmail is just confused,
> perhaps we need to report a bug to getmail.
> b) i can make imap-dl avoid this checking based on option in the config
> file (options.ignore_size_mismatch). This makes the config file
> diverge a bit from getmail, but it looks like getmail is happy to
> ignore the extra config var.
>
> I'm leaning toward (b) -- would you be willing to set that flag in your
> config file?
I guess so, since it approximates what getmail is apparently doing
>
> But if the server lies about message size, then i don't really know how
> to calculate tranche size realistically. I suppose if the user has
> specified ignore_size_mismatch, we can do whatever we want for tranche
> sizes, but that makes me kind of sad. If i had this tranching mechanism
> in place, what would you want imap-dl to do when talking to such a lying
> server?
I dunno, but given the server is microsoft's, I doubt I'm going to be the
only one.
d
Bug#940473: dump: Verify fails when multiple extended attributes are present
On Mon, 16 Sep 2019 08:22:56 +0100, Tim Woodall writes: >This is a very longstanding, but minor, bug that I've finally got around >to reporting. I did investigate trying to fix but it appeared highly >non-trivial. tim, thanks for the note. i'll have a look at this issue as soon as i find a few spare moments. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much." -- Matt Blaze signature.asc Description: Digital Signature
Bug#940209: info desktop file is missing the additional category 'ConsoleOnly'
Hi! Today you send me a mail and asked me about the correct notation. I would like to answer now: > Currently we have: > Categories=Utility;Documentation > How should the line should look like after change? > Categories=Utility;Documentation;ConsoleOnly Exactly in this way! And please don't forget a trailing semicolon after the last category. I would like to show you the complete line again: Categories=Utility;Documentation;ConsoleOnly; If you change this entry in that way I think you will fulfill Freedesktops requirements. Thanks for you attention! -- Yours sincerely Joerg Schiermeier
Bug#940461: mailscripts: please adopt imap-dl
Thanks for this, David.
On Mon 2019-09-16 10:04:10 -0300, David Bremner wrote:
> It looks like every message; see attached log. I haven't had a chance to
> try the patched imap-dl
It looks lke your server is indeed lying about the message size in the
initial summary.
It clearly says 41997 octets here:
> command FETCH ('1:1', '(UID RFC822.SIZE)') response ['1 (UID 94515
> RFC822.SIZE 41997)']
> _parse_imapattrresponse() [_retrieverbases.py:1334] parsing attributes
> response line 1 (UID 94515 RFC822.SIZE 41997)
> _parse_imapattrresponse() [_retrieverbases.py:1357] got {'rfc822.size':
> '41997', 'uid': '94515'}
and then when you go to retrieve it, it gives you only 6294 octets:
> retrieving body for message "94515"
> _parse_imapuidcmdresponse() [_retrieverbases.py:1314] trace
> command uid FETCH ('94515', '(BODY.PEEK[])') response [('1 (BODY[] {6294}',
but then getmail claims to have delivered 41997 octets:
> msg 1/1 (41997 bytes) delivered, deleted
> 1 messages (41997 bytes) retrieved, 0 skipped
This is all very weird.
Can you verify the size of the actual message as delivered?
stat "$(notmuch search --output=files id:87sgowo0w8@tethera.net)"
If this is the case, and your server lies, and getmail is just confused,
perhaps we need to report a bug to getmail.
But more to the point here, if you want to use imap-dl i suppose we have
a few options:
a) i can make imap-dl not care about this confirmation check at all (or
maybe just warn instead of throw an exception)
b) i can make imap-dl avoid this checking based on option in the config
file (options.ignore_size_mismatch). This makes the config file
diverge a bit from getmail, but it looks like getmail is happy to
ignore the extra config var.
I'm leaning toward (b) -- would you be willing to set that flag in your
config file?
You might be wondering why imap-dl cares, given that getmail seems to
ignore the mismatch. At the moment, the size mismatch check doesn't do
anything functional.
The reason i have it in place is that i imagine that in future versions,
i'd want to try to pull down messages in batches, so that we don't have
to worry about buffering all the messages in RAM before starting to save
them to disk.
getmail's behavior is to pull messages one at a time, but this approach
adds at least one additional roundtrip to the server between messages.
If you're pulling 60 messages totalling 500KiB over a 1Mbps connection,
then the time to pull the messages due to overall bandwidth constraints
is ~4s. If round-trip latency to the server is 85ms, adding 1RTT per
message induces an extra 5s lag -- doubling the time it takes to fetch
the mailbox. Yuck! So we don't want to pull the messages one at a
time.
If we could rely on the message sizes reported from the server, then we
could retrieve messages in tranches of "reasonable" size -- enough to
not worry about RAM exhaustion, and to also be able to deliver (and if
configured, delete) some messages even if the whole list hasn't been
retrieved and deleted yet. I was thinking that a reasonable "tranche
size" would be something like 5MiB or 10MiB. You'd build tranches based
on the summary, starting with the first unfetched message, then
considering each subsequent message until it would total more than the
tranche size. Then for each tranche, retrieve the messages from that
tranche, store them locally, and expunge them if configured. Then on to
the next tranche until you've exhausted the summary.
But if the server lies about message size, then i don't really know how
to calculate tranche size realistically. I suppose if the user has
specified ignore_size_mismatch, we can do whatever we want for tranche
sizes, but that makes me kind of sad. If i had this tranching mechanism
in place, what would you want imap-dl to do when talking to such a lying
server?
--dkg
signature.asc
Description: PGP signature
Bug#940333: RFH: python-click
Hey Alexandre, On Sun, 15 Sep 2019 17:01:07 -0400 Alexandre Viau wrote: > Package: wnpp > Severity: normal > > Hello, > > I haven't had a lot of time to put into python-click lately. > > I am thinking that moving it to the python packaging team could be a > good idea. I am not familiar with the python team's processes, so that > would be without my help. id be happy to move it under the DPMT umbrella > > If you want to take over python-click, as part of a team or not, you are > welcome! want me to keep you as uploaders or you're ok with me taking over? i dont mind either way :)
Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
On 16/09/2019 10:38, Andreas Tille wrote:
Hi Peter,
On Sun, Sep 15, 2019 at 02:47:50PM +0100, peter green wrote:
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
Thanks to this hint
This hint was *wrong*, it will introduce garbage into the string and the
"rotor" code is clearly designed to work with byte strings, not unicode strings.
Change it to
"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"
Thanks a lot for your patience. Unfortunately this is not
yet the final solution:
...
Traceback (most recent call last):
File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )
File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
return self.cryptmore(buf, 0)
File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'int' and 'float'
Kind regards
Andreas.
When you get a floating point number where you were expecting an integer that
is probably an issue related to the change in behavior of the division operator
in python 3. In python 2 using the regular division operator on two integers
produces an integer result, but in python 3 it produces a floating point result.
I see a few cases in the p_rotor code where regular division is used in a way
that python2 would interpret it as floored division but python3 would interpret
it as floating point division.
|"drotor[i] = erotor[i] = 1 + 2*rand(i/2) # increment" -> |||"drotor[i] = erotor[i]
= 1 + 2*rand(i//2) # increment"
"|x = 171 * (x % 177) - 2 * (x/177)|" -> |||"x = 171 * (x % 177) - 2 *
(x//177)"
"|||y = 172 * (y % 176) - 35 * (y/176)|" -> "y = 172 * (y % 176) - 35 *
(y//176)||"
"z = 170 * (z % 178) - 63 * (z/178)" -> "z = 170 * (z % 178) - 63 * (z//178)"|
||
||
Bug#940479: pocketsphinx: please add a -doc package
Hello, Gianfranco Costamagna, le lun. 16 sept. 2019 11:47:07 +0200, a ecrit: > It would be nice to have a split doc package, like Ubuntu does, to have a > less heavy package. Thinking about this, can't we just move the doc to libpocketsphinx-dev? (since the doc is about the library, not the programs) I understand that it'll be appreciated to have a pocketsphinx package that is reduced as much as possible, but I don't think it's such a concern for libpocketsphinx-dev? I'm just meaning to save developers from installing yet another package only to get the documentation, when it's just 8MiB away. Samuel
Bug#940536: dhex: hangs on keyboard config screen
Package: dhex Version: 0.69-1 Severity: important Hi, As described the program hangs on what it looks like some keyboard configuration screen, which only can be exited by Ctrl-C. I tried also pressing ESC as advertised, but is ignored: Please press the following keys (Press ESC if your keyboard does not have them) Config file:/home/mones/.dhexrc KEYESC: The standard cancel key Nothing else can be done with it, so this is completely useless. Looking also at #889956 makes me wonder if this stuff wouldn't be better removed from the archive. regards, -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dhex depends on: ii libc62.28-10 ii libncurses6 6.1+20181013-2+deb10u1 ii libtinfo66.1+20181013-2+deb10u1 dhex recommends no packages. dhex suggests no packages. -- no debconf information
Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.
I was also affected by this and could fix the problem with: sudo apt install -t unstable libgegl-0.4-0 Best, -- Antoine Amarilli signature.asc Description: PGP signature
Bug#931568: fetchmail: Loaded OpenSSL library 0x1010103f newer than headers 0x1010101f, trying to continue.
On Sun, 07 Jul 2019 15:10:57 -0400 karl wrote: > Package: libssl1.1.1c-1 > Version: libssl1.1 > Severity: important > > > Began losing email and or attachments 5/19 with a fetchmailrc that had worked for years. > > > (fetchmail -v) > > fetchmail: Loaded OpenSSL library 0x1010103f newer than headers 0x1010101f, trying to continue. This is a warning only to notify the user that the system is inconsistently installed and the OpenSSL library loaded at run-time was newer than the OpenSSL headers on the build host. This does not mention the fetchmail version, and it appears that fetchmail wasn't rebuilt after an OpenSSL upgrade. Please check if upgrading the entire system fixes the issue, and if not, please provide further logging to show that and how fetchmail "loses mail".
Bug#940533: qemu-user-static: MasterCard in /proc/self/stat emulation causes sudo(8) to fail
On Tue, 17 Sep 2019, Thorsten Glaser wrote: > linux-user/syscall.c:open_self_stat() fills the emulated > /proc/self/stat with a lot of 0s, whereas sudo reads the > tty from it, making it fail in chroots using qemu-user-static. The weird thing is that /proc/$$/stat a.k.a. $(readlink /proc/self)/stat is correct… > Workaround: use sudo -S It ought to be still fixed ☻ bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#888073: glibc: Support amd64 systems without /lib64
Javier Serrano Polo, le lun. 16 sept. 2019 23:55:24 +0200, a ecrit: > El dl 16 de 09 de 2019 a les 22:53 +0200, Samuel Thibault va escriure: > > How can it start without its interpreter in /lib64? > > This is explained in the report. Ok, now I remember that discussion (from one year ago...). It seems I should just have ignored the mail you sent today, since everything was already discussed. Samuel
Bug#940535: python-pybadges: d/copyright issues
Source: python-pybadges Version: 2.0.2-1 Hello, I found two issues in d/copyright when reviewing this package in NEW: - the copyright years for Pybadge authors should include 2019 (see twine_upload.sh) - the `License: Apache-2` is said to apply to the debian/ directory, but the contents of that stanza includes the line "Copyright 2019 The pybadge Authors", which is probably not correct. -- Sean Whitton signature.asc Description: PGP signature
Bug#940534: python-django-waffle: incorrect upstream copyright years
Source: python-django-waffle Version: 0.16.0-1 Hello, Per docs/conf.py, upstream copyright years should be 2012-2019. -- Sean Whitton signature.asc Description: PGP signature
Bug#940335: RFA: golang-github-andreyvit-diff
Hello Alexandre, > I'd like to find new maintainers for some of my packages because I have > had less time for Debian. I'd like to focus the small amount of time > that I have for Debian on other things. Thanks for being honest about the time you can spend on Debian, it's always hard to let things go, in particular when you spent quite some time to build them. > For now, I intend to do my best to keep maintaining this package. > However, I will probably retitle this bug with the 'O:' prefix at some > point, indicating that I have orphaned it. thanks for opening the WNPP bugs; sadly, you did not use the correct format for their subject, which is: TAG: -- this breaks quite a few scripts, and tent to provide fewer information for potential adopters. Could you please retitle them following this format? thanks, Sandro
Bug#940533: qemu-user-static: MasterCard in /proc/self/stat emulation causes sudo(8) to fail
Package: qemu-user-static Version: 1:4.1-1+b1 Severity: important linux-user/syscall.c:open_self_stat() fills the emulated /proc/self/stat with a lot of 0s, whereas sudo reads the tty from it, making it fail in chroots using qemu-user-static. Workaround: use sudo -S -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) qemu-user-static:i386 depends on no packages. Versions of packages qemu-user-static:i386 recommends: ii binfmt-support 2.2.0-2 Versions of packages qemu-user-static:i386 suggests: ii sudo 1.8.27-1 -- no debconf information
Bug#940532: reportbug: another Multi-Arch issue
Package: reportbug Version: 7.5.3 Severity: minor The library issue got probably fixed, but there’s another issue for when a package is only installed for a foreign architecture: tglase@tglase:~ $ dpkg --print-architecture x32 tglase@tglase:~ $ dpkg --print-foreign-architectures i386 amd64 tglase@tglase:~ $ dpkg-query -W | fgrep qemu-user-static qemu-user-static:i386 1:4.1-1+b1 If I reportbug without M-A qualifier, I get an error: tglase@tglase:~ $ reportbug qemu-user-static (reportbug:18235): dbind-WARNING **: 00:26:57.237: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Thorsten Glaser ' as your from address. Getting status for qemu-user-static... Verifying package integrity... There may be a problem with your installation of qemu-user-static; the following problems were detected by debsums: debsums: package qemu-user-static is not installed Do you still want to file a report [y|N|q|?]? n Package integrity check failed; stopping. If I reportbug *with* M-A qualifier, things work, but I get a warning: 1|tglase@tglase:~ $ reportbug qemu-user-static:i386 (reportbug:18257): dbind-WARNING **: 00:27:11.600: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Thorsten Glaser ' as your from address. Getting status for qemu-user-static:i386... Verifying package integrity... Checking for newer versions at madison, incoming.debian.org and http://ftp-master.debian.org/new.html W: Unable to locate package qemu-user-static:i386 Will send report to Debian (per lsb_release). Querying Debian BTS for reports on qemu (source)... 185 bug reports found: […] -- Package-specific info: ** Environment settings: EDITOR="/usr/bin/sensible-editor" VISUAL="/usr/bin/jupp" DEBEMAIL="Thorsten Glaser " INTERFACE="text" ** /home/tglase/.reportbugrc: reportbug_version "6.6.6" mode advanced ui text -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages reportbug depends on: ii apt1.8.3 ii python33.7.3-1 ii python3-reportbug 7.5.3 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf-utils 1.5.73 ii debsums 2.2.3 pn dlocate pn emacs-bin-common ii file1:5.37-5 ii gnupg 2.2.17-3 ii postfix [mail-transport-agent] 3.4.5-1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.8.3 ii file 1:5.37-5 ii python33.7.3-1 ii python3-apt1.8.4 ii python3-debian 0.1.36 ii python3-debianbts 2.8.2 ii python3-requests 2.21.0-1 ii sensible-utils 0.0.12 python3-reportbug suggests no packages. -- no debconf information
Bug#940531: ubuntu-dev-tools: Please drop bzr from Recommends: to Suggests:
Package: ubuntu-dev-tools Version: 0.173 Severity: normal As part of the python2 removal effort, bzr is going away to be replaced by brz. Currently u-d-t Recommends: bzr, which will be a problem once it is gone. I reviewed the scripts that use bzr and they are either obsolete (relate to the old Ubuntu bzr branch for every package scheme), would only be used by someone who knows better (Ubuntu archive admin), or use alternate mechanisms if bzr is not installed. Even if bzr weren't being removed, I think Suggests would be more appropriate now, but definitely since it's going away. Scott K
Bug#940530: Add CONFIG_BRCMFMAC_SDIO=y to linux-image-rpi
Package: linux-image-4.19.0-6-rpi Version: 4.19.67-2 The linux-image-rpi kernel for armel does not include CONFIG_BRCMFMAC_SDIO=y. This config option is necessary to support the WiFi on the Raspberry Pi Zero W. I have verified that enabling this option fixes the problem on my Pi Zero W by building a version of the kernel package with the option enabled following https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage. I installed Debian using the images available here: https://wiki.debian.org/RaspberryPiImages
Bug#894663: transition: wxwidgets3.0
On Mon, Sep 16, 2019 at 09:25:54AM -0400, Scott Talbert wrote: > On Mon, 16 Sep 2019, Gunter Königsmann wrote: > > That only partially answers my question. Currently I am playing with the > > thought if the right idea would be uploading a wxMaxima version that > > uses GTK3 to debian testing and looking if anyone except Vadim and me is > > affected by the bug. Note you don't upload to testing - you upload to unstable, and then the package migrates to testing. I think this is probably a good idea. It seems there's something system dependent here since wxmaxima rebuilt to use GTK3 doesn't seem to flicker when scrolling horizontally or vertically to me, and so allowing easy wider testing would be helpful in trying to work out what's going on. > Well, the only thing we can control is that the GTK2 build of wx will be > gone in Bullseye, barring any unforseen circumstances. Whether that will be > with wx 3.0 or wx 3.2, remains to be seen. At this point the wxwidgets3.0-gtk3 transition is reporting 54% done: https://release.debian.org/transitions/ There's also one bug tagged "pending" and two packages uploaded to "experimental", so effectively 57% if you include stuff that's in progress (there are about 100 packages involved in all). I think even if wx 3.2 does come out soon we'd really want to get the current transition completed first. Having to deal with 3 wx variants at once sounds like more pain than necessary, and if we get the GTK2->GTK3 issues dealt with now then that's less to deal with in the second transition. Cheers, Olly
Bug#888073: glibc: Support amd64 systems without /lib64
El dl 16 de 09 de 2019 a les 22:53 +0200, Samuel Thibault va escriure: > How can it start without its interpreter in /lib64? This is explained in the report. It uses an "ugly solution" that happens to be the only way for a regular user to override interpreters, as far as I know. > What does > ldd ./true print? linux-vdso.so.1 (0x7ffddd5a2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c935f4000) /lib64/ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x7f8c93b9a000) smime.p7s Description: S/MIME cryptographic signature
Bug#935927: debian-science: migrate all python dependencies to their python3 variant
> Source: debian-science > Severity: important > > Hello, > many of the packages on this set refer to python packages. Theres an effort > on-going to remove Python 2 for Bullseye, > https://wiki.debian.org/Python/2Removal . > > It would be great if you could migrate all the python dependencies here into > their python3 correspondent ones. > > This will "free" packages from being reverse dependencies of debian-science > deps > packages, hence they could ideally be removed (once we figure out the > remaining rdeps). > > Given the high number of python deps from debian-science, it would be awesome > if > you could tackle this sooner rather than later. > > Let me know if i could help (ideally porting some of the deps to python3). any update here? if i dont hear anything within a week, i will raise the severity of this bug to serious. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#687288: Working as intended
This bug should probably be closed. The default cpio format doesn't support
>2GiB files. Some other formats only support 4GiB, and the file in this
report is >4GiB.
See:
https://en.wikipedia.org/wiki/Cpio#POSIX_standardization
https://www.systutorials.com/docs/linux/man/1-cpio/
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.se " };
char kernel[]= { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
Bug#940529: apt: Apt Fails to Handle Dependencies for Necessary Video Support
Package: apt Version: 1.8.2 Severity: critical Tags: upstream Justification: breaks the whole system Dell Studio XPS $nvidia-detect Detected NVIDIA GPUs: 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 [GeForce 9400M G] [10de:0866] (rev b1) Checking card: NVIDIA Corporation C79 [GeForce 9400M G] (rev b1) Your card is only supported up to the 340 legacy drivers series. It is recommended to install the nvidia-legacy-340xx-driver package. When attempting to install the package, the error messages are: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: nvidia-legacy-340xx-driver : PreDepends: nvidia-installer-cleanup but it is not installable Depends: nvidia-legacy-340xx-driver-libs (= 340.107-4) but it is not going to be installed Depends: nvidia-legacy-340xx-driver-bin (= 340.107-4) but it is not going to be installed Depends: xserver-xorg-video-nvidia-legacy-340xx (= 340.107-4) but it is not going to be installed Depends: nvidia-legacy-340xx-vdpau-driver (= 340.107-4) but it is not going to be installed Depends: nvidia-legacy-340xx-alternative (= 340.107-4) but it is not going to be installed Depends: nvidia-legacy-340xx-kernel-dkms (= 340.107-4) but it is not going to be installed or nvidia-legacy-340xx-kernel-340.107 Depends: nvidia-support but it is not installable Recommends: nvidia-settings-legacy-340xx but it is not installable Recommends: nvidia-persistenced but it is not installable E: Unable to correct problems, you have held broken packages. These leads to system becoming unviewable during attempt at resolution change. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "true"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.17\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-6-amd64$"; APT::VersionedKernelPackages "";
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
On Mon, Sep 16, 2019 at 10:12:09PM +0200, Gunter Königsmann wrote: > On 15.09.19 23:24, Olly Betts wrote: > > The upstream bug has been closed as invalid - the problem here is > > incorrect use of the wxWidgets API - Clear() uses the brush used by > > SetBackground() not the brush set by SetBrush(). Therefore I'm closing > > this bug as invalid too. > > > > Gunter: You'll need to fix the code in wxmaxima to call SetBackground() > > with the brush you want Clear() to use. > > wxMaxima already did use SetBackground() when it used Clear(). I don't > know if the GTK version debian uses or in the wxWidgets version debian > ships is the cause for this not to helo. > > The current release of wxMxima no more uses Clear() on GTK3. My program > therefore no more is affected by the bug. Therefore won't object against > closing the bug. But chances are high that other projects are still > affected. Upstream closed the bug based on the patch you sent to the list, which was invalid in the way I describe: https://trac.wxwidgets.org/ticket/18463#comment:4 Independently, I had previously tried to reproduce based on just your description, and was unable to. Maybe there is still a bug here, but if so you really need to provide a valid reduced testcase to demonstrate it: https://trac.wxwidgets.org/wiki/HowToSubmitTicket#ReproducingtheProblem Given such a way to reproduce a bug, upstream have a very good track record for resolving it, but bug reports that require someone to try to reproduce the situation from a description tend to just languish (upstream already have nearly 2000 open tickets, most of which have no clear way to reproduce provided). So if you want to get a wx bug fixed, the key thing is to provide a reduced way to reproduce it, ideally as a patch against one of the samples. Cheers, Olly
Bug#940528: debian-installer: B43 Firmware Not Found or Installed
Package: debian-installer Version: Buster 10 Severity: normal Tags: d-i The following notes a number of installer problems. I attempted to install Buster on Dell Studio XPS with debian- live-10.1.0-amd64-xfce+non-free. During install there is a notice of a need for B43 firmware. But while the firmware is supposed to be included, the installer cannot find it. Worse, when swapping out the flash drive for another with the firmware directory on it, it still cannot see it and cannot come back from the original installer drive is reinserted. Currently, the connection to the network is slow to connect. It is assumed that it is because of this reason. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN 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
Bug#888073: glibc: Support amd64 systems without /lib64
Javier Serrano Polo, le lun. 16 sept. 2019 21:52:31 +0200, a ecrit: > El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure: > > Can you run the attached program? > > Yes, I can. It looks like the program is true from GNU coreutils 8.28. How can it start without its interpreter in /lib64? What does ldd ./true print? Samuel
Bug#940527: schleuder: should error out if argument provided to 'refresh_keys' is no list
Package: schleuder Version: 3.4.0-1 Forwarded: https://0xacab.org/schleuder/schleuder/merge_requests/296 Tags: fixed-upstream buster If the argument to schleuder refresh-keys is an email address to which no list exists, up to now nothing happend, as if the job ran successfully. A fix was released upstream.
Bug#932882: Migration to testing blocked
Hi, Even though this bug is fixed in pyroute2/0.5.4-2, migration to testing is still blocked supposedly because of this bug. I *guess* it's because it is assigned to python-pyroute2 and python3-pyroute2 packages from which only one exists in fixed version. Latest python-pyroute2 exists only in buggy version and it confuses bts. But that's only my guess... Following advice got on #debian-ftp, I added sid tag, not sure if that will help. Any other ideas? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature
Bug#894663: transition: wxwidgets3.0
On Mon, 16 Sep 2019, Gunter Königsmann wrote: I can try to bisect wxWidgets. But as building wxWidgets drains my battery in minutes I will be able to do at maximum one step per week. You can only charge your battery once a week? If you're really strapped for compile resources, you can probably use some of the debian porter boxes? Scott
Bug#940526: schleuder: vulnerable to signature-flooded keys
Package: schleuder Version: 3.4.0-1 Forwarded: https://0xacab.org/schleuder/schleuder/merge_requests/291 Tags: fixed-upstream buster Schleuder is vulnerable to signature-flooded keys. GPG does not cope well with these keys. It will either refuse to import them, or during and after the import become so slow to be effectively unusable (while hogging CPUs). This is a potential problem for Schleuder lists, because Schleuder by default regularly updates keys from the keyservers (in order to receive extended expiry dates, or key revocations). Any list with an attacked key in its keyring will become practically unusable and strain the server. It was decided upstream to drop third-party signatures on keys, before importing the key into the keyring of the list. These signatures are not really important, interesting or relevant in the context of Schleuder.
Bug#940524: schleuder: fails to recognize keywords in mails with protected headers and empty subject
Package: schleuder Version: 3.4.0-1 Forwarded: https://0xacab.org/schleuder/schleuder/issues/431 Tags: fixed-upstream buster Schleuder fails to recognize keywords in mails with protected headers and empty subject. A fix was released upstream.
Bug#940525: gimp: segfault on start
Package: gimp
Version: 2.10.8-2+b1
Severity: grave
Tags: upstream
Justification: renders package unusable
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-
gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror --with-
arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-
driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-
gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)
using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: Segmentation fault
Stack trace:
```
# Stack traces obtained from PID 18793 - Thread 18793 #
[New LWP 18797]
[New LWP 18798]
[New LWP 18802]
[New LWP 18803]
[New LWP 18804]
[New LWP 18805]
[New LWP 18806]
[New LWP 18960]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffd75660d50, fd=19) at
../sysdeps/unix/sysv/linux/read.c:26
Id Target Id Frame
* 1Thread 0x7fa3125f0e00 (LWP 18793) "gimp-2.10" __libc_read
(nbytes=256, buf=0x7ffd75660d50, fd=19) at ../sysdeps/unix/sysv/linux/read.c:26
2Thread 0x7fa30f1a4700 (LWP 18797) "gmain" 0x7fa31434cedf in
__GI___poll (fds=0x55d59fcc3ec0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
3Thread 0x7fa30f9a5700 (LWP 18798) "gdbus" 0x7fa31434cedf in
__GI___poll (fds=0x55d59fcdb8c0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
4Thread 0x7fa2f4ffd700 (LWP 18802) "async" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
5Thread 0x7fa2f47fc700 (LWP 18803) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
6Thread 0x7fa2f3ffb700 (LWP 18804) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
7Thread 0x7fa2f37fa700 (LWP 18805) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
8Thread 0x7fa2f2ff9700 (LWP 18806) "pool-gimp-2.10" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
9Thread 0x7fa2f2698700 (LWP 18960) "swap writer"syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
Thread 9 (Thread 0x7fa2f2698700 (LWP 18960)):
#0 0x7fa314352279 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7fa31462395f in g_cond_wait () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2 0x7fa314ace0cd in () at /lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3 0x7fa31460189d in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7fa314427fb7 in start_thread (arg=) at
pthread_create.c:486
ret =
pd =
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140337828431616,
-6741646124569055617, 140726573074750, 140726573074751, 140337828431616,
140337828428032, 6716336281706311295, 6716824267332660863}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call =
#5 0x7fa31435749f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 8 (Thread 0x7fa2f2ff9700 (LWP 18806)):
#0 0x7fa314352279 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7fa314623a7f in g_cond_wait_until () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2 0x7fa3145aa0c1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7fa3145aa681 in g_async_queue_timeout_pop () at /lib/x86_64-linux-
Bug#894663: transition: wxwidgets3.0
I can try to bisect wxWidgets. But as building wxWidgets drains my battery in minutes I will be able to do at maximum one step per week. Kind regards, Gunter. On 14.09.19 21:31, Scott Talbert wrote: > On Sat, 14 Sep 2019, Gunter Königsmann wrote: > >> * Scroll Wheels and Two-Finger scroll are broken in this >> combination, if >> Wayland is used (934386) and > > Is two finger scrolling really a high priority issue? It seems like a > nice to have rather than a must-have IMHO. > >> * If a horizontal scrollbar is visible all custom controls (e.G. >> wxMaxima's worksheet) flicker badly (934386) > > On this issue, I'm not convinced that upstream can reproduce it, based > on the comments in the ticket. I don't think that I've reproduced it > either. Since you claim that it doesn't occur with wx 3.1, can you do > a bisection between wx 3.0 and 3.1 to determine which commit fixed > it? If we can figure that out, we can backport the patches. > >> If wxMaxima otherwise would be dropped from debian I am willing to >> switch >> to a flickering version that uses GTK3. But if I don't occur this risk I >> would rather stay at GTK3 until wxGTK 3.2 is released - which will >> fix this >> issue. The wxWidgets maintainers told me that wxGTK 3.2 will be released >> "soon". But the same was true a year ago - which I normally would be >> fine >> with: wxGTK 3.1 works fine, the combination of wxGTK 3.0 and GTK2 works >> fine, too - and it is wise to release a library when it is ready, not >> according to an arbitrary schedule. > > Well, there is still time to fix the issues - Bullseye release is > still a long way off. > > And yes, upstream wx claims that wx 3.2 will be "soon" but we have > heard that for a long time. :) So I don't think we can depend on that. > > Scott
Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research
I've just started looking at lean. One of the issues around packaging it is that different lean "scripts" (not sure the correct word here) require different versions of lean. There is a script available which downloads the required version of lean for any particular script, and so keeps a local set of lean versions. If we were to package lean for Debian, what exactly would we package? The current stable version, or a script such as this? See https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md for a little more on this. Thoughts would be appreciated! Best wishes, Julian
Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland
On 16.09.19 01:13, Olly Betts wrote: > On Sat, Sep 14, 2019 at 06:47:10PM +0200, Gunter Königsmann wrote: >>> With GTK3 you can probably work around this by forcing X11, e.g.: >>> >>> env GDK_BACKEND=x11 /usr/bin/app >> For many applications that might be a valuable hint. But it causes >> hideous flicker, due to >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934386. > If you insist on conflating all your bugs into one big bug ball that > just makes it more difficult to investigate, so it's less likely anyone > can help you solve any of them. > > Ignoring other issues for now, does my suggestion actually address > *THIS* bug? In other words, if run as above, does two-finger touchpad > scrolling work? If you set GDK_BACKEND=x11 the scrolling bug disappears, which is why I told that your hint normally would be an excellent idea. But I wanted to make sure that this bug is not closed because there is a workaround as using the workaround triggers other bugs in other places. Kind regards, Guner.
Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time
Control: affects -1 src:python-django-bootstrap-form Control: affects -1 src:python-semantic-version Control: affects -1 src:django-modeltranslation Control: affects -1 src:django-reversion Control: affects -1 src:python-aws-xray-sdk Control: affects -1 bcfg2-web Hi, How is progress here? I failed to spot recent activity, but I may have missed it. Paul paul@testavoira ~ $ reverse-depends python-django -r testing -b Reverse-Build-Depends-Indep === * python-django-bootstrap-form * python-semantic-version Reverse-Build-Depends = * django-modeltranslation * django-picklefield * django-reversion * python-aws-xray-sdk paul@testavoira ~ $ reverse-depends python-django -r testing Reverse-Depends === * bcfg2-web * python-bootstrapform * python-django-modeltranslation * python-django-pagination * python-django-picklefield * python-django-reversion Packages without architectures listed are reverse-dependencies in: amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x signature.asc Description: OpenPGP digital signature
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
On 15.09.19 23:24, Olly Betts wrote: > On Mon, Aug 12, 2019 at 05:44:11AM +0100, Olly Betts wrote: >> On Sun, Aug 11, 2019 at 11:18:11PM -0400, Scott Talbert wrote: >>> On Sun, 11 Aug 2019, Olly Betts wrote: So I'm afraid I don't seem to be able to reproduce your problem. Please can you come up with a small reproducer (upstream like a patch against one of their samples) and file a bug upstream? >>> Gunter did file a bug upstream: >>> https://trac.wxwidgets.org/ticket/18463 >> If you file an upstream bug too, please mark the Debian bug as forwarded >> to it, or if you don't know how, at least mention the upstream bug. >> Otherwise you have us wasting effort, which is rather disrespectful of >> our time. > The upstream bug has been closed as invalid - the problem here is > incorrect use of the wxWidgets API - Clear() uses the brush used by > SetBackground() not the brush set by SetBrush(). Therefore I'm closing > this bug as invalid too. > > Gunter: You'll need to fix the code in wxmaxima to call SetBackground() > with the brush you want Clear() to use. wxMaxima already did use SetBackground() when it used Clear(). I don't know if the GTK version debian uses or in the wxWidgets version debian ships is the cause for this not to helo. The current release of wxMxima no more uses Clear() on GTK3. My program therefore no more is affected by the bug. Therefore won't object against closing the bug. But chances are high that other projects are still affected. Kind regards, Gunter.
Bug#888073: glibc: Support amd64 systems without /lib64
El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure: > Can you run the attached program? Yes, I can. It looks like the program is true from GNU coreutils 8.28. smime.p7s Description: S/MIME cryptographic signature
Bug#940523: gnuradio: No jack support in Audio Sink
Package: gnuradio Version: 3.8.0.0-5 Severity: normal Dear Maintainer, Any attempt of using jack via Audio Sink block ends up with a message: Could not find audio architecture "audio_jack" in registry. Defaulting to the first available architecture... gr::log :INFO: audio source - Audio sink arch: alsa The change of default architecture was attepmted by putting into ~/.gnuradio/config.conf or /etc/gnuradio/conf.d/gr-audio.conf the following: [audio] audio_module = jack Gnuradio has to be compiled from source, if one wishes to output its audio to jack, which - I think - can be very useful. Best regards, Grzegorz -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (600, 'unstable'), (10, 'oldoldstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnuradio depends on: ii libboost-program-options1.67.0 1.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libboost-thread1.67.0 1.67.0-13 ii libc6 2.29-1 ii libcanberra-gtk-module 0.30-7 ii libcanberra-gtk3-module 0.30-7 ii libcodec2-0.8.1 0.8.1-2 ii libgcc1 1:9.2.1-8 ii libgnuradio-analog3.8.0 3.8.0.0-5 ii libgnuradio-audio3.8.0 3.8.0.0-5 ii libgnuradio-blocks3.8.0 3.8.0.0-5 ii libgnuradio-channels3.8.0 3.8.0.0-5 ii libgnuradio-digital3.8.03.8.0.0-5 ii libgnuradio-dtv3.8.03.8.0.0-5 ii libgnuradio-fec3.8.03.8.0.0-5 ii libgnuradio-fft3.8.03.8.0.0-5 ii libgnuradio-filter3.8.0 3.8.0.0-5 ii libgnuradio-pmt3.8.03.8.0.0-5 ii libgnuradio-qtgui3.8.0 3.8.0.0-5 ii libgnuradio-runtime3.8.03.8.0.0-5 ii libgnuradio-trellis3.8.03.8.0.0-5 ii libgnuradio-uhd3.8.03.8.0.0-5 ii libgnuradio-video-sdl3.8.0 3.8.0.0-5 ii libgnuradio-vocoder3.8.03.8.0.0-5 ii libgnuradio-wavelet3.8.03.8.0.0-5 ii libgnuradio-zeromq3.8.0 3.8.0.0-5 ii liblog4cpp5v5 1.1.3-1 ii libpython3.73.7.4-4 ii libqt5core5a5.11.3+dfsg1-4 ii libqt5widgets5 5.11.3+dfsg1-4 ii libstdc++6 9.2.1-8 ii libuhd3.14.13.14.1.0-2 ii libvolk2-bin2.0.0-2 ii python3 3.7.3-1 ii python3-click 7.0-1 ii python3-click-plugins 1.1.1-2 ii python3-gi 3.34.0-1 ii python3-gi-cairo3.34.0-1 ii python3-lxml4.4.1-1 ii python3-mako1.0.7+ds1-1 ii python3-numpy 1:1.16.5-1 ii python3-opengl 3.1.0+dfsg-2 ii python3-pyqt5 5.12.3+dfsg-2 ii python3-pyqtgraph 0.10.0-4 ii python3-sip 4.19.18+dfsg-1 ii python3-yaml5.1.2-1 ii python3-zmq 17.1.2-3 Versions of packages gnuradio recommends: ii gnuradio-dev3.8.0.0-5 ii python3-matplotlib 3.0.2-2+b1 ii python3-networkx2.2-1 pn python3-qwt-qt5 ii python3-scipy 1.2.2-7 ii rtl-sdr 0.6-2 ii uhd-host3.14.1.0-2 Versions of packages gnuradio suggests: ii gr-fosphor 3.8~1.278b66e-2 ii gr-osmosdr 0.1.4-15 -- Configuration Files: /etc/gnuradio/conf.d/gr-audio.conf changed: [audio] audio_module = jack /etc/gnuradio/conf.d/grc.conf changed: [grc] global_blocks_path = /usr/local/share/gnuradio/grc/blocks:/usr/share/gnuradio/grc/blocks local_blocks_path = /usr/local/share/gnuradio/grc/blocks default_flow_graph = xterm_executable = canvas_font_size = 8 canvas_default_size = 1280, 1024 /etc/gnuradio/conf.d/modtool.conf changed: [modtool] newmod_path = /usr/local/share/gnuradio/modtool/templates/gr-newmod -- no debconf information
Bug#939738: buster-pu: package aegisub/3.2.2+dfsg-4+deb10u1
I've just realized that before uploading to pu the bug has to be fixed in unstable. I'll do it soon, hopefully this week. I'll send a new reply after the upload. Aniol
Bug#940309: tmux: Random segfaults
Dear Maintainer,
just in case it may be of any help.
I guess the dmesg line points to function screen_write_collect_end
in screen-write.c:1240.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2019-09-16
apt update
apt dist-upgrade
# testing -> unstable
apt update
apt dist-upgrade
reboot
apt install systemd-coredump fakeroot gdb tmux tmux-dbgsym
apt build-dep tmux
mkdir /home/benutzer/source/tmux/orig -p
cd/home/benutzer/source/tmux/orig
apt source tmux
cd
tmux
gdb -q --pid $(pidof tmux)
set width 0
set pagination off
directory /home/benutzer/source/tmux/orig/tmux-2.9a
info target
...
0x55d3db9adc80 - 0x55d3dba0c921 is .text
...
# [173131.642703] Code: 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c
48 c1 e0 04 48 03 47 18 bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 <48> 89
2a 48 8d 95 30 01 00 00 48 89 50 08 e8 79 55 02 00 8b 55 08
# 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c 48 c1 e0 04 48 03 47 18
bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 48 89 2a 48 8d 95 30 01 00 00
48 89 50 08 e8 79 55 02 00 8b 55 08
# 0x48, 0xc7, 0x85, 0x30, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x89, 0x45,
0x00, 0x41, 0x8b, 0x47, 0x1c, 0x48, 0xc1, 0xe0, 0x04, 0x48, 0x03, 0x47, 0x18,
0xbf, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x50, 0x08, 0x48, 0x89, 0x95, 0x38,
0x01, 0x00, 0x00, 0x48, 0x89, 0x2a, 0x48, 0x8d, 0x95, 0x30, 0x01, 0x00, 0x00,
0x48, 0x89, 0x50, 0x08, 0xe8, 0x79, 0x55, 0x02, 0x00, 0x8b, 0x55, 0x08
(gdb) find /b 0x55d3db9adc80, 0x55d3dba0c921, 0x48, 0xc7, 0x85, 0x30,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x89, 0x45, 0x00, 0x41, 0x8b, 0x47,
0x1c, 0x48, 0xc1, 0xe0, 0x04, 0x48, 0x03, 0x47, 0x18, 0xbf, 0x01, 0x00, 0x00,
0x00, 0x48, 0x8b, 0x50, 0x08, 0x48, 0x89, 0x95, 0x38, 0x01, 0x00, 0x00, 0x48,
0x89, 0x2a, 0x48, 0x8d, 0x95, 0x30, 0x01, 0x00, 0x00, 0x48, 0x89, 0x50, 0x08,
0xe8, 0x79, 0x55, 0x02, 0x00, 0x8b, 0x55, 0x08
0x55d3db9e417a
1 pattern found.
(gdb) print/x 0x55d3db9e417a + 42
$1 = 0x55d3db9e41a4
(gdb) b *0x55d3db9e41a4
Breakpoint 1 at 0x55d3db9e41a4: file screen-write.c, line 1240.
(gdb) info break
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x55d3db9e41a4 in screen_write_collect_end
at screen-write.c:1240
(gdb) list screen-write.c:1240
1235if (ci->used == 0)
1236return;
1237ci->data[ci->used] = '\0';
1238
1239ci->x = s->cx;
1240TAILQ_INSERT_TAIL(>list[s->cy].items, ci, entry);
1241ctx->item = xcalloc(1, sizeof *ctx->item);
1242
1243log_debug("%s: %u %s (at %u,%u)", __func__, ci->used, ci->data,
s->cx,
1244s->cy);
(gdb) print/x $rdx
$2 = 0x55d3dd642800
(gdb) print ctx->list[1]
$3 = {items = {tqh_first = 0x0, tqh_last = 0x55d3dd642800}}
(gdb) print ctx->s->cy
$4 = 1
Bug#940220: postgresql-common: pg_ctlcluster segfault
I just deployed updates to a small fleet of mostly-identical machines and this issue (pg_ scripts enter a recursive loop and consume all available memory) happened on just one of them. Went through the usual remove & purge and reinstall and the issue persisted. Turned out that I had an old Postgres directory in /usr/lib/postgresql (/usr/lib/postgresql/9.4-bak). Once I removed this and reinstalled (removed, purged, installed) all the postgresql packages, no problems! I was then able to recreate the cluster, reload data, everything works normally. Seems something in PgCommon.pm's get_versions function didn't like /usr/lib/postgresql/9.4-bak existing. Maybe this helps you, Andrej. Regards, Bryce Chidester bryce.chides...@calyptix.com Calyptix Security
Bug#700633: Debootstrap is very slow. Please use eatmydata to fix this.
Version: 1.0.115 Hi everyone, I’m appalled that this feature request is still open… I’ve got a need to do this without patching debootstrap, and have had success (although I did not time it, but someone else can ;-) with this sequence of commands (assuming dpkg-deb is available ― which my script checks earlier): safe_PATH=/bin:/sbin:/usr/bin:/usr/sbin # […] case $TERM in (Eterm|Eterm-color|ansi|cons25|cons25-debian|cygwin|dumb|hurd|linux|mach|mach-bold|mach-color|mach-gnu|mach-gnu-color|pcansi|rxvt|rxvt-basic|rxvt-m|rxvt-unicode|rxvt-unicode-256color|screen|screen-256color|screen-256color-bce|screen-bce|screen-s|screen-w|screen.xterm-256color|sun|vt100|vt102|vt220|vt52|wsvt25|wsvt25m|xterm|xterm-256color|xterm-color|xterm-debian|xterm-mono|xterm-r5|xterm-r6|xterm-vt220|xterm-xfree86) # list from ncurses-base (6.1+20181013-2+deb10u1) ;; (screen.*|screen-*) # aliases possibly from ncurses-term TERM=screen ;; (rxvt.*|rxvt-*) # let’s hope… TERM=rxvt ;; (xterm.*|xterm-*) # …this works… TERM=xterm ;; (linux.*) # …probably TERM=linux ;; (*) die "Your terminal type '$TERM' is not supported by ncurses-base." \ 'Maybe run this script in GNU screen?' ;; esac # […] eatmydata debootstrap --arch=arm64 --include=eatmydata --no-merged-usr \ --force-check-gpg --verbose --foreign buster "$mpt" \ http://deb.debian.org/debian sid # script specified here as it’s normally what buster symlinks to, # to achieve compatibility with more host distros # we need this early ( set -e cd "$mpt" for archive in var/cache/apt/archives/*eatmydata*.deb; do dpkg-deb --fsys-tarfile "$archive" >a tar -xkf a done rm -f a ) || die 'failure extracting eatmydata early' # the user can delete this later, from the booted system (or apt will) cp /usr/bin/qemu-aarch64-static "$mpt/usr/bin/" || die 'cp failed' echo >&2 'I: second stage bootstrap (under emulation), slooow…' mount -t tmpfs swap "$mpt/dev/shm" || die 'mount /dev/shm failed' mount -t proc proc "$mpt/proc" || die 'mount /proc failed' mount -t tmpfs swap "$mpt/tmp" || die 'mount /tmp failed' chroot "$mpt" /usr/bin/env -i LC_ALL=C.UTF-8 HOME=/root PATH="$safe_PATH" \ TERM="$TERM" /usr/bin/eatmydata /debootstrap/debootstrap --second-stage || \ die 'debootstrap (second stage) failed' Of course, “success” here means it does not error out… ☻ (also, as it’s run under emulation it’s very slooow anyway…) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#940520: RFP: puppet-prometheus-reporter -- Puppet reports Prometheus exporter
Package: wnpp Severity: wishlist * Package name: puppet-prometheus-reporter Version : 0.3.1 Upstream Author : bastelfreak * URL : https://github.com/voxpupuli/puppet-prometheus_reporter/ * License : Apache 2.0 Programming Lang: Ruby Description : Puppet reports Prometheus exporter This module contains a Puppet reports processor that writes report metrics in a format that is accepted by Prometheus node_exporter Textfile Collector. This package is useful to expose internal Puppet master metrics to the Prometheus monitoring engine. There is, as far as I know, no equivalent in Prometheus or Puppet. I am not using it yet, but would love to. I am not sure I will have time to do the packaging (hence the RFP) and it should probably be packaged by the Puppet team (in cc).
Bug#940505: pure-ftpd: TLS 1.3 support broken
On 9/16/19 3:53 PM, Thomas Deutschmann wrote: > Source: pure-ftpd > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > > please consider disabling TLS 1.3 support. > > While you added TLS 1.3 compatibility through bug 918630, this uncovered > a grave bug in pure-ftpd, see https://github.com/jedisct1/pure-ftpd/issues/102 > or https://bugzilla.redhat.com/show_bug.cgi?id=1654838#c5 > > It's fixed in newer pure-ftpd versions. However, it's not easy to backport > because upstream refactored TLS code while fixing this bug. > > That's why I am requesting to disable TLS 1.3 to avoid data loss. So this affects the package version 1.0.47-3 in stable + testing? And the problem is supposed to fixed in the latest version ... I will take a look. Regards Racke > > > -- System Information: > Debian Release: 9.9 > APT prefers stable > APT policy: (1001, 'stable'), (990, 'oldstable'), (500, 'oldstable-updates') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible. signature.asc Description: OpenPGP digital signature
Bug#940317: hplip: No more printing
tags 940317 moreinfo thanks On Sun 15 Sep 2019 at 16:20:03 +0200, Nicolas Patrois wrote: > Package: hplip > Version: 3.19.8+dfsg0-1 > Severity: important > > Dear Maintainer, > > I can’t print anymore, neither with a Photosmart 4780 nor with an Envy 5534 (. > Both used to work. > In fact, the jobs seem frozen in the queue. > > I send the jobs and immediately, I’m informed that the job has been completed. > It has not been printed. Thank you for your report, Nicolas. PPD files for your two printers are in /etc/cups/ppd. For both devices, would you please execute the following command (as root) and post the two logs. cupsfilter -p -m printer/foo -e /etc/nsswitch.conf > out.dat 2>log Regards, Brian.
Bug#940519: curl: Enable support for http3 protocol
Package: curl Version: 7.66.0-1 Severity: normal Dear Maintainer, Recent curl package 7.66.0-1 doesn't support new http3 protocol. For sure you are already aware of the introduced experimental http3 into 7.66 curl upstream release. It seems to have a new build-dependency on quiche [0] (your implementation of QUIC ;). Still to be packaged. As an alternative it can be build with nghttp3 (non-packaged). I've been said by an expert that the best available option is quiche. Is someone packaging the new dependency? Do you plan to enable http3 as soon as deps are ready? Thanks, [0] https://github.com/cloudflare/quiche [1] https://github.com/ngtcp2/nghttp3
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
On Mon, Sep 16, 2019 at 05:38:47PM +0200, Andreas Tille wrote: > Determining dependency 'gtest_main' with pkg-config executable > '/usr/bin/pkg-config' > PKG_CONFIG_PATH: > Called `/usr/bin/pkg-config --modversion gtest_main` -> 1 There is no pkgconfig file for gtest_main in the archive. -- WBR, wRAR signature.asc Description: PGP signature
Bug#940021: Re[2]: Bug#940021: systemd: socket activation leads to OOM situation due to slices not getting cleaned up
Hi Michael, here is your requested output: find /sys/fs/cgroup/system.slice/system-check_mk.slice/ produces: root@debian:~# ls -la /sys/fs/cgroup/systemd/system.slice/system-check_mk.slice/ total 0 drwxr-xr-x 8 root root 0 Sep 16 19:53 . drwxr-xr-x 18 root root 0 Sep 16 19:53 .. -rw-r--r-- 1 root root 0 Sep 16 19:53 cgroup.clone_children -rw-r--r-- 1 root root 0 Sep 16 19:53 cgroup.procs drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@1-10.28.1.101:6556-10.28.1.99:61957.service drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@2-10.28.1.101:6556-10.28.1.99:61958.service drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@3-10.28.1.101:6556-10.28.1.99:61960.service drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@4-10.28.1.101:6556-10.28.1.99:61962.service drwxr-xr-x 2 root root 0 Sep 16 19:53 check_mk@5-10.28.1.101:6556-10.28.1.99:61964.service -rw-r--r-- 1 root root 0 Sep 16 19:53 notify_on_release -rw-r--r-- 1 root root 0 Sep 16 19:53 tasks systemctl status check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service produces: root@debian:~# systemctl status check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service * check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service - Check_MK Loaded: loaded (/etc/systemd/system/check_mk@.service; static; vendor preset: enabled) Active: inactive (dead) Sep 16 19:52:26 debian systemd[1]: Started Check_MK (10.28.1.99:61952). Sep 16 19:52:26 debian systemd[1]: check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service: Succeeded. so systemctl status system-check_mk.slice produces: root@debian:~# systemctl status system-check_mk.slice * system-check_mk.slice Loaded: loaded Active: active since Mon 2019-09-16 19:52:26 CEST; 4min 10s ago Tasks: 0 Memory: 6.0M CGroup: /system.slice/system-check_mk.slice Sep 16 19:52:26 debian systemd[1]: Created slice system-check_mk.slice. While memory reported by "systemctl status system-check_mk.slice" grows with each execution by call to the corresponding port (6556) of the service. Kind Regards, Julian -- Original Message -- From: "Michael Biebl" To: "Julian Hübenthal" ; 940...@bugs.debian.org Sent: 13/09/2019 00:55:16 Subject: Re: Bug#940021: systemd: socket activation leads to OOM situation due to slices not getting cleaned up Am 13.09.19 um 00:53 schrieb Michael Biebl: Am 12.09.19 um 14:29 schrieb Michael Biebl: Am 11.09.19 um 15:54 schrieb Julian Hübenthal: Just discovered something that may help to debug: It does not happen with a simple “Hello World” bash script instead of the Check MK Agent. It does not happen when the Encryption of the Check MK Agent is disabled. It happens when the Encryption of Check MK is enabled, which should be AES 128/256 output. I wonder if the MK agent does some tricks like locking the memory when encryption is on and then does not properly release its resources? Just to ask the obvious: The slice(s) themselves are empty, i.e. the check-mk agent process has exited (successfully)? What's the status of such a service that is not cleaned up? Taking your first email that would be systemctl status check_mk@10-10.28.5.6:6556-10.28.5.1:42844.service I'd be interested in the output of find /sys/fs/cgroup/system.slice/system-check_mk.slice/ as well As well as systemctl status system-check_mk.slice -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#940517: libcairo-gobject-perl: investigate library-not-linked-against-libc Lintian error
On Mon, Sep 16, 2019 at 05:20:06PM +0200, intrig...@debian.org wrote: > Package: libcairo-gobject-perl > Version: 1.004-3 > Severity: important > > I've spotted this error while packaging 1.005: > > E: libcairo-gobject-perl: library-not-linked-against-libc > usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Cairo/GObject/GObject.so > 1. 1.004-3+b1 that's in the archive (binNMU from 2018-11-02) > > - there's a "NEEDED" for libc.so.6 > - the "DYNAMIC SYMBOL TABLE" section includes: > > w DF *UND* GLIBC_2.2.5 > __cxa_finalize > > 2. Fresh build of 1.005-1 > > - no "NEEDED" for libc.so.6, hence the Lintian error > - __cxa_finalize is still present in the dynamic symbol table > > So this does not look like a false positive: at least one symbol from > libc is directly used by the library, so presumably it should be > linked against libc. The 'w' indicates a weak symbol. I expect that's why it doesn't result in a NEEDED entry. #896012 explains the behaviour if I understand it correctly: -lc used to be exempt from --as-needed but apparently GCC changed in that regard. Quoting doko there: If the plugin doesn't have a reference to libc and --as-needed is specified as in your case, then libc isn't linked in. So it seems to me that this is a false positive, and as discussed in #909267 lintian needs to get smarter. -- Niko
Bug#939754: gimp: Crashes when I try to open an image or create a new one
Package: gimp Version: 2.10.8-2+b1 Followup-For: Bug #939754 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? ``` GNU Image Manipulation Program version 2.10.8 git-describe: GIMP_2_10_6-294-ga967e8d2c2 C compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20190827 (Debian 9.2.1-6) using GEGL version 0.4.12 (compiled against version 0.4.14) using GLib version 2.60.6 (compiled against version 2.60.6) using GdkPixbuf version 2.38.1 (compiled against version 2.38.1) using GTK+ version 2.24.32 (compiled against version 2.24.32) using Pango version 1.42.3 (compiled against version 1.42.3) using Fontconfig version 2.13.1 (compiled against version 2.13.1) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` > fatal error: Segmentation fault Stack trace: ``` # Stack traces obtained from PID 4512 - Thread 4512 # [New LWP 4513] [New LWP 4514] [New LWP 4515] [New LWP 4516] [New LWP 4517] [New LWP 4518] [New LWP 4519] [New LWP 4520] [New LWP 4521] [New LWP 4522] [New LWP 4523] [New LWP 4524] [New LWP 4525] [New LWP 4526] [New LWP 4527] [New LWP 4528] [New LWP 4529] [New LWP 4530] [New LWP 4531] [New LWP 4588] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __libc_read (nbytes=256, buf=0x7ffda3037e90, fd=18) at ../sysdeps/unix/sysv/linux/read.c:26 Id Target Id Frame * 1Thread 0x7f92764c3e00 (LWP 4512) "gimp-2.10" __libc_read (nbytes=256, buf=0x7ffda3037e90, fd=18) at ../sysdeps/unix/sysv/linux/read.c:26 2Thread 0x7f927548a700 (LWP 4513) "gmain" 0x7f927821fedf in __GI___poll (fds=0x55bb8c04cf50, nfds=2, timeout=3578) at ../sysdeps/unix/sysv/linux/poll.c:29 3Thread 0x7f9274c89700 (LWP 4514) "gdbus" 0x7f927821fedf in __GI___poll (fds=0x55bb8c1a9010, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 4Thread 0x7f926660e700 (LWP 4515) "async" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 5Thread 0x7f9265e0d700 (LWP 4516) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 6Thread 0x7f926560c700 (LWP 4517) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 7Thread 0x7f9264e0b700 (LWP 4518) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8Thread 0x7f9253fff700 (LWP 4519) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 9Thread 0x7f92537fe700 (LWP 4520) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 10 Thread 0x7f9252ffd700 (LWP 4521) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 11 Thread 0x7f92527fc700 (LWP 4522) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 12 Thread 0x7f9251ffb700 (LWP 4523) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 13 Thread 0x7f92517fa700 (LWP 4524) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 14 Thread 0x7f9250ff9700 (LWP 4525) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 15 Thread 0x7f9233fff700 (LWP 4526) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 16 Thread 0x7f92337fe700 (LWP 4527) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 17 Thread 0x7f9232ffd700 (LWP 4528) "worker"
Bug#940104: x2goserver-x2goagent: x2goagent creates coredump after upgrate to Debian 10.1
Hi, On Fr 13 Sep 2019 10:37:11 CEST, Mark Hymers wrote: reassign 940104 nx-libs merge 940104 940103 thanks On Thu, 12, Sep, 2019 at 02:47:23PM +0200, Frank Rocholl spoke thus.. I'm not able to use x2go anymore. Hi Frank, I'm not the maintainer, but I've had the same problem with x2go in 10.1 (see bug #940103). As a workaround you can downgrade the nx-libs packages (libnx-x11-6, libxcomp3, libxcompshad3, nx-x11-common, nxagent, nxproxy) to the earlier version (you can grab them from snapshot.debian.org if necessary). Thanks, Mark Sorry for this hassle, no clue how this could slip through (other than having various nxagent versions here that I test in turns). I will for a quick work-around provide an nx-libs 3.5.99.22-1~bpo10+1 via buster-backports. This is no solution for Debian stable, I know. Regarding the package in Debian stable, I already know which patch from the +deb10u1 upload causes the trouble, but I don't know a proper solution for it, yet. Unfortunately, upstream diverged around the code passage under investigation. I'll see to get a fix into Debian stable-updates asap. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpRMDL_7fTv1.pgp Description: Digitale PGP-Signatur
Bug#940237: linphone segfault by clicking on its tray icon (a bit more debug information)
Today: [250748.834245] linphone[17812]: segfault at 4163000f41e1 ip 7fec20c15e9b sp 7ffcd6ec7de0 error 4 in libgtk-x11-2.0.so.0.2400.32[7fec20ab+25f000] [299754.840099] linphone[23858]: segfault at 1 ip 7f1ae215de9b sp 7ffc1d4e9ee0 error 4 in libgtk-x11-2.0.so.0.2400.32[7f1ae1ff8000+25f000] And I've noticed: segfault happens when swap access (RAM on my PC is not enough - 3 Gb only)
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
On 2019-09-16 at 11:38, Andreas Tille wrote: > Control: tags -1 pending > > Hi, > > I wanted to upgrade to the latest upstream version in Git[1] where > upstream has changed the build system. Its a bit irritating to use > meson on top of cmake (at least I have never seen this before) and I > think I have added all needed Build-Depends (locally - not commited > yet): > > > diff --git a/debian/control b/debian/control > index b4d7424..c5a11fd 100644 > --- a/debian/control > +++ b/debian/control > @@ -5,6 +5,10 @@ Section: libs > Priority: optional > Build-Depends: debhelper-compat (= 12), > dh-exec, > + meson, > + pkg-config, > + cmake, > + googletest, > zlib1g-dev, > libhdf5-dev, > libboost-dev, > > > Despite I have added googletest it seems not be found: > > > Library rt found: YES > Configuring LibBlasrConfig.h using configuration > Program tools/check-formatting found: YES > (/build/pbseqlib-5.3.3+dfsg/tools/check-formatting) > Pkg-config binary for MachineChoice.HOST is cached. > Determining dependency 'gtest_main' with pkg-config executable > '/usr/bin/pkg-config' > PKG_CONFIG_PATH: > Called `/usr/bin/pkg-config --modversion gtest_main` -> 1 > > CMake binary for MachineChoice.HOST is not cached > CMake binary missing from cross or native file, or env var undefined. > Trying a default CMake fallback at cmake > Trying CMake binary cmake for machine MachineChoice.HOST at ['/usr/bin/cmake'] > Found CMake: /usr/bin/cmake (3.13.4) > Extracting basic cmake information > Try CMake generator: auto > Called `/usr/bin/cmake --trace-expand .` in > /build/pbseqlib-5.3.3+dfsg/obj-x86_64-linux-gnu/meson-private/cmake_gtest_main > -> 0 > -- Module search paths:['/', '/opt', '/usr', '/usr/local'] > -- CMake root: /usr/share/cmake-3.13 > -- CMake architectures:['x86_64-linux-gnu'] > -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share', > 'lib/x86_64-linux-gnu'] > Run-time dependency gtest_main found: NO (tried pkgconfig and cmake) > Looking for a fallback subproject for the dependency gtest_main > > unittest/meson.build:14:0: ERROR: Automatic wrap-based subproject downloading > is disabled > > > > I also tried adding libgtest-dev in addition but this does not change > the situation. > > Any hint, what to do? I'm not remotely an expert on any of the tools, systems, or packages involved, but one thing I notice is that googletest doesn't seem to install an actual .pc file, just a .pc.in: $ dlocate gtest.*.pc googletest:amd64: /usr/src/googletest/googletest/cmake/gtest.pc.in googletest:amd64: /usr/src/googletest/googletest/cmake/gtest_main.pc.in (And similar lack of suitable results from apt-file search, et cetera.) The googletest package description says that it "does not contain a library to link against, but rather the source code to build the google test and mock libraries" (which fits with the fact that it isn't a lib* package). Typically the .pc file would be in the lib*-dev package, but in this case, since there isn't a matching lib* package to install, I can easily see why that might not make sense to do. (If it would, this would probably be a wishlist item for the googletest package maintainers.) /usr/share/doc/googletest/README.Debian states that >> The Google C++ Testing Framework uses conditional compilation for >> some things. Because of the C++ "One Definition Rule", gtest and >> gmock must be compiled with exactly the same flags as your C++ >> code under test. Because this is hard to manage, upstream no >> longer recommends using precompiled libraries [1]. >> [1] >> http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d and that >> If your build system uses CMake, the ExternalProject command can >> be used to build gtest, then FindGTest can be used to find the >> built library. Clearly you need to build gtest before it can be picked up; this might give some indication of how to go about doing so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
Control: tags -1 pending Hi, I wanted to upgrade to the latest upstream version in Git[1] where upstream has changed the build system. Its a bit irritating to use meson on top of cmake (at least I have never seen this before) and I think I have added all needed Build-Depends (locally - not commited yet): diff --git a/debian/control b/debian/control index b4d7424..c5a11fd 100644 --- a/debian/control +++ b/debian/control @@ -5,6 +5,10 @@ Section: libs Priority: optional Build-Depends: debhelper-compat (= 12), dh-exec, + meson, + pkg-config, + cmake, + googletest, zlib1g-dev, libhdf5-dev, libboost-dev, Despite I have added googletest it seems not be found: Library rt found: YES Configuring LibBlasrConfig.h using configuration Program tools/check-formatting found: YES (/build/pbseqlib-5.3.3+dfsg/tools/check-formatting) Pkg-config binary for MachineChoice.HOST is cached. Determining dependency 'gtest_main' with pkg-config executable '/usr/bin/pkg-config' PKG_CONFIG_PATH: Called `/usr/bin/pkg-config --modversion gtest_main` -> 1 CMake binary for MachineChoice.HOST is not cached CMake binary missing from cross or native file, or env var undefined. Trying a default CMake fallback at cmake Trying CMake binary cmake for machine MachineChoice.HOST at ['/usr/bin/cmake'] Found CMake: /usr/bin/cmake (3.13.4) Extracting basic cmake information Try CMake generator: auto Called `/usr/bin/cmake --trace-expand .` in /build/pbseqlib-5.3.3+dfsg/obj-x86_64-linux-gnu/meson-private/cmake_gtest_main -> 0 -- Module search paths:['/', '/opt', '/usr', '/usr/local'] -- CMake root: /usr/share/cmake-3.13 -- CMake architectures:['x86_64-linux-gnu'] -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share', 'lib/x86_64-linux-gnu'] Run-time dependency gtest_main found: NO (tried pkgconfig and cmake) Looking for a fallback subproject for the dependency gtest_main unittest/meson.build:14:0: ERROR: Automatic wrap-based subproject downloading is disabled I also tried adding libgtest-dev in addition but this does not change the situation. Any hint, what to do? Kind regards Andreas. [1] https://salsa.debian.org/med-team/pbseqlib -- http://fam-tille.de
Bug#940518: Grilo 0.3.10 available
Package: grilo Version: 0.3.9-1 There is a new version available, would be nice to have it uploaded to Debian http://ftp.acc.umu.se/pub/gnome/sources/grilo/0.3/grilo-0.3.10.news (there is also a grilo-plugins corresponding update) Cheers,
Bug#940517: libcairo-gobject-perl: investigate library-not-linked-against-libc Lintian error
Package: libcairo-gobject-perl Version: 1.004-3 Severity: important I've spotted this error while packaging 1.005: E: libcairo-gobject-perl: library-not-linked-against-libc usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Cairo/GObject/GObject.so N: N:The package installs a library which is not dynamically linked against N:libc. N: N:It is theoretically possible to have a library which doesn't use any N:symbols from libc, but it is far more likely that this is a violation of N:the requirement that "shared libraries must be linked against all N:libraries that they use symbols from in the same way that binaries are". N: N:Refer to Debian Policy Manual section 10.2 (Libraries) and N:https://bugs.debian.org/698720 for details. N: N:Severity: important, Certainty: possible N: N:Check: binaries, Type: binary, udeb If I rebuild 1.004-3 I see the same problem so it's caused by a change in build-dependencies, and not by the new libcairo-gobject-perl upstream release. I've investigated a bit with this command: objdump -Tx /usr/lib/x86_64-linux-gnu/perl5/5.*/auto/Cairo/GObject/GObject.so 1. 1.004-3+b1 that's in the archive (binNMU from 2018-11-02) - there's a "NEEDED" for libc.so.6 - the "DYNAMIC SYMBOL TABLE" section includes: w DF *UND* GLIBC_2.2.5 __cxa_finalize 2. Fresh build of 1.005-1 - no "NEEDED" for libc.so.6, hence the Lintian error - __cxa_finalize is still present in the dynamic symbol table So this does not look like a false positive: at least one symbol from libc is directly used by the library, so presumably it should be linked against libc. In both cases, all other symbols listed in the dynamic symbol table section have names that suggest they're coming from perl, GLib, or Cairo libraries. I'm not blocking on this to upload 1.005-1 because this could happen just as well with a binNMU next week (random example: as part of the perl 5.30 transition), regardless of whether I upload or not. And it seems to be a minor problem here: the only libc symbol that's used directly by this .so file was introduced in libc6 2.2.5, which was uploaded to sid in 2002; I doubt this will ever change given the nature of this library and its build system. However, I don't dare adding a Lintian override: I'm not well versed in the shared library / linker space and might very well be underestimating the severity of this problem. For whoever, better skilled at this than me, will investigate this problem: - #909267 might be interesting - I don't know if -Wl,--as-needed is passed during the build: the actual call to the linker is obfuscated as "LD". Cheers, -- intrigeri
Bug#940516: valgrind: ONLY uses /usr/lib/$(arch)-linux-gnu/default.supp by default
Package: valgrind
Version: 1:3.15.0-1
Severity: normal
Tags: upstream
Dear Maintainer,
The only suppression file that Valgrind loads by default is
/usr/lib/$(arch)-linux-gnu/default.supp
(/usr/lib/x86_64-linux-gnu/default.supp on my system). This is
inconvenient, because if you are using Valgrind to debug a program, but
you don't want to debug the libraries that program uses, or maybe one of
the libraries never free()'s some of its memory (for example ncurses or
Readline), then you will need to load the suppression file manually.
Further more (and this is the reason I tagged this bug as `normal'
rather than `wishlist'), some Debian packages install suppression files
to /usr/lib/valgrind/, and they appear to think that those files will be
loaded automatically. For example, the packages python{,2,3} install the
files /usr/lib/valgrind/python{,2,3}.supp. Here is an excerpt from one
of those files:
# Debian note:
# The file Misc/valgrind-python.supp is placed in an modified form into the
# directory /usr/lib/valgrind as python.supp. There's no need to to add it
# with the --suppressions option.
But in fact you DO need to add it with the --suppressions option.
To prove that Valgrind actually doesn't load these files, create a file
like this one:
#include
int main(void) {
/* Leak some memory. */
malloc(1);
return 0;
}
Then create a suppression like this:
{
Memory leak suppression
Memcheck:Leak
match-leak-kinds: definite
fun:malloc
fun:main
}
Verify that the suppression works:
$ gcc -o leak leak.c
$ valgrind ./leak
[...]
==3428==definitely lost: 1 bytes in 1 blocks
[...]
==3428== suppressed: 0 bytes in 0 blocks
[...]
$ valgrind --suppressions=leak.supp ./leak
[...]
==3436==definitely lost: 0 bytes in 0 blocks
[...]
==3436== suppressed: 1 bytes in 1 blocks
[...]
And if you copy the suppression to /usr/lib/valgrind/ (or even
/usr/lib/$(arch)-linux-gnu/valgrind/), you will find that it is not
loaded automatically. However, if you copy it to
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp (make a backup of
default.supp first), it *is* loaded automatically.
Correct me if I am mistaken, but I don't believe that Valgrind
suppression files have any way to include other files. If they did, and
it supported shell globs or similar,
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp could simply include
all the *.supp files in /usr/lib/valgrind/, /usr/local/lib/valgrind/,
etc.
But since I don't believe that is possible, the next best solution would
be to modify /usr/bin/valgrind (which is already a wrapper shell script)
to pass a --suppression=FILE for every FILE in /usr/lib/valgrind/*.supp,
/usr/local/lib/valgrind/*.supp, etc. to valgrind.bin. And maybe it could
also parse --default-suppressions=no and not include those files as well
as passing on --default-suppressions=no to valgrind.bin so it doesn't
load the actual default.supp.
Of course, this should probably really be fixed upstream. Maybe the best
solution would be to allow inclusion of other suppression files within
suppression files so that it is easy for the distribution packaging
Valgrind to choose which files/directories are loaded.
Thanks,
Asher
--
Steal this tagline. I did.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages valgrind depends on:
ii libc6 2.29-1
ii libc6-dbg 2.29-1
Versions of packages valgrind recommends:
ii gdb 8.3-1
ii valgrind-dbg 1:3.15.0-1
Versions of packages valgrind suggests:
pn alleyoop
pn kcachegrind
pn valgrind-mpi
pn valkyrie
-- no debconf information
signature.asc
Description: PGP signature
Bug#940105: linux: serious corruption issue with btrfs
I had a look at and it appears to have gone into both 5.3 (final) and 5.2.15. For what it's worth, it took only a day or so to exhibit the issue on our (admittedly active) nginx/postgres/PHP server; we weren't doing any unusual work during that time. If you're using btrfs, and you can't apply a patch to the backports kernel, it'd be a good idea to revert to a 4.19 kernel for the time being. -- Laurence "GreenReaper" Parry
Bug#940515: stress-ng: Doesn't recognize or error out on size suffixes (e.g. 10M).
Package: stress-ng Version: 0.10.05-1 Severity: normal user@debian:~$ time stress-ng --fifo 8 --fifo-ops 1000 stress-ng: info: [32701] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [32701] dispatching hogs: 8 fifo stress-ng: info: [32701] successful run completed in 4.71s real0m4.718s user0m2.611s sys 1m19.569s user@debian:~$ time stress-ng --fifo 8 --fifo-ops 10M stress-ng: info: [32660] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [32660] dispatching hogs: 8 fifo stress-ng: info: [32660] successful run completed in 0.00s real0m0.012s user0m0.012s sys 0m0.028s user@debian:~$ time stress-ng --fifo 8 --fifo-ops 1000M stress-ng: info: [36317] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [36317] dispatching hogs: 8 fifo stress-ng: info: [36317] successful run completed in 4.33s real0m4.334s user0m2.649s sys 1m21.490s user@debian:~$ user@debian:~$ time stress-ng --futex 8 --futex-ops 1000 stress-ng: info: [32744] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [32744] dispatching hogs: 8 futex stress-ng: info: [32744] successful run completed in 10.62s real0m10.631s user0m3.830s sys 2m2.262s user@debian:~$ time stress-ng --futex 8 --futex-ops 10M stress-ng: info: [32761] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [32761] dispatching hogs: 8 futex stress-ng: info: [32761] successful run completed in 0.00s real0m0.011s user0m0.021s sys 0m0.005s user@debian:~$ time stress-ng --futex 8 --futex-ops 1000M stress-ng: info: [36259] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [36259] dispatching hogs: 8 futex stress-ng: info: [36259] successful run completed in 9.69s real0m9.694s user0m3.383s sys 1m55.287s As you can see, 10M is interpreted as 10. The M suffix is silently dropped. Please emit an error and exit, or interpret the numbers as expected. This should definitively apply to all --*-ops flags, but many other ones should support K, M, G suffixes, i.e. --dirdeep-inodes, --heapsort-size, --aiol-requests, --aio-requests. Regards, Witold -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stress-ng depends on: ii libaio1 0.3.112-5 ii libapparmor1 2.13.3-5 ii libbsd0 0.10.0-1 ii libc6 2.29-1 ii libipsec-mb0 0.52-2+b1 ii libsctp1 1.0.18+dfsg-1 ii zlib1g1:1.2.11.dfsg-1+b1 stress-ng recommends no packages. stress-ng suggests no packages. -- no debconf information
Bug#940511: [Pkg-javascript-devel] Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg
Control: tags -1 + wontfix Le Lundi, Septembre 16, 2019 16:02 CEST, Melvin Vermeeren a écrit: > Package: yarnpkg > Version: 1.13.0-1 > Severity: normal > > Upstream calls the binary itself yarn as yarnpkg appears to have been > deprecated. Packaging as yarnpkg for backwards-compatibility is > understandable, > though I believe a symlink yarn -> yarnpkg should be added as tools and > scripts > nowadays typically check only for yarn. > > For example a problem occurs when installing GitLab from source, it only > checks > for yarn during the rake task and complains it cannot be found. A local > symlink > /usr/local/bin/yarn -> /usr/bin/yarnpkg resolved the issue. > > (Alternatively, perhaps make yarn the primary installation and symlink the > legacy yarnpkg -> yarn.) > > Thanks. Debian has already a /usr/bin/yarn file given by cmdtest. cmdtest has a better "popcon" than yarnpkg, that's why we won't change this for now. Cheers, Xavier
Bug#940261: Upgrade clang/llvm version used for postgresql-11
Christoph Berg writes: > it's a strict dependency because postgresql-11 is linked against a > specific version of libllvm, used for JIT compilation of SQL queries > using LLVM bitcode. I haven't really looked around myself, but from > talking to Andres Freund who implemented the JIT engine on the > PostgreSQL side, the bitcode files are probably specific to the llvm > version, so we make that a strict dependency to make sure the > PostgreSQL extension modules are compiled using the same clang version > as the server itself. I see. Thanks for the clarification. > About the version used, 9 is around the corner so I'd prefer moving > from 7 to 9, instead of upgrading to 8 now, and then upgrading again > in the next weeks/month. I'll leave this bug around as a reminder that > we need to do that upgrade. OK, sounds good. Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. signature.asc Description: PGP signature
Bug#940088: Same bug here when Gimp tries to open existing image
Dear Maintainer,
when try to open a small image (128x128 px) Gimp crashed completely.
Debian System Information see below.
Gimp produces this crash debug output:
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)
using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: Segmentation fault
Stack trace:
```
# Stack traces obtained from PID 4136 - Thread 4136 #
[New LWP 4138]
[New LWP 4139]
[New LWP 4140]
[New LWP 4141]
[New LWP 4142]
[New LWP 4143]
[New LWP 4155]
[New LWP 4161]
[New LWP 4169]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7fff5f6d5d50, fd=24) at
../sysdeps/unix/sysv/linux/read.c:26
Id Target Id Frame
* 1Thread 0x7f27627d3e00 (LWP 4136) "gimp"__libc_read (nbytes=256,
buf=0x7fff5f6d5d50, fd=24) at ../sysdeps/unix/sysv/linux/read.c:26
2Thread 0x7f275e9cf700 (LWP 4138) "gmain" 0x7f2761bc7edf in
__GI___poll (fds=0x562de11d7020, nfds=2, timeout=4993) at
../sysdeps/unix/sysv/linux/poll.c:29
3Thread 0x7f275e1ce700 (LWP 4139) "gdbus" 0x7f2761bc7edf in
__GI___poll (fds=0x562de129fe70, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
4Thread 0x7f274700 (LWP 4140) "async" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
5Thread 0x7f274f7fe700 (LWP 4141) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
6Thread 0x7f274effd700 (LWP 4142) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
7Thread 0x7f274e7fc700 (LWP 4143) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
8Thread 0x7f274d07f700 (LWP 4155) "threaded-ml" 0x7f2761bc7edf in
__GI___poll (fds=0x7f2734002f40, nfds=3, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
9Thread 0x7f274dffb700 (LWP 4161) "pool-gimp" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
10 Thread 0x7f271f7ff700 (LWP 4169) "swap writer" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
Thread 10 (Thread 0x7f271f7ff700 (LWP 4169)):
#0 0x7f2761bcd279 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7f2761ea995f in g_cond_wait () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f276237a0cd in () at /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3 0x7f2761e8789d in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f2761ca0fb7 in start_thread (arg=) at
pthread_create.c:486
ret =
pd =
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139806008932096,
-821260945208051, 140734794389566, 140734794389567, 139806008932096,
139806008928512, 8090942993227309521, 8090770207997813201}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call =
#5 0x7f2761bd249f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 9 (Thread 0x7f274dffb700 (LWP 4161)):
#0 0x7f2761bcd279 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1
Bug#940514: yarnpkg: implement bash autocompletion
Package: yarnpkg Version: 1.13.0-1 Severity: normal please implement bash autocompletion for yarnpkg as we have for example in npm. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yarnpkg depends on: ii node-asap 2.0.6-1 ii node-babel-runtime 6.26.0+dfsg-3 ii node-bytes 3.0.0-1 ii node-camelcase 5.0.0-1 ii node-chalk 2.3.0-2 ii node-chownr1.1.1-1 ii node-ci-info 1.1.2-1 ii node-cli-table 0.3.1-1 ii node-commander 2.12.2-3 ii node-death 1.0.0-1 ii node-debug 3.1.0-2 ii node-deep-equal1.0.1-1 ii node-detect-indent 5.0.0-1 ii node-duplexify 3.6.1-1 ii node-emoji 1.8.1-1 ii node-fast-levenshtein 2.0.5-1 ii node-glob 7.1.3-2 ii node-imports-loader0.7.1-1 ii node-ini 1.3.5-1 ii node-inquirer 3.3.0-2 ii node-invariant 2.2.2-1 ii node-is-builtin-module 2.0.0-1 ii node-loud-rejection1.6.0-1 ii node-micromatch2.3.11-1 ii node-minimatch 3.0.4-3 ii node-mkdirp0.5.1-1 ii node-node-uuid 3.3.2-2 ii node-object-path 0.11.4-2 ii node-proper-lockfile 2.0.1-1 ii node-puka 1.0.0+dfsg-1 ii node-pump 3.0.0-1 ii node-pumpify 1.5.1-1 ii node-read 1.0.7-1 ii node-request 2.88.1-2 ii node-request-capture-har 1.2.2-1 ii node-resolve 1.5.0-1 ii node-rimraf2.6.2-1 ii node-semver5.5.1-1 ii node-ssri 5.2.4-2 ii node-strip-ansi4.0.0-1 ii node-strip-bom 3.0.0-1 ii node-tar-stream1.5.2-1 ii node-validate-npm-package-license 3.0.1-1 ii node-yn3.0.0-1 ii nodejs 10.15.2~dfsg-2 yarnpkg recommends no packages. yarnpkg suggests no packages. -- no debconf information
Bug#940471: diffoscope: test failures
tags 940471 - moreinfo > thanks > > Hi Gianfranco, > > > Hello, looks like the latest diffoscope in unstable has a test failure > > that is preventing it from entering testing: > > Hm, I can't reproduce this unfortunately. > > > FileNotFoundError: [Errno 2] No such file or directory: 'ocamlc': 'ocamlc' > > This does not make immediate sense to me - ocamlc is provided by the > ocaml-nox package which is listed in the Build-Depends and in the > autopkgtest debian/tests/control file. > > Any ideas? > If you look at the log, https://ci.debian.net/packages/d/diffoscope/testing/amd64/ you can see that pytest-with-recommends works, because it installs ocaml-nox, while pytest doesn't... look at debian/tests/control Tests: pytest Depends: diffoscope, python3-pytest, file, python3-tlsh I would expect either: 1) ocaml-nox to become a runtime dependency for pytest test 2) test being skipped when ocaml-nox is not installed 3) ocaml-nox become a runtime dependency of diffoscope. I don't really know which one is better, I think 2), but since it requires code modifications, I went for 1) in Ubuntu https://launchpad.net/ubuntu/+source/diffoscope/123ubuntu1 (lets see how it goes) G. > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org chris-lamb.co.uk >`- > >
Bug#866704: guacamole-client FTBFS: guacamole-common-js failure
Control: reassign -1 libmaven-assembly-plugin-java Control: found -1 2.4.1-2 Control: fixed -1 2.4.1-3 Control: close -1 On Sat, 01 Jul 2017 09:04:00 +0300 Adrian Bunk wrote: > [[1;31mERROR[m] Failed to execute goal > [32morg.apache.maven.plugins:maven-assembly-plugin:2.4.1:attached[m > [1m(make-zip)[m on project [36mguacamole-common-js[m: [1;31mExecution > make-zip of goal > org.apache.maven.plugins:maven-assembly-plugin:2.4.1:attached failed: An API > incompatibility was encountered while executing > org.apache.maven.plugins:maven-assembly-plugin:2.4.1:attached: > java.lang.NoSuchMethodError: > org.codehaus.plexus.interpolation.object.FieldBasedObjectInterpolator.interpolate(Ljava/lang/Object;Lorg/codehaus/plexus/interpolation/Interpolator;Lorg/codehaus/plexus/interpolation/RecursionInterceptor;)V[m This is a duplicate of #866855 which was fixed two years ago.
Bug#940511: there's a already a yarn binary in Debian
Hi Melvin, thanks for raising this issue again. We can't just symlink yarn to yarnpkg or rename yarnpkg -> yarn because there's a already a yarn binary in Debian, see: https://packages.debian.org/search?suite=sid=all=any=contents=yarn This was extensively debated in the IPT bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843021#65 and the consensus at the time was that "our" yarn -was to ship only the yarnpkg binary I still think it's confusing and I agree with you that it would be best to use the same name as upstream. I propose to keep this bug open and wait to see what happens; ATM cmdtest is far more popular (as per popcon data) than yarnpkg ... Paolo
Bug#910423: guacamole: broken symlink: /usr/share/guacamole/guacamole/WEB-INF/lib/stax-api.jar -> ../../../../java/stax-api.jar
Control: severity -1 normal On Sat, 06 Oct 2018 08:07:40 +0200 Andreas Beckmann wrote: > Is guacamole missing a dependency on libstax-java ? The StAX API is a standard API of the JDK since Java 6, so the missing stax-api.jar link has no effect at runtime. Emmanuel Bourg
Bug#940513: ITP: r-bioc-mofa -- Multi-Omics Factor Analysis (MOFA)
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-mofa -- Multi-Omics Factor Analysis (MOFA) Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-bioc-mofa Version : 1.0.0 Upstream Author : Copyright: (FIXME: year)-2019 Ricard Argelaguet, Britta Velten, Damien Arnol, Florian Buettner, Wolfgang Huber, Oliver Stegle * URL : https://bioconductor.org/packages/MOFA/ * License : GPL-3 Programming Lang: GNU R Description : Multi-Omics Factor Analysis (MOFA) Multi-Omics Factor Analysis: an unsupervised framework for the integration of multi-omics data sets. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-mofa
Bug#940512: feature is no longer recommended by Mozilla
Package: sso.debian.org Severity: normal With a Firefox nightly 71.0a1 (2019-09-15), tag does not work for sso.debian.org anymore. After searching a little bit, it appears that Mozilla claims on their website that is no longer recommended[1]. [1]https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen Regards, Aron
Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg
Package: yarnpkg Version: 1.13.0-1 Severity: normal Upstream calls the binary itself yarn as yarnpkg appears to have been deprecated. Packaging as yarnpkg for backwards-compatibility is understandable, though I believe a symlink yarn -> yarnpkg should be added as tools and scripts nowadays typically check only for yarn. For example a problem occurs when installing GitLab from source, it only checks for yarn during the rake task and complains it cannot be found. A local symlink /usr/local/bin/yarn -> /usr/bin/yarnpkg resolved the issue. (Alternatively, perhaps make yarn the primary installation and symlink the legacy yarnpkg -> yarn.) Thanks. -- System Information: Debian Release: 10.1 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/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yarnpkg depends on: pn node-asap pn node-babel-runtime pn node-bytes pn node-camelcase pn node-chalk pn node-chownr pn node-ci-info pn node-cli-table pn node-commander pn node-death pn node-debug pn node-deep-equal pn node-detect-indent pn node-duplexify pn node-emoji pn node-fast-levenshtein pn node-glob pn node-imports-loader pn node-ini pn node-inquirer pn node-invariant pn node-is-builtin-module pn node-loud-rejection pn node-micromatch pn node-minimatch pn node-mkdirp pn node-node-uuid pn node-object-path pn node-proper-lockfile pn node-puka pn node-pump pn node-pumpify pn node-read pn node-request pn node-request-capture-har pn node-resolve pn node-rimraf pn node-semver pn node-ssri pn node-strip-ansi pn node-strip-bom pn node-tar-stream pn node-validate-npm-package-license pn node-yn ii nodejs 10.15.2~dfsg-2 yarnpkg recommends no packages. yarnpkg suggests no packages.
Bug#940509: RM: golang-gopkg-robfig-cron.v2 -- ROM; no longer needed
Package: ftp.debian.org Severity: normal golang-gopkg-robfig-cron.v2 is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#940510: RM: typeahead.js -- ROM; no longer needed
Package: ftp.debian.org Severity: normal typeahead.js is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#940508: RM: golang-github-influxdata-flux -- ROM; no longer needed
Package: ftp.debian.org Severity: normal golang-github-influxdata-flux is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#927971: tomcat9: split policy files and libexec scripts so that pki-server can use them
On 3.6.2019 1.11, Emmanuel Bourg wrote: > Hi Timo, > > Le 25/04/2019 à 19:37, Timo Aaltonen a écrit : > >> I'd like to use the libexec scripts and policy files from the pki-server >> systemd service file, but installing 'tomcat9' will start an instance and >> then 'pkispawn' would fail because the (default) port is already used. So I >> can't just depend on tomcat9, but maybe these files could be moved to >> -common or -user? > > Did you consider calling /usr/share/tomcat9/bin/catalina.sh (installed > by tomcat9-common) instead of reusing the libexec script that's focused > on the tomcat9 package needs? That should allow you to start a Tomcat > instance with the settings you want. Right, I've copied the start-script to pki and modified to suit, but the policy files should probably still moved to -common? -- t
Bug#940506: RM: golang-github-getkin-kin-openapi -- ROM; no longer needed
Package: ftp.debian.org Severity: normal golang-github-getkin-kin-openapi is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#940507: RM: golang-github-nats-io-go-nats-streaming -- ROM; no longer needed
Package: ftp.debian.org Severity: normal golang-github-nats-io-go-nats-streaming is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#940504: RM: golang-github-juju-webbrowser -- ROM; no longer needed
Package: ftp.debian.org Severity: normal golang-github-juju-webbrowser is no longer needed by any package. It should be removed from the archive. Cheers, -- Aleaxandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#940505: pure-ftpd: TLS 1.3 support broken
Source: pure-ftpd Severity: grave Justification: causes non-serious data loss Dear Maintainer, please consider disabling TLS 1.3 support. While you added TLS 1.3 compatibility through bug 918630, this uncovered a grave bug in pure-ftpd, see https://github.com/jedisct1/pure-ftpd/issues/102 or https://bugzilla.redhat.com/show_bug.cgi?id=1654838#c5 It's fixed in newer pure-ftpd versions. However, it's not easy to backport because upstream refactored TLS code while fixing this bug. That's why I am requesting to disable TLS 1.3 to avoid data loss. -- System Information: Debian Release: 9.9 APT prefers stable APT policy: (1001, 'stable'), (990, 'oldstable'), (500, 'oldstable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#932716: [Pkg-samba-maint] Bug#932716: samba: smbd gets killed by systemd on magic script invocation
Control: reopen -1 2:4.5.16+dfsg-1+deb9u2 Control: tag -1 moreinfo Le lun. 16 sept. 2019 à 15:42, Alexander Zima a écrit : > > Can you please explain it a little bit more... > I investigated the whole thing through and finally I decided to open the bug. > As there was no information in the samba logs, I didn't add them. > I really need this to be clarified. Reopening. This needs more info: Does it gets killed for a simple no-op script too? Regards -- Mathieu Parent
