Bug#958059: mumble: push-to-talk not working with some media keys

2020-05-07 Thread nfb
On Thu, May 07, 2020 at 03:30:21AM +, Chris Knadle wrote:
> forwarded 958059 https://github.com/mumble-voip/mumble/issues/4140
> thanks
> 
> nfb:
> > Package: mumble
> > Version: 1.3.0~git20190125.440b173+dfsg-2
> > Severity: normal
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > some multimedia keys are not working when bound to the push-to-talk
> > shortcut, but some of them do work fine.
> > 
> > For example the ThinkVantage button on a Thinkpad x230 keyboard
> > generates XF86Launch1 keysym. Output from xev:
> > 
> > KeyPress event, serial 34, synthetic NO, window 0x161,
> > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen 
> > YES,
> > XLookupString gives 0 bytes: 
> > XmbLookupString gives 0 bytes: 
> > XFilterEvent returns: False
> > 
> > KeyRelease event, serial 34, synthetic NO, window 0x161,
> > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen 
> > YES,
> > XLookupString gives 0 bytes: 
> > XFilterEvent returns: False
> > 
> > The key is correctly detected and saved (as XF86Launch1) by the
> > shortcut setting dialog in mumble, but when pushing it, the voice is
> > not activated.
> > Also, there should be no interference by the rest of the system, since
> > this button, but also all other media keys i chose for testing, are
> > not used by the window manager, nor by any running application.
> > 
> > The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
> > instead, work as expected, as all other "standard" keys do, afaict.
> > 
> > I already reported on the #mumble irc channel and was told to file a
> > bug because it probably is, but i decided to open it here so we can
> > track it in Debian and also because i dont't know if the package in
> > the stable repo is a bit outdated and the issue has been recently
> > fixed somehow...
> > 
> > Let me know if you need more details.
> > 
> > Thanks for the support.
> 
> Thank you for opening a bug upstream about this; if upstream is able to fix 
> the
> bug then I'll be able to upload a new package with the fix for unstable and 
> testing.
> 
> It is doubtful that this can be fixed for Debian stable though; the only bugs
> that are possible to fix for stable are bugs that are serious, and any fixes 
> for
> serious bugs would have to be targeted for only the serious issues 
> specifically.
>  I don't think this bug passes that threshold.

Yes sure, that's totally fine.

> Out of curiosity, have you tested to see if Mumble 1.3.0+dfsg-1 in Debian
> unstable and testing exhibits the same bug?

No I'm sorry, I don't have right now a testing environment and on
stable there is dependency on a newer libc6. I could try a virtual
machine, yet I wanted to keep it non-virtualized to avoid another
layer of uncertainty in keystrokes passing and configurations to make
it work (and indeed it looks like the vm I have doesn't detect media
keys at all, must be something with the default generic keyboard
emulation). If I find some spare time to set it up I can maybe give
it a try.


P.S. Thanks a lot for including me in To. I was already subscribed so
if you find it easier to skip the hassle of including me everytime I
will still receive replies.



-- 
free as in freedom, not free beer



Bug#958059: mumble: push-to-talk not working with some media keys

2020-05-06 Thread nfb
Meanwhile, forwarded upstream [0].

[0] https://github.com/mumble-voip/mumble/issues/4140



-- 
free as in freedom, not free beer



Bug#958059: mumble: push-to-talk not working with some media keys

2020-04-17 Thread nfb
Package: mumble
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal
Tags: upstream

Dear Maintainer,

some multimedia keys are not working when bound to the push-to-talk
shortcut, but some of them do work fine.

For example the ThinkVantage button on a Thinkpad x230 keyboard
generates XF86Launch1 keysym. Output from xev:

KeyPress event, serial 34, synthetic NO, window 0x161,
root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x161,
root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

The key is correctly detected and saved (as XF86Launch1) by the
shortcut setting dialog in mumble, but when pushing it, the voice is
not activated.
Also, there should be no interference by the rest of the system, since
this button, but also all other media keys i chose for testing, are
not used by the window manager, nor by any running application.

The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
instead, work as expected, as all other "standard" keys do, afaict.

I already reported on the #mumble irc channel and was told to file a
bug because it probably is, but i decided to open it here so we can
track it in Debian and also because i dont't know if the package in
the stable repo is a bit outdated and the issue has been recently
fixed somehow...

Let me know if you need more details.

Thanks for the support.



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

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

Versions of packages mumble depends on:
ii  libasound2 1.1.8-1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libopus0   1.3-1
ii  libprotobuf17  3.6.1.3-2
ii  libpulse0  12.2-4+deb10u1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus55.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5sql5 5.11.3+dfsg1-1+deb10u3
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1+deb10u3
ii  libqt5svg5 5.11.3-2
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u3
ii  libsndfile11.0.28-6
ii  libspeechd20.9.0-5
ii  libspeex1  1.2~rc1.2-1+b2
ii  libspeexdsp1   1.2~rc1.2-1+b2
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libstdc++6 8.3.0-6
ii  libx11-6   2:1.6.7-1
ii  libxi6 2:1.7.9-1
ii  lsb-release10.2019051400

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
pn  speech-dispatcher  

-- no debconf information



Bug#941556: zathura: page count mismatch when more than one page fit the window

2019-10-01 Thread nfb
Package: zathura
Version: 0.4.4-1
Severity: normal

Dear Maintainer,

when more than one page fit the zathura window (i.e. you have plenty
of vertical space, or the document pages are much more wide than they
are high) the page count is not correctly updated, and pageUP/pageDOWN
navigation breaks.
This can be particularly noticeable (and annoying) when using a
monitor in portrait mode, among the other things.

To reproduce, open a document and resize the window like a slim
vertical pane, like 5 to 10 times more high than wide, enough to
accomodate at least two pages in best-fit or width mode (they should
behave the same in this use case).

For example with two full pages and 1/4 of the third one filling the
window, starting from page 1, this is what happens:

[step]  [KEY]   [page count]

0   -   1   // displayed: 1, 2, a bit of 3
1   PgDn2   // displayed: ~half 1, 2, ~half 3
2   PgUp2   // displayed: 1, 2, a bit of 3
3   PgDn3   // displayed: ~half 2, 3, ~half 4

So, in step 2 we are in practice back to what was displayed at the
beginning (0), but now with a wrong page count of 2 instead of 1. So
on the following PgDn there is actually a jump from page 1 to page 3,
while we should visualize the same pages as in step 1.

In other words the sequence page down/up/down doesn't leave the view
unchanged as one would expect.

Thanks.



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

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

Versions of packages zathura depends on:
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libgirara-gtk3-3 0.3.3-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.11-1
ii  libmagic11:5.37-5
ii  libpango-1.0-0   1.42.4-7
ii  libseccomp2  2.4.1-2
ii  libsqlite3-0 3.29.0-2
ii  libsynctex2  2019.20190605.51237-3
ii  zathura-pdf-poppler  0.2.9-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  firefox-esr [www-browser]  60.8.0esr-1
ii  links [www-browser]2.20.1-1
ii  w3m [www-browser]  0.5.3-37+b1
pn  zathura-cb 
pn  zathura-djvu   
pn  zathura-ps 

-- no debconf information



Bug#929222: tracker.debian.org: RSS title field contains HTML

2019-05-19 Thread nfb
Package: tracker.debian.org
Severity: minor

Dear Maintainer,

some RSS feeds titles generated for package news contain HTML, see for
example [0][1], breaking presentation in some RSS feed readers.
Thanks for your work.
Kind regards.

[0] https://tracker.debian.org/pkg/lame/rss
[1] 
https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Ftracker.debian.org%2Fpkg%2Flame%2Frss


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

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



Bug#918834: newsboat: freeze and 100% cpu load when pressing TAB

2019-01-09 Thread nfb
Package: newsboat
Version: 2.13-1
Severity: normal

Dear Maintainer,

when (accidentally) pressing TAB in the main feed (or article) index
view, the program freezes and the cpu load of the process jumps to
100%.

NOTE: The issue just seem to happen in the feed index and in the
article index views when:
1. read feeds are not shown (either by config or pressing 'l')
2. index view is actually empty (all feeds/articles are read)

When this happens, the only viable solution seems to be killing the
process and - at least on my side - it is reproducible 100% of the
times. I didn't test beyond the keystroke/views/config combinations
reported above.

In case it would be useful, here is what gdb shows at the freeze:

--- BEGIN GDB ---

(gdb) i thr
  Id   Target IdFrame
* 1Thread 0x7fb8b7f2d980 (LWP 26490) "newsboat" 0x7fb8bb6e4b80 in 
stfl_form_run () from /usr/lib/libstfl.so.0
  2Thread 0x7fb8b7c47700 (LWP 26491) "newsboat" 0x7fb8bb050ae0 in 
__GI___nanosleep (requested_time=requested_time@entry=0x7fb8b7c466b0,
remaining=remaining@entry=0x7fb8b7c466b0) at 
../sysdeps/unix/sysv/linux/nanosleep.c:28
(gdb) bt
#0  0x7fb8bb6e4b80 in stfl_form_run () from /usr/lib/libstfl.so.0
#1  0x7fb8bb6e38d5 in stfl_run () from /usr/lib/libstfl.so.0
#2  0x557662ccdc2c in ?? ()
#3  0x557662bae087 in ?? ()
#4  0x557662bbc4fb in ?? ()
#5  0x557662b73e73 in ?? ()
#6  0x7fb8bafae09b in __libc_start_main (main=0x557662b73da0, argc=1, 
argv=0x7fffe7628b48, init=, fini=,
rtld_fini=, stack_end=0x7fffe7628b38) at 
../csu/libc-start.c:308
#7  0x557662b74baa in ?? ()
(gdb) thr 2
(gdb) bt
#0  0x7f97ece04ae0 in __GI___nanosleep 
(requested_time=requested_time@entry=0x7f97e99fa6b0, 
remaining=remaining@entry=0x7f97e99fa6b0)
at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x7f97ece049ea in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#2  0x555a062b9705 in ?? ()
#3  0x7f97ed157aff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x7f97ed802fa3 in start_thread (arg=) at 
pthread_create.c:486
#5  0x7f97ece3788f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

--- END GDB ---

Let me know if you need more details.
Thanks.



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

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

Versions of packages newsboat depends on:
ii  libc62.28-2
ii  libcurl3-gnutls  7.62.0-1
ii  libgcc1  1:8.2.0-13
ii  libjson-c3   0.12.1-1.3
ii  libncursesw6 6.1+20181013-1
ii  libsqlite3-0 3.26.0+fossilbc891ac6b-1
ii  libstdc++6   8.2.0-13
ii  libstfl0 0.22-1.3+b10
ii  libtinfo66.1+20181013-1
ii  libxml2  2.9.4+dfsg1-7+b3

Versions of packages newsboat recommends:
ii  sensible-utils  0.0.12

newsboat suggests no packages.

-- no debconf information



Bug#913639: unclutter: change upstream to unclutter-xfixes

2018-11-13 Thread nfb
Package: unclutter
Version: 8-21
Severity: wishlist

Dear Maintainer,

since unclutter seems very old (so old that it doesn't even have an
Homepage, but it must be referred to by a web.archive snapshot among
the other things), would you mind switching upstream location to
unclutter-xfixes[0] for an hopefully actively maintained alternative
which also seems to solve many known bugs with modern WMs?

By the way, this is a rewrite of the program, so maybe a new package
with a different name is more appropriate?

Thank you.

[0] https://github.com/Airblader/unclutter-xfixes

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

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

Versions of packages unclutter depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.27-8
ii  libx11-6   2:1.6.7-1

unclutter recommends no packages.

unclutter suggests no packages.

-- debconf information excluded



Bug#910546: firefox-esr: emoji rendered oversized when fonts-noto-color-emoji is istalled

2018-10-07 Thread nfb
Package: firefox-esr
Version: 52.9.0esr-1
Severity: minor

Dear Maintainer,

when fonts-noto-color-emoji is installed, (some?) emojis are shown
oversized in various parts of firefox, including web pages and UI.
This means they are much bigger than the font size of their
surrounding regular text, and they overlap other lines creating a very
weird and unlegible effect.

As example see the two attached screenshots showing the issue in:
1.  the firefox UI: see how icons on first/last page buttons are
rendered in the 'Print' dialog. I guees those are some sort of
backward/forward icons;
2.  web content: I managed to find a youtube video [0] affected by this
behaviour (wasn't hard honestly, just searched for 'emoji title'
:)). Here you can see the issue at its worst. I don't remember
right now if i had problems on other websites, but I usually don't
browse webpages with lots of emojis in general...

Now I don't know whether the problem is in firefox or in
fonts-noto-color-emoji (or some sort of GTK fonts precedence maybe?).
I can only say i just use plain default themes and fonts, so idk.

Thanks, let me know if you need more details.
Best regards.


[0] https://www.youtube.com/watch?v=NPjDrN2ovME




-- Package-specific info:

-- Extensions information
Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Linen Light theme
Status: user-disabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr52.9.0esr-1  amd64Mozilla Firefox web browser - Ext

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-1
ii  libasound21.1.6-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-3
ii  libsqlite3-0  3.25.2-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-7
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
pn  mozplugger 

-- no debconf information


Bug#906918: fdisk: document cfdisk resize command and shortcut

2018-08-22 Thread nfb
Package: fdisk
Version: 2.32.1-0.1
Severity: minor
Tags: upstream

Dear Maintainer,

the resize command for cfdisk is not documented in the cfdisk(8) man
page, nor in the online help dialog of the tool (shown pressing 'h' or
'?' or selecting [ Help ]). The shortcut 'r' for resizing is actually
working but it's not documented either.

Regards.



-- 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/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fdisk depends on:
ii  libc6  2.27-5
ii  libfdisk1  2.32.1-0.1
ii  libmount1  2.32.1-0.1
ii  libncursesw6   6.1+20180714-1
ii  libsmartcols1  2.32.1-0.1
ii  libtinfo6  6.1+20180714-1

fdisk recommends no packages.

fdisk suggests no packages.

-- no debconf information



Bug#892517: Info received (Bug#892517: linux: swiotlb coherent allocation failed)

2018-06-05 Thread nfb
> There were various commits which went in up to v4.16.9 upstream which
> should adress the issues. There is a 4.16.12-1 upload pending for sid,
> can you check if this will fix your issue?

Hi,
just reporting back that after 4.16.12-1 arrived to testing few days
ago i booted the new version this morning, and the error still hasn't
shown up, with the same workload that was triggering it before. At
least for now... maybe fixed?
Thank you.

-- 
free as in freedom, not free beer



Bug#892517: linux: swiotlb coherent allocation failed

2018-05-27 Thread nfb
Hi,
this is happening to me too, with nouveau drivers, and it starts for
example with a huge file transfer over LAN.
Btw as i can read on lklm.org and some other places on the net, it
seems the proposed patch is just addressing log spamming and
suppressing all those dmesg lines, while in my case i can say that
this issue is affecting user interaction as well, since the graphics
interface is stuttering and looks very unresponsive while the problem
is in progress. It's not just a matter of logs noise.
For example my interface was really laggish few minutes ago, and i
tryed to kill a firefox instance running inside a Xephyr display which
i discovered not responding anymore. The error messages suddenly
stopped filling the logs, and the general user interaction came back
as fluid as it should normally be. So i don't know if it's just me,
but in my case there is an impact on the graphical performance.

Thank you.

-- 
free as in freedom, not free beer



Bug#891219: cryptsetup: cryptdisks_start bad output formatting

2018-02-23 Thread nfb
Package: cryptsetup
Version: 2:2.0.1-1
Severity: minor

Hi,
after cryptsetup 2:1.7.5-1 -> 2:2.0.1-1 upgrade, starting an encrypted
volume with cryptidsks_start shows broken output:

Ā» cryptdisks_start containers
[] Starting crypto disk...[info] containers (starting)...
[ ok iners (started)...done.

Besides the whole output looks a bit confusing with the info blocks
not always at the line start and with no space separation (but may be
a matter of personal taste), note the second line, where the volume
name is overwritten by the string "[ ok ".

After a quick check, it seems something must happen between the call
to log_action_cont_msg() by device_msg() in
/lib/cryptsetup/cryptdisks.functions and log_end_msg_pre() in
/lib/lsb/init-functions.d/20-left-info-blocks. Or log_end_msg_pre()
is simply called after log_action_cont_msg() so it overwrites the
beginning of the string, setting the cursor position to the first
column. I didn't investigate further...

Thanks.


-- Package-specific info:

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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:2.0.1-1
ii  debconf [debconf-2.0]  1.5.65
ii  dmsetup2:1.02.145-4.1
ii  libc6  2.26-6

Versions of packages cryptsetup recommends:
ii  busybox 1:1.27.2-2
ii  console-setup   1.178
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kbd 2.0.4-2

Versions of packages cryptsetup suggests:
ii  dosfstools  4.1-1
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b3

-- debconf information:
  cryptsetup/prerm_active_mappings: true


Bug#801655: xorg crashes with "NOUVEAU(0): failed to set mode: Permission denied" when exiting tty2-6 shell

2018-01-24 Thread nfb
Package: xserver-xorg-video-nouveau
Version: 1:1.0.15-2
Followup-For: Bug #801655

I see this is old, but still existing bug, as of now.

startx on tty1, switch to tty2, login and exit, X session on tty1
crashes.
Anyways there is no freeze as reported in #801518, i.e. i can switch
to any tty and restart X again.

To avoid crashing X but still not willing to leave me logged in a
different tty (which i could forget about and let unlocked when i
step away from my pc), i kill the last bash instance on it, e.g.:

$ pkill -t tty2 -u 1000 bash

I attach the Xorg log containing the crash, but relevant lines are the
same as the ones originally submitted in this bug report.
If you need the full set of infos (most recent Xorg log, udev) which i
stripped out, let me know.

Thanks.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107GLM [Quadro 
K2000M] [10de:0ffb] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)


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

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

Versions of packages xserver-xorg-video-nouveau depends on:
ii  libc6  2.26-4
ii  libdrm-nouveau22.4.89-1
ii  libdrm22.4.89-1
ii  libudev1   236-3
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.5-1

Versions of packages xserver-xorg-video-nouveau recommends:
ii  libgl1-mesa-dri  17.2.5-1

Versions of packages xserver-xorg-video-nouveau suggests:
pn  firmware-misc-nonfree  

-- no debconf information
.local/share/xorg/Xorg.0.log
(Synaptics error lines:
"SynPS/2 Synaptics TouchPad: Read error 19"
"SynPS/2 Synaptics TouchPad: Read error 9"
removed because of flooding)



[ 66398.828] 
X.Org X Server 1.19.5
Release Date: 2017-10-12
[ 66398.830] X Protocol Version 11, Revision 0
[ 66398.831] Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
[ 66398.832] Current Operating System: Linux stfurtfm 4.14.0-2-amd64 #1 SMP 
Debian 4.14.7-1 (2017-12-22) x86_64
[ 66398.832] Kernel command line: BOOT_IMAGE=/vmlinuz 
root=UUID=e3ef26d2-2867-48fe-9369-d0a32c5e1d31ro  quiet   -- 
systemd.show_status=true initrd=/initrd.img
[ 66398.834] Build Date: 16 October 2017  12:28:38PM
[ 66398.835] xorg-server 2:1.19.5-1 (https://www.debian.org/support) 
[ 66398.836] Current version of pixman: 0.34.0
[ 66398.837]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 66398.837] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 66398.841] (==) Log file: "/home/me/.local/share/xorg/Xorg.0.log", Time: Wed 
Jan 10 00:52:47 2018
[ 66398.842] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 66398.842] (==) No Layout section.  Using the first Screen section.
[ 66398.842] (==) No screen section available. Using defaults.
[ 66398.842] (**) |-->Screen "Default Screen Section" (0)
[ 66398.842] (**) |   |-->Monitor ""
[ 66398.842] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 66398.842] (==) Automatically adding devices
[ 66398.842] (==) Automatically enabling devices
[ 66398.842] (==) Automatically adding GPU devices
[ 66398.842] (==) Max clients allowed: 256, resource mask: 0x1f
[ 66398.842] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 66398.842]Entry deleted from font path.
[ 66398.842] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 66398.842] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 66398.842] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 66398.842] (II) Loader magic: 0x564e91f15de0
[ 66398.842] (II) Module ABI versions:
[ 66398.842]X.Org ANSI C Emulation: 0.4
[ 66398.842]X.Org Video Driver: 23.0

Bug#856902: passwd: typos for subuids/subgids long options in usermod(8) man page

2017-03-05 Thread nfb
Package: passwd
Version: 1:4.4-4
Severity: minor

Dear Maintainer,

The usermod(8) man page contains wrong long options for uids/gids
related actions. We read:

[add|del]-sub-[uids|gids]

while it should be:

[add|del]-sub[uids|gids]

(there is an extra hyphen after 'sub')


Thanks for your time.


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

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

Versions of packages passwd depends on:
ii  libaudit1   1:2.6.7-1
ii  libc6   2.24-9
ii  libpam-modules  1.1.8-3.5
ii  libpam0g1.1.8-3.5
ii  libselinux1 2.6-3
ii  libsemanage12.6-2

passwd recommends no packages.

passwd suggests no packages.

-- no debconf information



Bug#844084: gnupg: typo in man page

2016-11-12 Thread nfb
Package: gnupg
Version: 2.1.15-4
Severity: minor

Dear Maintainer,

in the man page, the description of option '--delete-secret-keys'
starts with a lowercase 'g' like this:

"gRemove  key from the secret keyring. [...]"

Thank you.



-- 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/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-4
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-5
ii  libgcrypt201.7.3-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-1
ii  libsqlite3-0   3.15.0-1
ii  zlib1g 1:1.2.8.dfsg-2+b3

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-4
ii  gnupg-l10n  2.1.15-4

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information



Bug#840994: mpop: should exit with non-zero code when checking all accounts and errors occur for some of them

2016-10-16 Thread nfb
Package: mpop
Version: 1.2.5-1
Severity: normal
Tags: upstream

Dear Maintainer,

supposing one (or more) account has problems, if mpop was started to
check that account only, it will exit with non-zero code, like in my
case, a TLS handshake failed with code 76.
On the other hand, if it was started to check all of the accounts
(mpop -a), including the problematic one, it always returns zero whter
or not an error occured.
Some scripts may rely on the fact that no error occurred at all, so
the exit status is not meaningful when checking all accounts (IMHO).

Thank you for your time.



-- 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/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpop depends on:
ii  libc62.24-3
ii  libgnutls30  3.5.4-2
ii  libgsasl71.8.0-8+b1

mpop recommends no packages.

mpop suggests no packages.

-- no debconf information



Bug#837426: virtualbox: guest display not filling its window

2016-09-29 Thread nfb
Hi Nate,
from what i can see i believe it's the same issue. The misbehaviour is
not deterministic, so i have some random flashings/redraws when
starting the VM or when resizing it, like in your screencast.
Anyways im seeing some more comments upstream, hopefully someone will
start digging into it...
Thank you



Bug#837047: zathura not parsing zathurarc and forcing some default fallback theme

2016-09-08 Thread nfb
Package: zathura
Version: 0.3.6-2
Severity: normal

Dear Maintainer,

today zathura opened with a very basic, more like a default fallback,
theme, not using options set in zathurarc configuration file.
Launching zathura from the terminal prints this:



###

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

(zathura:7908): Gtk-WARNING **: Theme parsing error: :12:16:
Using Pango syntax for the font: style property is deprecated; please
use CSS syntax
error: Unable to load CSS: :12:8not a number

###



As only recent changes i see pango/gtk updates in my apt logs from few
days ago... maybe it's related to that.

Thank you.



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

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

Versions of packages zathura depends on:
ii  libc62.23-5
ii  libcairo21.14.6-1+b1
ii  libgirara-gtk3-2 0.2.6-1+b1
ii  libglib2.0-0 2.49.6-1
ii  libgtk-3-0   3.21.5-3
ii  libmagic11:5.28-4
ii  libsqlite3-0 3.14.1-1
ii  libsynctex1  2016.20160513.41080-6
ii  zathura-pdf-poppler  0.2.6-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  firefox-esr [www-browser]  45.3.0esr-1
ii  links [www-browser]2.13-1
ii  w3m [www-browser]  0.5.3-29
pn  zathura-cb 
pn  zathura-djvu   
pn  zathura-ps 

-- no debconf information



Bug#823454: mutt-patched: soft-fill behaviour no longer working in sidebar after 1.5.24-1 -> 1.6.0-1

2016-05-04 Thread nfb
Package: mutt-patched
Version: 1.6.0-1
Severity: normal

Dear Maintainer,

after having updated mutt(-patched) today from 1.5.24-1 to 1.6.0-1,
i noticed that long mailbox names are no longer truncated, and as
consequence mailbox sizes are no longer visible for some mailboxes,
since the name takes the whole space.

I remember the default behaviour of the previous version(s) was to
truncate long mailbox names to leave space to mailbox sizes, like in
the soft-fill format. Now it's the opposite.
Particularly, i never had to use the sidebar_format option in my
.muttrc (i don't even know wheter it has been introduced now or was
already there, just to say).

At this point, i tried getting the good ol' behaviour setting the
sidebar_format option, but it doesn't seem to do what i want. You can
consider this simplified test version:

set sidebar_format = "%B%*  %S"

With this format string I'd expect the rightmost part (mailbox size)
to be always visible because of the soft-fill (e.g. " 219"), and have
the mailbox name truncated at some point if it is too long, or padded
with ' ' if it is too short.
Anyway as i said, this is not working as expected, but it behaves like
the regular right-alignment was used ('%> ') since the mailbox sizes
are right-aligned, but mailbox names take the precedence when they are
too long. So:

- Is soft-fill even supported by the sidebar_format option?
- Is there an equivalent way to obtain this behaviour in the sidebar?
- Am i misunderstanding something?

In the same way, also the default value of the sidebar_format option
specified in the man page (Default: ā€œ%B%?F? [%F]?%* %?N?%N/?%4Sā€) is
not doing its job.

Let me know if you need additional infos.
Thank you.



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

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

Versions of packages mutt-patched depends on:
ii  libassuan02.4.2-3
ii  libc6 2.22-7
ii  libcomerr21.43~WIP.2016.03.15-2
ii  libgnutls30   3.4.11-4
ii  libgpg-error0 1.22-1
ii  libgpgme111.6.0-3
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libidn11  1.32-3
ii  libk5crypto3  1.13.2+dfsg-5
ii  libkrb5-3 1.13.2+dfsg-5
ii  libncursesw5  6.0+20160319-1
ii  libsasl2-22.1.26.dfsg1-15
ii  libtinfo5 6.0+20160319-1
ii  libtokyocabinet9  1.4.48-10
ii  mutt  1.6.0-1

mutt-patched recommends no packages.

mutt-patched suggests no packages.

-- no debconf information



Bug#821935: gdb-arm-none-eabi: internal-error using the 'run' command on an extended-remote target

2016-04-20 Thread nfb
Package: gdb-arm-none-eabi
Version: 7.10-1+9
Severity: normal

Dear Maintainer,

using the 'run' command on an extended-remote target results in:

../../gdb/gdb/inferior.c:361: internal-error: find_inferior_pid:
Assertion `pid != 0' failed.

After that, the only available action is terminating the debugging
session, optionally creating a core file.

As stated here [0], the 'run' command is supported in extended-remote
mode, and should work as if the program being debugged was local, and
restart it from the beginning when used.
A relevant detail may be that it actually works as expected on a
different computer i had, which had the very same gdb-arm version from
the debian repos (the current one), but on the 32 bit architecture.
This is the only difference i can notice between the two.

Let me know if additional infos are needed.
Thank you.



[0] https://sourceware.org/gdb/onlinedocs/gdb/Connecting.html


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

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

Versions of packages gdb-arm-none-eabi depends on:
ii  libc6 2.22-6
ii  libexpat1 2.1.1-1
ii  libncurses5   6.0+20160319-1
ii  libpython2.7  2.7.11-7
ii  libreadline6  6.3-8+b4
ii  libtinfo5 6.0+20160319-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gdb-arm-none-eabi recommends:
ii  gcc-arm-none-eabi  15:4.9.3+svn231177-1

gdb-arm-none-eabi suggests no packages.

-- no debconf information



Bug#806595: aptitude: Changelog download throws warning: "W: Can't drop privileges for downloading as file '/tmp/aptitude-root.15442:qGi6mn/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA' couldn't b

2015-12-14 Thread nfb
I'm getting these same warnings, both for root and regular user, so
i found this bug report.

>In my system, both dirs' permissions are 700 and owned by _apt:root,
>it doesn't emit any error and changelog works fine, no warnings.

Anyway on my system (Debian stretch/testing, aptitude 0.7.4-2):

$ ls -ld /var/lib/apt/lists/partial /var/cache/apt/archives/partial
drwx-- 2 _apt root 4096 dic 14 10:00 /var/cache/apt/archives/partial
drwx-- 2 _apt root 4096 dic 14 09:58 /var/lib/apt/lists/partial



Bug#803468: systemd: /etc/locale.conf locale variables are not set into the user locale

2015-10-30 Thread nfb
Package: systemd
Version: 227-2
Severity: normal

Dear Maintainer,

after installing locales package, generating my localization, editing
/etc/locale.conf and finally rebooting the system, all the locales
variable now default to "POSIX", as stated from the output of
"locale".
"localectl status", though, shows the desired values (the one i set in
/etc/locale.conf), so the status printed by localectl is different
from the actual status of the system.
Here is the output of the two commands:


---
$ locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

$ localectl status
   System Locale: LANG=C.UTF-8
  LC_NUMERIC=it_IT.UTF-8
  LC_TIME=it_IT.UTF-8
  LC_MONETARY=it_IT.UTF-8
  LC_NAME=it_IT.UTF-8
  LC_ADDRESS=it_IT.UTF-8
  LC_TELEPHONE=it_IT.UTF-8
  LC_MEASUREMENT=it_IT.UTF-8
   VC Keymap: n/a
  X11 Layout: it
   X11 Model: pc105
---


To circumvent this, i copied /etc/locale.conf to /etc/default/locale,
and in this way the locale is correctly set at startup.
Reading locale.conf(5) man page, one may think that editing
/etc/locale.conf is enough to set the locale, but indeed it's not.

Thanks.





-- Package-specific info:

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

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27-3
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcc1 1:5.2.1-22
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27-3
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 227-2
ii  mount   2.27-3
ii  sysv-rc 2.88dsf-59.2
ii  udev227-2
ii  util-linux  2.27-3

Versions of packages systemd recommends:
ii  dbus1.10.0-3
ii  libpam-systemd  227-2

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

-- Configuration Files:
/etc/systemd/logind.conf changed [not included]

-- no debconf information



Bug#803468: systemd: /etc/locale.conf locale variables are not set into the user locale

2015-10-30 Thread nfb
> > There is no /etc/locale.conf in Debian, the correct file is
> > /etc/default/locale
> 
> Btw, did you manually create /etc/locale.conf? This file is not shipped
> by systemd

There is no /etc/locale.conf but there is a man page for it. The file
itself is not shipped with systemd but its man page does:

$ dpkg -S /usr/share/man/man5/locale.conf.5.gz
systemd: /usr/share/man/man5/locale.conf.5.gz

and it states:

[...]
The /etc/locale.conf file configures system-wide locale settings. It
is read at early-boot by systemd(1).
[...]

I manually created the file according to this documentation, sorry if
i misunderstood but i never had to deal with locales, so i didn't know
which was the default debian file.



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-23 Thread nfb
 Hm, if the Chromium kernel/LSM forbids this, I don't see how this can be
 fixed in systemd? Do you?

Obviously the answer is no... i reported here since the commands in
the service file were working fine when executed by hand, so i thought
it couldn't be a kernel issue, but how systemd handled this kernel
restricion. Maybe could systemd handle such an issue transparently?
Thanks.


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



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-22 Thread nfb
 Are you suspecting the arm architecture or the custom kernel to be the
 culprit? Can you test the stock Debian kernel on arm?
 Your custom kernel, does it have every option enabled as specified in
 /usr/share/doc/systemd/README.gz

Yes i suspect about the kernel, also because among the error logs i
reported we can read:

kernel: Chromium OS LSM: Mount path with symlinks prohibited

I've not built the kernel by myself, so i don't know much details
about it, but it's the default chromeOS kernel shipped with this arm
chromebook. There is no way to try the stock debian kernel due to how
the boot process works on this device (restricted boot loader and
separate signed kernel partition).


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



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-22 Thread nfb
As i suspected there is no such issue on my main x86 laptop running
the same distro and updated software. The only difference is the arm
architecture and the custom kernel, as i noticed before.


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



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-12 Thread nfb
 Including the complete .service file would be helpful.

Oh yes i didn't specify i installed the tor package in the debian testing
repos, so the unit file is the one included in the package:

---

[Unit]
Description=Anonymizing overlay network for TCP
After=network.target nss-lookup.target

[Service]
Type=notify
NotifyAccess=all
PIDFile=/var/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d
/var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc
/usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
--verify-config
ExecStart=/usr/bin/tor --defaults-torrc
/usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutSec=45
Restart=on-failure
LimitNOFILE=65536

# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER

[Install]
WantedBy=multi-user.target

---


 That said, this sounds like an upstream issue, so please report that at
 
 https://github.com/systemd/systemd/issues/
 
 and report bug with the bug number.

Sorry, do i have to file an upstream bug referring to this bug number in its
body, or do i have to write back the upstream bug number here?

Thanks.


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



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-12 Thread nfb
 Once you file the bug upstream, reply to *this* bug report with the
 upstream bug report number.
 This way I can link the two bug reports and we can track the upstream
 process automatically.

here it is:

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


@Intrigeri
So you cannot confirm... maybe it's actually related to my system
configuration. I'd have checked on my other laptop if i could acces it (which
indeed didn't seem to have such problems in the past days), but unfortunately
i will stay away from it for a week or so...


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



Bug#792187: systemd: systemctl start not working when ReadWriteDirectories is a symlink

2015-07-12 Thread nfb
Package: systemd
Version: 221-1
Severity: normal

Dear Maintainer,

I installed tor (The onion router) the other day and when i started it
(either via /usr/sbin/service or systemctl) i went through this:


$ sudo systemctl start tor.service
Job for tor.service failed because the control process exited with
error code. See systemctl status tor.service and journalctl -xe
for details.

$ systemctl status tor.service 
ā— tor.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor
preset: enabled)
   Active: failed (Result: start-limit) since Sun 2015-07-12 01:47:54
CEST; 45s ago
  Process: 19035 ExecStartPre=/usr/bin/install -Z -m 02750 -o
debian-tor -g debian-tor -d /var/run/tor (code=exited,
status=226/NAMESPACE)


$ sudo journalctl -xe

[...]
Jul 12 01:47:54 blade systemd[1]: Starting Anonymizing overlay network
for TCP...
-- Subject: Unit tor.service has begun start-up
-- Defined-By: systemd
-- Support:
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit tor.service has begun starting up.
Jul 12 01:47:54 blade systemd[19030]: tor.service: Failed at step
NAMESPACE spawning /usr/bin/install: Too many levels of symbolic links
-- Subject: Process /usr/bin/install could not be executed
-- Defined-By: systemd
-- Support:
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- The process /usr/bin/install could not be executed and failed.
-- 
-- The error number returned by this process is 40.
Jul 12 01:47:54 blade kernel: Chromium OS LSM: Mount path with
symlinks prohibited - pid=19030 cmdline=(install)

Jul 12 01:47:54 blade systemd[1]: tor.service: Control process exited,
code=exited status=226
Jul 12 01:47:54 blade systemd[1]: Failed to start Anonymizing overlay
network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support:
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit tor.service has failed.
-- 
-- The result is failed.
Jul 12 01:47:54 blade systemd[1]: tor.service: Unit entered failed
state.
Jul 12 01:47:54 blade systemd[1]: tor.service: Failed with result
'exit-code'.
Jul 12 01:47:54 blade systemd[1]: tor.service: Service hold-off time
over, scheduling restart.
[...]


At first i thought it was a kernel issue (beware also that my kernel
is a chrome os kernel, not the one shipped by Debian, if that
matters). Anyways running the commands in the tor unit file by hand,
one by one in a terminal, leads to a correct execution. The same
renaming/removing the tor unit file and starting the service using the
init file in /etc/init.d.

After a quick jump on the #tor IRC channel we concluded that this may
be an issue on the systemd side, and after reading something around
the web we tried to tweak the Hardening section of the unit file. And
indeed we found that ReadWriteDirectories is set to /var/run which on
my system is a link to /run. Changing ReadWriteDirectories to /run and
running 'systemctl daemon-reload' solved the issue and now the service
is starting fine.


Let me know if more infos are needed.
Thanks.



-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.9.2-3
ii  libaudit1   1:2.4.2-1
ii  libblkid1   2.26.2-6
ii  libc6   2.19-18
ii  libcap2 1:2.24-9
ii  libcap2-bin 1:2.24-9
ii  libcryptsetup4  2:1.6.6-5
ii  libgcc1 1:5.1.1-12
ii  libgcrypt20 1.6.3-2
ii  libkmod220-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.26.2-6
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.1-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 221-1
ii  mount   2.26.2-6
ii  sysv-rc 2.88dsf-59.2
ii  udev221-1
ii  util-linux  2.26.2-6

Versions of packages systemd recommends:
ii  dbus1.8.18-1
ii  libpam-systemd  221-1

Versions of packages systemd suggests:
pn  systemd-ui  none

-- Configuration Files:
/etc/systemd/logind.conf changed [not included]

-- 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#788349: mpv: Segmentation fault after upgrade (libnettle6 installation)

2015-06-13 Thread nfb
 Yep, same as #787620 as well. It's caused by the fact that libnettle4 doesn't
 provide symbols versioning so both libenttle4 and libnettle6 may get loaded at
 the same time.
 
 To fix this you should make sure that packages that use nettle are updated, in
 particular libgnutls-deb0-28.
 
 Since mpv doesn't depend directly on nettle or gnutls (they are pulled in due
 to other packages), there isn't anything I can do about this.

Yes after upgrading libgnutls-deb0-28 everything works as expected.
Thanks for the support.


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



Bug#788333: wget: Segmentation fault after upgrade (libnettle6 installation)

2015-06-10 Thread nfb
Package: wget
Version: 1.16.3-2+b2
Severity: grave
Justification: renders package unusable

Hi,
after today's upgrade which installed libnettle6 as dependency, i get
segmentation fault running wget.
Here is the gdb output:



$ gdb wget
(gdb) run
Starting program: /usr/bin/wget 
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/arm-linux-gnueabihf/libthread_db.so.1.

Program received signal SIGSEGV, Segmentation fault.
0xb6f4a580 in nettle_yarrow256_update () from
/usr/lib/arm-linux-gnueabihf/libnettle.so.6
(gdb) bt
#0  0xb6f4a580 in nettle_yarrow256_update () from
/usr/lib/arm-linux-gnueabihf/libnettle.so.6
#1  0xb6eff76c in ?? () from
/usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
Backtrace stopped: previous frame identical to this frame (corrupt
stack?) 



If more infos are needed let me know.
Thanks.


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

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

Versions of packages wget depends on:
ii  libc6  2.19-18
ii  libgnutls-deb0-28  3.3.15-2
ii  libidn11   1.30-1
ii  libnettle6 3.1.1-3
ii  libpcre3   2:8.35-5
ii  libpsl00.5.1-1
ii  libuuid1   2.26.2-6
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages wget recommends:
ii  ca-certificates  20150426

wget 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#788333: wget: Segmentation fault after upgrade (libnettle6 installation)

2015-06-10 Thread nfb
I forgot to mention the upgraded packages:

[INSTALL, DEPENDENCIES] libhogweed4:armhf
[INSTALL, DEPENDENCIES] libnettle6:armhf
[UPGRADE] dpkg:armhf 1.17.25 - 1.18.1
[UPGRADE] libgpg-error0:armhf 1.17-3 - 1.19-2
[UPGRADE] libldap-2.4-2:armhf 2.4.40+dfsg-1 - 2.4.40+dfsg-1+b2
[UPGRADE] libperl4-corelibs-perl:armhf 0.003-1 - 0.003-2
[UPGRADE] librtmp1:armhf 2.4+20150115.gita107cef-1 -
2.4+20150115.gita107cef-1+b2
[UPGRADE] rename:armhf 0.20-3 - 0.20-4
[UPGRADE] wget:armhf 1.16.3-2 - 1.16.3-2+b2

Best regards.


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



Bug#788349: mpv: Segmentation fault after upgrade (libnettle6 installation)

2015-06-10 Thread nfb
Package: mpv
Version: 0.9.2-1
Severity: important

Hi,
after today's upgrade which installed libnettle6 as dependency, i get
segmentation fault running mpv.
Here is the gdb output:


$ gdb mpv
(gdb) run
Starting program: /usr/bin/mpv 
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/arm-linux-gnueabihf/libthread_db.so.1.

Program received signal SIGSEGV, Segmentation fault.
0xb468e580 in nettle_yarrow256_update () from
/usr/lib/arm-linux-gnueabihf/libnettle.so.6
(gdb) bt
#0  0xb468e580 in nettle_yarrow256_update () from
/usr/lib/arm-linux-gnueabihf/libnettle.so.6
#1  0xb51bc76c in ?? () from
/usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)


May be related to bug #788333:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788333



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

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

Versions of packages mpv depends on:
ii  libasound2  1.0.28-1
ii  libass5 0.12.2-1
ii  libavcodec566:11.4-2
ii  libavdevice55   6:11.4-2
ii  libavfilter56:11.4-2
ii  libavformat56   6:11.4-2
ii  libavresample2  6:11.4-2
ii  libavutil54 6:11.4-2
ii  libbluray1  1:0.8.1-1
ii  libbs2b03.1.0+dfsg-2.1
ii  libc6   2.19-18
ii  libcdio-cdda1   0.83-4.2
ii  libcdio-paranoia1   0.83-4.2
ii  libcdio13   0.83-4.2
ii  libdrm2 2.4.60-3
ii  libdvdnav4  5.0.1-4
ii  libdvdread4 5.0.0-1
ii  libegl1-mesa [libegl1-x11]  10.5.5-1
ii  libenca01.16-1
ii  libgl1-mesa-glx [libgl1]10.5.5-1
ii  libguess1   1.2-1
ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20140719git3eb0ae6a~dfsg-2
ii  libjpeg62-turbo 1:1.4.0-7
ii  liblcms2-2  2.6-3+b3
ii  liblua5.2-0 5.2.3-1.1
ii  libpulse0   6.0-2
ii  libsdl2-2.0-0   2.0.2+dfsg1-7
ii  libswscale3 6:11.4-2
ii  libva-x11-1 1.5.1-2
ii  libva1  1.5.1-2
ii  libvdpau1   1.1-1
ii  libwayland-client0  1.7.0-2
ii  libwayland-cursor0  1.7.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  10.5.5-1
ii  libx11-62:1.6.3-1
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxrandr2  2:1.4.2-1+b1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.10-1+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.0~rc1+git20111210-7.4
pn  youtube-dl  none

mpv 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#787781: [pkg-gnupg-maint] Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-09 Thread nfb
  stdbuf -oL gpg --use-agent --sign file
 
  works without errors retrieving the cached password from gpg-agent.
  I'd say the problem is not directly gpg-agent then...
 depends on how gpg-agent is configured.  for example, do you have
 ignore-cache-for-signing in ~/.gnupg/gpg-agent.conf ?

Nop, i don't have ~/.gnupg/gpg-agent.conf, i currently have no need
for settings other than de dafault ones.
Anyways i start noticing this isssue is happening quite often on my
intel machine too, but with some weirdness. I mean, i have six mail
accounts configured for mpop, so it should do six calls to
pass+gpg(+gpg-agent only the first time), and while on arm i get six
broken pipe errors, on my x86 i get from zero to two/three of them
randomly.


 [...] and we shouldn't distract #787781 with it.

Yes sure, sorry for that.


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



Bug#787781: [pkg-gnupg-maint] Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-06 Thread nfb
 how many cores does the i386 machine have?  from the initial report, i
 see that your armhf machine is marked as SMP w/2 CPU cores.  How much
 RAM does each machine have?

The i386 machine is a core 2 Duo with 4Gb of RAM. The armhf one is an
arm chromebook, dual core with 2Gb of RAM.
Anyways on both machines RAM usage is well under a critical value, i 
guess 25%-30% at most...

 I'm cc'ing Colin Watson (the pass maintainer) here, maybe he can try to
 replicate the behavior you've observed in https://bugs.debian.org/787781

Yes it's a good idea... i'd also try to abstract the issue even more,
so if i manage to use gpg-agent in a way that doesn't involve pass,
(maybe asimmetrically signing/encrypting some files) and the error
shows up again when invoking via stdbuf, than it'd be likely and
strictly an issue on gpg-agent and not pass... (shouldn't it?)

Updates will follow...


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



Bug#787781: [pkg-gnupg-maint] Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-06 Thread nfb
 Yes it's a good idea... i'd also try to abstract the issue even more,
 so if i manage to use gpg-agent in a way that doesn't involve pass,
 (maybe asimmetrically signing/encrypting some files)

*decrypting

 and the error
 shows up again when invoking via stdbuf, than it'd be likely and
 strictly an issue on gpg-agent and not pass... (shouldn't it?)
 
 Updates will follow...

Well, using:

stdbuf -oL gpg --use-agent --sign file

works without errors retrieving the cached password from gpg-agent.
I'd say the problem is not directly gpg-agent then...

Anyways executing the command above, i noticed it asked me the
passphrase via pinentry curses althogh it was already cached, because
i used it few seconds before with pass, and i used it after just to be
sure (obviously i have signed the test file with the same key pass
uses to encrypt its password store).
Now i don't know gpg-agent internals, but shouldn't it have used the
already cached passphrase? Also the two pinentry dialog showed when
using pass and when using gpg are slightly different in text and size.
But maybe this is OT.

Thanks.


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



Bug#787781: [pkg-gnupg-maint] Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-05 Thread nfb
Hi, thanks.
Well, after some quick tests the results push me to explain the whole
script, which i didn't do at the beginning to just keep to focus on the
issue itself without additional bloat, because in any case the error
is on the gpg functionality which is used by pass only. So everything
i wrote (with some corrections i'll write now) is also reproducible
without knowing the full details of my scripts, but we never know they
may be useful...


  i have a script that uses pass [0] password manager, which on his hand
  uses gpg-agent to remember the master passphrase, as you can see.
  Also i have to filter its output, so i pipe it into another script,
  but since i want the output to be unbuffered to get a more real-time
  feedback, i tried calling it this way:
 
  stdbuf -oL pass pass_arguments

The script actually calls mpop pop3 client, which i set to use its
passwordeval functionality to retrieve appropriate passwords for each
account from pass password manager.
mpop is invoked via stdbuf (to achieve line by line printing) piping
its output into another script. So it may be logically represented
something like:
mpop (= pass (= gpg + gpg-agent)) | anotherscript
while the actual command in the script is:

stdbuf -oL mpop mpop_arguments | anotherscript

The second part after the pipe should be not relevant at all, since
the issue also happens without any piping.

The reason i decided to describe the full structure is that in the
mpoprc config file, pass is called just with the account i want the
password for as argument, such as:

passwordeval pass my_mail_account

And this results in the broken pipe error as reported.
Anyways i'm not able to get a broken pipe directly calling on a
terminal:

stdbuf -oL pass my_mail_account

which whould be equivalent, unless i also use the -c switch (that
copies the output to clipboard instead of the stdout). So:

stdbuf -oL pass -c pass_arguments

gives broken pipe.
This was the command i was using to test yesterday from the command
line, but i tought the -c switch was not relevant so in the quoted
command in my first mail i didn't specify it.
I decided to describe everything because these last steps seemed weird
to me.

So to sum up, the broken pipe error is present when mpop calls pass
with just the mail account as argument, or on the command line
specifying the -c switch too (always invoking them via stdbuf).

Another weird thing i noticed is that if i call consecutively multiple
times the command line command (the one with -c) discussed above, the
error happens one time but not the following, then it shows again and
so on alternating almost deterministically, but sometimes it doesn't
alternate.

 
 Is that the only difference between your arm device and your x86 device?

Yes, this should be the only difference, i keep the two machines
synced on most scripts and using the same packages (they are both
debian testing too). The kernel is different anyways, it's 3.8.11 on
th arm side, if that matters.

 
 From the footer in your bug report, you're using pinentry-curses on the
 arm device.  is this true for x86 as well, or are you using a different
 pinentry there?
 
 on each machine, what do these show?
 
   readlink -f /etc/alternatives/pinentry
   grep pinentry ~/.gnupg/*.conf
 

I use pinentry on both. The readlink command shows
/usr/bin/pinentry-curses while grep finds nothing, on both machines.


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



Bug#787781: [pkg-gnupg-maint] Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-05 Thread nfb
A quick update, just for information.
This night for the first time in my life i've seen this broken pipe
error on my x86 laptop too when running the script. It happened once
but then has not appeared again running the script multiple
consecutive times. On my arm device it happens almost always, as i
told.
It's getting more and more weird...


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



Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

2015-06-04 Thread nfb
Package: gnupg-agent
Version: 2.0.27-2
Severity: normal

Hi,
i have a script that uses pass [0] password manager, which on his hand
uses gpg-agent to remember the master passphrase, as you can see.
Also i have to filter its output, so i pipe it into another script,
but since i want the output to be unbuffered to get a more real-time
feedback, i tried calling it this way:

stdbuf -oL pass pass_arguments

which buffers on a per line basis. On my x86 pc everything is fine,
while on my arm device i get:

gpg: error writing to `-': Broken pipe
gpg: handle plaintext failed: Broken pipe

but after that the script works as expected.
So i was wondering if any tool using gpg-agent invoked with stdbuf
with '-oL' option gives this error. I tried using '-o0' instead of
'-oL' as stdbuf option, and this gives no problems. I also tried
doing some symmetric encryptions/decriptions (not involving gpg-agent)
to make sure the issue was on the agent side, invoking every time gpg
with stdbuf, and indeed no error is showed when the agent is not used.


P.S.:
I really didn't know if this issue had the requisites to be reported
as bug, so forgive me in case it's not, or let me know if more details
are needed.


[0] http://www.passwordstore.org



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

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

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.2.1-1
ii  libc6   2.19-18
ii  libgcrypt20 1.6.3-2
ii  libgpg-error0   1.17-3
ii  libpth202.0.7-20
ii  libreadline66.3-8+b3
ii  pinentry-curses [pinentry]  0.9.2-1

Versions of packages gnupg-agent recommends:
ii  gnupg   1.4.19-3
ii  gnupg2  2.0.27-2

gnupg-agent 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#787211: libopenblas-base: 100% CPU load on ARM

2015-05-29 Thread nfb
Package: libopenblas-base
Version: 0.2.14-1
Severity: normal


Hi,
i have experienced 100% CPU load on ARM with octave + libopenblas as
reported here [0]. I don't know if this is due to my hardware setup or
it can be verified on other platforms too, but if verified maybe it
could be nice to contact octave mantainers and tell them to remove
libopenblas from the dependencies list until a fix (or apply a more
appropriate procedure for these cases, idk).
I was told in the #octave IRC channel that this bug may be already
known upstream, but i wonder if something can be done on the Debian
side to avoid CPU cycles wastage to users who may not monitor their
CPU usage during the program execution, and so may be unaware of the
issue.
If you need more informations let me know.

Thanks.


[0]
http://lists.gnu.org/archive/html/help-octave/2015-05/msg00108.html


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

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


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



Bug#783745: libsecret-tools: Should depend on gnome-keyring in some way?

2015-04-29 Thread nfb
Package: libsecret-tools
Version: 0.18-1+b1
Severity: normal

Installing libsecret-tools on a system which doesn't already have gnome-keyring
package installed, and then running secret-tool results into the following:

** Message: Remote error from secret service:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was
not provided by any .service files
secret-tool: The name org.freedesktop.secrets was not provided by any .service
files

So should libsecret-tools depend on gnome-keyring in some way to avoid this?

Thanks.


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages libsecret-tools depends on:
ii  libc6  2.19-18
ii  libglib2.0-0   2.42.1-1
ii  libsecret-1-0  0.18-1+b1

libsecret-tools recommends no packages.

libsecret-tools 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