Bug#1063841: jami quits after left mouse click on system tray icon

[Anonymous 648]

Package: jami
Version: 20230206.0~ds2-1.1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

0) I use AwesomeWM window manager
1) Run jami. Now jami icon appears on WM system tray
2) Move window focus to jami window
3) Left click jami icon in sys tray
4) jami just quits without any warning

Expected behaviour: jami continuous to work


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jami depends on:
ii  jami-daemon 20230206.0~ds2-1.1
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.6-2
ii  libnm0  1.42.4-1
ii  libnotify4  0.8.1-1
ii  libqrencode44.1.1-1
ii  libqt6core5compat6  6.4.2-1
ii  libqt6core6 6.4.2+dfsg-10
ii  libqt6dbus6 6.4.2+dfsg-10
ii  libqt6gui6  6.4.2+dfsg-10
ii  libqt6multimedia6   6.4.2-5
ii  libqt6network6  6.4.2+dfsg-10
ii  libqt6positioning6  6.4.2-1
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6quick66.4.2+dfsg-1
ii  libqt6sql6  6.4.2+dfsg-10
ii  libqt6sql6-sqlite   6.4.2+dfsg-10
ii  libqt6svg6  6.4.2-2
ii  libqt6widgets6  6.4.2+dfsg-10
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2+deb12u2
ii  libxcb1 1.15-1
ii  qml6-module-qt-labs-platform6.4.2+dfsg-1
ii  qml6-module-qt-labs-qmlmodels   6.4.2+dfsg-1
ii  qml6-module-qt5compat-graphicaleffects  6.4.2-1
ii  qml6-module-qtmultimedia6.4.2-5
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg-1
ii  qml6-module-qtquick 6.4.2+dfsg-1
ii  qml6-module-qtquick-controls6.4.2+dfsg-1
ii  qml6-module-qtquick-dialogs 6.4.2+dfsg-1
ii  qml6-module-qtquick-layouts 6.4.2+dfsg-1
ii  qml6-module-qtquick-shapes  6.4.2+dfsg-1
ii  qml6-module-qtquick-templates   6.4.2+dfsg-1
ii  qml6-module-qtquick-window  6.4.2+dfsg-1
ii  qml6-module-qtquick3d-spatialaudio  6.4.2-5

jami recommends no packages.

jami suggests no packages.

-- no debconf information

Bug#1060464: nss-tlsd: segmentation fault

[Anonymous 648]

Package: nss-tlsd
Version: 1.1-1.1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

nss-tlsd periodically crashes with segmentation fault error:
[1]2315094 segmentation fault  nss-tlsd
[1]2616830 segmentation fault  nss-tlsd



-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-16-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nss-tlsd depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u3
ii  libglib2.0-0 2.74.6-2
ii  libsoup2.4-1 2.74.3-1

nss-tlsd recommends no packages.

nss-tlsd suggests no packages.

-- Configuration Files:
/etc/nss-tls.conf changed:
[global]
resolvers=https://1.1.1.1/dns-query


-- no debconf information

Bug#1037311: rxvt-unicode: Xft font fallback issues when using subpixel rendering and URxvt.letterSpace: -2

[anonymous]

Package: rxvt-unicode
Version: 9.30-2+b4
Severity: important
X-Debbugs-Cc: epoc...@gmail.com

Dear Maintainer,

On bookworm, I'm having font rendering issues under urxvt when using Xft 
subpixel rendering (Xft.rgba: rgb) and URxvt.letterSpace: -2 in ~/.Xresources.

pic of what I mean: https://files.catbox.moe/mnb790.png
expected bullseye behavor on the left, bookworm on the right 

I use xft:Go Mono:pixelsize=13, It's falling back to some unknown serif font.
>From what I understand, in bullseye, it would just draw the glyph even if it 
>was being cut-off, now it either draws a box or uses an ugly fallback font.
I also notice that this adds significant latency to terminal output, random 
glyphs will also flicker as I type.

When I run urxvt from the terminal, stderr spits out various errors to the tune 
of
urxvt: unable to calculate font width for  using max_advance_width
But the fonts it lists are stuff like DejaVu Sans Mono, Courier New, Andale 
Mono and FreeMono, none of which I'm using in my ~/.Xresources and I can't find 
where these are being defined in /etc either.

I found that setting Xft.rgba: none and URxvt.letterSpace: -1 fixes all these 
issues but it forces me to live without subpixel rendering.

I marked as important because this makes urxvt considerably difficult to uses 
and I'm holding off on upgrading to bookworm because of it.
I can provide more information if you need it, my email is epoc...@gmail.com, 
thank you.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 rxvt-unicode depends on:
ii  base-passwd   3.6.1
ii  libc6 2.36-9
ii  libfontconfig12.14.1-4
ii  libgcc-s1 12.2.0-14
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libperl5.36   5.36.0-7
ii  libptytty02.0-1+b1
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.8.4-2
ii  libxft2   2.3.6-1
ii  libxmu6   2:1.1.3-3
ii  libxrender1   1:0.9.10-1.1
ii  ncurses-base  6.4-4
ii  ncurses-term  6.4-4

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-6
ii  fonts-vlgothic [fonts-japanese-gothic]  20220612-1

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.17+nmu1

-- no debconf information

Bug#1036187: vfu: several notes about clipboard

[Anonymous 648]

Hi Vladi.
Seems to be working fine now

On Thu, Jun 01, 2023 at 12:14:57AM +0300, Vladi Belperchinov-Shabanski wrote:


hi,

I fixed it with commit 2cfa35ceef551708481626732a4d98734e7a0f22.
also fixed size calculation so it will properly report progress
and estimate time when copy/move from the clipboard.

try it again?

P! Vladi.
--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1037026: bugs.debian.org: Thinkpad button led issue

[Anonymous thinkpad guy]

Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: raga_plonge...@icloud.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I wanted to mute the mic of mmy computer with the f4 button, and the
led of the button should turn on, but it doesn't.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
The led on the mute mic button to turn on

*** End of the template - remove these template lines ***

Bug#1036187: vfu: several notes about clipboard

[Anonymous 648]

Hi Vladi.

Seems to me new features work fine. But looks like I have found another issue.
When I add files to the clipboard - indicator shows that there are 0
files in the clipboard. Please check screenshot attached


On Tue, May 30, 2023 at 12:53:11AM +0300, Vladi Belperchinov-Shabanski wrote:


hi,

I have fixed the clipboard to add the file under cursor and more menu items
for adding and removing files to/from clipboard. this will enter the new 
release.

meanwhile you can test the latest dev version:

 mkdir vfu-tmp
 cd vfu-tmp
 wget https://cade.noxrun.com/projects/vfu/pull-and-build-vfu.sh
 chmod +x pull-and-build-vfu.sh
 ./pull-and-build-vfu.sh

in 'vfu' dir there should be curses and yascreen versions of vfu: vfu and 
vfu.yas

tell me if there are problems?

thanks,
Vladi.
--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1036187: vfu: several notes about clipboard

[Anonymous 648]

Package: vfu
Severity: wishlist
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Have several thoughts about clipboard improving

1) Now you need to select file (using SPACE) before adding it into
clipboard. Even when you want to add one file. I think it would be
better to add file under cursor into the clipboard when nothing selected.
So adding single file will be a bit easier

2) When you add new file into the clipboard - previously added files
will be removed from the clipboard. Seems to me it would be better to
keep previously added files in the clipboard. So you can add multiple files from
different directories


-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi.

I use zsh (5.8-6+deb11u1)

On Mon, Mar 20, 2023 at 11:37:59PM +0200, Vladi Belperchinov-Shabanski wrote:


hi!

fixed in vslib for "|".
still not sure if there is ever need for "%" but added for now:
(btw, what shell do you use?)

vslib
commit ecdba011eef270083320fadd5e1a0407294fb3b2 (HEAD -> master)
Date:   Mon Mar 20 23:35:15 2023 +0200

thanks!

P! Vladi.

--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1033198: vfu crashes on new directory creation

[Anonymous 648]

Package: vfu
Version: 5.07-1~bpo11+1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

1) Create new directory via pressing "t t" (vfu's tool menu)
2) Enter this directory
3) Try create new directory again via pressing "t t"

Vfu crashes with following error message in console:
 *** No files found *** vfu: vfufiles.cpp:69: TF* files_list_get(int):
 Assertion `pos >= 0 && pos < files_list_cnt' failed.
   [1]22558 abort  vfu

Please check screenshot attached


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2  1.0.8-4
ii  libc6  2.31-13+deb11u5
ii  libgcc-s1  10.2.1-6
ii  libpcre2-32-0  10.36-2+deb11u1
ii  libpcre2-8-0   10.36-2+deb11u1
ii  libstdc++6 10.2.1-6
ii  libyascreen0   1.97-1~bpo11+1
ii  unzip  6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1032340: vfu: new macros for shell

[Anonymous 648]

Hi Vladi.

Looking forward to test this feature. Thanks 



On Fri, Mar 17, 2023 at 04:24:15PM +0200, Vladi Belperchinov-Shabanski wrote:

hi!

I have added new shell place-holder %h (and %H), which equals to either
%f and %F if no files are selected or %g and %G otherwise.

the reason to add as separate placeholder is to allow using
both %f and %g in the same shell line but avoid the problem that
%g may point to %f, which is not always true.

for example you may want to have shell external which adds selected
files (%g) to pointed archive (%f) but do not want the archive
itself to be added to the same archive (i.e. %g is equal to %f if no
selection.)

in all other cases where you would want to follow common behaviour to
use selected files or if no selection, just the current one,
use %h and %H.

the feature will be added to the new backport or stable VFU Debian package
and is now in the VFU git repo at GitHub.


--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi

Removed my old .vfu directory and allowed vfu to create a new 
default configuration.


PLEASE NOTE: I have disabled usage of internal viewer and editor 
(when I tested it with internal editor - everything worked fine)


Problem exists when I use vim or any other editor for following files:
aa%bb.txt
aa|bb.txt

On Wed, Mar 15, 2023 at 12:00:57PM +0200, Vladi Belperchinov-Shabanski wrote:


hello!

regarding opening of files with names like:

 'aa bb.txt'
 'aa$bb.txt'
 'aa%bb.txt'

as of v5.00: 30.Jan.2023, VFU does not require %f to be quoted.
it was reflected in the enclosed sample vfu.conf and HISTORY
changes files.

I'm sorry for the change but the old way was not good enough
even though it was this way for years.

please, get back to me if this does not help for some reason.

cheers!
Vladi.




--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi

Removed my old .vfu directory and allowed vfu to create a new default
configuration.

PLEASE NOTE: I have disabled usage of internal viewer and editor (when I
tested it with internal editor - everything worked fine)

Problem exists when I use vim or any other editor for following files:
aa%bb.txt
aa|bb.txt

On Wed, Mar 15, 2023 at 12:00:57PM +0200, Vladi Belperchinov-Shabanski wrote:


hello!

regarding opening of files with names like:

 'aa bb.txt'
 'aa$bb.txt'
 'aa%bb.txt'

as of v5.00: 30.Jan.2023, VFU does not require %f to be quoted.
it was reflected in the enclosed sample vfu.conf and HISTORY
changes files.

I'm sorry for the change but the old way was not good enough
even though it was this way for years.

please, get back to me if this does not help for some reason.

cheers!
Vladi.




--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Package: vfu
Version: 5.07-1~bpo11+1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

1) Create files with special characters in names:
touch 'aa bb.txt'  
touch 'aa$bb.txt'
touch 'aa%bb.txt'

2) Configuration from vfu.conf:
ux=EDIT TEXT,ENTER,.txt.TXT.conf.CONF.log.LOG.cfg.CFG.,xterm -e vim "%f"  1> 
/dev/null 2> /dev/null &
see=*,see '%f' 1> /dev/null 2> /dev/null &

Configuration from .mailcap:
text/plain; batcat --paging=always '%s'; edit=vim '%s'; compose=vim '%s'; 
needsterminal

3) When I am trying to open these files using "right arrow" - nothing
happens. If I use "ENTER" for opening these files - everything works ok



-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2  1.0.8-4
ii  libc6  2.31-13+deb11u5
ii  libgcc-s1  10.2.1-6
ii  libpcre2-32-0  10.36-2+deb11u1
ii  libpcre2-8-0   10.36-2+deb11u1
ii  libstdc++6 10.2.1-6
ii  libyascreen0   1.97-1~bpo11+1
ii  unzip  6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1032338: vfu: can not enter directories which names start from empty space

[Anonymous 648]

Hi Boian.

Tested on 5.07 from backports. Bug still exists

On Sat, Mar 04, 2023 at 07:11:15PM +0200, Boian Bonev wrote:

Hi,

Thanks for reporting this.

Can you please verify that the bug is still present with 5.07-1 (or 5.07-
1~bpo11+1 from backports)?

--
With best regards,
b.

Bug#1032340: vfu: new macros for shell

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: wishlist
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Currently vfu has following macroses for opening files:
%f  -- replaced w. current filename (w/o path)
%g  -- same as %f but for each selected filename

Seems to me it would be a good idea to have additional macros
which works as %f if nothing selected (you just hit ENTER or RIGHT ARROW)
and works as %g if you have selected at least one file.

Now you need to add 2 separate lines into config file.
For cases when you want to open one file by hitting ENTER. And for cases when 
you want to
open multiple files at a time.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1029107: vfu: problem with long cyrillic file names

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

1) Create file with long latin name
touch 
lng_name.ext

2) Create file with long cyrillic(non latin) name
touch 
жж.ext
 

3) Run vfu 

Cyrillic name gets cut off. Please check screenshot attached.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1016009: reportbug: Paranoid mode shows base64 instead of human readible text

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Followup-For: Bug #1016009
X-Debbugs-Cc: debbug.report...@sideload.33mail.com
Control: tags 1016009 + a11y

You have misunderstood the purpose of the --paranoid option. The
purpose of this option is to enable users to mitigate data leaks by
checking the information being sent for publication. Hiding the
payload works contrary to this purpose and undermines the user’s
request. By hiding the msg payload in an encoded container you /block/
users from verifying what information is being transmitted for
/publication/.

The status quo is dangerous as it ensures that only highly motivated
users will actually go though the decoding hoops.

The current behavior is also ableist as it hinders anyone using a
screen reader & it also needlessly imposes a higher level of
competency on users to recognize the base64 text and convert it.

> If they are not interested in this then they don't need to use the
> option. The option is deliberately named "--paranoid" and disabled by
> default.

The current behavior only serves users who are interested in the
metadata, and disservices users who are interested in reviewing /all/
information being transmitted. Base 64-encoded text is not
reviewable. A user who wants to fully review the payload currently
must copy-paste encoded text into another file, one screenfull at a
time, taking care not to miss any lines or duplicate any lines, filter
out the whitespace, and separately filter the text through an external
tool. It’s impossible for non-GUI users to do this and absurdly
tedious and impractical for GUI users.

> If you want to check the human-readable message text before
> submission, there are already menu entries to print the message to
> stdout or view it in a pager. You don't need the --paranoid option
> for this.

Those options are only available prior to final processing by
reportbug. Reportbug does further manipulation to the bug report
/after/ the user submits (e.g. like adding a msg ID header). While
it’s likely that the final stage of processing only affects headers &
not the encoded portion, it’s unreasonable to expect users to trust
that. And trust is an understatement because unless the user actually
reads the source code, they can only speculate that the payload body
would not be altered in the final processing step.

Please reopen this ticket.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2+deb11u2
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#1024884: vfu: archives support: incorrect display file names with space

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Looks like there is a problem with built-in archives support

1) mkdir test
2) touch test/11\ 222 
3) tar -cvf test.tar test
4) Enter test.tar using vfu. Instead of "11 222" file name you
can see only "11"


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1024330: vfu compiled without unicode support

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Looks like vfu compiled without unicode support.
Instead of cyrillic symbols it shows some mess.
Please check screenshot attached.

Also attached a patch for fixing this problem. Tested with vfu 4.21.
This patch is very simple so it can be easily adapted to upstream version


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information
Patch for adding UTF-8 support to vfu file manager
--- a/vfu/makefile
+++ b/vfu/makefile
@@ -40,7 +40,7 @@
 AR_1   = $(AR) rv
 RANLIB_1   = $(RANLIB)
 CCFLAGS_1  = -I../vstring -I../vslib -I/usr/include/ncurses -O2 $(CFLAGS) 
$(CPPFLAGS) $(CCDEF)  
-LDFLAGS_1  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncurses $(LDFLAGS) $(LDDEF) 
+LDFLAGS_1  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncursesw $(LDFLAGS) $(LDDEF) 
 DEPFLAGS_1 = 
 ARFLAGS_1  = 
 TARGET_1   = vfu
@@ -226,7 +226,7 @@
 AR_3   = $(AR) rv
 RANLIB_3   = $(RANLIB)
 CCFLAGS_3  = -I../vstring -I../vslib -I/usr/include/ncurses -O0 -g $(CFLAGS) 
$(CPPFLAGS) $(CCDEF)  
-LDFLAGS_3  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncurses -g $(LDFLAGS) $(LDDEF) 
+LDFLAGS_3  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncursesw -g $(LDFLAGS) $(LDDEF) 
 DEPFLAGS_3 = 
 ARFLAGS_3  = 
 TARGET_3   = vfu-debug
--- a/vslib/makefile
+++ b/vslib/makefile
@@ -249,7 +249,7 @@
 AR_4   = $(AR) rv
 RANLIB_4   = $(RANLIB)
 CCFLAGS_4  = -g -I../vstring -I. -I../yascreen -DUSE_YASCREEN -O0 -DTEST 
$(CFLAGS) $(CPPFLAGS) $(CCDEF)  
-LDFLAGS_4  = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncurses 
$(LDFLAGS) $(LDDEF) 
+LDFLAGS_4  = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncursesw 
$(LDFLAGS) $(LDDEF) 
 DEPFLAGS_4 = 
 ARFLAGS_4  = 
 TARGET_4   = test
--- a/vslib/mm.conf
+++ b/vslib/mm.conf
@@ -67,7 +67,7 @@
 AR  = $(AR) rv
 RANLIB  = $(RANLIB)
 CCFLAGS = -g -I../vstring -I. -I../yascreen -DUSE_YASCREEN -O0 -DTEST 
$(CFLAGS) $(CPPFLAGS) $(CCDEF) 
-LDFLAGS = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncurses 
$(LDFLAGS) $(LDDEF)
+LDFLAGS = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncursesw 
$(LDFLAGS) $(LDDEF)
 DEPS= libvslib.a libvscon.a
 SRC = t/test.cpp
 

Bug#1024281: vfu: can not open file with special characters in name

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal

Dear Maintainer,

1) Created file with following name:
1'"1.txt

2) Configured vfu.conf to open .txt files with vim:
ux=EDIT TEXT,ENTER,.txt.TXT.conf.CONF.log.LOG.cfg.CFG., vim "%f%!"

3) After pressing ENTER on a file name I can see following error message:
*** execution failed, system() == 512 ***

4) After closing vfu I can see this message in my terminal:
sh: 1: Syntax error: Unterminated quoted string


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip21.0.8-4
ii  libc62.31-13+deb11u5
ii  libgcc-s110.2.1-6
ii  libncurses6  6.2+20201114-2
ii  libpcre3 2:8.39-13
ii  libstdc++6   10.2.1-6
ii  libtinfo66.2+20201114-2
ii  unzip6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#141323: [bug #33839] wget -nv outputs non-error output to stderr

[anonymous]

Follow-up Comment #3, bug #33839 (project wget):

Yes, please add something like `-nvv` to suppress that one line so that we can
stop writing:

$ wget -nv whatever 2>&1 | grep -v ' -> '


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Bug#1017024: reportbug: Reportbug cannot properly handle archived bugs (somewhat contrary to documentation)

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: debbug.report...@sideload.33mail.com

When a bug is archived, reportbug still accepts user input for that
bug, then falls over when the SMTP server blocks the message.  There
are a few bugs in this scenario.

(bug 1)

The documentation fails to inform the user. From the man page:

  -N BUGNUMBER, --bugnumber BUGNUMBER
  Run reportbug against the specified bug report, useful when
  following-up a bug and its number is already known.

That paragraph should instruct users that only non-archived bug
numbers will work correctly.

(bug 2)

When the user supplies “-N $archived_bug_number”, reportbug should not
continue the normal process as if the bug is live. It should interrupt
the normal flow and warn the user of consequences.  The status quo
wastes the user’s time by letting them compose an undeliverable
message.

(bug 3)

Simply being unable to do anything with an archived bug is a needless
limitation of the reportbug app.  There is a /control/ command to
unarchive a bug.  So the app should ask the user if they would like to
unarchive the bug. If the user answers “yes”, then it should send a
control msg requesting the unarchival of the bug.

(bug 4?)

This is not really in the app but rather the SMTP server that accepts
bug reports.  If a bug report is submitted for an archived bug and it
contains this line:

  Control: unarchive $archived_bug_number

the SMTP server should accept the message because the bug comment
contains an embedded request to unarchive the bug.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="text"

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2+deb11u2
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#1016834: gnucash: Debug package gnucash-gdb missing; GNC_DEBUG variable & --debug have no effect

[anonymous coward]

Package: gnucash
Version: 1:4.4-1
Severity: normal
X-Debbugs-Cc: debbug.gnuc...@sideload.33mail.com

Upstream devs have requested a stack trace from me, which is
documented here:

  https://wiki.gnucash.org/wiki/Stack_Trace

Running “aptitude search gnucash” indicates that there are no packages
named gnucash-dbg, contrary to what the wiki suggests. Ubuntu
apparently has a gnucash-dbg package.

The man page has no DEBUGGING section, but ENVIRONMENT mentions a
GNC_DEBUG variable without saying how to use it.  Since it’s a
boolean, I tried running GC this way:

  $ GNC_DEBUG=1 gnucash --debug $my_data_file

I made it crash, but there is no stack dump so it’s unclear if I
correctly guessed how to use that variable. This is the full complete
and total output from that command:

  ===8<--
  Found Finance::Quote version 1.50.
  Gdk-Message: 09:28:51.919: Lost connection to Wayland compositor.
  ===8<--

It may actually be enough information to troubleshoot the particular
bug I’m working on, but this output is too minimal. In fact, it’s the
same output as running with no debugging options. A /tmp/gnucash.trace
file was created but it’s empty.

The man page also mentions:

  --log  Log level overrides, of the form 
"log.ger.path={debug,info,warn,crit,error}" This option can be specified 
multiple times.

This syntax is bizarre and confusing. Is “log.ger.path” supposed to be
typed literally, or is that supposed to be replaced with something
else?  Is that whole equality string then passed as a space-separated
argument following --log?

The lack of gnucash-dbg package implies that users need to recompile
gnucash to get debugging symbols, IIUC. The
/etc/share/docs/gnucash/README file refers us here for building:

  https://wiki.gnucash.org/wiki/Building

But that wiki page above has no Debian-specific instructions. Debian
has a unique way of downloading source and building (unlike tarballs)
which uses Debian’s package management system. It seems we either need
a gnucash-dbg package, or Debian building instructions-- ideally both.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.4-1
ii  guile-3.0  3.0.5-4
ii  guile-3.0-libs 3.0.5-4
ii  libaqbanking44 6.2.10-1
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-locale1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13+deb11u3
ii  libcairo2  1.16.0-5
ii  libcrypt-ssleay-perl   0.73.06-1+b3
ii  libdate-manip-perl 6.83-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.50~rc2-2
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libgwengui-gtk3-79 5.6.0-2
ii  libgwenhywfar795.6.0-2
ii  libhtml-tableextract-perl  2.15-1.1
ii  libhtml-tree-perl  5.07-2
ii  libicu67   67.1-7
ii  libofx71:0.9.15-3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpython3.9   3.9.2-1
ii  libsecret-1-0  0.20.4-2
ii  libstdc++6 10.2.1-6
ii  libwebkit2gtk-4.0-37   2.36.4-1~deb11u1
ii  libwww-perl6.52-1
ii  libxml22.9.10+dfsg-6.7+deb11u2
ii  perl   5.32.1-4+deb11u2
ii  zlib1g 1:1.2.11.dfsg-2+deb11u1

Versions of packages gnucash recommends:
ii  gnucash-docs 4.4-1
ii  

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[anonymous coward]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Followup-For: Bug #1016424
X-Debbugs-Cc: debbug.1016...@sideload.33mail.com

> Therefore please report the issue upstream.

I just happened to have an account on the upstream bug tracker that
still works, so I reported here:

  https://bugs.ghostscript.com/show_bug.cgi?id=705699

But I should say this it’s not normal procedure for Debian maintainers
to ask bug reporters to mirror their report upstream according to the
section “Don't file bugs upstream” on this page:

  https://www.debian.org/Bugs/Reporting

If upstream had been a place like Github (or even worse: gitlab.com),
I would not have created an account on those forges to report a bug.
In principle, it should be automated so a Debian maintainer can mirror
bugs upstream with a simple keystroke or click, ideally.

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[anonymous coward]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Severity: normal
X-Debbugs-Cc: debbug.ghostscr...@sideload.33mail.com

Ghostscript fails to convert PBM files to PDF. Attempts were made with
3 different PBM files:

  1) scanner-made PDF → (pdfimages -all) → (unpaper) → PBM → 
(ghostscript/pdfwrite) → error
  2) tex → (LaTeX) → PDF → (ghostscript/pbm) → PBM → (ghostscript/pdfwrite) → 
error
  3) (imagemagick) → PBM → (ghostscript/pdfwrite) → error

This seems to show that PBMs of any kind produce an error when using
the PDFwrite driver.  Case 2 is interesting because it shows
Ghostscript’s own output is fed back into it and it can’t handle it.
Case 3 is demonstrated below because it requires no source file to
start with (ImageMagick gives a way to generate an arbitrary image
on-the-fly).  So it’s easy to reproduce as long as ImageMagick is
installed.

===8<--
  $ convert logo: -colors 2 -colorspace gray -normalize pbm:im_logo.pbm
  
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo.pdf -- 
/usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.pbm
  Error: /invalidfileaccess in --file--
  Operand stack:
 (im_logo.pbm)   (r)
  Execution stack:
 %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   
1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   --nostringval--   %array_continue   --nostringval--
  Dictionary stack:
 --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   
--dict:0/20(L)--
  Current allocation mode is local
  Last OS error: Permission denied
  Current file position is 10282
  GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<--

It’s worth noting that case 2 has no problem if the middle step uses
the ppmraw driver instead of the pbm driver. So I thought perhaps a
workaround would be to convert the PBM file produced by unpaper (case
1) to PPM, then feed the PPM file into GS -- but no, the same
“invalidfileaccess” occurs. I also retried case 3 but using a PPM
instead, which also failed:

===8<--
  $ convert logo: -colors 2 -colorspace gray  -normalize pbm:im_logo.ppm
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo_ppm.pdf -- 
/usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.ppm
Error: /invalidfileaccess in --file--
Operand stack:
   (im_logo.ppm)   (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   
1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   --nostringval--   %array_continue   --nostringval--
Dictionary stack:
   --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   
--dict:0/20(L)--
Current allocation mode is local
Last OS error: Permission denied
Current file position is 10282
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<--

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghostscript depends on:
ii  libc6   2.31-13+deb11u3
ii  libgs9  9.53.3~dfsg-7+deb11u2

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7+deb11u2

-- no debconf information

Bug#1016102: rsync: The --remove-source-files destroys data when source & destination are the same (data loss!)

[anonymous coward]

Package: rsync
Version: 3.2.3-4+deb11u1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: debbug.rs...@sideload.33mail.com

I accidentally ran:

  $ rsync -va --progress --remove-source-files "$dir_with_many_files" 
"$dir_with_many_files"

Due to a typo when using bash history substitution, the source and
destination were both directories and they both named the same
directory.

The expectation is that rsync should detect movement from A to A and
do nothing apart from warning the user that there is nothing to do.
Instead, because of the “--remove-source-files” option, rsync DESTROYS
all the files in "$dir_with_many_files" irrevokably.

There needs to be a safeguard that prevents --remove-source-files from
having effect if:

 * Files are not copied to the destination (for any reason)
 * The source and destination are the same

I suffered data loss because of this.  At the very least, if it’s
really intended for “rsync --remove-source-files $A $A” to effectively
behave like “rm -rf $A/*”, there AT LEAST needs to be a very loud
warning prompting the user for confirmation. But I conjecture that there
never is a legit scenario where “rsync --remove-source-files” simply
destroys files without safely ensuring they exist somewhere in the
end.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13+deb11u3
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1n-0+deb11u3
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5+deb11u1
ii  openssh-server  1:8.4p1-5+deb11u1
ii  python3 3.9.2-3

-- no debconf information

Bug#1014374: tootle: Tootle only remembers 4 accounts (5th acct can be added but is lost)

[anonymous coward]

Package: tootle
Followup-For: Bug #1014374
X-Debbugs-Cc: debbug.1014...@sideload.33mail.com

I should also mention that it’s important that tootle uses the
XDG_CONFIG_HOME variable when referencing the config file. If not, and
the config file path is hardcoded to include a directory that the user
has converted into a symbolic link (e.g. ~/.config/), that’s one
scenario that will break access to that file within a firejail
environment.

So in short, it’s still feasible that there is a tootle bug here.
Certainly the man page should specify whether the XDG_CONFIG_HOME
variable is used and otherwise how the user can control the path to
the config file.

Bug#1014374: tootle: actually there is no account limit

[anonymous coward]

Package: tootle
Followup-For: Bug #1014374
X-Debbugs-Cc: debbug.1014...@sideload.33mail.com
Control: block 1014374 by 1016015
Control: severity 1014374 minor
Control: retitle 1014374 Accounts cannot be added when running in Firejail
Control: summary 1014374 This is possibly not a bug in tootle. It may be 
strictly a Firejail bug.

Tootle was likely running within a Firejail sandbox when this bug was
noticed. Considering another app (toot) has a very similar problem
when running in Firejail, it’s more likely that firejail is preventing
config files from being updated.

As an extra test, I ran tootle outside of firejail and was able to add
more accounts.

Bug#1016015: firejail: The --read-write option fails to enable file mods to persist after the sandbox is gone

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Severity: important
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com
Control: affects 1014374 + tootle

The command tootle was first executed outside firejail to establish a
working config file. This was motivated to work around bug
1015816. After tootle proved to function outside of firejail, it was
relaunched within firejail as follows:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
 --whitelist="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 --noblacklist="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 --read-write="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 tootle

$HOME/.config is a symblic link to "$HOME"/my_config_files, and the
above configuration is crafted to ensure that firejail receives no
references to a symbolic file or directory.

Tootle was able to read the config file and make use of it within
firejail. Tootle was also able to update the config file during that
session, proven by its ability to add new accounts and interact with
them. But when the session ended, the config file updates were not
persistent and new accounts were lost.

Note that “tootle” and “toot” (mentioned in bug 1015816) are two
completely different applications, though they both serve the same
purpose.  Also note that bug 1015816 is very similar. The difference
is that in bug 1015816 the config file cannot be created, while the
bug herein reports that modifications to an existing config file do
not persist across sessions.  The bug herein may boil down to the same
bug affecting the same code as 1015816 (investigation needed).

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015816: firejail: Unable to create a whitelisted config file

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Followup-For: Bug #1015816
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

To cover all bases, I also tried enabling the read-write perms,
effectively running:

  $ firejail --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
 --whitelist="$(readlink $HOME/.config)"toot/config.json\
 --noblacklist="$(readlink $HOME/.config)"toot/config.json\
 --profile=<(printf '%s\n' 'mkdir ~/tools/conf/toot')\
 --read-write="$HOME"/my_config_files/toot\
 --read-write="$HOME"/my_config_files/toot/config.json\
 toot login

It made no difference. It still just leaves the empty directory
"$HOME"/my_config_files/toot.

As a possible secondary bug in the docs, the man page contains:

===8<--
  --read-write=dirname_or_filename
  Set directory or file read-write. Only files or directories belonging 
to the current user are allowed for this  operation.
  File globbing is supported, see FILE GLOBBING section for more 
details.  Example:

  $ mkdir ~/test
  $ touch ~/test/a
  $ firejail --read-only=~/test --read-write=~/test/a
===8<--

The man page does not state what the default perms are.  The whitelist
option in the man page says: “Modifications to whitelisted files are
persistent”. This seems to imply that the read-write option is the
default setting on whitelisted dirs, but makes no mention of what
happens if read-write is used on a non-whitelisted dir.  The example
given somewhat implies that read-write is useful when giving different
perms to a subdir than the parent dir.  But it does not outright state
this so users are left guessing.

I should also say it’s unclear whether the noblacklist option is
useful or redundant.  Does --whitelist imply --noblacklist
automatically?  The man page should make that clear.

Bug#1015816: firejail: Unable to create a whitelisted config file

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Followup-For: Bug #1015816
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

It was an interesting suggestion but in the end it made no
difference. And in fact the test inspires a feature request.

I created /tmp/toot.profile as follows:

===8<--
mkdir ~/my_config_files/toot/
===8<--

Then I ran the same command as previously, but added
“--profile=/tmp/toot.profile”.  It ran just the same as it did
previously, except the only difference is that ~/my_config_files/toot/
persists.  So it runs successfully, exits, and leaves the empty
directory ~/my_config_files/toot/.  The fact that it’s empty is the
problem.  The config file created therein must persist as well.

The output is the same as before apart from also printing the
following line upon launch:

===8<--
…
Reading profile /tmp/toot.profile
…
===8<--

It was useful to see an indicator that the profile was read. It’s a
little annoying that firejail does not inform the user that it’s
creating a directory.  After reading the profile, it eventually
executes “mkdir ~/my_config_files/toot/” without telling the user.  So
as a feature request I suggest printing that action in the output.

Even if the /mkdir/ parameter were to have fixed the problem, it would
have simply been a workaround.  That is, it’s not always trivial (or
even possible) to predict which directories an app will
create. Firejail should permit an app to arbitrarily create any
directories on-the-fly as needed-- to the extent that it has write
permission in the applicable directory.

In a 2nd test I took your suggestion a step further, and expanded
/tmp/toot.profile to also create the file:

===8<--
mkdir ~/my_config_files/toot/
mkfile ~/my_config_files/toot/config.json
===8<--

Firejail successfully created an empty config file, but this time it
fell over.  When I say “it” fell over, I don’t know if Firejail fell
over or if the app did. I’m speculating that the app’s JSON parser did
not like finding any empty file.  This was the output:

===8<--
Traceback (most recent call last):
  File "/usr/bin/toot", line 11, in 
load_entry_point('toot==0.27.0', 'console_scripts', 'toot')()
  File "/usr/lib/python3/dist-packages/toot/console.py", line 547, in main
user, app = config.get_active_user_app()
  File "/usr/lib/python3/dist-packages/toot/config.py", line 94, in 
get_active_user_app
config = load_config()
  File "/usr/lib/python3/dist-packages/toot/config.py", line 70, in load_config
return json.load(f)
  File "/usr/lib/python3.9/json/__init__.py", line 293, in load
return loads(fp.read(),
  File "/usr/lib/python3.9/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.9/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 2 column 1 (char 1)
===8<--

I think I might have previously reported the difficulty in
distinguising an app error from a firejail error because FJ does not
tag its own output.  In any case, to summarize, I’ll enumerate the 3
outstanding issues:

1) The config file for the /toot/ app is apparently created within the
sandbox but it fails to persist when the app terminates (regardless of
whether or not the mkdir parameter is used).

2) The mkdir and mkfile profile parameters take effect (as expected),
but Firejail neglects to inform the user of this.

3) Firejail errors are often indistinguishible from child process
errors because FJ makes no effort to tag its own output.



-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1016009: reportbug: Paranoid mode shows base64 instead of human readible text

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: wishlist
Tags: a11y
X-Debbugs-Cc: debbug.report...@sideload.33mail.com

Using the --paranoid option shows the text of the bug report before
transmission. In my case, the body is usually base64 encoded, which
means only the headers are readible to a human.

There may be some debugging or academic merit to showing the base64,
but this is not generally what the user is interested in.  This can be
improved in a couple ways:

1) After the headers, instead of showing multiple screens full of
base64, just print 1 line like:

  «115 lines of base64-encoded text»

and follow that with:

  [decoded body]
  …
  …

«OR»

2) show just the decoded msg, but give an extra option in the prompt
to show the verbatim raw msg for those who are interested.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2+deb11u2
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#1016007: reportbug: The prompt “Does this bug still exist in version X…” requires a binary answer when there are 3 possibilities

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: debbug.report...@sideload.33mail.com

In responding to this bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880877

reportbug prompted with:

  Does this bug still exist in version 7.10.3+deb11u1 of this package [y|N|q|?]?

Luckily I happened to know the answer, but this is not always the
case. Forcing users to answer this question with “y” or “n”
facilitates misinfo, because a user who does not know if their
particular version at the moment has the bug may opt to give an
arbitrary answer instead of testing.  Maybe they can’t test. Maybe
testing the bug requires a complex/elaborate setup.  There needs to be
an option to skip this question.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="text"

** /home/blee/.reportbugrc:
reportbug_version "7.10.3"
mode advanced
ui text
realname "anonymous coward"
email "tripr@a5dkbvgakon2lxmauleiizkv6i3s36wp6w3i32a3buc4xmtdnbttmryd.onion"
no-cc
list-cc-me
smtphost reportbug.debian.org

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2+deb11u2
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#880877: reportbug: leak user private information in the SMTP log

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Followup-For: Bug #880877
X-Debbugs-Cc: debbug.880...@sideload.33mail.com

>> When reportbug is used as a direct SMTP client , reporting user
>> hostname , ip and username  are leaked to the BTS.
>
> well, that's how mail transport systems work

Different MTAs work differently.

Regarding the hostname, that is a configurable parameter in
postfix. It can be whatever the user sets it to.

Regarding IP, all MTAs inherently know the IP but some
privacy-respecting MTAs strip out the IP to protect the sender’s
privacy from the recipient.  This is crtically important when email is
not merely going to the inbox of an individual but rather being
published to the world.  It’s reckless to expose that sensitive
information.

The MTA is one place where this leak can be addressed, but it’s not
the only place. IIUC, bugs are processed by procmail, which means a
procmail recipe also has the opportunity to strip out the sender’s IP
address.

>> Such information leak is not expected (and undesirable). That
>> information is passes under Message-ID (hash-reportbug@users-fqdn)
>> and in the Received: from section.
>
> this is generated by a standard python function
>
> reportbug/submit.py:message['Message-ID'] =
> email.utils.make_msgid('reportbug')

While it’s interesting to know that a standard lib fails to give the
user control over what elements are used for the composition of the
msg id, this does not excuse the leaking of sensitive info.  Use of
that library call is optional. IIRC, the RFC does not dictate what
info appears in a msg id, only that the msg id is sufficiently random
so as to facilitate uniqueness and avoid duplicating another msg id.

> this is all expected.

Certainly not. It’s expected that a mainstream project like Debian be
on the ball about safeguarding sensitive info.  IP address & other
unique IDs can go in the logs if Debian needs the info for abuse
control, but it’s embarrassing that a reputable distro would publish
that info for the world.

> what i think your report is missing is a concrete solution to address
> whatever you think it wrong. if you cant provide anything, i'm afraid i'm
> going to close this report, as i dont think any action is warranted.

This is a bug report, not a PR request.  Bug reports do not need a PR
request to justify their existence.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2+deb11u2
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#1014871: reportbug: is being confusing with the -r option

[anonymous coward]

Package: reportbug
Version: 7.10.3+deb11u1
Followup-For: Bug #1014871
X-Debbugs-Cc: debbug.1014...@sideload.33mail.com

Indeed I concur. If this bug report were on Launchpad I would be
upvoting it (which I think is not possible in debian bug reports).

Calling reportbug -r “confusing” is putting it overly lightly. The -r
option is actually completely broken & useless.  There are several
bugs which should probably be reported separately.

This is what my session looked like:

===8<--
$ torsocks reportbug -r "$saved_report"
1658731266 WARNING torsocks[21461]: [syscall] Unsupported syscall number 315. 
Denying the call (in tsocks_syscall() at syscall.c:604)
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'anonymous coward 
' as your 
from address.
Will send report to Debian (per lsb_release).

Spawning emacs...
1658731267 WARNING torsocks[21486]: [syscall] Unsupported syscall number 315. 
Denying the call (in tsocks_syscall() at syscall.c:604)
No changes were made in the editor.
Report will be sent to Debian Bug Tracking System 
Submit this report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|tSubmit this 
report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]?Submit this report 
on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? y
Report is unchanged. Edit this report or quit [E|q|s|?]? s
Sending empty report anyway...
1658731287 ERROR torsocks[21461]: Unable to resolve. Status reply: 4 (in 
socks5_recv_resolve_reply() at socks5.c:677)
Saving a backup of the report at 
/tmp/reportbug-reportbug-backup-20220725084127-j_q_q9m2
Connecting to reportbug.debian.org via SMTP...
1658731289 ERROR torsocks[21461]: Unable to resolve. Status reply: 4 (in 
socks5_recv_resolve_reply() at socks5.c:677)
1658731289 ERROR torsocks[21461]: Unable to resolve. Status reply: 4 (in 
socks5_recv_resolve_reply() at socks5.c:677)
SMTP send failure: (550, b'No valid sender found in the From:, Sender: and 
Reply-to: headers'). You can retry, or save the report and exit.
Do you want to retry [Y|n|q|?]? 
Connecting to reportbug.debian.org via SMTP...
1658731317 ERROR torsocks[21461]: Unable to resolve. Status reply: 4 (in 
socks5_recv_resolve_reply() at socks5.c:677)
1658731318 ERROR torsocks[21461]: Unable to resolve. Status reply: 4 (in 
socks5_recv_resolve_reply() at socks5.c:677)
SMTP send failure: (550, b'No valid sender found in the From:, Sender: and 
Reply-to: headers'). You can retry, or save the report and exit.
Do you want to retry [Y|n|q|?]? q
===8<--

Bug 1) It ignored the email address that was supplied in the saved
draft and instead used the email address in the config file.  When an
email address is given for a specific bug report, that address should
override the default address from the configs.

Bug 2) Emacs was spawned to show me the bug report without me
asking. Yet the prompt with option to edit (“E”) follows that anyway,
and it defaults to E!  The default “E” is reasonable if, and only if,
the editor is not triggered before the prompt.  So I had to override
the default action and choose “y”.

Bug 3) It says “Report is unchanged. Edit this report or quit
[E|q|s|?]?”  It’s accurate that the report is unchanged, but not
interesting.  The user should not be told that it was unchanged in a
normal mode of execution.  That should only appear if debugging
reportbug with some extra verbosity.  It’s particularly absurd that
this prompt also defaults to “E”, as if to suggest that the input
report /needs/ to be changed.  It does not, and that’s not the normal
course.  This whole prompt should go away.

Bug 4) It says “Sending empty report anyway...” and it does that
without a prompt.  So after the user receives excessive prompting,
reportbug neglects to prompt to ask the user if it’s okay to send an
empty report. The default action is also stupid. Why should reportbug
even support the possibility of sending an empty report?  That should
never happen.

Bug 5) The fact that reportbug *detects* the report as being empty is
clearly a bug. It just showed me in the editor that my bug report was
clearly not empty.  It showed me a complete report, it knew I did not
change that complete report, then it treats the report as empty.  WTF.

Bug 6) A backup report is saved which is an exact copy of the input
report. Is there cause to think that the input file would be lost in
this operation?  In the case above, the backup file was saved in /tmp/
so the pollution will eventually be removed. But in other executions
I’ve seen the backup report saved in my drafts directory -- the same
directory that holds the input report. So there are multiple verbatim
copies of the same report in that directory, thus pollution that
persists.

(note: some of the noise in the output sample is 

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

[anonymous coward]

Package: firejail
Followup-For: Bug #1015151
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

I did another test, this time ensuring that the profile was read:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 --profile=<(printf '%s\n' 'ignore noroot')\
 lynx -dump 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015151'

Same output:

===8<--
Reading profile /dev/fd/63
…
firejail: util.c:910: create_empty_dir_as_root: Assertion `(s.st_mode & 0) 
== (mode)' failed.
Error: proc 15924 cannot sync with peer: unexpected EOF
Peer 15928 unexpectedly killed (Segmentation fault)
===8<--

So the “ignore noroot” option makes no difference.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015816: firejail: Unable to create a whitelisted config file

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Severity: normal
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

The app “toot” generally needs to create and access this config file:

  ~/.config/toot/config.json

For organizational and backup reasons, I’ve taken these steps
(in effect):

  $ mv ~/.config ~/my_config_files
  $ ln -s ~/my_config_files ~/.config

So ~/.config is a symlink pointing to ~/my_config_files.  To avoid
supplying a symlink to Firejail, it’s launched as follows:

  $ firejail --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
 --whitelist="$(readlink $HOME/.config)"toot/config.json\
 --noblacklist="$(readlink $HOME/.config)"toot/config.json\
 toot login

The readlink command substitution converts the symlink to a full
absolute pathname (not symbolic).  Passing the XDG_CONFIG_HOME
variable ensures that the app itself makes no reference to the
symbolic link, which is confirmed by the app’s output showing:

===8<--
  Creating config file at /home/user/my_config_files/toot/config.json
===8<--

The app runs without issue, but when the app terminates there is no
existing file /home/user/my_config_files/toot/config.json.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015813: toot: User guide missing and man page should mention files & variables used by the app

[anonymous coward]

Package: toot
Version: 0.27.0-1
Severity: minor
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The default config file is apparently ~/.config/toot/config.json, but
this is not mentioned in the man page. The man page should also
mention how to change which config file is used, if possible.  It
should also include environment variables the app
uses. E.g. presumably the app looks at XDG_CONFIG_HOME, which might be
a way to at least change where the config file is rooted (if there is
no specific option).

Apart from the man page, there is:

  /usr/share/doc/toot/changelog.Debian.gz

There should ideally be a complete user guide there.  The upstream
repo directs users to this Cloudflare site:

  https://toot.readthedocs.io/

Cloudflare is an access restricted walled garden that excludes some
users, and it violates the privacy of users who unwittingly go there.
It also violates the FSF Free Documentation criteria, IIRC.  Therefore
the user guide should be imported into /usr/share/doc/toot/.  Apart
from Cloudflare abuses, it’s worth noting that it’s generally useful
to have local offline docs anyway.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

[anonymous coward]

Package: firejail
Followup-For: Bug #1015151
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

I tried the suggestion and it made no difference, but I suspect I have
a separate problem with local profiles.  I first looked through the
man page for a commandline equivalent to “ignore noroot” and found
nothing.  So then I created:

  /home/user/my_symlinked_configs/firejail/my_app.local

with “ignore noroot” along with a whitelisted path and “net
vnet0”. Then I ran:

  $ firejail --profile=/home/user/my_symlinked_configs/firejail/my_app.local\
 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')\
 my_app

(note that the --dns option *must* be on the CLI because unfortunately
 profiles are incapable of command substitution)

It got the segfault as before.  Then I downgraded to version
0.9.64.4-2 again and ran the same command.  The app ran but it acted
as if the whitelisted folder did not exist.  So I have a problem
making profiles work (likely because firejail cannot handle symlinks
properly [or even real dirs that happen to have a symlink]). So
apparently I cannot test the “ignore noroot” profile-only option.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

[anonymous coward]

Package: firejail
Followup-For: Bug #1015151
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

When doing this upgrade:

  0.9.64.4-2 → 0.9.64.4-2+deb11u1

~50+ or so other packages were upgraded at the same time which could
have theoretically changed the Tor middlebox. So more testing was
needed to confirm that the regression was actually in the firejail
pkg. The deb file for the old version was still present, so this was
run:

  $ apt install /var/cache/apt/archives/firejail_0.9.64.4-2_amd64.deb

Then this was run as a test:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')" lynx -dump 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015151'

Indeed firejail worked after the downgrade. I believe this proves the
bug was introduced in firejail version 0.9.64.4-2+deb11u1.  The
following file was created to prevent the buggy version from being
reinstalled before bug 1015151 is fixed:

[/etc/apt/preferences.d/firejail]
===8<--
Package: firejail   

Pin: version 0.9.64.4-2 

Pin-Priority: 999   

===8<--

Reproducing the bug may require the tester to create a Tor
middlebox. The Tor middlebox used in my tests followed this approach:

  
https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/Bylon/TOR_Middlebox

A newer approach to building a Tor middlebox is documented here:

  
https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitlab.com/BylonAkila/TOR_Middlebox.git

This article may have been inspired the above repos:

  
https://web.archive.org/web/20200805082619/https://www.howtoforge.com/how-to-set-up-a-tor-middlebox-routing-all-virtualbox-virtual-machine-traffic-over-the-tor-network

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed:
cgroup no


-- no debconf information

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2+deb11u1
Severity: important
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com, t...@security.debian.org

This upgrade introduced a segmentation fault:

  firejail:amd64 0.9.64.4-2 → 0.9.64.4-2+deb11u1

This is a sample command where it fails:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 lynx -dump "$arbitrary_URL"

The network namespace “vnet0” is a Tor middlebox.  This command
previously had no problem, but now it crashes with the following
output:

===8<--
  firejail: util.c:910: create_empty_dir_as_root: Assertion `(s.st_mode & 
0) == (mode)' failed.
  Error: proc 23396 cannot sync with peer: unexpected EOF
  Peer 23406 unexpectedly killed (Segmentation fault)
===8<--

I have set the severity to /important/ because this defect makes it
impossible to restrict apps to the Tor network. There is no
workaround. Perhaps torsocks will work in cases where the app is
expected to access the network via common system calls, but in cases
where apps bypass systems calls we have a breach.  E.g. java apps tend
to not function with torsocks.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1014794: tootle: (security) Doxxing issue: user agent (“application”) appears in status

[anonymous coward]

Package: tootle
Version: 1.0-alpha2-1
Severity: normal
X-Debbugs-Cc: debbug.too...@sideload.33mail.com

When a status/toot is composed, the user is given no control over what
populates the “application” field. This adds to users’
fingerprints.

I’ve been doxxed and it was revealed that the user agent was a crucial
factor.



-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  elementary-xfce-icon-theme   0.15.2-1
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libsoup2.4-1 2.72.0-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#1014377: tootle: When adding a new account, Tootle fails to launch a browser but remains silent

[anonymous coward]

Package: tootle
Version: 1.0-alpha2-1
Severity: normal
X-Debbugs-Cc: debbug.too...@sideload.33mail.com

Everytime I added a new account, tootle failed to launch a browser for
the Oauth URL. Most normal users would be totally stumped at this
point because the GUI gives no indication that there was a problem.
The terminal output shows this:

===8<--
   ** Message: 09:57:11.695: NewAccount.vala:116: Checking instance URL
   ** Message: 09:57:11.696: NewAccount.vala:131: Registering client
   ** Message: 09:57:11.710: NewAccount.vala:58: Successfully associated MIME 
type for automatic authorization

   ** (tootle:14): CRITICAL **: 09:13:11.710: string_to_string: assertion 'self 
!= NULL' failed
   ** Message: 09:57:13.760: NewAccount.vala:144: OK: Instance registered client
   ** Message: 09:57:13.761: NewAccount.vala:151: Opening permission request 
page
   ** Message: 09:57:13.761: Desktop.vala:7: Opening URI: 
https:///oauth/authorize?scope=read%20write%20follow_type=code_uri=tootle://auth_code_id=
   [36:36:0705/091314.208881:FATAL:zygote_host_impl_linux.cc(204)] Check 
failed: ReceiveFixedMessage(fds[0], kZygoteHelloMessage, 
sizeof(kZygoteHelloMessage), _pid). 
   #0 0x563710d06f09 (/usr/lib/chromium/chromium+0x487cf08)

   Received signal 6
   #0 0x563710d06f09 (/usr/lib/chromium/chromium+0x487cf08)
 r8:   r9: 7ffcf944e3a0 r10: 0008 r11: 
0246
r12: 0f45f989c700 r13: 0f45f989c710 r14: 7ffcf944ee70 r15: 
00a8
 di: 0002  si: 7ffcf944e3a0  bp: 7ffcf944e5f0  bx: 
7f626dce2480
 dx:   ax:   cx: 7f6275021ce1  sp: 
7ffcf944e3a0
 ip: 7f6275021ce1 efl: 0246 cgf: 002b0033 erf: 

trp:  msk:  cr2: 
   [end of stack trace]
   Calling _exit(1). Core file will not be generated.
===8<--

The registration/linking can be completed by manually copy-pasting the
URI in a browser and then giving permission for the browser to run
xdg-open to feed the key back to tootle.  And that’s the workaround.

Note that the only reason I knew to look for that oauth URL is because
I’m familiar with the bitlbee plugin, which is a text based client
with a more manual process.  The user is instructed to open URL X, get
a token/password, and then paste that in a msg to the client app.

Tootle could follow that example when dealing with browser
failures. It could catch the exception when the browser fails to
launch and walk the user through the process.

Possible cause:

The snag in Tootle could be Tor-related.  If someone launches
“torsocks tootle” (because tootle lacks HTTP proxy & SOCKS proxy
options) or they run tootle inside a Tor middlebox, and the user’s
default browser is a script that runs something like “torsocks
firefox” or “ chromium”, that would likely fail
because torsocks would be run within a session that has already been
torsocksified or forced over Tor.

I postulate that there are multiple bugs here:

1. When the browser fails to launch for any reason, tootle neglects to
give GUI dialog that at least minimally informs the user. And ideally
Tootle would go as far as to walk the user through a manual oauth
linking process.

2. There is no HTTP proxy option.

3. There is no SOCKS proxy option.

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  elementary-xfce-icon-theme   0.15.2-1
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libsoup2.4-1 2.72.0-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#1014374: tootle: Tootle only remembers 4 accounts (5th acct can be added but is lost)

[anonymous coward]

Package: tootle
Version: 1.0-alpha2-1
Severity: normal
X-Debbugs-Cc: debbug.too...@sideload.33mail.com

I have been able to add 4 accounts, shutdown the app, relaunch, and
the 4 accounts are remembered just fine.  But when a 5th account is
added, it is accepted and it functions just for the session it was
added in.  After exiting and relaunching, the 5th account is gone-- as
if it never existed. I reattempted and same result. Then I attempted
to add a 5th account for the third time but this time it was for a
different account from a different Mastodon node. Same problem.

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  elementary-xfce-icon-theme   0.15.2-1
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libsoup2.4-1 2.72.0-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#1014373: tootle: Crash when clicking a deleted toot

[anonymous coward]

Package: tootle
Version: 1.0-alpha2-1
Severity: normal
X-Debbugs-Cc: debbug.too...@sideload.33mail.com

Steps to reproduce:

1. Click the search icon and manually enter your own pseudonym by hand (since 
there is no other way to view one’s own timeline)
2. Click the /more/ icon (stacked dots) & choose “delete”
3. Notice that the post that was just deleted remains in the window with no 
indication that the delete was successful
4. Click anywhere in the box showing the deleted message (but avoid clicking on 
something that’s obviously sensitive). This action would normally expand the 
status, but in this case tootle crashes & the window simply disappears.

Note also that it’s human nature to click to expand the deleted toot in order 
to look for some indication that the deletion completed.

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  elementary-xfce-icon-theme   0.15.2-1
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libsoup2.4-1 2.72.0-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#1013442: firejail: cannot spawn emacs from reportbug (sometimes)

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Severity: normal
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

Using Firejail to run reportbug sometimes works and sometimes
doesn’t. When it doesn’t work, it reports that it cannot find
emacs. Sample command:

  $ firejail --env=EDITOR=/usr/bin/emacs\
 --whitelist="$HOME"/.reportbugrc\
 --whitelist=/etc/passwd\
 --whitelist=/var/lib/apt/lists\
 --whitelist=/var/lib/dpkg/status\
 --whitelist=/etc/apt/sources.list\
 --whitelist=/etc/apt/sources.d\
 --whitelist=/etc/debian_version\
 --whitelist="$draft_folder"\
 /usr/bin/reportbug -b --no-check-available --email="$my_email" 
--paranoid --draftpath="$draft_folder" --no-cc

Output:

===8<--
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 8934, child pid 8935
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Child process initialized in 103.73 ms
Please enter the name of the package in which you have found a problem, or type 
'other' to report a more general problem. If you don't know
what package the bug is in, please contact debian-u...@lists.debian.org for 
assistance.
> firejail
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'anonymous coward ' as your from 
address.
Getting status for firejail...
Will send report to Debian (per lsb_release).
Maintainer for firejail is 'Reiner Herrmann '.
Looking up dependencies of firejail...
Getting changed configuration files...

Rewriting subject to 'firejail: profile needed for reportbug'
How would you rate the severity of this problem or report?

1 criticalmakes unrelated software on the system (or the whole system) 
break, or causes serious data loss, or introduces a security
  hole on systems where you install the package.
2 grave   makes the package in question unusable by most or all users, 
or causes data loss, or introduces a security hole allowing
  access to the accounts of users who use the package.
3 serious is a severe violation of Debian policy (that is, the problem 
is a violation of a 'must' or 'required' directive); may or
  may not affect the usability of the package. Note that 
non-severe policy violations may be 'normal,' 'minor,' or
  'wishlist' bugs. (Package maintainers may also designate 
other bugs as 'serious' and thus release-critical; however, end
  users should not do so.). For the canonical list of issues 
deserving a serious severity you can refer to this webpage:
  http://release.debian.org/testing/rc_policy.txt .
4 important   a bug which has a major effect on the usability of a package, 
without rendering it completely unusable to everyone.
5 does-not-build  a bug that stops the package from being built from source. 
(This is a 'virtual severity'.)
6 normal  a bug that does not undermine the usability of the whole 
package; for example, a problem with a particular option or menu
  item.
7 minor   things like spelling mistakes and other minor cosmetic errors 
that do not affect the core functionality of the package.
8 wishlistsuggestions and requests for new features.

Please select a severity level: [normal] 8
invalid report type None, defaulting to debbugs
Spawning emacs...
sh: 1: /usr/bin/emacs: not found
Warning: possible error exit from emacs: 32512
No changes were made in the editor.
Report will be sent to Debian Bug Tracking System 
Submit this report on firejail (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? q
Saving a backup of the report at 
/tmp/reportbug-firejail-backup-20220623182047-x0toa9s3
Bug report written to $draft_folder/reportbug-firejail-20220623182039-7kfg55kv
Hint: You can resume an unsent report using reportbug -r TEMPFILE
Thank you for using reportbug

Parent is shutting down, bye...
===8<--

I saw this command correctly spawn emacs several times all on the same
day. Another day (after a reboot), reportbug running inside of firejail
consistently fails to spawn emacs. Rebooting should not have made a
difference.  I don’t see how the state of the system can influence
this.  I’m write this bug report herein using reportbug without
firejail, and reportbug spawns emacs fine every time when firejail is
not involved.

Note that there is another problem: before failing to find e

Bug#810933: reportbug: possible workaround

[anonymous coward]

Package: reportbug
Version: 7.10.3
Followup-For: Bug #810933
X-Debbugs-Cc: bug810...@sideload.33mail.com

I concur that SMTP proxying would be useful.

I also have a workaround using firejail. Firejail makes it possible to
restrict an app to a network namespace. So if you can configure your
proxy to be a network namespace that appears in
/proc/sys/net/ipv4/conf/, then firejail can do the rest. Restricting
apps to use Firejail is generally a good security practice anyway.

I managed to create a network (proxynet0). So running reportbug in
firejail to force use of proxynet0 looks like this:

===8<--
  $ firejail --net=proxynet0\
 --dns="$(ip address show dev proxynet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 --whitelist="$HOME"/.reportbugrc\
 --whitelist="$draft_folder"\
 --whitelist="$app_specific_configs"\
 --whitelist=/etc/passwd\
 --whitelist=/var/lib/apt/lists/\
 --whitelist=/var/lib/dpkg/status\
 --whitelist=/etc/apt/sources.list\
 --whitelist=/etc/apt/sources.d\
 reportbug --draftpath="$draft_folder" --no-cc

  Reading profile /etc/firejail/default.profile
  Reading profile /etc/firejail/disable-common.inc
  Reading profile /etc/firejail/disable-passwdmgr.inc
  Reading profile /etc/firejail/disable-programs.inc

  ** Note: you can use --noprofile to disable default.profile **

  Parent pid 25268, child pid 25271

  InterfaceMACIP   Mask Status
  lo  127.0.0.1255.0.0.0UP
  eth0…
  Default gateway…
  DNS server…

  Child process initialized in 1877.72 ms

  (reportbug:11): dbind-WARNING **: 10:06:51.011: Couldn't connect to 
accessibility bus: Failed to connect to socket /tmp/dbus-jLt9P0UVaA: Connection 
refused
  Please enter the name of the package in which you have found a problem, or 
type 'other' to report a more general problem. If you don't know
  what package the bug is in, please contact debian-u...@lists.debian.org for 
assistance.
  > 
===8<--

Be sure to also add a --whitelist path for the config file of the app
the bug is reported on because reportbug will try to access that as
well. The placeholder “$app_specific_configs” was used above.

The reportbug app uses dbus for accessbility features, which firejail
blocks by default. The warning can be ignored if you don’t need
accessibility features. Otherwise Firejail offers the following
options to make dbus accessible:

  --dbus-log=file
  --dbus-system=filter|none
  --dbus-system.broadcast=name=[member][@path]
  --dbus-system.call=name=[member][@path]
  --dbus-system.log
  --dbus-system.own=name
  --dbus-system.see=name
  --dbus-system.talk=name
  --dbus-user=filter|none
  --dbus-user.broadcast=name=[member][@path]
  --dbus-user.call=name=[member][@path]
  --dbus-user.log
  --dbus-user.own=name
  --dbus-user.talk=name
  --dbus-user.see=name

I’m not sure which dbus restriction needs to be lifted (hence why this
is a half-baked workaround). I tried adding this:

  --dbus-system=filter 
--dbus-system.call=org.freedesktop.DBus=org.freedesktop.DBus.*@/org/gnome/desktop/a11y/

but got:

  Error: Invalid dbus-system.call rule: 
org.freedesktop.DBus=org.freedesktop.DBus.*@/org/gnome/desktop/a11y/

Anyway, that’s typically not needed. Hopefully this workaround helps
someone looking to proxy their reportbug SMTP traffic.

Note as well that the info in this post can be useful if someone wants
to introduce a reportbug profile into the firejail project.


-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="text"

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends 

Bug#1013254: reportbug: the --subject= CLI parameter ignored when -N is used

[anonymous coward]

Package: reportbug
Version: 7.10.3
Severity: normal
X-Debbugs-Cc: debbug.report...@sideload.33mail.com

This command was run:

  $ reportbug -b --no-check-available -N 881955 --email="$email_address" 
--paranoid --draftpath="$my_draft_path" --subject='feedback' --no-cc

after having read this in the man page:

  -s SUBJECT, --subject=SUBJECT
 Set the subject of the bug report (i.e. a brief explanation of the
 problem, less than 60 characters).  If you do not specify this switch,
 you will be prompted for a subject.

The --subject parameter is ignored and reportbug prompts the user for a subject 
as follows:

  ===8<--
  …
  Looking up dependencies of reportbug...
  Getting status for related package python3-reportbug...
  Looking up 'depends' of related package python3-reportbug...
  Looking up 'suggests' of related package python3-reportbug...
  Getting changed configuration files...

  Please provide a subject for your response.
  [Re: reportbug: Subject header encoding not RFC2047-compliant (too long)]> 
  Does this bug still exist in version 7.10.3 of this package [y|N|q|?]? q
  …
  ===8<--

In this situation where a valid (<60 chars) subject is supplied, either:

  1. the supplied subject field should be used without prompting

  «OR»

  2. the prompt’s default should be the supplied subject with an option to 
override with the OP’s subject line.

In any case, it’s certainly wrong to ignore the --subject parameter
when a valid subject is supplied.

BTW, I was half-tempted to mark this as an accessibility issue because
someone who is handicapped might use the CLI options heavily to
mitigate the question/answer process. But I’m not sure if the impact
is significant.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="text"

** /home/blee/.reportbugrc:
reportbug_version "7.10.3"
mode advanced
ui text
realname "anonymous coward"
no-cc
list-cc-me
smtphost reportbug.debian.org

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3
ii  gnupg   2.2.27-2
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

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#1013229: wvdial: Verbose PPP debugging output cannot be enabled

[anonymous coward]

Package: wvdial
Version: 1.61-5
Severity: normal
X-Debbugs-Cc: debbug.wvd...@sideload.33mail.com

Connecting using a GSM mobile broadband USB modem succeeds but there
are errors during the PPP handshake.  When the “debug” option is
uncommented in /etc/ppp/options as well as the “-detach” option, the
ppp logging is no more verbose than without those options. They seem
to take no effect. Is wvdial launching pppd in a way that interferes
with parameters in /etc/ppp/options?

This is the output both with and without debug info enabled:

/var/log/messages:

  ===8<--
  $timestamp $host pppd[84797]: pppd 2.4.9 started by $user, uid 0
  $timestamp $host pppd[84797]: Using interface ppp0
  $timestamp $host pppd[84797]: Connect: ppp0 <--> /dev/ttyUSB0
  $timestamp $host pppd[84797]: LCP: timeout sending Config-Requests
  $timestamp $host pppd[84797]: Connection terminated.
  $timestamp $host pppd[84797]: Modem hangup
  $timestamp $host pppd[84797]: Exit.
  -->8===

/etc/wvdial.conf:

  ===8<--
  [Dialer Defaults]
  StupidMode = 1
  Modem Type = Analog Modem
  Baud = 460800
  New PPPD = yes
  Modem = /dev/ttyUSB0
  ISDN = 0
  Init1 = ATZ
  Init2 = ATQ0 V1 E1 S0=0   +FCLASS=0

  [Dialer Orange]
  Init3 = AT+CGDCONT=1,"IP","mworld.be",,0,0
  Phone = *99#
  Mcc = 206
  Mnc = 10
  Username = ''
  Password = ''
  Carrier Check = off
  -->8===

/etc/ppp/options:

  ===8<--
  asyncmap 0
  auth
  crtscts
  lock
  hide-password
  modem
  debug
  -detach
  nodetach
  lcp-echo-interval 30
  lcp-echo-failure 4
  noipx
  -->8===

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wvdial depends on:
ii  debconf [debconf-2.0]   1.5.77
ii  libc6   2.31-13
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libstdc++6  10.2.1-6
ii  libuniconf4.6   4.6.1-15
ii  libwvstreams4.6-base4.6.1-15
ii  libwvstreams4.6-extras  4.6.1-15
ii  ppp 2.4.9-1+1

wvdial recommends no packages.

wvdial suggests no packages.

-- debconf information excluded

Bug#444714: wvdial: comments start with hash (“#”)

[anonymous coward]

Package: wvdial
Version: 1.61-5
Followup-For: Bug #444714
X-Debbugs-Cc: bug639...@sideload.33mail.com

Indeed the README still shows semicolons to designate comments. So the
README still needs to be updated. I find that the hash symbol works
for comments so that’s the workaround.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wvdial depends on:
ii  debconf [debconf-2.0]   1.5.77
ii  libc6   2.31-13
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libstdc++6  10.2.1-6
ii  libuniconf4.6   4.6.1-15
ii  libwvstreams4.6-base4.6.1-15
ii  libwvstreams4.6-extras  4.6.1-15
ii  ppp 2.4.9-1+1

wvdial recommends no packages.

wvdial suggests no packages.

-- debconf information excluded

Bug#639368: ppp: confirmed verbosity problem in v. 2.4.9-1+1

[anonymous coward]

Package: ppp
Version: 2.4.9-1+1
Followup-For: Bug #639368
X-Debbugs-Cc: bug639...@sideload.33mail.com

When the following options are supplied in /etc/ppp/options prior to
running wvdial:

* debug
* -detach
* nodetach

output is normal (non-verbose). It’s unclear if this is the same bug
as the 11 year old bug (639368) because the OP reports no output after
the “pppd 2.4.5 started by root” line. Whereas I’m seeing a little
more output but certainly not verbose. So this report was filed
upstream:

  https://github.com/ppp-project/ppp/issues/352



-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ppp depends on:
ii  libc6   2.31-13
ii  libcrypt1   1:4.4.18-4
ii  libpam-modules  1.4.0-9
ii  libpam-runtime  1.4.0-9
ii  libpam0g1.4.0-9
ii  libpcap0.8  1.10.0-2
ii  libssl1.1   1.1.1k-1
ii  libsystemd0 247.3-6
ii  procps  2:3.3.17-5

ppp recommends no packages.

ppp suggests no packages.

-- Configuration Files:
/etc/ppp/options changed [not included]

-- no debconf information

Bug#1012803: libmariadb-java: Missing AwsIamCredentialPlugin error (libmariadb-java stable(2.7.2-1) and testing(2.7.4-1))

[anonymous]

Package: libmariadb-java
Version: 2.7.4-1
Severity: important
X-Debbugs-Cc: anonymouse743...@gmail.com

Java 17 refuses to use the jdbc driver for mariadb because of a missing
plugin

This error persists on both version 2.7.2-1 and 2.7.4-1, but is
fixed upstream in the jar file downloaded from mariadb.com for versions
3.0.5 and 2.7.5.

Specific error reproduced in java and jshell binaries:

java --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/ --add-modules 
org.mariadb.jdbc -ea TestJDBC 
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

jshell --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/ --add-modules 
org.mariadb.jdbc -ea TestJDBC 
Launching JShell execution engine threw: FailOverExecutionControlProvider: 
FAILED: 0:jdi:hostname(127.0.0.1) --
  Exception: java.lang.IllegalArgumentException: Error occurred during 
initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

  
jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:111)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  
jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
  
jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
  Exception: java.lang.InternalError: Failed remote launch: 
java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: 
VM initialization failed for: /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
--add-modules org.mariadb.jdbc --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4 -Xdebug 
-Xrunjdwp:transport=dt_socket,address=localhost:50629,suspend=y 
jdk.jshell.execution.RemoteExecutionControl 35629 @ 
com.sun.jdi.CommandLineLaunch (defaults: 
home=/usr/lib/jvm/java-17-openjdk-amd64, options=, main=, suspend=true, 
quote=", vmexec=java) -- {home=home=/usr/lib/jvm/java-17-openjdk-amd64, 
options=options=--add-modules org.mariadb.jdbc --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4, 
main=main=jdk.jshell.execution.RemoteExecutionControl 35629, 
suspend=suspend=true, quote=quote=", vmexec=vmexec=java}
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:110)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  
jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
  cause: java.util.concurrent.ExecutionException: 
com.sun.jdi.connect.VMStartException: VM initialization failed for: 
/usr/lib/jvm/java-17-openjdk-amd64/bin/java --add-modules org.mariadb.jdbc 
--module-path /usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4 
-Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:50629,suspend=y 
jdk.jshell.execution.RemoteExecutionControl 35629
FailOverExecutionControlProvider: FAILED: 2:jdi --
  Exception: java.lang.IllegalArgumentException: Error occurred during 
initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

  
jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:111)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  

Bug#966636: asterisk: after upfgrade from buster, no sip connections succeed due to silent ls 1.3 requirement

[anonymous envelope]

Package: asterisk
Version: 1:16.10.0~dfsg-1
Severity: normal

Dear Maintainer,

after upgrading the asterisk version from buster to testing, the pjsip channel 
no longer accepts any connections, due to:

SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <337678594> 

as it turns out, this is because the new asterisk version enforces a minimum 
tls version of 1.3, i.e., clients connecting with tls 1.2 (all of them for us, 
as this includes android) can no longer connect.

There doesn't seem to be a way to confifgure this in pjsip.conf, at least not a 
documented way, and even drastic workarounds such as method=sslv23 do not help.

I think an enforced tls 1.3 minimum version is too harsh.

For reference, here is the transport configuration that works with asterisk 
16.2 in buster:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0
cert_file=...
priv_key_file=...
method=tlsv1

-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages asterisk depends on:
ii  adduser  3.118
ii  asterisk-config  1:16.10.0~dfsg-1
ii  asterisk-core-sounds-en  1.6.1-1
ii  asterisk-modules 1:16.10.0~dfsg-1
ii  libc62.31-2
ii  libcap2  1:2.25-2
ii  libcrypt11:4.4.16-1
ii  libedit2 3.1-20181209-1
ii  libjansson4  2.12-1
ii  libpopt0 1.16-12
ii  libsqlite3-0 3.27.2-3
ii  libssl1.11.1.1d-0+deb10u3
ii  libsystemd0  241-7~deb10u4
ii  liburiparser10.9.1-1
ii  libuuid1 2.33.1-0.1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  lsb-base 10.2019051400

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
ii  asterisk-voicemail [asterisk-voicemail-storage]  1:16.10.0~dfsg-1
ii  sox  14.4.2+git20190427-1

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
pn  asterisk-dev 
pn  asterisk-doc 
ii  asterisk-ooh323  1:16.10.0~dfsg-1
ii  asterisk-opus13.7+20171009-2
pn  asterisk-vpb 

-- no debconf information

Bug#961648: texlive-latex-base: "LaTeX Error: Command \bbl@foreign@x already defined." when using babel

[Anonymous]

Package: texlive-latex-base
Version: 2020.20200522-1
Severity: important

   * What led up to the situation?

Updating to the latest version of texlive available in Debian unstable

-
apt policy texlive-latex-base
texlive-latex-base:
  Installed: 2020.20200522-1
  Candidate: 2020.20200522-1
  Version table:
 *** 2020.20200522-1 500
500 http://ftp2.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
-

and then trying to compile the following document:

-
\RequirePackage{latexbug}
\documentclass{minimal}

%\usepackage[ngerman]{babel}
\usepackage{babel}

\begin{document}
Test
\end{document}
-

leads to the following error message:

-
$ pdflatex -recorder mwe.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./mwe.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-04-06>
(/usr/share/texlive/texmf-dist/tex/latex/latexbug/latexbug.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001/05/25 Standard LaTeX minimal class
) (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def

! LaTeX Error: Command \bbl@foreign@x already defined.
   Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.745   \endgroup}

? X
No pages of output.
Transcript written on mwe.log.
-

-
$ cat mwe.fls
PWD /tmp/babel_debug
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /home/foo/.texlive2020/texmf-var/web2c/pdftex/pdflatex.fmt
INPUT mwe.tex
OUTPUT mwe.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/latexbug/latexbug.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/latexbug/latexbug.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/minimal.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/minimal.cls
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
-

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried reinstalling the packages.
   * What was the outcome of this action?
It did not resolve the issue.



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1591 May 26 11:30 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Apr 17 03:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 May 22 14:37 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 May 22 14:37 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Apr 20 06:26 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 May 22 14:37 /usr/share/texmf/web2c/fmtutil.cnf -> 

Bug#934707: Temporal fix-up

[Anonymous Legionus]

As temp workaround, inspect policy files in /etc/dbus-1/system.d and create
missed users. One liner:
for i in $(awk 'BEGIN{FS="user=\"|\">"}; $0 ~ /policy user=/{print $2}'
/etc/dbus-1/system./* | sort -u); do [ "x$(getent passwd $i)" = "x" ] && {
useradd -Mr $i && echo System user $i created; }; done

Bug#905674: Public Code Public Money?

[Anonymous]

This is a critical issue. Would you recognize the need of a citation notice if 
developers publish a list of donors?

Sincerely yours

Bug#886798: Ceci est mon dernier avertissement! 886...@bugs.debian.org

[Anonymous - Ethelene]

DERNIER AVERTISSEMENT 886...@bugs.debian.org!

Je vous laisse les 72 dernières heures pour effectuer le paiement avant
d'envoyer une vidéo avec votre masturbation à tous vos amis.

La dernière fois que vous avez visité un site Web pornographique avec des
adolescents, vous avez téléchargé et installé le logiciel que j'ai
développé.

Mon programme a allumé votre appareil photo et enregistré le processus de
votre masturbation. Mon logiciel a également téléchargé toutes vos
listes de contacts et une liste de vos amis sur Facebook.

J'ai à la fois le wmh42ild.mpg avec votre masturbation ainsi qu'un fichier
avec tous vos contacts sur mon disque dur.
Vous êtes très pervers!

Si vous voulez que je supprime les deux fichiers et garde le secret, vous
devez m'envoyer le paiement Bitcoin. Je vous donne 72 dernières heures.
Si vous ne savez pas comment envoyer des Bitcoins, visitez Google.

Envoyez immédiatement 1000 EUR à cette adresse Bitcoin:
3CZVtQLBxAXjfqPHx5t45yk35iDnQ8q7A9

1 BTC = 3033 EUR, envoyez donc exactement 0.337630 BTC à l'adresse
ci-dessus.

N'essayez pas de me tromper! Dès que vous ouvrez cet email, je saurai que
vous l'avez ouvert.

Cette adresse Bitcoin est uniquement liée à vous. Je saurai donc si vous
avez envoyé le montant correct.
Si vous n'envoyez pas le paiement, je vais envoyer votre vidéo de
masturbation à tous vos amis de votre liste de contacts que j'ai piratés.

Voici à nouveau les détails du paiement:

Envoyez 0.337630 BTC à cette adresse Bitcoin:
3CZVtQLBxAXjfqPHx5t45yk35iDnQ8q7A9

Vous pouvez rendre visite à la police, mais personne ne vous aidera.
Je ne vis pas dans ton pays. J'ai traduit ce message dans votre langue pour
que vous puissiez comprendre.

Ne me trompe pas! N'oubliez pas la honte et si vous ignorez ce message,
votre vie sera ruinée.

J'attends votre paiement Bitcoin.

Ethelene
Anonymous Hacker

Bug#904302: That's a free software issue!

[Anonymous]

Dear Chair

reasoning of this policy is really absurd. The opposite is actually
true. Usage of vendor patches should be encouraged downstream. That's a
free software issue! The goal is to facilitate patches. 

If Debian want patches it has to support this process with tools. The
attitude Debian owns all source packages is wrong. Sharing source
packages among different vendors is more efficient. Different patch
series may be the best solution in some cases. This policy decision only
breaks the workflow. Derivatives have to duplicate the whole source
tree. It is a huge burden and waste of resources.

Patch series are supported by git-am and git-format-patch. There is no
better approach to incorporate patches. I fear circumventing the policy
with "QUILT_SERIES=debian/patches/$(dpkg-vendor --query vendor).patch
quilt push -a" in debian/rules. The patch series separates vendor
specific code properly. If policy is against vendor specific code it has
to accept patch series at least. They are a last resort to make
independent patches.

Builds for different vendors are not a standard use case at all. Identic
source after unpacking is possible with dpkg-source --skip-patches
anyways. A hint about different series during unpacking can be useful
but changing policy because someone was confused is unbelievable. Usage
of the right tools is good practice and should not forced with power.

The decision is based on wrong assumptions and implications, arguments
are weak, valid objections ignored. This is abusing Debian policy and
technical committee against free software! Debian needs patches
regardless of policy.

Yours truly

Bug#898214: Package: d52

[Anonymous]

Package: d52

The given homepage URL points to digiwana and even archive.org has no useable 
copy.

--8<--
Package: d52
Source: d52 (3.4.1-1.1)
Version: 3.4.1-1.1+b2
Installed-Size: 208
Maintainer: Uwe Hermann 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description-en: Disassembler for 8052, 8048/8041, and Z80/8080/8085 code
 Disassembler for microcontroller code which supports various targets.
 .
 This package contains:
  - d52: a disassembler for 8052 code,
  - d48: a disassembler for 8048/8041 code,
  - dz80: a disassembler for Z80/8080/8085 code.
Description-md5: 0d826c987151f46e1e73b76928882a59
Homepage: http://home.pacbell.net/theposts
Tag: devel::machinecode, implemented-in::c, role::program
Section: devel
Priority: extra
Filename: pool/main/d/d52/d52_3.4.1-1.1+b2_amd64.deb
Size: 56680
MD5sum: 5fc45f86e672e042a70e6c70df1c3356
SHA256: 40e459b81136338d66040a845b225a30bb825d7a170c629eeab3cdcb8b8ce783
-->8--

Bug#824827: mixmaster: hold on..

[Anonymous]

Package: mixmaster
Version: 3.0.0-8.1
Followup-For: Bug #824827

> I know that. What you fail to realise is that the mixmaster
> *specification* makes no mention of 4k keys!

Then why would you claim it's not a bug for mixmaster to write packets
for out-of-spec hosts?  If a host doesn't conform to mixmaster specs,
then it's not a mixmaster node, thus mixmaster shouldn't be talking to
it.  You might as well design it to create messages for FTP servers
(which are also non-compliant but equally functional as the current
state).

Bug#813158: [bug #52349] Seg fault with wget -O - smxi.org/sm/sm-versions

[anonymous]

Follow-up Comment #3, bug #52349 (project wget):

Hi Darshit.  I'm the guy who reported this bug to Noël Köthe/Debian.

It looks like this bug fix will be in the next release. Would it be possible
to patch 1.19.2? I've downgraded, and that seems to be a fine workaround for
the sgfxi script that the bug affected, but the script dev isn't convinced,
and we're trying to address a couple of issues, and would like to check this
one off the list.

Thanks.  Chris M

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#881193: tp-smapi-dkms: module does not autoload (and incomplete docs)

[Anonymous]

Package: tp-smapi-dkms
Version: 0.42-1
Severity: normal

Dear Maintainer,

After installing, the package, I was able to manually run modprobe
tp_smapi and verify that it works.  After rebooting, the module was
not loaded.  I believe hardware drivers are loaded automatically when
there is an attempt to access the device.  So AFAIK this should be the
case for tp_smapi.  I noticed gkrellm-thinkbat failed after the
reboot.  So I ran "journalctl -b" which shows:

  .. sysfsutils[805]: Setting sysfs variables...unknown attribute 
devices/platform/smapi/BAT0/start_charge_thresh ... fail
  .. sysfsutils[805]: unknown attribute 
devices/platform/smapi/BAT0/stop_charge_thresh ... failed!

If this is not a module that should load on demand, then the installer
should probably be configuring the system to load it unconditionally.
Or failing that, the documentation is lacking and needs to cover this.
I'm noticing many ways to load a module:

  1) Add it to /etc/modules
  2) Add it to /etc/modprobe.d/dkms.conf
  3) echo 'tp-smapi' > /etc/modules-load.d/tp-smapi.conf
  4) create a file in /etc/init.d that includes "modprobe tp_smapi"
  5) create /etc/systemd/system/tp_smapi_set_battery_thresholds.service:

 [Unit]
 Description=Set Battery Charge Thresholds by tp_smapi

 [Service]
 Type=oneshot
 ExecStart=/usr/sbin/set_battery_thresholds
 RemainAfterExit=yes

 [Install]
 WantedBy=multi-user.target

Which way is the standard practice on Debian?  I suspect the
tp_smapi_set_battery_thresholds.service file above should be part of
the package.  Or is dkms going to be more accepted in the future?

There's also a possible documentation clash with sysfsutil.

(1) Sysfsutil suggests (by example) including these lines in
/etc/sysfs.conf:

  devices/platform/smapi/BAT0/start_charge_thresh=40
  devices/platform/smapi/BAT0/stop_charge_thresh=85

(2) However, that seems redundant with these instructions in README:

  # echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh
  # echo 70 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh

Approach (1) seems the most sensible - most users will want these
settings to persist, and I'm guessing approach (2) is temporary.  But
the README only mentions approach (2).  IMO the README should be
updated to show either both approaches or just approach (1).  It
already references http://thinkwiki.org/wiki/tp_smapi, so users going
further with experimentation can learn about approach (2) there.

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1510159819
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1510159819
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tp-smapi-dkms depends on:
ii  dkms  2.3-2

tp-smapi-dkms recommends no packages.

tp-smapi-dkms suggests no packages.

Bug#792580: chromium: privacy-concious ppl want ungoogled-chromium

[Anonymous]

Control: Tags 792580 security

Dear Martín and others,

You don't want the official Debian version of Chromium.  Instead you
want "ungoogled-chromium".  See:

  https://github.com/Eloston/ungoogled-chromium

Bug#880858: cclive: mirror the --prefer-free-formats option from youtube-dl

[Anonymous]

Package: cclive
Version: 0.9.3-0.1+b2
Severity: wishlist
Control: tags -1 stretch

Dear Maintainer,

The problem with the current "--stream best" option is that it
includes proprietary video formats like MP4.  Note that youtube-dl has
the very useful option "--prefer-free-formats".

Please add a keyword like "bestfree" to limit the formats to
freedom-respecting formats like Matroska ("webm" aka i43), and then
take the best quality of that shortlist.  Likewise, it would also be
useful to have a "smallestfree" keyword.


Thank you.


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509794646 WARNING 
torsocks[4109]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509794646 WARNING torsocks[4111]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cclive depends on:
ii  dpkg1.18.24
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u1
ii  libcurl3-gnutls 7.52.1-5+deb9u2
ii  libgcc1 1:6.3.0-18
ii  libglib2.0-02.50.3-2
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libquvi-0.9-0.9.3   0.9.3-1.2
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.3.0-18

cclive recommends no packages.

cclive suggests no packages.

-- debconf information excluded

Bug#825864: sedutil should be considered basic and somewhat essential

[Anonymous]

Package: wnpp
Followup-For: Bug #825864
control: tags 825864 stretch security

I'm wondering why the lack of action on this.. should this bug have
been sent to the sponsorship-requests instead, perhaps?

I was half-tempted to elevate the severity to important, b/c it is a
security issue to be unable to lock and unlock hard drives.  I think
it should possibly be considered more important than having Donkey
Kong installed, for example.

Bug#880734: cclive: mirror the --prefer-free-formats option from youtube-dl

[Anonymous]

Package: cclive
Version: 0.9.3-0.1+b2
Severity: wishlist
Control: tags -1 stretch

Dear Maintainer,

The problem with the current "--stream best" option is that it
includes proprietary video formats like MP4.  Note that youtube-dl has
the very useful option "--prefer-free-formats".

Please add a keyword like "bestfree" to limit the formats to
freedom-respecting formats like Matroska ("webm" aka i43), and then
take the best quality of that shortlist.  Likewise, it would also be
useful to have a "smallestfree" keyword.


Thank you.


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509794646 WARNING 
torsocks[4109]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509794646 WARNING torsocks[4111]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cclive depends on:
ii  dpkg1.18.24
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u1
ii  libcurl3-gnutls 7.52.1-5+deb9u2
ii  libgcc1 1:6.3.0-18
ii  libglib2.0-02.50.3-2
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libquvi-0.9-0.9.3   0.9.3-1.2
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.3.0-18

cclive recommends no packages.

cclive suggests no packages.

-- debconf information excluded

Bug#880725: cclive: cclive -S hangs. Also, stream IDs are undocumented

[Anonymous]

Package: cclive
Version: 0.9.3-0.1+b2
Severity: normal
Control: tags -1 stretch

Dear Maintainer,

This report includes two bugs and one related enhancement request--

*bug (functional)*

  ATM supplying a "-S" without an URL causes cclive to hang, which is
  a bug.  Even though the syntax is wrong, it should print an error
  message, not hang.

*bug (documentation)*

  The manpage shows this:
  
] REPORTING BUGS
]Report bugs to the cclive-devel mailing list 

]where the development and the maintenance is primarily done.
]You do not have to be subscribed to the list to send a message 
there.

  That mailing list is dead.  There has been no activity for months
  according to the archives, and the final months that have posts are
  spam.  The list seems to no longer be accepting messages, hence why
  the bug report herein is sent to debian when really these are
  upstream issues.

*enhancement request*

  Stream IDs like "small_3gpp_i36_180p" are a bit cryptic (although an
  improvement over past versions), and it's very difficult to find
  documentation on them.  Even knowing that I need a
  "QUVI_MEDIA_STREAM_PROPERTY_ID" as well as what some of the IDs look
  like, web searches for this information is frustrating and futile.

  Please put a reference in the manpage to where users can get a list
  of stream IDs -- or perhaps even better, smarten the "-S" command so
  that it lists all known stream IDs with descriptions if no URL is
  supplied (which would fix the above mentioned bug).


Thank you!


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509794646 WARNING 
torsocks[4109]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509794646 WARNING torsocks[4111]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cclive depends on:
ii  dpkg1.18.24
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u1
ii  libcurl3-gnutls 7.52.1-5+deb9u2
ii  libgcc1 1:6.3.0-18
ii  libglib2.0-02.50.3-2
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libquvi-0.9-0.9.3   0.9.3-1.2
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.3.0-18

cclive recommends no packages.

cclive suggests no packages.

-- debconf information excluded

Bug#880724: cclive: cclive -S hangs. Also, stream IDs are undocumented

[Anonymous]

Package: cclive
Version: 0.9.3-0.1+b2
Severity: normal
Control: tags -1 stretch

Dear Maintainer,

This report includes two bugs and one related enhancement request--

*bug (functional)*

  ATM supplying a "-S" without an URL causes cclive to hang, which is
  a bug.  Even though the syntax is wrong, it should print an error
  message, not hang.

*bug (documentation)*

  The manpage shows this:
  
] REPORTING BUGS
]Report bugs to the cclive-devel mailing list 

]where the development and the maintenance is primarily done.
]You do not have to be subscribed to the list to send a message 
there.

  That mailing list is dead.  There has been no activity for months
  according to the archives, and the final months that have posts are
  spam.  The list seems to no longer be accepting messages, hence why
  the bug report herein is sent to debian when really these are
  upstream issues.

*enhancement request*

  Stream IDs like "small_3gpp_i36_180p" are a bit cryptic (although an
  improvement over past versions), and it's very difficult to find
  documentation on them.  Even knowing that I need a
  "QUVI_MEDIA_STREAM_PROPERTY_ID" as well as what some of the IDs look
  like, web searches for this information is frustrating and futile.

  Please put a reference in the manpage to where users can get a list
  of stream IDs -- or perhaps even better, smarten the "-S" command so
  that it lists all known stream IDs with descriptions if no URL is
  supplied (which would fix the above mentioned bug).


Thank you!


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509794646 WARNING 
torsocks[4109]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509794646 WARNING torsocks[4111]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cclive depends on:
ii  dpkg1.18.24
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u1
ii  libcurl3-gnutls 7.52.1-5+deb9u2
ii  libgcc1 1:6.3.0-18
ii  libglib2.0-02.50.3-2
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libquvi-0.9-0.9.3   0.9.3-1.2
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.3.0-18

cclive recommends no packages.

cclive suggests no packages.

-- debconf information excluded

Bug#824827: mixmaster: hold on..

[Anonymous]

Package: mixmaster
Version: 3.0.0-8.1
Followup-For: Bug #824827

Dear Maintainer,

> Mixmaster does not support 4k keys.
> 
> It is not designed to support 4k keys.
> 
> Closing the bug.

Hold on.. even if the project has decided that 1k keys is the way
forward, 2 bugs still remain:

bug 1: mixmaster autonomously chooses to use a (so-called) unsupported
   chain.  If 4k keys are not supported, the tool shouldn't
   attempt to chain through unusable nodes in the first place.

bug 2: the error message "encryption failed" is absurdly vague.  In
the absence of a fix for bug 1, the tool should say something
meaningful like:

  "cannot route through dizum because its keys are too large"

Please reopen.

Note this is my *6th* attempt to send this reply -- I am sending it
using mixmaster.

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508766057 WARNING 
torsocks[12002]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508766057 WARNING torsocks[12004]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mixmaster depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  libmailtools-perl  2.18-1
ii  libncurses56.0+20161126-1+deb9u1
ii  libpcre3   2:8.39-3
ii  libssl1.0.21.0.2l-2
ii  libtinfo5  6.0+20161126-1+deb9u1
ii  libwww-perl6.15-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages mixmaster recommends:
ii  postfix [mail-transport-agent]  3.1.6-0+deb9u1

Versions of packages mixmaster suggests:
ii  mutt  1.7.2-1

-- Configuration Files:
/etc/mixmaster/allpingers.txt changed:
[austria]
base= https://www.tahina.priv.at/~cm/stats/
rlist   = https://www.tahina.priv.at/~cm/stats/rlist.txt
mlist   = https://www.tahina.priv.at/~cm/stats/mlist.txt
rlist2  = https://www.tahina.priv.at/~cm/stats/rlist2.txt
mlist2  = https://www.tahina.priv.at/~cm/stats/mlist2.txt
rlist_html  = https://www.tahina.priv.at/~cm/stats/rlist.html
mlist_html  = https://www.tahina.priv.at/~cm/stats/mlist.html
rlist2_html = https://www.tahina.priv.at/~cm/stats/rlist2.html
mlist2_html = https://www.tahina.priv.at/~cm/stats/mlist2.html
pgpring = https://www.tahina.priv.at/~cm/stats/pgp-all.asc
pgpring_rsa = https://www.tahina.priv.at/~cm/stats/pgp-rsa.asc
mixring = https://www.tahina.priv.at/~cm/stats/pubring.mix
type2list   = https://www.tahina.priv.at/~cm/stats/type2.list
[deuxpi]
base= http://www.deuxpi.ca/echolot/
rlist   = http://www.deuxpi.ca/echolot/rlist.txt
mlist   = http://www.deuxpi.ca/echolot/mlist.txt
rlist2  = http://www.deuxpi.ca/echolot/rlist2.txt
mlist2  = http://www.deuxpi.ca/echolot/mlist2.txt
rlist_html  = http://www.deuxpi.ca/echolot/rlist.html
mlist_html  = http://www.deuxpi.ca/echolot/mlist.html
rlist2_html = http://www.deuxpi.ca/echolot/rlist2.html
mlist2_html = http://www.deuxpi.ca/echolot/mlist2.html
pgpring = http://www.deuxpi.ca/echolot/pgp-all.asc
pgpring_rsa = http://www.deuxpi.ca/echolot/pgp-rsa.asc
mixring = http://www.deuxpi.ca/echolot/pubring.mix
type2list   = http://www.deuxpi.ca/echolot/type2.list
[frell]
base= http://echolot.theremailer.net/
rlist   = http://echolot.theremailer.net/rlist.txt
mlist   = http://echolot.theremailer.net/mlist.txt
rlist2  = http://echolot.theremailer.net/rlist2.txt
mlist2  = http://echolot.theremailer.net/mlist2.txt
rlist_html  = http://echolot.theremailer.net/rlist.html
mlist_html  = http://echolot.theremailer.net/mlist.html
rlist2_html = http://echolot.theremailer.net/rlist2.html
mlist2_html = http://echolot.theremailer.net/mlist2.html
pgpring = http://echolot.theremailer.net/pgp-all.asc
pgpring_rsa = http://echolot.theremailer.net/pgp-rsa.asc
mixring = http://echolot.theremailer.net/pubring.mix
type2list   = http://echolot.theremailer.net/type2.list
[hermetix]
base= http://www.hermetix.org/echolot/
rlist   = http://www.hermetix.org/echolot/rlist.txt
mlist   = http://www.hermetix.org/echolot/mlist.txt
rlist2  = http://www.hermetix.org/echolot/rlist2.txt
mlist2  = http://www.hermetix.org/echolot/mlist2.txt
rlist_html  = http://www.hermetix.org/echolot/rlist.html
mlist_html  = http://www.hermetix.org/echolot/mlist.html
rlist2_html = http://www.hermetix.org/echolot/rlist2.html
mlist2_html = http://www.hermetix.org/echolot/mlist2.html
pgpring = http://www.hermetix.org/echolot/pgp-all.asc
pgpring_rsa = http://www.hermetix.org/echolot/pgp-rsa.asc
mixring = 

Bug#855123: mutt: terrible default setting in /etc

[Anonymous]

Package: mutt
Version: 1.7.2-1
Followup-For: Bug #855123

Dear Maintainer,

It's a bad idea to enable GPGME by default.  GPGME introduces serious
limitations that make it unnacceptible as a default setting.  Mutt
users cannot even send messages to protonmail or hushmail users when
GPGME is on.  The man page is correct, and the default should be off.

This bug was unfortunately reported upstream:

  https://github.com/neomutt/neomutt/issues/904

-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-4-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-2' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-sy
 stem-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20161229 (Debian 6.3.0-2) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D
 _FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM 
+HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS 
+USE_COMPRESSED +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX 
+USE_GSS +USE_HCACHE +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL 
+USE_SETGID +USE_SIDEBAR +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-forwref-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt

Bug#874590: [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[anonymous]

Follow-up Comment #2, bug #51181 (project wget):

This affects me, too.  Please fix.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#877948: aptitude needs to improve

[Anonymous]

Package: aptitude
Followup-For: Bug #877948

Mr. Kalnischkies,

I really appreciate your helpful and detailed reply, as well as your
good advice.

I must say though that you should not have had to explain the SHA1
limitation - that's something aptitude should have done.  I've always
found the user feedback from aptitude quite lacking w.r.t errors (and
reported it 4 years ago):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706183

How could I (as an apt team outsider) have known that the (poorly
worded) "invalid" signature error was due to use of a substandard
algorithm?  I ran aptitude with debugging output enabled, and it gave
no further information about this.  The man page for aptitude also
says nothing about the subjective criteria in play for validation.

BTW, I have a couple new bug reports coming to hopefully mitigate the
report herein being repeated by others.

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd2e9f5000)
/usr/lib/torsocks/libtorsocks.so (0x7ffb63a8)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7ffb6371)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7ffb634da000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7ffb632b)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7ffb630aa000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7ffb62d94000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7ffb62acb000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7ffb628b3000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7ffb624a2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ffb62285000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7ffb61f7a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffb61c79000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7ffb61a63000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffb616b8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffb614b4000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7ffb612b1000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffb61096000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7ffb60e86000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ffb60c63000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffb60a5b000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7ffb60856000)
/lib64/ld-linux-x86-64.so.2 (0x7ffb642e5000)

-- System Information:
Debian Release: 8.6
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.3
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u6
ii  libcwidget3   0.5.17-2
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libsqlite3-0  3.8.7.1-1+deb8u2
ii  libstdc++64.9.2-10
ii  libtinfo5 5.9+20140913-1+b1
ii  libxapian22   1.2.19-1+deb8u1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1.1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47
pn  debtags   
ii  tasksel   3.31+deb8u1

-- no debconf information

Bug#878177: aptitude: Use of the word "invalid" in error msgs should be restored to meaning

[Anonymous]

Package: aptitude
Version: 0.6.11-1+b1
Severity: minor

Dear Maintainer,

Aptitude's error messages often create confusion, either due to
vagueness or improper use of English.  In particular, use of the word
/invalid/ in the following warning message needs to be re-examined:

W: GPG error: tor+http://wertarbyte.de/apt ./ Release: The following 
signatures were invalid: CC49F74C816C499C899A42885145B9CD752C0197
E: The repository 'tor+http://wertarbyte.de/apt ./ Release' is not signed.
E: Failed to download some files

After a costly investigation involving multiple developers, it was
discovered that the apt team has taken an objective word
(valid/invalid) out of context and given it a new subjective meaning.
A signature is "valid" when whatever algorithm used determines it is
valid.  This is not subjective.  It is a matter of fact and is
mathematically provable.

In the above case, a valid signature was falsely reported as invalid
by aptitude because the algorithm (SHA1) was considered substandard in
the opinion of the apt team.  It's a reasonable opinion to have, but
please express it in a way that does not hi-jack a term that has a
different common understanding with a higher mathematical purpose.
There are many ways to express that warning in a non-misleading way:

 * The following signatures were valid but substandard
 * The following signatures do not meet apt team standards
 * The algorithm used by the signature is not worthy
 * The signature does not use a debian-accepted hash
 * No approval granted for the hash used in the following signature
 * The following signature does not conform to debian security standards

In the course of investigating, gpg confirmed that the SHA1 sig was
*valid*, and rightly so.  When aptitude debug output was enabled,
there was still no indication of what aptitude did, or why it did it.
There was no mention that SHA1 was insufficient, or even that SHA1 was
used, or whether it's a factor.  The man page also says nothing about
this.  So in addition to a false error msg, aptitude is not doing what
it's documented to do.

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7fffc5ff4000)
/usr/lib/torsocks/libtorsocks.so (0x7fc1d058b000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7fc1d021b000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fc1cffe5000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fc1cfdbb000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fc1cfbb5000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fc1cf89f000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fc1cf5d6000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7fc1cf3be000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7fc1cefad000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc1ced9)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc1cea85000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc1ce784000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc1ce56e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc1ce1c3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc1cdfbf000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc1cddbc000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc1cdba1000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fc1cd991000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc1cd76e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc1cd566000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fc1cd361000)
/lib64/ld-linux-x86-64.so.2 (0x7fc1d0df)

-- System Information:
Debian Release: 8.6
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.3
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 

Bug#877948: aptitude: false error: "The following signatures were invalid" (gpg con good)

[Anonymous]

Package: aptitude
Version: 0.6.11-1+b1
Severity: normal

Dear Maintainer,

There are two repositories which are blocked from "aptitude update" on
the basis of "invalid signature", when in fact gpg reports the
signatures are valid.

* 1st package: gc2latex *

  To reproduce, these steps are taken:

1) apt-key adv --recv-key 0x5145B9CD752C0197
2) gpg --keyring /etc/apt/trusted.gpg --edit-key 0x5145B9CD752C0197 trust
3) Selected full trust ("4")

  To prove that gpg find the signature good:

  $ gpg --verify --keyring /etc/apt/trusted.gpg <(curl -s 
http://wertarbyte.de/apt/Release.gpg) <(curl -s 
http://wertarbyte.de/apt/Release)

  results in:

gpg: Signature made Wed 25 May 2011 11:15:52 PM CEST
gpg:using DSA key 5145B9CD752C0197
gpg: Good signature from "Wertarbyte.de (Software Signing Key) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the 
owner.
Primary key fingerprint: CC49 F74C 816C 499C 899A  4288 5145 B9CD 752C 
0197

  This is the deb line in sources.list:

deb http://wertarbyte.de/apt/ ./
 
  When doing "aptitude update", the output is:

W: GPG error: tor+http://wertarbyte.de/apt ./ Release: The following 
signatures were invalid: CC49F74C816C499C899A42885145B9CD752C0197
E: The repository 'tor+http://wertarbyte.de/apt ./ Release' is not signed.
E: Failed to download some files

* 2nd package: pwsafe *

  It's the same problem for pwsafe, which has the sources.list entry:
  
deb http://packages.steve.org.uk/pwsafe/jessie/ ./

  the gpg key of which can be installed this way:
  
wget -O - http://packages.steve.org.uk/pwsafe/apt-key.pub | apt-key add -

Note the version info below is on Jessie, but the same problem occurs on recent 
versions in Stretch.

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7fff97679000)
/usr/lib/torsocks/libtorsocks.so (0x7f7d01765000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7f7d013f5000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f7d011bf000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f7d00f95000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f7d00d8f000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f7d00a79000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f7d007b)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f7d00598000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f7d00187000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f7cfff6a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f7cffc5f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7cff95e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f7cff748000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7cff39d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7cff199000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f7cfef96000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f7cfed7b000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f7cfeb6b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f7cfe948000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f7cfe74)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f7cfe53b000)
/lib64/ld-linux-x86-64.so.2 (0x7f7d01fca000)

-- System Information:
Debian Release: 8.6
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.3
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u6
ii  libcwidget3   0.5.17-2
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  

Bug#830973: minizinc executable is missing

[anonymous]

Package: minizinc
Followup-For: Bug #830973

Dear Maintainer,

This bug appears to be fixed in the latest upstream release (2.1.5) as it now
includes an executable "mzn-fzn" that works as the minizinc driver. However
mzn-gecode searches for a binary called "minizinc" so that script would need to
be updated also.

Bug#861949: flatzinc: fzn-gecode segfaults on most input files

[anonymous]

Package: flatzinc
Version: 4.4.0-4
Severity: important
Tags: upstream

Dear Maintainer,

fzn-gecode segmentation faults on most input .fzn files, rendering it mostly 
unusable.

Running the following commands reproduce the segmentation fault
(behaviour is not exclusive to this file):

$ mzn2fzn /usr/share/doc/examples/functions/warehouses.mzn -O- -o warehouses.fzn
$ fzn-gecode warehouses.fzn

An example of a file that does not cause a segfault is: 
/usr/share/doc/minizinc/new_syntax/extended_let.mzn

This appears to also affect the upstream 4.4.0 release when compiled on the 
same system.

GDB backtrace is attached.

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flatzinc depends on:
ii  libc6  2.24-10
ii  libgcc11:6.3.0-14
ii  libgecode41v5  4.4.0-4
ii  libgecodeflatzinc41v5  4.4.0-4
ii  libgecodegist41v5  4.4.0-4
ii  libstdc++6 6.3.0-14

flatzinc recommends no packages.

flatzinc suggests no packages.

-- no debconf information

*** backtrace.txt
user@debian:~/Desktop/flatzinc-debugging$ mzn2fzn 
/usr/share/doc/minizinc/examples/functions/warehouses.mzn -o ./warehouses.fzn 
-O-
user@debian:~/Desktop/flatzinc-debugging$ gdb fzn-gecode
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
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:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fzn-gecode...Reading symbols from 
/usr/lib/debug/.build-id/98/163b16bd01cfce89b50186d369bd0086c05a77.debug...done.
done.
(gdb) run warehouses.fzn
Starting program: /usr/bin/fzn-gecode warehouses.fzn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__cxxabiv1::__dynamic_cast (src_ptr=src_ptr@entry=0x0,
src_type=src_type@entry=0x55759ad0 ,
dst_type=dst_type@entry=0x77dd7258 , src2dst=src2dst@entry=0)
at ../../../../src/libstdc++-v3/libsupc++/dyncast.cc:50
50  ../../../../src/libstdc++-v3/libsupc++/dyncast.cc: No such file or 
directory.
(gdb) bt
#0  __cxxabiv1::__dynamic_cast (src_ptr=src_ptr@entry=0x0,
src_type=src_type@entry=0x55759ad0 ,
dst_type=dst_type@entry=0x77dd7258 , src2dst=src2dst@entry=0)
at ../../../../src/libstdc++-v3/libsupc++/dyncast.cc:50
#1  0x77b8c658 in Gecode::FlatZinc::AST::Node::hasAtom (this=0x0, 
id="output_var") at ./gecode/flatzinc/ast.hh:326
#2  0x77bb2b66 in yyparse (
parm=parm@entry=0x7fffda00)
at gecode/flatzinc/parser.yxx:628
#3  0x77bbb9ef in Gecode::FlatZinc::parse (
filename="warehouses.fzn", p=..., err=...,
fzs=, rnd=)
at gecode/flatzinc/parser.yxx:416
#4  0x7256 in main (argc=,
argv=) at tools/flatzinc/fzn-gecode.cpp:68
(gdb)

Bug#830973: minizinc: workaround for missing minizinc executable

[anonymous]

Package: minizinc
Version: 2.0.14+dfsg1-1+b1
Followup-For: Bug #830973

The following script can be used as a workaround for the missing
'minizinc' executable. It replaces the 'mzn-gecode' script provided by
the flatzinc package. It will conver the mzn to fzn and then pipe to
fzn-gecode. There may be a better method but this seems to work.

--- Script:

prefix=/usr
datarootdir=${prefix}/share
FLATZINC_CMD=fzn-gecode mzn2fzn -I ${datarootdir}/gecode/mznlib \
"$@" --output-to-stdout --no-output-ozn | fzn-gecode -

---


-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minizinc depends on:
ii  flatzinc4.4.0-4
ii  libc6   2.24-10
ii  libgcc1 1:6.3.0-14
ii  libstdc++6  6.3.0-14

minizinc recommends no packages.

minizinc suggests no packages.

-- no debconf information

Bug#859598: broadcom-sta-dkms occasionally drops wifi on BCM4331

[Anonymous]

Package: broadcom-sta-dkms
Version: 6.30.223.248-3

Using broadcom-sta-dkms & wl on a late 2012 Mac Mini with the internal BCM4331 
wifi card, the wifi connnection continually stalls, dozens of time a day (most 
often in the daytime). To reconnect, I shut off wifi in the GUI using 
NetworkManager, then turn it back on ... until it stalls again. When it stalls, 
NetworkManager reports a 100% signal on every listed & detected wifi network.

All other devices are working normally, connected to the same wifi router, set 
to b/g/n mode. If I set the router's wifi protocol to 802.11b (only), the wifi 
connection on the Mac Mini is much more stable, but it still stalls 
occasionally.

It looks like this problem may have been going on since at least 2014: 
http://crunchbang.org/forums/viewtopic.php?id=35128

I am using Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 
(2017-03-07) x86_64 GNU/Linux

Bug#347573: [bug #20417] 503 respose is not retryable but should be

[anonymous]

Follow-up Comment #5, bug #20417 (project wget):

Starting with version 1.19.1, Wget supports the option --retry-on-http-error
which you can use to specify a list of HTTP error codes that should be
retried. So, provided that you are running a current version of wget, just add
this to the arguments: --retry-on-http-error=503


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#846959: plume-creator: Characters, Items etc. cannot be added or removed from Mise en scene

[anonymous]

Package: plume-creator
Version: 0.66+dfsg1-3.1+b1
Severity: important

Dear Maintainer,

In this version of plume-creator, characters, items, places etc. cannot be
added or removed from the 'mise en scene' for a section. Attempting to drag one
of the characters (or items etc.) onto the 'mise en scene' gives a cursor with
a 'prohibited' emblem and has no effect. Opening a project that already has
characters added to the 'mise en scene' correctly loads them, however they
cannot be removed or added to.

In other words, the 'mise en scene' is unusable in this version.

This bug does not exist in the version on jessie, which is still built with
qt4.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plume-creator depends on:
ii  libc62.24-7
ii  libgcc1  1:6.2.1-5
ii  libhunspell-1.4-01.4.1-2+b1
ii  libqt5core5a 5.7.1~20161021+dfsg-6
ii  libqt5gui5   5.7.1~20161021+dfsg-6
ii  libqt5network5   5.7.1~20161021+dfsg-6
ii  libqt5printsupport5  5.7.1~20161021+dfsg-6
ii  libqt5widgets5   5.7.1~20161021+dfsg-6
ii  libqt5xml5   5.7.1~20161021+dfsg-6
ii  libquazip5-1 0.7.2-1
ii  libstdc++6   6.2.1-5

Versions of packages plume-creator recommends:
ii  hunspell  1.4.1-2+b1

Versions of packages plume-creator suggests:
pn  plume-creator-dbg  

Bug#819847: Additional information on Bug #819847

[Anonymous]

Package: gnome-packagekit
Version: 3.14.0-1
Followup-For: Bug #819847

Same problem here but I found a workaround (not a permanent one, though):

After issuing 'dpkg-reconfigure packagekit', the Package Updater seems to work
as intended again.

However, this only lasts for as long as the system is not restarted. Next time
when I start the computer, it is back to "No network connection was detected."
again.

I lack the skills to investigate it further but it seems to me that the problem
is in packagekit and not necessarily in gnome-packagekit and that something
messes with it when the system is started.

Hope this helps.

Bug#841988: qbittorrent: Crashing at random intervals

[Anonymous]

Package: qbittorrent
Version: 3.3.6-1+b1
Severity: important

Dear Maintainer,
I have been having this problem for more than a month now, so I think a little
bug report is needed. For some reason, qbittorrent keeps crashing at random
intervals with or without user interaction. A similar bug report is marked as
resolved, but my system doesn't seem to work with it. 
Running qbittorrent on a terminal makes it spit out the following after 
crashing:

*
Catching signal: SIGSEGV
Please file a bug report at http://bug.qbittorrent.org and provide the 
following information:

qBittorrent version: v3.3.6
stack trace:
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x15b65b  [0x7f834769b65b]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x15d60a  [0x7f834769d60a]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xa2713  [0x7f83475e2713]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xa5c4a  [0x7f83475e5c4a]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xa9e0c  [0x7f83475e9e0c]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xac0bd  [0x7f83475ec0bd]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1654ec  [0x7f83476a54ec]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x16668b  [0x7f83476a668b]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1c1078  [0x7f8347701078]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xc72bf  [0x7f83476072bf]
  /lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x7464  [0x7f8345ec2464]
  /lib/x86_64-linux-gnu/libc.so.6 : clone()+0x5f  [0x7f83453699df]
Segmentation fault
*

Having no idea why I'm having problems, I asked the devs and was told that it 
might be a problem with the libtorrent libs.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qbittorrent depends on:
ii  geoip-database 20161017-1
ii  libboost-system1.61.0  1.61.0+dfsg-3
ii  libc6  2.24-5
ii  libgcc11:6.2.0-9
ii  libqt5core5a   5.6.1+dfsg-3+b1
ii  libqt5dbus55.6.1+dfsg-3+b1
ii  libqt5gui5 5.6.1+dfsg-3+b1
ii  libqt5network5 5.6.1+dfsg-3+b1
ii  libqt5widgets5 5.6.1+dfsg-3+b1
ii  libqt5xml5 5.6.1+dfsg-3+b1
ii  libstdc++6 6.2.0-9
ii  libtorrent-rasterbar9  1.1.0-3
ii  python 2.7.11-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#789763: Can't leave fullscreen mode in Vinagre

[Anonymous]

Package: vinagre
Version: 3.14.1-1
Followup-For: Bug #789763

Dear Maintainer,

When watching a remote deskop via VNC, it's really hard to leave the fullscreen
mode because the popup on the top middle does not appear and seemingly almost
no keyboard input is accepted (ctrl + alt + delete sometimes leads to the
shutdown dialogue popping up. Sometimes...). However, it seems like I can click
on the invisible buttons but it's a pain to find them.
What I tried: pretty much every combination of keys I found on the interwebs:
alt + f10 , ctrl + alt + f , ctrl + alt + delete, f11 , esc, alt + esc, super +
esc, ... to no avail.

Hope the log helps.



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vinagre depends on:
ii  dconf-gsettings-backend [gsettings-bac  0.22.0-1
ii  libavahi-common30.6.31-5
ii  libavahi-gobject0   0.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-18+deb8u6
ii  libcairo2   1.14.0-2.1+deb8u1
ii  libdbus-glib-1-20.102-1
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-locale1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libgtk-vnc-2.0-00.5.3-1.3
ii  libsecret-1-0   0.18-1+b1
ii  libspice-client-glib-2.0-8  0.25-1+b1
ii  libspice-client-gtk-3.0-4   0.25-1+b1
ii  libtelepathy-glib0  0.24.1-1
ii  libvte-2.91-0   0.38.1-2
ii  libxml2 2.9.1+dfsg1-5+deb8u3

Versions of packages vinagre recommends:
ii  freerdp-x11  1.1.0~git20140921.1.440916e+dfsg1-4

vinagre suggests no packages.

-- no debconf information

Bug#794316: can't unlock desktop

[Anonymous]

Package: gdm3
Version: 3.14.1-7
Followup-For: Bug #794316

Similar/same problem here, with Jessie 8.6 / Gnome 3-3.14.1-7; the lock screen
was unresponsive after the desktop was locked for some time.
Restarting gdm3 from tty2 worked, but the session was lost.



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.37-3+b1
ii  adduser   3.113+nmu3
ii  dconf-cli 0.22.0-1
ii  dconf-gsettings-backend   0.22.0-1
ii  debconf [debconf-2.0] 1.5.56
ii  gir1.2-gdm3   3.14.1-7
ii  gnome-session [x-session-manager] 3.14.0-2
ii  gnome-session-bin 3.14.0-2
ii  gnome-settings-daemon 3.14.2-3
ii  gnome-shell   3.14.4-1~deb8u1
ii  gnome-terminal [x-terminal-emulator]  3.14.1-1+deb8u1
ii  gsettings-desktop-schemas 3.14.1-1
ii  libaccountsservice0   0.6.37-3+b1
ii  libaudit1 1:2.4-1+b1
ii  libc6 2.19-18+deb8u6
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgdm1   3.14.1-7
ii  libglib2.0-0  2.42.1-1+b1
ii  libglib2.0-bin2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libpam-modules1.1.8-3.1+deb8u1+b1
ii  libpam-runtime1.1.8-3.1+deb8u1
ii  libpam-systemd215-17+deb8u5
ii  libpam0g  1.1.8-3.1+deb8u1+b1
ii  librsvg2-common   2.40.5-1+deb8u2
ii  libselinux1   2.3-2
ii  libsystemd0   215-17+deb8u5
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.2-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1+b1
ii  libxrandr22:1.4.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  metacity [x-window-manager]   1:3.14.3-1
ii  mutter [x-window-manager] 3.14.4-1~deb8u1
ii  policykit-1   0.105-15~deb8u2
ii  ucf   3.0030
ii  x11-common1:7.7+7
ii  x11-xserver-utils 7.7+3+b1
ii  xterm [x-terminal-emulator]   312-2

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.14.0-1
ii  desktop-base   8.0.2
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+1
ii  xserver-xephyr 2:1.16.4-1
ii  xserver-xorg   1:7.7+7
ii  zenity 3.14.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.14.0-4+deb8u1
ii  libpam-gnome-keyring  3.14.0-1+b1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
AutomaticLoginEnable=False
AutomaticLogin=user
[security]
[xdmcp]
[greeter]
[chooser]
[debug]



-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#751270: bitlbee: works for me

[Anonymous]

Package: bitlbee
Followup-For: Bug #751270

Dear Maintainer,

Bitlbee now works with Twitter on Jessie, w/out hacks.  So perhaps
this ticket can be closed?

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bitlbee depends on:
ii  bitlbee-common 3.2.2-2
ii  debianutils4.4+b1
ii  libc6  2.19-18+deb8u4
ii  libevent-2.0-5 2.0.21-stable-2
ii  libgcrypt201.6.3-2+deb8u1
ii  libglib2.0-0   2.42.1-1+b1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3

bitlbee recommends no packages.

bitlbee suggests no packages.

-- no debconf information

Bug#831835: iceweasel: Padlock icon indicates a secure SSL connection established w MitM-ed

[Anonymous]

Package: iceweasel
Version: 38.8.0esr-1~deb8u1
Severity: important

Dear Maintainer,

A large portion of websites are being MitM'd (man-in-the-middle) by a
company that is centralizing the web (CloudFlare).  Firefox misleads
users by showing them a padlock icon stating (falsely) that the
connection is secure.  Users are lead to believe that they have a
secure end-to-end tunnel to the service named in the address bar.
However, they (unwittingly) have a tunnel to CloudFlare, who sees all
the traffic before it reaches the destination.

This means very sensitive data is being disclosed to CloudFlare
without the knowledge or consent of (mislead) Firefox users.  The
*only* way for a user to know of this MitM (using Firefox) is if they
hit F12 and inspect the HTTP response headers for a "cf-ray:" header.
Most users are not advanced enough to do that.

This security bug is serious.  To illustrate the gravity of the
problem, here are some bitcoin sites that share all traffic cloudflare
for which their exposed users are largely unaware:

 * bitcoin.de
 * bitcoin.it
 * bitcoinist.net
 * bitpay.com
 * biteasy.com
 * localbitcoins.com
 * seebitcoin.com

This means those sites (or disgruntled insider therein) could steal
money from clients, and CloudFlare could be blamed.  Or a CloudFlare
insider could do the same, and blame the service.

All usernames and passwords are being exposed to CloudFlare without
users knowledge or consent.  Many naive users re-use the same
credentials on many websites.

This bug report should be treated with very high priority!

Why this is reported as a debian package bug:

  The submitter understands that this bug should be reported upstream.
  However, that was tried.  Mozilla's bug database is hostile toward
  security-conscious users.  Mozilla forces e-mail address submission,
  then it blocks when the address is not from a provider of their
  liking.

  Mozilla claims github logins can be used, but then after the user
  exposes github creds Mozilla denies access if the associated address
  is not to their liking.

  Bug report submitters are not getting paid.  It's charity work.
  It's despicable that Mozilla expects charity workers to do more work
  for them than technically required.

  Therefore, this report is submitted to the debian package, because
  the Debian project has figured out how to collect bug reports from
  contributors, and all the hoops on Mozilla's upstream server were
  too exhausting.  Hopefully someone with an existing upstream account
  can mirror this report.  And I would appreciate it if this section
  is maintained.

  Thanks.

-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

-- Addons package information
ii  gnome-shell3.14.4-1~deb amd64graphical shell for the GNOME des
ii  icedtea-7-plug 1.5.3-1  amd64web browser plugin based on OpenJ
ii  iceweasel  38.8.0esr-1~ amd64Web browser based on Firefox
ii  rhythmbox-plug 3.1-1amd64plugins for rhythmbox music playe

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iceweasel depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.4.4-2
ii  gstreamer1.0-plugins-good  1.4.4-2

Versions of packages iceweasel suggests:

Bug#702241: gnome-packagekit: Update information is not refreshed

[Anonymous]

Package: gnome-settings-daemon
Version: 3.14.2-3
Followup-For: Bug #702241

Hi

I just wanted to report that the bug seems to be still present, using Jessie
8.5 and Gnome 3.14.1 . No update notifications and looking for updates via
the built-in update-viewer results in a message saying, that the system was
up to date, when it isn't. However, the update-viewer finds updates when I've
run "apt-get update" prior.
I had the same bug on two laptops, too. While not that big a problem for my-
self it still means that the combination Debian/Gnome might not work for every-
day users.
Thanks for all your work on Debian, I appreciate it!

Anonymous

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libcolord2   1.2.1-1+b2
ii  libcups2 1.7.5-11+deb8u1
ii  libfontconfig1   2.11.0-6.3
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libgeocode-glib0 3.14.0-1
ii  libglib2.0-0 2.42.1-1+b1
ii  libgnome-desktop-3-103.14.1-1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libgudev-1.0-0   215-17+deb8u4
ii  libgweather-3-6  3.14.1-1
ii  liblcms2-2   2.6-3+b3
ii  libnm-glib4  0.9.10.0-7
ii  libnm-util2  0.9.10.0-7
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.10.7-1+deb8u1
ii  libnss3  2:3.17.2-1.1+deb8u2
ii  libpackagekit-glib2-18   1.0.1-2
ii  libpam-systemd   215-17+deb8u4
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-gobject-1-00.105-8
ii  libpulse-mainloop-glib0  5.0-13
ii  libpulse05.0-13
ii  librsvg2-2   2.40.5-1+deb8u2
ii  libupower-glib3  0.99.1-3.2
ii  libwacom20.8-1
ii  libwayland-client0   1.6.0-2
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.14.1-2

Versions of packages gnome-settings-daemon recommends:
ii  pulseaudio  5.0-13

Versions of packages gnome-settings-daemon suggests:
pn  gnome-screensaver
ii  metacity [x-window-manager]  1:3.14.3-1
ii  mutter [x-window-manager]3.14.4-1~deb8u1
ii  x11-xserver-utils7.7+3+b1

-- no debconf information

Bug#824437: mpack: RFC 2047 non-compliant. MIME strings are not decoded

[Anonymous]

Package: mpack
Version: 1.6-8
Severity: normal

Dear Maintainer,

If a MIME header uses a character set encoding, munpack does not
correctly decode the string when naming the file.  For example, if a
MIME header looks like this:

===8<
--926373431-50545-903641383=:8047
Content-Type: application/pdf;
name="=?ISO-8859-1?Q?Andr=E9?="
Content-Disposition: attachment;
filename="=?ISO-8859-1?Q?Andr=E9?="
Content-Transfer-Encoding: BASE64
===8<

Then munpack creates a file that is literally named
"=?ISO-8859-1?Q?Andr=E9?=".  Likewise, it's the same problem if the
filename is UTF-8 encoded, which takes the form:
"=?UTF-8?B?blahblah=?=".

This does not comply with RFC 2047.  For simple example if the
decoding that's needed, see: http://dogmamix.com/MimeHeadersDecoder/
Perhaps that site will be good for testing purposes.

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpack depends on:
ii  libc6  2.19-18+deb8u4

mpack recommends no packages.

Versions of packages mpack suggests:
pn  inews   
ii  postfix [mail-transport-agent]  2.11.3-1

-- no debconf information

Bug#816768: v4l2loopback-dkms: simply fails with "Internal data flow error" on basi usage

[Anonymous]

Package: v4l2loopback-dkms
Version: 0.8.0-4
Severity: important

Dear Maintainer,

After installing this package on debian stable, the kernel module is
not automatically loaded.  The workaround is to run this every time:

  $ sudo modeprobe v4l2loopback

Which *appears* to have no problems according to /var/logs/kern.log:

  =8<
  Mar  4 20:51:33 host kernel: [14443.590541] Linux video capture interface: 
v2.00
  Mar  4 20:51:33 host kernel: [14443.593673] v4l2loopback driver version 0.8.0 
loaded
  =8<

However, the problem comes when simply trying to use it in the most
basic way.  E.g.:

  $ gst-launch-1.0 videotestsrc ! v4l2sink device=/dev/video0

results in:

  =8<
  Setting pipeline to PAUSED ...
  Pipeline is PREROLLING ...
  Pipeline is PREROLLED ...
  Setting pipeline to PLAYING ...
  New clock: GstSystemClock
  ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: 
Internal data flow error.
  Additional debug info:
  gstbasesrc.c(2933): gst_base_src_loop (): 
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
  streaming task paused, reason error (-5)
  Execution ended after 0:00:00.000351581
  Setting pipeline to PAUSED ...
  Setting pipeline to READY ...
  =8<

Note that 'ls /dev/video0' shows the device is present.

If the same hardware boots Linux Mint instead of Debian stable, there
is no problem.  This package installs completely, so that modprobe is
automatically run on boot, and the gstreamer test works, as well as
any other content given over gstreamer.  So this is likely a problem
with the debian packaging.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages v4l2loopback-dkms depends on:
ii  dkms  2.2.0.3-2

v4l2loopback-dkms recommends no packages.

Versions of packages v4l2loopback-dkms suggests:
pn  v4l2loopback-utils  

-- no debconf information

Bug#808253: eog: please make user directory structure conform to freedesktop standards

[Anonymous]

Package: eog
Version: 3.14.1-1
Severity: wishlist

Dear Maintainer,

The thumbnails are hard-coded to be stored in
$HOME/.cache/thumbnails/.  It's a good place, but eog should support
some environment variables to conform to this standard:

  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Since thumbnails are shared by many apps, having different apps choose
different directories breaks the benefit of that sharing.  Gimp, for
example, stores thumbnails in $XDG_CACHE_HOME/thumbnails/.  ATM, users
who want to exploit the thumbnail are forced to set $XDG_CACHE_HOME to
$HOME/.cache/ to cater for eog.

There should also be an "Environment" section added to the manpage,
which should document any of these variables that eog ends up using:

$XDG_DATA_HOME
$XDG_CONFIG_HOME
$XDG_DATA_DIRS
$XDG_CONFIG_DIRS
$XDG_CACHE_HOME
$XDG_RUNTIME_DIR

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages eog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gir1.2-gtk-3.0   3.14.5-1+deb8u1
ii  gir1.2-peas-1.0  1.12.1-2
ii  gnome-icon-theme 3.12.0-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u1
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libexempi3   2.2.1-2
ii  libexif120.6.21-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u2
ii  libgirepository-1.0-11.42.0-2.2
ii  libglib2.0-0 2.42.1-1
ii  libgnome-desktop-3-103.14.1-1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  liblcms2-2   2.6-3+b3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpeas-1.0-01.12.1-2
ii  librsvg2-2   2.40.5-1
ii  libx11-6 2:1.6.2-3
ii  libxml2  2.9.1+dfsg1-5
ii  shared-mime-info 1.3-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages eog recommends:
ii  librsvg2-common  2.40.5-1
ii  yelp 3.14.1-1

eog suggests no packages.

-- no debconf information

Bug#807595: grepmail: standard directory structure should be used

[Anonymous]

Package: grepmail
Version: 5.3033-6
Severity: wishlist

Dear Maintainer,

The cache storage location is hard-coded to $HOME/.grepmail-cache.
This is a non-standard structure.  Please consider conforming to the
freedesktop standard which is documented here:

  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Specifically, please honor the $XDG_CACHE_HOME variable.

Thank you!

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages grepmail depends on:
ii  libmail-mbox-messageparser-perl1.5002-2
ii  libtimedate-perl   2.3000-2
ii  perl   5.20.2-3+deb8u1
ii  perl-base [libscalar-list-utils-perl]  5.20.2-3+deb8u1

grepmail recommends no packages.

Versions of packages grepmail suggests:
ii  libdate-manip-perl  6.47-1

-- no debconf information

Bug#804756: gnus-agent-regenerate-group crashes => Invalid read syntax: ". in wrong context"

[Anonymous]

Package: emacs24
Version: 24.4+1-5
Severity: important

Dear Maintainer,

A particular newsgroup breaks gnus in an irrecoverable way.  Gnus
cannot open a group with content from "gwene.com.fatwallet.hotdeals"
from the news.gmane.org server (filed in bug# 797409).

Two other gnus functions fail when trying to recover:

  * gnus-agent-regenerate-group
  * gnus-agent-expire-group

Those two commands fail with:

  Invalid read syntax: ". in wrong context"

This is very severe, because regenerating the group is the only
function to recover from other bugs, and this function itself is
broken.  It's not even possible to delete the messages, because the
group cannot be entered.  It's a complete stalemate.  The bugs are so
entrenched that there is no way to recover from this.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.4+1-5
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.0.28-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u1
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libdbus-1-31.8.20-0+deb8u1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u2
ii  libgif44.1.6-11
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libgomp1   4.9.2-10
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libm17n-0  1.6.4-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-5
ii  libmagickwand-6.q16-2  8:6.8.9.9-5
ii  libotf00.9.13-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.5-1
ii  libselinux12.3-2
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.3-12.3
ii  libtinfo5  5.9+20140913-1+b1
ii  libx11-6   2:1.6.2-3
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.1+dfsg1-5
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.4.2-1+b1
ii  libxrender11:0.9.8-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

Bug#804754: gnus-agent-regenerate-group crashes => Invalid read syntax: ". in wrong context"

[Anonymous]

Package: emacs24
Version: 24.4+1-5
Severity: important

Dear Maintainer,

A particular newsgroup breaks gnus in an irrecoverable way.  Gnus
cannot open a group with content from "gwene.com.fatwallet.hotdeals"
from the news.gmane.org server (filed in bug# 797409).

Two other gnus functions fail when trying to recover:

  * gnus-agent-regenerate-group
  * gnus-agent-expire-group

Those two commands fail with:

  Invalid read syntax: ". in wrong context"

This is very severe, because regenerating the group is the only
function to recover from other bugs, and this function itself is
broken.  It's not even possible to delete the messages, because the
group cannot be entered.  It's a complete stalemate.  The bugs are so
entrenched that there is no way to recover from this.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.4+1-5
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.0.28-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u1
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libdbus-1-31.8.20-0+deb8u1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u2
ii  libgif44.1.6-11
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libgomp1   4.9.2-10
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libm17n-0  1.6.4-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-5
ii  libmagickwand-6.q16-2  8:6.8.9.9-5
ii  libotf00.9.13-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.5-1
ii  libselinux12.3-2
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.3-12.3
ii  libtinfo5  5.9+20140913-1+b1
ii  libx11-6   2:1.6.2-3
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.1+dfsg1-5
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.4.2-1+b1
ii  libxrender11:0.9.8-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

Bug#804761: gnus-agent-regenerate-group crashes => Invalid read syntax: ". in wrong context"

[Anonymous]

Package: emacs24
Version: 24.4+1-5
Severity: important

Dear Maintainer,

A particular newsgroup breaks gnus in an irrecoverable way.  Gnus
cannot open a group with content from "gwene.com.fatwallet.hotdeals"
from the news.gmane.org server (filed in bug# 797409).

Two other gnus functions fail when trying to recover:

  * gnus-agent-regenerate-group
  * gnus-agent-expire-group

Those two commands fail with:

  Invalid read syntax: ". in wrong context"

This is very severe, because regenerating the group is the only
function to recover from other bugs, and this function itself is
broken.  It's not even possible to delete the messages, because the
group cannot be entered.  It's a complete stalemate.  The bugs are so
entrenched that there is no way to recover from this.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.4+1-5
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.0.28-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u1
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libdbus-1-31.8.20-0+deb8u1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u2
ii  libgif44.1.6-11
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libgomp1   4.9.2-10
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libm17n-0  1.6.4-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-5
ii  libmagickwand-6.q16-2  8:6.8.9.9-5
ii  libotf00.9.13-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.5-1
ii  libselinux12.3-2
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.3-12.3
ii  libtinfo5  5.9+20140913-1+b1
ii  libx11-6   2:1.6.2-3
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.1+dfsg1-5
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.4.2-1+b1
ii  libxrender11:0.9.8-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

Bug#801270: emacs/gnus: better expiry feature needed for spam groups

[Anonymous]

Package: emacs
Version: 46.1
Severity: wishlist

Dear Maintainer,

Gnus has only two semi-automated mechanisms to mark messages as
expirable (auto-expire and total-expire).  Both approaches require
users to select or read every single message in the group in order to
have all messages set to expire.  This imposes too much manual labor
for a group that collects spam, where a user simply wants to glance in
the group summary buffer periodically to scan for false positives,
without having to touch the individual messages.

I propose two solutions:

1) a header that gnus recognizes, which would suggest the expiration
   date of a message.  Something like "X-requested-exp-date:".  This
   would serve two purposes:

 * procmail could (and should) hold the decision logic for when a
   message should expire.  Ideally procmail would add a header
   like "X-requested-exp-date: 2015-10-16" or
   "X-requested-exp-date: +96 hours".  Or even just having a
   boolean switch without a date.

 * an author of a message could request that their message expire,
   and a recipient could tell gnus to honor that.

2) rename the current "auto-expire" to "semi-auto-expire", and invent
   a real "auto-expire" mechanism that starts an aging clock on all
   messages as they arrive (selected or not), based on the group
   settings.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs24  24.4+1-5

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#799904: qpdf: AES encryption ignores password and uses an unknown key

[Anonymous]

Package: qpdf
Version: 5.1.2-2
Severity: normal

Dear Maintainer,

The syntax for performing an AES cipher on an unencrypted source PDF
is this:

  $ qpdf --encrypt usrpw ownrpw 256 -- source.pdf encrypted.pdf

It executes without error, but both evince and okular fail to open the
PDF using either password.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qpdf depends on:
ii  libc6   2.19-18+deb8u1
ii  libgcc1 1:4.9.2-10
ii  libpcre32:8.35-3.3
ii  libqpdf13   5.1.2-2
ii  libstdc++6  4.9.2-10
ii  zlib1g  1:1.2.8.dfsg-2+b1

qpdf recommends no packages.

qpdf suggests no packages.

-- no debconf information

Bug#799407: java.io.IOException: Address family not supported by protocol

[Anonymous]

Package: icedtea-7-plugin
Version: 1.5-2+deb8u1
Severity: important

Dear Maintainer,

After installing icedtea-plugin, I ran the test on this page:

  https://www.java.com/en/download/installed.jsp

Clicking "Verify Java version" resulted in an animated "Error" text
string, which appeared in the window.  This is the stack trace:

8<
IcedTea-Web Plugin version: 1.5 (1.5-2+deb8u1)
Fri Sep 18 21:01:21 CEST 2015
java.io.IOException: Address family not supported by protocol
at net.sourceforge.jnlp.JNLPFile.openURL(JNLPFile.java:307)
at net.sourceforge.jnlp.JNLPFile.(JNLPFile.java:227)
at net.sourceforge.jnlp.JNLPCreator.create(JNLPCreator.java:33)
at net.sourceforge.jnlp.PluginBridge.(PluginBridge.java:114)
at net.sourceforge.jnlp.PluginBridge.(PluginBridge.java:67)
at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:101)
at sun.applet.AppletPanel.run(AppletPanel.java:380)
at java.lang.Thread.run(Thread.java:745)
8<

The browser version is Mozilla Iceweasel 38.2.1.

I also tried some other java browser plugin test sites.  Same error at
all of them.  These are the other test sites:

  * http://javatester.org/version.html
  * https://www.cis.upenn.edu/~matuszek/General/JavaVersionTests/JavaTests.html

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages icedtea-7-plugin depends on:
ii  icedtea-netx   1.5-2+deb8u1
ii  libc6  2.19-18+deb8u1
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.42.1-1
ii  libstdc++6 4.9.2-10
ii  openjdk-7-jre  7u79-2.5.6-1~deb8u1

icedtea-7-plugin recommends no packages.

icedtea-7-plugin suggests no packages.

-- no debconf information

Bug#793652: p7zip-full: AES cipher broken on zip files made for Windows users

[Anonymous]

Package: p7zip-full
Version: 9.20.1~dfsg.1-4.1+deb8u1
Severity: normal

Dear Maintainer,

Per the documentation, this command should produce a classic zip file
encrypted using the AES-256 algorithm and the password foo:

 $ 7z a -tzip -mem=AES256 -pfoo aes256.zip bar.txt

It produces the file without error, and in fact 7z can also extract
the file.  However, when a Windows user tries to open the file, they
can only see the list of files.  None of the files can be opened.
Double-clicking bar.txt gets no response.  Right-clicking
aes256.zip and then choosing extract all files.. results in the
error unknown compression.

This may be a Windows XP problem.  But it should be looked at.  Note
that there is no problem if -mem=AES256 is omitted, in which case
the unusual ZipCrypto cipher is used.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages p7zip-full depends on:
ii  libc6   2.19-18
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

p7zip-full recommends no packages.

Versions of packages p7zip-full suggests:
pn  p7zip-rar  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792115: bash: hold on..

[Anonymous]

Package: bash
Version: 4.3-11+b1
Followup-For: Bug #792115

Bob,

Indeed the octal variant of the syntax negates permissions.  I did not
mention this, but it's a good point.  It's another case where the
documentation misleads users.

When the documentation is corrected, Bob's point should also be taken
into account.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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   8+deb8u1
ii  dash 0.5.7-4+b1
ii  debianutils  4.4+b1
ii  libc62.19-18
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4

Versions of packages bash suggests:
pn  bash-doc  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792532: lynx: w3m consistency would be nice

[Anonymous]

Package: lynx
Version: 2.8.9dev1-2
Followup-For: Bug #792532

Andy,

Thanks for the reply.  In principle, I would not be fussy about how
the fail-safe is implemented, so long as there is a means to fail
safely.

But I suggest that whatever the syntax is, it would be useful if it
were consistent with other browsers.  Inventing yet another way of
expressing something adds complexity to the overall gnu environment.
E.g. isn't it a bit irritating that w3m looks for the variable
HTTP_PROXY, and lynx looks for http_proxy?

For the matter at hand, w3m also lacks a fail-safe, so I created bug
792234 at the same time.  Perhaps there could be some coordination.

If lynx aligns with the links browser, links has these options:

  -http-proxy host:port
  -ftp-proxy host:port
  -https-proxy host:port
  -socks-proxy user@host:port

  as well as this (poorly worded) option:

  -only-proxies 0/1
 1 causes that Links won't initiate any non-proxy connection.
 It is useful for anonymization with tor or similar networks.

cURL has:

  -U, --proxy-user user:password
  -x, --proxy [protocol://][user:password@]proxyhost[:port]
  -p, --proxytunnel
  --proxy1.0 proxyhost[:port]
  --proxy-ntlm
  --proxy-digest
  --proxy-basic
  --proxy-anyauth
  --proxy-header header
  --noproxy no-proxy-list

  env vars: http_proxy, HTTPS_PROXY = it's bizarre that casing is
   inconsistent
wget has:

  --no-proxy
  --proxy-user=user
  --proxy-password=password

  env vars: http_proxy, https_proxy, ftp_proxy, no_proxy

  wget can also force a proxy to be used, but it's somewhat clumsy.
  It requires config file options to be given on the commandline.
  E.g. wget -e use_proxy=yes -e http_proxy=$proxy http://www.eff.org;

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lynx depends on:
ii  lynx-cur  2.8.9dev1-2+b1

lynx recommends no packages.

lynx 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