Bug#907902: [Pkg-utopia-maintainers] Bug#907902: network-manager-openvpn won't save changes in username or password

[Jape Person]

On 09/03/2018 11:38 PM, Michael Biebl wrote:


On 9/4/18 05:34, Michael Biebl wrote:

This is what I'm getting on the console:

** Message: 05:28:17.858: Cannot save connection due to error: Invalid
setting VPN: ca: No key set


Nvm, seems to be a genuine upstream issue, see
https://gitlab.gnome.org/GNOME/network-manager-applet/issues/20

Aha! I need to remember to search outside of the Debian bug reports when 
I have an issue like this.


Thank you very much for your help.

And let me thank you for all of the hard work you do, and for the 
excellent information you've provided by writing and speaking.


Best regards,
JP

Bug#907902: [Pkg-utopia-maintainers] Bug#907902: network-manager-openvpn won't save changes in username or password

[Jape Person]

On 09/03/2018 07:22 PM, Michael Biebl wrote:

On 9/4/18 00:25, Jape Person wrote:

The software gives no indication that anything is wrong other than the
fact that the "Editing " dialog that
comes up doesn't activate the "Save" button when I change the contents
of the user name or password fields.


Can you share such a .ovpn file?



Of Course. Attached is an example.

These are pre-rolled .ovpn files downloaded from Torguard. (I preferred 
using the openvpn packages available from Debian repositories to 
downloading and installing the Linux client that Torguard provides.)



client
dev tun
proto udp
remote sa.west.usa.torguardvpnaccess.com 1912
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-auth ta.key 1
auth SHA256
cipher AES-128-CBC
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
fast-io
# Uncomment these directives if you have speed issues
;sndbuf 393216
;rcvbuf 393216
;push "sndbuf 393216"
;push "rcvbuf 393216"

Bug#907902: [Pkg-utopia-maintainers] Bug#907902: network-manager-openvpn won't save changes in username or password

[Jape Person]

On 09/03/2018 05:42 PM, Michael Biebl wrote:

Control: tags -1 moreinfo unreproducible

On 9/3/18 23:14, Jape Person wrote:

Package: network-manager-openvpn
Version: 1.8.4-1
Severity: important

Dear Maintainer,


To duplicate the issue, use Edit Connections function of network-manager.

Attempt to edit an imported openvpn configuration. Changes can be made to the
user name and password fields, but the Save button on the dialog never becomes
active.


Which program do you use to update the configuration,
nm-connection-editor, something else?
If you run that command from the command line, do you get any output?
Which environment do you run this program, GNOME, KDE etc?

Is the password saved per user (agent-owned) or system wide?


Sorry, I used the little gtk reporter and didn't notice it wasn't 
including info about the DE.


I'm using Xfce, and editing the configuration using the dialog named 
"Network Connections" that's called by right-clicking the NM icon in the 
notification Area on the panel and choosing Edit Connections.


The program is nm-connection-editory. When issued from within 
xfce4-terminal it results in this output:


wiz@wiz-nuc:~$ nm-connection-editor

(nm-connection-editor:7415): dbind-WARNING **: 18:13:19.754: Couldn't 
register with accessibility bus: Did not receive a reply. Possible 
causes include: the remote application did not send a reply, the message 
bus security policy blocked the reply, the reply timeout expired, or the 
network connection was broken.


The software gives no indication that anything is wrong other than the 
fact that the "Editing " dialog that 
comes up doesn't activate the "Save" button when I change the contents 
of the user name or password fields.


That dialog lets you choose between saving the password for the current 
user or for all users. I've been accustomed to using the all users setting.

Bug#907902: network-manager-openvpn won't save changes in username or password

[Jape Person]

Package: network-manager-openvpn
Version: 1.8.4-1
Severity: important

Dear Maintainer,


To duplicate the issue, use Edit Connections function of network-manager.

Attempt to edit an imported openvpn configuration. Changes can be made to the
user name and password fields, but the Save button on the dialog never becomes
active.

Functions of openvpn appear normal otherwise.

This behavior is weird enough that I'm tempted to suspect apparmor.

Apparmor, network-manager, openvpn, etc. have all been updated several times
recently. No idea when the problem appeared exactly, but has to have been
since end of July. I changed user names and passwords on all openvpn configur-
ations at that time with no difficulty.



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

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

Versions of packages network-manager-openvpn depends on:
ii  adduser  3.117
ii  libc62.27-5
ii  libglib2.0-0 2.56.1-2
ii  libnm0   1.12.2-2
ii  network-manager  1.12.2-2
ii  openvpn  2.4.6-1

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#904950: Bug apparently resolved in version 1:6.1.0-1

[Jape Person]

testing systems upgraded today (08/15/2018) eliminated the issue reported

Thanks!

Bug#904950: libreoffice: lost ability to remove single files from Recent Files dialog

[Jape Person]

Package: libreoffice
Version: 1:6.1.0~rc2-3
Severity: normal

Dear Maintainer,

In previous recent versions of Libreoffice, placing mouse cursor over a
thumbnail in the Recent Files dialog would cause an "X" to appear in the upper
right corner of the thumbnail. Clicking on this "X" would delete only the
chosen file from the Recent Files list. Very nice feature. It's gone in the
recent upgrade to version 1:6.1.0-rc2-3. I hope this was a regression instead
of a feature change. Most gtk recent files menus became more of a nuisance than
a help a few years ago. The recent files menu of of Libreoffice was a welcome
exception.

If not a regression, then I guess this is a wishlist bug.

Thanks!



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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.0~rc2-3
ii  libreoffice-base   1:6.1.0~rc2-3
ii  libreoffice-calc   1:6.1.0~rc2-3
ii  libreoffice-core   1:6.1.0~rc2-3
ii  libreoffice-draw   1:6.1.0~rc2-3
ii  libreoffice-impress1:6.1.0~rc2-3
ii  libreoffice-math   1:6.1.0~rc2-3
ii  libreoffice-report-builder-bin 1:6.1.0~rc2-3
ii  libreoffice-writer 1:6.1.0~rc2-3
ii  python3-uno1:6.1.0~rc2-3

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-7
ii  fonts-liberation2   2.00.1-7
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-hinted   20171026-2
ii  fonts-noto-mono 20171026-2
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.1.0~rc2-3
ii  libreoffice-librelogo   1:6.1.0~rc2-3
ii  libreoffice-nlpsolver   0.9+LibO6.1.0~rc2-3
ii  libreoffice-ogltrans1:6.1.0~rc2-3
ii  libreoffice-report-builder  1:6.1.0~rc2-3
ii  libreoffice-script-provider-bsh 1:6.1.0~rc2-3
ii  libreoffice-script-provider-js  1:6.1.0~rc2-3
ii  libreoffice-script-provider-python  1:6.1.0~rc2-3
ii  libreoffice-sdbc-postgresql 1:6.1.0~rc2-3
ii  libreoffice-wiki-publisher  1.2.0+LibO6.1.0~rc2-3

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.8-5
ii  default-jre [java6-runtime] 2:1.10-67
ii  firefox-esr 52.9.0esr-1
ii  ghostscript 9.22~dfsg-2.1
ii  gnupg   2.2.9-1
pn  gpa 
ii  gstreamer1.0-libav  1.15.0.1+git20180723+db823502-1
ii  gstreamer1.0-plugins-bad1.14.2-1
ii  gstreamer1.0-plugins-base   1.14.2-1
ii  gstreamer1.0-plugins-good   1.14.2-1
ii  gstreamer1.0-plugins-ugly   1.14.2-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-5
ii  imagemagick 8:6.9.10.2+dfsg-3
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.2+dfsg-3
ii  libgl1  1.0.0+git20180308-3
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.25-4.1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.0.5-1
pn  openclipart2-libreoffice | openclipart-lib  
ii  openjdk-10-jre [java6-runtime]  10.0.2+13-1
ii  openjdk-8-jre [java6-runtime]   8u171-b11-2
pn  pstoedit
ii  thunderbird 1:52.9.1-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-5
ii  fonts-opensymbol  2:102.10+LibO6.1.0~rc2-3
ii  libboost-date-time1.62.0  1.62.0+dfsg-8
ii  libboost-locale1.62.0 1.62.0+dfsg-8
ii  libc6 2.27-5
ii  libcairo2 1.15.10-3
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   

Bug#892229: wireless-regdb: incompatible with Linux kernel 4.15

[Jape Person]

On 04/05/2018 12:00 PM, Ben Hutchings wrote:
> On Thu, 2018-04-05 at 11:50 -0400, Jape Person wrote:
>> On 04/05/2018 03:43 AM, Ben Hutchings wrote:
>>> On Wed, 2018-04-04 at 19:57 -0400, Jape Person wrote:
>>>> In addition to these findings, has anyone noticed this having an
>>>> adverse effect on file transfers? I suspect what I have seen is
>>>> due to my particular wireless hardware.
>>>
>>> [...]
>>>
>>> This is almost certainly an unrelated regression in the wireless
>>> driver.
>>>
>>> Ben.
>>>
>>
>> Of course, that makes more sense. I wonder if the problem with
>> the driver is elicited by the failure of the regulatory.db to be
>> loaded.
> 
> It still gets loaded by crda, so I don't think so.
> 
>> I don't know enough about this to have any real idea. Should I
>> attempt to report a bug against the driver?
> 
> Yes, you can submit a bug report about the driver upstream
> (linux-wirel...@vger.kernel.org).
> 
> Ben.
> 
I shall endeavor to do so!

Best regards,
JP

Bug#892229: wireless-regdb: incompatible with Linux kernel 4.15

[Jape Person]

On 04/05/2018 03:43 AM, Ben Hutchings wrote:
> On Wed, 2018-04-04 at 19:57 -0400, Jape Person wrote:
>> In addition to these findings, has anyone noticed this having an
>> adverse effect on file transfers? I suspect what I have seen is
>> due to my particular wireless hardware.
> [...]
> 
> This is almost certainly an unrelated regression in the wireless
> driver.
> 
> Ben.
> 
Of course, that makes more sense. I wonder if the problem with
the driver is elicited by the failure of the regulatory.db to be
loaded.

I don't know enough about this to have any real idea. Should I
attempt to report a bug against the driver?

Thank you for your reply.

JP

Bug#892229: wireless-regdb: incompatible with Linux kernel 4.15

[Jape Person]

In addition to these findings, has anyone noticed this having an
adverse effect on file transfers? I suspect what I have seen is
due to my particular wireless hardware. (I didn't experiment
with Ethernet connections.)

I used

# sysctl net.ipv4.tcp_congestion_control=cubic

to switch tcp_congestion_control from bbr to cubic. This improve
file transfer speeds between my Debian testing system by roughly
100X on my LAN.

Just posting a note to indicate that -- at least for some people
-- this is a pretty serious bug.

Thanks,
JP

Bug#857198: Additional Information

[Jape Person]

I reported that I was seeing slow echo of characters back to my terminal 
emulator windows when using SSH connections between these systems. I 
reported it because I thought it was possible that this behavior might 
possibly be caused by substandard performance of the wireless adapters 
due to lack of firmware support.


Some research I did indicated that the Intel Corporation Iris Graphics 
6100 (rev 09) adapters might work better if I removed the 
xserver-xorg-video-intel package from the systems so that modesetting 
was handled directly by the hardware. That turns out to be correct, and 
all delay in character echo from remote systems over SSH has been 
eliminated.


So -- the only symptom I can now report on this bug is the fact that the 
recent firmware doesn't load. Don't know what the consequences of that 
-- other than the error messages -- might be.

Bug#857198: firmware-iwlwifi: iwlwifi firmware load failures for Intel Corporation Wireless 7265 (rev 59)

[Jape Person]

Package: firmware-iwlwifi
Version: 20161130-2
Severity: minor

Dear Maintainer,

The following is reported in dmesg after each boot of the systems use this 
adaptor.

4.004680] iwlwifi :02:00.0: firmware: failed to load iwlwifi-7265D-26.ucode 
(-2)
[4.004686] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-7265D-26.ucode failed with error -2
[4.004699] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-7265D-25.ucode (-2)
[4.004703] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-7265D-25.ucode failed with error -2
[4.004712] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-7265D-24.ucode (-2)
[4.004714] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-7265D-24.ucode failed with error -2
[4.004723] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-7265D-23.ucode (-2)
[4.004726] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-7265D-23.ucode failed with error -2
[4.006712] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[4.010201] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-7265D-22.ucode
[4.010487] iwlwifi :02:00.0: loaded firmware version 22.361476.0 
op_mode iwlmvm

Functionality of the wifi adaptors is not compromised seriously, but they do 
occasionally lose connection
when other wifi adaptors are having no issues with the network.

There is also an odd delay of a fraction of a second in echo of characters to 
screen over SSH connections to
these systems. No such delay occurs when connecting to systems with different 
adaptors. It's like the old
days on CompuServe!

8-)

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.127

-- no debconf information

Bug#843693: Fwd: Re: Bug#843693: sddm: starting sddm results in white screen with active cursor and keyboard

[Jape Person]

Sincere apologies for not sending this properly before. I thought I 
received an acknowledgment from the bug system, but I must have sent 
only to Maximiliano.


Forgive the delay in sending this information properly.


 Forwarded Message 
Subject: Re: Bug#843693: sddm: starting sddm results in white screen 
with active cursor and keyboard

Date: Tue, 8 Nov 2016 20:09:50 -0500
From: Jape Person <jap...@comcast.net>
To: Maximiliano Curia <m...@debian.org>

On 11/08/2016 05:48 PM, Maximiliano Curia wrote:

Control: severity -1 important

¡Hola Jape!



Hello, Maximiliano!


ii  sddm-theme-breeze [sddm-theme]  4:5.8.2-1


The breeze theme causes sddm to use the composite mode, this has caused issues
with certain graphical cards in the past. Could you try installing
sddm-theme-maui and removing sddm-theme-breeze?

Also, could you share the output of:
 lspci -vnn | grep VGA -A 12

Happy hacking,



# lspci -vnn | grep VGA -A 12

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV17 
[GeForce4 MX 440] [10de:0171] (rev a3) (prog-if 00 [VGA controller])
  Subsystem: ASUSTeK Computer Inc. NV17 [GeForce4 MX 440] 
[1043:a000]

  Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
  Memory at e700 (32-bit, non-prefetchable) [size=16M]
  Memory at f000 (32-bit, prefetchable) [size=128M]
  Memory at ef80 (32-bit, prefetchable) [size=512K]
  Expansion ROM at 000c [disabled] [size=128K]
  Capabilities: [60] Power Management version 2
  Capabilities: [44] AGP version 2.0
  Kernel driver in use: nouveau
  Kernel modules: nouveau

I did use apt to install sddm-theme-maui 0.13.0-1 and to purge 
sddm-theme-breeze.


I used dpkg-reconfigure to switch from xdm back to sddm, but I still am 
getting a white screen. Mouse cursor is present and reacts to mouse 
movement, and keyboard is functional (can be used to cycle through 
virtual terminals).


Other systems here are not having this trouble with sddm, so I can 
certainly believe that the old nvidia card is the source of the trouble.


Please let me know if I can provide any more information.

Best regards,
Jape

Bug#843693: sddm: starting sddm results in white screen with active cursor and keyboard

[Jape Person]

Package: sddm
Version: 0.13.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Installed task-lxqt-desktop. Replacement of lightdm by sddm resulted in 
inability
to log in. Screen presented is all white, but cursor is visible, and keyboard
functions appear to be intact.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Reconfigured to use lightdm and was able to log in to the system. Removed 
lightdm,
installed xdm, and that was also successful for logging in.

   * What was the outcome of this action?

Have left system temporarily configured to use xdm until sddm is fixed.

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

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

Versions of packages sddm depends on:
ii  adduser 3.115
ii  debconf [debconf-2.0]   1.5.59
ii  libc6   2.24-5
ii  libgcc1 1:6.2.0-10
ii  libpam0g1.1.8-3.3
ii  libqt5core5a5.6.1+dfsg-3+b1
ii  libqt5dbus5 5.6.1+dfsg-3+b1
ii  libqt5gui5  5.6.1+dfsg-3+b1
ii  libqt5network5  5.6.1+dfsg-3+b1
ii  libqt5qml5  5.6.1-11
ii  libqt5quick55.6.1-11
ii  libstdc++6  6.2.0-10
ii  libsystemd0 231-9
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  qml-module-qtquick2 5.6.1-11
ii  sddm-theme-breeze [sddm-theme]  4:5.8.2-1

Versions of packages sddm recommends:
ii  libpam-systemd  231-9

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.2-1

-- debconf information:
* shared/default-x-display-manager: xdm
  sddm/daemon_name: /usr/bin/sddm

Bug#842080: [pkg-lxqt-devel] Bug#842080: Bug#842080: additional information

[Jape Person]

On 10/25/2016 04:26 PM, Alf Gaida wrote:

On Tue, 25 Oct 2016 15:53:48 -0400
Jape Person <jap...@comcast.net> wrote:

Do you suppose that my slightly odd system configuration could
be at fault? I do not have any of the regular desktop

No, not relly - that was my fault


Please let me know if there's anything I might do from a testing
standpoint. I might try grabbing libfm-qt3 from sid to see if

The sid package will fix it, there are 10 new symbols in the new
lib, but it seems that they are not called directly so dh had no
chance to calculate the dependencies right. Have to learn about it.

I do like pcmanfm-qt. Like the rest of the lxqt stuff it's very
fast and responsive. It has required me to adjust some habits. I
had figured out how to use thunar in the Xfce desktop
environment without ever touching the mouse, and I don't seem
able to do that with pcmanfm. Then again, I haven't had a lot of
time to explore it.

Glad you like it. If there are missed functions or things we can
improve we will be glad if you write a request here:
https://github.com/lxde/pcmanfm-qt/issues

Cheers Alf


Okay, I'll grab the libfm-qt3 version from sid.

Thank you for your work on FOSS, and for your helpfulness in 
this matter.


Folks like you are treasures to the world community. That's not 
an exaggeration. Throughout history, the people who fashion 
tools have made it possible for all of us to have better lives.


Regards,
JP

Bug#842080: [pkg-lxqt-devel] Bug#842080: additional information

[Jape Person]

On 10/25/2016 02:50 PM, Alf Gaida wrote:



8<
** Message: x-terminal-emulator has very limited support, consider
choose another terminal

** (process:6455): WARNING **: XDG_TEMPLATES_DIR is set to invalid
path, ignoring it
8<


You can ignore this message - both messages are misleading warnings and
can be ignored - i try to reproduce the crash  - it should not happend
and is not happend with my former tests. A possible solution might be to
take libfm-qt3 from sid but that should not needed™ - anyways, thanks
for the report



Hi,

Do you suppose that my slightly odd system configuration could 
be at fault? I do not have any of the regular desktop 
environment metapackages installed but am, instead, using lxqt 
components along with the supporting packages for gtk 
applications. My DM is lightdm, and I'm using the 
lightdm-gtk-greeter for login. (My understanding is that we 
don't yet have a qt version of the greeter available in the repos.)


Please let me know if there's anything I might do from a testing 
standpoint. I might try grabbing libfm-qt3 from sid to see if 
that makes a difference, but I'm in the midst of a move from one 
home to another, so time and mental resources are a little taxed 
at the moment.


I do like pcmanfm-qt. Like the rest of the lxqt stuff it's very 
fast and responsive. It has required me to adjust some habits. I 
had figured out how to use thunar in the Xfce desktop 
environment without ever touching the mouse, and I don't seem 
able to do that with pcmanfm. Then again, I haven't had a lot of 
time to explore it.


Thanks for the information and your suggestion.

JP

Bug#842080: additional information

[Jape Person]

I should have included in the original bug report that starting 
pcmanfm-qt from a terminal emulator results in the following:


8<
** Message: x-terminal-emulator has very limited support, 
consider choose another terminal


** (process:6455): WARNING **: XDG_TEMPLATES_DIR is set to 
invalid path, ignoring it

8<

I realize that this means that something is wrong with the 
environment, but I haven't had to explore the cause or try 
correcting it.


Please advise.

Thanks.

Bug#842080: pcmanfm-qt: Attempting any action on a file or folder causes immediate crash.

[Jape Person]

Package: pcmanfm-qt
Version: 0.11.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
update on 10/24/2016 from version 0.11.0-10 to 0.11.102
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
absolutely nothing that I can do from within the sofware will keep it 
from crashing the instant
a file or folder is selected.
   * What was the outcome of this action?
NA
   * What outcome did you expect instead?
I expected the file manager to continue working.

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

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

Versions of packages pcmanfm-qt depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.12-1
ii  dbus-x11 [dbus-session-bus]   1.10.12-1
ii  libc6 2.24-5
ii  libfm-modules 1.2.4-1
ii  libfm-qt3 0.11.0-2+b1
ii  libfm41.2.4-1
ii  libglib2.0-0  2.50.1-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5dbus5   5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libqt5x11extras5  5.6.1-2
ii  libstdc++66.2.0-6
ii  libxcb1   1.12-1

Versions of packages pcmanfm-qt recommends:
ii  breeze-icon-theme  4:5.27.0-1
ii  gksu   2.0.2-9
ii  gnome-icon-theme   3.12.0-2
ii  gvfs-backends  1.30.1.1-1
ii  lxqt-sudo  0.11.0-2
ii  oxygen-icon-theme  5:5.27.0-1
pn  pcmanfm-qt-l10n

pcmanfm-qt suggests no packages.

-- no debconf information

Bug#765586: systemd-gpt-auto-generator: systemd-gpt-auto-generator[152]: Failed to determine partition table type

[Jape Person]

On 01/30/2016 02:48 PM, Michael Biebl wrote:

Am 30.01.2016 um 20:40 schrieb Jape Person:

Hi, Michael.

Thanks for the follow-up.

Yes, the problem is still reproducible running version 228-4+b1 in testing.

I'll check into creating myself an account at github and reporting it
there.


Thanks. If it's too much of a hassle, let me know. I'll file the bug
report upstream myself then. But it's better if you do, just in case
upstream has follow-up questions.

Regards,
Michael




Thanks! I'll do my best to figure it out.

Bug#765586: systemd-gpt-auto-generator: systemd-gpt-auto-generator[152]: Failed to determine partition table type

[Jape Person]

On 01/30/2016 10:50 AM, Michael Biebl wrote:

Hi Jim,

thanks for your bug report.

On Thu, 16 Oct 2014 08:39:39 -0400 Jim Wallen  wrote:

Package: systemd
Version: 215-5+b1
Severity: minor
File: systemd-gpt-auto-generator

Dear Maintainer,

Pertinent information from dmesg:
[4.853751] systemd-gpt-auto-generator[154]: Failed to determine partition 
table type of /dev/sda: Input/output error
[4.854298] systemd[151]: 
/lib/systemd/system-generators/systemd-gpt-auto-generator failed with error 
code 1.


is this problem still reproducible with v228 from unstable/testing?

If so, can you please forward this issue upstream and file a bug at

https://github.com/systemd/systemd/issues/new

Regards,
Michael




Hi, Michael.

Thanks for the follow-up.

Yes, the problem is still reproducible running version 228-4+b1 in testing.

I'll check into creating myself an account at github and reporting it there.

Best regards,
Jim

Bug#780352: initramfs-tools: Can't force fsck on remote systems

[Jape Person]

On 04/09/2015 08:42 AM, Robert Moonen wrote:

I am sure that a tune2fs -C -1 should suffice, as is normally the case to
force an fsck.

Robert


Thanks, Robert.

As Ben Hutchings was able to divine, tune2fs was working, but the output 
from the file system check was not being recorded where I expected. He's 
got me straightened out now.


Best regards,
JP


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780352: initramfs-tools: Can't force fsck on remote systems

[Jape Person]

On 04/08/2015 09:05 PM, Ben Hutchings wrote:

Control: tag -1 unreproducible

On Thu, 12 Mar 2015 10:25:34 -0400 jpw jap...@comcast.net wrote:

Package: initramfs-tools
Version: 0.119
Severity: important

Dear Maintainer,

A basic change in function for fsck at boot time has resulted following upgrade
of this package from 0.116 to 0.119.

Following deprecation of touch /forcefsck earlier this past year for forcing 
fsck
at next reboot I started using a line in  rc.local (tune2fs -c 0 /dev/sda1) to 
set
maximum mount count so that in-depth file system checks would never occur 
unless I
specified. I then issued tune2fs -c 1 /dev/sda1 from a root prompt on the 
remote
systems to force the in-depth fsck on next reboot.

The remote systems used to execute an in-depth fsck on the boot partition at
next reboot when I followed this procedure. This function no longer works.

[...]

It works for me.  However, the forced fsck is now done from the
initramfs (for the root and /usr filesystems), not under systemd or
initscripts.

Is the real problem to do with logging the output of fsck?

Ben.


Hi!

I was trying to force the type of fsck which results in a report of the 
% of discontiguous files on remote systems that I maintain. In the 
spirit of avoiding the use of the deprecated touch /forcefsck I was 
using a line (tune2fs -c 0 /dev/sda1) in rc.local to cause the check to 
never run unless I issued tune2fs -c 1 /dev/sda1 from a root prompt 
and then rebooted.


So when you say that it works for you, do you mean that touch 
/forcefsck still gets the check for file system fragmentation, or that 
using the tune2fs trick works. Because, for me, touch /forcefsck still 
works (but I'm trying to avoid it), but using the tune2fs trick stopped 
working when initramfs-tools was upgraded from 0.116 to 0.119.


By that, I mean that issuing systemctl status -l 
systemd-fsck-root.service stopped showing me % discontiguous following 
a reboot when I tried to run the full fsck check using the tune2fs command.


Now I am just using grub-reboot to make the system use a new entry I 
created in the grub boot menu which contains the mode.fsck=force command 
on the next reboot, and I get my report.


So I have a workaround to replace the previous workaround.

If my bug report against initramfs-tools is invalid because initramfs is 
actually working as designed, I'm content to have the bug closed. But 
does the change in behavior mean, essentially, that maximum mount count 
is no longer a controller in determining whether or not the more 
extensive type of file system check is run at boot time?


Just curious. I'm trying to keep my rather vague conceptual structure 
about this as up-to-date as possible. It's an old brain, and there is no 
longer enough coffee in the world...


:-)

And thank you for all the work you do. I see your name on a lot of 
changelogs and on many of the most useful posts on various lists!


Best regards,
JP


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780352: initramfs-tools: Can't force fsck on remote systems

[Jape Person]

On 04/09/2015 12:24 PM, Ben Hutchings wrote:

Control: tag -1 - moreinfo unreproducible
Control: retitle -1 fsck log from initramfs is not documented

On Thu, 2015-04-09 at 08:30 -0400, Jape Person wrote:

On 04/08/2015 09:05 PM, Ben Hutchings wrote:

Control: tag -1 unreproducible

On Thu, 12 Mar 2015 10:25:34 -0400 jpw jap...@comcast.net wrote:

Package: initramfs-tools
Version: 0.119
Severity: important

Dear Maintainer,

A basic change in function for fsck at boot time has resulted following upgrade
of this package from 0.116 to 0.119.

Following deprecation of touch /forcefsck earlier this past year for forcing 
fsck
at next reboot I started using a line in  rc.local (tune2fs -c 0 /dev/sda1) to 
set
maximum mount count so that in-depth file system checks would never occur 
unless I
specified. I then issued tune2fs -c 1 /dev/sda1 from a root prompt on the 
remote
systems to force the in-depth fsck on next reboot.

The remote systems used to execute an in-depth fsck on the boot partition at
next reboot when I followed this procedure. This function no longer works.

[...]

It works for me.  However, the forced fsck is now done from the
initramfs (for the root and /usr filesystems), not under systemd or
initscripts.

Is the real problem to do with logging the output of fsck?

Ben.


Hi!

I was trying to force the type of fsck which results in a report of the
% of discontiguous files on remote systems that I maintain. In the
spirit of avoiding the use of the deprecated touch /forcefsck I was
using a line (tune2fs -c 0 /dev/sda1) in rc.local to cause the check to
never run unless I issued tune2fs -c 1 /dev/sda1 from a root prompt
and then rebooted.

So when you say that it works for you, do you mean that touch
/forcefsck still gets the check for file system fragmentation, or that
using the tune2fs trick works. Because, for me, touch /forcefsck still
works (but I'm trying to avoid it), but using the tune2fs trick stopped
working when initramfs-tools was upgraded from 0.116 to 0.119.


I mean using 'tune2fs -c 1' before rebooting.


By that, I mean that issuing systemctl status -l
systemd-fsck-root.service stopped showing me % discontiguous following
a reboot when I tried to run the full fsck check using the tune2fs command.

[...]

Right, so as I suspected you're talking about where the output is
logged.

Currently it's logged to /run/initramfs/fsck, but not documented.  I'm
intending to rename that to fsck.log (so it's obviously a log file) and
to document it in the initramfs-tools(8) manual page.

Ben.



Aha! Yes, as usual, I didn't even really know what I was complaining about!

Thank you for shedding the light! So now I know just a little more, and 
I have alternatives. That's always nice.


Best regards,
JP


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations

[Jape Person]

Hi, Eriberto.

I found https://github.com/conformal/xombrero/issues/59

This indicates that this is a problem with the GTK3 CSS.

Unfortunately, this means that either I have to not use Xombrero, or I 
have to avoid using almost all of the appearance themes available.


I could also do trial and error on the /usr/share/xombrero/xombrero.css 
file.


Regards,
Jim

On 10/17/2014 08:52 PM, Eriberto Mota wrote:

Your problem is your environment. Please, confirm it and close this
bug. Let me know what happened.

Cheers,

Eriberto


2014-10-17 21:26 GMT-03:00 Jape Person jap...@comcast.net:

Hi, Eriberto!

The two fields where I type the Web address and search terms are the
problem.

I keep thinking my problem must have something to do with the desktop
environment theme. I'm using Xfce, but I've tried every single appearance
theme (and even changed through all of the window managers). None of that
has any effect on the problem

When I type in the address for a site like light http://www.bing.com, I see
white letters on a bright yellow background. It's extremely hard to see.

The search field or box is even worse. Apparently it's white on white there.

I just tried to type in an URL and then highlight it by selecting with the
cursor, and nothing shows at all.

In addition -- and this appears to be a totally different problem -- I'm
seeing an error message at the bottom of the Xombrero window --
Invalid about page. I wonder if something is simply wrong with my
installation of Xombrero.

It was working perfectly up until very recently.

Please let me know if I can do anything to help figure this out.

Thanks,
Jim


On 10/17/2014 08:11 PM, Eriberto Mota wrote:


tags 765744 moreinfo
thanks


Hi Jim,

Which fields that you have problem? How to reproduce this issue?

Cheers,

Eriberto


2014-10-17 15:15 GMT-03:00 Jim Wallen jap...@comcast.net:


Package: xombrero
Version: 2:1.6.3-1
Severity: important

Dear Maintainer,

Text typed in either of these fields isn't legible because there's so
little contrast
between text color and background color.

It's a nice privacy feature, though, because no one else can read what
I'm typing.

(-:

I saw in the man pages for xombrero that these colors have been set
deliberately, but
the backgrounds need to be darker if the text is going to be white.

I love this browser. Use it more than vimperator -- or at least I did
before I lost the
to see what I was typing in the search field.

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

Kernel: Linux 3.16-2-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

Versions of packages xombrero depends on:
ii  libbsd0 0.7.0-2
ii  libc6   2.19-11
ii  libgdk-pixbuf2.0-0  2.30.8-1+b1
ii  libglib2.0-02.42.0-2
ii  libgnutls-deb0-28   3.3.8-2
ii  libgtk-3-0  3.14.1-1
ii  libjavascriptcoregtk-3.0-0  2.4.6-1
ii  libpango-1.0-0  1.36.8-2
ii  libsoup2.4-12.48.0-1
ii  libwebkitgtk-3.0-0  2.4.6-1

xombrero recommends no packages.

xombrero suggests no packages.

-- no debconf information










--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765746: zim: Attempt to invoke Task List brings up error dialog

[Jape Person]

On 10/21/2014 02:30 AM, Raphael Hertzog wrote:

Hi,

On Mon, 20 Oct 2014, Jape Person wrote:

Please let me know if there are other things I can do to help pinpoint the
problem. Results of tests you requested are below.


Yes please attach ~/.config/zim/preferences.conf.

The error messages seem to imply that the settings in [TaskListPlugin]
are not as expected (in particular the labels one might be missing). For
example, here's what I have:

[TaskListPlugin]
all_checkboxes=True
tag_by_page=False
deadline_by_page=False
use_workweek=True
labels=FIXME, TODO
next_label=Next:
nonactionable_tags=
included_subtrees=
excluded_subtrees=

You can try to fix those by editing the preferences of the TaskList
plugin... (the configure button in the plugin list when you select
the task list plugin).

Cheers,



Hello, Raphael.

I've attached my preferences.conf. I'm afraid that the only difference I 
see between our [TasklistPlugin] sections is the inclusion of FIXME and 
TODO in your version.


I was using only checkboxes to mark tasks, though I seem to recall 
having used TODO at some time in the past. As I remember it, there might 
have been a time when there were some temporary changes in which tags 
were supported.


Anyway, after attaching my unchaged preferences.conf file I did try 
updating the configuration, but still got the following error dialog 
when trying to invoke the task list.


This is zim 0.62
Platform: posix
Locale: en_US UTF-8
FS encoding: UTF-8
Python: (2, 7, 8, 'final', 0)
Gtk: (2, 24, 25)
Pygtk: (2, 24, 0)
Zim revision is:
  branch: zim-trunk
  revision: 738 jaap.karssenb...@gmail.com-20140930191715-hpl66psh7yudcskr
  date: 2014-09-30 21:17:15 +0200

=== Traceback ===
  File /usr/lib/python2.7/dist-packages/zim/actions.py, line 55, in func
self.func(instance, *arg, **kwarg)
  File /usr/lib/python2.7/dist-packages/zim/plugins/tasklist.py, line 
407, in show_task_list

if not self.index_ext.db_initialized:
AttributeError: 'NoneType' object has no attribute 'db_initialized'

Thanks again, and please let me know if I can provide more information.

Best regards,
Jim
[GtkInterface]
tearoff_menus=False
toggle_on_ctrlspace=True
remove_links_on_delete=True
always_use_last_cursor_pos=True
gtk_bell=False
toggle_on_altspace=False
mouse_nav_button_back=8
mouse_nav_button_forw=9
autosave_timeout=10
toolbar_style=icons_only
toolbar_size=tiny

[PageView]
follow_on_enter=False
read_only_cursor=True
autolink_camelcase=False
autolink_files=False
autoselect=False
unindent_on_backspace=False
cycle_checkbox_type=True
recursive_indentlist=True
recursive_checklist=True
auto_reformat=False
copy_format=Text
file_templates_folder=~/Templates

[General]
plugins=[calendar,diagrameditor,insertsymbol,linkmap,printtobrowser,quicknote,screenshot,spell,tasklist,inlinecalculator,linesorter,arithmetic]

[CalendarPlugin]
embedded=False
pane=('left_pane', 'top')
granularity=Day
namespace=Calendar

[SpellPlugin]
language=

[TaskListPlugin]
all_checkboxes=True
tag_by_page=False
deadline_by_page=False
use_workweek=True
labels=
next_label=Next:
nonactionable_tags=FIXME, TODO
included_subtrees=
excluded_subtrees=

[InsertScreenshotPlugin]
screenshot_command=import

Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations

[Jape Person]

Hello, Eriberto!

I have installed various sets of themes for testing with Xombrero. 
(Within the Xfce DE these are referred to as choices of Appearance.)


The URI and search fields only present readable text / background 
combinations with a handful of these themes. The only Xfce theme that 
yields a usable Xombrero is Xfce-dusk.


Among the add-on themes, Adwaita doesn't not work, but Albatross does. 
Greybird works. None of the Murrina themes work.


Iceweasel/Vimperator are not adversely affected by any of the themes in 
this respect. Also, no other applications that I use are adversely 
affected by theme choice -- other than, maybe, looking ugly.


Heh.

Please let me know if I can provide any information that could be of 
help to you.


Thanks, and best regards,
Jim

On 10/17/2014 08:52 PM, Eriberto Mota wrote:

Your problem is your environment. Please, confirm it and close this
bug. Let me know what happened.

Cheers,

Eriberto


2014-10-17 21:26 GMT-03:00 Jape Person jap...@comcast.net:

Hi, Eriberto!

The two fields where I type the Web address and search terms are the
problem.

I keep thinking my problem must have something to do with the desktop
environment theme. I'm using Xfce, but I've tried every single appearance
theme (and even changed through all of the window managers). None of that
has any effect on the problem

When I type in the address for a site like light http://www.bing.com, I see
white letters on a bright yellow background. It's extremely hard to see.

The search field or box is even worse. Apparently it's white on white there.

I just tried to type in an URL and then highlight it by selecting with the
cursor, and nothing shows at all.

In addition -- and this appears to be a totally different problem -- I'm
seeing an error message at the bottom of the Xombrero window --
Invalid about page. I wonder if something is simply wrong with my
installation of Xombrero.

It was working perfectly up until very recently.

Please let me know if I can do anything to help figure this out.

Thanks,
Jim



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765745: zim: Calendar portion of tree in left pane insists on being expanded

[Jape Person]

On 10/20/2014 11:28 AM, Raphael Hertzog wrote:

Control: forwarded -1 https://bugs.launchpad.net/zim/+bug/1383344

Hello Jim,

On Fri, 17 Oct 2014, Jim Wallen wrote:

The recent upgrade in Debian testing from version 0.60-1 to 0.62-1 resulted in
a change in behavior.

In notebooks containing a calendar, if the user selects a date page to display 
in
right pane, then collapses the tree and hides the left pane -- when the left 
pane
is opened again, the calendar tree will be expanded to the date shown in the 
right
pane.

Unfortunately, I just  want to navigate the calendar with the calendar widget
instead of scrolling up and down through the calendar tree in the left pane.

In the previous version, once I collapsed the calendar tree, it stayed that way.
That allowed me to use the left pane only for navigating named pages in the 
tree.

Was this change deliberate, is this PEBKAC, or am I missing something?


It was deliberate apparently, I asked the upstream author and he told me:

The issue about the expanding index pane is not really a bug in my
opinion.  The index pane is designed to always expand to the current page,
regardless whether that is a journal page or not. Would not consider the
old behavior as a feature. (Which of course does not exclude the option
to actually introduce a feature to leave the index collapsed - but that is
not a fix.)


Though I'm not sure it's a regression, it's been a long time that I have
been annoyed by the fact that the index gets clogged with multiple trees
(the current month, the former month, the next month each with 30 days)
and thus making it difficult to navigate in other pages there... I was not
even aware that collapsing the higher level entry worked as you explained.

So I submitted your request upstream so that we have this as a proper
feature in the future.

Cheers,



Very interesting!

Thank you for the information, and I'll look forward to being able to 
keep the calendar collapsed at some time in the future. Considering the 
existence of the calendar applet it would seem silly to navigate to a 
date using the tree. And the expanded calendar tree just gets in the way 
of getting to the other pages.


I hardly every touch my mouse, so collapsing that part of the tree is 
just a few quick keystrokes each time. I'd imagine it might be a lot 
more annoying to a use who uses the mouse primarily for navigating.


Thanks again!

Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765746: zim: Attempt to invoke Task List brings up error dialog

[Jape Person]

On 10/20/2014 11:34 AM, Raphael Hertzog wrote:

Hello again,

On Fri, 17 Oct 2014, Jim Wallen wrote:

Dear Maintainer,

When I try to bring up a Task List (from menu or from toolbar) I am presented
with a Looks like you found a bug dialog. The Task List, of course, isn't
shown.


Can you start zim with zim -D --standalone and send the full output as
attachment?

I can't reproduce the problem and neither can Jaap (the upstream author).
Maybe the problem can be fixed by rebuilding the index (the option is
in the Tools menu), can you try to rebuild the index and see if the
problem persists ?

Cheers,



Hi, Raphael!

I had already re-indexed, but I did it again. It made no difference.

BTW, the first time I ran the index update following the Zim version 
upgrade it took a long, long time to complete. I have a fairly large 
notebook, but the same thing happens in a small notebook.


Please let me know if there are other things I can do to help pinpoint 
the problem. Results of tests you requested are below.


I ran zim -D --standalone from a terminal emulator.

Output from Zim dialog and terminal emulator stdout, respectively, are 
pasted below.


Zim error dialog:

This is zim 0.62
Platform: posix
Locale: en_US UTF-8
FS encoding: UTF-8
Python: (2, 7, 8, 'final', 0)
Gtk: (2, 24, 24)
Pygtk: (2, 24, 0)
Zim revision is:
  branch: zim-trunk
  revision: 738 jaap.karssenb...@gmail.com-20140930191715-hpl66psh7yudcskr
  date: 2014-09-30 21:17:15 +0200

=== Traceback ===
  File /usr/lib/python2.7/dist-packages/zim/actions.py, line 55, in func
self.func(instance, *arg, **kwarg)
  File /usr/lib/python2.7/dist-packages/zim/plugins/tasklist.py, line 
407, in show_task_list

if not self.index_ext.db_initialized:
AttributeError: 'NoneType' object has no attribute 'db_initialized'

Output in terminal emulator:

jpw@T520i:~$ zim -D --standalone
INFO: This is zim 0.62
DEBUG: Python version is sys.version_info(major=2, minor=7, micro=8, 
releaselevel='final', serial=0)

DEBUG: Platform is posix
DEBUG: Zim revision is:
  branch: zim-trunk
  revision: 738 jaap.karssenb...@gmail.com-20140930191715-hpl66psh7yudcskr
  date: 2014-09-30 21:17:15 +0200
DEBUG: Not running from a source dir
DEBUG: Set XDG_DATA_HOME to /home/jpw/.local/share
DEBUG: Set XDG_DATA_DIRS to [Dir: /usr/share/xfce4, Dir: 
/usr/local/share, Dir: /usr/share]

DEBUG: Set XDG_CONFIG_HOME to /home/jpw/.config
DEBUG: Set XDG_CONFIG_DIRS to [Dir: /etc/xdg]
DEBUG: Set XDG_CACHE_HOME to /home/jpw/.cache
DEBUG: Loading config from: zim.notebook.VirtualFile object at 
0x7fcec38d7d90

DEBUG: Loading config from: /home/jpw/Data/Zim/Domestic/notebook.zim
DEBUG: Loading config from: /home/jpw/Data/Zim/DebianReference/notebook.zim
DEBUG: Wrote /home/jpw/.config/zim/notebooks.list
DEBUG: Loading config from: zim.notebook.VirtualFile object at 
0x7fcebd8d7150

DEBUG: Loading config from: /home/jpw/Data/Zim/Domestic/notebook.zim
DEBUG: Loading config from: /home/jpw/Data/Zim/DebianReference/notebook.zim
DEBUG: Wrote /home/jpw/.config/zim/notebooks.list
DEBUG: Loading config from: zim.notebook.VirtualFile object at 
0x7fcebd8d7bd0

DEBUG: Loading config from: /home/jpw/Data/Zim/Domestic/notebook.zim
DEBUG: Loading config from: /home/jpw/Data/Zim/DebianReference/notebook.zim
DEBUG: Wrote /home/jpw/.config/zim/notebooks.list
DEBUG: Opening dialog Open Notebook - Zim
DEBUG: Dialog response OK
DEBUG: Wrote /home/jpw/.config/zim/notebooks.list
DEBUG: Closed dialog Open Notebook
DEBUG: Wrote /home/jpw/Data/Zim/Domestic/.zim/tmp
INFO: Remove file: /home/jpw/Data/Zim/Domestic/.zim/tmp
DEBUG: Loading config from: /home/jpw/Data/Zim/Domestic/notebook.zim
DEBUG: Cache dir: /home/jpw/.cache/zim/notebook-home_jpw_Data_Zim_Domestic
DEBUG: Index database file: 
/home/jpw/.cache/zim/notebook-home_jpw_Data_Zim_Domestic/index.db

DEBUG: Opening notebook: zim.notebook.Notebook object at 0x7fcebdf8df10
DEBUG: Loading config from: ConfigFile: 
/home/jpw/.config/zim/preferences.conf

DEBUG: Loading plugin: arithmetic
DEBUG: Loading plugin: calendar
DEBUG: Loading plugin: diagrameditor
DEBUG: Loading plugin: inlinecalculator
DEBUG: Loading plugin: insertsymbol
DEBUG: Loading plugin: linesorter
DEBUG: Loading plugin: linkmap
DEBUG: Loading plugin: printtobrowser
DEBUG: Loading plugin: quicknote
DEBUG: Loading plugin: screenshot
DEBUG: Loading plugin: spell
DEBUG: Loading plugin: tasklist
ERROR: Exception in plugin: tasklist
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/zim/plugins/__init__.py, line 
290, in _foreach

func(plugin)
  File /usr/lib/python2.7/dist-packages/zim/plugins/__init__.py, line 
302, in lambda

self._foreach(lambda p: p.extend(obj))
  File /usr/lib/python2.7/dist-packages/zim/plugins/tasklist.py, line 
128, in extend

PluginClass.extend(self, obj)
  File /usr/lib/python2.7/dist-packages/zim/plugins/__init__.py, line 
559, in extend

ext = self.extension_classes[name](self, obj)
  File 

Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations

[Jape Person]

On 10/17/2014 08:52 PM, Eriberto Mota wrote:

Your problem is your environment. Please, confirm it and close this
bug. Let me know what happened.

Cheers,

Eriberto


Okay. This morning Xombrero works perfectly. Text in the URI and Search 
fields is now black with various appropriate background colors applied 
to the URI field (depending upon cert of site visited) just as it was 
before I started having problems. Selection of text in the Web page 
bodies now also works properly.


There were package upgrades this morning, but it's hard to believe any 
of them could have caused this change in behavior on the browser's part.


bash:amd64 4.3-10 - 4.3-11
guile-2.0:amd64 2.0.11+1-7 - 2.0.11+1-9
guile-2.0-doc:amd64 2.0.11+1-7 - 2.0.11+1-9
guile-2.0-libs:amd64 2.0.11+1-7 - 2.0.11+1-9
inkscape:amd64 0.48.5-2+b1 - 0.48.5-3
libcryptsetup4:amd64 2:1.6.6-1 - 2:1.6.6-2
libpython2.7:amd64 2.7.8-7 - 2.7.8-10
libpython2.7-minimal:amd64 2.7.8-7 - 2.7.8-10
libpython2.7-stdlib:amd64 2.7.8-7 - 2.7.8-10
python2.7:amd64 2.7.8-7 - 2.7.8-10
python2.7-minimal:amd64 2.7.8-7 - 2.7.8-10
tzdata:amd64 2014h-1 - 2014h-2
tzdata-java:amd64 2014h-1 - 2014h-2
xserver-xorg-video-mach64:amd64 6.9.4-1+b3 - 6.9.4-2

I won't close the bug yet since another person has reported having the 
same problem.


It's hard to understand. I'm going to blame it on systemd.

;-)

No, not really.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations

[Jape Person]

Hi, Eriberto!

The two fields where I type the Web address and search terms are the 
problem.


I keep thinking my problem must have something to do with the desktop 
environment theme. I'm using Xfce, but I've tried every single 
appearance theme (and even changed through all of the window managers). 
None of that has any effect on the problem


When I type in the address for a site like light http://www.bing.com, I 
see white letters on a bright yellow background. It's extremely hard to see.


The search field or box is even worse. Apparently it's white on white there.

I just tried to type in an URL and then highlight it by selecting with 
the cursor, and nothing shows at all.


In addition -- and this appears to be a totally different problem -- I'm 
seeing an error message at the bottom of the Xombrero window --
Invalid about page. I wonder if something is simply wrong with my 
installation of Xombrero.


It was working perfectly up until very recently.

Please let me know if I can do anything to help figure this out.

Thanks,
Jim

On 10/17/2014 08:11 PM, Eriberto Mota wrote:

tags 765744 moreinfo
thanks


Hi Jim,

Which fields that you have problem? How to reproduce this issue?

Cheers,

Eriberto


2014-10-17 15:15 GMT-03:00 Jim Wallen jap...@comcast.net:

Package: xombrero
Version: 2:1.6.3-1
Severity: important

Dear Maintainer,

Text typed in either of these fields isn't legible because there's so little 
contrast
between text color and background color.

It's a nice privacy feature, though, because no one else can read what I'm 
typing.

(-:

I saw in the man pages for xombrero that these colors have been set 
deliberately, but
the backgrounds need to be darker if the text is going to be white.

I love this browser. Use it more than vimperator -- or at least I did before I 
lost the
to see what I was typing in the search field.

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

Kernel: Linux 3.16-2-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

Versions of packages xombrero depends on:
ii  libbsd0 0.7.0-2
ii  libc6   2.19-11
ii  libgdk-pixbuf2.0-0  2.30.8-1+b1
ii  libglib2.0-02.42.0-2
ii  libgnutls-deb0-28   3.3.8-2
ii  libgtk-3-0  3.14.1-1
ii  libjavascriptcoregtk-3.0-0  2.4.6-1
ii  libpango-1.0-0  1.36.8-2
ii  libsoup2.4-12.48.0-1
ii  libwebkitgtk-3.0-0  2.4.6-1

xombrero recommends no packages.

xombrero suggests no packages.

-- no debconf information





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765744: xombrero: entries in URI and Search fields not readable due to default color combinations

[Jape Person]

Hello, Eriberto.

Oops!

Sorry that my mail client sent to control@bugs.debian, too. I didn't 
mean to do that. I just fired off that e-mail without noticing where it 
was going.


Just some additional information from a terminal emulator when xombrero 
is started from there:


** (xombrero:20003): WARNING **: Couldn't register with accessibility 
bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy 
blocked the reply, the reply timeout expired, or the network connection 
was broken.
xombrero: config_parse: cannot open /home/jpw/.xombrero.conf: No such 
file or directory

java version 1.7.0_65
OpenJDK Runtime Environment (IcedTea 2.5.2) (7u65-2.5.2-4)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

I didn't see anything that looks particularly unusual for starting an 
application like this from a terminal window, but I just thought I'd 
include it along with my apology for bombarding the control address.


Please let me know if you need a screenshot of the application.

Thanks,
Jim

On 10/17/2014 08:11 PM, Eriberto Mota wrote:

tags 765744 moreinfo
thanks


Hi Jim,

Which fields that you have problem? How to reproduce this issue?

Cheers,

Eriberto


2014-10-17 15:15 GMT-03:00 Jim Wallen jap...@comcast.net:

Package: xombrero
Version: 2:1.6.3-1
Severity: important

Dear Maintainer,

Text typed in either of these fields isn't legible because there's so little 
contrast
between text color and background color.

It's a nice privacy feature, though, because no one else can read what I'm 
typing.

(-:

I saw in the man pages for xombrero that these colors have been set 
deliberately, but
the backgrounds need to be darker if the text is going to be white.

I love this browser. Use it more than vimperator -- or at least I did before I 
lost the
to see what I was typing in the search field.

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

Kernel: Linux 3.16-2-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

Versions of packages xombrero depends on:
ii  libbsd0 0.7.0-2
ii  libc6   2.19-11
ii  libgdk-pixbuf2.0-0  2.30.8-1+b1
ii  libglib2.0-02.42.0-2
ii  libgnutls-deb0-28   3.3.8-2
ii  libgtk-3-0  3.14.1-1
ii  libjavascriptcoregtk-3.0-0  2.4.6-1
ii  libpango-1.0-0  1.36.8-2
ii  libsoup2.4-12.48.0-1
ii  libwebkitgtk-3.0-0  2.4.6-1

xombrero recommends no packages.

xombrero 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