Bug#1021656: please package new upstream release
Package: tt-rss Version: 21~git20210204.b4cbc79+dfsg-1.2 Severity: normal Followup-For: Bug #1021656 X-Debbugs-Cc: mnalis-debian...@voyager.hr It is possible to package new version of tt-rss? As noted earlier, this one from 2021 is quite buggy and requires several manual patches to even be usable on newer PHP versions. Sebastian, if you're short on time or have other priorities, would you like some help with packaging and testing of tt-rss?
Bug#1061093: fpc not working on loong64 yet
Ironseed requires working free pascal compiler; at the moment it seems there is not one available for loong64: https://packages.debian.org/sid/fp-utils-3.2.2 so unfortunately this bug is blocked until such time as FPC becomes available for loong64. You may want to open bug there to add support for loong64: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=fpc -- Opinions above are GNU-copylefted.
Bug#974750: imagemagick-6.q16: Convert to .tga (Targa) now flips image upside-down
related graphicsmagick bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016653 -- Opinions above are GNU-copylefted.
Bug#998514: related bug #1065133
Suggested init.d script to orphan-sysvinit-scripts package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065133 -- Opinions above are GNU-copylefted.
Bug#1065133: orphan-sysvinit-scripts: Please support pdns-recursor
On Tue, Mar 26, 2024 at 12:39:23PM +0100, Lorenzo wrote: > Hi Matija, > > could you please test the attached refreshed script and report if it > works as expected for your use case? Thanks! I can confirm that attached /etc/init.d/pdns-recursor seems to work just fine on my SysV based Debian Bookworm with pdns-recursor 4.8.7-1 -- Opinions above are GNU-copylefted.
Bug#1055451: prosody: Bug still present in prosody 0.12.4-1~bpo12+1
Package: prosody
Version: 0.12.4-1~bpo12+1
Followup-For: Bug #1055451
X-Debbugs-Cc: mnalis-debian...@voyager.hr
Control: tags -1 patch
Dear Maintainer,
I can confirm the issue is still present in prosody 0.12.4-1~bpo12+1 from
bookworm-backports, and affects all non-systemd installations. E.g.:
# /etc/init.d/prosody stop ; ps auxfw | grep prosod | grep -v grep
Stopping Prosody XMPP Server: prosody.
prosody 3005 0.0 0.1 54900 8344 ?S20:42 0:00 lua5.4
/usr/bin/prosody -D
Attached is a simple patch that fixes it.
In the future, /etc/init.d/prosody should be kept in sync with debian/control
"Depends:" field (i.e. if prosody depends on "lua5.4", then init.d script
should
reference "lua5.4" too).
-- System Information:
Debian Release: 12.5
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages prosody depends on:
ii adduser 3.134
ii init-system-helpers 1.65.2
ii libc6 2.36-9+deb12u4
ii libicu7272.1-3
ii libssl3 3.0.11-1~deb12u2
ii lua-bitop [lua5.4-bitop]1.0.2-7
ii lua-expat [lua5.4-expat]1.5.1-3
ii lua-filesystem [lua5.4-filesystem] 1.8.0-3
ii lua-sec [lua5.4-sec]1.2.0-2
ii lua-socket [lua5.4-socket] 3.1.0-1+b1
ii lua5.4 5.4.4-3
ii ssl-cert1.1.2
Versions of packages prosody recommends:
ii lua-event [lua5.4-event] 0.4.6-2+b1
ii lua-unbound [lua5.4-unbound] 1.0.0-2
pn lua5.4-readline
Versions of packages prosody suggests:
pn lua-dbi-mysql
pn lua-dbi-postgresql
pn lua-dbi-sqlite3
ii lua-zlib1.2-3
-- Configuration Files:
/etc/prosody/conf.avail/example.com.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/conf.avail/example.com.cfg.lua'
/etc/prosody/conf.avail/localhost.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/conf.avail/localhost.cfg.lua'
/etc/prosody/prosody.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/prosody.cfg.lua'
-- no debconf information
--- /etc/init.d/prosody.org-bookworm2020-10-02 11:45:27.0 +0200
+++ /etc/init.d/prosody 2024-03-28 20:38:07.172873463 +0100
@@ -43,7 +43,7 @@
chown prosody:adm "$(dirname $PIDFILE)"
[ -x /sbin/restorecon ] && /sbin/restorecon `dirname $PIDFILE`
if start-stop-daemon --start --quiet --pidfile "$PIDFILE" \
- --chuid "$USER" --oknodo --user "$USER" --name lua5.2 \
+ --chuid "$USER" --oknodo --user "$USER" --name lua5.4 \
$(start_opts) --startas "$DAEMON" -- -D;
then
return 0
@@ -54,7 +54,7 @@
stop_prosody () {
if start-stop-daemon --stop --quiet --retry 30 \
- --oknodo --pidfile "$PIDFILE" --user "$USER" --name lua5.2;
+ --oknodo --pidfile "$PIDFILE" --user "$USER" --name lua5.4;
then
return 0
else
@@ -64,7 +64,7 @@
signal_prosody () {
if start-stop-daemon --stop --quiet --pidfile "$PIDFILE" \
- --user "$USER" --name lua5.2 --oknodo --signal "$1";
+ --user "$USER" --name lua5.4 --oknodo --signal "$1";
then
return 0
else
@@ -111,7 +111,7 @@
;;
status)
log_daemon_msg "Status of Prosody XMPP Server" "prosody "
- status_of_proc -p"$PIDFILE" lua5.2
+ status_of_proc -p"$PIDFILE" lua5.4
;;
*)
log_action_msg "Usage: /etc/init.d/prosody
{start|stop|restart|reload|status}"
Bug#1065133: orphan-sysvinit-scripts: Please support pdns-recursor
Package: orphan-sysvinit-scripts Version: 0.14 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr pdns-recursor dropped support for sysVinit scripts at some moment. Maintainer wontfixed the request to reinstate it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998514 would it be possible to o-s-c takes it over, so people not running systemd can actually use the package? Thanks! -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages orphan-sysvinit-scripts depends on: ii ucf 3.0043+nmu1 orphan-sysvinit-scripts recommends no packages. orphan-sysvinit-scripts suggests no packages. -- no debconf information
Bug#1063507: tt-rss: Upgrading to Bookworm results in old read articles to be refetched as unread
Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1.2
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr
Dear Maintainer,
There was happily working tt-rss instalation in Bullseye, however after
upgrading the Bookworm, the first time updating script run, it re-fetched
a lot of older articles and marked them as unread.
Trying to debug the issue, I've found that the GUID seems to have changed,
probably due to PHP 8.2 in Bookworm changed not to quote integers fetched
from database:
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo.mysql
and the old packaged version of tt-rss apparently not having support for it.
That resulted in duplicate rows (in otherwise UNIQUE field "guid"), e.g.:
MariaDB [ttrss]> select id, title, guid, updated, date_entered, date_updated
from ttrss_entries where title like 'Could the Sun%';
++---++-+-+-+
| id | title | guid
| updated |
date_entered| date_updated|
++---++-+-+-+
| 528463 | Could the Sun be hiding a black hole? |
{"ver":2,"uid":"3","hash":"SHA1:dcf27dd8206c88fc25db2439fbfdbcc1113d826e"} |
2024-01-21 15:01:08 | 2024-01-22 00:05:00 | 2024-02-05 00:09:14 |
| 534207 | Could the Sun be hiding a black hole? |
{"ver":2,"uid":3,"hash":"SHA1:dcf27dd8206c88fc25db2439fbfdbcc1113d826e"} |
2024-01-21 15:01:08 | 2024-02-09 00:56:00 | 2024-02-09 00:56:08 |
++---++-+-+-+
That should not have happened, there should've been only first row existing, and
second row shouldn't have been created. The problem seems to be that "guid"
is not EXACTLY the same, before it said:
"uid":"3"
and now it says
"uid":3
while it points to exactly the same data, the strings are not the same, so
it fails to detect it as a duplicate.
I've worked around the problem by stopping updating services, restoring the
last tt-rss database backup before Bookworm upgrade, and running following
mysql command on ttrss database:
UPDATE ttrss_entries SET guid = REGEXP_REPLACE(guid, '"uid":"([0-9]+)"',
'"uid":\\1');
that converted all old entries (which used quoted-integers) to a new format
(which does not quote integers), thus allowing subsequent tt-rss feed updates
not to create duplicates as even old entries are using new format.
Perhaps newer upstream version of tt-rss handles that as well as it does
other similar problems with string/integer (e.g. as it does in #1054608)
-- System Information:
Debian Release: 12.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages tt-rss depends on:
ii dbconfig-common 2.0.24
ii dbconfig-mysql2.0.24
ii debconf [debconf-2.0] 1.5.82
ii fonts-material-design-icons-iconfont 6.7.0+dfsg-1
ii init-system-helpers 1.65.2
ii libapache2-mod-php8.2 [php-json] 8.2.7-1~deb12u1
ii libjs-dojo-core 1.17.2+dfsg1-2.1
ii libjs-dojo-dijit 1.17.2+dfsg1-2.1
ii libjs-scriptaculous 1.9.0-3
ii lsb-base 11.6
ii php 2:8.2+93
pn php-cli
ii php-intl 2:8.2+93
ii php-mbstring 2:8.2+93
ii php-mysql 2:8.2+93
ii php-php-gettext 1.0.12-5
ii php-psr-log 1.1.4-2
ii php-xml 2:8.2+93
ii php8.2 [php] 8.2.7-1~deb12u1
ii php8.2-cli [php-json] 8.2.7-1~deb12u1
ii php8.2-intl [php-intl]8.2.7-1~deb12u1
ii php8.2-mbstring [php-mbstring]8.2.7-1~deb12u1
ii php8.2-phpdbg [php-json] 8.2.7-1~deb12u1
ii php8.2-xml [php-xml] 8.2.7-1~deb12u1
ii phpqrcode 1.1.4-3.1
ii sysvinit-utils [lsb-base] 3.06-4
Versions of packages tt-rss recommends:
ii apache2 [httpd] 2.4.57-2
ii ca-certificates 20230311
ii php-curl2:8.2+93
ii php-gd
Bug#1054608: tt-rss: New entries always marked as read even if the unread counter is not null
Package: tt-rss Version: 21~git20210204.b4cbc79+dfsg-1.2 Severity: important Followup-For: Bug #1054608 X-Debbugs-Cc: mnalis-debian...@voyager.hr I agree, this is MAJOR usability problem. I can confirm that the patch suggested here works, as does the (two-years old) upstream change: https://git.tt-rss.org/fox/tt-rss.git/commit/?id=931e33c3818d160a2ea4e7e30c220df0b622cca7 So either applying patch, or upgrading the tt-rss to newer upstream would fix the issue.
Bug#1061093: ironseed: please add support for loong64
Hi wuruilong, Thanks for reporting! Just to confirm, you've tried compiling and running it, and it works on loong64 architecture? On Thu, Jan 18, 2024 at 01:42:19AM +, wuruilong wrote: > Source: ironseed > Severity: normal > X-Debbugs-Cc: wuruil...@loongson.cn > > Dear Maintainer, > > Please modify the file to support the loong64 architecture, the content is as > follows: > debian/tests/control:2:Architecture: amd64 arm64 armel armhf i386 loong64 > mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64 > debian/control:23:Architecture: amd64 arm64 armel armhf i386 loong64 mipsel > mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64 > > wuruilong > > -- System Information: > Debian Release: trixie/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: loong64 (loongarch64) > > Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads) > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect > -- Opinions above are GNU-copylefted.
Bug#1058643: dnsdist: re-enable 32-bit support via _TIME_BITS=64
On Sun, Dec 17, 2023 at 11:54:56PM +0100, Chris Hofstaedtler wrote: > On Thu, Dec 14, 2023 at 12:06:59AM +0000, Matija Nalis wrote: > > export DEB_CXXFLAGS_APPEND="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" > > (and skipping dependency on architecture-is-64-bit, of course). > > My understanding is, doing this on an individual package level, is > not safe in any way. It might work when the stars align correctly, > but there are zero guarantees for anything. I agree, there would be issues in cases where 64-bit time_t is passed to library which was not compiled for 64-bit time_t. But as link below notes, that actually seems to happen not all that often. (and I have not seen it in my - admittedly somewhat basic - use of dnsdist) > I think we'll wait at the very least until Debian finishes the t64 > transition, and then we'll see what to do about 32bit archs. Yes, when transition happens (with tentative timeline of Jan 2024?), re-enabling 32-bit archs for dnsdist should "just work". More details (and suggestions for package maintainers how to prepare) are available at: https://wiki.debian.org/ReleaseGoals/64bit-time > In the meantime, dnsdist works on arm64, also on Raspberrys! It does, if one happens to have newer Rasperry Pi hardware (i.e. Cortex-A53+, not older Rpi1 & Rpi2 which are 32-bit only), and 64-bit distro (many are still 32-bit based by default for plug-in compatibility with older hardware and resource conservation, and people are somewhat understandably reluctant to reinstalling and reconfiguring their whole systems just to install one package) I did talk to people at #dnsdist IRC, and they referenced https://github.com/PowerDNS/pdns/pull/10933 If I understood correctly, it should just work when whole system is recompiled for 64-bit, but there were talks about improving tests suite so it can validated if 64bit dnsdist + 32libs would work fine too. (But it is, as always, the matter of priorities and available time...) -- Opinions above are GNU-copylefted.
Bug#1058643: dnsdist: re-enable 32-bit support via _TIME_BITS=64
Package: dnsdist Version: 1.8.2-3 Severity: wishlist X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, dnsdist has been available until Bullseye in Debian on 32-bit arhitectures, when support was removed and package was modified to depend on "architecture-is-64-bit". That seems to be prompted by this upstream change (quoting from https://blog.powerdns.com/2021/05/11/dnsdist-1-6-0-released): "We would also like to take this opportunity to announce that we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm and i386 before kernel version 5.1." and confirmed in Debian changelog https://sources.debian.org/src/dnsdist/1.8.2-3/debian/changelog/#L97 "* Note: upstream dropped support for archs with 32bit time_t values in 1.6.0." And indeed, trying to compile Debian package on 32-bit armhf Debian Bookworm, it fails in configure step due to 32-bit time_t. However, Debian Bookworm (and newer) include new glibc and kernel > 5.1 which allow for 64-bit time_t on 32-bit system like armhf, as documented here: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fTIME_005fBITS So, all that is needed for dnsdist on 32-bit platform (like my Rasperry Pi armhf, where I tested that solution, and it compiles and runs just fine, both versions 1.7.3-2 and 1.8.2-3) is: export DEB_CXXFLAGS_APPEND="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" (and skipping dependency on architecture-is-64-bit, of course). So, can we fix the build on 32-bit architectures that support 64-bit time_t? I'd love to see dnsdist back on armhf in Trixie! Thank you for your consideration.
Bug#1054227: /usr/bin/josm: Randomly stops processing hotkeys until mouse is clicked
Package: josm Version: 0.0.svn18822+dfsg-1~bpo12+1 Followup-For: Bug #1054227 X-Debbugs-Cc: mnalis-debian...@voyager.hr Still happens with bookworm-backports JOSM version. See the screencast at https://mnalis.com/tmp/simplescreenrecorder-2023-10-19_18.35.02.mp4 (the issue happens even without screenkey and SimpleScreenRecoreder, of course, there are in the video to show when I press the keys that they don't work anymore) It seem main actors problem is F3 key for opening list of presets, but also other hotkeys that open separate window (like ctrl-f for finding objects, or ctrl-h for history). Changing editing mode (e.g. 's' / 'a') even when pressed many times do not seem to trigger the problem. You can note I remove previous JOSM directories and start fresh. Issue happens both when dismissing presets window with "ESC" as well as with clicking cancel button. I usually use icewm window manager (no any desktop environment); however I've reproduced the same problem in aewm++, evilwm, flwm, fvwm3, lwm and icewm out of several that I tried, and the issue is reproducable in all of them (in some even quicker; i.e. it blocks every time, not just every second or third or forth time as it does in icewm). However, much to my surprise, I've found that the issue does not seem to happen (or at least happen much more rarely, i.e. I can't easily reproduce it in ~30+ keypresses) in openbox, twm and i3 window managers! All other apps (browser, video players, libreoffice etc) show no problem with any of the window managers. I do not use any other java GUI apps, though. Also, as noted before, even JOSM worked perfectly in Bullseye for years, and the bug only manifested itself in Bookworm. Does that gives a clue? It seems like it might be some strange interaction between JOSM (or maybe java itself, that is, some of its GUI components) and window managers? Can you reproduce it with one of window managers above? Anything else I could try to pinpoint it down? -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages josm depends on: ii default-jre [java9-runtime] 2:1.17-74 ii fonts-noto 20201225-1 ii jmapviewer 2.16+dfsg-2 ii libcommons-compress-java1.22-1 ii libgettext-commons-java 0.9.6-6 ii openjdk-17-jre [java9-runtime] 17.0.8+7-1~deb12u1 ii openjfx 11.0.11+1-3 ii proj-data 9.1.1-1 Versions of packages josm recommends: pn josm-l10n josm suggests no packages. -- no debconf information
Bug#1054227: /usr/bin/josm: Randomly stops processing hotkeys until mouse is clicked
Package: josm
Version: 0.0.svn18646+dfsg-1
Severity: normal
File: /usr/bin/josm
X-Debbugs-Cc: mnalis-debian...@voyager.hr
After upgrade from Bullseye to Bookworm, JOSM very frequently stops processing
all hotkeys.
Problem never occured in Bullseye.
Once it happens, no keyboard input is processed until a mouse is clicked on
some element, when it seems to work again
for some time.
I can reliably reproduce it with unmodified /etc/default/josm, as well as new
user with no JOSM
configurations/plugins/caches in HOME.
Easieast way to reproduce it to download some area with buildings, click on
building to select it, and then press F3 to bring up preset chooser, and exit
it with ESC. After several "F3 / ESC" combos (usually less then 10), the bug
triggers, so new press on F3 will NOT bring up preset window, neither will
other keyboard shortcuts (like "s" to select, "a" to add etc) work.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages josm depends on:
ii default-jre [java9-runtime] 2:1.17-74
ii fonts-noto 20201225-1
ii jmapviewer 2.16+dfsg-2
ii libcommons-compress-java1.22-1
ii libgettext-commons-java 0.9.6-6
ii openjdk-17-jre [java9-runtime] 17.0.8+7-1~deb12u1
ii openjfx 11.0.11+1-3
ii proj-data 9.1.1-1
Versions of packages josm recommends:
pn josm-l10n
josm suggests no packages.
-- Configuration Files:
/etc/default/josm changed:
JAVA_OPTS="${JAVA_OPTS} -Xmx4096m"
JAVA_OPTS="${JAVA_OPTS} -Dsun.java2d.opengl=True"
-- no debconf information
Bug#1053737: /usr/bin/ssh-keygen: ssh-keygen -R: "invalid line" errors
Package: openssh-client Version: 1:8.4p1-5+deb11u2 Severity: normal File: /usr/bin/ssh-keygen Dear Maintainer, * What led up to the situation? Trying to execute: ssh-keygen -f "/home/mnalis/.ssh/known_hosts" -R "github.com" (exact command as suggested by ssh itself because host key changed, probably due to https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/) * What exactly did you do (or not do) that was effective (or ineffective)? Tried on another machine with openssh-client 1:9.4p1-1, the same problem is present there for this known_hosts file too. Manually editing the file and removing line 200 works around the specific instance of the problem, but "ssh-keygen -R" remains unusable. I assume that manually removing all lines detected as "invalid line" would also allow ssh-keygen to proceed, but I have not tested it. * What was the outcome of this action? ssh-keygen refuses to update known_hosts with following error: % ssh-keygen -f "/home/mnalis/.ssh/known_hosts" -R "github.com" /home/mnalis/.ssh/known_hosts:1: invalid line /home/mnalis/.ssh/known_hosts:2: invalid line /home/mnalis/.ssh/known_hosts:4: invalid line /home/mnalis/.ssh/known_hosts:16: invalid line /home/mnalis/.ssh/known_hosts:17: invalid line # Host github.com found: line 200 /home/mnalis/.ssh/known_hosts is not a valid known_hosts file. Not replacing existing known_hosts file because of errors Here is how first 4 lines of that known_hosts file look like: |1|DCvQVwzVexcX3Mau1D5fZmVKruM=|soAN7Mhjth9ExnFxG47y++6LLHg= 1024 35 167434766793837483340248804980769949824665268604993978563358959479765830951370741558908832827011687207884480786428301345738847818832072690127564924719644302715664485137952117178027506363037390447008852228373472317454193197538959482837286051143224351239595700806436016270258891540041265360900792522259140180921 |1|amNEFjA4gEiPAJp/hZepdJ1a38A=|3r0i0zg3DJ9iiaAcpdPfLNrhUrw= 1024 35 167434766793837483340248804980769949824665268604993978563358959479765830951370741558908832827011687207884480786428301345738847818832072690127564924719644302715664485137952117178027506363037390447008852228373472317454193197538959482837286051143224351239595700806436016270258891540041265360900792522259140180921 |1|+Q0EQTlTQeJ0jfLrk4Bhhyq7tic=|OtfKGw6dQ8Sw3BsH3MsRxj/+am8= ssh-rsa B3NzaC1yc2EBIwAAAIEAoSZK2F7aXr0UxG8TqyqRiVKK1redIINJw2XHAFYwg+fRT4QxRGWANoZO4ggK6SB1dV0JsIvfJr/D7VGNiwfLT/i+K/EWt1jQ1Y13cLhzqqSrsUOWvsr2xC+re8QeSILk5pzP5nzQEYTyyBknCq0yCjnuRKm9MhqQOrcgY2GMB3U= |1|zlwmrL64HaBaMTElBLAjB5wfiNE=|aqU2HeyZ00Nb16tHDcnZF/KALYI= 1024 35 127996390308881367982749181615590389946112714634614519843262364092321681710130910232611431762945334377336640067840062246513041629962755479231984134203580650174397517780096139161960264450818602524143591999435168314030504459201667428786398279613415241098669732580262057385208616093432930475934719992598708459451 That machine on which known_hosts exist, has been updated for many Debian versions (at least from Squeeze, probably from Woody). I seem to recall that the known_hosts contained plaintext FQDNs back in the time, and then some version decided to convert them to currently used hashed format. It seem that not all lines that were converted are recognized by recent openssh versions. * What outcome did you expect instead? that the offending line at line 200 is removed. -- System Information: Debian Release: 11.8 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.118+deb11u1 ii dpkg 1.20.13 ii libc6 2.31-13+deb11u7 ii libedit2 3.1-20191231-2+b1 ii libfido2-11.6.0-2 ii libgssapi-krb5-2 1.18.3-6+deb11u4 ii libselinux1 3.1-3 ii libssl1.1 1.1.1w-0+deb11u1 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages openssh-client recommends: ii xauth 1:1.1-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere ii ssh-askpass-gnome [ssh-askpass] 1:8.4p1-5+deb11u2 -- no debconf information
Bug#1053336: rsyslog: Removal of SysV init scripts is not prominent in docs
Package: rsyslog Version: 8.2302.0-1 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Hi, the rsyslog shipped in Bookworm no longer installs SysV init scripts. While that is maintainer prerogative; it is a regression on default upgrade path from Bullseye for all non-systemd init users which are silently left without running syslog deamon (and all associated issues stemming from that). (The fact that Bookworm release-notes do not mention that is not helping either, but that is another issue). Could we kindly indicate that end-of-sysV-support in rsyslog's NEWS.Debian (per https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#supplementing-changelogs-with-news-debian-files), and point users of non-default init systems to orphan-sysvinit-scripts package? Thank you for your consideration, Matija -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages rsyslog depends on: ii libc6 2.36-9+deb12u1 ii libelogind0 [libsystemd0] 246.10-1debian1 ii libestr0 0.1.11-1 ii libfastjson4 1.2304.0-1 ii liblognorm52.0.6-4 ii libuuid1 2.38.1-5+b1 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages rsyslog recommends: ii logrotate 3.21.0-1 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-openssl | rsyslog-gnutls pn rsyslog-relp -- no debconf information
Bug#1053008: singularity: more crash info
Package: singularity Version: 1.0.0-1 Followup-For: Bug #1053008 X-Debbugs-Cc: mnalis-debian...@voyager.hr It crashes at about once per hour or two. Buster version (0.30) was rock stable. % singularity Singularity 1.00 (commit: 2ebc2f3f2059b96885416167363bde2e27ece106) Running under Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] pygame 2.1.2 (SDL 2.26.5, Python 3.11.2) Hello from the pygame community. https://www.pygame.org/contribute.html The error-log configured as /home/mnalis/.local/share/singularity/log/error.log (lazily created when something is logged) Warning: can't fit on its parent. (432, 0) (1223, 26) (9, 36) (268, 26) Warning: can't fit on its parent. (204, 0) (1104, 26) (9, 36) (297, 26) Warning: can't fit on its parent. (0, 0) (998, 26) (9, 36) (329, 26) Warning: can't fit on its parent. (863, 0) (86, 26) (9, 36) (697, 26) Warning: can't fit on its parent. (0, 0) (998, 26) (9, 36) (329, 26) Warning: can't fit on its parent. (201, 0) (84, 26) (9, 36) (39, 26) Fatal Python error: pygame_parachute: (pygame parachute) Segmentation Fault Python runtime state: initialized Current thread 0x7f56125f96c0 (most recent call first): Thread 0x7f562baa42c0 (most recent call first): File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 272 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 674 in show File "/usr/lib/python3/dist-packages/singularity/code/screens/research.py", line 196 in show File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 125 in call_dialog File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 295 in show_dialog File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 247 in activated File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 213 in activate_with_sound File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 199 in handle_event File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 405 in call_handlers File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 390 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/code/safety.py", line 64 in safe_call File "/usr/lib/python3/dist-packages/singularity/code/screens/map.py", line 580 in show File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 125 in call_dialog File "/usr/lib/python3/dist-packages/singularity/code/screens/main_menu.py", line 109 in load_game File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 247 in activated File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 213 in activate_with_sound File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 199 in handle_event File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 405 in call_handlers File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 390 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/__init__.py", line 382 in main File "/usr/games/singularity", line 11 in Extension modules: pygame.base, pygame.constants, pygame.rect, pygame.rwobject, pygame.surflock, pygame.color, pygame.bufferproxy, pygame.math, pygame.surface, pygame.display, pygame.draw, pygame.event, pygame.imageext, pygame.image, pygame.joystick, pygame.key, pygame.mouse, pygame.time, pygame.mask, pygame.pixelcopy, pygame.transform, pygame.font, pygame.mixer_music, pygame.mixer, pygame.scrap, numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, pygame._freetype (total: 39) zsh: IOT instruction singularity -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages singularity depends on: ii fonts-dejavu-core 2.37-6 ii python33.11.2-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-polib 1.1.1-1 ii python3-pygame
Bug#1053008: singularity: segmentation fault crash
Package: singularity Version: 1.0.0-1 Severity: normal While waiting for time to pass, game crashes. The log file is not created, but console contains the following: % singularity Singularity 1.00 (commit: 2ebc2f3f2059b96885416167363bde2e27ece106) Running under Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] pygame 2.1.2 (SDL 2.26.5, Python 3.11.2) Hello from the pygame community. https://www.pygame.org/contribute.html The error-log configured as /home/mnalis/.local/share/singularity/log/error.log (lazily created when something is logged) Warning: can't fit on its parent. (0, 1037) (249, 43) (0, 0) (1920, 1080) Warning: can't fit on its parent. (0, 0) (1920, 1080) (0, 0) (1920, 1080) zsh: segmentation fault singularity -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages singularity depends on: ii fonts-dejavu-core 2.37-6 ii python33.11.2-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-polib 1.1.1-1 ii python3-pygame 2.1.2+dfsg-5+b1 Versions of packages singularity recommends: ii singularity-music 007-2 Versions of packages singularity suggests: ii timidity 2.14.0-8.1 -- no debconf information
Bug#1042460: openssh-client: ssh-agent CVE-2023-38408
Package: openssh-client Version: 1:8.4p1-5+deb11u1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: mnalis-debian...@voyager.hr, Debian Security Team "The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system." While it does not affect all users of ssh-agent, it does affect many of them and commonly suggested workaround (using jumphosts instead of agent forwarding) is not applicable to many use cases (git push over ssh, using libpam-ssh-agent-auth, etc.) https://security-tracker.debian.org/tracker/CVE-2023-38408 indicates that the new fixed version 1:9.3p2-1 has been uploaded in sid and trixie, however bookworm (stable) and bullseye (oldstable) still have no security fix since CVE release on 2023-07-20. (workaround by pinning fixed version from trixie is not possible, due to significant libraries clash; and there are no Debian backports either) -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-23-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.20.12 ii libc6 2.31-13+deb11u6 ii libedit2 3.1-20210910-1 ii libfido2-11.6.0-2 ii libgssapi-krb5-2 1.18.3-6+deb11u3 ii libselinux1 3.1-3 ii libssl1.1 1.1.1n-0+deb11u5 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages openssh-client recommends: pn xauth Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information
Bug#1036064: rss-bridge: Package newer upstream version (TwitterBridge no longer working)
Package: rss-bridge Version: 2022-01-20+dfsg1-1 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, Twitter changed server side again, and thus TwitterBridge stopped working (unable to find usernames and get tweets). Updating to latest version of Debian rss-bridge was not effective. Using latest upstream github branch fixed the issue. Can we have the package updated to the latest upstream git master? It fixes the issue: https://github.com/RSS-Bridge/rss-bridge/issues/3239#issuecomment-1546648731 -- System Information: Debian Release: 11.7 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages rss-bridge depends on: ii php-common 2:76 ii php-curl2:7.4+76 ii php-mbstring2:7.4+76 ii php-parsedown 1.7.4-1 ii php-xml 2:7.4+76 ii php7.4-curl [php-curl] 7.4.33-1+deb11u3 ii php7.4-json [php-json] 7.4.33-1+deb11u3 ii php7.4-mbstring [php-mbstring] 7.4.33-1+deb11u3 ii php7.4-xml [php-xml]7.4.33-1+deb11u3 Versions of packages rss-bridge recommends: ii apache2 [httpd] 2.4.56-1~deb11u2 ii libapache2-mod-php7.4 [libapache2-mod-php] 7.4.33-1+deb11u3 Versions of packages rss-bridge suggests: pn php-memcached pn php-sqlite3 -- Configuration Files: /etc/rss-bridge/config.ini.php changed [not included] /etc/rss-bridge/whitelist.txt changed [not included] -- no debconf information
Bug#928284: libxalan2-java: This bug is still present in Bullseye
Package: libxalan2-java Version: 2.7.2-4 Followup-For: Bug #928284 Dear Maintainer, I have exactly the same problem in Bullseye... Removing libxalan2-java package fixes the problem. % javaws josm-1.jnlp Codebase matches codebase manifest attribute, and application is signed. Continuing. See: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html for details. Starting application [org.openstreetmap.josm.gui.MainApplication] ... 2023-02-26 03:00:06.278 INFO: Log level is at INFO (INFO, 800) netx: Launch Error: Could not launch JNLP file. ( (Provider for class javax.xml.validation.SchemaFactory cannot be created (javax.xml.validation.SchemaFactory: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found))) net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. The application has not been initialized, for more information execute javaws/browser from the command line and send a bug report. at java.desktop/net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:582) at java.desktop/net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:945) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at java.desktop/net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:576) ... 1 more Caused by: javax.xml.validation.SchemaFactoryConfigurationError: Provider for class javax.xml.validation.SchemaFactory cannot be created at java.xml/javax.xml.validation.SchemaFactoryFinder.findServiceProvider(SchemaFactoryFinder.java:350) at java.xml/javax.xml.validation.SchemaFactoryFinder._newFactory(SchemaFactoryFinder.java:217) at java.xml/javax.xml.validation.SchemaFactoryFinder.newFactory(SchemaFactoryFinder.java:144) at java.xml/javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:245) at org.openstreetmap.josm.tools.XmlUtils.newXmlSchemaFactory(XmlUtils.java:58) at org.openstreetmap.josm.data.preferences.PreferencesReader.validateXML(PreferencesReader.java:97) at org.openstreetmap.josm.data.preferences.PreferencesReader.validateXML(PreferencesReader.java:85) at org.openstreetmap.josm.data.Preferences.loadDefaults(Preferences.java:502) at org.openstreetmap.josm.data.Preferences.init(Preferences.java:596) at org.openstreetmap.josm.gui.MainApplication.mainJOSM(MainApplication.java:825) at org.openstreetmap.josm.gui.MainApplication$3.processArguments(MainApplication.java:277) at org.openstreetmap.josm.gui.MainApplication.main(MainApplication.java:742) ... 6 more Caused by: java.util.ServiceConfigurationError: javax.xml.validation.SchemaFactory: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1212) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1221) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1268) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1267) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1270) at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300) at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385) at java.xml/javax.xml.validation.SchemaFactoryFinder$2.run(SchemaFactoryFinder.java:339) at java.xml/javax.xml.validation.SchemaFactoryFinder$2.run(SchemaFactoryFinder.java:335) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.xml/javax.xml.validation.SchemaFactoryFinder.findServiceProvider(SchemaFactoryFinder.java:335) ... 17 more % -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxalan2-java depends on: ii libxerces2-java 2.12.1-1 libxalan2-java recommends no packages. Versions of packages
Bug#1007556: uqm-content: please consider upgrading to 3.0 source format
Package: uqm-content Followup-For: Bug #1007556 X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, it has been fixed in uqm-content 0.8.0+deb-1 in Bookworm.
Bug#1010861: ready to salvage?
As there have now been more than the double of required 21 days https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging with no comment from maintainer, I propose that Stephen now continue with the salvaging process, if that is okay? -- Opinions above are GNU-copylefted.
Bug#1007556: already solved in salsa
That particular issue is already solved by me (among the other things, like new upstream version and other fixes) in Salsa MR: https://salsa.debian.org/games-team/uqm-content/-/merge_requests/2 https://salsa.debian.org/games-team/uqm-content/-/merge_requests/1 also noted in related package uqm in #640881 All it needs is little maintainer love to merge and release it. See the thread at https://lists.debian.org/debian-devel-games/2022/01/msg1.html -- Opinions above are GNU-copylefted.
Bug#902887: [fpc] Add dbgsym packages for packages compiled with FPC
On Fri, Jan 28, 2022 at 08:32:25PM +, Peter wrote: > -k--build-id > is an answer to getting dbgsym packages, > however I tried it out with c-evo and it is breaking reproducible build. > Looks like the build ID is a random string, so the two builds differ. Does it build reproducibily *without* "-k--build-id"? AFAIR fpc never built packages fully reproducibly for me - checks also complained at least about "captures_build_path" (which should not be related to build-id I think): https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ironseed.html and more detailed look showed even more differences than paths and build-id: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ironseed.html (I'd love it if fpc was able to create reproducable builds, but that seems to be material for another issue...) Relatedly, is "c-evo" packaged in Debian? I cannot seem to find it in the packages.debian.org, nor on mentors.debian.net under that name? -- Opinions above are GNU-copylefted.
Bug#1004153: rss-bridge: Could we have new release 2022-01-20 please?
Package: rss-bridge Version: 2020-11-10+dfsg1-1 Severity: normal Dear Maintainer, Latest version of rss-bridge in Debian is 2020-11-10 based; and there have been 2 upstream releases in the meantime, and especially the newest one (2022-01-20) has been released: https://github.com/RSS-Bridge/rss-bridge/releases/tag/2022-01-20 which (among other things) fixes Twitter bridge which has developed several serious problems (4xx/5xx errors which make it mostly unusable), so it would be highly appreciated if this new release could be packaged. Thanks for your consideration!
Bug#483637: should be fixed upstream in new release
I belive 0.8.0 release should fix it, as setup screen now has options to control aspect ratio. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640881#20 for more details about new release -- Opinions above are GNU-copylefted.
Bug#1003862: munin-node fails to start on traditional sysvinit system
Package: munin-node Version: 2.0.69-1~bpo11+1 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, * What led up to the situation? After upgrading from Stretch to Buster to Bullseye, munin-node (2.0.49-1) refuses to start. (Which was especially frustrating, as Debian fails to finish upgrading normally then). # /etc/init.d/munin-node start Starting Munin-Node service: munin-nodestart-stop-daemon: timed out waiting for a notification failed! In another window I can see the process started immideately, but init script never realizes that: root 23786 0.1 0.0 18768 15856 ?S05:04 0:00 /usr/bin/perl -wT /usr/sbin/munin-node --foreground * What exactly did you do (or not do) that was effective (or ineffective)? - Trying version from bullseye-backports (munin-node 2.0.67-1~bpo10+1) also fails to start. - increasing the timeouts (#954128) doesn't help - commenting out following two lines however makes munin node start (and stop) normally: START_ARGS="--background --notify-await --notify-timeout 15" DAEMON_ARGS="--foreground" * What was the outcome of this action? I was expecting that munin-node would start normally, and control returned to shell after issuing "/etc/init.d/munin-node start" * What outcome did you expect instead? "/etc/init.d/munin-node start" fails with an error after trying for 15 seconds, and munin-node does not start. Note: I'm using sysvinit, not systemd. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages munin-node depends on: ii init-system-helpers 1.60 ii libnet-server-perl 2.009-2 ii lsb-base 11.1.0 ii munin-common 2.0.69-1~bpo11+1 ii munin-plugins-core 2.0.67-3 ii netbase 6.3 ii perl 5.32.1-4+deb11u2 Versions of packages munin-node recommends: ii gawk 1:5.1.0-1 ii git 1:2.30.2-1 ii jo 1.3-2 ii jq 1.6-2.1 ii man-db [man] 2.9.4-2 ii munin-plugins-extra 2.0.67-3 ii perl-doc 5.32.1-4+deb11u2 ii procps 2:3.3.17-5 Versions of packages munin-node suggests: ii munin 2.0.67-3 pn munin-plugins-java -- no debconf information
Bug#640881: 0.8.0 prepared in Salsa
I've prepared Salsa MRs for new 0.8.0 release. I've done basic testing on amd64 and it seems to work fine, but if someone else would like to test it, it would be great. https://salsa.debian.org/games-team/uqm/-/merge_requests/4 https://salsa.debian.org/games-team/uqm-content/-/merge_requests/2 -- Opinions above are GNU-copylefted.
Bug#999131: uqm-russian: provide fix by using dh sequencer
Package: uqm-russian Version: 1.0.2-5 Followup-For: Bug #999131 X-Debbugs-Cc: mnalis-debian...@voyager.hr Control: tags -1 patch Here is a MR to fix this, by using dh sequencer: https://salsa.debian.org/games-team/uqm-russian/-/merge_requests/1
Bug#999132: uqm: patch to use "dh"
Package: uqm Version: 0.6.2.dfsg-9.5 Followup-For: Bug #999132 X-Debbugs-Cc: mnalis-debian...@voyager.hr Control: tags -1 patch I've provided a patch to fix this by using dh sequencer. https://salsa.debian.org/games-team/uqm/-/merge_requests/1
Bug#999132: is help needed?
Is help needed in converting debian/rules to use dh? I certainly wouldn't want uqm to fall out of Debian. -- Opinions above are GNU-copylefted.
Bug#975911: ctrl-w handling
I support idea that ctrl-w should retain behaviour that it had all those years in libreadline5, until it was removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980504 and libedit2 made an drop-in replacement. Could we please change the default keybindings in Debian libedit2 itself, instead of having to do same as having to create following ~/.editrc for all users on all systems in order for seamless transition? bind "^W" ed-delete-prev-word bind "^_" vi-undo Those two would at least (mostly) restore behaviour of two most missing/changed features. -- Opinions above are GNU-copylefted.
Bug#993471: mc crashes if ftp server specified on cmdline requires authentication
Package: mc Version: 3:4.8.26-1.1 Severity: normal Dear Maintainer, Trying to specify FTP URL with username crashes mc if invoked from command line. For example: mc /tmp ftp://someuser@192.168.43.1:2121/ mc would start to show the dialog to ask password, and then crash: ┌─── FTP: Password required for someuser ───┐ │ Password: │ │ zsh: segmentation fault mc /tmp ftp://someuser@192.168.43.1:2121/ │ * What exactly did you do (or not do) that was effective (or ineffective)? - When invoked via menus (eg. F9 / Right / FTP link / ftp://mnalis@192.168.43.1:2121/) it asks for password normally and connects. - if anonymous FTP is attempted (which does not require inputting password) it works. - if correct password is also specified on command line, it also works - if incorrect password is specified on command line, it fails as it tries to re-ask the password - Also, it worked in Buster version of mc just fine. After upgrade to Bullseye it crashes. In short, it seems to crash only if URL which was specified IN COMMAND LINE requires some user input. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mc depends on: ii libc6 2.31-13 ii libext2fs21.46.2-2 ii libglib2.0-0 2.66.8-1 ii libgpm2 1.20.7-8 ii libslang2 2.3.2-5 ii libssh2-1 1.9.0-2 ii mc-data 3:4.8.26-1.1 Versions of packages mc recommends: ii mime-support3.66 ii perl5.32.1-4+deb11u1 ii sensible-utils 0.0.14 ii unzip 6.0-26 Versions of packages mc suggests: pn arj ii bzip21.0.8-4 pn catdvi | texlive-binaries ii dbview 1.0.4-4 pn djvulibre-bin ii epub-utils 0.2.2-4+b4 ii evince [pdf-viewer] 3.38.2-1 ii file 1:5.39-3 ii genisoimage 9:1.1.11-3.2 pn gv ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 pn libaspell-dev ii lynx 2.9.0dev.6-3~deb11u1 pn odt2txt ii poppler-utils20.09.0-3.1 pn python pn python-boto pn python-tz pn unar ii w3m 0.5.3+git20210102-6 pn wimtools ii zip 3.0-12 -- no debconf information
Bug#991622: munin-plugins-core: reported upstream
Package: munin-plugins-core Version: 2.0.67-1~bpo10+1 Followup-For: Bug #991622 I've reported it upstream at https://github.com/munin-monitoring/munin/issues/1412 In current git master version there, it seems to already be fixed in different way. So updating to newer upstream should fix the bug in Debian too.
Bug#991622: munin-plugins-core: mysql_ plugin sometimes fails with "Unknown section: Main thread process..."
Package: munin-plugins-core
Version: 2.0.67-1~bpo10+1
Severity: normal
Tags: patch
Dear Maintainer,
* What led up to the situation?
munin plugin mysql_, invoked as for example mysql_qcache (or any other,
sometimes (but not always) fails with errors like:
Unknown section: Main thread process no. 21673, id 139511430366976,
state: sleeping at /etc/munin/plugins/mysql_qcache line 1382
thus resulting in VERY unusable mysql munin stats (about 20% visible,
80% broken in my case)
* What exactly did you do (or not do) that was effective (or
ineffective)?
tried upgrading munin-plugins-core all the way from 2.0.33-1, via
2.0.49-1~bpo9+1:to 2.0.67-1~bpo10+1
* What was the outcome of this action?
error still sporadically happens
* What outcome did you expect instead?
I expected the plugin to not die with error, but instead returns
available data.
After some debugging, I found out the problem is output of "show engine innodb
status"
which sometimes (when mysql views are used in some way?) returns this output on
which
mysql_ barfs:
--
ROW OPERATIONS
--
0 queries inside InnoDB, 0 queries in queue
2 read views open inside InnoDB
1 RW transactions active inside InnoDB
0 RO transactions active inside InnoDB
1 out of 1000 descriptors used
---OLDEST VIEW---
Normal read view
Read view low limit trx n:o 14142166371
Read view up limit trx id 14142166371
Read view low limit trx id 14142166371
Read view individually stored trx ids:
-
Main thread process no. 21673, id 139511430366976, state: sleeping
Number of rows inserted 9568126016, updated 1596177407, deleted 515944374,
read 15378019524560
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 1602.00 reads/s
END OF INNODB MONITOR OUTPUT
instead of this output which is parsed OK:
--
ROW OPERATIONS
--
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
0 RW transactions active inside InnoDB
0 RO transactions active inside InnoDB
0 out of 1000 descriptors used
Main thread process no. 21673, id 139511430366976, state: sleeping
Number of rows inserted 9568124954, updated 1596176891, deleted 515943708,
read 15377906700512
0.17 inserts/s, 1.67 updates/s, 0.00 deletes/s, 880245.13 reads/s
END OF INNODB MONITOR OUTPUT
Attached patch quickly removes the offending (non-standardly formatted) and
unused "---OLDEST VIEW---" section, thus fixing the issue.
-- System Information:
Debian Release: 9.8
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.67-1~bpo10+1
ii perl 5.24.1-3+deb9u5
Versions of packages munin-plugins-core recommends:
pn libnet-snmp-perl
Versions of packages munin-plugins-core suggests:
pn acpi | lm-sensors
pn conntrack
pn default-mysql-client
ii ethtool 1:4.8-1+b1
ii hdparm9.51+ds-1+deb9u1
ii libcache-cache-perl 1.08-2
ii libdbd-mysql-perl 4.041-2
pn libdbd-pg-perl
ii libhttp-date-perl 6.02-1
ii liblwp-useragent-determined-perl 1.07-1
pn libnet-dns-perl
pn libnet-ip-perl
pn libnet-irc-perl
pn libnet-ldap-perl
pn libnet-netmask-perl
pn libnet-telnet-perl
ii libwww-perl 6.15-1
pn libxml-parser-perl
pn libxml-simple-perl
pn logtail
ii net-tools 1.60+git20161116.90da8a0-1
ii python3 3.5.3-1
pn ruby
ii smartmontools 6.5+svn4324-1
-- no debconf information
--- /usr/share/munin/plugins/mysql_.orig2021-03-08 11:57:43.0
+0100
+++ /usr/share/munin/plugins/mysql_ 2021-07-28 21:33:05.984676113 +0200
@@ -1348,6 +1348,9 @@
sub parse_innodb_status {
local $_ = shift;
+# remove non-stanard (and useless) "---OLDEST VIEW---" section, as it
breaks the plugin
+s{^---OLDEST VIEW---\v.*?^-\v}{}ms;
+
# Add a dummy section to the end in case the innodb status output
# has been truncated (Happens for status > 64K characters)
$_ .= "\n--\nDUMMY\n";
Bug#991338: ftp-ssl: uploading with TLS fails after transfer
Package: ftp-ssl
Version: 0.17.34+0.2-5.1
Severity: normal
Tags: patch
X-Debbugs-Cc: mnalis-debian...@voyager.hr
Dear Maintainer,
* What led up to the situation?
Trying to upload to vsftpd server (3.0.3-12) with ftp-ssl using TLS.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Uploading via plaintext FTP works normally. Tryed changing vsftpd options - did
not help.
Fixing the ftp-ssl code helped.
* What was the outcome of this action?
File uploads, but returns error "426 Failure reading network stream."
* What outcome did you expect instead?
File uploads cleanly, without errors.
here is example transaction:
tekko% date > test.txt
tekko% ls -l test.txt
-rw-r--r-- 1 test test 30 Jul 21 02:34 test.txt
tekko% ftp-ssl -z secure ftp.example.org
Connected to ftp.example.org.
220 Welcome to VSFTPD
Name (ftp.example.org:test): test
234 Proceed with negotiation.
[SSL Cipher TLS_AES_256_GCM_SHA384]
200 PBSZ set to 0.
200 PROT now Private.
[Encrypted data transfer.]
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.
ftp> put test.txt
local: test.txt remote: test.txt
227 Entering Passive Mode (195,190,136,132,242,251).
150 Ok to send data.
426 Failure reading network stream.
30 bytes sent in 0.00 secs (770.9705 kB/s)
ftp> dir test.txt
227 Entering Passive Mode (195,190,136,132,240,196).
150 Here comes the directory listing.
-rw-r--r--1 ftp ftp30 Jul 21 02:35 test.txt
226 Directory send OK.
ftp>
I've looked up the ftp-ssl source, as well the official docs and did some
debugging.
Problem seems to be that ftp-ssl is closing file descriptor before doing
SSL_shutdown(),
thus losing unsent SSL data, which vsftpd then complains about.
So when SSL_shutdown() does run in ftp-ssl code, it then returns -1 as socket
is already gone. According to the docs at
https://linux.die.net/man/3/ssl_shutdown,
client should first call SSL_shutdown() (if needed twice), and only then should
the
socket be closed. Attached patch does so as documentation directs, and thus
fixes
the problem for me - uploads now finish with regular "226 Transfer complete."
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages ftp-ssl depends on:
ii libc6 2.31-12
ii libedit2 3.1-20191231-2+b1
ii libssl1.1 1.1.1k-1
ii netbase6.3
ftp-ssl recommends no packages.
ftp-ssl suggests no packages.
-- no debconf information
--- netkit-ftp-ssl-0.17.34+0.2/ftp/ftp.c.orig 2021-07-21 02:59:00.0
+0200
+++ netkit-ftp-ssl-0.17.34+0.2/ftp/ftp.c2021-07-21 02:59:30.632103435
+0200
@@ -947,18 +947,20 @@
INTON;
}
INTOFF;
- (void) fclose(dout);
- dout = NULL;
#ifdef USE_SSL
if (ssl_data_active_flag && (ssl_data_con!=NULL)) {
- SSL_shutdown(ssl_data_con);
+ fflush(dout);
+ if (SSL_shutdown(ssl_data_con) == 0) SSL_shutdown(ssl_data_con);
SSL_free(ssl_data_con);
ssl_data_active_flag=0;
ssl_data_con=NULL;
}
#endif /* USE_SSL */
+ (void) fclose(dout);
+ dout = NULL;
+
/* closes data as well, so discard it */
data = -1;
INTON;
Bug#982565: unattended-upgrades: fixed in bullseye
Package: unattended-upgrades Followup-For: Bug #982565 X-Debbugs-Cc: mnalis-debian...@voyager.hr Bug seems to be fixed in bullseye version of unattended-upgrades 2.8 -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.75 ii lsb-base 11.1.0 ii lsb-release11.1.0 ii python33.9.2-2 ii python3-apt2.1.7 ii python3-dbus 1.2.16-5 ii python3-distro-info1.0 ii ucf3.0043 ii xz-utils 5.2.5-2 Versions of packages unattended-upgrades recommends: ii cron [cron-daemon] 3.0pl1-137 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20180807cvs-2 pn needrestart ii nullmailer [mail-transport-agent] 1:2.2-3 ii powermgmt-base 1.36 pn python3-gi -- debconf information: unattended-upgrades/enable_auto_updates: true
Bug#985825: do not remove useful packages due to political issues, please
Whatever you decide, please, do not consider *removing* useful package, just due to name controversy. That is not a good path to go down, IMHO. After all, we still have several "reiserfs" named packages in Debian main, and one should well argue that Hans Reiser actions were much bigger atrocity than RMS-based one. Perhaps check-dfsg-status might be good binary name (akin to check-support-status from debian-security-support package) if you are looking for non-controversial and easier to understand name. Please do contact release team ASAP to check about what renaming possibilities are available, and in what timeframes.
Bug#982565: it seems to be due to not using systemd
I've added some basic debugging of my own, and it seems it is caused by transitive_dependencies() function in /usr/bin/unattended-upgrade being called with pkg.name="systemd" Note: I run sysvinit, and do not have "systemd" package installed. Are there any workarounds for using unattened-upgrade with sysvinit (eg. without systemd) in Buster? How about Bullseye? Thanks, Matija -- Opinions above are GNU-copylefted.
Bug#982565: Exception: 'NoneType' object has no attribute 'dependencies' (fails installing packages)
Package: unattended-upgrades Version: 1.11.2 Severity: normal Dear Maintainer, * What led up to the situation? Trying to run unattended-upgrades does not result in upgraded packages (neither when done automatically nor manually) Running it manually with "unattended-upgrades -d" ends with following lines: Packages that will be upgraded: apt apt-utils base-files ca-certificates distro-info-data file grub-common grub-pc grub-pc-bin grub2-common iproute2 libapt-inst2.0 libapt-pkg5.0 libefiboot1 libefivar1 libgnutls30 libjpeg62-turbo libldap-2.4-2 libldap-common libmagic-mgc libmagic1 libp11-kit0 libpq5 libsqlite3-0 libssl-dev libssl1.1 libsystemd0 libudev1 libxml2 libzstd1 linux-image-amd64 linux-libc-dev openssl postgresql-11 postgresql-client-11 python-apt-common python-lxml python3-apt sudo tcpdump tzdata udev unzip Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log Exception: 'NoneType' object has no attribute 'dependencies' InstCount=0 DelCount=0 BrokenCount=0 Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2021-02-11 23:06:20 However it does not upgrade packages, and /var/log/unattended-upgrades/unattended-upgrades-dpkg.log remains zero-byte sized. * What exactly did you do (or not do) that was effective (or ineffective)? I seem to recall it working back in Stretch... I've tried running it manually and automatically for few weeks. I've also tried purging and reinstalling unattended-upgrades, as well as changing Unattended-Upgrade::MinimalSteps to "false" and to "true" - none of that helps. * What was the outcome of this action? I expected unattended-upgrades to automatically upgrade packages. * What outcome did you expect instead? Instead it dies with "Exception: 'NoneType' object has no attribute 'dependencies'" without upgrading packages. *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.71 ii lsb-base 10.2019051400 ii lsb-release10.2019051400 ii python33.7.3-1 ii python3-apt1.8.4.1 ii python3-dbus 1.2.8-3 ii python3-distro-info0.21 ii ucf3.0038+nmu1 ii xz-utils 5.2.4-1 Versions of packages unattended-upgrades recommends: ii cron [cron-daemon] 3.0pl1-134+deb10u1 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20180807cvs-1 ii needrestart3.4-5 ii nullmailer [mail-transport-agent] 1:2.2-3 ii powermgmt-base 1.34 ii python3-gi 3.30.4-1 -- debconf information: * unattended-upgrades/enable_auto_updates: true
Bug#973566: pidgin: workaround
Package: pidgin Version: 2.13.0-2+b1 Followup-For: Bug #973566 There is also an workaround on Debian Buster: in Pidgin, one can select "Tools" / "Plugins" and install "NSS Preferences 2.13.0" plugin, and then click "Configure": here one can select what TLS versions and ciphers will be used, *including* TLS1.3 So I've installed it, enabled "min TLS1.2" and "max TLS1.3" and now it connects to TLS1.3-only server jabber.fsfe.org just fine. Why using best supported TLS protocol isn't default behaviour in Pidgin is something that should probably be addressed.
Bug#973566: pidgin: jabber/XMPP connection fails with "SSL Handshake failed"
Package: pidgin Version: 2.13.0-2+b1 Followup-For: Bug #973566 For me, the same error "SSL Handshake Failed" started happening with pidgin 2.13.0-2+b1 on Debian Buster about a week ago. Interestingly, one TLS XMPP account work just fine, but other TLS XMPP account (on jabber.fsfe.org) started failing. So it is not that whole of XMPP if broken in Pidgin. Interestingly enough, I can still use other TLS XMPP Clients (like Android client "Conversations v2.9.6+FCR" from f-droid.org) to connect to that jabber.fsfe.org server just fine, so it is not and issue that FSFE XMPP server is broken for all clients, either. "pidgin -d" when pressing reconnect it fails and prints: (17:16:46) jabber: Sending (redac...@jabber.fsfe.org/redacted): (17:16:46) jabber: Recv (50): (17:16:46) nss: Handshake failed (-12286) (17:16:46) connection: Connection error on 0x557f6ad65f00 (reason: 5 description: SSL Handshake Failed) Seraching the web for "nss: Handshake failed (-12286)" finds https://github.com/fchat-pidgin/fchat-pidgin/issues/156#issuecomment-305260240 whish says it means "SSL_ERROR_NO_CYPHER_OVERLAP" which is somewhat more informative. I've also managed to use "wireshark" to see Pidgin tries to use TLS 1.2 (why not 1.3? It seems supported in Buster otherwise?), and that seems to fail when trying to connect to jabber.fsfe.org XMPP server (I've contacted FSFE). Manually verifying in shell seems to confirm this case to be combination of jabber.fsfe.org configuration issue of only supporting TLS 1.3, and Buster Pidgin issue of not supporting TLS 1.3: % openssl s_client -connect jabber.fsfe.org:5222 -starttls xmpp -servername jabber.fsfe.org -tls1_3 works, but % openssl s_client -connect jabber.fsfe.org:5222 -starttls xmpp -servername jabber.fsfe.org -tls1_2 fails with: CONNECTED(0003) 140641803256960:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 So, probably not a bug in Pidgin (although I do hope Pidgin will support TLS1.3 in Bullseye? right?) I'm writing this anyway so other poor soul that gets such error can try to narrow down what is the problem. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages pidgin depends on: ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4+deb10u1 ii libdbus-1-3 1.12.20-0+deb10u1 ii libdbus-glib-1-20.110-4 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3+deb10u2 ii libgadu31:1.12.2-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk2.0-0 2.24.32-3 ii libgtkspell02.0.16-1.2 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangoft2-1.0-0 1.42.4-8~deb10u1 ii libpurple0 2.13.0-2+b1 ii libsm6 2:1.2.3-1 ii libx11-62:1.6.7-1+deb10u1 ii libxss1 1:1.2.3-1 ii perl-base [perlapi-5.28.0] 5.28.1-6+deb10u1 ii pidgin-data 2.13.0-2 Versions of packages pidgin recommends: ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2 ii gstreamer1.0-plugins-base 1.14.4-2 ii gstreamer1.0-plugins-good 1.14.4-1 ii gstreamer1.0-pulseaudio1.14.4-1 Versions of packages pidgin suggests: ii libsqlite3-0 3.27.2-3+deb10u1 -- no debconf information
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
On Sun, Jan 24, 2021 at 01:15:51AM +0100, Iain Buclaw wrote: > The logmake application runs just fine here. Fix has been committed to > gcc mainline, and backported to the version 9 and 10 release branches. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98806 Thanks a lot for your work, Iain! Do you think it might make it in Debian for Bullseye? Cheers, Matija -- Opinions above are GNU-copylefted.
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
> > (mipsel-chroot)$ printf 'import std.stdio;\nvoid main() { writeln("Hello,
> > World!"); }\n' > hello.d ; gdc hello.d && ./a.out
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault
> >
> > This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
> > but the other not-too-complicated D programs fail on Debian buildd
> > infrastructure too:
> > https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
>
> Building current gdc-master on a MIPS server (running Debian Jessie, I
> don't seem to have access to the Buster node), I can't reproduce the
> segfault. What are the chances of it being QEMU that's the cause?
I would be first to blame qemu in my virtual chroot on amd64, but I
was under impression the Debian buildd machine that failed was real
hardware? I could be wrong though, this is information for buildd machine
referenced in bug report where gdc failed:
https://db.debian.org/machines.cgi?host=eberlin
The program there segfaulted there was more complex than simple "hello world",
though.
(but it does work without any problems on all other architectures with gdc)
> Also, are you linking to the static or shared libphobos library?
shared (default):
(mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
ii gdc4:10.2.1-1 mipsel D compiler (language version 2),
based on the GCC backend
(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV),
dynamically linked, interpreter /lib/ld.so.1,
BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0,
not stripped
(mipsel-chroot):/tmp/w$ ldd a.out
libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
/lib/ld.so.1 (0x7ffc9000)
But good point, when I try to link this "hello world" example statically, it
throws warnings, but works!
(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
warning: Using 'dlopen' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in
function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
warning: Using 'gethostbyname' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
Hello, World!
(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (GNU/Linux),
statically linked, BuildID[sha1]=2da3a20d4fe083f1c33f79e4d259f91f8ed7696d, for
GNU/Linux 3.2.0, with debug_info, not stripped
(mipsel-chroot):/tmp/w$ dpkg -l "libgphobos*" | grep '^ii'
ii libgphobos-10-dev:mipsel 10.2.1-6 mipsel Phobos D standard library
ii libgphobos-dev:mipsel10.2.1-1 mipsel Phobos D standard library
ii libgphobos1:mipsel 10.2.1-6 mipsel Phobos D standard
library (runtime library)
> Running the testsuite now, to see if there's any reported failures, but
> none so far...
However, when I try to build and run the more complex program
Data_Generators/makedata/logmake.d
from this version:
http://snapshot.debian.org/archive/debian/20210115T023714Z/pool/main/i/ironseed/ironseed_0.3.6-4.dsc
it still fails with segfault on my qemu mipsel chroot, even when '-static' is
added
(as it did on Debian buildd machine "eberlin.debian.org"):
(mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ gdc -static -o
Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d
Data_Generators/makedata/data.d && Data_Generators/makedata/logmake
Data_Generators/makedata/logs.txt data/titles.dta data/log.dta
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
function
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Package: gdc
Version: 4:10.2.1-1
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr
Dear Maintainer,
compiling D programs with gdc produces excutable, but trying to run that
executable segfaults.
I've tried various gdc flags, but never managed to produce even the simplest
working program.
on Debian Sid in chroot:
(mipsel-chroot)$ printf 'import std.stdio;\nvoid main() { writeln("Hello,
World!"); }\n' > hello.d ; gdc hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
but the other not-too-complicated D programs fail on Debian buildd
infrastructure too:
https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: mipsel (mips)
Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages gdc depends on:
ii gdc-10 10.2.1-6
ii libgphobos-dev 10.2.1-1
gdc recommends no packages.
gdc suggests no packages.
-- no debconf information
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
On Tue, Dec 29, 2020 at 03:20:14PM +0100, Abou Al Montacir wrote: > Why gcc10 and not gcc8? I assume you are using sid.But then we need a way to > avoid hard coding the gcc version. Yes, gcc-10 is what build-essential installs on Sid (and Bullseye), which is what I am using there (as I'm trying to prepare my package using fpc for Bullseye). As for hard coding, those paths are ALREADY hard-coded at least for Intel architectures (amd64, i386), for example: - on amd64 Buster, /etc/fpc-3.0.4.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif - on i386 Sid, /etc/fpc-3.2.0.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif That hard-coded paths seem to already be auto-generated on build somehow. Note that current values also seem wrong if one is using multiarch / cross-compiling; as a path for "ifdef cpui386" should probably be different than than the one for "ifdef cpux86_64". I see two ways to fix this bug: - easier: Just remove the ifdefs, that is make that whole block just one line: -Fl/usr/lib/gcc/$TRIPLET/$GCC # whatever variable names are... eg. -Fl/usr/lib/gcc/i686-linux-gnu/10 # when generating binary package on i386 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 # when generating binary package on amd64 -Fl/usr/lib/gcc/arm-linux-gnueabi/10 # when generating binary package on armel etc. Then it will be behaving just it does now on amd64 and i386, but would also fix arm and other non-intel architectures - better (also fixing not just arm* builds, but multiarch too), but more work: Do not generate that block using variables, instead hard-code it manually for each Debian release and supported architectures from https://wiki.freepascal.org/Platform_defines, eg. #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 #endif #ifdef cpuarm -Fl/usr/lib/gcc/arm-linux-gnueabi/10 #endif #etc... While it needs more testing to find all the correct fpc ifdefs and gcc path triplets, it would fix all supported architectures, and make it more multiarch friendly (although there might be other multiarch blockers, I haven't checked) -- Opinions above are GNU-copylefted.
Bug#854889: still fails with qemu from buster-backports
found 854889 qemu/1:5.0-14~bpo10+1 thanks sparc64 bug is still there with qemu-user-static 1:5.0-14~bpo10+1, trying to enter qemu-debootstrap chroot with qemu-sparc64-static: user@phyhost> sudo chroot sid bin/bash ; echo "EXIT $?" *** longjmp causes uninitialized stack frame ***: terminated EXIT 0 Some simple commands run, and then terminate qemu-sparc64-static immediately: user@phyhost> sudo chroot sid bin/dash ; echo "EXIT $?" # arch sparc64 EXIT 0 user@phyhost> sudo chroot sid md5sum /usr/bin/qemu-sparc64-static ; echo "EXIT $?" a335ea29569463a13455746e67abc56c /usr/bin/qemu-sparc64-static EXIT 0 user@phyhost> -- Opinions above are GNU-copylefted.
Bug#978153: libgphobos-10-dev: include/d/std/stdio.d (and rest of std/*) missing on PowerPC (eg. ppc64el) architectures only
Package: libgphobos-10-dev Version: 10.2.1-3 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, * What led up to the situation? after installing "gdc" and its dependencies on ppc64el, trying to compile my D program having "import std.stdio;" fails with error. (in this case causing sid FTBFS of https://packages.debian.org/sid/ironseed on ppc64el architecture) * What exactly did you do (or not do) that was effective (or ineffective)? I've tried to find a missing file. On other architectures, libgphobos-10-dev contains that file, eg.: ./usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/stdio.d ./usr/lib/gcc/arm-linux-gnueabi/10/include/d/std/stdio.d ./usr/lib/gcc/s390x-linux-gnu/10/include/d/std/stdio.d etc. but on ppc64el whole following directory is missing: ./usr/lib/gcc/powerpc64le-linux-gnu/10/include/d/std/ The problem seems to be the same on all PowerPC architectures, eg. missing files in: - libgphobos-10-dev_10.2.1-3_ppc64el.deb - libgphobos-10-dev_10.2.1-1_ppc64el.deb - libgphobos-11-dev_11-20201222-1_ppc64el.deb - libgphobos-10-dev-ppc64el-cross_10.2.1-1cross1_all.deb - libgphobos-10-dev-ppc64-cross_10.2.1-1cross1_all.deb - libgphobos-10-dev-powerpc-cross_10.2.1-1cross1_all.deb (std/stdio.d missing in that architecture, but present in others) libgphobos-9-dev did not contain ppc* architectures on http://ftp.debian.org/debian/pool/main/g/gcc-9/, so I did not test further back. * What was the outcome of this action? On ppc64el architecture, build fails with following error: gdc -g -o Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d Data_Generators/makedata/data.d Data_Generators/makedata/logmake.d:26:8: error: module stdio is in file 'std/stdio.d' which cannot be read 26 | import std.stdio; |^ import path[0] = /usr/lib/gcc/powerpc64le-linux-gnu/10/include/d make: *** [Makefile:147: Data_Generators/makedata/logmake] Error 1 * What outcome did you expect instead? Finding a std/stdio.d file, resulting in successful compilation. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libgphobos-10-dev depends on: ii gcc-10-base 10.2.1-3 ii libgphobos1 10.2.1-3 ii zlib1g-dev 1:1.2.11.dfsg-2 libgphobos-10-dev recommends no packages. libgphobos-10-dev suggests no packages. -- no debconf information
Bug#902887: -dbgsym not working
Answering myself (and other parties interested in fpc/debug packages): fpc 3.2.0 will build -dbgsym packages correctly automatically if "-k--build-id" is added to all fpc invocations (or to /etc/fpc.conf file) -- Opinions above are GNU-copylefted.
Bug#902887: -dbgsym not working
Well, does FPC actually support building in a way that allow dbgsym packages? Specifically, with most basic dh(1) debian/rules, I'm getting "dh_strip: warning: Could not find the BuildID in debian/ironseed/usr/libexec/ironseed/main" warnings in sid with fpc 3.2.0+dfsg-8, and resulting -dbgsym file is unusable by gdb. I've tried various compilation options, last one being: fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO -O1 -gw -godwarfsets -gt -vewnhiq -Sa -Sy -Sewnh -vm4049 -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' -k-pie main.pas that works for debugging with gdb when symbols are not extracted, but not in -dbgsym case. (package is currently at https://incoming.debian.org/debian-buildd/pool/main/i/ironseed/ironseed_0.3.2-2.dsc) Do we have some other packages using fpc, which have working -dbgsym? Or does fpc itself need some changes for it to work? -- Opinions above are GNU-copylefted.
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Package: fpc Version: 3.2.0+dfsg-8 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, * What led up to the situation? trying to compile my source throws warnings (which subsequently causes failure to build due to "-Sewnh". I can of course remove that option and continue build even in presence of warnings, but would like to fix the problem at the source, as it is simple fix): fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO -O1 -gw -godwarfsets -gt -vewnhiq -Sa -Sy -vm4049 -Sewnh -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' -k-pie is.pas Hint: (11030) Start of reading config file /etc/fpc.cfg Hint: (11031) End of reading config file /etc/fpc.cfg Free Pascal Compiler version 3.2.0+dfsg-8 [2020/08/22] for arm Copyright (c) 1993-2020 by Florian Klaempfl and others (1002) Target OS: Linux for ARMHF (3104) Compiling is.pas (3104) Compiling _paths_.pas (9015) Linking is is.pas(86,1) Warning: (9034) "crtbeginS.o" not found, this will probably cause a linking failure is.pas(86,1) Warning: (9034) "crtendS.o" not found, this will probably cause a linking failure is.pas(86,1) Fatal: (10026) There were 2 errors compiling module, stopping Fatal: (1018) Compilation aborted Error: /usr/bin/ppcarm returned an error exitcode make: *** [Makefile:83: is] Error 1 * What exactly did you do (or not do) that was effective (or ineffective)? it seems that required /usr/lib/gcc/X/ library path is not included on fpc.cfg on ARM architectures (https://buildd.debian.org/status/package.php?p=ironseed shows that warnings at least for arm64, armel, armhf) It is mentioned in FAQ at https://wiki.lazarus.freepascal.org/Lazarus_Faq#I_receive_a_warning_during_the_linking_that_states:_Warning:_.22crtbeginS.o.22_.28or_.22crtendS.o.22.29_not_found and manually adding "-Fl/usr/lib/gcc/arm-linux-gnueabihf/10" to /etc/fpc-3.2.0.cfg fixes the problem. Similar library path is already present for amd64/i386 inside ifdef marked with "# path to the gcclib". It should be simple to add it to non-intel architectures too. * What was the outcome of this action? The two warnings show above appear (and so build fails due to '-Sewnh') * What outcome did you expect instead? No warnings, and sucessful build on ARM. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages fpc depends on: ii fp-docs-3.2.0 3.2.0+dfsg-8 ii fp-utils-3.2.0 3.2.0+dfsg-8 ii fpc-3.2.0 3.2.0+dfsg-8 fpc recommends no packages. fpc suggests no packages. -- no debconf information
Bug#974810: RFS: ironseed/0.2.8-1 [ITP] -- science-fiction exploration/strategy adventure game in space
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "ironseed": * Package name: ironseed Version : 0.2.8-1 Upstream Author : Matija Nalis * URL : https://github.com/mnalis/ironseed_fpc * License : GPL-2+, GPL-3+ * Vcs : https://salsa.debian.org/mnalis/ironseed Section : games It builds those binary packages: ironseed-data - science-fiction exploration/strategy adventure game in space - data files ironseed - science-fiction exploration/strategy adventure game in space To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ironseed/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ironseed/ironseed_0.2.8-1.dsc Changes for the initial release: ironseed (0.2.8-1) unstable; urgency=low . * Initial release. Closes: #971924 Regards, Matija Nalis -- Opinions above are GNU-copylefted.
Bug#971924: RFP: ironseed -- science-fiction exploration/strategy adventure game in space
On Thu, Oct 22, 2020 at 11:32:38AM +0100, Sudip Mukherjee wrote: > On Fri, Oct 09, 2020 at 10:46:34PM +0200, Matija Nalis wrote: > > Package: wnpp > > Severity: wishlist > > > > * Package name: ironseed > > Version : 0.2.4 > > Upstream Author : Matija Nalis > > * URL : https://github.com/mnalis/ironseed_fpc > > * License : GPLv3 > > Programming Lang: Pascal > > Description : science-fiction exploration/strategy adventure game in > > space > > > > > You should retitle this bug as "ITP" and then look at > https://mentors.debian.net/intro-maintainers/ > Your package will need some minor work, like version etc. And also it > fails to build for me with: Thanks for your suggestions! I've since retitled as ITP, did a lot of extra reading, fixed the compile bug, cleaned up the lintian stuff and prepared version at https://mentors.debian.net/package/ironseed/ If you'd like to take a look and try it, I'd appreciate any feedback! Cheers, Matija -- Opinions above are GNU-copylefted.
Bug#974750: imagemagick-6.q16: Convert to .tga (Targa) now flips image upside-down
Package: imagemagick-6.q16 Version: 8:6.9.11.24+dfsg-1+b2 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, Converting to .tga (Targa) format now (Unstable) flips image upside-down. It worked fine in Buster version (imagemagick 8:6.9.10.23+dfsg-21+deb10u1) and it still works fine with graphicsmagick version in Unstable (graphicsmagick 1.4+really1.3.35+hg16348-1+b1). So this is regression. Resulting .tga image created by Sid version of imagemagick 8:6.9.11.24+dfsg-1+b2 is consistently vertially flipped when viewed in all viewers (gimp, xzgv, xli, mirage, and even imagemagick's own display(1)) One can kludge around by using "convert-im6 -flip" to get correct image, but it is wrong behaviour. sid% convert-im6.q16 Graphics_Assets/intro5.png /tmp/imagemagick_sid.tga sid% gm convert Graphics_Assets/intro5.png /tmp/graphicsmagick_sid.tga sid% convert-im6 -flip Graphics_Assets/intro5.png /tmp/imagemagick_flip_sid.tga sid% md5sum /tmp/*_sid.tga 81d1f1a2c481958c5af09c3985615ed0 /tmp/graphicsmagick_sid.tga 81d1f1a2c481958c5af09c3985615ed0 /tmp/imagemagick_flip_sid.tga d948d272cbb2ab8230ee0b185414e6c6 /tmp/imagemagick_sid.tga buster% convert-im6.q16 Graphics_Assets/intro5.png /tmp/imagemagick_buster.tga buster% md5sum /tmp/imagemagick_buster.tga 81d1f1a2c481958c5af09c3985615ed0 /tmp/imagemagick_buster.tga It happens with any source file; I've tried with several .png and .jpg files as source, for example /usr/share/desktop-base/spacefun-theme/login/sddm-preview.jpg or /usr/lib/libreoffice/share/template/wizard/bitmap/euro_2.png Bug only happens when converting to .tga (converting to png/jpg/tiff works normally) Of course, the nature of bug is such that if you convert from .png to .tga, and then back from .tga to .png, the seconds .png will again look correct, as bug happened twice and thus fixed itself again! -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org compare: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org convert: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org composite: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org conjure: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org display: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org identify: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org import: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org mogrify: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org montage: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org stream: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-2-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages imagemagick-6.q16 depends on: ii hicolor-icon-theme 0.17-2 ii libc6 2.31-4 ii libmagickcore-6.q16-6 8:6.9.11.24+dfsg-1+b2 ii libmagickwand-6.q16-6 8:6.9.11.24+dfsg-1+b2 Versions of packages imagemagick-6.q16 recommends: pn ghostscript pn libmagickcore-6.q16-6-extra pn netpbm Versions of packages imagemagick-6.q16 suggests: pn autotrace pn cups-bsd | lpr | lprng ii curl7.72.0-1 pn enscript pn ffmpeg pn gimp pn gnuplot pn grads pn graphviz ii groff-base 1.22.4-5 pn hp2xx pn html2ps pn imagemagick-doc pn libwmf-bin pn mplayer pn povray pn radiance pn sane-utils pn texlive-base-bin pn transfig pn ufraw-batch ii xdg-utils 1.1.3-2 -- no debconf information
Bug#967049: java.lang.IllegalArgumentException: Width and height must be >= 0 since upgrade to 11.0.8+10
Package: openjdk-11-jre Version: 11.0.9+11-1~deb10u1 Followup-For: Bug #967049 Also I don't think it ever occured to me before cca begining of Oct/2020 as my first report was this: https://josm.openstreetmap.de/ticket/19900 And it looks like I've only upgraded from 11.0.8+10-1~deb10u1 to 11.0.9+11-1~deb10u1 on 30.Oct.2020., so I can confirm bug was present in 11.0.8+10-1~deb10u1 too, but probably not in any earlier versions. So it looks like possible security.debian.org regression? % ls -l /var/log/dpkg.log* -rw-r--r-- 1 root root 68779 Nov 11 17:38 /var/log/dpkg.log -rw-r--r-- 1 root root 64403 Oct 31 01:14 /var/log/dpkg.log.1 -rw-r--r-- 1 root root 6676 Oct 11 17:31 /var/log/dpkg.log.2.gz -rw-r--r-- 1 root root 794 Sep 21 21:06 /var/log/dpkg.log.3.gz -rw-r--r-- 1 root root 2702 Sep 11 01:36 /var/log/dpkg.log.4.gz % zfgrep openj /var/log/dpkg.log* /var/log/dpkg.log.1:2020-10-30 05:19:40 upgrade openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-configured openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-installed openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 upgrade openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-configured openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-installed openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status unpacked openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 configure openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status unpacked openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status half-configured openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status installed openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 configure openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status unpacked openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status half-configured openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status installed openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages openjdk-11-jre depends on: ii libc62.28-10 ii libgif7 5.1.4-3 ii libgl1 1.1.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii openjdk-11-jre-headless 11.0.9+11-1~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openjdk-11-jre recommends: ii fonts-dejavu-extra 2.37-1 pn libatk-wrapper-java-jni openjdk-11-jre suggests no packages. -- no debconf information
Bug#967049: java.lang.IllegalArgumentException: Width and height must be >= 0 since upgrade to 11.0.8+10
Package: openjdk-11-jre Version: 11.0.9+11-1~deb10u1 Followup-For: Bug #967049 Dear Maintainer, Same issue happened to me: https://josm.openstreetmap.de/ticket/20060 It happens only rarely for me so I can't reproduce at will unfortunately. I'm not using any DE, but icewm with X11 if it matters. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages openjdk-11-jre depends on: ii libc62.28-10 ii libgif7 5.1.4-3 ii libgl1 1.1.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii openjdk-11-jre-headless 11.0.9+11-1~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openjdk-11-jre recommends: ii fonts-dejavu-extra 2.37-1 pn libatk-wrapper-java-jni openjdk-11-jre suggests no packages. -- no debconf information
Bug#971924: ITP: ironseed -- science-fiction exploration/strategy adventure game in space
Package: wnpp Followup-For: Bug #971924 Owner: Matija Nalis * Package name: ironseed Version : 0.2.5 Upstream Author : Matija Nalis * URL : https://github.com/mnalis/ironseed_fpc * License : GPLv3 Programming Lang: Pascal Description : science-fiction exploration/strategy adventure game in space It was originally both developed and published by Channel 7 for DOS in 1994. Gameplay is real-time, featuring trading, diplomacy, and strategy, and somewhat resembles Star Control 2 / Ur-Quan masters. DOS sources have been changed to make it possible to compile it with the freepascal compiler under Linux and SDL, and many bugs were fixed. Wikipedia entry: https://en.wikipedia.org/wiki/Iron_Seed The DOS version of the game was originally released under GPLv3 on http://ironseed.net by original developers, ported to SDL by https://github.com/y-salnikov/ironseed_fpc and further improved by https://github.com/nukebloodaxe/ironseed_fpc and finally many bugs fixed (and currently maintained upstream) by: https://github.com/mnalis/ironseed_fpc (disclaimer: myself) I've done basic Debian packaging in github repo above (and package now cleanly builds and works in pdebuild in Buster), but after reading https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2F_directory.3F I'll be removing Debian stuff from Github upstream, and recreating it at Debian as this seems to be much prefered. If anyone wants to give it a try and provide feedback, I'd be grateful! I'll be updating this bug with progress as it happens.
Bug#971924: RFP: ironseed -- science-fiction exploration/strategy adventure game in space
Thanks to both you Sudip and Yangfl, I'm doing additional reading on Debian procedures, so I'll update this bug in few days. (I'll also investigate build bug, thanks!) -- Opinions above are GNU-copylefted.
Bug#971924: RFP: ironseed -- science-fiction exploration/strategy adventure game in space
Package: wnpp Severity: wishlist * Package name: ironseed Version : 0.2.4 Upstream Author : Matija Nalis * URL : https://github.com/mnalis/ironseed_fpc * License : GPLv3 Programming Lang: Pascal Description : science-fiction exploration/strategy adventure game in space It was originally both developed and published by Channel 7 for DOS in 1994. Gameplay is real-time, featuring trading, diplomacy, and strategy, and somewhat resembles Star Control 2 / Ur-Quan masters. DOS sources have been changed to make it possible to compile it with the freepascal compiler under Linux and SDL, and many bugs were fixed. Wikipedia entry: https://en.wikipedia.org/wiki/Iron_Seed The DOS version of the game was originally released under GPLv3 on http://ironseed.net by original developers, ported to SDL by https://github.com/y-salnikov/ironseed_fpc and further improved by https://github.com/nukebloodaxe/ironseed_fpc and finally many bugs fixed by: https://github.com/mnalis/ironseed_fpc (disclaimer: myself) It is a nice game (or I wouldn't invest time in fixing bugs in it!) I've done basic Debian packaging in github repo, and resulting Debian package builds and runs fine with me. I'm hoping to find someone willing to help me push it to Debian GNU/Linux, so more people can easily get it and have fun playing it. If more work is required on it, I'm willing to do it, if someone will point me in right direction. But I am not DD and thus cannot do it all the way through myself. If I get Debian lingo right, I'm looking for a sponsor.
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
On Sun, Oct 04, 2020 at 12:40:48PM +0300, Otto Kekäläinen wrote: > la 3. lokak. 2020 klo 18.17 Matija Nalis (mnalis-debian...@voyager.hr) > > Yes, I can write a shell test scripts which looks like > > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke > > Yes, that seems like a sensible approach. You don't need much > resources as you can use the resources of Salsa (Gitlab-CI) to run it > for you. See https://wiki.debian.org/Teams/MySQL/patches "Using > Salsa-CI". Thanks for the pointers, Otto - they look interesting! Unfortunately, I'm now failing even at this simple task of cleanly reproducing the bug manually. I've tried but I am unable to recreate the problems when I install mariadb from scratch in Stretch. (our original machines had mysql/mariadb databases upgraded from previous Debian versions, so something there might have done something to databases to trigger that behavior). As original machines which were exhibiting problem were in the meantime updated to Buster (where the problem seems to be gone now), and myself not being able to reproduce it in clean install of Scratch mariadb-10.1 (even after importing few databases on which it was failing on original machines) and myself lacking time to try some deeper forensics, I propose this bug be closed unless someone else chimes in that they can reproduce it. -- Opinions above are GNU-copylefted.
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Yes, I can write a shell test scripts which looks like https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke and verify that (when run from shell) it fails with non-zero errorlevel in Stretch mariadb, and passes with 0 on Buster mariadb. If that is enough? (I don't really have resources ATM to setup build environment and do full-build checks etc) On Tue, Sep 29, 2020 at 11:44:12PM +0300, Otto Kekäläinen wrote: > Thanks! > > Would you like to test with mariadb-10.5 in unstable as well? > > Or perhaps contribute by writing a small autopkgtest extension (the > debian/tests files in the packaging repository at > https://salsa.debian.org/mariadb-team/mariadb-10.5) that runs this > dump and thus ensure forever that this feature will not regress? -- Opinions above are GNU-copylefted.
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
I've retested now quickly on different machine, and it *seems* to be working OK in Buster. # mysqldump -uroot --max_allowed_packet=2147483648 --hex-blob --lock-all-tables --master-data --flush-privileges --databases video1 mysql > backup.sql # mysql < backup.sql # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster # dpkg -l | grep mariadb ii libmariadb3:amd641:10.3.23-0+deb10u1 amd64MariaDB database client library ii mariadb-client 1:10.3.23-0+deb10u1 all MariaDB database client (metapackage depending on the latest version) ii mariadb-client-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database client binaries ii mariadb-client-core-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database core client binaries ii mariadb-common 1:10.3.23-0+deb10u1 all MariaDB common metapackage ii mariadb-server 1:10.3.23-0+deb10u1 all MariaDB database server (metapackage depending on the latest version) ii mariadb-server-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database server binaries ii mariadb-server-core-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database core server files
Bug#516394: removal of djbdns ?
Hi, I see djbdns is removed from testing, due to unarchiving of critical bug #516394 However, as source package djbdns 1:1.05-11 builds several binary packages (axfrdns, djbdns-conf, djbdns-utils, rbldns, tinydns, walldns) and the bug is only in (if not patched) dnscache, would other packages reenter testing and later new stable Debian? I don't particularly care about dnscache, but use other parts of djbdns (tinydns, axfrdns, djbdns-utils...) often. I don't know if only some binary packages sharing same source package can be blocked from entering testing, or how this should reasonably be handled so other binary packages remain in Debian (lowering severity to important, as much of the binaries are non-affected? patching dnscache with provided patches?) I am not DD/DM, but have some experience with creating Debian packages, so am willing to help if needed. Thanks! -- Opinions above are GNU-copylefted.
Bug#901081: libayatana-appindicator related
also found reported upstream in: https://github.com/transmission/transmission/issues/403 It seems to happen only when "libayatana-appindicator for Ubuntu-like tray" is enabled. I've modified the control file to: Build-Conflicts: libayatana-appindicator3-dev instead of Build-Depends: libayatana-appindicator3-dev and rebuilt package, and now it restores behaviour "left-click tray icon to show/hide transmission main window" which was working in previous Debian releases. Right-clicking the tray icon still shows window with: "Show Transmission / Open / Open URL / Pause etc" menu, as expected. So I guess that enabling ayatana-appindicator support breaks left-click action and make it same as right-click action. -- Opinions above are GNU-copylefted.
Bug#942504: acmetool new version?
I can confirm that this is important issue. For freshly installed package it no longer works. If acmetool Debian package was installed (and account created) before Nov/2019, it still works, but will start failing beginning Jun/2020 (as described in ACMEv1 EoL plan), and if not fixed by then this bug should have its Severity upgraded to "grave" (due to package being unusable or mostly so). Upstream git master works fine for ACMEv2, but needs to be packaged for Debian. Is there specific event Debian maintainers wait for; so interested parties should go bug upstream about? Or is there anything non-maintainers can do to help resolving this soon and keeping acmetool in Debian? -- Opinions above are GNU-copylefted.
Bug#901081: transmission-gtk: I can confirm this in Debian Buster
Package: transmission-gtk Version: 2.94-2 Followup-For: Bug #901081 Dear Maintainer, I can confirm this bug in Debian Buster. Prior to upgrading (eg. in Debian Stretch) it worked normally (left click on the icon in tray would hide or show transmission-gtk main window). Now it does the same as right click (shows a submenu in tray). I'm using icewm. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages transmission-gtk depends on: ii libayatana-appindicator3-1 0.5.3-4 ii libc6 2.28-10 ii libcurl47.64.0-4 ii libevent-2.1-6 2.1.8-stable-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u1 ii libgtk-3-0 3.24.5-1 ii libminiupnpc17 2.1-1+b1 ii libnatpmp1 20150609-7 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libssl1.1 1.1.1d-0+deb10u1 ii transmission-common 2.94-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages transmission-gtk recommends: ii xdg-utils 1.1.3-1 transmission-gtk suggests no packages. -- no debconf information
Bug#941622: man-db: man(1) manpage does not mention MAN_DISABLE_SECCOMP=1 environment variable
Package: man-db Version: 2.8.5-2 Severity: normal Dear Maintainer, man1/man.1.gz manpage should document all enviroment variables it uses. It includes: - MAN_DISABLE_SECCOMP=1 - PIPELINE_DEBUG=1 Those are usually only used for debugging, but so is MAN_KEEP_STDERR, which is correctly documented in man(1) manpage. Having them undocumented/unmentioned makes a life much more complicated for casual bug reporter, and sysadmins trying to troubleshoot apparmor/seccomp related bugs. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii groff-base 1.22.4-3 ii libc6 2.28-10 ii libgdbm6 1.18.1-4 ii libpipeline1 1.5.1-2 ii libseccomp22.4.1-2~bpo10+1 ii zlib1g 1:1.2.11.dfsg-1 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor 2.13.2-10 ii chromium [www-browser] 76.0.3809.100-1~deb10u1 ii elinks [www-browser] 0.13~20190125-3 ii firefox-esr [www-browser] 60.9.0esr-1~deb10u1 ii groff 1.22.4-3 ii less 487-0.1+b1 ii lynx [www-browser] 2.8.9rel.1-3 ii surf [www-browser] 2.0+git20181009-4 ii w3m [www-browser] 0.5.3-37 -- Configuration Files: /etc/apparmor.d/usr.bin.man changed [not included] /etc/manpath.config changed [not included] -- debconf information excluded
Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Package: mariadb-client-10.1 Version: 10.1.38-0+deb9u1 Severity: normal Dear Maintainer, Doing "mysqldump --all-databases" on one mariadb 10.1 instance, and trying to import it on another mariadb 10.1 instance fails with: I would expect it to suceed without errors (like it did all the time in mysql in Jessie) I traced it down and it happens if dump contains one db with tables with indexes, and mysql db. machine1# mysqldump -uroot --max_allowed_packet=2147483648 --hex-blob --lock-all-tables --master-data --flush-privileges --databases video1 mysql > backup.sql machine2# mysql < backup.sql ERROR 1062 (23000) at line 796: Duplicate entry 'video1-test2-PRIMARY-n_diff_pfx01' for key 'PRIMARY' Digging deeper it seems that bug happens when mysql tryies to restore mysql.innodb_index_stats table I've found two workarounds: 1) modify order of databases, so mysql table is backed up (and restored) first, and all other later; eg "mysqldump ... --databases mysql video1" 2) before starting mysql for import, do "SET global innodb_stats_persistent=0" (and restore it afterwards) Perhaps one of those (or some other) workaround should be implemented automatically (at least when using "mysqldump --flush-privileges" and/or "--all-databases" which implies backup/import of mysql DB)? I would assume backup up and restoring whole mariadb server is one of relatively common operations which should not involve such debugging. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mariadb-client-10.1 depends on: ii debianutils 4.8.1.1 ii libaio1 0.3.110-3 ii libc6 2.24-11+deb9u4 ii libconfig-inifiles-perl 2.94-1 ii libjemalloc1 3.6.0-9.1 ii libstdc++66.3.0-18+deb9u1 ii libsystemd0 232-25+deb9u11 ii mariadb-client-core-10.1 10.1.38-0+deb9u1 ii perl 5.24.1-3+deb9u5 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-client-10.1 recommends: ii libdbd-mysql-perl 4.041-2 ii libdbi-perl 1.636-1+b1 ii libterm-readkey-perl 2.37-1 mariadb-client-10.1 suggests no packages. -- no debconf information
Bug#682369: confirmed
Control: found -1 60.6.1esr-1~deb9u1 Just to clarify, this bug happens even on normal browser close, when session restore is *NOT USED* - that is, even when web pages are fully closed before quitting the browser. And it happens even with setting "When Firefox starts" to "Show a blank page" (which should disable session restore functionality completely). So the option "Keep (cookies) until: I close Firefox" *never* does anything. It is quite deceptive :( As workarounds, only options not to retain cookies when closing firefox-esr browser I've found are: - installing add-on like "Cookie Autodelete" to remove cookies automatically on *tab* close - enabling "Always use private browsing mode" in "Preferences" / "Privacy & Security" (which also disabled sometimes useful session restore) - manually deleting cookies before closing browser. -- Opinions above are GNU-copylefted.
Bug#754809: bugs.debian.org still broken regarding DKIM
Has this issue ever has been dealt with for bugs.debian.org (as it seems to have been solved for lists.debian.org in forked #752084) ? Because I still have breakage when I submit mail to bugs.debian.org and I get failure notices from other hosts as noted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830865#45 (note: my DKIM validates elsewhere, and I do not have any other issues with it except on bugs.debian.org mails). Forensic headers (requested in DMARC with fo=1) seems to indicate DKIM breaks along the way near bendel.debian.org, for example: Authentication-Results: mail.susi-moog.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=voyager.hr header.i=@voyager.hr header.b="EVrAhWxo"; dkim-atps=neutral Authentication-Results: mail.susi-moog.de; spf=none (mailfrom) smtp.mailfrom=lists.debian.org (client-ip=82.195.75.100; helo=bendel.debian.org; envelope-from=bounce-debian-bugs-rc=andreas.moog=warperbbs...@lists.debian.org; receiver=) Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with QMQP id ABCCC20BAE; Wed, 6 Mar 2019 03:15:08 + (UTC) X-Mailbox-Line: From debian-bugs-rc-requ...@lists.debian.org Wed Mar 6 03:15:08 2019 Old-Return-Path: X-Original-To: lists-debian-bugs...@bendel.debian.org Delivered-To: lists-debian-bugs...@bendel.debian.org Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with ESMTP id 9CF7820BA9 for ; Wed, 6 Mar 2019 03:15:08 + (UTC) X-Virus-Scanned: at lists.debian.org with policy bank bug X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-1 required=5.3 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from bendel.debian.org ([127.0.0.1]) by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525) with ESMTP id r-35XNxN_7Md for ; Wed, 6 Mar 2019 03:15:06 + (UTC) Received: from buxtehude.debian.org (buxtehude.debian.org [IPv6:2607:f8f0:614:1::1274:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "buxtehude.debian.org", Issuer "Debian SMTP CA" (not verified)) by bendel.debian.org (Postfix) with ESMTPS id 78D1B20BA4; Wed, 6 Mar 2019 03:15:06 + (UTC) Received: from debbugs by buxtehude.debian.org with local (Exim 4.89) (envelope-from ) id 1h1N1L-0008UD-2y; Wed, 06 Mar 2019 03:15:03 + X-Loop: ow...@bugs.debian.org I can provide whole forensic report if required, or do tests. -- Opinions above are GNU-copylefted.
Bug#662960: ssmtp doesn't validate server TLS certificates
severity 662960 wishlist thanks The bug have been added tag "security", which is in sync with its TLS deficiencies. However (as you noticed) "Severity" values (while they might look innocently like plain English) have quite specific meanings in BTS, which sometimes might be at odds with their common language usages. Because of that "Severity" is not just a number from 0-5 indicating how much one would like for bug to be fixed, but something else. "Severity: important" would indicate that package is just one small step away from "rendering it completely unusable to everyone", which looks too harsh to me in this case (as in many cases ssmtp is used only for non-TLS plaintext SMTP delivery on LAN from satellite machines to main MTA, which would then speak TLS to outside world etc.) "Severity: wishlist" however (as opposed to "normal") subtly indicates that there is some functionality that is *missing*, and that someone needs to think it over and write it, and that it might be a more complicated task and probably not an one-line-fix (and thus it would probably left to upstream to fix it, as Debian maintainer in most cases won't be fixing it h[im/er]self unless upstream is dead and someone else provides a verified good patch). It also indicates it might be due to design decisions, like here. I do agree completely with you that package should strongly indicate in its docs and description about it's TLS deficiencies. If someone would write such a documentation patch, perhaps it might have a chance to be included. [ As a side note, even with certificate checking in place there are a lot of problems in todays "zillion untrusted CAs which we trust anyway" security model, and even more so if you move from web world (where clients try to be secure, and even people might sometimes check basic credentials) to unattended MTA world where almost nobody does, and vast majority of MTAs will simply by default silently downgrade to plaintext if they think anything might be problematic with TLS support etc. ] -- Opinions above are GNU-copylefted.
Bug#662960: ssmtp doesn't validate server TLS certificates
Hi Celejar, you have raised severity to "serious" on ssmtp Debian package in bug #662960, which is reserved for "Serious policy violations" as described at https://www.debian.org/Bugs/Developer#severities It is customary to indicate exactly which section of Debian policy Manual (at https://www.debian.org/doc/debian-policy/) the bug breaks when setting "serious" severity. While I do agree that limitations of TLS implementation should be prominently noted in package documentation and even description, I do not think that even completely non-existent TLS support qualifies for more than "important" severity (and more likely "normal" or "wishlist"). Unless someone objects with specific Debian policy section that this package runs afoul, I'm going to revert its severity back to wishlist. -- Opinions above are GNU-copylefted.
Bug#919795: thunderbird: cannot save changes to addressbook
Few more data points (3rd being most important):
1) while I can't edit or create new contacts under "Personal Address Book", I:
- can create new list - via "New List" button
- can add/remove members on existing list by right clicking on the list,
selecting "Edit List"
- but can't add member on existing list by right clicking on the list, and
selecting "New contact"
(as that bring the same form as original "New Contact" button)
2) I've managed to find somewhat similar simptoms ("OK" buttons does
not do anything, contact screen does not go away, and contact does not get
added). But it's ten years old, on Windows XP, and shows additional error
messages so does not look too related unfortunately. Still, here it is:
https://bugzilla.mozilla.org/show_bug.cgi?id=473966
3) Driven by desparation, I've used debootstrap to create chrooted
minbase Stretch chroot, installed thunderbird inside it (via
"chroot stretch_root apt-get install --no-install-recommends thunderbird")
copied /etc/hosts, /etc/machine-id to it, done "adduser mnalis"
and used "mount --bind" to include directories
/home/mnalis /tmp /proc /dev /dev/pts /sys /run/shm inside chroot.
Then I've run thunderbird in chrooted Stretch, and it worked
without problem (using same /home/mnalis/.thunderbird that
original onn-chrooted Stretch system has problems with).
But debootstrap installed thunderbird 1:60.2.1-2~deb9u1.
After exiting chroot and starting regular thunderbird (with same
profile in homedir), it again doesn't work.
Then in chroot I upgraded just thunderbird from Default Stretch
main repo 1:60.2.1-2~deb9u1 to Security version 1:60.4.0-1~deb9u1
and it stopped working in chroot too.
Downgrading to 1:60.2.1-2~deb9u1 fixes addressbook again.
So it seems that it is regression in the Stretch security upgrade
from 1:60.2.1-2~deb9u1 to 1:60.4.0-1~deb9u1 that breaks
addressbook functionality.
--
Opinions above are GNU-copylefted.
Bug#919795: thunderbird: cannot save changes to addressbook
On Sat, Jan 19, 2019 at 06:48:46PM +0100, Carsten Schoenert wrote: > > -- Configuration Files: > > /etc/apparmor.d/usr.bin.thunderbird [Errno 2] No such file or directory: > > '/etc/apparmor.d/usr.bin.thunderbird' > > you have AppAprmor installed and there is some problem with the AA > profile for TB which can't be found. I do have apparmor installed, but it is not enabled. % sudo aa-status apparmor module is loaded. apparmor filesystem is not mounted. > I expect you will see some 'ACCESS denied' messages in the output of the > dmesg command so Thunderbird can't write the information to the > harddisk. Please check for such messages. I've cleared message buffer with "dmesg -c", run thunderbird and experienced problem, and then run "dmesg" again, which produced no output. So I would guess apparmor has not blocked anything. (on other machine where I do have it enabled, it always log to dmesg any access denied messages) Also, I do not think it is probable that it is permission problem with write access to "abook.mab" - if it were, I probably also couldn't delete entries from addressbook, which I CAN do. I just can't add new contact or modify existing ones. It feels like the OK button in GUI is not linked to doing anything. Could that perhaps be the case (linked to that "Gtk-WARNING **: Theme parsing error" messages when starting up Thunderbird)? > $ sudo apt install --reinstall thunderbird Interestingly enough, this did not reinstall /etc/apparmor.d/usr.bin.thunderbird file. I did "dpkg --purge thunderbird; apt-get install thunderbird" which did reinstall it. But since apparmor isn't enabled, it didn't help. > If you don't want to use the ApprArmor functionality you can disable the > profile for TB. But we prefer to fix such issues. Yeah, I would prefer that too, but too many things break on this system with apparmor, so I disabled it after some period of testing. Just to make sure, I have now completely removed apparmor, apparmor-utils, apparmor-profiles, and apparmor-profiles-extra packages from the system and rebooted. The same bug in thunderburd is still there. Any other ideas? Or can you reproduce the bug? -- Opinions above are GNU-copylefted.
Bug#919795: thunderbird: cannot save changes to addressbook
Package: thunderbird Version: 1:60.4.0-1~deb9u1 Severity: important When I try to make a change to address book contact (either "Personal Address Book" or "Collected Addresses") I am unable to do so. For example, I doubleclick the contact to open it, then change e-mail address field. But when I press "OK" the dialog does not go away as it should. It just stays there open (see attached picture) no matter how many times I click "OK". (I expected the screen to close and contact information be updated) When I finally give up and press "Cancel", the dialog goes away, and the addressbook *looks* like it was updated afterall, but as soon as addressbook is closed and reopened again I can see that no changes have taken place. Same problem arises when I try to add new contact. Only write operation on addressbook that DOES work is "Delete" - i can right click on contact and select Delete and it is really gone forever. Running "thunderbird --verbose" shows: INFO -> [[ ... using verbose mode ... ]] DEBUG -> Found folder /home/mnalis/.icedove, found a symlink /home/mnalis/.thunderbird pointing to /home/mnalis/.icedove DEBUG -> call '/usr/lib/thunderbird/thunderbird ' (thunderbird:2851): Gtk-WARNING **: Theme parsing error: :1:34: Expected ')' in color definition (thunderbird:2851): Gtk-WARNING **: Theme parsing error: :1:77: Expected ')' in color definition I'm running thunderbird 1:60.4.0-1~deb9u1 on XFCE on Debian 9.6 (Stretch) with no active apparmor (apparmor filesystem is not mounted). No messages in dmesg are visible. It was upgraded regularily from old debian versions on each cycle (including thunderbird -> icedove -> thunderbird migration). Addressbook worked normally in the past, but I cannot pinpoint when it stopped working. I've tried (with no success): - starting as icedove wrapper (same issue) - removing icedove package (same issue) - starting thunderbird --safe-mode (same issue) - removing abook.mab file (the thunderbird starts with empty personal address book, but I'm still unable to add new entries to it) - creating new profile (address book is empty, but I can't add anything to it) - doing rm -rf ~/.icedove ~/.thunderbird (get new wizard etc, but still can't add to address book) - trying with another user on the same machine (same issue) -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages thunderbird depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libgtk2.0-0 2.24.31-2 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3+deb9u1 ii libx11-xcb1 2:1.6.4-3+deb9u1 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b2 ii x11-utils 7.7+3+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-en-gb [hunspell-dictionary] 1:5.2.5-1 ii hunspell-hr [hunspell-dictionary] 1:5.2.5-1 pn lightning Versions of packages thunderbird suggests: ii apparmor 2.11.0-3+deb9u2 ii fonts-lyx 2.2.2-1 ii libgssapi-krb5-2 1.15-1+deb9u1 -- Configuration Files: /etc/apparmor.d/usr.bin.thunderbird [Errno 2] No such file or directory: '/etc/apparmor.d/usr.bin.thunderbird' -- no debconf information
Bug#830865: any progress?
This still seems to happen on bugs.debian.org mails, for example I got RUF reports like: Authentication-Results: mail.susi-moog.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=voyager.hr header.i=@voyager.hr header.b=jhX0w52b; dkim-atps=neutral It is really problematic, because if person reporting bug uses DKIM, and MTA of package maintainer (or other subscribed persons) verifies it, then the bug report might never reach the maintainer / interested subscribers. This is especially likely to happen if DMARC is also used with policy different than "none". Could some solution/workaround (like #500965 for similar problems in lists.debian.org) be adopted? -- Opinions above are GNU-copylefted.
Bug#906847: workaround?
is workaround possible? (eg. having the Adblock plus be available for all users on system) I see in #906837 that for (similar) xul-ext-ublock-origin that the issue was fixed in unstable; could it also be fixed for xul-ext-adblock-plus? -- Opinions above are GNU-copylefted.
Bug#864987: newer FF
for newer firefox 60.2.0esr see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908349 for possible workarounds (like apulse wrapper for using ALSA instead of pulseaudio) On Wed, Sep 12, 2018 at 04:51:10AM +, 908349-subh...@bugs.debian.org wrote: > You have been successfully subscribed to 908...@bugs.debian.org. > > If you wish to unsubscribe, send mail to > 908349-unsubscr...@bugs.debian.org . > > For instructions on using the bug subscription software, send > mail to 908349-h...@bugs.debian.org . > > If you have problems with this subscription, please contact the Debian > Listmaster Team at listmas...@lists.debian.org. > > Thank you. -- Opinions above are GNU-copylefted.
Bug#827059: newer firefoxes
for newer firefox 60.2.0esr see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908349 for possible workarounds
Bug#902899: me too
On Tue, Jul 10, 2018 at 08:01:56AM +0200, Sebastian Andrzej Siewior wrote: > On 2018-07-09 22:45:15 [+0200], Matija Nalis wrote: > > I got bitten by this too in jessie-updates (after wasting some time > > being *sure* local signature I was just creating at the time made > > clamd crash silently)... > > wasn't there an assert which made clamd exit? no, /var/log/clamav* does not contain any info about clamd crash (which made it hard to debug), and that system does not use systemd (so no information from systemd journal like the OP). Only when one runs "clamscan" manually (or debugs clamd+clamdscan manually outside the Debian startup scripts) did I see: "clamscan: yara_exec.c:177: yr_execute_code: Assertion `sp == 0' failed." -- Opinions above are GNU-copylefted.
Bug#767329: rdesktop: also happens here
Package: rdesktop
Version: 1.8.2-3+deb8u1
Followup-For: Bug #767329
Dear Maintainer,
* What led up to the situation?
pasting to windows app via ctrl-v. Source was raw email piped to "xsel
-bpi" in mutt.
rdesktop was started on remote host via ssh. 95% of the time
everything works just fine, but now and then (on larger pieces of
text - this one was 38KB) it crashes with:
% rdesktop -u user.name -d DOMENA -r clipboard:PRIMARYCLIPBOARD -K -z -P -x m
-g 98% hostname
Autoselected keyboard map en-us
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized
?
Connection established using SSL.
WARNING: Remote desktop does not support colour depth 24; falling back to 16
ERROR: SSL_read: 5 (Connection reset by peer)
Disconnected due to network error, retrying to reconnect for 70 minutes.
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized
?
Connection established using SSL.
up to here it does not seems those error are important and rdesktop is
connected to remote host and works normally
until large piece of text is pasted, then it crashes:
*** Error in `rdesktop': double free or corruption (fasttop):
0x01a02f90 ***
./hosting: line 16: 11666 Aborted rdesktop -u user.name -d
DOMENA -r clipboard:PRIMARYCLIPBOARD -K -z -P -x m -g ${SIZE}% hostname
(the address changes, for example it was also 0x02685cb0)
(The remote is Microsoft windows server 2008 R2 in this case)
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
One the rdesktop crashes, upon further rdesktop connections, it is
not possible to paste anything (even simple words) on windows host
until "log off" on windows side is performed. After that, if same
big paste buffer is tried again, crash is reproducible.
If I logoff on winows, and clear paste buffers on localhost with
"xsel -bpsc", then fill them with something simple like "echo hello
| xsel -bpi" the pasting works again.
* What outcome did you expect instead?
I expected the text to be pasted to windows app, instead of rdesktop
crash
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.11
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages rdesktop depends on:
ii libasound21.0.28-1
ii libc6 2.19-18+deb8u10
ii libgssglue1 0.4-2
ii libpcsclite1 1.8.13-1+deb8u1
ii libssl1.0.0 1.0.1t-1+deb8u9
ii libx11-6 2:1.6.2-3+deb8u1
ii libxrandr22:1.4.2-1+deb8u1
rdesktop recommends no packages.
Versions of packages rdesktop suggests:
ii pcscd 1.8.13-1+deb8u1
-- no debconf information
Bug#902899: me too
I got bitten by this too in jessie-updates (after wasting some time being *sure* local signature I was just creating at the time made clamd crash silently)... I did: rm -f /var/lib/clamav/*.yar (just removing "antidebug_antivm.yar was not enough) and put: enable_yararules="" in /etc/clamav-unofficial-sigs/user.conf and after restarting clamd, it seems to work fine... Hopefully it won't download them again. Still wondering how much of protection is lost without YARA rules?
Bug#888484: Updates for stretch/jessie not in security repo
nor does debian security tracker list the updates as available for jessie/stretch: https://security-tracker.debian.org/tracker/source-package/clamav (security-tracked does say in hover text that jessie "gets updated via -updates", so it should pick that up) it correctly reports wheezy, buster and sid as fixed. for example, see also https://security-tracker.debian.org/tracker/CVE-2017-12376 this looks to me also like something that should be fixed (somewhere)?
Bug#877737: screen corrupts display when switching back to mutt using UTF-8 chars
Thanks, that bug certainly sounds like mine... Updated manually to screen 4.6.1-1 from Debian Buster (luckily no dependencies issues) and the problem is gone! -- Opinions above are GNU-copylefted.
Bug#877737: screen corrupts display when switching back to mutt using UTF-8 chars
Package: screen Version: 4.5.0-6 Severity: normal Dear Maintainer, When I open mutt (with some UTF-8 emails) in one window, it displays ok. Now I create new terminal with ctrl-a, c it is still ok. However when I switch back to mutt window with ctrl-a a, it is corrupted. (see attached pics - before and after ctrl-a a) So far I've only seen this bug with screen + mutt. - this problem was seen in Stretch, and did not seem to appear in Jessie - my LANG=hr_HR.UTF-8 both before and after starting screen - forcing screen -U does not fix the problem - if emails in mutt do not contain UTF-8 chars, there is no bug. There also seems to be no bug if there are SOME UTF-8 letters (like etc) but fails with other UTF-8 chars. - ~/.muttrc is either empty or with 'set charset="utf-8"' - same problem if I set it to ASCII then there is no UTF-8 chars shown and no bug of course. - It happens independent of xterm used (xterm, uxterm, lxterminal, stterm) - my TERM=xterm before starting screen, and TERM=screen after starting it. If I start mutt with "TERM=screen.linux mutt" screen is still buggy. But if I start mutt with "TERM=xterm mutt" it works aroung the bug (but display is not as nice, as selector line is not whole line length but just length of text) - out of X11 in Linux text console, TERM=linux before starting screen and TERM=screen.linux after starting it. mutt also works fine in Linux text console. - if I run mutt in tmux instead of screen (which also seems to use TERM=screen), switching works normally without corruption. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages screen depends on: ii libc6 2.24-11+deb9u1 ii libpam0g 1.1.8-3.6 ii libtinfo5 6.0+20161126-1 screen recommends no packages. Versions of packages screen suggests: pn byobu | screenie | iselect ii ncurses-term6.0+20161126-1 -- no debconf information
Bug#877734: joe: ctrl-k / piping breaks when command contains // character sequence
Package: joe Version: 4.4-1 Severity: normal Dear Maintainer, When piping text block through external command (via ctrl-k /), joe breaks if external command parameters contains two consecutive slashes. For example, piping (ctrl-k /) block through: sed -e 's/foo/bar/' work normally, as does replacing by space: sed -e 's/foo/ /' but piping it through: sed -e 's/foo//' (to delete string 'foo') fails with "/bin/sh: 1: Syntax error: Unterminated quoted string" It also does weird syntax-coloring in "Command to filter file through" prompt, showing all of command but last slash and apostrophe in green. Also when recalling command next time with up-arrow, it shows only slash and apostrophe instead of whole command! The problem arises after upgrading from jessie to stretch - the joe in jessie and before was working normally. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages joe depends on: ii libc62.24-11+deb9u1 ii libncurses5 6.0+20161126-1 ii libtinfo56.0+20161126-1 joe recommends no packages. joe suggests no packages. -- no debconf information
Bug#777095: localepurge: also remove /usr/share/help (patch)
Package: localepurge
Version: 0.7.3.4
Followup-For: Bug #777095
Dear Maintainer,
the attached patch adds support for cleaning /usr/share/help localized help
pages too
-- System Information:
Debian Release: 8.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages localepurge depends on:
ii debconf [debconf-2.0] 1.5.56+deb8u1
ii locales2.19-18+deb8u10
ii procps 2:3.3.9-9
ii ucf3.0030
localepurge recommends no packages.
Versions of packages localepurge suggests:
pn bleachbit
pn debfoster
ii deborphan 1.7.28.8-0.1
-- debconf information:
localepurge/quickndirtycalc: true
localepurge/remove_no:
* localepurge/use-dpkg-feature: false
* localepurge/nopurge: en, en_US, en_US.ISO-8859-15, en_US.UTF-8, hr, hr_HR,
hr_HR.UTF-8
localepurge/none_selected: false
localepurge/verbose: false
localepurge/dontbothernew: false
* localepurge/mandelete: true
localepurge/showfreedspace: true
-- debsums errors found:
debsums: changed file /usr/sbin/localepurge (from localepurge package)
--- /usr/sbin/localepurge.org 2014-11-30 20:47:51.0 +0100
+++ /usr/sbin/localepurge 2017-08-06 21:42:07.327725428 +0200
@@ -245,7 +245,7 @@
## Now, get the job done
-for LDIR in /usr/share/{locale,man,gnome/help,omf,doc/kde/HTML}; do
+for LDIR in /usr/share/{locale,man,help,gnome/help,omf,doc/kde/HTML}; do
if [ ! -d "$LDIR" ]; then continue; fi
spacebefore "$LDIR"
case "$LDIR" in
@@ -272,6 +272,12 @@
fi
done ;;
+ /usr/share/help)
+ ((VERBOSE)) && echo "localepurge: processing help files ..."
+ for locale in $(cd "$LDIR"; echo *); do
+ remove_superfluous_files_under "$locale" "$LDIR/$locale"
+ done ;;
+
/usr/share/omf)
((VERBOSE)) && echo "localepurge: processing Omf files ..."
for file in "$LDIR"/*/*; do
Bug#803941: samba: cp and cat return an endless stream of 0s when reading a file on a samba share
Package: samba Version: 2:4.2.10+dfsg-0+deb8u2 Followup-For: Bug #803941 It seems that the bug happens when using too big read buffer. I can work around it on client side by either: 1) mounting with "-o rsize=16384" (or actually any number lower than 131071, which is 2^17-1; just playing it safe here) by default mount.cifs from Debian Jessie with kernel linux-image-3.16.0-4-amd64 3.16.7-ckt25-2 will do mount with CIFS 1.0 and too big rsize: //merlin.tomsoft.lan/ganeti2-blade /var/lib/ganeti/export cifs rw,relatime,vers=1.0,cache=strict,domain=MERLIN,uid=0,noforceuid,gid=0,noforcegid,addr=10.66.2.10,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1 0 0 2) mounting with (at least) "-o vers=3.0" (or anything at or above 2.0; which seems to force rsize=65536) (Unfortunately, trying to force it on the server side with "client min protocol = SMB2" does not seem to work maybe some of the cache/aio options would, but it is production samba server here which I can't disturb too much...) -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.26 ii libbsd0 0.7.0-2 ii libc62.19-18+deb8u4 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-9 ii libldb1 2:1.1.20-0+deb8u1 ii libpam-modules 1.1.8-3.1+deb8u1+b1 ii libpam-runtime 1.1.8-3.1+deb8u1 ii libpopt0 1.16-10 ii libpython2.7 2.7.9-2 ii libtalloc2 2.1.2-0+deb8u1 ii libtdb1 1.3.6-0+deb8u1 ii libtevent0 0.9.25-0+deb8u1 ii lsb-base 4.1+Debian13+nmu1 ii multiarch-support2.19-18+deb8u4 ii procps 2:3.3.9-9 ii python 2.7.9-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.2.10+dfsg-0+deb8u2 pn python2.7:any ii samba-common 2:4.2.10+dfsg-0+deb8u2 ii samba-common-bin 2:4.2.10+dfsg-0+deb8u2 ii samba-dsdb-modules 2:4.2.10+dfsg-0+deb8u2 ii samba-libs 2:4.2.10+dfsg-0+deb8u2 ii tdb-tools1.3.6-0+deb8u1 ii update-inetd 4.43 Versions of packages samba recommends: pn attr ii logrotate 3.8.7-1+b1 pn samba-vfs-modules Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools ii ntp1:4.2.6.p5+dfsg-7+deb8u1 pn smbldap-tools pn winbind -- debconf information: samba-common/title: samba/run_mode: daemons
Bug#796118: Re: Should djbdns be removed?
On Tue, Feb 09, 2016 at 06:00:40PM -0500, Robert Edmonds wrote: > Matija Nalis wrote: > > dnscache component only is RC-buggy. The solution has been proposed > > by Robert Edmonds (remove only buggy component /usr/bin/dnscache). > > > > It is not upstream orphaned. > > As far as I can tell, the only maintenance activity that djbdns has > received from its upstream developer has been the release of a two-line > patch, about 7 years ago: > > http://marc.info/?l=djbdns=123613000920446=2 I would consider a fact that software did not have serious security bug nor other compelling need to change for 7 years a big *plus* for using it, not as a problem. (But then again, I'm one of those guys running stuff on Debian Stable or even oldstable LTS) > The only upstream maintenance attention djbdns has received in the past > 15 years has been related to the security guarantee, and that security > guarantee is very narrowly tailored to problems that DJB finds > worthwhile; attacks enabled by the ease of forging UDP packets on the > Internet, or denial-of-service attacks are both specifically excluded > classes of problems. While I'd love to engage to in comparative analyses of various DNS software, or discuss how for example any DNS software supporting DNSSEC is by far a biggest denial-of-service amplifier attack, how BIND and other DNS tools were not even considered for removal even after having way bigger problems with forged UDP packets (for example, see https://cr.yp.to/talks/2012.03.08-1/slides.pdf) or note that other DNS software does not offer *any* gurantees at all, I do not feel that this bug report is a right place for it. > Other routine maintenance such as updating the list of root nameserver > address hints has simply been neglected. E.g., the dnsroots.global file One might say that editing a default list of servers is in domain of responsibility of sysadmin, not programmer (hey, I still remember days of AlterNIC and not using default InterNIC root server list). Still, I did offer to fix that trivial bug. > > It is just stable piece of software which does not change often, as it > > was engineered on KISS principle, so it does not *need* to be changed. > > That is great engineering feat, and I'd love if way more software > > would be like that instead of having everincreasing featurecreep. > > Many djbdns users speak about how well engineered or elegant the servers > are, but I suspect this comes from the experience of configuring the > daemons (which have very few configuration knobs compared to other DNS > implementations), rather than reading the code. Here are comments from > a security researcher with extensive experience analyzing source code: What does anecdotal rants with beauty of the code have to do with this bug? While I have not editied djbdns source (didn't have the need!) I did modify DJB's qmail and ucspi-tcp code written in similar style at times past, and had much less difficulty than average (see http://linux.voyager.hr/ for patches). But yes, the admin part is where tinydns and friends just shines. Does the job fast, efficient, with minimum administrative overhead, not getting in the way, providing the extremly easy way to integrate into it's surroundings. And no uneeded updates breaking stuff. Excellent security record for all tools but dnscache (and even there, it was first with improved protections > > I do not know why you think it *has* to be heavily patched. > > It works for me without patching just fine, for example. > > Many users have requirements that are not satisfied by the original > djbdns-1.05 source release. For example, the following post from a > Facebook developer mentions that tinydns is used at Facebook, with > multiple patches, including an in-house IPv6 support patch: > > > https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014250.html well, yes, adding support for whole new core layer3 technology does usually require some work. Upstream didn't do it as he doesn't belive it was the right way to do thinks (http://cr.yp.to/djbdns/ipv6mess.html). Some might agree that it could've been done way better. Too late for that now, IPv6 is here to stay. > > The recent DNS standards (DNSSEC, I assume) it doesn't support is by > > design, as it is deemed broken by upstream author (see > > http://dnscurve.org/ for more details, for example) and the whole > > point of KISS principle is to keep it simple and use modular design > > for extra bloat if wanted (for example, even DJB's dnscurve is to be > > implemented as separate independent software part, and not patching > > tinydns with its functionality) > > Can you cite any evidence that djbdns has a modular design, or that > enhancements can be implemented modularly, wi
Bug#657405: status?
On Mon, Nov 09, 2015 at 07:26:37PM -0500, Simon Fondrie-Teitler wrote: > Matija Nalis <mnalis-debian...@voyager.hr> writes: > > So, what is the status with mediagoblin in Debian? > > > > I've seen it go to NEW queue (and disappear from debian-mentors), but > > never found any trace of it in unstable or elsewhere? > > Sorry, I haven't found the time to work on this a while. The package is > now a version behind upstream, and there's a bunch of javascript stuff > that will need to be dealt with for new new upstream version to be > packaged. I'm going to remove myself as the owner of this bug, since I > don't want to stop others from working on it. Thanks for all the help, Simon. Hopefully someone will pick it up. > > seems to build installable package ok in ../build-area > > What remains to be done so it can be included in Debian unstable? > > Depends if you want 0.7.1 or 0.8. 0.7.1 should only need a little more > works. There's a thread about what needs to be done for it to be let > through NEW, but I'm not quite sure how to link to it (is > ftpmas...@ftp-master.debian.org archived somewhere?). 0.8 would need a > fair amount, though I don't know exactly how much. I'd like to work on 0.7.1, as that is what I'm currently using and would like that to get to Debian unstable (when that is accomplished I could take a look at 0.8 or newer). I have basic Debian packaging skills and can probably fix some of the problems, but I'm not DD/DM so I would need some help there I guess. I would need to know what are showstoppers for inclusion of mediagoblin 0.7.1 to Debian unstable, so if someone can get that info here, I would try to fix as much as I can. -- Opinions above are GNU-copylefted.
Bug#796118: Re: Should djbdns be removed?
On Tue, Oct 06, 2015 at 04:26:49PM +0200, Ondřej Surý wrote: > > On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote: > > > On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote: > > > > djbdns is RC-buggy for many years now and was out of testing since 2009. > > > > Should we remove it from unstable? > > > > No, I don't think so. > > Any solid arguments supporting your opinion? > > djbdns is RC buggy, upstream orphaned, outdated, has to be heavily > patched, doesn't support recent DNS standards and it still even carries > old J-ROOT IP address that was decommissioned a ***13*** years ago. dnscache component only is RC-buggy. The solution has been proposed by Robert Edmonds (remove only buggy component /usr/bin/dnscache). It is not upstream orphaned. It is just stable piece of software which does not change often, as it was engineered on KISS principle, so it does not *need* to be changed. That is great engineering feat, and I'd love if way more software would be like that instead of having everincreasing featurecreep. I do not know why you think it *has* to be heavily patched. It works for me without patching just fine, for example. The recent DNS standards (DNSSEC, I assume) it doesn't support is by design, as it is deemed broken by upstream author (see http://dnscurve.org/ for more details, for example) and the whole point of KISS principle is to keep it simple and use modular design for extra bloat if wanted (for example, even DJB's dnscurve is to be implemented as separate independent software part, and not patching tinydns with its functionality) J-ROOT should be trivial to patch, care to file a bug for that? > I myself started my DNS journey with djbdns years ago, and I always > loved the code-style. It's very well written, but the world has moved > on, and it's time to *let it go*. Just let it go and let it rest in > peace, Gerrit. Ondřej, I see that you advertise competing DNS product; but really, there are some people more happy with tinydns than with any other peace of DNS software out there. I'm not a DD, but I am willing to do the work if it will be accepted. For that, I propose to do the following: - fix J-ROOT - split djbdns source package into: - djbdns-dnscache (dnscache only), - djbdns-auth (authorative DNS servers, like tinydns, axfrdns, walldns), - djbdns-tools (all the command line tools) Are there other issues that need fixing in order for most of djbdns package (everything except dnscache) friends not be RC-buggy? only djbdns-dnscache can remain RC-buggy then (until patched by someone). Would that work for everyone? -- Opinions above are GNU-copylefted.
Bug#657405: status?
So, what is the status with mediagoblin in Debian? I've seen it go to NEW queue (and disappear from debian-mentors), but never found any trace of it in unstable or elsewhere? Also, in Debian Jessie with python2.7 I don't see Christopher Baines problem with jquery-1.11.1.js: git clone https://anonscm.debian.org/git/collab-maint/mediagoblin.git cd mediagoblin git fetch --all git checkout debian/unstable git-buildpackage -us -uc seems to build installable package ok in ../build-area What remains to be done so it can be included in Debian unstable? I can only see few warnings thrown by "lintian mediagoblin*.deb": W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/media_types/video/devices/web-flv.png W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/tests/test_submission/big.png W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/tests/test_submission/bigblue.png W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/tests/test_submission/evil.png W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/tests/test_submission/good.png W: mediagoblin: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mediagoblin/tests/test_submission/medium.png -- Opinions above are GNU-copylefted.
Bug#774735: offlineimap: sometimes dies randomly at startup when ui = Blinkenlights
Package: offlineimap Version: 6.3.4-1 Severity: normal Sometimes, randomly, only when ui is set to Blinkenlights, the offlineimap crashes rigth at start with: OfflineIMAP 6.3.4 Copyright 2002-2011 John Goerzen contributors. Licensed under the GNU GPL v2+ (v2 or any later version). 2: [active] *Control: . Thread 'InputHandler loop' terminated with exception: Traceback (most recent call last): File /usr/lib/pymodules/python2.7/offlineimap/threadutil.py, line 140, in run Thread.run(self) File /usr/lib/python2.7/threading.py, line 505, in run self.__target(*self.__args, **self.__kwargs) File /usr/lib/pymodules/python2.7/offlineimap/ui/Curses.py, line 281, in bgreaderloop ch = s.c.stdscr.getch() AttributeError: CursesUtil instance has no attribute 'stdscr' No debug messages were logged for InputHandler loop. when running it again, it starts and completes without any problems. Bug appears sporadically but consistently, in about 5% of the runs. I'm using multiple threads in offlineimap, if it may be related. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages offlineimap depends on: ii python 2.7.3-4+deb7u1 ii python-support 1.0.15 offlineimap recommends no packages. Versions of packages offlineimap suggests: ii doc-base 0.10.4 pn python-kerberos none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650965: pdns-recursor: gives inconsistent results on subsequent queries
Package: pdns-recursor Version: 3.6.1-1~bpo70+1 Followup-For: Bug #650965 Unfortunately, inconsistency bug still appears in 3.6.1-1~bpo70+1 from wheezy-backports. This time not fatal (as domain data didn't change), but subsequent calls to pdns-recursor return different TTL data (indicating it keeps two different cached versions for same data): for example (all request are to this one pdns-recursor instance via /etc/resolv.conf). You'll notice in attached report TTL being 77xxx, then 28xxx, then again 77xxx, and again 28xxx and repeating. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages pdns-recursor depends on: ii adduser 3.113+nmu3 ii libc62.13-38+deb7u6 ii libgcc1 1:4.7.2-5 ii liblua5.2-0 5.2.1-3+deb7u1 ii libstdc++6 4.7.2-5 ii lsb-base 4.1+Debian8+deb7u1 Versions of packages pdns-recursor recommends: pn pdns-doc none pdns-recursor suggests no packages. -- Configuration Files: /etc/powerdns/recursor.conf changed: allow-from=127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10, 83.139.110.0/26, 2a00:dd8:0:1::1e/126, 2a00:dd8:8000:100::/56 chroot=/var/empty dont-query=fe80::/10 forward-zones-file=/etc/powerdns/forward-zones.cfg local-address=192.168.200.254 local-port=53 query-local-address=83.139.110.1 query-local-address6=2a00:dd8:8000:110::1 quiet=yes setgid=pdns setuid=pdns -- no debconf information % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62962 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 77083 IN NS ns2.incloud.hr. inside.hr. 77083 IN NS ns1.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:18 2014 ;; MSG SIZE rcvd: 71 % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 5264 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 77079 IN NS ns2.incloud.hr. inside.hr. 77079 IN NS ns1.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:21 2014 ;; MSG SIZE rcvd: 71 % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 55603 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 28036 IN NS ns1.incloud.hr. inside.hr. 28036 IN NS ns2.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:22 2014 ;; MSG SIZE rcvd: 71 % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 39498 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 77078 IN NS ns2.incloud.hr. inside.hr. 77078 IN NS ns1.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:23 2014 ;; MSG SIZE rcvd: 71 % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25100 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 77075 IN NS ns2.incloud.hr. inside.hr. 77075 IN NS ns1.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:26 2014 ;; MSG SIZE rcvd: 71 % dig ns inside.hr ; DiG 9.8.4-rpz2+rl005.12-P1 ns inside.hr ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 64829 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;inside.hr. IN NS ;; ANSWER SECTION: inside.hr. 77074 IN NS ns2.incloud.hr. inside.hr. 77074 IN NS ns1.incloud.hr. ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) ;; WHEN: Wed Nov 26 15:15:26 2014 ;;
Bug#767243: mdadm: a new disk always remains spare instead of becoming active
Package: mdadm Version: 3.2.5-5 Severity: normal The problem is that newly added disk in 2-device RAID1 (intended to replace failing disk) is remaining as 'spare' and cannot be made active. History: there were two disks, 'sde' and 'sdf' (back then with different names, of course) in RAID1 with no spares. 'sdf' died, and was replaced with 'sdc', and everything was synced (probably successfuly, but I can't guarantee it - it was possible problem was present even then but wasn't critical). Now 'sde' is also showing disk errors, and we're trying to replace it with new 'sdd' disk. Tt works for all RAID1 partition but /dev/md2 (which is root filesystem). It says that only active device in RAID is 'sde2' (problematic disc): md2 : active raid1 sdc2[2](S) sde2[1] 48795520 blocks super 1.2 [2/1] [U_] bitmap: 1/1 pages [4KB], 65536KB chunk I've tried: - mdadm --zero-superblock /dev/sdd2 mdadm --add /dev/md2 /dev/sdd2 this does the sync, but as soon as we're over 99% and it ends, /dev/sdd2 is marked as spare instead of active: md2 : active raid1 sdd2[3] sdc2[2](S) sde2[1] 48795520 blocks super 1.2 [2/1] [U_] [===.] recovery = 98.1% (47889664/48795520) finish=0.0min speed=171438K/sec bitmap: 1/1 pages [4KB], 65536KB chunk md2 : active raid1 sdd2[3](S) sdc2[2](S) sde2[1] 48795520 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk # mdadm -D /dev/md2 /dev/md2: Version : 1.2 Creation Time : Mon Dec 9 09:13:46 2013 Raid Level : raid1 Array Size : 48795520 (46.54 GiB 49.97 GB) Used Dev Size : 48795520 (46.54 GiB 49.97 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Wed Oct 29 15:29:28 2014 State : clean, degraded Active Devices : 1 Working Devices : 3 Failed Devices : 0 Spare Devices : 2 Name : debian:2 UUID : 78009515:2a02c34f:976f01ac:b35c9ee0 Events : 5289 Number Major Minor RaidDevice State 1 8 660 active sync /dev/sde2 1 001 removed 2 8 34- spare /dev/sdc2 3 8 50- spare /dev/sdd2 - Then I've tried mdadm --grow -n 2 /dev/md2, which replied mdadm: /dev/md2: no change requested. - Forcing mdadm --grow -n 1 --force /dev/md2; mdadm --grow -n 2 /dev/md2 makes the changes, but the mdadm -D /dev/md2 output remains exactly the same (1 active, 2 spare). - mdadm --remove /dev/md2 /dev/sdd2, mdadm --add /dev/md2 /dev/sdd2, etc. also never make active device bigger than 1. - mdadm --remove failed /dev/md2 and mdadm --remove detached /dev/md2 do not report error, but do not change mdadm -D /dev/md2 output either. I'd like to have only 'sdc' and 'sdd' in RAID1 when this is finished (so I can remove faulty 'sde' from machine) This looks like the similar issue as archived bug #603343 (but I'm running up-to-date debian wheezy, only with kernel from wheezy-backports due to needed hardware support). I can try some more things and provide more info if needed for debug, but will eventually need to shutdown and reinstall RAID array soon if no solution is found. -- Package-specific info: --- mdadm.conf CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST system MAILADDR root ARRAY /dev/md/0 metadata=1.2 UUID=58606e8a:bc27f4f0:f2aacce7:0c62b968 name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=d0d4ac06:6d7affe7:2a9668b8:4a08d5a2 name=debian:1 ARRAY /dev/md/2 metadata=1.2 UUID=78009515:2a02c34f:976f01ac:b35c9ee0 name=debian:2 ARRAY /dev/md/3 metadata=1.2 UUID=1fb0ef02:487bcabc:0889b021:bbcf076b name=debian:3 ARRAY /dev/md/4 metadata=1.2 UUID=6afcb7bf:3daeacf4:f1bc433d:f8f153be name=debian:4 ARRAY /dev/md/5 metadata=1.2 UUID=57c56f38:3c7f00da:d0af5afe:28d9cb58 name=debian:5 ARRAY /dev/md/6 metadata=1.2 UUID=706266de:7af51091:7246dfb4:677916d4 name=debian:6 --- /etc/default/mdadm INITRDSTART='all' AUTOSTART=true AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS=--syslog VERBOSE=false --- /proc/mdstat: Personalities : [raid1] md6 : active raid1 sdd7[3] sdc7[2] 5077952 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md5 : active raid1 sdd6[3] sdc6[2] 722523968 blocks super 1.2 [2/2] [UU] bitmap: 0/6 pages [0KB], 65536KB chunk md4 : active raid1 sdd5[3] sdc5[2] 97589120 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md3 : active raid1 sdd3[3] sdc3[2] 97590144 blocks super 1.2 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk md2 : active raid1 sdc2[2](S) sde2[1] 48795520 blocks super 1.2 [2/1] [U_] bitmap: 1/1 pages [4KB], 65536KB chunk md1 : active raid1 sdd1[3] sdc1[2] 4877248 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md0 : active raid1 sda1[0] sdb1[1] 117153664 blocks super 1.2
Bug#767243: mdadm: a new disk always remains spare instead of becoming active
Summary: Thanks for your quick feedback! You can close this as invalid. I do understand BTS is not general support forum, and I was genuinely believing that there was bug in mdadm, as I though both source and destination disks were without errors (despite SMART errors I've got on /dev/sde, it looked undamaged and it's removal was supposed to be preemptive). That belief was reinforced by seeing /proc/mdstat showing sync progress going above 99.9% without aborting. The steps I've tried that look like usage errors (-G -n2, ...) were my last-resort (perhaps misguided) attempts to force mdadm to realize there are supposed to be two ACTIVE disks in the array (aand not active+spare) - and I've only tried them the because regular way (mdadm --add, --remove) didn't work when I though it really should. That being said, you were correct afterall :-) Your response prompted me to doublecheck, and I've run badblocks(8) on both destination disks (both ok) and source /dev/sde2 disk. And the source disk was really having bad sectors - about 80 of them, at 99.97%. That last 0.03% was visually too quick to notice, so I was fooled by /proc/mdstat showing how it progresses from 0% to 99.9%+ without error and I wrongly assumed it did manage to finish the sync (but somehow didn't update the active/spares, due to some bug) Some hammering with hdparm --write-sector managed to zero-out that few sectors (which didn't appear to be used by any files), and after that mdadm did finish the sync. Anyway, may the bug be archived for future adventurers with same problem. -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#144191: workaround
same problem here (Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller). Workaround for me is to specify -o oss and use OSS emulation layer on top of ALSA instead, or -o alsa09 (instead of default -o alsa which plays at double speed). -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657405: mediagoblin: no more missing dependencies
On Mon, Oct 13, 2014 at 11:33:11PM -0400, Simon Fondrie-Teitler wrote: I should have posted that 0.6.1 is now in new (thanks Asheesh!). https://ftp-master.debian.org/new/mediagoblin_0.6.1+dfsg1-1.html That is great news indeed! Thanks Asheesh! In terms of Jessie, I'm actually not aiming to get it in, and either Asheesh or I will probably file an RC bug to prevent it from migrating to testing. Upstream is not planning on supporting either 0.6.1 or 0.7.1 for the next few years, and I can't commit to providing security support. I do welcome the thoughts of others on this issue though. Has the upstream indicated that they plan on doing long term support on some later version? If so, then OK, I agree it might be good idea to wait for that (even if we miss Jessie). If not, then I'd assume it would be like with vast majority of other packages - only last version ever gets fixes (perpetual development model). If you're lucky, some packages have a practice that the most important fixes might be released as new point release (or two) for last stable version, but that support (when available) is also usually measured in at most months, and certainly not years. If the current development model of mediagoblin is any indication of future, it will follow the same path: you'll get minor bugfix from 0.6.0 to 0.6.1, but next one will be major 0.7.0, and after that it would be end of support for 0.6.x. Same will probably be with 0.7.0 - 0.7.1 - 0.8.0, etc. What am I getting at, is that most packages work that way (without providing LTS), and yet they're readily available in Debian Testing and Stable. Blocking mediagoblin until upstream commits to LTS would probably result in mediagoblin never getting into stable, which I think would be great shame, as I think (especially due to its distributed nature) mediagoblin would suffer greatly if it is not available easily as prepared package in distributions - most people will never even consider wget/unpack/get and build dependencies/compile/install route. So I'd ask Asheesh and you to reconsider allowing mediagoblin in Jessie. If there are any (security or otherwise) bugs you think are preventing it NOW from entering testing, by all means do voice your concerns, so others (like myself) might try to help. But I do not think abstract fear of the possible future should be RC bug... And if/when security bugs happen later in the cycle, I'd like to help too. I'm no great python hacker (perl is more of my forte), but I do manage around, and I think I could be of help backporting security fixes if needed. But, as words are cheap, I'll show some git work on mediagoblin in next week. -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657405: mediagoblin: no more missing dependencies
On Sat, Oct 11, 2014 at 01:29:56PM +0200, W. Martin Borgert wrote: On 2014-10-11 02:52, Matija Nalis wrote: Wow, thanks for quick work! You need to thank the FTP masters! Well, then I thank them too! extlib/tinymce/js/tinymce/tinymce.min.js I assume, that this could be left out during installation and you can depend on either: python-django-tinymce - replacement text widget for Django web framework tinymce - platform independent web based Javascript/HTML WYSIWYG editor Yes, it could depend on tinymce. However, Debian packages tinymce 3.4.8, and mediagoblin uses tinymce 4.0.2 which is a problem because: - they use different directory structure / filenames (could be worked around with symlinks) - they use quite different API Also, in upstream mediagoblin 0.7.1 tinyMCE is used only in default (airy) theme in file mediagoblin/themes/airy/templates/mediagoblin/extra_head.html, but due to the (simple) bug does not work... The possible solutions I see: 1) package tinymce4 for debian, make mediagoblin recommend it, and fix simple 0.7.1 bug (wrong CSS selector used). Problem with this solution is that packaging new major tinymce is much work (and we don't have much time for getting mediagoblin in jessie) 2) modify mediagoblin to depend on tinymce 3.4.8 currently in debian (and fix mediagoblin tinyMCE selector bug in the process). Much less work, but tinyMCE3 and 4 look different... 3) modify mediagoblin default airy theme to not use tinyMCE at all (as it doesn't work in stock 0.7.1 anyway), and then revisit problem later when upstream fixes that. It's as simple as deleting both script blocks from extra_head.html. 4) just leave it as it is, it will behave like stock 0.7.1 (i.e. tinymce not working), but will leave 404s in the logs. But as we don't need to do *any* work, it is the simplest solution. 5) use the included copy of tinymce4 (and fix the selector bug). IIRC Debian policy is not happy with this solution, so it should probably be avoided. My order of (descending) preference is 3,4,2,1,5. What do you think should best be done? fonts/Lato-Regular.ttf Maybe this is already packaged? fonts-lato - sans-serif typeface family font Yes, sorry for the noise, that was my bad (didn't notice I didn't have all recommended packages installed). Mediagoblin does indeed recommend fonts-lato, and has symlinks setup correctly so it works OK. Martin: what do you think would be needed to get mediagoblin pushed into debian NEW queue so it would make it to stable Jessie? I'm willing to do extra work helping making this happen if Simon is short on time. Would you help with DD / sponsoring part (or whatever is correct procedure)? Thanks, Matija -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
