Bug#1032381: aide: Broken aideinit due to _aide user handling

[Dark]

Yep this is a systemd system

The only relevant customisation I can think of is adduser.conf set to 
'DIR_MODE=0750' (which I reverted to the new 0700 default as part of the 
upgrade, but not sure if that happened before or after aide was 
upgraded), and proc mounted with 'hidepid=2' (which I know systemd 
sometimes isn't happy with)


Will get a separate bug written up soon


On 02/05/2023 12:41, Marc Haber wrote:

Hi Dark,

please file a new bug report, that gives more information about your
system.

Are you using systemd?

Greetings
Marc

Bug#873073: [Pkg-samba-maint] Bug#873073: Other ways to disable IPv6 ?

[Dark Penguin]

On 24/07/19 22:14, Mathieu Parent wrote:
> Le mer. 24 juil. 2019 à 00:27, Dark Penguin  a écrit :
>>
>> On 24/07/19 00:15, Mathieu Parent wrote:
>>> Version: 2:4.9.5+dfsg-5
>>>
>>> I'm closing this bug with the version in buster.
>>>
>>> Le dim. 21 juil. 2019 à 21:45, Dark Penguin  a 
>>> écrit :
>>>>
>>>> I tried this just now. The result is, basically, nothing: my kernel does
>>>> not have IPv6 support anyway, so restricting IPv6 out on the systemd
>>>> level does not change anything. There are still error messages about
>>>> being unable to bind to IPv6 upon restarting smbd, however with this,
>>>> restarting it also takes a few seconds instead of happening almost
>>>> instantly.
>>>>
>>>> I guess the "proper" solution would be the same: if there are no IPv6
>>>> interfaces in the system, smbd should not try to bind to them. If it was
>>>> specifically instructed to bind to a certain interface and it is
>>>> unavailable, then output an error message "This interface is requested
>>>> but unavailable", instead of "open_socket_in(): socket() call failed:
>>>> Address family not supported by protocol". This error message is not
>>>> even decipherable without Google's help.
>>>
>>> The following binds to IPv4 only:
>>>
>>>   interfaces = lo 0.0.0.0
>>>   bind to interfaces only = yes
>>>
>>> Regards
>>
>>
>> Umm... I've actually tried that before.
> 
> Confirmed with:
>interfaces = 127.0.0.0/8 0.0.0.0
>bind interfaces only = yes
> 
> 
> $ sudo ss -lntp | grep smbd
> LISTEN0 50   127.0.0.1:445
> 0.0.0.0:*users:(("smbd",pid=9146,fd=32))
> LISTEN0 50   127.0.0.1:139
> 0.0.0.0:*users:(("smbd",pid=9146,fd=33))


We should probably reopen this then?..


-- 
darkpenguin

Bug#873073: [Pkg-samba-maint] Bug#873073: Still present in Buster

[Dark Penguin]

Oh, there was a file like that?.. ^_^

Ooohkay, this has revealed something interesting.

In /etc/default/networking, it says:

# Which interface to wait for.
# If none given, wait for all auto interfaces, or if there are none,
# wait for at least one hotplug interface.
#WAIT_ONLINE_IFACE=

I have two interfaces: "auto lo" and "allow-hotplug eth0". So, in my
case, by default it waits for lo, and then the network is assumed to be
up. (Apparently "if there are none" includes lo, which makes little sense.)

Changing this to "auto eth0" has fixed the smbd problem!

I remember having read somewhere that "allow-hotplug implies auto", so I
usually change eth0 to allow-hotplug without expecting any consequences
of this kind. Turns out that with "allow-hotplug", the system does not
wait for the interface to come up at boot, that's why samba starts
without it.

Changing it back to "auto" fixes this problem, but introduces another
one. For some reason, DHCP address acquisition takes 5 to 8 seconds, so
the downside is adding 8 seconds to the system boot time.



So, to sum it up:

- If you are running a samba server, then either run it on an "auto"
interface, or restart it after configuring a hotplug interface by adding
this line in the interface's definition:

up /bin/systemctl restart smbd.service nmbd.service || true

This actually makes sense. If you reconfigure a hotplug interface, you'd
probably want to restart everything that is supposed to listen on it.

(Come to think about it, why doesn't sshd have this problem?.. Maybe
because it listens on 0.0.0.0 ?.. Specifying 0.0.0.0/0 as an interface
to listen on in smb.conf does not help.)

- Still, it would be nice to fix samba so that it does not try to bind
to nonexistent interfaces (even though it is not even asked to), and
does not output a high-level uninformative error message when it fails
to do that. This would allow us to not worry about IPv6 and not see the
strange red error message at the same time. It could probe those
interfaces if it wants to bind to all of them, but a negative probing
result is expected, and is not a high-level error.



On 15/07/19 16:36, Mathieu Parent wrote:
> Le dim. 14 juil. 2019 à 14:51, Dark Penguin  a écrit :
>>
>> This issue is still present in Buster.
>>
>> Changing the interface name to its IP address in smb.conf does not make
>> sense because we're talking about a situation when your IP address is
>> managed by DHCP.
>>
>> Tweaking the systemd service files does not help according to the OP,
>> and even if it did, this is not a solution - network-online.target
>> apparently still does not work.
>>
>> Mathieu, is there a bug report with more details about the
>> network-online.target problem? It looks pretty serious since it can
>> potentially break all network-based daemons, and is still not fixed in
>> Buster.
> 
> Have you considered tuning /etc/default/networking ?
> 
> For example:
> WAIT_ONLINE_METHOD="ifup"
> WAIT_ONLINE_IFACE="enp2s0"
> WAIT_ONLINE_ADDRESS=""
> WAIT_ONLINE_TIMEOUT=300
> 
> or:
> WAIT_ONLINE_METHOD="ping"
> WAIT_ONLINE_IFACE=""
> WAIT_ONLINE_ADDRESS="128.31.0.62"
> WAIT_ONLINE_TIMEOUT=300
> 
> See also /lib/ifupdown/wait-online.sh
> 
> What is the content of /etc/network/interfaces?
> 
> Regards
> 

-- 
darkpenguin

Bug#873073: [Pkg-samba-maint] Bug#873073: Other ways to disable IPv6 ?

[Dark Penguin]

I tried this just now. The result is, basically, nothing: my kernel does
not have IPv6 support anyway, so restricting IPv6 out on the systemd
level does not change anything. There are still error messages about
being unable to bind to IPv6 upon restarting smbd, however with this,
restarting it also takes a few seconds instead of happening almost
instantly.

I guess the "proper" solution would be the same: if there are no IPv6
interfaces in the system, smbd should not try to bind to them. If it was
specifically instructed to bind to a certain interface and it is
unavailable, then output an error message "This interface is requested
but unavailable", instead of "open_socket_in(): socket() call failed:
Address family not supported by protocol". This error message is not
even decipherable without Google's help.


On 15/07/19 16:51, Mathieu Parent wrote:
> Le dim. 14 juil. 2019 à 15:09, Dark Penguin  a écrit :
>>
>> This particular case could be less of a problem (at least to me) if
>> adding "bind interfaces only = yes" was not the only way to disable IPv6
>> in samba.
>>
>> Would it make sense to change the priority of an error message on
>> startup about missing IPv6 support? If samba sees that IPv6 is not
>> supported on this system, shouldn't it deduce that it is therefore not
>> required, and output an "info" message like "Not binding to IPv6 -
>> protocol not supported" instead of an error?
> 
> Have you tried overriding with:
> 
> cat /etc/systemd/system/smbd.service
> [Service]
> RestrictAddressFamilies=AF_UNIX AF_INET
> 
> (then systemctl daemon-reload and systemctl restart smbd)
> 
> (Not tested...)
> 
> Regards
> 

-- 
darkpenguin

Bug#873073: Other ways to disable IPv6 ?

[Dark Penguin]

This particular case could be less of a problem (at least to me) if
adding "bind interfaces only = yes" was not the only way to disable IPv6
in samba.

Would it make sense to change the priority of an error message on
startup about missing IPv6 support? If samba sees that IPv6 is not
supported on this system, shouldn't it deduce that it is therefore not
required, and output an "info" message like "Not binding to IPv6 -
protocol not supported" instead of an error?


-- 
darkpenguin

Bug#873073: Still present in Buster

[Dark Penguin]

This issue is still present in Buster.

Changing the interface name to its IP address in smb.conf does not make
sense because we're talking about a situation when your IP address is
managed by DHCP.

Tweaking the systemd service files does not help according to the OP,
and even if it did, this is not a solution - network-online.target
apparently still does not work.

Mathieu, is there a bug report with more details about the
network-online.target problem? It looks pretty serious since it can
potentially break all network-based daemons, and is still not fixed in
Buster.


-- 
darkpenguin

Bug#929892: vfat mounts are not protected

[Dark Penguin]

Package: bilibop-lockfs
Version: 0.5.6

In lockfs mode, if there are any vfat mounts to be protected, they are
ignored and simply mounted as read-write. Everything else is properly
protected with overlayfs.

Isn't it kind of dangerous?.. The user is expecting everything to be safe!

If it is not possible to protect a vfat filesystem due to overlayfs
limitations, then maybe it should be mounted read-only instead of
read-write? At least then the user will notice it before breaking
something, and add it to the whitelist if they want it read-write,
easily replicating the current behaviour. And currently, there is no way
to do the opposite - which is, "in lockfs mode, mount everything that
can not be properly protected as read-only".


This is reproducible on Debian Buster amd64 , and also on Raspbian
Stretch with bilibop 0.5.6 from Debian Buster armhf.


-- 
darkpenguin

Bug#929893: Emergency shell due to broken parsing

[Dark Penguin]

Package: bilibop-lockfs
Version: 0.5.6


Steps to reproduce:

# apt-get install bilibop --no-install-recommends

Now, add a single line to the bottom of /etc/bilibop/bilibop.conf :

BILIBOP_LOCKFS_WHITELIST=/anything

It does not matter if this directory exists or not. Now do an
"update-initramfs -u -k all", and reboot. You won't be able to boot,
because all mounts except "/" will fail, giving you an emergency shell.

Attempting to mount one of them manually (by "mount /mydir") gives me
the following result:

/sbin/mount.lockfs: 1: eval: net.ifnames=0: not found

This is apparently a part of my kernel command line. Here it is, just in
case:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=64e67ea6-1627-4258-9c70-8bcc120daf86 ro console=tty1
console=ttyS0 ipv6.disable=1 net.ifnames=0 consoleblank=0 lockfs


This is reproducible on Debian Buster amd64 and Raspbian Stretch with
bilibop 0.5.6 from Debian Buster armhf.

Other lines in bilibop.conf work fine, only the "whitelist" one seems to
break things. However, whitelisting other mounts or marking them
"noauto" in /etc/fstab seems to help, despite the option itself being
the source of the problem. %)


-- 
darkpenguin

Bug#929891: Error message about udev rules not found

[Dark Penguin]

Package: bilibop-rules
Version: 0.5.6

After installing bilibop, even without enabling lockfs, I see this error
message during the boot process:

---
Begin: Running /scripts/local-bottom ... Warning: bilibop-lockfs:
Nothing to do.
ls: /root/etc/udev/rules.d/70-persistent-cd.rules: No such file or directory
ls: /root/etc/udev/rules.d/70-persistent-net.rules: No such file or
directory
done.
---


With lockfs enabled, it is still there:

---
Begin: Running /scripts/local-bottom ... Warning: bilibop-lockfs:
Locking files.
Begin: bilibop-lockfs: Setting up overlay branches ... done.
Success: bilibop-lockfs: Root filesystem is now locked (soft policy).
Warning: bilibop-lockfs: Modifying temporary static filesystem table
(fstab).
ls: /root/etc/udev/rules.d/70-persistent-cd.rules: No such file or directory
ls: /root/etc/udev/rules.d/70-persistent-net.rules: No such file or
directory
done.
---


This is reproducible on Debian Buster amd64, and I saw it on Raspbian
Stretch with bilibop 0.5.6 from Debian Buster armhf.

I don't see any negative consequence of this, other than making the user
scared a little, but it is still an error message meant to be noticed.
Maybe it will help find other bugs. :)


-- 
darkpenguin

Bug#929890: Error during installation and uninstallation

[Dark Penguin]

Package: bilibop-rules
Version: 0.5.6

During installation AND uninstallation, I see the following error message:

---
Setting up bilibop-rules (0.5.6) ...
dpkg: error: --compare-versions takes three arguments: 
 

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or
'more' !
---

I don't see any other negative effect of this, but an error message is
there for someone to notice, so I noticed it. :)

This is reproducible on Debian Buster amd64 (debootstrapped installation
in qemu), and Raspbian Stretch with bilibop 0.5.6 from Debian Buster armhf.


-- 
darkpenguin

Bug#816874: Bug#816779: Remmina doesn't always honor scale ratio lock

[Dark Penguin]

Yes, this was a bug in 1.1.2, which was buggy. So I moved to 1.2.0, 
which was not in the repo at the time, but without this bug.



--
darkpenguin

Bug#845445: mutter: illegal instruction error

[dark yux]

Package: mutter
Version: 3.14.4-1~deb8u1
Severity: important

Dear Maintainer,

When trying to use mutter I receive a illegal instruction error. Try this with 
two terminals:

Terminal 1:
Xephyr -ac -br -noreset -screen 800x600 :1

Terminal 2:
mutter -d :1

I expected Mutter functioning within a Xephyr window. Instead I got: "[1]
21548 illegal hardware instruction  mutter -d :1".

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mutter depends on:
ii  gnome-themes-standard      3.14.2.2-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  libc6                      2.19-18+deb8u6
ii  libclutter-1.0-0           1.20.0-1
ii  libglib2.0-0               2.42.1-1+b1
ii  libmutter0e                3.14.4-1~deb8u1
ii  libx11-6                   2:1.6.2-3
ii  libxcomposite1             1:0.4.4-1
ii  mutter-common              3.14.4-1~deb8u1
ii  zenity                     3.14.0-1
Versions of packages mutter recommends:
ii  openbox [x-session-manager]  3.5.2-8
Versions of packages mutter suggests:
ii  gnome-control-center  1:3.14.2-3
ii  xdg-user-dirs         0.15-2
 

Bug#787950: mdadm/checkarray: broken on current debian systems

[Dark Penguin]

The easiest fix for this is changing #!/bin/sh to #!/bin/bash in that 
file. And I believe it's the "correct" fix, because the shebang line is 
invented specifically to tell you which interpreter to use, so it you 
write a script for Bash, you should put Bash there, not Dash or whatever 
sh could be installed on that system. And I think Bash is installed by 
default on almost any system, exactly because a lot of scripts require 
specifically Bash to execute.


Changing only two letters in one file. To fix a grave-level bug that has 
been there for a year. In Debian STABLE. Is it too much to ask?..


By the way, how come this bug report is not "grave", but "normal"?! 
Going on without periodical scrubs is a direct way to lose all your 
data, which is, by definition, "grave", correct? And the bug affects 
100% of the users. All of them. Except maybe the ones who changed their 
default shell to Bash, which is hardly a lot.


Actually, I have a list of similar bugs in Jessie that are around for 
over a year, with extremely simple fixes (if you know about the bug in 
the first place). Because of this tendency to ignore such bugs, Debian 
Stable is now becoming the most unstable distro out there, effectively 
failing its only mission: "The goal of the Debian Project is Debian 
Stable" (I can't find the exact document on the Debian website in which 
I read this only yesterday).



--
darkpenguin

Bug#835840: Bugs in Remmina

[Dark Penguin]

Just came here to ask for better Remmina support.  Use it every day, and
use Wheezy and Devuan exclusively.  What's the hold up, biggest blocker /
barrier?  How can I help?


Apparently, it's just the number of issues in FreeRDP 2.0. Actually, I 
understand the reasoning, but I think this is an exceptional situation 
specifically described somewhere in the Debian release policy: something 
like "usually, packages make their way from unstable into testing when 
the number of bugs is low enough, but sometimes the maintainer can 
decide that the advantages of having that package outweigh the 
unstability risks, so they an force it manually".


We're not talking about "from unstable into testing" right now, but the 
idea is the same: anyone who actually tried both versions agrees that 
the new version that works but suggests an unstable package is better 
than the old version that does barely work at all.


Actually, there are only 18 bugs in Remmina 1.2.0 versus 20 bugs in 
Remmina 1.1.2 in Jessie, 5 of which are "important" (3 of them being 
segfaults). I'd say 18 < 20 , really. (I hope you did not count wishlist 
items, "notabug"-s, "questions", "outofscope"-s and everything else 
while looking at the number of open issues on Github? You did filter 
them by "bugs" label, right?.. And we don't necessarily have to package 
FreeRDP 2.0 - having Remmina alone would be better already.)




My experience with Remmina 1.1.2 on Jessie:
- Every few minutes, there is a segfault (important)
- When changing my layout with Alt+Shift, Alt gets stuck (important)
- Scaling doesn't work properly (important)
- Shift+Tab doesn't get across (normal, if you don't use it often)
- Sometimes the main window opens when connecting from tray (minor)

Now, I'm sorry for some off-topic, but the only package that can beat 
the record of five bugs everyone is affected by is nut, which has four 
100% reproducible grave bugs that render the whole critically important 
package not only useless, but harmful (it's UPS management software - 
you can damage your hardware and lost your data because of those bugs). 
Basically, it does not shut down your machine upon power loss (which is 
the purpose of the package), it does not shut down your UPS after that, 
and two common workarounds for that do not work. That's partly because 
of systemd, which is somehow deemed stable enough to be not only 
present, but default and mandatory in Debian.


Of course, all those are fixed in Remmina 1.2.0, and it works flawlessly.


--
darkpenguin

Bug#835840: Bugs in Remmina

[Dark Penguin]

Have you actually tried either of them? I don't know how many bugs are 
in Remmina 1.1.2 and how many in Remmina 1.2.0, but my actual experience 
(I use Remmina a lot every day) shows that Remmina 1.1.2 is utterly 
broken and barely usable, while 1.2.0 works just fine.


Actually, I notice this kind of things more and more lately. Debian 
Stable is becoming the most unstable distro because nobody is interested 
in fixing bugs for software this old - and for some reason, even the 
most obvious bugs have not been fixed before the release. In the newer 
versions, all those things have been fixed years ago, but those fixes do 
not make their way into stable. I don't have anything against old 
software, but not buggy software, and it's called "stable" because it's 
supposed to actually be stable. I've been using exclusively Debian 
Stable for many years, but seems like it's time to abandon ship because 
of this tendency. (Why is it that Remmina is "not yet stable enough", 
but systemd is?.. That's what most of those problems are with...)


By the way, I'm not using FreeRDP - only Remmina, for VNC. And no, 
Remmina does NOT "depend" on FreeRDP - you can run it without FreeRDP. 
So maybe it would be an acceptable solution to package Remmina 1.2.0 as 
a separate package called "remmina-next", and not package the "unstable" 
FreeRDP at all?..



--
darkpenguin

Bug#835634: [Nut-upsuser] "Halt then reboot" script with systemd

[Dark Penguin]

I've asked on the systemd mailing lists whether it's possible with 
systemd. Maybe this thread could be helpful...


https://lists.freedesktop.org/archives/systemd-devel/2016-September/037447.html

--
darkpenguin

Bug#835634: nut: POWEROFF_WAIT option has no effect

[Dark Penguin]

Package: nut
Version: 2.7.2-4
Severity: important


The POWEROFF_WAIT option in nut.conf does not work (has no effect).

I have a suspicion that it has something to do with systemd handling 
system shutdowns nowadays, though it's too complex for me to investigate 
further and find any proof (other than /sbin/shutdown and /sbin/poweroff 
pointing to /bin/systemctl, which does not prove anything).


This bug introduces quite a regression I believe is worth fixing in 
Jessie (even if it turns out to be fixed in later versions). Also, it 
becomes especially hilarious together with #83 - nut also doesn't 
send the command to kill the power; so nut doesn't handle the case when 
your UPS supports cutting the power, AND it doesn't handle the situation 
when it does not. Seriously, did no one notice a 100% broken package 
BEFORE shipping Jessie?.. A package that manages power supply, of all 
things. Hence the "important" severity.




Details:
If the command for the UPS to kill the power is sent when AC power is 
already back, my UPS ignores it. (And it's APC, so I really didn't 
expect that kind of thing from them.) So, there is a risk to have all my 
machines require a manual restart after a power failure.

And nut has a workaround just for this case...

Actions required:
- Add "POWEROFF_WAIT=15m" line in /etc/nut/nut.conf

Intended behaviour:
- After an emergency shutdown triggerd by NUT, the system is not
powered down, only halted. After a timeout (15 minutes in this
example) it reboots, in case the UPS did not cut the power
for some reason.

Actual behaviour:
- The system is always powered off, ignoring the option added.



Minor notes:

- man nut.conf has a section about this option which directs me to 
/usr/share/doc/nut/docs/shutdown.txt.gz , which is not there anymore.


- man nut.conf does say that "if you want to specify time in seconds, 
use the 's' suffix", but it does not say which suffix should I use if I 
do NOT want to specify time in seconds. According to the example below, 
using "m" is also possible - apparently, for minutes, but I was 
wondering if "m" is already deprecated (along with shutdown.txt.gz 
mentioned above) and I should use no suffix by default... I don't want 
to do a real power failure test again just to find out.




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

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

Versions of packages nut depends on:
ii nut-client 2.7.2-4
ii nut-server 2.7.2-4

nut recommends no packages.

nut suggests no packages.

-- no debconf information


--
darkpenguin

Bug#835555: nut does not kill power after shutdown

[Dark Penguin]

Package: nut
Version: 2.7.2-4
Severity: important


After an emergency shutdown due to power loss, the command to kill the 
power is never sent to the UPS. And since all the machines are powered 
down, the load is zero, so this will continue for a pretty long time, 
during which power is very likely to return. Because of this, not only 
do the connected machines require a manual power-on, but the UPS and the 
battery may be damaged (batteries do not like discharging completely, 
and UPS-es do not like overheating due to operating at low wattages, 
according to their manuals).


I know that NUT has a workaround for this situation for UPS-es that do 
not support killing the power (POWEROFF_WAIT). However, people KNOW that 
their UPS DOES support it, so they will not have it turned on. And even 
if they do a test run (and does everyone do a completely real power 
failure test run after an upgrade to Jessie from a perfectly working 
Wheezy installation?), they may not be patient enough to wait until the 
UPS cuts the power automatically, because the timeout may be set to 
something pretty long.




My investigation revealed that the power kill command is supposed to be 
sent by /lib/systemd/system-shutdown/nutshutdown (which is really 
neither obvious nor documented, as far as I could find, but oh well):


/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown

However, /sbin/upsmon -K ALWAYS returns false, even if the flag is there 
(I've tried replacing "/sbin/upsdrvctl shutdown" with a debug command 
and it never got executed).


Changing that line to "if [ -f /etc/killpower ] ; then /sbin/upsdrvctl 
shutdown ; fi" fixes the problem for me.


I do not know why does upsmon -K not work as intended, but there are 
many possible reasons:
- it likes to complain that "the file is there, but I can't read it, so 
what if there's no magic word?! I won't do it without the magic word!"
- it likes to complain that "one UPSMON is already running" (and systemd 
seems to be particularly good at starting upsmon when it's not needed 
and not being able to stop it when you try to do that)

- maybe some other permission problems between "root" and "nut" (see:

https://bugs.launchpad.net/ubuntu/+source/nut/+bug/839490

and

http://askubuntu.com/questions/511387/nut-not-shutting-down-ups-does-14-04-server-block-usb-comms-in-runlevel-0 
)



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

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

Versions of packages nut depends on:
ii  nut-client  2.7.2-4
ii  nut-server  2.7.2-4

nut recommends no packages.

nut suggests no packages.

-- no debconf information

--
darkpenguin

Bug#834747: nginx-extras: Feature request: Add 3rd party module graphite-nginx-module.

[Thomas Ward (Dark-Net)]

Please note that there is currently a "Won't Fix" for "No New Modules
or Flavors", which may still apply here.  This is bug #790623
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790623)

--
Thomas

On Thu, Aug 18, 2016 at 10:39 AM, Roman V. Nikolaev  wrote:
> Package: nginx-extras
> Version: 1.10.1-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please add new module to nginx-extras:
> graphite-nginx-module - an nginx module for collecting location stats into 
> Graphite.
>
> Url: https://github.com/mailru/graphite-nginx-module
> License: BSD
> Depends: lua-nginx-module
>
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages nginx-extras depends on:
> ii  libc6   2.23-2
> ii  libexpat1   2.1.0-6+deb8u2
> ii  libgd3  2.2.1-1
> ii  libgeoip1   1.6.2-4
> ii  liblua5.1-0 5.1.5-7.1
> ii  libpam0g1.1.8-3.1+deb8u1+b1
> ii  libpcre32:8.35-3.3+deb8u4
> pn  libperl5.18 
> ii  libssl1.0.0 1.0.1k-3+deb8u5
> ii  libxml2 2.9.3+dfsg1-1
> ii  libxslt1.1  1.1.28-2+b2
> ii  nginx-common1.6.2-5+deb8u2
> ii  perl5.20.2-3+deb8u5
> pn  perlapi-5.18.1  
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> nginx-extras recommends no packages.
>
> Versions of packages nginx-extras suggests:
> pn  nginx-doc  
>

Bug#834164: systemd: Services are not killed after a timeout or killed immediately after ExecStop

[Dark Penguin]

Package: systemd
Version: 215-17+deb8u4
Severity: normal


I am trying to set up a service shutdown sequence in a way that the 
service is asked nicely to quit, and if it doesn't, then it's killed 
after a timeout. Sounds very simple - this is very basic.


According to man systemd.service,

TimeoutStopSec=
Configures the time to wait for stop. If a service is asked to
stop, but does not terminate in the specified time, it will be
terminated forcibly via SIGTERM, and after another timeout of equal
duration with SIGKILL (see KillMode= in systemd.kill(5)).

However, with this setup:

ExecStop=
KillMode=none
TimeoutStopSec=10s

the service is NEVER killed - even after 10s timeout.

Maybe I don't understand what's written in the manual? I just can't 
believe such a basic thing could seriously be overlooked up until now...


I've also tried the same with KillMode=process (and without KillMode at 
all - it defaults to control-group), hoping that maybe it will give my 
service some time to shut down after ExecStop=, but it killed the 
process immediately (and it went into "failed" mode for not stopping 
quickly enough). Why do we have ExecStop= at all if the service is 
killed immediately anyway?


This behaviour us the same in a newer version of systemd in Linux Mint 
18, so it's an upstream bug. (Either that, or I really don't understand 
something that simple.)


Here is a sample .service file that can be used safely to test this 
behaviour.



= = = = = = =
test.service
= = = = = = =

[Unit]
Description=Test service


[Service]
ExecStart=/usr/bin/screen -h 1024 -dmS test ftp nonExistentServer
Type=forking

ExecStop=/usr/bin/screen -p 0 -S test -X eval 'stuff \"ServiceGoDie\"\015'
# Change the command to "bye" to actually let the "service" quit
# Otherwise it is supposed to fail to quit peacefully
# and be killed after 10s after "systemctl stop test"

KillMode=none
TimeoutStopSec=10s


[Install]
WantedBy=multi-user.target

= = = = = = =


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u4
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u1+b1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u4
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u4
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u4

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

--
darkpenguin

Bug#826068: X11vnc layouts problem

[Dark Penguin]

I did some research. I totally mis-diagnosed the problem earlier; seems 
like it's a problem with key translation (or how is it called properly?).


First of all, I've confirmed that this is indeed a problem with upstream 
x11vnc. It's present in Linux Mint 18 Cinnamon, it doesn't matter which 
VNC viewer do I use (the problem persists even with x11vnc's "Java 
viewer"), and it's not present with other VNC servers. (Do I have to go 
upstream in this case? Where?)


I've read the manpage carefully and tried all kinds of keyboard-related 
options, and some of them had some effect, but I couldn't get the 
"correct" behaviour, so I"m trying to find out what the problem is by 
looking at the "x11vnc -dk" output. And I can't figure it out on my own, 
as I know very little about how keyboards work and how the keys are 
supposed to be transferred... (But I see that other VNC servers got it 
perfectly right, so it should be possible; I just really like x11vnc and 
don't want to go with the other ones!)



The problem is:
- I have two layouts on my local machine: "us" and "ru"
- Everything works fine when the only layout on the remote machine is 
"us"; my local layout is honored and all keys work properly.
- When I add the "ru" layout on the remote machine, the problems start: 
everything is fine as long as my local layout is "us", but if I switch 
it to "ru", then most keys are mangled in a way hard to describe in a 
brief way.


I believe the correct behaviour would be similar to what vino has: the 
remote layout is completely ignored, and only the local layout is honored.



The only thing that helped me partially was disabling modtweak; it only 
mangled my keys even further. So I'm looking at the debug output without 
modtweak. (And I'm omitting all the "Shift" presses and all the releases 
for uncluttered view.)



Case #1:
- "ru" is NOT added on the remote machine
- the local layout is "ru"

I press й (located on "q") - I get й :
09/08/2016 05:46:23 # keyboard(down, 0x6ca "Cyrillic_shorti") uip=0 
2058.5674
09/08/2016 05:46:23 keyboard(): KeySym 0x6ca "Cyrillic_shorti" -> 
KeyCode 0x5d
09/08/2016 05:46:23 XTestFakeKeyEvent(dpy, keycode=0x5d 
"Cyrillic_shorti", down)

09/08/2016 05:46:23 calling XTestFakeKeyEvent(93, 1)  2058.5685

I press " (located on Shift+2) - I get " :
09/08/2016 05:48:26 # keyboard(down, 0x22 "quotedbl") uip=0  2182.3190
09/08/2016 05:48:26 keyboard(): KeySym 0x22 "quotedbl" -> KeyCode 0x30
09/08/2016 05:48:26 XTestFakeKeyEvent(dpy, keycode=0x30 "apostrophe", down)
09/08/2016 05:48:26 calling XTestFakeKeyEvent(48, 1)  2182.3194

I press № (located on Shift+3) - I get № :
09/08/2016 05:50:22 # keyboard(down, 0x6b0 "numerosign") uip=0  2297.9047
09/08/2016 05:50:22 keyboard(): KeySym 0x6b0 "numerosign" -> KeyCode 0x78
09/08/2016 05:50:22 XTestFakeKeyEvent(dpy, keycode=0x78 "numerosign", down)
09/08/2016 05:50:22 calling XTestFakeKeyEvent(120, 1)  2297.9071


Case #2:
- adding "ru" to the remote machine, but not enabling it
- the local layout is "ru"

I press й (located on "q") - but for some reason I get q :
09/08/2016 05:52:17 # keyboard(down, 0x6ca "Cyrillic_shorti") uip=0 
2413.0940
09/08/2016 05:52:17 keyboard(): KeySym 0x6ca "Cyrillic_shorti" -> 
KeyCode 0x18

09/08/2016 05:52:17 XTestFakeKeyEvent(dpy, keycode=0x18 "q", down)
09/08/2016 05:52:17 calling XTestFakeKeyEvent(24, 1)  2413.0950
(Why is it being translated back into English?! Who's doing it and how 
to disable it?!)


I press " (located on Shift+2) - I get " :
09/08/2016 05:53:27 # keyboard(down, 0x22 "quotedbl") uip=0  2483.1056
09/08/2016 05:53:27 keyboard(): KeySym 0x22 "quotedbl" -> KeyCode 0x30
09/08/2016 05:53:27 XTestFakeKeyEvent(dpy, keycode=0x30 "apostrophe", down)
09/08/2016 05:53:27 calling XTestFakeKeyEvent(48, 1)  2483.1066
(Why is this NOT translated into English, then?!)

I press ; (located on Shift+3) - I get : :
09/08/2016 05:57:24 # keyboard(down, 0x3b "semicolon") uip=0  2720.3259
09/08/2016 05:57:24 keyboard(): KeySym 0x3b "semicolon" -> KeyCode 0x2f
09/08/2016 05:57:24 XTestFakeKeyEvent(dpy, keycode=0x2f "semicolon", down)
09/08/2016 05:57:24 calling XTestFakeKeyEvent(47, 1)  2720.3265
(It is a SEMI-colon in both "us" and "ru" - why does it turn into a COLON?!)


Case #3:
- the remote layout is "ru"
- the local layout is "ru"

I press й (located on "q") - I get й:
09/08/2016 06:01:12 # keyboard(down, 0x6ca "Cyrillic_shorti") uip=0 
2948.2130
09/08/2016 06:01:12 keyboard(): KeySym 0x6ca "Cyrillic_shorti" -> 
KeyCode 0x18

09/08/2016 06:01:12 XTestFakeKeyEvent(dpy, keycode=0x18 "q", down)
09/08/2016 06:01:12 calling XTestFakeKeyEvent(24, 1)  2948.2142

I press " (located on Shift+2) - I get Э (located on the ' and " key ):
09/08/2016 06:02:28 # keyboard(down, 0x22 "quotedbl") uip=0  3023.8559
09/08/2016 06:02:28 keyboard(): KeySym 0x22 "quotedbl" -> KeyCode 0x30
09/08/2016 06:02:28 XTestFakeKeyEvent(dpy, keycode=0x30 "apostrophe", down)
09/08/2016 06:02:28 calling XTestFakeKeyEvent(48, 1)  3023.8568

I 

Bug#816779: Remmina doesn't always honor scale ratio lock

[Dark Penguin]

This is one of two bugs with Remmina that really annoy me; after a 
while, I've gathered more data and now I think have the simplest way to 
reproduce the problem. Also, this time all the machines are running 
Debian Jessie with MATE.


- I connect over VNC to one machine with a 1024x768 screen. A small 
window appears in the center of my FullHD screen. (This is a good 
starting point to see all kinds of scaling problems that I have.)


- Then I connect to another machine with a FullHD screen. The window is 
still the same size, but now a FullHD screen is cramped into it (without 
honoring my "Maintain scale ratio" option, of course.)


Now if I resize the window by dragging its border, or click "Maintain 
scale ratio" twice to disable it and enable it back, then it resizes the 
image properly; but whatever else I do, the scale ration is not honored.


What I've tried:

- Being not happy, I try to "Maximize" the window. The image is now 
stretched in a thin horizontal line with black borders above and below - 
neither honoring the scale ratio, nor even scaling to fit all the screen.


- If I click "Resize the windows to fit in remote resolution", the same 
happens.


- If I click "Toggle fullscreen mode", the same happens.

- After any of those, if I toggle the "Scaling mode" off and back on, 
then it scales to cover all the window, but still does not honor the 
"Maintain scale ratio".



I've also tried this with RDP - connecting to Windows machines. The 
results are the same.


And finally, only in the case when the remote screen is SMALLER than the 
window, turning "Scaled mode" off and on helps resize the window 
properly. When the remote screen is LARGER than the window, it does not 
honor the aspect ratio.



--
darkpenguin

Bug#826068: X11vnc layouts problem

[Dark Penguin]

Package: x11vnc
Version: 0.9.13-1.2+b2
Severity: normal


When the local layout is non-English, capital letters (and also "Shift-" 
keys) come out lower-case (or "without Shift").


Example:

- I connect to a Debian Jessie machine running x11vnc over MATE (I've 
also tried x11vnc on LMDE2 with Cinnamon) using Remmina on Debian Jessie 
or TightVNC on Windows. Both local and remote layouts are english by 
default. Everything is fine at this point.


- I press Alt+Shift to change layouts. This changes both local and 
remote layouts (to Russian, in my case, but I assume it would be the 
same with any non-English layout). Now, all upper-case that I type come 
out lower-case, and if I try to type '!' , I get '1' on the other side.


- If I change the remote layout by clicking it with my mouse, but leave 
my local layout non-English, the problem persists. However, if I change 
my local layout back to English, then the problem is gone, whichever 
layout there is on the remote side.



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

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

Versions of packages x11vnc depends on:
ii  libavahi-client3  0.6.31-5
ii  libavahi-common3  0.6.31-5
ii  libc6 2.19-18+deb8u4
ii  libjpeg62-turbo   1:1.3.1-12
ii  libssl1.0.0   1.0.1k-3+deb8u5
ii  libvncclient0 0.9.9+dfsg2-6.1+deb8u1
ii  libvncserver0 0.9.9+dfsg2-6.1+deb8u1
ii  libx11-6  2:1.6.2-3
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxinerama1  2:1.1.3-1+b1
ii  libxrandr22:1.4.2-1+b1
ii  libxtst6  2:1.2.2-1+b1
ii  openssl   1.0.1k-3+deb8u5
ii  tk8.6.0+8
ii  x11vnc-data   0.9.13-1.2
ii  zlib1g1:1.2.8.dfsg-2+b1

x11vnc recommends no packages.

x11vnc suggests no packages.

-- no debconf information


--
darkpenguin

Bug#816875: Update

[Dark Penguin]

I've tried it with relatively recent versions of x11vnc and 
tightvncserver on Debian Jessie and Linux Mint. It works. Apparently, it 
doesn't work with older versions of various VNC servers on various 
operating systems... but I don't think this is something that really 
needs to be fixed.


I think we can close this bug now. Sorry for not checking it with recent 
versions of VNC servers in the beginning - I did not have an opportunity 
back then...


--
darkpenguin

Bug#820897: Update

[Dark Penguin]

I've tried it with relatively recent versions of x11vnc and 
tightvncserver on Debian Jessie and Linux Mint. It works. Apparently, it 
doesn't work with older versions of various VNC servers on various 
operating systems - upon closer inspection, it seems that the Alt key 
tends to get "stuck" if you release it before releasing Shift... but I 
don't think this is something that really needs to be fixed.


I think we can close this bug now. Sorry for not checking it with recent 
versions of VNC servers in the beginning - I did not have an opportunity 
back then...



--
darkpenguin

Bug#816874: New information

[Dark Penguin]

First of all, I mistyped about LMDE: I mean, I'm using MATE on Jessie, 
of course.


Now, I've tried to gather more data.

- Click the Remmina tray icon, then quickly (within the double-click 
timeout) click one of the items in the context menu: the item is 
activated, but the main Remmina window also pops up. (This is what's 
most annoying.)


- Move the mouse over the tray icon, hold the left mouse button, quickly 
move the mouse over to some item in the context menu, release the 
button: the item is activated, but the main Remmina window also pops up.


- Left-click the tray icon, then immediately right-click it (just for 
testing purposes): the main Remmina window pops up.


However:

- Double-right-click the tray icon: nothing happens.

- Right-click the icon, then immediately left-click it: the main window 
does not pop up.


- Click the tray icon (the context menu pops up). Now, double-click the 
icon (intending to open the main window). It does not pop up - the 
context menu disappears and then reappears again, but the main window 
does not pop up.



--
darkpenguin

Bug#820897: Remmina - buggy Alt+Shift

[Dark Penguin]

Package: remmina
Version: 1.1.1-2


I switch my keyboard layout with Alt+Shift on all my computers. I use 
Remmina on MATE on Debian Jessie to connect to other computers - an old 
version of tightvncserver on Windows XP, Vino on Debian Squeeze, and 
tightvncserver on Debian Wheezy (I'm not sure if I've also tried this 
with X11vnc on Debian Jessie - I can't confirm this at the moment). I 
believe Remmina is to blame because I don't have this problem with an 
old TightVNC viewer running on Windows XP/7.


Let's say I'm editing an OpenOffice Writer document, for example.

Expected behaviour:
- I press Alt+Shift
- Layout changes (on both local and remote computers)
- I can continue typing - the Alt key press does not get across.

Observed behaviour:
- I press Alt+Shift
- Layout changes (on both local and remote computers)
- The "File" menu is highlighted - because the Alt key press has gotten 
across to the remote computer. Now if I continue typing, I'll 
accidentally launch menu items instead, so I have to remember to press 
Alt again after every layout change.



Here is the reportbug information.


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

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

Versions of packages remmina depends on:
ii  dbus-x111.8.20-0+deb8u1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-18+deb8u3
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libssh-40.6.3-4+deb8u2
ii  libvte-2.90-9   1:0.36.3-1
ii  libx11-62:1.6.2-3
ii  remmina-common  1.1.1-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp  1.1.1-2
ii  remmina-plugin-vnc  1.1.1-2

remmina suggests no packages.

-- no debconf information


--
darkpenguin

Bug#816875: Remmina does not transfer Shift+Tab over VNC

[Dark Penguin]

Hi,

you can use reportbug for reporting a bug. Reportbug collect some very
useful informations for the maintainer.

Please run 'reportbug remmina -N 816779' to give me this infos.

And on which operating system and which VNC Server has the error
occurred?



I'm running the client on MATE on Debian Jessie. And now that I think 
about it, it may be an issue not with Remmina, but with both 
tightvncserver and x11vnc, since I can reproduce it from the Windows 
TightVNC client... Or maybe it's an issue with both Remmina and TightVNC 
client?.. This needs further investigation...



Here is the reportbug output.


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

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

Versions of packages remmina depends on:
ii  dbus-x111.8.20-0+deb8u1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-18+deb8u3
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libssh-40.6.3-4+deb8u2
ii  libvte-2.90-9   1:0.36.3-1
ii  libx11-62:1.6.2-3
ii  remmina-common  1.1.1-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp  1.1.1-2
ii  remmina-plugin-vnc  1.1.1-2

remmina suggests no packages.

-- no debconf information


--
darkpenguin

Bug#816874: Remina tray icon treats everything like a double-click

[Dark Penguin]

> Hi,
>
> you can use reportbug for reporting a bug. Reportbug collect some very
> useful informations for the maintainer.
>
> Please run 'reportbug remmina -N 816874' to give me this infos.
>
> And on which desktop environment has the error occurred?

I'm using LMDE2 on Debian Jessie.


Here is the reportbug output.


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

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

Versions of packages remmina depends on:
ii  dbus-x111.8.20-0+deb8u1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-18+deb8u3
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libssh-40.6.3-4+deb8u2
ii  libvte-2.90-9   1:0.36.3-1
ii  libx11-62:1.6.2-3
ii  remmina-common  1.1.1-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp  1.1.1-2
ii  remmina-plugin-vnc  1.1.1-2

remmina suggests no packages.

-- no debconf information


--
darkpenguin

Bug#816779: Remmina doesn't always honor scale ratio lock

[Dark Penguin]

> you can use reportbug for reporting a bug. Reportbug collect some very
> useful informations for the maintainer.
>
> Please run 'reportbug remmina -N 816779' to give me this infos.
>
> And on which operating system and which VNC Server has the error
> occurred?


Hello,

Sorry for the delay - I've been kind of on a vacation...

I didn't know exactly what information really is useful and what is only 
littering the report.


I'm trying to connect to an old tightvncserver on Windows XP and Vino on 
Debian Squeeze (but I remember having similar problems no matter where I 
connect - I've definitely tried something modern, most probably x11vnc 
on a LMDE2 LiveCD). Now I'm trying to analyze Remmina's behaviour, and 
I've made some interesting observations.


Apparently, it does re-scale the image properly if you resize the window 
by dragging its border, but sometimes it fails - you drag the window to 
the new size, and the image is neither scaled correctly nor even 
stretched to occupy the whole window - instead, it's stretched in a 
disfigured way somewhere in between. The same happens when you Maximize 
the window or un-Maximize it. Can you not reproduce this problem on your 
system, whatever it is?..


Also, you can try the following cases:

- I connect with "Scaled Mode" and "Scale Ration Lock" enabled. Instead 
of maximizing the window and scaling the image maintaining the ratio, 
the window remembers the last used size, and stretches the image without 
maintainig the ratio.
- I resize the window a little by dragging its border. The image is now 
scaled correctly.


- I disable "Scaled Mode" by clicking a button on the toolbar and enable 
it again. Now the image is stretched incorrectly again, taking my whole 
window. I drag its border again to make it scale properly again.



I'm running MATE on Debian Jessie.

Here is the reportbug output.


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

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

Versions of packages remmina depends on:
ii  dbus-x111.8.20-0+deb8u1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-18+deb8u3
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libssh-40.6.3-4+deb8u2
ii  libvte-2.90-9   1:0.36.3-1
ii  libx11-62:1.6.2-3
ii  remmina-common  1.1.1-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp  1.1.1-2
ii  remmina-plugin-vnc  1.1.1-2

remmina suggests no packages.

-- no debconf information


--
darkpenguin

Bug#816875: Remmina does not transfer Shift+Tab over VNC

[Dark Penguin]

Package: remmina
Version: 1.1.1-2

In a VNC connection, Shift+Tab combination just does not get across to 
the remote desktop. It does not have any result at all, with or without 
"Grab Keyboard" enabled.


Shift+Tab is one of the very basic shortcuts for people who mostly use 
keyboard and not mouse: open some application on the remote screen, 
enter the login, Tab, enter the password... oh, I made a typo in the 
login! Shift+Tab... Nothing happens! You have to reach for the mouse to 
click the login field again...


Shift+Tab does work correctly over RDP, though.


--
darkpenguin

Bug#816874: Remina tray icon treats everything like a double-click

[Dark Penguin]

Package: remmina
Version: 1.1.1-2

I have Remmina autostart when I log in, so the Remmina icon sits in the 
tray. Whenever I want to connect to some host, I click the tray icon and 
the I choose an item from the list of saved hosts.


Now, I only have very few hosts, so those two clicks happen in less than 
a second. And for some reason, Remmina treats it like a double-click and 
opens the main program window, even though the first click is on the 
icon, and the second click is on a menu item. And I have to close the 
main window every time, or remember to make a long pause after clicking 
the tray icon and before choosing the host to connect to.


Also, instead of two separate clicks, I usually do it the Linux way: 
click on the tray icon, hold the button down, move it to the menu item I 
want, and release the button. I find this really convenient. But even in 
this case Remmina treats it like a double-click, even though it was 
actually only one click and release!!



--
darkpenguin

Bug#787950: How about accepting this patch?

[Dark Penguin]

I think this situation is a disaster. Not having periodical checks on 
your arrays, or rather, having them fail quietly without even notifying 
the admin, can lead to grave consequences. (People tend to underestimate 
how critical it is to have periodical consistency checks, especially in 
RAID5's).


Finding this bug report is not exactly easy. I've spent a whole day 
trying to find out why do I not have consistency checks, and I could not 
advance any further than "why does checkarray not do anything". Not to 
mention it was a very lucky coincidence that I even noticed not having 
consistency checks.


So, how about accepting this patch and having checkarray use bash by 
default? I see no downsides to this; bash is an "essential" package, so 
most people do have bash installed; even if they don't, they will still 
not have critical maintenance fail silently, but get an error message. 
Even if this is fixed in more recent kernels, 4.1-LTS is one of the most 
popular ones, if not THE most popular, and it still has this problem.



But still... "One byte at a time"? Was this the reason why Linus wrote 
one of his most famous quotes about this being incredibly stupid rather 
than simply "inefficient"? %) Is there at least a bug filed against dash 
about, um, "optimizing the inefficient behaviour potentially leading to 
major problems on most widely used LTS kernels"?



--
darkpenguin

Bug#816779: Remmina doesn't always honor scale ratio lock

[Dark Penguin]

Package: remmina
Version: 1.1.1-2


Even if the "Maintain scale ratio" button is enabled, and this is saved 
in the connection, Remmina does not always honor it. This happens in 
some cases on window size change, and sometimes even right after connecting.



How to reproduce:
- Connect via VNC to a computer whose screen is larger than your screen.

Expected behaviour:
- A connection window appears that takes all available space on the 
screen. It has the remote screen in the center, scaled down with correct 
aspect ratio, and black borders around it.


Actual behaviour:
- A connection windows appears that takes all available space on the 
screen. It has the remote screen stretched to take all available space, 
with wrong aspect ratio and no black borders.
- If I click the "Lock ratio" (or whatever it's called) button two times 
in a row (disabling and re-enabling it), Remmina applies the ratio lock, 
and black borders appear.


Having to make three additional clicks right after starting each 
connection simply because Remmina forgets to apply its saved options is 
annoying.



I'm using Debian Jessie x64 with MATE and all available updates - just 
installed it few days ago, so it's almost "a clean installation", and 
the Remmina package from the repository with VNC and RDP plugins. I 
haven't tried to reproduce the bug with RDP - I don't have a suitable 
RDP server available.



--
darkpenguin

Bug#813010: caja: Shift-Del behaviour is wrong when renaming files

[Dark Penguin]

And, no, it's not only up to the developers to figure what causes the
bug. Both Mate and Debian are community-driven, so if you find a bug
you would like to get fixed as a user, you should help developers
with some testing which helps locate the issue.

The more information you provide, the faster can others fix your
problem. Remember, many people here don't get paid for fixing these
things, so they might as well say that they don't care about a bug if
it takes too much effort to debug and fix it.


Yes, I know; and I absolutely agree - when reporting a bug, I make sure 
to test everything I can think of that I would do if I was the project 
developer. Actually, I like fixing UI problems myself, and I would do it 
if I could, but I'm not yet good enough to deal with things like this...


What I meant is, "it's there in Debian, it's not there in Mint; the only 
people who can find out exactly where it all went wrong is the Debian 
people". Also, the bug report page for Debian said something like, "if 
you're unsure, don't send the report upstream; maybe it's only there in 
Debian - we'll direct it upstream if we have to".



> Could you please test caja upstream and report back? Linux Mint is
> not upstream, the MATE project is.
>
> And if it turns out that the bug is still present upstream, then
> you're barking up the wrong tree as Debian just packages most
> upstream software, we don't develop it.
>
> Also, if turns out to be an upstream bug, then you should yell at the
> Linux Mint people to fix it.

I'm extremely sorry, but it seems that I've provided some wrong 
information. I've just tested it again. The bug IS there in Linux Mint 
Debian Edition 2; however, it is NOT there in Linux Mint 17.3 . (I mixed 
up different Mint distros.) So the problem is upstream, anyway, and it's 
not with Caja - it's with something else that's different between Debian 
and Ubuntu.



--
darkpenguin

Bug#813010: caja: Shift-Del behaviour is wrong when renaming files

[Dark Penguin]

The next problem is to find the bugtracker for MATE. Unsurprisingly, 
googling "bugs mate" yield unwanted and graphic results. %)



--
darkpenguin

Bug#813010: caja: Shift-Del behaviour is wrong when renaming files

[Dark Penguin]

Package: caja
Version: 1.8.2-3+deb8u1
Severity: normal

Dear Maintainer,

When renaming files in Caja, pressing Shift+Del does not "cut the name"; 
instead, it works as if you wanted to "permanently delete" the file. 
Ctrl+X works as expected, however.


To reproduce:
- Press F2 on any file to rename it
- Press Shift+Del to cut the highlighted part of the name

Expected behaviour:
- It cuts the highlighted part of the file name.

Observed behaviour:
- Renaming stops, and a confirmation dialog appears: "Are you sure you 
want to permanently delete this file?"



This buggy behaviour is present in Caja 1.8.2 in the current Jessie, but 
not in Caja 1.8.2 in LMDE2.



--
darkpenguin

Bug#813010: caja: Shift-Del behaviour is wrong when renaming files

[Dark Penguin]

When renaming files in Caja, pressing Shift+Del does not "cut the name";
instead, it works as if you wanted to "permanently delete" the file.
Ctrl+X works as expected, however.


Meh, you people are really nitpicky. I would have expected that
Shift+Del will actually delete the file, not cut the text here.


I find Shift+Del for Cut and Shift+Ins for Paste much more convenient to 
use, and I use those shortcuts all the time. When that does not work as 
expected, it is very uncomfortable...


But yes, I'm as nitpicky as one can get about "user interface should be 
as polished and comfortable as possible", because it directly influences 
the user's experience. I think it is very important. But usually people 
are too lazy to file bugs about such minor things, which is why we have 
a lot of amazing software with UI so buggy that no wonder people prefer 
proprietary software sometimes... =/



> I think it's arguable whether this is a bug or not. But in any case,

When I am in the process of editing a file name, the "text edition 
shortcut" should obviously be a priority - it should cut selected text. 
Why would I even want to rename a file before Shift-Deleting it?!.. Even 
if I did, I'd just press Escape to cancel or Enter to confirm, and then 
delete the file.




this is up to the MATE upstream developers what the expected behavior
of Shift+Del is in this case.

In fact, you should not test any other Linux distribution, but download
caja in source from the upstream website, compile it yourself and test
how the vanilla version behaves.

If the upstream version behaves as the Debian package, it's an upstream
bug. If not, they probably changed behavior upstream and caja just
needs to be updated in Debian. I highly doubt that someone intentionally
changed this behavior in Debian.


I believe Linux Mint is as vanilla as it gets with MATE. And their 
version works correctly, so they think this behaviour is not expected.


It may be that Mint "fixed" this already, but I think it's been more 
than a year already - why is it still not in Debian?! So I think it's a 
problem with something other than Caja itself - some Debian-specific 
hotkey-snatching subsystems or something. Maybe this problem was never 
even there in Mint. Either way, it's up to the developers to find out 
why is there a problem with Debian, but not with Mint.



--
darkpenguin

Bug#766957:

[Thomas Ward (Dark-Net)]

I can maybe take a stab at backporting to 0.206, as it's on my radar
to do anyways.

Note this though: I don't think we should outright disable SSLv3 in a
stable release.  There is a code commit in the pull requests queue
waiting for inclusion that allows the specification of SSLv3 being
disabled - this in turn would allow 0.206 users to disable SSLv3 if
they wish and not change a default that would maybe cause undesired
confusion and results.  Downstream in Ubuntu, the Security Team will
not include the SSLv3-disabled-always changes, but may consider the
pending Configure disabling of protocols commits.

--
Thomas


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

Bug#767456: disable SSLv3 by default

[Thomas Ward (Dark-Net)]

Okay, so after poking #debian-security on OFTC, Thijs said the
following:  (Or at least I believe it's Thijs):

[2014/11/01 11:25:15] thijs_ teward: I think the ideal package does
not have SSLv3 included in its default settings. With Apache in Debian
is quite the case because /etc/apache2/conf-available/ssl.conf will
disable SSLv3 so any vhost using SSL without explicitly overriding the
SSLProtocols will not have it
[2014/11/01 11:26:28] thijs_ that nginx disables it in a
configuration example is good, but I would think it's much better if
someone creates a vhost without explicit protocol specification, it
would not do SSLv3

To that end, I went fussing around with the code of the SSL module.
Attached is a patch which should do the trick, and disable SSLv3
support if ssl_protocols is NOT defined.

Before this patch is included, though, we should really consider
whether we actually *want* to disable SSLv3 by default and potentially
break nginx configurations which need SSLv3 and don't have
ssl_protocols defined.  At the very least, a NEWS entry needs to be
added for this.  If this change is accepted, I'll make a blog post
about it, but only if it's included.

--
Thomas


disable_sslv3_default_protocol.patch
Description: Binary data

Bug#767456: disable SSLv3 by default

[Thomas Ward (Dark-Net)]

fixed 1.6.2-3
thanks

Confirmed: This was done already.  The commit this was done in was
this one: 
http://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=9a4e0f0a698bee2b03b7f417ad9286e5eb22141e

1.6.2-3, which had this fix already, was uploaded and accepted to
Unstable on 2014-10-16, according to the package tracker
(https://packages.qa.debian.org/n/nginx.html)  This is confirmed in
the 1.6.2-4 changelog in Unstable
(http://metadata.ftp-master.debian.org/changelogs/main/n/nginx/unstable_changelog).

Dissection of the package 1.6.2-4 also shows that the default SSL
stanza has an ssl_protocols line of `ssl_protocols TLSv1 TLSv1.1
TLSv1.2`.  Coupled with the OpenSSL updates made by the Debian
security team to support TLS_FALLBACK_SCSV to prevent the protocol
downgrade attack from TLSv1 to SSLv3, POODLE is effectively mitigated
with the now-default config stanzas for SSL.  (This assumes also that
a user is using the default SSL config sections.  A large portion of
(albeit newer) users do use the default config stanzas, or at least
use it as a base, and it can be argued that competent administrators
will already disable the vulnerable protocols in their own site
configs separately.)

--
Thomas Ward

On Fri, Oct 31, 2014 at 7:28 AM, Thomas Ward tew...@dark-net.net wrote:
 I thought this was already done?  I checked the packaging myself and this 
 change was already in there, or at least in git.  (the default ssl stanza in 
 the config has SSLv3 dropped from the ciphers list in the git tree for the 
 Debian package already, I checked the commit logs myself)


 --
 Thomas


 On Oct 31, 2014, at 03:37, Thijs Kinkhorst th...@debian.org wrote:

 Package: nginx
 Version: 1.6.2-2
 Severity: important

 Hi,

 Please disable the legacy SSLv3 protocol by default for installations of
 nginx. It doesn't need to be disabled completely per se, but should not
 be available on a default installation.

 This helps to defend against the recent POODLE attack (CVE-2014-3566).

 Thanks,
 Thijs



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

Bug#762494: Please update the Lua module to upstream git master

[Thomas Ward (Dark-Net)]

Apparently upstream has posted a new tagged version of the Lua module,
v0.9.13rc1.

Can we update the package to include this tagged revision, to address this bug?

(Also note: bug retitled)


--
Thomas


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

Bug#764527: Package Tracker URL Problem Resolution and Request to Look Into Updating the Package

[Thomas Ward (Dark-Net)]

Source: libpff
Severity: wishlist

Hello.

Firstly, it should be made known that packages.qa.debian.org is
showing that there is a problem with the URLs for this package.
According to what I could find, the libpff project moved away from
sourceforge.  It looks like it was located on Google Code for a while,
but has since moved to GitHub at https://github.com/libyal/libpff
(this assumption is based on the owner of the libyal group on GitHub
being the same person who filed the ticket at SourceForge requesting
project removal - http://sourceforge.net/p/forge/site-support/3913/
and is also based on Google searches for the libpff project.)

Secondly, the version currently provided by Debian appears to be
several years old.  Downstream in Ubuntu and elsewhere, it looks like
users are trying to use these tools but are forced to compile the
software to get the newer software.  While this is typically not an
issue for power users, for the less technically inclined with the
coding and compile-from-scratch side of OSS it is a disadvantage.  To
that end, it may be prudent to investigate whether the software can be
updated in Debian.


--
Thomas


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

Bug#762494: Please update the Lua module to upstream git master

[Thomas Ward (Dark-Net)]

Source: nginx
Severity: wishlist

Hello.

I would like to request that the Lua module be updated to the version in
its latest git master branch.  I am requesting this early, ahead of future
upstream versions of nginx uploaded to Debian.

This request is based on the Mainline branch, which I package in the
downstream Ubuntu PPAs, and directly base its debian/ folder off of Debian
Unstable.  The latest mainline branch, 1.7.5 changes the API and causes the
Lua module to fail to build in its current form.  While this API change
does not change here, there is added into the module an `if` block which
determines which code to use based on the version of NGINX it's being built
with.

As this is related to a future hypothetical fail to build error, I would
like the module to be updated to include the fix ahead of future API
changes in the nginx versions.


--
Thomas

Bug#587657: locally installed plugins aren't loaded

[Dark LiSNAz]

On Thu, Jul 1, 2010 at 3:57 AM, Niels Thykier wrote:
 With the upgrade from 3.5.2-3 to 3.5.2-4 all locally installed plugins
 aren't loaded anymore, while they appear in the Installed Software
 tab. Neither uninstall/install of the plugins nor an clean ~.eclipse/
 and ~/workspace folder solves the problem.

 ~/workspace/.metadata/.log is empty.

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


 Can you please provide the contents of [1] from your original ~/.eclipse
 (if you still have it) and the one generated when start eclipse with a
 clean ~/.eclipse.

 [1]

.eclipse/org.eclipse.platform_*/configuration/org.eclipse.equinox.simpleconfigur
 ator/bundles.info

Same problem encountered, and I just solved my problem temporarly.
As pointed out by Niels, I made a quick diff of these two .info file and it
turned out to be the problem of org.eclipse.equinox.concurrent. Previously,
this package's location was at:

`org.eclipse.equinox.concurrent,1.0.1.R35x_v20100209,../../../home/lisnaz/.eclipse/org.eclipse.platform_3.5.0_155965261/plugins/org.eclipse.equinox.concurrent_1.0.1.R35x_v20100209.jar,4,false'

a jar under local plugin directory, I don't know why it went there but it
must be there for reason. After modifed the path to the newly generated
.info's
location:

`org.eclipse.equinox.concurrent,1.0.1.R35x_v20100209,plugins/org.eclipse.equinox.concurrent_1.0.1.R35x_v20100209.jar,4,false'

then every plugin works fine.

This solves my problem, but it may also means something to Hannes's
problem.

--
Best regards!
Vincent Gu  lis...@gmail.com
NE RD

Bug#544515: MD Listing in the United States

[dark Childress]

Many of these lists are on sale too. Just email me here:  
jillian.gr...@marketlistgurus.at

  




By emailing disapp...@marketlistgurus.at you will have your email taken off



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