Bug#1063145: x11-to-wayland-regression: clipboard copy-paste from chromium to konsole doesn't work
Package: kwin-wayland Version: 4:5.27.10-1 Severity: normal This is X11-to-Wayland regression. Steps to reproduce: - Start KDE in Wayland mode - Open konsole window - Open chromium window - Copy to clipboard some text from chromium - Close chromium - Try to paste the text to konsole This will not work. I use up-to-date sid. Versions: kwin-wayland 4:5.27.10-1 xwayland 2:23.2.4-1 konsole4:23.08.1-1 chromium 121.0.6167.139-1 plasma-workspace-wayland 4:5.27.10-3 qtwayland5:amd64 5.15.10-2 xserver-xorg 1:7.7+23 kwin-x11 4:5.27.10-1 The bug is not reproducible with X11! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kwin-wayland depends on: ii kwayland-integration 5.27.10-1 ii kwin-common4:5.27.10-1 ii libc6 2.37-15 ii libcap2-bin1:2.66-4+b2 ii libepoxy0 1.5.10-1+b2 ii libfontconfig1 2.14.2-6+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libkdecorations2-5v5 4:5.27.10-1 ii libkf5configcore5 5.107.0-1 ii libkf5configgui5 5.107.0-1 ii libkf5configwidgets5 5.107.0-2 ii libkf5coreaddons5 5.107.0-1 ii libkf5crash5 5.107.0-1 ii libkf5dbusaddons5 5.107.0-1 ii libkf5globalaccel-bin 5.107.0-2 ii libkf5globalaccel5 5.107.0-2 ii libkf5globalaccelprivate5 5.107.0-2 ii libkf5i18n55.107.0-1+b1 ii libkf5idletime55.107.0-1 ii libkf5notifications5 5.107.0-1 ii libkf5plasma5 5.107.0-1 ii libkf5service-bin 5.107.0-1 ii libkf5service5 5.107.0-1 ii libkf5windowsystem55.107.0-1 ii libkwineffects14 4:5.27.10-1 ii libkwinglutils14 4:5.27.10-1 ii libpipewire-0.3-0 1.0.3-1 ii libqaccessibilityclient-qt5-0 0.6.0-1 ii libqt5core5a [qtbase-abi-5-15-10] 5.15.10+dfsg-6 ii libqt5dbus55.15.10+dfsg-6 ii libqt5gui5 5.15.10+dfsg-6 ii libqt5network5 5.15.10+dfsg-6 ii libqt5qml5 5.15.10+dfsg-2 ii libqt5quick5 5.15.10+dfsg-2 ii libqt5widgets5 5.15.10+dfsg-6 ii libstdc++6 14-20240201-3 ii libxcb-randr0 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb11.15-1 ii xwayland 2:23.2.4-1 kwin-wayland recommends no packages. kwin-wayland suggests no packages. -- no debconf information
Bug#509100: Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied
I found a workaround. If you need to install build dependencies for package X, just create a fake package, which has "Depends", which are equal to X's "Build-Depends". Then install this fake package via aptitude. Possibility of such workaround means that aptitude already has all needed machinery. We just need to make aptitude to treat "Build-Depends" in similar way to "Depends" -- Askar Safin
Bug#1061169: aptitude: "aptitude install debhelper-compat" fails with "virtual package provided by: debhelper debhelper debhelper"
Package: aptitude Version: 0.8.13-5+b1 Severity: normal Steps to reproduce: - Create fresh sid system - Type "aptitude install debhelper-compat" The command will fail with the following absolutely absurd message: # aptitude install debhelper-compat "debhelper-compat" is a virtual package provided by: debhelper debhelper debhelper debhelper debhelper You must choose one to install. Unable to apply some actions, aborting apt works correctly -- Package-specific info: Terminal: xterm $DISPLAY not set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.13 Compiler: g++ 13.2.0 Compiled against: apt version 6.0.0 NCurses version 6.4 libsigc++ version: 2.12.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.4.20240113 cwidget version: 0.5.18 Apt version: 6.0.0 aptitude linkage: linux-vdso.so.1 (0x7ffcf0934000) libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 (0x7fb020e0) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7fb020dc6000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7fb020d91000) libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fb020d88000) libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 (0x7fb020c86000) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fb020b14000) libboost_iostreams.so.1.83.0 => /lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7fb020afa000) libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 (0x7fb0208c9000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fb020673000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb020594000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fb02057) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb02038c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb02036d000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fb02035a000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb02032a000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb020304000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fb020243000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fb02020e000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x7fb02012c000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7fb01ffe4000) libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 (0x7fb01ffd1000) /lib64/ld-linux-x86-64.so.2 (0x7fb02148) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb01ffc7000) libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fb01ffb9000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7fb01ff9) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.24-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 /usr/bin/dash Init: unable to detect Versions of packages aptitude depends on: ii aptitude-common 0.8.13-5 ii libapt-pkg6.0 2.7.8 ii libboost-iostreams1.83.0 1.83.0-2+b2 ii libc6 2.37-13 ii libcwidget4 0.5.18-6+b1 ii libgcc-s1 13.2.0-9 ii libncursesw6 6.4+20240113-1 ii libsigc++-2.0-0v5 2.12.1-1 ii libsqlite3-0 3.44.2-1 ii libstdc++613.2.0-9 ii libtinfo6 6.4+20240113-1 ii libxapian30 1.4.22-1 Versions of packages aptitude recommends: pn libdpkg-perl ii sensible-utils 0.0.20 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags pn tasksel -- no debconf information
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
I tried aptitude and it works! Thank you for your help! aptitude behaves properly in example from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229775#66 (message 66). Moreover, stretch's aptitude version behaves properly (i. e. in the way I need). So, my problem is solved. But I still think "man apt_preferences" is incomplete. Please, add to the first page of the manual something like this: "apt's priority-aware dependency resolution algorithm is simplistic. Sometimes it is unable to find any solution. If you find yourself in such situation, consider using aptitude, it has advanced resolution algorithm" -- Askar Safin
Bug#895874: git-email: Should depend on libmailtools-perl for Mail::Address
Package: git-email Version: 1:2.43.0-1 Followup-For: Bug #895874 X-Debbugs-Cc: jrnie...@gmail.com, safinas...@gmail.com The bug is still present in modern versions of git-email. I. e. after 6 years it is still not fixed. I did some experiments and I figured that the following 3 packages should be added to "Depends": libmailtools-perl libauthen-sasl-perl ca-certificates They are required for sending mail -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.24-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 /usr/bin/dash Init: unable to detect Versions of packages git-email depends on: ii git 1:2.43.0-1 Versions of packages git-email recommends: ii libauthen-sasl-perl2.1700-1 pn libemail-valid-perl ii libio-socket-ssl-perl 2.084-1 ii libmailtools-perl 2.21-2 ii libnet-smtp-ssl-perl 1.04-2 ii perl 5.38.2-3 Versions of packages git-email suggests: pn git-doc -- no debconf information
Bug#1060914: reportbug: [PATCH] Fully remove config option "cc"
Package: reportbug
Version: 13.0.0
Severity: normal
Tags: patch
X-Debbugs-Cc: safinas...@gmail.com
Please, apply this patch. It is against current master (
9ee3cd8db321283319c3c8e96a96acb3a659cdb8 ).
All motivation/rationale is inside the patch itself.
Tested by building and sending this very email.
-- Package-specific info:
** Environment settings:
INTERFACE="text"
** /root/.reportbugrc:
reportbug_version "12.0.0"
mode advanced
ui text
realname "Askar Safin"
email "safinas...@gmail.com"
no-check-uid
list-cc-me
smtphost reportbug.debian.org
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-0.deb9.24-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages reportbug depends on:
ii apt2.7.7
ii python33.11.4-5+b1
ii python3-reportbug 13.0.0
ii sensible-utils 0.0.20
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
ii debconf 1.5.82
pn debsums
pn default-mta | postfix | exim4 | mail-transport-agent
pn dlocate
pn emacs-bin-common
ii file 1:5.45-2
ii gnupg 2.2.40-1.1
pn python3-urwid
pn reportbug-gtk
pn xdg-utils
Versions of packages python3-reportbug depends on:
ii apt2.7.7
ii file 1:5.45-2
ii python33.11.4-5+b1
ii python3-apt2.7.0
ii python3-debian 0.1.49
ii python3-debianbts 4.0.2
ii python3-requests 2.31.0+dfsg-1
ii sensible-utils 0.0.20
python3-reportbug suggests no packages.
-- no debconf information
>From 064c4ae6c008760add008c89f6c9d7328312c341 Mon Sep 17 00:00:00 2001
From: Askar Safin
Date: Tue, 16 Jan 2024 11:30:24 +
Subject: [PATCH] Fully remove config option "cc"
Fully remove config options "cc" and "no-cc". And CLI options "-x" and
"--no-cc".
And all related code, tests and documentation.
Current code contains two ways of controlling CC'ing reporter:
1. CLI options "-x", "--no-cc", config options "cc", "no-cc"
2. CLI option "--list-cc-me", config option "list-cc-me"
It seems that the second way was added later. And it seems to work.
The first way seems not to work with current bugs.debian.org .
So let's just remove the first way. This will simplify code and
documentation.
Now user will get a warning if their config contains "cc".
But I don't think this is bad. This is just a warning
---
bin/reportbug| 9 +
conf/reportbug.conf | 3 ---
man/reportbug.1 | 4
man/reportbug.conf.5 | 3 ---
reportbug/utils.py | 4 +---
test/data/reportbug.conf | 1 -
test/test_utils.py | 1 -
7 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/bin/reportbug b/bin/reportbug
index 34961d6..1fb17a2 100755
--- a/bin/reportbug
+++ b/bin/reportbug
@@ -691,13 +691,11 @@ def offer_configuration(options):
if stupidmode:
print('# Disable fallback mode by commenting out the following:',
file=fp)
-print('no-cc', file=fp)
print('list-cc-me', file=fp)
print('smtphost reportbug.debian.org', file=fp)
else:
print('# If nothing else works, remove the # at the beginning',
file=fp)
print('# of the following three lines:', file=fp)
-print('#no-cc', file=fp)
print('#list-cc-me', file=fp)
print('#smtphost reportbug.debian.org', file=fp)
@@ -847,8 +845,6 @@ def main():
parser.add_option('-q', '--quiet', action='store_true', dest='quietly',
help='reduce the verbosity of the output', default=False)
parser.add_option('-s', '--subject', help='the subject for your report')
-parser.add_option('-x', '--no-cc', dest='nocc', action='store_true',
- help='do not send a copy of the report to yourself')
parser.add_option('-z', '--no-compress', dest='nocompress',
action='store_true', help='do not strip blank lines '
'and comments from config
files')
@@ -1820,10 +1816,7 @@ class UI(object):
return
ccaddr = os.environ.get('MAILCC')
-if self.options.nocc:
-bccaddr = os.environ.get('MAILBCC')
Bug#1060854: reportbug: @example.com is rejected
Package: reportbug Version: 12.0.0 Severity: normal When I try to specify a...@example.com as my email address, it is rejected. I don't like this. Such addresses should be supported. They are good for testing "reportbug" util. Full log: # reportbug Welcome to reportbug! Since it looks like this is the first time you have used reportbug, we are configuring its behavior. These settings will be saved to the file "/root/.reportbugrc", which you will be free to edit further. Please choose the default operating mode for reportbug. 1 noviceOffer simple prompts, bypassing technical questions. 2 standard Offer more extensive prompts, including asking about things that a moderately sophisticated user would be expected to know about Debian. 3 advanced Like standard, but assumes you know a bit more about Debian, including "incoming". 4 expertBypass most handholding measures and preliminary triage routines. This mode should not be used by people unfamiliar with Debian's policies and operating procedures. Select mode: [novice] 3 Will reportbug often have direct Internet access? (You should answer yes to this question unless you know what you are doing and plan to check whether duplicate reports have been filed via some other channel.) [Y|n|q|?]? What real name should be used for sending bug reports? [root]> a Which of your email addresses should be used when sending bug reports? (Note that this address will be visible in the bug tracking system, so you may want to use a webmail address or another address with good spam filtering capabilities.) [root@fc2e0df8e121]> a...@example.com Your email address is not valid; please try another one. Which of your email addresses should be used when sending bug reports? (Note that this address will be visible in the bug tracking system, so you may want to use a webmail address or another address with good spam filtering capabilities.) [root@fc2e0df8e121]> a...@exammppllee.com Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP configured on this computer to send mail to the Internet [y|N|q|?]? -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "12.0.0" mode advanced ui text realname "Askar Safin" email "safinas...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.24-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages reportbug depends on: ii apt2.7.7 ii python33.11.4-5+b1 ii python3-reportbug 12.0.0 ii sensible-utils 0.0.20 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.82 pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.45-2 ii gnupg 2.2.40-1.1 pn python3-urwid pn reportbug-gtk pn xdg-utils Versions of packages python3-reportbug depends on: ii apt2.7.7 ii file 1:5.45-2 ii python33.11.4-5+b1 ii python3-apt2.7.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.2 ii python3-requests 2.31.0+dfsg-1 ii sensible-utils 0.0.20 python3-reportbug suggests no packages. -- no debconf information
Bug#1059967: less: [fixed upstream] Colored text disappears when I try to search it. Reproducible in "less -R", when input is colored (such as "grep --color=always")
Package: less Version: 590-2 Severity: normal Fixed upstream! Steps to reproduce: - Execute command "echo axb | grep --color=always x | less -R" - When less spawns, press "/", then "x", then "Enter" "x" will disappear. This is a bug. Fortunately, the bug is not present in latest upstream release, i. e. in 649. So, please, upload new version -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.24-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages less depends on: ii libc6 2.37-12 ii libtinfo6 6.4+20231121-1 less recommends no packages. less suggests no packages. -- no debconf information
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
Package: apt Followup-For: Bug #229775 X-Debbugs-Cc: Johannes Schauer Marin Rodrigues , David Kalnischkies Johannes Schauer Marin Rodrigues: > It feels to me like what you are describing as a bug is like saying that dash > is buggy because it does not support arrays David Kalnischkies: > All that small incomplete sentence in the summary section of the manpage > provides is that a solver *might* deviate from installing the highest > version Thank you for lengthy answers. Okay, then please apply the following patch. :) (Or something with similar meaning.) Feel free to close the bug when the patch is released. (Sent using "reportbug", so I hope whitespace is okay.) diff --git a/doc/apt_preferences.5.xml b/doc/apt_preferences.5.xml index 1b38ae1..1478770 100644 --- a/doc/apt_preferences.5.xml +++ b/doc/apt_preferences.5.xml @@ -39,12 +39,21 @@ for installation. the file contains references to more than one distribution (for example, stable and testing). APT assigns a priority to each version that is available. -Subject to dependency constraints, apt-get selects the +apt-get selects the version with the highest priority for installation. The APT preferences override the priorities that APT assigns to package versions by default, thus giving the user control over which one is selected for installation. +If picking the version with the highest priority leads to violation +of dependency constraints, then sometimes +apt chooses low-priority correct version instead of high-priority +incorrect one. But sometimes apt simply fails with an error message +in such situation, and this is not considered a bug. If you want package +manager to always choose low-priority correct version instead of +high-priority incorrect version in such situation, then use other package +managers instead of apt. + Several instances of the same version of a package may be available when the file contains references to more than one source. In this case apt-get downloads the instance listed
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
ase
Codename: backports
Architectures: $ARCH
Components: main
Date: Thu, 1 Jan 1970 00:00:00 UTC
EOF
cat << EOF > /etc/apt/sources.list
deb file:///repo stable main
deb file:///repo backports main
EOF
cat << EOF > /etc/apt/preferences
Package: *
Pin: release n=backports
Pin-Priority: 499
Package: *
Pin: release n=stable
Pin-Priority: 500
EOF
mkdir -p /etc/apt/preferences.d
mkdir -p /etc/apt/apt.conf.d
cat << EOF > /etc/apt/apt.conf
Acquire::AllowInsecureRepositories yes;
EOF
apt-get update --quiet --quiet
apt-get install "/root/dependent_1_${ARCH}.deb"
=*=*=*=*=*=*=*=
Here is output:
===
Get:1 http://deb.debian.org/debian sid InRelease [198 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 Packages [9626 kB]
Fetched 9824 kB in 6s (1522 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
[..snip..]
Setting up dpkg-dev (1.22.2) ...
Processing triggers for libc-bin (2.37-12) ...
dpkg-deb: building package 'dependency' in
'/repo/dists/stable/main/binary-amd64/dependency_1_amd64.deb'.
dpkg-deb: building package 'dependency' in
'/repo/dists/backports/main/binary-amd64/dependency_2_amd64.deb'.
dpkg-deb: building package 'dependent' in '/root/dependent_1_amd64.deb'.
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
W: The repository 'file:/repo stable Release' is not signed.
W: No Hash entry in Release file
/var/lib/apt/lists/partial/_repo_dists_stable_Release
W: The repository 'file:/repo backports Release' is not signed.
W: No Hash entry in Release file
/var/lib/apt/lists/partial/_repo_dists_backports_Release
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'dependent' instead of '/root/dependent_1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
dependent : Depends: dependency (>= 2) but 1 is to be installed
E: Unable to correct problems, you have held broken packages.
===
So, I reproduced the very same bug, but this time with fully
artifactual packages. Note that "build-dep" is not involved. Bug is
reproducible with the usual "apt-get install".
> Support for stretch ended nearly a decade ago
You mixed up stretch and squeeze. According to Wikipedia,
support for stretch ended in 2020.
--
Askar Safin
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
Package: apt Version: 2.7.7 Followup-For: Bug #229775 This bug (#229775) is still reproducible with current apt version (apt 2.7.7). The bug can be summarized so: "apt-get build-dep" fails to install a package from a repo if its priority is slightly less than priority of installed release. In more details: "apt-get build-dep" fails to install a package from backports if backports priority is set to 499 and installed release have its default priority (i. e. 500, as well as I understand). Here are steps to reproduce. But please note: the steps to reproduce below involve stretch. But despite this, please note that the bug is reproducible with apt 2.7.7! Yes, I did run apt 2.7.7 on stretch! Now let me show you steps to reproduce: Build docker container using this dockerfile: FROM debian:stretch ENV LC_ALL C.UTF-8 RUN echo deb http://archive.debian.org/debian stretch main > /etc/apt/sources.list RUN echo deb http://archive.debian.org/debian-security stretch/updates main >> /etc/apt/sources.list RUN apt-get update RUN apt-get install -y --no-install-recommends apt-utils whiptail RUN apt-get dist-upgrade -y --no-install-recommends RUN apt-get install -y --no-install-recommends build-essential RUN echo deb http://archive.debian.org/debian stretch-backports main >> /etc/apt/sources.list RUN echo deb-src http://deb.debian.org/debian buster main >> /etc/apt/sources.list RUN apt-get update RUN printf 'Package: *\nPin: release n=*backports*\nPin-Priority: 499\n' > /etc/apt/preferences RUN apt-get build-dep -y --no-install-recommends cmake || : # This command fails RUN printf 'Package: *\nPin: release n=*backports*\nPin-Priority: 500\n' > /etc/apt/preferences RUN apt-get build-dep -y --no-install-recommends cmake # Success If you don't have docker, then you can do this instead: - Create fresh stretch system using "debootstrap --variant=minbase" - Then run commands above in this stretch one after one I tried commands above in docker and was able to reproduce the bug. I didn't try debootstrap way, but I'm nearly sure the bug will reproduce, too. If backports priority is set to 499, then "apt-get build-dep -y --no-install-recommends cmake" will print this: === # apt-get build-dep -y --no-install-recommends cmake Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:cmake : Depends: libuv1-dev (>= 1.10) but 1.9.1-3 is to be installed E: Unable to correct problems, you have held broken packages. === I think this is a bug: dependecies can be satisfied if one really tries. If I set backports priority to 500, then "apt-get build-dep" is able to install needed packages. So, apt-get doesn't try hard enough. Requirement "libuv1-dev (>= 1.10)" can be satisfied: stretch-backports has libuv1-dev 1.34.2-1~bpo9+1, but it is ignored, and this is a bug. I reproduced this bug using apt 2.7.7. To do this I copied apt 2.7.7 binary and all its .so files to stretch and then I did run this: /tmp/apt-get.d/ld.so --library-path /tmp/apt-get.d/libs /tmp/apt-get.d/apt-get ... I. e. I was able to do this using "ld.so --library-path" trickery. Okay, now you may wonder why I think this is a bug, why I need this and why I don't like current behavior. Let me answer. Go to Debian IRC (a. k. a. OFTC IRC), join #debian channel and write to bot nicknamed "dpkg" the following text: "simple sid backport". The bot will respond to you with the following *very* helpful text: === First, check for a backport on . If unavailable: 1) Add a deb-src line for sid (not a deb line!); ask me about 2) enable debian-backports (see ) 3) apt update; apt install build-essential; apt build-dep packagename 4) apt -b source packagename 5) dpkg -i packagename-ver.deb To change compilation options, see ; for versions newer than sid see . === I use stretch as my main system. So I often need to backport packages. And I do this using instruction above. When I do 3rd step, i. e. "apt-get build-dep", I want apt to search in stretch and then in stretch-backports. Unfortunately, I was unable to find configuration, which achieve this. If I do not set apt_preferences at all, then stretch-backports is ignored by "apt-get build-dep" (reproduction steps listed above). If I set backports priority to 499, then the same happens. If I set backports priority to 500, then stretch-backports is prefered if its package is newer than stretch's. But stretch-backports always has newer packages than stretch, so stretch-backports is always prefered! But I want stretch to be prefered. Hence there is simply no configuration, which meets my goals. Again: I want stretch-backports to be visible, but I
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
I did some experiments and wrote a patch! Okay, so, I spend some more time thinking about this. And I think the bug is in apt's completion scripts. Because that *.bin files are simply cache. And lack of caches should not break program! This follows from my interpretation of FHS 3.0 5.5 ( https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html ). And that *.bin files are located in /var/cache. And debian policy refers to FHS 3.0 ( https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy ). So, the bug is in apt's completion scripts and we should simply remove "--no-generate" from them. And hence I attach a patch, which does exactly that. This will cause completion scripts to regenerate caches as needed. This will work even if *.bin files are not present. And this will work even if we are in unprivileged bash, I tested this. Okay, so you can ask: what are speed implications of this? Well, I tested this on my main system (Intel Core i7) and I feel that even full cache regeneration takes zero time, i. e. it is absolutely instant. So I started qemu-system-x86_64 without -enable-kvm and tested there. Results are this: if caches are not present, then bash-completion is slow, it takes something like 10 seconds (in qemu in emulation mode!!!). But if caches are present, then bash-completion feels fast. So, it seems that apt is smart, it regenerates cache only if needed. So, there is no need to insert special "if" in completion scripts to check whether we should regenerate caches, apt already does this. Also, I found that file /usr/share/bash-completion/completions/apt is owned by apt, but file /usr/share/bash-completion/completions/apt-get is owned by bash-completion . So, I apply patch to "apt" only. Needed patch for "apt-get" is essentially the same. Also, I think "apt-get" (and similar) scripts should be transferred from "bash-completion" package to "apt". This patch is for current apt's "main", 9da15d149f97e0f26cf5b7e32405512a5e63523c . diff --git a/completions/bash/apt b/completions/bash/apt index 59a8eaa94..ff3d7bd24 100644 --- a/completions/bash/apt +++ b/completions/bash/apt @@ -173,6 +173,7 @@ _apt() fi # specific command arguments +# we don't pass "--no-generate" to "apt-cache" because we want completion to work even if caches are not present (#1034650) if [[ -v command ]]; then case $command in remove|purge|autoremove|autopurge) @@ -187,7 +188,7 @@ _apt() return 0 ;; show|list|download|changelog|depends|rdepends) -COMPREPLY=( $( apt-cache --no-generate pkgnames "$cur" \ +COMPREPLY=( $( apt-cache pkgnames "$cur" \ 2> /dev/null ) ) return 0 ;; @@ -195,7 +196,7 @@ _apt() if [[ "$cur" == .* || "$cur" == /* || "$cur" == ~* ]]; then _filedir "deb" else -COMPREPLY=( $( apt-cache --no-generate pkgnames "$cur" \ +COMPREPLY=( $( apt-cache pkgnames "$cur" \ 2> /dev/null ) ) fi return 0 @@ -204,7 +205,7 @@ _apt() if [[ "$command" == build-dep && ( "$cur" == .* || "$cur" == /* || "$cur" == ~* ) ]]; then _filedir "dsc" else -COMPREPLY=( $( apt-cache --no-generate pkgnames "$cur" \ +COMPREPLY=( $( apt-cache pkgnames "$cur" \ 2> /dev/null ) $( apt-cache dumpavail | \ command grep "^Source: $cur" | sort -u | cut -f2 -d" " ) ) fi
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
On Fri, May 5, 2023 at 8:53 PM Tianon Gravi wrote: > To be clear, there was nothing _certain_ in my response, merely that > my first impression matched Cyril's for the very similar issue on d-i. Okay, sorry for misunderstanding. -- Askar Safin
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
David Kalnischkies: > The completion script explicitly disables the recreation on-the-fly as > creating the files takes a while robbing users for many seconds of their > interactivity. So, we can't just "fix" the completion script as that has > a(nother?) set of users complain as well. Deleting /var/cache/apt/*.bin and then running "apt-cache gencaches" takes 0.22 on my (loaded) system. I propose regenerate caches in completion scripts only if they are not present. This will change situation from "not working at all" (in default d-i install and in official docker image) to "working slowly". Also, "working slowly" is just minor annoyance. But "not working" means that the user doesn't know how to fix. Yes, merely calling "apt-get install apt" will regenerate caches (in d-i case, not in docker case), but how the user should know this? The solution is not discoverable -- Askar Safin
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
Current apt behavior also breaks official debian docker images, I reported this here: https://github.com/debuerreotype/debuerreotype/pull/153 . The images' developer said this is apt completion scripts' problem -- Askar Safin
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
Четверг, 20 апреля 2023, 23:33 +03:00 от "Cyril Brulebois" : > Clearly one of these. It seems apt completion is located in /usr/share/bash-completion/completions/apt, which belongs to apt package. So, anyway this belongs to apt package, so I reassigned == Askar Safin
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
Package: debian-installer Severity: normal Tags: d-i Steps to reproduce: - Install debian using recently published debian-bookworm-DI- rc1-amd64-netinst.iso - At first boot as a very first thing to do type "apt-get install a" (as root, in normal root login shell) - You will see that bash-completion doesn't work - If you type "apt-get install apt", and try "apt-get install a" again, you will see that bash-completion works This situation is very bad. Imagine you installed Debian. Of course, the first thing you may try to do is install some package to it. So it is quite possible you will type "apt-get install ..." as a first thing. And you will see that bash-completion doesn't work! (Don't confuse "apt-get install a" with "apt-get insta") I think I know why this happens. d-i has file /usr/lib/finish- install.d/60cleanup. This file calls "apt-get clean". "apt-get clean" removes "/var/cache/apt/*.bin". And "/var/cache/apt/*.bin" are needed for bash- completion to work with apt. If I remove /usr/lib/finish-install.d/60cleanup, then this bug disappears. So, if you want to quickly fix this bug, simply delete /usr/lib/finish- install.d/60cleanup. I don't know what should really be done. I can list possible solutions: - Fix d-i. Remove /usr/lib/finish-install.d/60cleanup or replace it with something else - Fix "apt-get clean". Make it not remove /var/cache/apt/*.bin - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are not present (for example, by recreating them on-the-fly) (Disregard "System information" below) -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#275623: sync root's .bashrc and .profile with bash's skeletons
Yes, current situation breaks bash-completion. Moreover, it breaks bash-completion in standard debian images for docker. Because in this images you enter the container as root via non-login shell. So, bash-completion in docker simply doesn't work. So, please, copy /etc/skel/.bashrc to /root/.bashrc . I can write a patch, if you want. -- Askar Safin
Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)
/var/lib/dpkg/info/base-files.postinst installs /root/.bashrc from /usr/share/base-files/dot.bashrc . So /root/.bashrc is owned by base-files . I found this is already reported to base-files: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275623 . And moreover there is a message on bash-completion there, which CC you: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275623#58 . -- Askar Safin
Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)
I just did a little research. In sid chain for login shell for root is so: "bash --login" -> /etc/profile -> /etc/profile.d/bash_completion.sh -> /usr/share/bash-completion/bash_completion (But I still think we should just make /etc/skel/.bashrc to be default /root/.bashrc . This will fix other possible "user vs root" bugs. Currently /root/.bashrc doesn't have any non-comment lines, i. e. it doesn't contain anything useful anyway.) (Also this time I got your email properly.) -- Askar Safin
Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)
If I copy /etc/skel/.bashrc to /root/.bashrc , the bug disappears. Let's simply make /root/.bashrc to be a copy of /etc/skel/.bashrc . This will remove all "root vs user" bugs. P. S. For unknown reasons I didn't get your email, I discovered it by chance. I will try to report this to bugs.debian.org bug tracker -- Askar Safin
Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)
Package: bash-completion Version: 1:2.11-6 Severity: normal X-Debbugs-Cc: safinas...@gmail.com bash-completion (for example, "apt-get inst") doesn't work for root in non-login shell on default settings. Completion works for normal users. And completion works in login shells. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.21-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 /usr/bin/dash Init: unable to detect -- no debconf information
Bug#1034564: debbugs: "There is no record of Bug" after getting confirmation e-mail
Package: debbugs Severity: normal I just reported bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034563 . After some minutes I got confirmation e-mail titled "Bug#1034563: Acknowledgement (login: "su" doesn't put /sbin and /usr/sbin to PATH)" This e-mail contained a link " https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1034563 " I clicked the link. And I saw a text: == Debian Bug report logs - #1034563 There is no record of Bug #1034563. Try the search page instead. == Then I updated the page and saw proper bug report page. So I didn't saw bug report page immediately after clicking link from mail. This is a bug -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034563: login: "su" doesn't put /sbin and /usr/sbin to PATH
Package: login Version: 1:4.13+dfsg1-1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com Steps to reproduce: user@92fe0070d0e9:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games user@92fe0070d0e9:~$ su Password: root@92fe0070d0e9:/home/user# echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.21-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 /usr/bin/dash Init: unable to detect Versions of packages login depends on: ii libaudit1 1:3.0.7-1.1+b3 ii libc6 2.36-8 ii libcrypt1 1:4.4.33-2 ii libpam-modules 1.5.2-6 ii libpam-runtime 1.5.2-6 ii libpam0g1.5.2-6 login recommends no packages. login suggests no packages. -- no debconf information
Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15
I just tested this bug using packages from https://apt.llvm.org/ . I see that the bug reproduces with lldb-15, but doesn't reproduce with lldb-16. So let's just wait when lldb 16 enters debian, and the bug will be hopefully fixed -- Askar Safin
Bug#1032438: lldb-15: "man lldb-15" concatenated several lines to one
Package: lldb-15 Version: 1:15.0.7-1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com Consider this fragment from "man lldb-15": Passing one of the attach options causes lldb to immediately attach to the given process. lldb -p lldb -n Passing --repl starts lldb in REPL mode. lldb -r Passing --core causes lldb to debug the core file. lldb -c /path/to/core Command options can be combined with these modes and cause lldb to run the specified commands before or after events, like loading the file or crashing, in the order provided on the command line. lldb -O 'settings set stop-disassembly-count 20' -o 'run' -o 'bt' lldb -S /source/before/file -s /source/after/file lldb -K /source/be‐ fore/crash -k /source/after/crash As you can see, "lldb -p lldb -n " is wrong. Two lines should be. Same for other lines. See "lldb-15 --help" for correct text -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages lldb-15 depends on: ii libc62.36-8 ii libclang-cpp15 1:15.0.7-1 ii libedit2 3.1-20221030-2 ii libgcc-s112.2.0-14 ii liblldb-15 1:15.0.7-1 ii libllvm151:15.0.7-1 ii libncurses6 6.4-2 ii libstdc++6 12.2.0-14 ii libtinfo66.4-2 ii libxml2 2.9.14+dfsg-1.1+b3 ii llvm-15-dev 1:15.0.7-1 ii python3-lldb-15 1:15.0.7-1 ii zlib1g 1:1.2.13.dfsg-1 lldb-15 recommends no packages. lldb-15 suggests no packages. -- no debconf information
Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15
Package: lldb-15
Version: 1:15.0.7-1
Severity: normal
X-Debbugs-Cc: safinas...@gmail.com
Here are steps to reproduce (in form of Dockerfile):
FROM debian:sid
ENV LC_ALL C.UTF-8
RUN apt-get update && apt-get install -y whiptail apt-utils
RUN apt-get update && apt-get install -y clang-15 lldb-15
RUN echo 'int main(){}' > a.c
RUN clang-15 -g -o a a.c
RUN lldb-15 ./a < /dev/null
The last command prints:
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
(lldb) target create "./a"
Current executable set to '/a' (x86_64).
I see here error message "ModuleNotFoundError: No module named
'lldb.embedded_interpreter'" and
I don't like it.
I found and reported this bug back in 2016
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846531 ).
And it seems it was fixed, but now it reappeared again. I would be nice to
somehow ensure it will never
appear again (i. e. add some test).
(Note: I'm talking about "No module named 'lldb.embedded_interpreter'" bug. I
don't mean other bugs
mentioned in #846531.)
(This bug was sent from very same docker container I'm talking about.)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-0.deb9.20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
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 lldb-15 depends on:
ii libc62.36-8
ii libclang-cpp15 1:15.0.7-1
ii libedit2 3.1-20221030-2
ii libgcc-s112.2.0-14
ii liblldb-15 1:15.0.7-1
ii libllvm151:15.0.7-1
ii libncurses6 6.4-2
ii libstdc++6 12.2.0-14
ii libtinfo66.4-2
ii libxml2 2.9.14+dfsg-1.1+b3
ii llvm-15-dev 1:15.0.7-1
ii python3-lldb-15 1:15.0.7-1
ii zlib1g 1:1.2.13.dfsg-1
lldb-15 recommends no packages.
lldb-15 suggests no packages.
-- no debconf information
Bug#1023786: marked as pending in reportbug
I tested current master. Yes, the bug is fixed. On Sat, Nov 26, 2022 at 11:00 PM Nis Martensen wrote: > > Control: tag -1 pending > > Hello, > > Bug #1023786 in reportbug reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/reportbug-team/reportbug/-/commit/b97bdcbbd2382e4f3e3533b1785ef2f83a5f2f13 > > > bin/reportbug: ask CC addresses also if list-cc-me is set > > Closes: #1023786 > > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/1023786 -- Askar Safin
Bug#1024848: "Operating modes" are nearly identical
Package: reportbug Version: 11.5.1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com In the beginning "reportbug" asks "operating mode": novice, standard, advanced and expert. This is very bad question. Moreover, the answer will not matter. Here is reportbug logs when I answered "novice" and when I answered "expert": https://paste.debian.net/1261952/ , https://paste.debian.net/1261953/ . As you can see, changes are small. So, please, remove this "operating mode" question. Or at very least make 2 modes, not 4 -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "11.5.1" mode expert ui text realname "Askar Safin" email "safinas...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 reportbug depends on: ii apt2.5.4 ii python33.10.6-3 ii python3-reportbug 11.5.1 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.79 pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.41-4 pn gnupg | pgp pn python3-urwid pn reportbug-gtk pn xdg-utils Versions of packages python3-reportbug depends on: ii apt2.5.4 ii file 1:5.41-4 ii python33.10.6-3 ii python3-apt2.3.0+nmu1+b1 ii python3-debian 0.1.49 ii python3-debianbts 3.2.4 ii python3-requests 2.28.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- no debconf information
Bug#1023864: reportbug: Doesn't put cursor to correct position in emacs unless config specially edited
Package: reportbug Version: 11.5.1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com When reportbug spawns emacs editor, it doesn't put cursor to correct position. The cursor is placed in first line instead. This happens if I never edited /etc/reportbug.conf . If I uncomment line 'editor "emacs -nw"' in the config, then cursor will be placed correctly. This is exact steps to reproduce starting from fresh docker container: https://paste.debian.net/hidden/66b1f071/ You may say: "Just edit reportbug.conf". Well, when I want to report some bug I often create fresh system (for example, I start fresh docker container), then reproduce the bug in it and then report the bug from this system. I usually don't edit reportbug.conf every time. -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "11.5.1" mode advanced ui text realname "Askar Safin" email "safinas...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 reportbug depends on: ii apt2.5.4 ii python33.10.6-1 ii python3-reportbug 11.5.1 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf1.5.79 pn debsums pn dlocate ii emacs-bin-common 1:27.1+1-3.1+b1 ii exim4-daemon-light [mail-transport-agent] 4.96-8 ii file 1:5.41-4 pn gnupg | pgp pn python3-urwid pn reportbug-gtk pn xdg-utils Versions of packages python3-reportbug depends on: ii apt2.5.4 ii file 1:5.41-4 ii python33.10.6-1 ii python3-apt2.3.0+nmu1 ii python3-debian 0.1.48 ii python3-debianbts 3.2.4 ii python3-requests 2.27.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- Configuration Files: /etc/reportbug.conf changed [not included] -- no debconf information
Bug#1023786: reportbug: [Regression] [I bisected] reportbug in bullseye doesn't ask CC addresses anymore
Package: reportbug Version: 7.10.3+deb11u1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com * This is regression * I did bisect "reportbug" doesn't ask question "Enter any additional addresses this report should be sent to" in bullseye's version and buster's version. (I use 3rd operating mode, i. e. "advanced".) But "reportbug" asked this in stretch. I like this feature, I want it to be supported. I think it was deleted by accident. Here's full reproducing steps in bullseye's "reportbug", starting from fresh docker container: https://paste.debian.net/hidden/2c826222/ . If you do exactly this steps in stretch you will see a question "Enter any additional addresses this report should be sent to" in some moment. I bisected this bug and I see that it was introduced in this commit: https://salsa.debian.org/reportbug-team/reportbug/-/commit/9df3e4c7096d9cc3222359a7ec582bf40bc37186 -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "7.10.3+deb11u1" mode advanced ui text realname "Askar Safin" email "safinas...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 reportbug depends on: ii apt2.2.4 ii python33.9.2-3 ii python3-reportbug 7.10.3+deb11u1 ii sensible-utils 0.0.14 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.39-3 pn gnupg | pgp pn python3-urwid pn reportbug-gtk pn xdg-utils Versions of packages python3-reportbug depends on: ii apt2.2.4 ii file 1:5.39-3 ii python33.9.2-3 ii python3-apt2.2.1 ii python3-debian 0.1.39 ii python3-debianbts 3.1.0 ii python3-requests 2.25.1+dfsg-2 ii sensible-utils 0.0.14 python3-reportbug suggests no packages. -- no debconf information
Bug#1023735: bullseye: preseed's keyword "default" is not documented
It seems you didn't understand me. I did some more experiments and discovered that I can use word "default" everywhere when "select" or "multiselect" is expected. Here is preseed.cfg I ended up with: https://paste.debian.net/hidden/2a058f0e/ . Especially see this lines: d-i keyboard-configuration/xkb-keymap default d-i apt-setup/services-select default tasksel tasksel/first default It seems that in all these cases default option/options are selected. It is very cool! I like this feature. Is it supposed to work or does it work by accident? Please, document it. Reopening bug. > Holger -- Askar Safin
Bug#1023735: bullseye: preseed's keyword "default" is not documented
Package: debian-installer Severity: normal Tags: d-i X-Debbugs-Cc: safinas...@gmail.com I'm trying to install bullseye fully automatically using netboot with pressed.cfg embedded in initramfs. I wonder how to make taskel to install default set of packages. If I don't mention tasksel in preseed at all, then tasksel asks what packages should be installed (i. e. installation becomes non-automatic). If I write to pressed "tasksel tasksel/first seen true", then (it seems) tasksel stage is skipped (instead of installing default set of packages). I was unable to find any answer in documentation (i. e. appendix B of installation manual and https://www.debian.org/releases/bullseye/example-preseed.txt ). So I decided to try this: "tasksel tasksel/first default". Susprisiongly, it worked! So, please, document this "default" syntax. Appendix B and https://www.debian.org/releases/bullseye/example-preseed.txt say nothing about it. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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
Bug#1023733: reportbug: Please, depend on some editor
Package: reportbug Version: 7.10.3+deb11u1 Severity: normal X-Debbugs-Cc: safinas...@gmail.com I wanted to report some bug in bullseye. So, I started fresh bullseye docker container using this command: sudo docker run -it --rm -v /tmp:/tmp debian:bullseye Then, in this container I typed "apt-get update; apt-get install whiptail apt-utils" (whiptail and apt-utils are packages I usually install when I start new container) Then I typed "apt-get install bugreport". Then I proceed to answer questions. But when I reached the stage when I need to edit message, I saw this: %%%begin Please select tags: (one at a time) [done] Spawning sensible-editor... update-alternatives: error: no alternatives for editor /usr/bin/sensible-editor: 25: editor: not found /usr/bin/sensible-editor: 28: nano: not found /usr/bin/sensible-editor: 31: nano-tiny: not found /usr/bin/sensible-editor: 34: vi: not found Couldn't find an editor! Set the $EDITOR environment variable to your desired editor. Warning: possible error exit from sensible-editor: 256 No changes were made in the editor. Report will be sent to Debian Bug Tracking System Submit this report on debian-installer (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? %%%end So, "reportbug" does not depend on any editor. This is a big issue for unusual small environments, such as fresh small docker container. So, please add "Depends" dependency (or at least "Recommends" dependency) on some editor. -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "7.10.3+deb11u1" mode standard ui text realname "Askar Safin" email "safinas...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 reportbug depends on: ii apt2.2.4 ii python33.9.2-3 ii python3-reportbug 7.10.3+deb11u1 ii sensible-utils 0.0.14 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.39-3 pn gnupg | pgp pn python3-urwid pn reportbug-gtk pn xdg-utils Versions of packages python3-reportbug depends on: ii apt2.2.4 ii file 1:5.39-3 ii python33.9.2-3 ii python3-apt2.2.1 ii python3-debian 0.1.39 ii python3-debianbts 3.1.0 ii python3-requests 2.25.1+dfsg-2 ii sensible-utils 0.0.14 python3-reportbug suggests no packages. -- no debconf information
Bug#1023388: apt-cacher-ng: "wget http://d-i.debian.org/" returns "400 Bad request"
Package: apt-cacher-ng Version: 3.7.4-1+b2 Severity: normal X-Debbugs-Cc: safinas...@mail.ru Steps to reproduce: 1. Install apt-cacher-ng in its default configuration 2. Make sure d-i.debian.org is not present in wget's HSTS database by running 'rm -f "$HOME/.wget-hsts"' 3. Run "http_proxy=http://localhost:3142/ wget http://d-i.debian.org/;. You will see: %%% begin %%% root@26890f84728d:/# http_proxy=http://localhost:3142/ wget http://d-i.debian.org/ --2022-11-03 09:01:47-- http://d-i.debian.org/ Resolving localhost (localhost)... 127.0.0.1, ::1 Connecting to localhost (localhost)|127.0.0.1|:3142... connected. Proxy request sent, awaiting response... 400 Bad Request 2022-11-03 09:01:47 ERROR 400: Bad Request. %%% end %%% Here is full steps to reproduce: https://builds.sr.ht/~safinaskar/job/874839 . Click "view manifest »" to view (commented) script. -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 apt-cacher-ng depends on: ii adduser3.129 ii debconf [debconf-2.0] 1.5.79 ii dpkg 1.21.9+b1 ii libbz2-1.0 1.0.8-5+b1 ii libc-ares2 1.18.1-1+b2 ii libc6 2.35-3 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libevent-pthreads-2.1-72.1.12-stable-5+b1 ii libfuse2 2.9.9-6 ii libgcc-s1 12.2.0-7 ii liblzma5 5.2.7-0.0 ii libssl33.0.7-1 ii libstdc++6 12.2.0-7 ii libsystemd0251.6-1 ii libwrap0 7.6.q-31 ii sysvinit-utils [lsb-base] 3.05-6 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20211016 Versions of packages apt-cacher-ng suggests: pn avahi-daemon pn doc-base -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed [not included] -- debconf information: apt-cacher-ng/bindaddress: keep apt-cacher-ng/proxy: keep apt-cacher-ng/port: keep apt-cacher-ng/cachedir: keep * apt-cacher-ng/tunnelenable: false apt-cacher-ng/gentargetmode: No automated setup
Bug#1023332: debian-installer: sid's installer's initrd.img has testing (bookworm) in udebs-source and default-release
Package: debian-installer Severity: normal Tags: d-i I just downloaded this file: http://deb.debian.org/debian/dists/sid/main/installer- amd64/current/images/netboot/debian-installer/amd64/initrd.gz Its /etc/udebs-source is bookworm (this is current testing) instead of sid, but I downloaded this from sid directory. The same is true for /etc/default-release file. I think this is a bug -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#935334: closed by Lyndon Brown (Re: Re: debootstrap: man page says that --include will add package to download and extract list, but an experiment shows opposite)
control: reopen 935334 Hi, Lyndon Brown. It seems you don't understand what I mean, please, re-read bug report. First of all, note on terminology, specially on word "extracting". I will use output of "debootstrap" tool itself as source of terminology. Look here, this is output of debootstrap: https://paste.debian.net/1210574/ . As you can see, debootstrap output uses word "extracting" in one very specific sense: "extracting" means extracting using "dpkg-deb" or "ar" at very early stage of debootstrap. Other actions have different names, for example, "unpacking". So, word "extract" means "extract using dpkg-deb or ar", this is different from "unpack using dpkg --unpack". So, I will use word "extract" in this sense. Next. We know that --foreign causes early stopping of debootstrap. This stopping happens AFTER extracting stage (I use here word "extracting" in sense introduced above). Next. Man page says: "--include=alpha,beta Comma separated list of packages which will be added to download and extract lists". So, --include=aptitude should add aptitude to extract list, i. e. aptitude should be extracted at extract stage. --foreign runs extract stage, so --foreign should extract aptitude. But it doesn't. So man page (or debootstrap output or debootstrap itself) is wrong. So, we anyway have a bug either in debootstrap implementation or in terminology used in its output or in manual page. I think we should fix the latter. == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar
Bug#700633: Why this eatmydata patch still not applied to debootstrap? My USB storage devices are slow
severity -1 normal thanks Hi. Why this bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633 ) still is not fixed? I did some experiments and here are results: if I run debootstrap stage of d-i under eatmydata, then its time decreases from 755 s to 370 - 405 s. (I installed Debian to USB storage device). Please, fix this bug. Fix is simple, benefits for many users are big. (So I change severity.) I think eatmydata mode should be enabled by default in debootstrap. Both inside of d-i and outside of it. == Askar Safin https://github.com/safinaskar
Bug#935334: debootstrap: man page says that --include will add package to download and extract list, but an experiment shows opposite
Steps to reproduce: * Get fresh sid system with debootstrap installed * Run: debootstrap --include=aptitude --foreign sid /tmp/sid * Then run: ls /tmp/sid/usr/bin/aptitude I expected to see: /tmp/sid/usr/bin/aptitude I see instead: ls: cannot access '/tmp/sid/usr/bin/aptitude': No such file or directory I will state again that this bug can be fixed either by changing code, either by changing documentation. I can explain problem another way, if you still don't understand. == Askar Safin https://github.com/safinaskar
Bug#941856: Oops
Oops, s/eproxy/epoxy/. And it is already packaged
Bug#941856: xdg-desktop-portal-kde: Please enable screen casting
Package: xdg-desktop-portal-kde Version: 5.14.5-1 Severity: normal This package is build with SCREENCAST_ENABLED as false. Thus screencast functionality is currently disabled. Please, fix this. It seems this would require packaging libeproxy for debian -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages xdg-desktop-portal-kde depends on: ii libc6 2.29-2 ii libkf5coreaddons5 5.62.0-1 ii libkf5i18n5 5.62.0-1 ii libkf5notifications5 5.62.0-1 ii libkf5widgetsaddons5 5.62.0-1 ii libkf5windowsystem5 5.62.0-2 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-4 ii libqt5dbus5 5.11.3+dfsg1-4 ii libqt5gui55.11.3+dfsg1-4 ii libqt5printsupport5 5.11.3+dfsg1-4 ii libqt5widgets55.11.3+dfsg1-4 ii libstdc++69.2.1-8 xdg-desktop-portal-kde recommends no packages. xdg-desktop-portal-kde suggests no packages. -- no debconf information
Bug#935334: debootstrap: man page says that --include will add package to download and extract list, but an experiment shows opposite
Package: debootstrap Version: 1.0.115 Severity: normal It is known that debootstrap first extracts packages without writting to dpkg database using "dpkg-deb" or "ar" and then unpacks and configures packages using more high-level methods. I will refer to that low-level stage (when we extract packages using "dpkg-deb" or "ar") as extract stage. Manual page says: "--include=alpha,beta Comma separated list of packages which will be added to download and extract lists." So, it follows from manual page that --include=alpha will add a package to set of packages, which are extracted at extract stage. But experiment shows that this is not true. So, please either fix debootstrap or its manual page. Same for --exclude. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages debootstrap depends on: ii wget 1.20.3-1+b1 Versions of packages debootstrap recommends: ii arch-test 0.16-1 ii debian-archive-keyring 2019.1 ii gnupg 2.2.17-3 Versions of packages debootstrap suggests: pn squid-deb-proxy-client pn ubuntu-archive-keyring -- no debconf information
Bug#916084: bison-doc: Examples don't contain Makefiles
Package: bison-doc Version: 1:3.2.2-1 Severity: normal /usr/share/doc/bison-doc/examples doesn't contain Makefiles, READMEs and other such information, which may be of interest for user. It should contain all info, which is installed by upstream package by "make install". Relevant thread starts here: http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00015.html -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect bison-doc depends on no packages. bison-doc recommends no packages. Versions of packages bison-doc suggests: pn doc-base -- no debconf information
Bug#900533: chromium 67.0.3396.62-1: youtube video, gif's, html5, and movies no longer work
Package: chromium Version: 67.0.3396.87-1~deb9u1 Followup-For: Bug #900533 My system is Debian Stretch amd64. My sources.list is this: === deb http://mirror.yandex.ru/debian stretch main non-free contrib deb-src http://mirror.yandex.ru/debian stretch main non-free contrib deb http://security.debian.org/debian-security stretch/updates main contrib non-free deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free deb http://mirror.yandex.ru/debian stretch-updates main contrib non-free deb-src http://mirror.yandex.ru/debian stretch-updates main contrib non-free deb http://mirror.yandex.ru/debian stretch-backports main deb-src http://mirror.yandex.ru/debian stretch-backports main === The bug still exists in latest version in stable security repo 67.0.3396.87-1~deb9u1 as of today (2018-07-26 UTC+03). Steps to reproduce. Log in to https://vk.com , then go to https://vk.com/audio . You will not be able to listen any audio. There is no bug in latest version in stable repo 63.0.3239.84-1~deb9u1 as of today. So, this is clear regression, introduced by security update. That daily motion link doesn't work in stable security, too (note: daily motion is banned in Russia). https://hpr.dogphilosophy.net/test/ doesn't work, too. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii libasound2 1.1.3-5 ii libatk1.0-0 2.22.0-1 ii libavcodec57 7:3.2.11-1~deb9u1 ii libavformat577:3.2.11-1~deb9u1 ii libavutil55 7:3.2.11-1~deb9u1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libcups2 2.2.1-8+deb9u2 ii libdbus-1-3 1.10.26-0+deb9u1 ii libevent-2.0-5 2.0.21-stable-3 ii libexpat12.2.0-2+deb9u1 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libicu57 57.1-6+deb9u2 ii libjpeg62-turbo 1:1.5.1-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1.1+deb9u1 ii libopus0 1.2~alpha2-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpng16-16 1.6.28-1 ii libpulse010.0-1+deb9u1 ii libre2-3 20170101+dfsg-1 ii libsnappy1v5 1.1.3-3 ii libstdc++6 6.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libwebp6 0.5.2-1 ii libwebpdemux20.5.2-1 ii libwebpmux2 0.5.2-1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb1 1.12-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-1+deb9u1 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.29-2.1 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.3-1 ii x11-utils7.7+3+b1 ii xdg-utils1.1.1-1+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 ii libgl1-mesa-dri 13.0.6-1+b2 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell pn chromium-widevine -- no debconf information
Bug#900533: The most annoying bug ever: https://bugs.debian.org/900533 , fix it!
Recently Debian Stretch introduced the most annoying bug ever:
https://bugs.debian.org/900533 ("chromium 67.0.3396.62-1: youtube video, gif's,
html5, and movies no longer work"). It affects a very very lot of Debian users.
It renders entire system completely unusable. Because ability of viewing
videos, listening to music etc using one's favorite browser is one of the main
functions of the system.
I am unable listen music using https://vk.com/audio anymore.
Bad Chromium version was installed through stretch-security repository into
every Stretch installation.
So, please fix the bug immediately!!! And make it install to usual Stretch
installations (with stable and stable-security repos enables) in next upgrade.
This is very important, so I sent this widespread mail.
==
Askar Safin
http://vk.com/safinaskar
Bug#898486: fakeroot: Remove fakeroot and fakechroot in favour of fakeroot-ng or CLONE_NEWUSER
Package: fakeroot Version: 1.21-3.1 Severity: important Tags: upstream fakeroot and fakechroot are very unreliable. Just look at other bug reports. Even simple "env -i" (such commands are likely in building utils) unexpectedly turn off fakeroot. Other thing incompatible with fakeroot is static linking. Calls to "ldconfig" are usual in building tools. Other utils have to introduce kludges to deal with fakeroot unreliability. For example, debootstrap includes its own ldconfig replacement for fakeroot mode. Okey, what to do? I propose to replace fakeroot with fakeroot-ng or user namespaces (CLONE_NEWUSER). fakeroot-ng is based on ptrace, as opposed to fakeroot. So, it is more reliable. But I'm not sure whether its perfect. For example, I don't know whether fakeroot-ng is compatible with SETUID binaries. CLONE_NEWUSER (user namespaces) and tools based on it (recent systemd-nspawn, lxc, etc) are better. I think user namespaces are more reliable and faster than fakeroot-ng. But user namespaces seem to be less secure. So, please remove fakeroot and fakechroot. Remove package "pseudo", too, because it uses LD_PRELOAD (like fakeroot), and thus it shares same problems. If you decide user namespaces are better than fakeroot-ng, then remove fakeroot-ng, too. Okey, so, please remove fakeroot, fakechroot, pseudo (and possibly fakeroot-ng) from Debian archive. Change all packages which use them to use fakeroot-ng or user namespaces. Stop using this obsolete packages in your infrastructure, i. e. don't build packages using fakeroot. Remove all kludges you introduced to work with fakeroot, such as special debootstrap variant. What about non-Linux kernels supported by Debian, i. e. Hurd and kFreeBSD? I think Hurd has some feature similar to user namespaces (subhurd or something like that). Moreover, they are theoretically more secure than Linux user namespaces due to microkernel architecture. And moreover, ability to simulate root without such hacky tools always was selling point of Hurd. kFreeBSD? Well, nobody wants it anyway. :) User namespaces are supported by default in Stretch's Linux kernel. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fakeroot depends on: ii libc62.24-11+deb9u3 ii libfakeroot 1.21-3.1 fakeroot recommends no packages. fakeroot suggests no packages. -- no debconf information
Bug#889079: debian-live: In installed system keyboard almost doesn't work in taskbar if Russian layout is added and Live is used for installing
Package: debian-live Severity: important THIS BUG FORCED me to reinstall my system!!! I got Debian Live Stretch KDE using this link: https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-9.3.0-amd64-kde+nonfree.iso MD5 sum starts so: 11c5365e... I downloaded this image very recently (today is 2018-02-01 using my local time). I installed it to fresh qemu virtual machine. Language: English, location: Russian Federation, locale: en_US.UTF-8. Tasksel DID NOT run. It seems d-i did COPYING of system and not CREATING new system using debootstrap. Then I did boot into installed system (Stretch KDE). Then I opened keyboard layout configuration and added Russian layout. Then I configured "Switching Policy" to "Application". Then I opened "Advanced" tab and configured switching layouts using "Right Alt (while pressed)". Then I did reboot (this virtual machine). Then I opened application launcher, clicked "Type to search..." and attempted to type something. But most letters didn't appear. I. e. most of my keypresses was ignored. Same happens with everything which comes from taskbar, for example I cannot type Wi-Fi password in taskbar network manager widget. This bug report is sent from this virtual machine. Also I created another virtual machine. I got Debian Installer Stretch DVD (not Live!) using this link: https://mirror.yandex.ru/debian-cd/current/amd64/iso-dvd/debian-9.3.0-amd64-DVD-1.iso MD5 sum starts so: f49c3d1a... I downloaded this image very recently (today is 2018-02-01 using my local time). I installed it to fresh qemu virtual machine. Language: English, location: Russian Federation, locale: en_US.UTF-8. Tasksel DID run. And I tell tasksel that I want KDE desktop environment. It seems d-i did CREATING new system using debootstrap and not COPYING. Then I did boot into installed system (stretch KDE). Then I configured keyboard layout the same as in that Live system. Then I did reboot. And then that keyboard bug didn't appear, so, it seems that this bug is Live-specific. Also I installed debian using that live image to my physical computer (laptop Dell Inspiron 15) and got the bug. I mark this bug as important, because it makes installed system, well, "poisoned". And I don't know to fix such installed system, so I see only way to fix problem: reinstall the system (using non-Live installer). So, this bug causes your users to reinstall the system. I would make the following suggestion on how to fix the bug: I recommend ALWAYS perform installing using normal debootstrap. I. e. your Live installer should install system exactly same way as normal d-i does this. Because today Live installer is not tested well. And who knows how many bugs it has? -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-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: systemd (via /run/systemd/system)
Bug#883579: unzip: Acts very strangely with options after "--"
Package: unzip Version: 6.0-21 Severity: normal There are two kinds of shell utils. Some understand "--" and threat all arguments after it as non-options (this utils are good). Some don't understand "--" and try to threat it as normal option or as normal operand (this utils are bad, but they exist). "unzip" is neither. It accepts "--" and start to ignore (!) all options it find after "--". Instead of, say, threating them as normal operands, i. e. file names. Such behavior is very strange and should be fixed. Example: $ unzip -- -v /tmp/a.zip Archive: /tmp/a.zip [/tmp/a.zip] txt.txt password: extracting: txt.txt As you can see, "-v" is simply ignored. "unzip" didn't process it as file, nor as option. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages unzip depends on: ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-11+deb9u1 unzip recommends no packages. Versions of packages unzip suggests: ii zip 3.0-11+b1 -- no debconf information
Bug#514015: mkdir && tar && cp/mv
Also, I have this idea: let's create empty dir and untar into it. Then copy or move content of this dir into target using "cp" or "mv" with specially picked set of options. And I still think that debootstrap and cdebootstrap should check whether target is empty as a safety measure in any case. Also, I thought bug I reported still applies to modern hosts. If you have modern host (say, stretch) and perform double debootstrap (one squeeze and one wheezy) into same dir, this (as I thought) will write to host's /lib/ld-linux-x86-64.so.2 . Fortunately, this will not cause any bad consequences. But now I performed tests. I used stretch host, stretch's debootstrap 1.0.89 and stretch's cdebootstrap 0.7.7+b1. And I see no bug. When that libc6 extracts during second (c)debootstrap, symlink /tmp/target/lib64 is replaced with regular dir /tmp/target/lib64 and then (c)debootstrap writes to this dir. So, there is no (even harmless) leak to host. Maybe tar changed? So, it seems that the bug #514015/#514016 is fixed. But I am not sure, it is possible that my observation is due to special structure of Debian packages. What if some malformed untrusted Debian packages may still cause leaked files? == Askar Safin http://vk.com/safinaskar
Bug#514015: FreeBSD tar
Also, FreeBSD's tar has option "--chroot". And (if I remember correctly) it is used in installation process. (Also, please see my previous letter in this bug report if you missed it.) == Askar Safin http://vk.com/safinaskar
Bug#514015: Example of ruined host
This bug can ruin the host! Steps to reproduce. * Host should be squeeze amd64. I used absolutely fresh squeeze with few packages. It have normal squeeze's debootstrap 1.0.26+squeeze1 * Run in it: # debootstrap --variant=minbase squeeze /tmp/target http://archive.debian.org/debian # debootstrap --variant=minbase wheezy /tmp/target http://deb.debian.org/debian * The first debootstrap was OK, the second debootstrap stopped after this: === I: Extracting debianutils... I: Extracting diffutils... I: Extracting dpkg... I: Extracting e2fslibs... I: Extracting e2fsprogs... I: Extracting libcomerr2... I: Extracting libss2... I: Extracting libc-bin... I: Extracting libc6... === * After this point nearly any command doesn't work AT HOST!!! After this point the dynamic linker is not available. For example, /bin/true gives this: "bash: /bin/true: No such file or directory". "ldconfig" as root fixes the situation. But this quiet possible the user simply would not guess he should type "ldconfig". Moreover, I think if he has no already opened root shell, he cannot open it (I think "sudo" will not work and I think attempting to log in in /dev/tty1 will not work, too). So, this is quiet possible the user will simply power off the computer. And then (I think) he will unable to boot the computer anymore. Yes, this is still possible to restore the computer (I think something like "linux /vmlinuz rw init=/sbin/ldconfig" from GRUB), but this is possible the user will not guess the right command. So he will simply reinstall OS. So, this is absolutely critical bug, which can force average user to reinstalling OS. Moreover, in the time while the dynamic linker is missing, other running programs may experience data loss. So, this is critical data-loss bug! You may say that this has little probability that someone will run debootstrap two times in same dir with different debian releases. Yes, this has little probability. But I run into this problem once. And this is not important to speak about probabilities when the consequences are such bad (I mean OS reinstalling). The same bug is reproducible with squeeze's cdebootstrap (i. e. 0.5.7). The same bug is reproducible with squeeze's dpkg-deb (dpkg 1.15.11). Okey, how I run into this problem? Well, in fact I was developing my own debootstrap replacement. And I occasionally did run it in one directory two times. Then all commands stopped to work. Fortunately I had root shell opened and fortunately I was smart enough to type "ldconfig" into it. Then I checked that same problem applies not only my program, but also to original debootstrap. Okey, how to reproduce with without risk of crashing your host? Well, let's assume you has host A with any OS. Create chroot environment B with squeeze using debootstrap. Then chroot into it, create dir C and run debootstrap two times on it as I described above. This will crash B, but not A. It seems the bug is not reproducible when host is something newer than squeeze. So, I did not open separate bug report and posted my problem here. But the root cause of the issue is bugs #514015 / #514016, so these bugs (#514015 / #514016) should be fixed. It is possible that #514015 / #514016 for some reason will cause some another critical "reinstall this OS" bug. One possible fix for my problem: check (in both debootstrap and cdebootstrap) that target is empty or non-existent. Now some more info about my bug. This is part of file hierarchy after first debootstrap: /lib /lib/ld-2.11.3.so /lib/ld-linux-x86-64.so.2 -> ld-2.11.3.so /lib64 -> /lib /tmp/target/lib /tmp/target/lib/ld-2.11.3.so /tmp/target/lib/ld-linux-x86-64.so.2 -> ld-2.11.3.so /tmp/target/lib64 -> /lib This is contents of libc6_2.13-38+deb7u10_amd64.deb from wheezy (it will be extracted during second debootstrap): /lib /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.11.3.so /lib/x86_64-linux-gnu/ld-2.13.so /lib64 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.13.so Now second debootstrap extracts libc6_2.13-38+deb7u10_amd64.deb into /tmp/target. Debootstrap tries to put package's "/lib64/ld-linux-x86-64.so.2" into system's "/tmp/target/lib64/ld-linux-x86-64.so.2", but "/tmp/target/lib64" is symlink to /lib, so debootstrap writes to host's /lib64/ld-linux-x86-64.so.2 . So, now host's /lib64/ld-linux-x86-64.so.2 is symlink and it points to file /lib/x86_64-linux-gnu/ld-2.13.so , which is non-existent on host. So, now host's dynamic linker name ( /lib64/ld-linux-x86-64.so.2 , hardcoded into nearly all dynamic binaries) is symlink to non-exist file. == Askar Safin http://vk.com/safinaskar
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Same for buster. I. e. if I replace sid virtual machine with buster virtual machine, I got the same bug. I mean that I created buster from the same alpha 1 installer, but this time I didn't upgrade it to sid. == Askar Safin http://vk.com/safinaskar
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Package: src:linux Version: 4.13.10-1 Severity: important Current (2017-11-14 - 2017-11-15) sid with up-to-date kernel (4.13.0) cannot "chroot" into squeeze chroot environment. What I did? * I started qemu-system-x86_64 (debian package qemu-system-x86 1:2.8+dfsg-6+deb9u3) from my host system (debian stretch amd64) * 2017-11-14 I downloaded current buster installer from here: http://cdimage.debian.org/cdimage/buster_di_alpha1/amd64/iso-cd/debian-buster-DI-alpha1-amd64-netinst.iso * I installed it to the qemu virtual machine * I upgraded it to current sid (2017-11-14 - 2017-11-15) * I created (in this qemu virtual machine, of course) squeeze chroot environment using command (I use debootstrap 1.0.92): # debootstrap --variant=minbase --no-check-gpg squeeze /tmp/target http://archive.debian.org/debian * It failed: W: Failure trying to run: chroot /tmp/target dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb W: See /tmp/target/debootstrap/debootstrap.log for details * /tmp/target/debootstrap/debootstrap.log is here: warning, in file '/var/lib/dpkg/status' near line 4 package 'dpkg': missing description Segmentation fault * Then I tried to run "chroot /tmp/target /bin/bash" and got "Segmentation fault" So, it seems current sid simply cannot run squeeze chroot environment: it gots segmentation fault when triyng to run /bin/bash . * Then I removed /tmp/target and created it again using command: # debootstrap --variant=minbase --no-check-gpg --foreign squeeze /tmp/target http://archive.debian.org/debian * Now the command worked well. But then I tried "chroot /tmp/target /bin/bash" and got "Segmentation fault" again * Then I copied that /tmp/target to outside of my qemu virtual machine and run it on my host. My host is debian stretch with kernel linux-image-4.9.0-4-amd64 4.9.51-1. And /bin/bash worked successfully. So, squeeze chroot environment doesn't work on sid with kernel 4.13.0, but works with stretch with kernel 4.9.0 * Then I run my host OS in qemu using well known "qemu -snapshot /dev/sda" trick. And then I did run "chroot /tmp/target /bin/bash" in this qemu instance. /bin/bash worked well again. So, it seems qemu doesn't influence bug reproducebility. I. e. it seems the problem is not qemu-related. So, I am pretty sure problem is not in debootstrap. I also think the problem is not in qemu (I already wrote why I did so). I think problem is this: modern kernel cannot run old squeeze chroot environment. So I fill this bug to "linux-image" package. I think this is very important bug, so I give it "important" priority. Linux kernel is very conservative when we speak about API and ABI. Modern debian releases typically can run very old chroot environments. I can successfully create debian hamm chroot environment on my stretch host using my own script. Yes, hamm!!! Which is released 1998-07-24!!! And I can successfully run /bin/bash from it. So, debian (until recently) successfully did run very old chroot environments. And now you broke this tradition, this is very bad. This bug report is sent from mentioned sid qemu virtual machine. -- Package-specific info: ** Version: Linux version 4.13.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.4.0 20171026 (Debian 6.4.0-9)) #1 SMP Debian 4.13.10-1 (2017-10-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=8e27eccf-cc87-4c57-8bb6-7d3da96097e3 ro quiet ** Not tainted ** Kernel log: [0.606044] Write protecting the kernel read-only data: 12288k [0.606615] Freeing unused kernel memory: 1592K [0.608452] Freeing unused kernel memory: 1128K [0.609313] x86/mm: Checked W+X mappings: passed, no W+X pages found. [0.657316] SCSI subsystem initialized [0.658541] piix4_smbus :00:01.3: SMBus Host Controller at 0x700, revision 0 [0.659811] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [0.659811] e1000: Copyright (c) 1999-2006 Intel Corporation. [0.668058] libata version 3.00 loaded. [0.671377] Floppy drive(s): fd0 is 2.88M AMI BIOS [0.674626] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 [0.674745] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 [0.690794] FDC 0 is a S82078B [0.698539] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [1.025342] e1000 :00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56 [1.025348] e1000 :00:03.0 eth0: Intel(R) PRO/1000 Network Connection [1.025367] ata_piix :00:01.1: version 2.13 [1.026725] e1000 :00:03.0 ens3: renamed from eth0 [1.027495] scsi host0: ata_piix [1.027584] scsi host1: ata_piix [1.027608] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14 [1.027609] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc048 irq 15 [1.184305] ata1.01: NODEV after polling detection [1.184501] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [
Bug#872845: base-files: Public SCM seem to be not available
Package: base-files Version: 9.9+deb9u1 Severity: normal It seems public SCM for base-files is not available. When I type "apt-get source base-files" I don't see something like "'base-files' packaging is maintained in the ... version control system". Please provide some public SCM. For example, I may want to do "git bisect" to determine when some config change appeared in base-files. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages base-files depends on: ii gawk [awk] 1:4.1.4+dfsg-1 ii mawk [awk] 1.3.3-17+b3 base-files recommends no packages. base-files suggests no packages. -- no debconf information
Bug#867895: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#867895: fixed in e2fsprogs 1.43.5-1)
Thanks, but https://www.kernel.org/doc/Documentation/filesystems/ext4.txt seems still to contain bug. If you want, I will send separate bug report to kernel bugzilla
Bug#870675: apt: Strangely hangs without any meaningful error message if apt-transport-https is not installed
Package: apt Version: 1.4.7 Severity: normal I just wrote this to sources.list: deb https://deb.debian.org/debian stretch main deb https://deb.debian.org/debian-security stretch/updates main And then I run "apt-get update". I saw: # apt-get update 0% [Working] I waited, and waited and waited. And then I suddenly understand that the package apt-transport-https is missing. So, if sources.list contains some schema which has no corresponding apt-transport-* package installed, then meaningful error message should be printed instead of just hanging. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "false"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "false"; APT::Compressor::xz::Cost "200"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "false"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "false"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--suffix="; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--suffix="; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::mirrors "mirrors/"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences
Bug#870317: dash: "type" doesn't threat "--" specially (POSIX compliance issue)
Package: dash Version: 0.5.8-2.4 Severity: normal Tags: upstream dash$ type -- ls --: not found ls is /bin/ls "type" doesn't threat "--" specially. But POSIX 2016 edition says it should. Also, all your builtins mentioned in POSIX (be it "special built-in utility" or normal utility) should threat "--" specially. Unless it is in this list: --begin of list-- break : continue . eval exec exit return shift times echo test [ --end of list-- -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dash depends on: ii debianutils 4.8.1.1 ii dpkg 1.18.24 ii libc62.24-11+deb9u1 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
Bug#870270: bash: Manual bug: says "test" doesn't accept "--", but doesn't say anything about "["
Package: bash
Version: 4.4-5
Severity: normal
Tags: upstream
https://www.gnu.org/software/bash/manual/bash.html says this: "Unless otherwise
noted, each builtin command documented as accepting options preceded by ‘-’
accepts ‘--’ to signify the end of the options. The :, true, false, and test
builtins do not accept options and do not treat ‘--’ specially".
So, docs list not only "true", but also its short form ":". Also, it list
"test", but don't list its short form "[". "[" seems not to accept "--" on my
version of bash, i. e. [ -f -- /etc/fstab ] fails. So, please, add "[" to
mentioned list.
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bash depends on:
ii base-files 9.9
ii dash 0.5.8-2.4
ii debianutils 4.8.1.1
ii libc62.24-11+deb9u1
ii libtinfo56.0+20161126-1
Versions of packages bash recommends:
ii bash-completion 1:2.1-4.3
Versions of packages bash suggests:
pn bash-doc
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
if [ -x /usr/lib/command-not-found -o -x
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
if ! shopt -oq posix; then #my-config#
if [ -f /usr/share/bash-completion/bash_completion ]; then #my-config#
. /usr/share/bash-completion/bash_completion #my-config#
elif [ -f /etc/bash_completion ]; then #my-config#
. /etc/bash_completion #my-config#
fi #my-config#
fi #my-config#
/etc/skel/.bash_logout [Errno 2] No such file or directory:
'/etc/skel/.bash_logout'
/etc/skel/.bashrc changed:
case $- in
*i*) ;;
*) return;;
esac
HISTCONTROL=ignoreboth
shopt -s histappend
HISTSIZE=1000
HISTFILESIZE=2000
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval
"$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
-- no debconf information
Bug#870096: bash: <(printf '%s' $'\177ELF')
Package: bash
Version: 4.4-5
Severity: normal
Tags: upstream
Type this to bash:
cat <(printf '%s' $'\177ELF') > file-1
and this:
printf '%s' $'\177ELF' > file-2
Resulting files will be different. file-1 will contain 5 bytes (as opposed to
expected 4)
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bash depends on:
ii base-files 9.9
ii dash 0.5.8-2.4
ii debianutils 4.8.1.1
ii libc62.24-11+deb9u1
ii libtinfo56.0+20161126-1
Versions of packages bash recommends:
ii bash-completion 1:2.1-4.3
Versions of packages bash suggests:
pn bash-doc
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
if [ -x /usr/lib/command-not-found -o -x
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
if ! shopt -oq posix; then #my-config#
if [ -f /usr/share/bash-completion/bash_completion ]; then #my-config#
. /usr/share/bash-completion/bash_completion #my-config#
elif [ -f /etc/bash_completion ]; then #my-config#
. /etc/bash_completion #my-config#
fi #my-config#
fi #my-config#
/etc/skel/.bash_logout [Errno 2] No such file or directory:
'/etc/skel/.bash_logout'
/etc/skel/.bashrc changed:
case $- in
*i*) ;;
*) return;;
esac
HISTCONTROL=ignoreboth
shopt -s histappend
HISTSIZE=1000
HISTFILESIZE=2000
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval
"$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
-- no debconf information
Bug#869206: dash: man dash doesn't describe "false" and other builtins
Package: dash Version: 0.5.8-2.4 Severity: normal man dash describe dash builtins wrong. In particular it doesn't describe "false". Please, double-check that man's builtin list correspond to actual. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dash depends on: ii debianutils 4.8.1.1 ii dpkg 1.18.24 ii libc62.24-11+deb9u1 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
Bug#867895: Re[2]: Bug#867895: e2fsprogs: man ext4: it seems you document "commit" option for ext4 wrong
Documentation/filesystems/ext4.txt contains this: commit=nrsec(*) Ext4 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your filesystem will not be damaged though, thanks to the journaling) It seems this is wrong, please, fix it.
Bug#867895: e2fsprogs: man ext4: it seems you document "commit" option for ext4 wrong
It seems https://www.kernel.org/doc/Documentation/filesystems/ext4.txt has the same issue?!
Bug#867895: e2fsprogs: man ext4: it seems you document "commit" option for ext4 wrong
Package: e2fsprogs Version: 1.43.4-2 Severity: normal Tags: upstream Hi. Currently "commit" for ext3 documented so: .BI commit= nrsec Sync all data and metadata every .I nrsec seconds. The default value is 5 seconds. Zero means default. And in the beginning of ext4: The options .B journal_dev, norecovery, noload, data, commit, orlov, oldalloc, [no]user_xattr .B [no]acl, bsddf, minixdf, debug, errors, data_err, grpid, bsdgroups, nogrpid .B sysvgroups, resgid, resuid, sb, quota, noquota, grpquota, usrquota .B usrjquota, grpjquota and jqfmt are backwardly compatible with ext3 or ext2. So, it seems from man that ext4 has same "commit" option and its default value is 5 seconds (even if I don't specify "commit" at command line at all). But it seems that this is wrong ( https://lwn.net/Articles/322823/ ). So, please, fix the man. I tried to fill the bug report to util-linux ( https://github.com/karelzak/util-linux/issues/479 ), but they removed description of ext* from their manual and said that ext* description will be in e2fsprogs manual only. But e2fsprogs seems to want bugs filled to downstream distros ( https://sourceforge.net/p/e2fsprogs/discussion/7053/thread/2caf9bc1/?limit=25 ), so I am posting here. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages e2fsprogs depends on: ii e2fslibs1.43.4-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcomerr2 1.43.4-2 ii libss2 1.43.4-2 ii libuuid12.29.2-1 ii util-linux 2.29.2-1 e2fsprogs recommends no packages. Versions of packages e2fsprogs suggests: pn e2fsck-static pn fuse2fs pn gpart ii parted 3.2-17 -- no debconf information
Bug#846616: Re[2]: Bug#846616: Subj
>For 4.0, it is in NEW: >https://ftp-master.debian.org/new/llvm-toolchain-snapshot_1:4.0~svn291432-1.html Where can I download it? And why it is still not in sid? Why you just uploaded fix to lldb-3.9 and it fastly went to sid and I still cannot download this lldb-4.0? == Askar Safin http://vk.com/safinaskar
Bug#851182: Subj
Same for this more complicated example:
#include
std::string
f (void)
{
printf ("a\n");
return "";
}
int
main (void)
{
printf ("%s\n", f ().c_str ());
}
==
Askar Safin
http://vk.com/safinaskar
Bug#851182: gdb is broken in current sid: "std::string f (void)" doesn't work
Package: gdb
Version: 7.12-4
Severity: grave
Justification: renders package unusable
Steps to reproduce:
* Create this file /h.cpp:
#include
std::string
f (void)
{
return "";
}
int
main (void)
{
f ();
}
* Then:
root@ideal-os:/# g++ -g -o h h.cpp
root@ideal-os:/# gdb ./h
GNU gdb (Debian 7.12-4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Bug#846612: Re[2]: Bug#846612: Subj
reassign 846612 lldb-3.8 1:3.8.1-16 fixed 846612 1:3.8.1-17 thanks Okey, I created separate bug. (But it seems it can be solved just by adding that python-lldb-xx dependency.) == Askar Safin http://vk.com/safinaskar
Bug#851171: "ImportError: No module named lldb.embedded_interpreter" when typing "p a"
Package: lldb-3.9
Version: 1:3.9.1-2
Severity: normal
Steps to reproduce:
* Create fresh minimal debian sid
* Create apt.conf with APT::Install-Recommends "false";
* Install lldb-3.9 and clang-3.9
* Then:
root@ideal-os:/# cat o.cpp
#include
int
main (void)
{
std::vector a;
a.push_back (0);
}
root@ideal-os:/# clang++-3.9 -g -o o o.cpp
root@ideal-os:/# lldb-3.9 ./o
(lldb) target create "./o"
Current executable set to './o' (x86_64).
(lldb) b main
Breakpoint 1: where = o`main + 12 at //o.cpp:6, address = 0x0040091c
(lldb) r
Process 527 launched: './o' (x86_64)
Process 527 stopped
* thread #1: tid = 527, 0x0040091c o`main + 12 at //o.cpp:6, name =
'o', stop reason = breakpoint 1.1
frame #0: 0x0040091c o`main + 12 at //o.cpp:6
3int
4main (void)
5{
-> 6 std::vector a;
7 a.push_back (0);
8}
(lldb) n
Process 527 stopped
* thread #1: tid = 527, 0x00400928 o`main + 24 at //o.cpp:7, name =
'o', stop reason = step over
frame #0: 0x00400928 o`main + 24 at //o.cpp:7
4main (void)
5{
6 std::vector a;
-> 7 a.push_back (0);
8}
(lldb)
Process 527 stopped
* thread #1: tid = 527, 0x00400945 o`main + 53 at //o.cpp:8, name =
'o', stop reason = step over
frame #0: 0x00400945 o`main + 53 at //o.cpp:8
5{
6 std::vector a;
7 a.push_back (0);
-> 8}
(lldb) p a
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
(std::vector) $0 = size=1 {
std::_Vector_base = {
_M_impl = {
_M_start = 0x00615c20
_M_finish = 0x00615c24
_M_end_of_storage = 0x00615c24
}
}
}
(lldb)
If I install python-lldb-3.9, it works. :)
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
Versions of packages lldb-3.9 depends on:
ii libc6 2.24-8
ii libgcc1 1:6.3.0-2
ii liblldb-3.9 1:3.9.1-2
ii libllvm3.91:3.9.1-2
ii libncurses5 6.0+20161126-1
ii libpython2.7 2.7.13-1
ii libstdc++66.3.0-2
ii libtinfo5 6.0+20161126-1
ii llvm-3.9-dev 1:3.9.1-2
lldb-3.9 recommends no packages.
Versions of packages lldb-3.9 suggests:
pn python-lldb-3.9
-- no debconf information
Bug#846612: Subj
reassign 846612 lldb-3.9 1:3.9.1-2
thanks
The bug is still present in sid in lldb-3.9 1:3.9.1-2 and possibly in lldb-4.0.
Steps to reproduce in lldb-3.9:
root@ideal-os:/# cat o.cpp
#include
int
main (void)
{
std::vector a;
a.push_back (0);
}
root@ideal-os:/# clang++-3.9 -g -o o o.cpp
root@ideal-os:/# lldb-3.9 ./o
(lldb) target create "./o"
Current executable set to './o' (x86_64).
(lldb) b main
Breakpoint 1: where = o`main + 12 at //o.cpp:6, address = 0x0040091c
(lldb) r
Process 527 launched: './o' (x86_64)
Process 527 stopped
* thread #1: tid = 527, 0x0040091c o`main + 12 at //o.cpp:6, name =
'o', stop reason = breakpoint 1.1
frame #0: 0x0040091c o`main + 12 at //o.cpp:6
3int
4main (void)
5{
-> 6 std::vector a;
7 a.push_back (0);
8}
(lldb) n
Process 527 stopped
* thread #1: tid = 527, 0x00400928 o`main + 24 at //o.cpp:7, name =
'o', stop reason = step over
frame #0: 0x00400928 o`main + 24 at //o.cpp:7
4main (void)
5{
6 std::vector a;
-> 7 a.push_back (0);
8}
(lldb)
Process 527 stopped
* thread #1: tid = 527, 0x00400945 o`main + 53 at //o.cpp:8, name =
'o', stop reason = step over
frame #0: 0x00400945 o`main + 53 at //o.cpp:8
5{
6 std::vector a;
7 a.push_back (0);
-> 8}
(lldb) p a
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "", line 1, in
NameError: name 'run_one_line' is not defined
(std::vector<int, std::allocator >) $0 = size=1 {
std::_Vector_base<int, std::allocator > = {
_M_impl = {
_M_start = 0x00615c20
_M_finish = 0x00615c24
_M_end_of_storage = 0x00615c24
}
}
}
(lldb)
==
Askar Safin
http://vk.com/safinaskar
Bug#846616: Subj
reassign 846616 lldb-3.7 1:3.7.1-3 thanks Thanks for fixing. The bug is still present in lldb-3.7 1:3.7.1-3 and in lldb-4.0 1:4.0~svn290810-1 in sid == Askar Safin http://vk.com/safinaskar
Bug#848162: (no subject)
Moreover, this is regression. Jessie's konsole works well. Moreover, described behavior contradicts to konsole's documentation. I have konsole 4:16.08.2-2 . "konsole --help" says: -eCommand to execute. This option will catch all following arguments, so use it as the last option. And still my version of konsole has this bug. == Askar Safin
Bug#848348: tar: shows strange error message if there is no space left on device
Package: tar Version: 1.29b-1.1 Severity: normal I wanted to create archive. I typed: $ sudo tar --one-file-system --same-owner --numeric-owner -cpf /tmp/x.tar . And I saw: tar: /tmp/x.tar: Wrote only 8192 of 10240 bytes tar: Error is not recoverable: exiting now Then I discovered that tar filled all space on destination file system. So, error message is misleading. tar should say: no space left on device. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages tar depends on: ii libacl1 2.2.52-3 ii libc62.24-7 ii libselinux1 2.6-3 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.6-8 pn ncompress pn tar-scripts ii xz-utils 5.2.2-1.2 -- no debconf information
Bug#847993: tar: man describes "--preserve" option, but tar doesn't support it
Package: tar Version: 1.29b-1.1 Severity: normal "man tar" says: --preserve Same as both -p and -s. But "tar" itself doesn't support this option: $ tar --preserve -cf /tmp/a.tar /etc/fstab tar: option '--preserve' is ambiguous; possibilities: '--preserve-permissions' '--preserve-order' Try 'tar --help' or 'tar --usage' for more information. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages tar depends on: ii libacl1 2.2.52-3 ii libc62.24-7 ii libselinux1 2.6-3 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.6-8 pn ncompress pn tar-scripts ii xz-utils 5.2.2-1.2 -- no debconf information
Bug#846640: lldb-3.8: lldb freezes after "run"
Package: lldb-3.8 Version: 1:3.8.1-16 Severity: grave Justification: renders package unusable lldb 3.8 freezes after "run". Same for lldb 3.9 in stretch. Details: http://bugs.debian.org/846531
Bug#846638: lldb-3.8: error: process launch failed: unable to locate lldb-server
Package: lldb-3.8 Version: 1:3.8.1-16 Severity: important (lldb) r error: process launch failed: unable to locate lldb-server Details: http://bugs.debian.org/846531. Same for lldb 3.9 and maybe lldb 3.7.
Bug#846612: lldb-3.8: ImportError: No module named lldb.embedded_interpreter
Package: lldb-3.8 Version: 1:3.8.1-16 Severity: normal debian:~# lldb-3.8 ./a Traceback (most recent call last): File "", line 1, in ImportError: No module named lldb.embedded_interpreter (lldb) target create "./a" Current executable set to './a' (x86_64). (lldb) See http://bugs.debian.org/846531 for details.
Bug#846531: Re[2]: Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch
>Please report a bug per issue. It is too hard to track otherwise. Is this okey if I create several bugs which differ in title and all point to this bug? == Askar Safin http://vk.com/safinaskar
Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch
Package: lldb-3.8
Version: 1:3.8.1-16
Severity: grave
Justification: renders package unusable
lldb 3.8 is unusable is Stretch. Here is list of bugs. Most of them apply to
lldb 3.9, too. Some of them apply
to lldb 3.7, too, but lldb 3.7 is somewhat usable unlike lldb 3.8 and lldb 3.9.
Steps to reproduce. I installed fresh Debian Stretch amd64 to Qemu/KVM virtual
machine (for clean experiment)
using Debian Stretch alpha 8 installer
(
http://cdimage.debian.org/cdimage/stretch_di_alpha8/amd64/iso-cd/debian-stretch-DI-alpha8-amd64-netinst.iso
).
During installation I cleared checkbox "Install standard system utilities" to
catch lldb dependency errors.
After installation I put 'APT::Install-Recommends "false";' to apt.conf for the
same reason.
Then I performed some misc. configuration and installed some misc. packages
(for example, openssh-server to
connect to this VM from outside).
Then:
debian:~# apt-get install clang-3.8 lldb-3.8
debian:~# echo 'int main (void) {}' > a.cpp
debian:~# clang-3.8 -g -o a a.cpp # See below on clang-3.8 and clang++-3.8
debian:~# lldb-3.8 ./a
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
(lldb)
Problem 1. "ImportError: No module named lldb.embedded_interpreter".
Then I pressed "r". "\U+96272" appeared instead. This happened in ssh session
from host in X terminal (KDE's
konsole), TERM is xterm. Same is happenning on linux console in VM (TERM is
linux).
Problem 2. "\U+96272".
Then:
debian:~# cat | lldb-3.8 ./a
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
r
(lldb) r
error: process launch failed: unable to locate lldb-server
Problem 3. "error: process launch failed: unable to locate lldb-server".
Then:
debian:~# ln -s lldb-server-3.8 /usr/bin/lldb-server
debian:~# cat | lldb-3.8 ./a
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
r
(lldb) r
^C
^\Quit
debian:~#
And now lldb freezed.
Problem 4. lldb freezes.
And now I don't know what to do and how to fix this. It seems
http://lists.llvm.org/pipermail/lldb-dev/2016-March/009925.html is related.
Then:
debian:~# apt-get install python-lldb-3.8
This fixed that "lldb.embedded_interpreter" problem, but lldb still freezes.
Full log is here: http://paste.debian.net/900115/
Additional notes:
* This bug report is sent from that VM using "bugreport".
* lldb 3.9 has the same bugs except that "lldb.embedded_interpreter" bug.
* lldb 3.7 has some of this bugs, but it is usable. It doesn't freeze, so I
actually was able
to debug that C++ one-liner (but terminal support is still broken).
* At first I compiled the program so: "clang-3.8 -g -o a a.cpp" and reproduced
all this bugs.
Then I compiled it so: "clang++-3.8 -g -o a a.cpp" and reproduced all this bugs
again.
So:
* Fix this bugs in lldb 3.7, lldb 3.8 and lldb 3.9 before Stretch release. Or
just remove this packages from Scretch.
* Test that they work out-of-the-box. Even if the system doesn't have "standard
system utilities" and apt configured
not to install recommended packages.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lldb-3.8 depends on:
ii libc6 2.24-7
ii libedit2 3.1-20160903-2
ii libffi6 3.2.1-6
ii libgcc1 1:6.2.0-13
ii liblldb-3.8 1:3.8.1-16
ii libllvm3.81:3.8.1-16
ii libncurses5 6.0+20160917-1
ii libpython2.7 2.7.12-7
ii libstdc++66.2.0-13
ii libtinfo5 6.0+20160917-1
ii llvm-3.8-dev 1:3.8.1-16
ii zlib1g1:1.2.8.dfsg-2+b3
lldb-3.8 recommends no packages.
Versions of packages lldb-3.8 suggests:
ii python-lldb-3.8 1:3.8.1-16
-- no debconf information
Bug#435069: http method doesn't cleanly handle out-of-space errors
Package: apt Version: 1.0.9.8.3 Followup-For: Bug #435069 The bug still exists in my version of apt. If there is no space on device, apt-get update prints: Ign http://192.168.1.64:3142 jessie InRelease Hit http://192.168.1.64:3142 jessie Release.gpg Hit http://192.168.1.64:3142 jessie Release Hit http://192.168.1.64:3142 jessie/main amd64 Packages Hit http://192.168.1.64:3142 jessie/main Translation-en Err http://192.168.1.64:3142 jessie/main Translation-en Bad header line Err http://192.168.1.64:3142 jessie/main amd64 Packages 404 Not Found W: Failed to fetch http://192.168.1.64:3142/debian/dists/jessie/main/binary-amd64/Packages 404 Not Found W: Failed to fetch http://192.168.1.64:3142/debian/dists/jessie/main/i18n/Translation-en Bad header line E: Some index files failed to download. They have been ignored, or old ones used instead. There is no way to guess from this output that there is no space. So, please, print "no space left" instead. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.6\.0-0\.bpo\.1-amd64$"; APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.6\.0-0\.bpo\.1-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Never-MarkAuto-Sections:: "oldlibs"; APT::Never-MarkAuto-Sections:: "restricted/oldlibs"; APT::Never-MarkAuto-Sections:: "universe/oldlibs"; APT::Never-MarkAuto-Sections:: "multiverse/oldlibs"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "1"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "2"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-9n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "false"; APT::Compressor::bzip2::Cost "3"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "false"; APT::Compressor::xz::Cost "4"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "false"; APT::Compressor::lzma::Cost "5"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--suffix="; APT::Compressor::lzma::CompressArg:: "-9"; APT::Compressor::lzma::UncompressArg "";
Bug#833155: rsync: "rsync root@host:'dat' /" doesn't autocomplete
Package: rsync Version: 3.1.1-3 Severity: normal The following command does not autocomplete: rsync root@host:'dat' / bash-completion is installed. The following is uncommented in /etc/bash.bashrc: if ! shopt -oq posix; then if [ -f /usr/share/bash-completion/bash_completion ]; then . /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then . /etc/bash_completion fi fi Completion works normally in other commands, such as dpkg. "rsync root@host:dat /" works normally. -- System Information: Debian Release: 8.5 Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages rsync depends on: ii base-files 8+deb8u5 ii libacl1 2.2.52-2 ii libattr11:2.4.47-2 ii libc6 2.19-18+deb8u4 ii libpopt01.16-10 ii lsb-base4.1+Debian13+nmu1 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:6.7p1-5+deb8u2 ii openssh-server 1:6.7p1-5+deb8u2 -- no debconf information
Bug#833059: coreutils: "du --exclude='*.jpg' /" doesn't autocomplete
Package: coreutils Version: 8.23-4 Severity: normal Type the following: du --exclude='*.jpg' / You will see that doesn't autocomplete. "du /" works normally. bash-completion is installed. The following is uncommented in /etc/bash.bashrc: # enable bash completion in interactive shells if ! shopt -oq posix; then if [ -f /usr/share/bash-completion/bash_completion ]; then . /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then . /etc/bash_completion fi fi Completion works normally in other utils (such as dpkg and apt). -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc62.19-18+deb8u4 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#832999: "ping: icmp open socket: Operation not permitted" as non-root in Debian Live
Package: iputils-ping Version: 3:20121221-5+b2 Severity: normal I downloaded Debian Live from this link: http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-8.5.0-amd64-kde-desktop.iso I booted into this KDE live system, opened Konsole terminal emulator, typed "ping debian.org" (as non-root) into it and saw: "ping: icmp open socket: Operation not permitted". "sudo ping debian.org" works. user@debian:~$ ls -l /bin/ping -rwxr-xr-x 1 root root 44104 Nov 8 2014 /bin/ping user@debian:~$ stat /bin/ping File: ‘/bin/ping’ Size: 44104 Blocks: 88 IO Block: 1024 regular file Device: 13h/19d Inode: 509687 Links: 1 Access: (0755/-rwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2014-11-08 17:04:43.0 + Modify: 2014-11-08 17:04:43.0 + Change: 2014-11-08 17:04:43.0 + Birth: - -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages iputils-ping depends on: ii libc62.19-18+deb8u4 ii libcap2 1:2.24-8 ii libgnutls-openssl27 3.3.8-6+deb8u3 Versions of packages iputils-ping recommends: ii libcap2-bin 1:2.24-8 iputils-ping suggests no packages. -- no debconf information
Bug#830693: systemd-container: systemd-nspawn says: "Failed to create directory /str/sys/fs/selinux: Read-only file system"
Package: systemd-container Version: 230-5 Severity: normal Steps to reproduce: Download stretch alpha 7 installer, install it using qemu, then in this fresh scretch system install debootstrap and systemd-container. Then run: # debootstrap stretch /str http://10.0.2.2:3142/debian (URL here is just my local APT caching mirror, of course you can replace it with something else) # systemd-nspawn -D /str You will see: root@debian:~# systemd-nspawn -D /str Spawning container str on /str. Press ^] three times within 1s to kill container. Failed to create directory /str/sys/fs/selinux: Read-only file system Failed to create directory /str/sys/fs/selinux: Read-only file system root@str:~# I. e. we see here some complains about "Read-only file system". -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-container depends on: ii libacl1 2.2.52-3 ii libblkid12.28-5 ii libbz2-1.0 1.0.6-8 ii libc62.22-13 ii libcurl3-gnutls 7.47.0-1 ii libgcrypt20 1.7.1-2 ii liblzma5 5.1.1alpha+20120614-2.1 ii libseccomp2 2.3.1-2 ii libselinux1 2.5-3 ii systemd 230-5 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages systemd-container recommends: ii btrfs-progs4.5.2-1 ii libnss-mymachines 230-5 systemd-container suggests no packages. -- no debconf information
Bug#830578: Re[2]: Bug#830578: apt-cacher-ng: Ignores CacheDir in default installation. Weird default behavior on Debian. debconf overrides CacheDir, but dpkg-rec. isn't run
>Now you waste my time by not providing the exact information. There >should be a comment in zz_debconf.conf saying why the override has been >placed there. If you want some info, then just ask for it. zz_debconf.conf after fresh install on sid contains the following: # Proxy set by other config files(s) # Port is set by other config file(s) # BindAddress is set by other config file(s) CacheDir: /var/cache/apt-cacher-ng # default or overridden since '/var/cache/apt-cacher-ng' directory didn't exist # PassThroughPattern: setting is not configured by debconf If you want some more info, then just ask. I can easily create small debian system and run it using chroot or systemd-nspawn or qemu and perform some experiments on it. == Askar Safin
Bug#830578: apt-cacher-ng: Ignores CacheDir in default installation. Weird default behavior on Debian. debconf overrides CacheDir, but dpkg-rec. isn't run
Package: apt-cacher-ng
Version: 0.9.3.1-1
Severity: important
Default behavior of CacheDir on Debian is really weird and annoying.
Steps to reproduce:
* Install apt-cacher-ng typical way ("apt-get install apt-cacher-ng") on sid.
You will notice that no interactive debconf will be run during this
process
* Change CacheDir in /etc/apt-cacher-ng/acng.conf
* Restart apt-cacher-ng
You will see apt-cacher-ng will not pick up this new CacheDir and will use
default ( /var/cache/apt-cacher-ng ) instead.
At first I didn't understand root of the problem. Then I finally understand it,
this took significant time.
After trying to reproduce the bug in clean container, I suddenly decided to use
instructions in acng.conf.
Instructions read: "THIS FILE IS MAYBE JUST ONE OF MANY CONFIGURATION FILES IN
THIS DIRECTORY". I looked at /etc/apt-cacher-ng and found
zz_debconf.conf . This file overrides CacheDir.
So,
* Straight-forward way of changing CacheDir doesn't work. Yes, you put big fat
warning into acng.conf, but I think nobody will actually read it
* You override CacheDir in debconf. Okey, but then why you don't run
interactive debconf during package install? If CacheDir is overrided, then
debconf should ask a user where he wants to put CacheDir. This question should
be enabled under default settings. In current situation debconf
overrides CacheDir although user didn't ask for that
So, please don't override CacheDir on default or ask a user during installation
where he wants to put CacheDir.
Bug#275623: Please, make /etc/skel/.bashrc and root's .bashrc identical
Please, make /etc/skel/.bashrc and root's .bashrc identical. Yes, you may make them both as empty as you want. But there is no any need in keeping them different. When I create new system, I edit this files using my scripts. This is part of my scripts: sed -i 's/^#force_color_prompt=yes$/force_color_prompt=yes/' ~/.bashrc sudo sed -i 's/^\(# \|\)PS1=.*$/PS1='\''\\[\\033[1m\\]\\u@\\h:\\w\\$\\[\\033[0m\\] '\''/' /root/.bashrc As you can see, I have to handle this bashrc's different, because they are different. Yes, I can just copy /etc/skel/.bashrc into /root/.bashrc. But then this would be kludge. Why users of the system have to do such copy? Why not just make this files identical upstream? Please, fix this in stretch or at least in buster. So that when new debian release is deployed, I will not use such kludges any more. Also, please, make whole /etc/skel be copied into /root at installation time. This will merge /etc/skel/.bashrc with /root/.bashrc and same for .profile etc. == Askar Safin
Bug#825371: python-lldb-3.9: Actually depends on python-six
Package: python-lldb-3.9 Version: 1:3.9~svn262954-1 Severity: normal I just created fresh Debian sid chroot environment using my tool similar to debootstrap. I installed clang-3.9 and lldb-3.9 and started lldb. It showed me error message about missing python module "six". So, please, mention "python-six" (or similar) as a dependency of "python-lldb-3.9" (or similar). -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages python-lldb-3.9 depends on: ii python 2.7.11-1 python-lldb-3.9 recommends no packages. python-lldb-3.9 suggests no packages. -- no debconf information
Bug#659387: Re[2]: [PATCH] apt-get -o RootDir=/foo install ... fails if /foo/foo doesn't exists
What option I should use to install some package to chroot environment? RootDir or Dir? == Askar Safin http://vk.com/safinaskar
Bug#778531: Re[2]: Bug#778531: Patch
Thanks for the patch, but you haven't really told us about your usecase with c++ in a d-i context. Any C library should allow including from C++. My usecase is following: I wrote my own analogue of debootstrap/cdebootstrap called asdebootstrap (as for Askar Safin, of course :)). I wrote it just because I like to experiment. It is written in shell, here is a source: http://paste.debian.net/289334 (some comments are in Russian). It depends on my util asdebootstrap-resolve, which performs actual dependencies resolving. asdebootstrap-resolve is written in C++, here is a source: http://paste.debian.net/289335 . asdebootstrap-resolve depends on libdebian-installer and on my library libsh: https://github.com/safinaskar/libsh. In particular, asdebootstrap-resolve depends on argument parser from libsh. This argument parser is written in C++14 and it heavily depends on C++11/C++14 features, including variadic templates. The parser is a header file arg.hpp and every file which includes it should be in C++14, too. So, asdebootstrap-resolve is C++14 and it includes libdebian-installer headers. == Askar Safin http://vk.com/safinaskar
Bug#778531: Patch
Patch for source package libdebian-installer 0.99+deb8u1.
==
Askar Safin
http://vk.com/safinaskar
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/exec.h
new/include/debian-installer/exec.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/exec.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/exec.h 2015-08-04 20:54:55.335590329 +
@@ -20,6 +20,11 @@
#ifndef DEBIAN_INSTALLER__EXEC_H
#define DEBIAN_INSTALLER__EXEC_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/types.h
#include sys/types.h
@@ -200,4 +205,9 @@
}
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/hash.h
new/include/debian-installer/hash.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/hash.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/hash.h 2015-08-04 20:54:55.339590329 +
@@ -21,6 +21,11 @@
#ifndef DEBIAN_INSTALLER__HASH_H
#define DEBIAN_INSTALLER__HASH_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/types.h
/**
@@ -139,4 +144,9 @@
di_ksize_t di_hash_table_size (di_hash_table *hash_table);
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/list.h
new/include/debian-installer/list.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/list.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/list.h 2015-08-04 20:54:55.339590329 +
@@ -20,6 +20,11 @@
#ifndef DEBIAN_INSTALLER__LIST_H
#define DEBIAN_INSTALLER__LIST_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/mem_chunk.h
typedef struct di_list di_list;
@@ -116,4 +121,9 @@
void di_list_prepend_chunk (di_list *list, void *data, di_mem_chunk
*mem_chunk) __attribute__ ((nonnull(1,3)));
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/log.h
new/include/debian-installer/log.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/log.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/log.h 2015-08-04 20:54:55.343590329 +
@@ -20,6 +20,11 @@
#ifndef DEBIAN_INSTALLER__LOG_H
#define DEBIAN_INSTALLER__LOG_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include stdarg.h
/**
@@ -104,4 +109,9 @@
di_log_handler_syslog;
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/mem.h
new/include/debian-installer/mem.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/mem.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/mem.h 2015-08-04 20:54:55.351590330 +
@@ -21,6 +21,11 @@
#ifndef DEBIAN_INSTALLER__MEM_H
#define DEBIAN_INSTALLER__MEM_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/types.h
#include stdio.h
@@ -87,4 +92,9 @@
((struct_type *) di_realloc ((mem), sizeof (struct_type) * (n_structs)))
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/mem_chunk.h
new/include/debian-installer/mem_chunk.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/mem_chunk.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/mem_chunk.h2015-08-04 20:54:55.355590330
+
@@ -21,6 +21,11 @@
#ifndef DEBIAN_INSTALLER__MEM_CHUNK_H
#define DEBIAN_INSTALLER__MEM_CHUNK_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/types.h
typedef struct di_mem_chunk di_mem_chunk;
@@ -37,4 +42,9 @@
size_t di_mem_chunk_size (di_mem_chunk *mem_chunk);
/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff -Naur libdebian-installer-0.99+deb8u1/include/debian-installer/package.h
new/include/debian-installer/package.h
--- libdebian-installer-0.99+deb8u1/include/debian-installer/package.h
2014-11-05 01:19:08.0 +
+++ new/include/debian-installer/package.h 2015-08-04 20:54:55.359590330
+
@@ -20,23 +20,16 @@
#ifndef DEBIAN_INSTALLER__PACKAGE_H
#define DEBIAN_INSTALLER__PACKAGE_H
+#ifdef __cplusplus
+extern C
+{
+#endif
+
#include debian-installer/mem.h
#include debian-installer/parser.h
#include debian-installer/slist.h
#include debian-installer/string.h
-typedef struct di_package di_package;
-typedef struct di_package_dependency di_package_dependency;
-typedef struct di_package_version di_package_version;
-
-typedef enum di_package_dependency_type di_package_dependency_type;
-typedef enum di_package_priority di_package_priority;
-typedef enum di_package_status di_package_status;
-typedef enum di_package_status_want di_package_status_want;
-typedef enum di_package_type di_package_type;
-
-#include debian-installer/packages.h
-
/**
* @addtogroup di_package
* @{
@@ -54,6 +47,8 @@
di_package_priority_required
Bug#778531: libdebian-installer4-dev: Cannot include from C++
Package: libdebian-installer4-dev Version: 0.98 Severity: normal I cannot build C++ programs using this library. G++ shows a lot of errors and warnings. /usr/include/debian-installer/package.h:32:14: error: use of enum ‘di_package_dependency_type’ without previous declaration typedef enum di_package_dependency_type di_package_dependency_type; ^ /usr/include/debian-installer/package.h:32:67: error: invalid type in declaration before ‘;’ token typedef enum di_package_dependency_type di_package_dependency_type; ^ /usr/include/debian-installer/package.h:33:14: error: use of enum ‘di_package_priority’ without previous declaration typedef enum di_package_priority di_package_priority; ^ /usr/include/debian-installer/package.h:33:53: error: invalid type in declaration before ‘;’ token typedef enum di_package_priority di_package_priority; ^ /usr/include/debian-installer/package.h: In function ‘di_package* di_package_alloc(di_packages_allocator*)’: /usr/include/debian-installer/package.h:161:59: error: invalid conversion from ‘void*’ to ‘di_package*’ [-fpermissive] return di_mem_chunk_alloc0 (allocator-package_mem_chunk); ^ /usr/include/debian-installer/package.h: In function ‘di_package_dependency* di_package_dependency_alloc(di_packages_allocator*)’: /usr/include/debian-installer/package.h:166:70: error: invalid conversion from ‘void*’ to ‘di_package_dependency*’ [-fpermissive] return di_mem_chunk_alloc0 (allocator-package_dependency_mem_chunk); ^ Also, there is no extern C-trick in the headers. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libdebian-installer4-dev depends on: ii libdebian-installer-extra4 0.98 ii libdebian-installer40.98 libdebian-installer4-dev recommends no packages. libdebian-installer4-dev suggests no packages. -- 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#773673: Re[2]: Bug#773673: reportbug: I cannot change window size when nano is running inside reportbug
do you experience the same behavior when running nano by itself (i.e. not spawn by reportbug) in konsole? No
Bug#773668: okular shows jumping letters in pdf documents generated using pdflatex with russian babel
Package: okular
Version: 4:4.8.4-3+b1
Severity: normal
Tags: l10n
Steps to reproduce:
* Create the following file tex.tex:
\documentclass[a4paper]{article}
\usepackage[russian]{babel}
\begin{document}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed ...
\end{document}
* pdflatex tex.tex
* okular tex.pdf
* Adjust zoom until you will see ugly jumping letters (i. e. one letter is
up, and the following letter in the same word is down). For example, on my
laptop with screen resolution 1600 x 900 pixels and physical size
214.8 cm x 381.9 cm zoom 100 % will go
What I see? Well, jumping letters. I see something like this: LOrEm IpSum
DOlOr SIT AmEt See screenshot: http://picpaste.com/y-gh3PH69b.png .
What I expected to see? Normal beautiful text.
Including [russian]{babel} is mandatory to reproduce the bug. [english]{babel}
will not go.
But the text itself need not to be in Russian. You don't need even
\usepackage[...]{inputenc}.
latex tex.tex + okular tex.dvi - no bug.
latex tex.tex + dvipdfm tex.dvi + okular tex.pdf - no bug.
pdflatex tex.tex + okular tex.pdf - bug.
pdflatex tex.tex + evince tex.pdf - no bug.
pdflatex tex.tex + transfer this tex.pdf to Windows machine + open it with
Adobe Reader on Windows - no bug.
TeXLive version info:
ii texlive-base 2012.20120611-5
all TeX Live: Essential programs and files
ii texlive-binaries 2012.20120628-4
amd64Binaries for TeX Live
ii texlive-common2012.20120611-5
all TeX Live: Base component
ii texlive-doc-base 2012.20120611-1
all TeX Live: TeX Live documentation
ii texlive-extra-utils 2012.20120611-2
all TeX Live: TeX auxiliary programs
ii texlive-font-utils2012.20120611-2
all TeX Live: Graphics and font utilities
ii texlive-fonts-recommended 2012.20120611-5
all TeX Live: Recommended fonts
ii texlive-generic-extra 2012.20120611-2
all TeX Live: Extra generic packages
ii texlive-generic-recommended 2012.20120611-5
all TeX Live: Recommended generic packages
ii texlive-lang-cyrillic 2012.20120611-2
all TeX Live: Cyrillic
ii texlive-latex-base2012.20120611-5
all TeX Live: Basic LaTeX packages
ii texlive-latex-extra 2012.20120611-2
all TeX Live: LaTeX supplementary packages
ii texlive-latex-recommended 2012.20120611-5
all TeX Live: LaTeX recommended packages
ii texlive-math-extra2012.20120611-2
all TeX Live: Advanced math typesetting
ii texlive-metapost 2012.20120611-5
all TeX Live: MetaPost (and Metafont) drawing packages
ii texlive-pictures 2012.20120611-5
all TeX Live: Graphics packages and programs
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages okular depends on:
ii kde-runtime 4:4.8.4-2
ii libc6 2.18-4
ii libfreetype6 2.4.9-1.1
ii libjpeg8 8d-1+deb7u1
ii libkdecore5 4:4.8.4-4+deb7u1
ii libkdeui5 4:4.8.4-4+deb7u1
ii libkio5 4:4.8.4-4+deb7u1
ii libkparts44:4.8.4-4+deb7u1
ii libkprintutils4 4:4.8.4-4+deb7u1
ii libkpty4 4:4.8.4-4+deb7u1
ii libokularcore14:4.8.4-3+b1
ii libphonon44:4.6.0.0-3
ii libpoppler-qt4-3 0.18.4-6
ii libqca2 2.0.3-4
ii libqimageblitz4 1:0.0.6-4
ii libqt4-dbus 4:4.8.2+dfsg-11
ii libqt4-svg4:4.8.2+dfsg-11
ii libqt4-xml4:4.8.2+dfsg-11
ii libqtcore44:4.8.2+dfsg-11
ii libqtgui4 4:4.8.2+dfsg-11
ii libsolid4 4:4.8.4-4+deb7u1
ii libspectre1 0.2.7-2
ii libstdc++64.7.2-5
ii phonon4:4.6.0.0-3
ii zlib1g1:1.2.7.dfsg-13
okular recommends no packages.
Versions of packages okular suggests:
ii ghostscript9.05~dfsg-6.3+deb7u1
pn jovie none
ii okular-extra-backends 4:4.8.4-3+b1
ii poppler-data 0.4.5-10
ii texlive-binaries 2012.20120628-4
ii unrar 1:3.9.10-1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Bug#773673: reportbug: I cannot change window size when nano is running inside reportbug
Package: reportbug Version: 6.4.4+deb7u1 Severity: normal Steps to reproduce: I run reportbug, answer questions, then at some point the reportbug run editor (nano), this editor is started in my terminal (konsole), then I try to change window (i. e. konsole's) size. The size changes, but nano becomes corrupted. ii nano 2.2.6-1+b1 amd64 ii konsole 4:4.8.4-2 amd64 -- Package-specific info: ** Environment settings: INTERFACE=text ** /root/.reportbugrc: reportbug_version 6.4.4 mode advanced ui text realname Askar Safin email safinas...@mail.ru no-check-uid no-cc header X-Debbugs-CC: safinas...@mail.ru smtphost reportbug.debian.org -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 0.9.7.9+deb7u6 ii python2.7.3-4+deb7u1 ii python-reportbug 6.4.4+deb7u1 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail none pn debconf-utils none pn debsumsnone pn dlocatenone pn emacs22-bin-common | emacs23-bin-commonnone ii exim4-daemon-light [mail-transport-agent] 4.80-7+deb7u1 ii file 5.11-2+deb7u6 ii gnupg 1.4.12-7+deb7u6 ii python-gtk22.24.0-3+b1 pn python-gtkspellnone pn python-urwid none pn python-vte none ii xdg-utils 1.1.0~rc1+git20111210-6+deb7u1 Versions of packages python-reportbug depends on: ii apt 0.9.7.9+deb7u6 ii python2.7.3-4+deb7u1 ii python-debian 0.1.21 ii python-debianbts 1.11 ii python-support1.0.15 python-reportbug suggests no packages. -- 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#772653: bison: %define api.value.type union is broken. It is impossible to use it with flex
Package: bison Version: 2:3.0.2.dfsg-2 Severity: important Tags: upstream Hi. Recently bison introduced new feature %define api.value.type union. The feature (as it seems from documentation) is really cool and I want to use it. But it is broken. If one say to bison to generate .tab.h-file, then this .tab.h will contain duplicate members in unions. And one need .tab.h to use bison with flex. You can find exact reproducing steps here: http://paste.debian.net/131031 . The bug still persists in lastest bison 3.0.2. The bug was already reported here: http://lists.gnu.org/archive/html/bug-bison/2014-03/msg0.html and is still not fixed -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bison depends on: ii libbison-dev 2:3.0.2.dfsg-2 ii libc6 2.18-4 ii m41.4.16-3 bison recommends no packages. Versions of packages bison suggests: pn bison-doc none -- no debconf information == Askar Safin http://vk.com/safinaskar Kazan, Russia
Bug#771244: Re[3]: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
Please stop mischaracterizing the issue. It's not a bug: it's a case of konsole's mismatched expectations. Since the mechanism it uses is not documented, and relies on something in readline that is not documented, it can't fairly be called a bug. Should long text line move when user changes size of terminal or no? So? Askar
Bug#771244: Re[2]: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
Someone else already provided a suitable answer. Continuing this conversation is not productive; it's quickly reaching dead horse territory. You might want to check out the latest devel branch snapshot, though. It works! Thanks a lot. Bug seems to be fixed in 2bfa477ae8878e21c0b15b5d66099c4c16899c0a in branch devel of git://git.sv.gnu.org/bash.git Bug in readline alone seems to be fixed, too (tested using small C program on top of readline). Thanks again, Chet, you are nice. ^_^ As well as I know bugs in Debian bug tracker should not be closed until fixed version will be uploaded to Debian. So, I will not close the bug (right?). == Askar Safin http://vk.com/safinaskar Kazan, Russia
Bug#771244: Re[2]: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
Please stop mischaracterizing the issue. It's not a bug: it's a case of konsole's mismatched expectations. Since the mechanism it uses is not documented, and relies on something in readline that is not documented, it can't fairly be called a bug. Should long text line move when user changes size of terminal or no? Askar
Bug#771244: Re[2]: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
No. You have missed the point. The point is that the secret mechanism that konsole used to use no longer works. It didn't rely on documented behavior; it relied on a side effect of the (flawed) readline-6.2 implementation. It can't really be called a bug. Okey, so, Chet, what will you say about resizing bug? Is this a bug? At this moment I doesn't ask where (readline or konsole) this bug resides. I'm just asking: is this a bug? Or long line doesn't move on resize is intended behavior? Also, mc resizes when I resize terminal window in all terminals. So, bash should move, too. Then, if you agree this is a bug, where should it fixed? You think in konsole, right? So, you think that konsole should be aware of some readline internals and should redisplay readline prompt itself? Well, let's suppose this. But what about mc? If I will follow your logic, it seems that mc should not redisplay itself in SIGWINCH handler (because it should not call too many functions in handlers) and so we have two possibilities: 1) Terminal should redisplay mc itself (this is impossible) 2) mc should not redisplay itself on SIGWINCH, nor terminal should do this. So, mc just should not resize (and user will be angry) mc somehow was able to redisplay itself on SIGWINCH, so why readline (which is smaller program) cannot? (And I don't ask you to fix this bug now, if you will say OK, it should be fixed, but I currently don't have time, this will be completely OK for me.) Yes, I understand, handlers, blah-blah. readline should not perform a lot of actions in SIGWINCH handler, so, they are deferred until read() exits. But mc has no such problems. And ssh client has no such problems (and so, it is able to pass SIGWINCH to remote program, for example, to remote mc). Further complicating things is the fact that there is not any portable way to specify that SIGWINCH should interrupt system calls. (from http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00070.html ) Well, let's specify that SIGWINCH should interrupt syscalls at least on archs where it is supposed to use interactive resizeable terminals. :) I don't think that someone use interactive terminal and resize it on some embedded device. (On GNU/Linux SIGWINCH interrupts read() by default, I tested this.) So, you can perform some compile-test. If you can make SIGWINCH to interrupt read() (for example, on GNU/Linux), then let's do it, if no - so, no. (Yes, there is still a problem: you may want to connect via ssh from some normal desktop OS (GNU/Linux, Mac OS X, WIndows) to some obscure embedded device. And in this case SIGWINCH will not work. But this a very special case, so this is OK.) Now immediate resizing just doesn't work (at least in konsole). If it will work at least on some platforms (GNU/Linux) this will be very good. And now I have read threads you pointed. I have to evaluate the possible consequences of doing that, since, as I said, it leads to hard-to-reproduce problems. So, again, do you acknowledge that there is a bug in bash, which eventually should be fixed? (And again, I don't ask to fix it now.) Also, I wrote small C program to test what method terminal use to force program resizing: http://paste.debian.net/134231 . Chet, you may test this program on Mac OS. I tested it with bash 4.2, bash 4.3, Debian's gnome-terminal 2.30.2-1, Debian's konsole 4:4.4.5-2 (upstream version 2.4.5) and got the following results: What terminals send to program? | clear and reset | resize gnome-terminal | nothing | SIGWINCH konsole| SIGWINCH | SIGWINCH What behavior seems to me as good? :) | clear and reset | resize gnome-terminal + bash 4.2 | bad | good gnome-terminal + bash 4.3 | bad | bad konsole + bash 4.2| good | good konsole + bash 4.3| bad | bad (And this gnome-terminal may be too old, i. e. Pádraig Brady just reported his gnome-terminal works, he probably uses newer version.) == Askar Safin http://vk.com/safinaskar Kazan, Russia
Bug#771244: Re[2]: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
Doesn't seem like a bug to me. You asked your terminal emulator to clear the screen. It did so. Now you complain that it's too clean :) When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should work the same and it should clear scrollback additionally. bash 4.3 + konsole behavior is not OK for me, because I have to press Enter after Ctrl-Shift-X. :) I understand how it may look confusing, but I don't think the term has much option here. Suppose that instead of the shell, you were executing something else (eg. reading a log file). Yes, but this somehow worked before. And I press Ctrl-Shift-X in bash only. :) PS: While I agree that what you are considering a bug is not Debian-specific, I don't think you had enough data at bug submission time to ascertain that this was an upstream bug (specially not knowing which was the upstream provider). However, you did a good job describing the bug report itself. :) Reproduced with bash 4.3 built from upstream sources. And yes, konsole was from Debian. Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: git bisect shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? == Askar Safin http://vk.com/safinaskar Kazan, Russia
