Bug#959971: meet.google.com broken with debian build (ff76)

[Viktor Jägersküpper]

This is the corresponding upstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1636632

Either building without --with-system-nss or adding a patch should
resolve the problem.

Bug#887798: firefox-esr: impossible to connect to Google domains

[Viktor Jägersküpper]

On Sat, 20 Jan 2018 11:30:56 +0100 Vincent Lefevre 
wrote:
> (...)
> As a temporary and insecure workaround, I can avoid this error by
> setting security.OCSP.require to false, even though the error was
> not about OCSP.

Hello Vincent,

this is not a bug in Firefox (ESR). See this thread (works in Firefox
only with "security.OCSP.require" set to "false" at the moment):
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/MMO3HSYghwQ/XLRuxWtJAwAJ

The Google engineers are working on fixing this issue, so that this OCSP
setting can be set to "true" again.

Regards,
Viktor

Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

[Viktor Jägersküpper]

On Wed, 01 Nov 2017 08:04:37 +0100 intrig...@debian.org wrote:
> So I propose we do this:
> 
> --- a/debian/systemd/tor@default.service
> +++ b/debian/systemd/tor@default.service
> @@ -20,7 +20,7 @@ Restart=on-failure
>  LimitNOFILE=65536
>  
>  # Hardening
> -AppArmorProfile=system_tor
> +AppArmorProfile=-system_tor
>  NoNewPrivileges=yes
>  PrivateTmp=yes
>  PrivateDevices=yes

I confirm that with this change tor starts normally without apparmor installed.

Note that I still see in syslog (if that's relevant):
kernel: [   22.193677] audit: type=1400 audit(1509560952.793:2): 
apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 
profile="unconfined" name="system_tor" pid=542 comm="(tor)"

I also tested it with "security=dac" on the kernel command line without getting 
the above syslog entry (of course).

Thanks,
Viktor

Bug#867818: No printer listed in some applications when no default printer is set

[Viktor Jägersküpper]

Brian Potkin:
> On Sun 09 Jul 2017 at 17:41:00 +0000, Viktor Jägersküpper wrote:
> 
>> The bug is already fixed upstream.
> 
> Reference, please.
https://github.com/apple/cups/commit/b2f85109da901eb652babdc4f2a846c1c28228ff

Bug#772097: Aw: Bug#772097: LibreOffice sees only "Generic Printer"

[Viktor Jägersküpper]

Hi,

Rene Engelhard:
> I am actually not sure. This bug is so old that cups 2.2.3 vs. 2.2.4 didn't 
> exist
> back then but is quite new.
> What makes you think this is a cups 2.2.3 vs. 2.2.4 issue? (yes, I read your 
> above
> steps, but...)

I just filed bug #867818, you should be able to reproduce it with the
comments from the referenced upstream bug report. I tested version
2.2.4-2~exp0 from experimental which also had the bug. Then I tested a
different machine running testing with cups 2.2.3-2, added the printer
via hp-setup and everything was fine, but upgrading to cups 2.2.4-1 made
the bug appear there. At last I tested a laptop with jessie and
LibreOffice 1:4.3.3-2+deb8u2 again with the steps as before, but the
printer was listed in LibreOffice and the GNOME control center, so I
believe this bug is not what I observe because it affects package
versions from jessie.

Regards,
Viktor

Bug#867818: No printer listed in some applications when no default printer is set

[Viktor Jägersküpper]

Package: cups
Version: 2.2.4-1
Severity: normal
Forwarded: https://github.com/apple/cups/issues/5046
Tags: upstream
Tags: fixed-upstream
Control: affects -1 src:libreoffice
Control: affects -1 gnome-control-center

Dear Maintainer,

CUPS 2.2.4-1 introduces a regression when no printer is set as default.
In this case some applications will not list any printer at all, e.g.
any Libreoffice application or the GNOME control center. A workaround is
to set a printer as the default one, e.g. via the CUPS web interface.

The bug is already fixed upstream.

Regards,
Viktor

Bug#772097: LibreOffice sees only "Generic Printer"

[Viktor Jägersküpper]

reassign 772097 libreoffice 1:4.3.3-1
retitle 772097 libreoffice: LibreOffice sees only "Generic Printer"
affects 772097 - src:libreoffice
affects 772097 - gnome-control-center
thanks

This bug report is actually not about the bug I observed, so cleaning up
the mess I created.

Bug#772097: Aw: Bug#772097: LibreOffice sees only "Generic Printer"

[Viktor Jägersküpper]

reassign 772097 src:cups 2.2.4-1
retitle 772097 printer not listed in some applications
affects 772097 src:libreoffice
affects 772097 gnome-control-center
thanks

Dear Maintainer,

On Fri, 5 Dec 2014 10:08:23 +0100 "Rene Engelhard"
 wrote:

(citing the original bug reporter)
> > I can print from every OTHER application I have tried, but I cannot 
> > print from LibreOffice.  Only the "Generic Printer" option is 
> > displayed.  No way to get it to reload or discover other printers that I 
> > can tell.
> 
> It gets the printer info rom CUPS during startup ttbomk. If it finds none...
> 
> I can't reproduce this. I have a jessie laptop and I *can* choose printers 
> there.

I can reproduce this with version 1:5.3.4-1 of Libreoffice. However I
believe that Libreoffice is not to blame. Instead I think it is a bug in
CUPS.

With version 2.2.3-2 of CUPS Libreoffice shows my printer and the
printer is listed in the printer section of the GNOME control center,
after the upgrade to version 2.2.4-1 of CUPS the printer does not appear
in both applications, but e.g. in Evince and it is still listed in the
CUPS web interface. I reconfigured the printer (via hplip because it is
a HP model), but that did not help, so I guess hplip is not to blame.
Then I downgraded CUPS and that solved the problem. Upgrading again
makes the printer disappear in Libreoffice and the GNOME control center,
but it is still listed in Evince and in the CUPS web interface.

The printer is connected via USB.

I assigned the bug to the source package because I didn't know which
binary package to blame.

Please tell me if I can give you more information.

Regards,
Viktor

Bug#858735: thunderbird: After migration Thunderbird fails to start due to AppArmor denials in ~/.icedove

[Viktor Jägersküpper]

Dear Gerald,

Gerald Turner:
> BTW, I'm having a frustrating time post-migration: My profile is 49GB,
> Thunderbird decided it needs to re-download all that mail, and it has
> also fogotten my per-folder "Sort By > Threaded" preference, that I'll
> have to re-click hundreds of times, but only after waiting few days for
> that 49GB to be synchronized so that the UI is less frozen.  I have two
> other installations of Thunderbird that will likely face the same fate.

I tested the Thunderbird packages last year and also experienced
something like this because I also moved .icedove to .thunderbird
manually once, but I don't remember the details. As far as I know, this
is a bug in Thunderbird (upstream).

I recommend you to wait with the upgrade of the icedove packages on your
two other installations until this bug is fixed, so that you won't have
to move .icedove to .thunderbird manually there and you won't suffer
from the Thunderbird bug (re-downloading etc.).

Regards,
Viktor

Bug#856185: icedove-l10n-it wants to uninstall thunderbird-l10n-it

[Viktor Jägersküpper]

Dear Salvo,

Carsten Schoenert:
> On Sun, Feb 26, 2017 at 09:59:21AM +0100, Salvo Tomaselli wrote:
>> # LANG=C aptitude remove icedove-l10n-it:all
>> The following packages will be REMOVED:  
>>   icedove-l10n-it thunderbird-l10n-it{u} 
>
> carsten@i5:~/gitprojects/icedove [debian/sid] $ LANG= sudo apt remove 
> icedove-l10n-it
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following package was automatically installed and is no longer required:
>   thunderbird-l10n-it
> Use 'sudo apt autoremove' to remove it.
> The following packages will be REMOVED:
>   icedove-l10n-it

you are using 'aptitude remove' which removes not only the package
icedove-l10n-it, but also all packages which are marked as automatically
installed, in your case thunderbird-l10n-it. Since the debranding of
Icedove to Thunderbird, icedove-l10n-it depends on thunderbird-l10n-it,
so if you install icedove-l10n-it, thunderbird-l10n-it is automatically
installed.

So you are experiencing just the usual behaviour of aptitude, while apt
behaves in another way as Carsten showed.

BTW, be careful when aptitude wants to remove any package. You might
remove a package which you actually don't want to remove.

To work around this behaviour, you can mark a package which you want to
keep as "manually installed" by
# aptitude unmarkauto thunderbird-l10n-it

and similarly for other packages which you want to keep installed, see
the aptitude manual for further information.

So this bug can be closed.

Regards,
Viktor

Bug#854587: icedove: incorrect start-version in {icedove,thunderbird}.maintscript

[Viktor Jägersküpper]

Andreas Beckmann:
> On 2017-02-08 16:23, Carsten Schoenert wrote:
>>> PS: do you plan to rename the source package to thunderbird, too?
>>
>> Yes, this is planned. But probaly after the Stretch release. Otherwise
>> we may conflict with apt-listchanges and the wanted pop-up for the
>> change of the icedove package.
> 
> You could continue building the transitional packages from src:icedove
> (so icedove.NEWS will be shown as intended) and only move the new
> content-bearing thunderbird packages to src:thunderbird.
> IMO that would make maintenance over stretch lifetime easier ... than
> having src:icedove (non-transitional) in stretch (stable) and
> src:thunderbird in buster (testing) over stretch's lifetime (expecting
> some new upstream releases going into stretch, too).
> It might make maintenance a bit more difficult for jessie (oldstable)
> though ...

A suggestion from a user's point of view:

You could also move/incorporate the content of the icedove.NEWS file to
the popup which will be shown during the migration of the icedove
profile(s) (#854488). This covers the (unusual?) case when
apt-listchanges is not installed.

I also want to mention users who don't have root privileges like me when
I used a PC in my university. These users will never see the
icedove.NEWS info, but only the popup, and they will probably see the
Icedove->Thunderbird link provided by the icedove.desktop file.

The reason for my suggestion is that I believe you have already planned
to provide the info about the re-branding to thunderbird
- for jessie and wheezy in the security-announce email
- for upgrades from jessie to stretch in the release notes

So you only need to have the new src:thunderbird package in stretch (the
release team has to give their ok to this of course because it is a new
source package), jessie and wheezy.

Maybe I forgot something, but I hope this will simplify the work for
you. It is of course your decision if the additional work for two source
packages is worth it only for giving the info about the re-branding via
apt-listchanges. My point of view is that you will have the attention of
all users when they want to *use* Icedove/Thunderbird, that means when
the actual migration of the profile(s) takes place, and the popup is the
best way to get attention.

Viktor

Bug#848355: New upstream release (0.96.24.8)

[Viktor Jägersküpper]

On Fri, 16 Dec 2016 17:16:38 +0100 Julian Andres Klode 
wrote:
> I'd like to follow xenial's 0.96.20.X, as that's an LTS release
> series and thus more appropriate for us than a version that only
> has 9 months of upstream support (and is not frozen yet).
> 
> I guess we can follow some newer changes too if they are small
> enough and neccessary, but I'd really like to be as close to the
> Ubuntu LTS one as possible.

Hi,

there is at least one issue in the version 0.96.20.2 which is annoying
or confusing, but I believe it is fixed in version 0.96.24.6 and later
in Ubuntu. When I open the dialog of software-properties-gtk (e.g. from
Synaptic) without an existing /etc/apt/trusted.gpg, a "strange"
trusted.gpg file is created which makes APT warn that it cannot read it.
So I have to manually remove the trusted.gpg file to get rid of the
warnings.

The fix could also close #843946 and #840997.

Regards,
Viktor

Bug#834943: bug forwarded to GitHub

[Viktor Jägersküpper]

reopen 834943
retitle 834943 caja crash when changing from trash in list view to other
directory in list view
forwarded 834943 https://github.com/mate-desktop/caja/issues/649
thanks

Dear MATE Maintainers,

unfortunately I noticed recently that this bug is still present in caja
1.16.0 and I reported it upstream.

Regards
Viktor

Bug#836238: no command line prompt visible after updating GTK+3 to 3.21.5-1

[Viktor Jägersküpper]

Hello Adrian,

if I start mate-terminal from the command line (with gnome-terminal)
while using the "TraditionalOk" theme, I get

$ mate-terminal
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:2202:16: not a number
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:2202:16: Expected a string.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3157:14: not a number
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3157:14: Expected a string.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3658:14: not a number
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3658:14: Expected a string.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3959:62: Using one color stop with linear-gradient() is
deprecated.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:3992:61: Using one color stop with linear-gradient() is
deprecated.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:4008:61: Using one color stop with linear-gradient() is
deprecated.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:4024:59: Using one color stop with linear-gradient() is
deprecated.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:4038:62: Using one color stop with linear-gradient() is
deprecated.
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
mate-applications.css:214:16: not a number
(mate-terminal:4005): Gtk-WARNING **: Theme parsing error:
mate-applications.css:214:16: Expected a string.

With GTK+ 3.20.9-1 these messages do not appear. With GTK+ 3.21.5-3 (I
updated to the latest version) I get different messages depending on
which theme I use. Maybe this helps.

Viktor

Bug#836238: no command line prompt visible after updating GTK+3 to 3.21.5-1

[Viktor Jägersküpper]

Hello Adrian,

I created a new user, opened mate-terminal, everything seemed ok, then
set the theme to "TraditionalOk" which I used with my standard user and
the bug appeared again. I also purged and reinstalled mate-terminal
after that. Then I played around with the themes. With "High contrast",
"TraditionalGreen" and "TraditionalOk" the command line prompt is not
displayed, so it could be a bug in mate-themes. However, in all other
themes the font colour is white and the background is grey (is this
standard?). When I want to change this, mate-terminal crashes (see bug
836239). So with the three themes mentioned mate-terminal is not really
usable for me.

Viktor

Bug#836239: crash when changing the background after updating GTK3 to 3.21.5-1

[Viktor Jägersküpper]

Package: mate-terminal
Version: 1.14.1-1
Severity: important

Dear Maintainer,

after updating the GTK+3 packages from version 3.20.9-1 to version
3.21.5-1 mate-terminal crashes when I change the background from "none"
to whatever I want. Downgrading the GTK+3 packages makes the bug disappear.

Please tell me if I should give you more information, maybe how I can
debug this.

Regards
Viktor



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

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

Versions of packages mate-terminal depends on:
ii  gsettings-desktop-schemas  3.21.4-2
ii  libatk1.0-02.20.0-1
ii  libc6  2.23-5
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.49.6-1
ii  libgnutls303.5.3-3
ii  libgtk-3-0 3.21.5-1
ii  libice62:1.0.9-1+b1
ii  libmate-desktop-2-17   1.14.1-1
ii  libpango-1.0-0 1.40.2-1
ii  libpangocairo-1.0-01.40.2-1
ii  libsm6 2:1.2.2-1+b1
ii  libstartup-notification0   0.12-4
ii  libvte-2.91-0  0.44.2-1
ii  libx11-6   2:1.6.3-1
ii  mate-desktop-common1.14.1-1
ii  mate-terminal-common   1.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#836238: no command line prompt visible after updating GTK+3 to 3.21.5-1

[Viktor Jägersküpper]

Package: mate-terminal
Version: 1.14.1-1
Severity: important

Dear Maintainer,

after updating the GTK+3 packages from version 3.20.9-1 to version
3.21.5-1 the command line prompt of mate-terminal is not displayed (just
white background). Commands are executed although they are not visible.
Downgrading the GTK+3 packages makes the bug disappear.

Please tell me if I should give you more information, maybe how I can
debug this.

Regards
Viktor



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

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

Versions of packages mate-terminal depends on:
ii  gsettings-desktop-schemas  3.21.4-2
ii  libatk1.0-02.20.0-1
ii  libc6  2.23-5
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.49.6-1
ii  libgnutls303.5.3-3
ii  libgtk-3-0 3.21.5-1
ii  libice62:1.0.9-1+b1
ii  libmate-desktop-2-17   1.14.1-1
ii  libpango-1.0-0 1.40.2-1
ii  libpangocairo-1.0-01.40.2-1
ii  libsm6 2:1.2.2-1+b1
ii  libstartup-notification0   0.12-4
ii  libvte-2.91-0  0.44.2-1
ii  libx11-6   2:1.6.3-1
ii  mate-desktop-common1.14.1-1
ii  mate-terminal-common   1.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#835119: tor client does not immediately open new circuits after standby

[Viktor Jägersküpper]

found 835119 0.2.8.2-alpha-1
thanks

I tested different versions again yesterday and today, this time only
0.2.7.6-1, 0.2.8.2-alpha-1 and 0.2.9.1-alpha-1 and I had several "long"
standby sessions. The results are again confusing, the 0.2.7 series
doesn't seem to have the issue, but it occurs in the 0.2.8 series and
also in the version 0.2.9.1-alpha-1 which also worked "normally" one
time, as you can see in the complete log of yesterday and today.
Aug 23 10:47:41.305 [notice] Tor v0.2.7.6 (git-605ae665009853bd) running on 
Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib 1.2.8.
Aug 23 10:47:41.305 [notice] Tor can't help you if you use it wrong! Learn how 
to be safe at https://www.torproject.org/download/download#warning
Aug 23 10:47:41.305 [notice] Read configuration file 
"/usr/share/tor/tor-service-defaults-torrc".
Aug 23 10:47:41.305 [notice] Read configuration file "/etc/tor/torrc".
Aug 23 10:47:41.308 [notice] Opening Socks listener on 127.0.0.1:9050
Aug 23 10:47:41.308 [notice] Opening Control listener on /var/run/tor/control
Aug 23 10:47:41.000 [notice] Bootstrapped 0%: Starting
Aug 23 10:47:41.000 [notice] Signaled readiness to systemd
Aug 23 10:47:42.000 [notice] Bootstrapped 5%: Connecting to directory server
Aug 23 10:47:42.000 [notice] Bootstrapped 10%: Finishing handshake with 
directory server
Aug 23 10:47:43.000 [notice] Bootstrapped 15%: Establishing an encrypted 
directory connection
Aug 23 10:47:43.000 [notice] Bootstrapped 20%: Asking for networkstatus 
consensus
Aug 23 10:47:44.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Aug 23 10:47:45.000 [notice] I learned some more directory information, but not 
enough to build a circuit: We have no usable consensus.
Aug 23 10:47:46.000 [notice] Bootstrapped 40%: Loading authority key certs
Aug 23 10:47:47.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 23 10:47:47.000 [notice] I learned some more directory information, but not 
enough to build a circuit: We need more microdescriptors: we have 0/6976, and 
can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, 
and 0% of exit bw = 0% of path bw.)
Aug 23 10:47:47.000 [notice] Bootstrapped 50%: Loading relay descriptors
Aug 23 10:47:49.000 [notice] Bootstrapped 55%: Loading relay descriptors
Aug 23 10:47:49.000 [notice] Bootstrapped 62%: Loading relay descriptors
Aug 23 10:47:49.000 [notice] Bootstrapped 68%: Loading relay descriptors
Aug 23 10:47:49.000 [notice] Bootstrapped 74%: Loading relay descriptors
Aug 23 10:47:50.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 23 10:47:50.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Aug 23 10:47:50.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 23 10:47:50.000 [notice] Bootstrapped 100%: Done
Aug 23 10:51:51.000 [notice] Interrupt: exiting cleanly.
Aug 23 10:51:59.000 [notice] Tor 0.2.7.6 (git-605ae665009853bd) opening log 
file.
Aug 23 10:51:58.971 [warn] OpenSSL version from headers does not match the 
version we're running with. If you get weird crashes, that might be why. 
(Compiled with 1000205f: OpenSSL 1.0.2e 3 Dec 2015; running with 1000208f: 
OpenSSL 1.0.2h  3 May 2016).
Aug 23 10:51:59.012 [notice] Tor v0.2.7.6 (git-605ae665009853bd) running on 
Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib 1.2.8.
Aug 23 10:51:59.012 [notice] Tor can't help you if you use it wrong! Learn how 
to be safe at https://www.torproject.org/download/download#warning
Aug 23 10:51:59.012 [notice] Read configuration file 
"/usr/share/tor/tor-service-defaults-torrc".
Aug 23 10:51:59.012 [notice] Read configuration file "/etc/tor/torrc".
Aug 23 10:51:59.018 [notice] Opening Socks listener on 127.0.0.1:9050
Aug 23 10:51:59.019 [notice] Opening Control listener on /var/run/tor/control
Aug 23 10:51:59.000 [notice] Bootstrapped 0%: Starting
Aug 23 10:51:59.000 [notice] Bootstrapped 5%: Connecting to directory server
Aug 23 10:51:59.000 [warn] Problem bootstrapping. Stuck at 5%: Connecting to 
directory server. (Network is unreachable; NOROUTE; count 1; recommendation 
warn; host 9EEAA02E338CDF5919F983F3245AA95A790B9B6C at 89.46.100.71:443)
Aug 23 10:51:59.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 23 10:51:59.000 [notice] Signaled readiness to systemd
Aug 23 10:51:59.000 [warn] Problem bootstrapping. Stuck at 80%: Connecting to 
the Tor network. (Network is unreachable; NOROUTE; count 2; recommendation 
warn; host 1C90D3AEADFF3BCD079810632C8B85637924A58E at 62.210.82.44:21)
Aug 23 10:52:00.000 [warn] Problem bootstrapping. Stuck at 80%: Connecting to 
the Tor network. (Network is unreachable; NOROUTE; count 3; recommendation 
warn; host 86E78DD3720C78DA8673182EF96C54B162CD660C at 62.210.124.124:9001)
Aug 23 10:52:01.000 [warn] Problem bootstrapping. Stuck at 80%: Connecting to 
the Tor network. (Network is unreachable; NOROUTE; count 4; recommendation 
warn; host 

Bug#835341: mutt 1.6.2-3 has wrong dependencies

[Viktor Jägersküpper]

Package: mutt
Version: 1.6.2-3
Severity: serious

Dear Maintainer,

the latest version of mutt has somehow got wrong dependencies (from an
older version I guess) and so is not installable in unstable or testing.

# apt-get install mutt
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mutt : Depends: libgnutls-deb0-28 (>= 3.3.0) but it is not installable
Depends: libnotmuch3 (>= 0.13~rc1) but it is not installable
E: Unable to correct problems, you have held broken packages.

Version 1.6.2-2 depends on

libgnutls30 (>=3.5.0)
libnotmuch4 (>=0.21~rc1)

These should be correct.

Regards
Viktor

Bug#835119: tor client does not immediately open new circuits after standby

[Viktor Jägersküpper]

Package: tor
Version: 0.2.8.6-3
Severity: normal

Dear Maintainer,

I use tor only as a client to connect icedove to the tor network with
the extension Torbirdy (on port 9050). With the tor version 0.2.8.6 I
can't immediately connect to any mail server or news feed after the pc
woke up from standby ("long" time in standby) and I started icedove. I
have to wait for several minutes in order to connect successfully, but
the timespan seems to be random. This does not occur after a (re)boot.
The first version I remember to have this issue is 0.2.8.6-2, I did an
upgrade from 0.2.7.6-1 to 0.2.8.6-2, so I skipped the alpha and rc
versions and the first upload to unstable. I am very sure that the issue
didn't occur in version 0.2.7.6-1 which I used for several months. I can
exclude network connectivity problems because e.g. I can immediately
start the Tor Browser after standby.

Today I purged tor, installed version 0.2.7.6-1, copied the old "state"
file to /var/lib/tor, and set the pc in standby mode for a couple of
minutes. After waking up from standby I immediately tried to connect to
a mail server which worked. Then I upgraded step by step to every
version of tor 0.2.8 which I could find on snapshot.debian.org and tried
to connect to a mail server immediately after waking up from standby.
Unfortunately I could not reproduce the bug then. Finally with version
0.2.8.6-3 the bug occured again, but only after a "long" standby time
(almost 90 minutes).

Attached are two log files from the weekend and the complete log from
today after the installation of version 0.2.7.6-1.

As you can see, the bug is not easily reproducible, and the logs don't
show any particular reason for why tor does not open new circuits
immediately. Please tell me what I can do to give you more information
about the bug.

Regards
Viktor



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

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

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.42
ii  libc62.23-4
ii  libevent-2.0-5   2.0.21-stable-2+b1
ii  libseccomp2  2.3.1-2
ii  libssl1.0.2  1.0.2h-1
ii  libsystemd0  231-4
ii  lsb-base 9.20160629
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages tor recommends:
ii  logrotate3.8.7-2
pn  tor-geoipdb  
pn  torsocks 

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  obfsproxy
pn  socat
ii  tor-arm  1.4.5.0-1.1
pn  torbrowser-launcher  

-- no debconf information
Aug 20 11:24:43.000 [notice] Tor 0.2.8.6 (git-89d2e261a925c6a6) opening new log 
file.
Aug 20 11:26:50.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 11:26:50.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 13:52:10.000 [notice] Your system clock just jumped 3486 seconds 
forward; assuming established circuits no longer work.
Aug 20 13:58:21.000 [notice] No circuits are opened. Relaxed timeout for 
circuit 22 (a General-purpose client 1-hop circuit in state doing handshakes 
with channel state open) to 337950ms. However, it appears the circuit has timed 
out anyway. 12 guards are live.
Aug 20 14:17:42.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 14:17:42.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 17:26:02.000 [notice] Your system clock just jumped 10956 seconds 
forward; assuming established circuits no longer work.
Aug 20 17:31:55.000 [notice] No circuits are opened. Relaxed timeout for 
circuit 29 (a General-purpose client 1-hop circuit in state doing handshakes 
with channel state open) to 337950ms. However, it appears the circuit has timed 
out anyway. 13 guards are live.
Aug 20 17:32:16.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 17:32:16.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Aug 20 20:03:52.000 [notice] Your system clock just jumped 3806 seconds 
forward; assuming established circuits no longer work.
Aug 20 20:08:13.000 [notice] Tried for 120 seconds to get a connection to 
[scrubbed]:993. Giving up. (waiting for circuit)
Aug 20 20:10:18.000 [notice] Tried for 120 seconds to get a connection to 
[scrubbed]:993. Giving up. (waiting for circuit)
Aug 20 20:11:52.000 [notice] No circuits are opened. Relaxed timeout for 
circuit 40 (a General-purpose client 3-hop circuit in state doing handshakes 
with channel state 

Bug#833698: Icedove 1:45.2.0-2+b1 (Debian Testing) SegFault

[Viktor Jägersküpper]

Everybody who reads only this bug report, please consider my workaround
mentioned in bug 833532:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833532#50

Bug#833864: icedove: Crash on big folders

[Viktor Jägersküpper]

Dear Jean-Philippe,

from my point of view (I am not a developer) it looks like this is the
same bug as 833532 (and the merged bugs). I suggest you to set
"javascript.options.baselinejit" to "false" in about:config. If this
fixes your problem, this is an indicator that your bug is the same as
833532. I think you have to set this option in safe mode because for me
icedove crashes when I try to open about:config with version
1:45.2.0-2+b1. Or you downgrade to an older version of icedove, set the
option and then upgrade again to test it.

Regards
Viktor

Bug#833532: Rebuild against libicu57 causes icedove to crash

[Viktor Jägersküpper]

In case anyone is not able to use a version prior to 1:45.2.0-2+b1, and
since this version is in testing now, I tried a workaround and set
"javascript.options.baselinejit" to "false" in about:config. This worked
for me so far.

Bug#833532: Rebuild against libicu57 causes icedove to crash

[Viktor Jägersküpper]

I analyzed the problem a bit more. I use the extension "ThunderBirthDay"
which creates a calendar with the birthday dates found in my address book.

If there is such a calendar, icedove crashes at startup. If there is no
such calendar, icedove starts normally.

Even with all extensions, plugins and language packs disabled icedove
still crashes when I want to open about:config. With all my extensions
and the two german language packs for icedove and iceowl-extension
enabled, icedove also crashes when I want to open about:config.

Only in safe mode icedove does neither crash at startup nor when opening
about:config.

Attached are the full logs I got with gdb for the two cases when icedove
crashes. Both times all extensions and language packs were enabled.

If I can give you more information, e.g. file system activity or
anything else, tell me.

Viktor
MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
GNU gdb (Debian 7.11.1-2) 7.11.1
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 /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) handle SIGPIPE nostop
SignalStop	Print	Pass to program	Description
SIGPIPE   No	Yes	Yes		Broken pipe
(gdb) handle SIG38 nostop
SignalStop	Print	Pass to program	Description
SIG38 No	Yes	Yes		Real-time event 38
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5cd2700 (LWP 7597)]
[Thread 0x7fffe5cd2700 (LWP 7597) exited]
[New Thread 0x7fffe5cd2700 (LWP 7601)]
[New Thread 0x7fffdbfff700 (LWP 7602)]
[New Thread 0x77fed700 (LWP 7603)]
[New Thread 0x7fffdb7fe700 (LWP 7604)]
[New Thread 0x7fffdacff700 (LWP 7605)]
[New Thread 0x7fffdaafe700 (LWP 7606)]
[New Thread 0x7fffda8fd700 (LWP 7607)]
[New Thread 0x7fffda6fc700 (LWP 7608)]
[New Thread 0x7fffda4fb700 (LWP 7609)]
[New Thread 0x7fffda2fa700 (LWP 7610)]
[New Thread 0x7fffd8fff700 (LWP 7611)]
[New Thread 0x7fffd827f700 (LWP 7612)]
[New Thread 0x7fffd7a7e700 (LWP 7613)]
[New Thread 0x7fffdafa6700 (LWP 7614)]
[New Thread 0x7fffd6eff700 (LWP 7615)]
[New Thread 0x7fffd5b69700 (LWP 7616)]
[New Thread 0x7fffd5368700 (LWP 7617)]
[New Thread 0x7fffd2eff700 (LWP 7618)]
TorBirdy registered!
[calBackendLoader] Using libical backend at /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
[New Thread 0x7fffd18ff700 (LWP 7619)]
[New Thread 0x7fffd0a8f700 (LWP 7620)]
[New Thread 0x7fffcf6ff700 (LWP 7621)]
[New Thread 0x7fffceefe700 (LWP 7622)]
[New Thread 0x7fffce6fd700 (LWP 7623)]
[New Thread 0x7fffcdefc700 (LWP 7624)]
[New Thread 0x7fffcd6fb700 (LWP 7625)]
[New Thread 0x7fffccefa700 (LWP 7626)]
[New Thread 0x7fffcbaff700 (LWP 7627)]
[New Thread 0x7fffcb2fe700 (LWP 7628)]
[New Thread 0x7fffcaafd700 (LWP 7629)]
[New Thread 0x7fffca2fc700 (LWP 7630)]
[New Thread 0x7fffc9afb700 (LWP 7631)]
[Thread 0x7fffcaafd700 (LWP 7629) exited]
[Thread 0x7fffca2fc700 (LWP 7630) exited]
[Thread 0x7fffc9afb700 (LWP 7631) exited]
[New Thread 0x7fffc90ff700 (LWP 7632)]
[New Thread 0x7fffc9afb700 (LWP 7633)]
[New Thread 0x7fffca2fc700 (LWP 7634)]
[Thread 0x7fffca2fc700 (LWP 7634) exited]
[New Thread 0x7fffca2fc700 (LWP 7635)]
[Thread 0x7fffca2fc700 (LWP 7635) exited]
[New Thread 0x7fffca2fc700 (LWP 7636)]
[New Thread 0x7fffcaafd700 (LWP 7637)]
[Thread 0x7fffd2eff700 (LWP 7618) exited]
[Thread 0x7fffcaafd700 (LWP 7637) exited]
[New Thread 0x7fffcaafd700 (LWP 7638)]
[New Thread 0x7fffd2eff700 (LWP 7639)]
[Thread 0x7fffcaafd700 (LWP 7638) exited]
[Thread 0x7fffd2eff700 (LWP 7639) exited]
[New Thread 0x7fffd2eff700 (LWP 7640)]
[Thread 0x7fffd2eff700 (LWP 7640) exited]
[New Thread 0x7fffd2eff700 (LWP 7641)]
[Thread 0x7fffca2fc700 (LWP 7636) exited]

Thread 1 "icedove-bin" received signal SIGSEGV, Segmentation 

Bug#833532: Rebuild against libicu57 causes icedove to crash

[Viktor Jägersküpper]

Dear Maintainers,

I assume my problem is related to this bug. After the last upgrade from
1:45.2.0-2 to 1:45.2.0-2+b1 icedove does not start or crashes reliably.
I found the following behaviour (plugins are always disabled):

- with iceowl-extension and its german language pack enabled icedove
fails to start
- with iceowl-extension and its german language pack disabled icedove
starts, but crashes when I click on the "I'll be careful, I promise!"
button for about:config. I didn't try much more.
- in safe-mode icedove starts and I could click on the button. I didn't
try much more.

On the command line I get "Speicherzugriffsfehler" when icedove fails to
start or crashes, is this a segmentation fault?

I had no problems with version 1:45.2.0-2. So I suspect the rebuild
against libicu57 causes these problems. Note that I have not installed
the calendar-google-provider addon.

Please tell me if I can help you with more information. I am just a
user, but maybe I am able to help.

Regards
Viktor