Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems
In my image builder, I just mount a tmpfs over /sys/firmware to hide it: https://github.com/Daniel-Abrecht/dpa-image-builder/blob/22a18b8108d07ef72595f5217fd196cd01ddb71f/script/chns#L100 An Image builder shouldn't mess with the hosts firmware anyway.
Bug#1010806: apt: Avoid color output on monochrome terminals
Am 2022-05-16 18:29, schrieb Adam Borowski: On Tue, May 10, 2022 at 07:34:25PM +0200, Axel Scheepers wrote: The terminfo entries stopped being maintained by late 80's. This doesn't seam to be true. The terminfo files seam to mostly come from ncurses-term, the ncurses package seams still to be maintained and getting updates (https://tracker.debian.org/pkg/ncurses). Looking at the upstream release notes, which state that they are form October 21, 2021, quiet a few new ones have been added: https://invisible-island.net/ncurses/announce.html#h3-database Therefore, it seams terminfo entries are still being maintained to this day. And even if they were, every new terminal would need to wait several years before it can have its definition known by operating systems (today, distributions). It's not like new kinds of real terminals are produced anymore, at least I don't know of any. In case of terminal emulators, they have to be packaged anyway, so a the terminfo file can be added to the appropriate package at the same time. The effect? Most terminals identify as "xterm", "xterm-256color", or "rxvt". For example both libvt (Gnome-Terminal, etc) and Konsole claim to be an xterm... There are terminals who choose to be compatible to xterm. It probably has more to do with programs wrongly hardcoding escape sequences than anything else, and there is nothing wrong with making an xterm-compatible terminal. However, that doesn't change the fact that other terminals exist as well. In addition to this, if terminals implement special new escape sequences (think about recent things like sixel for example), there is no way around an appropriate terminfo to make known that it's supported. And even if $TERM->terminfo were usable, a serial console has no way to pass env vars. As an install/rescue tool, apt gets run over a serial console pretty often. It works automatically for terminal emulators. Tools like getty can set the TERM variable. Yes, only the operator knows what is connected to a serial console. In cases where it is not known, personally, I think a dumb terminal should be assumed to maximize compatibility. But I guess in most cases, something like vt100 or xterm will often work, so I don't mind it too much. People who really need to can still override it. It's not automagic, but it works. Thus, using terminfo is definitely not a "Right Thing" this millenium. Most new programs just hardcode the codes, assuming a vt100-like terminal with a common set of capabilities. I'm happy to report, that aside from apt, I'm not using any of those programs. Yes, there are lazy modern programmers insisting on doing it wrong. Those programs will simply fail on various terminals. Let's not promote that, it won't right it. Setting TERM works, it works well, and it solves the problem in the best way possible. Just because it can't always do it automatically, doesn't mean we should give up and leave things unfixably broken. terminfo is the right thing. It is the only way to deal with these terminals. This will never change. Regards, Daniel Abrecht
Bug#1010806: apt: Avoid color output on monochrome terminals
Hi I'm not really involved with apt development, but I've strong opinions when it comes to terminal applications. The value of $TERM refers to a terminfo / termcap definition / file. If a terminal supports color, and which escape sequences they need for them, is specified inside those files. The name of the files (and thus the value of the $TERM variable), does not necessarily have to contain "color" if the terminfo / termcap definition specify the capabilities for color, and vice versa. Additionally, not all terminals may use the same escape sequence for colors either. I think the root cause of the problem is escape sequences being hardcoded in apt, that simply should never be done. An application should always make use of the terminfo database when outputting any escape sequence. This will also make it trivial not to output escape sequences on dumb terminals, since there'll simply be no cap / escape sequence in the terminfo definition to output in that case. For colors, this may be helpful: https://stackoverflow.com/questions/42734416/how-to-set-colors-in-terminal-using-terminfo It seams there are a few places with hard coded escape sequences, but it's not too bad yet: https://salsa.debian.org/search?search=033_id=2051_id=228=_code=true=false_ref=main_source=navbar Regards, Daniel Abrecht
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse trackingo
On 26/04/2019 14.30, Bill Allombert wrote: > On Thu, Apr 04, 2019 at 06:52:04PM +0000, Daniel Abrecht wrote: >> On 22/03/2019 21.33, Bill Allombert wrote: >>>> I'm not sure what the best course of action is. Some possibilities are: >>>> * If it isn't too much of a problem, we could just leave it how it is. >>>> * We could disable selections while mouse tracking is active >>> >>> If this can be done on a per tty basis, this might be the best course of >>> action. >> >> Ok, I've now created patch for this. This time, I've based the patch on >> the current master branch (commit >> c12a8c2d0cf72a340b13b00e6d4b98bfed57ce01) of the salsa.debian.org git repo. > > This version seems to work much better when reporting. > Thanks! I'm glad to hear that. If there is anything left you want me to change, I'm always happy to help. Regards, Daniel Abrecht signature.asc Description: OpenPGP digital signature
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse trackingo
On 22/03/2019 21.33, Bill Allombert wrote:
>> I'm not sure what the best course of action is. Some possibilities are:
>> * If it isn't too much of a problem, we could just leave it how it is.
>> * We could disable selections while mouse tracking is active
>
> If this can be done on a per tty basis, this might be the best course of
> action.
Ok, I've now created patch for this. This time, I've based the patch on
the current master branch (commit
c12a8c2d0cf72a340b13b00e6d4b98bfed57ce01) of the salsa.debian.org git repo.
Regards,
Daniel Abrecht
diff --git a/src/action.c b/src/action.c
index 5c47fda..58d8af0 100644
--- a/src/action.c
+++ b/src/action.c
@@ -19,6 +19,7 @@
static double xx=1, yy=1, x0=-1, y0=-1, x1=-1, y1=-1;
static int mode = 0;
+static enum current_button button = BUTTON_RELEASED;
void
set_pointer(double x, double y)
@@ -26,6 +27,11 @@ set_pointer(double x, double y)
xx = x+1; yy = y+1;
if (xx < 1) xx = 1; else if (xx > screen_width) xx = screen_width;
if (yy < 1) yy = 1; else if (yy > screen_height) yy = screen_height;
+ if (mouse_reporting != MOUSE_REPORTING_OFF)
+ {
+x0 = -1; y0 = -1;
+mode = 0;
+ }
if (x0 >= 0 && y0 >= 0)
select_region((int)xx,(int)yy,(int)x0,(int)y0);
else
@@ -55,6 +61,11 @@ move_pointer(double x, double y)
xx += x/20; yy += y/20;
if (xx < 1) xx = 1; else if (xx > screen_width) xx = screen_width;
if (yy < 1) yy = 1; else if (yy > screen_height) yy = screen_height;
+ if (mouse_reporting != MOUSE_REPORTING_OFF)
+ {
+x0 = -1; y0 = -1;
+mode = 0;
+ }
if (x0 >= 0 && y0 >= 0)
select_mode(mode,(int)xx,(int)yy,(int)x0,(int)y0);
else
@@ -64,36 +75,85 @@ move_pointer(double x, double y)
void
press_left_button(void)
{
- if ((int)x1==(int)xx && (int)y1==(int)yy)
+ if (mouse_reporting != MOUSE_REPORTING_OFF)
{
-mode = (mode+1)%3;
-select_mode(mode,(int)xx,(int)yy,(int)xx,(int)yy);
+button = BUTTON_LEFT;
+report_pointer((int)xx,(int)yy,button);
}
else
{
-mode = 0;
-select_region((int)xx,(int)yy,(int)xx,(int)yy);
+if ((int)x1==(int)xx && (int)y1==(int)yy)
+{
+ mode = (mode+1)%3;
+ select_mode(mode,(int)xx,(int)yy,(int)xx,(int)yy);
+}
+else
+{
+ mode = 0;
+ select_region((int)xx,(int)yy,(int)xx,(int)yy);
+}
+x0=xx; y0=yy; x1=x0; y1=y0;
}
- x0=xx; y0=yy; x1=x0; y1=y0;
}
void
release_left_button(void)
{
+ if (mouse_reporting == MOUSE_REPORTING_X11)
+ {
+button = BUTTON_RELEASED;
+report_pointer((int)xx,(int)yy,button);
+ }
x0=-1; y0=-1;
}
void
press_middle_button(void)
{
- paste();
+ if (mouse_reporting != MOUSE_REPORTING_OFF)
+ {
+button = BUTTON_MIDDLE;
+report_pointer((int)xx,(int)yy,button);
+ }
+ else
+ {
+paste();
+ }
+}
+
+void
+release_middle_button(void)
+{
+ if (mouse_reporting == MOUSE_REPORTING_X11)
+ {
+button = BUTTON_RELEASED;
+report_pointer((int)xx,(int)yy,button);
+ }
}
void
press_right_button(void)
{
- if (x1>=0 && y1>=0)
-select_region((int)xx,(int)yy,(int)x1,(int)y1);
+ if (mouse_reporting != MOUSE_REPORTING_OFF)
+ {
+button = BUTTON_RIGHT;
+report_pointer((int)xx,(int)yy,button);
+ }
+ else
+ {
+if (x1>=0 && y1>=0)
+ select_region((int)xx,(int)yy,(int)x1,(int)y1);
+ }
+}
+
+void
+release_right_button(void)
+{
+ if (mouse_reporting == MOUSE_REPORTING_X11)
+ {
+button = BUTTON_RELEASED;
+report_pointer((int)xx,(int)yy,button);
+ }
}
void
diff --git a/src/consolation.h b/src/consolation.h
index f907906..5290d65 100644
--- a/src/consolation.h
+++ b/src/consolation.h
@@ -19,14 +19,30 @@
extern int nodaemon;
+enum current_button {
+ BUTTON_LEFT,
+ BUTTON_MIDDLE,
+ BUTTON_RIGHT,
+ BUTTON_RELEASED
+};
+
+enum mouse_reporting_mode {
+ MOUSE_REPORTING_OFF,
+ MOUSE_REPORTING_X10,
+ MOUSE_REPORTING_X11,
+ MOUSE_REPORTING_MODE_COUNT
+};
+
/* global state */
extern unsigned int screen_width;
extern unsigned int screen_height;
+extern enum mouse_reporting_mode mouse_reporting;
/* selection.c */
-void set_screen_size(void);
+void set_screen_size_and_mouse_reporting(void);
+void report_pointer(int x, int y, enum current_button button);
void draw_pointer(int x, int y);
void select_region(int x, int y, int x2, int y2);
void select_words(int x, int y, int x2, int y2);
@@ -42,7 +58,9 @@ void move_pointer(double x, double y);
void press_left_button(void);
void release_left_button(void);
void press_middle_button(void);
+void release_middle_button(void);
void press_right_button(void);
+void release_right_button(void);
void vertical_axis(double v);
/* input.c */
diff --git a/src/input.c b/src/input.c
index 74ec072..4a6f99a 100644
--- a/src/input.c
+++ b/src/input.c
@@ -46,6 +46,7 @@
int nodaemon = false;
unsigned int screen_width;
unsigned int screen_height;
+en
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
On 10/03/2019 23.02, Bill Allombert wrote:
> Could you write a simple test program ?
> The problem with vttest is that it does not inhibit the normal copy
> paste mechanism. So while it correctly detects the button press, the
> result seems useless (try press- move-releas).
> This might explain why gpm use another solution.
I don't think this is the reason. When I try to select something in a
curses application which uses mouse tracking, gpm doesn't select what I
want it to, but it does copy what I select. GPM also seams to disables
pasting in that case. Other graphical terminal emulators seam to disable
selecting, copying and pasting while an application uses mouse tracking.
The linux console (fbcon) also clears any selection if anything is
written to the tty, even if the screen content doesn't change because of
it. I don't know if the curses library would do that automatically, but
some curses applications may do that. For some reason, a button release
mouse event also seams to clear the selection. In any case, unless how
the linux console handles selections in such situations is changed,
there is no way to use mouse reporting and text selection
simultaneously, regardless of how the mouse reporting is archived.
I'm not sure what the best course of action is. Some possibilities are:
* If it isn't too much of a problem, we could just leave it how it is.
* We could disable selections while mouse tracking is active
* I could add an option to consolation which allows the user to enable
this feature, in addition to one of the above options
I've attached 2 test programs, one uses curses, the other one doesn't
need any libraries.
I've also attached a patch to reorder the button constants.
Regards,
Daniel Abrecht
diff --git a/src/consolation.h b/src/consolation.h
index c8278e0..ee9fd4e 100644
--- a/src/consolation.h
+++ b/src/consolation.h
@@ -20,10 +20,10 @@
extern int nodaemon;
enum current_button {
- BUTTON_RELEASED,
BUTTON_LEFT,
BUTTON_MIDDLE,
- BUTTON_RIGHT
+ BUTTON_RIGHT,
+ BUTTON_RELEASED
};
/* global state */
diff --git a/src/selection.c b/src/selection.c
index 4f65863..0d4c1e9 100644
--- a/src/selection.c
+++ b/src/selection.c
@@ -78,7 +78,7 @@ linux_selection(int xs, int ys, int xe, int ye, int sel_mode)
void
report_pointer(int x, int y, enum current_button button)
{
- linux_selection(x, y, x, y, TIOCL_SELMOUSEREPORT + ((button+3) % 4) );
+ linux_selection(x, y, x, y, TIOCL_SELMOUSEREPORT + button );
}
void
#include
#include
bool mousereporting = true;
bool show_release = true;
bool show_press = true;
unsigned long i = 0;
void printinfo(void){
clear();
move(0,0);
addstr("q) quit");
move(1,0);
addstr(mousereporting?".) mouse reporting: on":".) mouse reporting: off");
move(2,0);
addstr(show_release?",) show button release: on":",) show button release: off");
move(3,0);
addstr(show_press?"-) show button presses: on":"-) show button presses: off");
move(5,0);
addch('>');
addch(' ');
if(mousereporting){
mousemask( BUTTON1_PRESSED | BUTTON1_RELEASED
| BUTTON2_PRESSED | BUTTON2_RELEASED
| BUTTON3_PRESSED | BUTTON3_RELEASED, 0);
}else{
mousemask(0,0);
}
mouseinterval(0);
}
int main(){
if(!initscr()){
fprintf(stderr,"initscr failed\n");
return 1;
}
clear();
noecho();
cbreak();
keypad(stdscr, true);
printinfo();
bool running = true;
while(running){
int ch = getch();
switch(ch){
case 'q': running = false; break;
case '.': {
mousereporting = !mousereporting;
printinfo();
} break;
case ',': {
show_release = !show_release;
printinfo();
} break;
case '-': {
show_press = !show_press;
printinfo();
} break;
case '\n': {
i = 0;
move(5,0);
clrtoeol();
addch('>');
addch(' ');
} break;
default: {
if(ch > 0xFF || ch <= 0)
break;
move(5,i+++2);
addch(ch);
} break;
case KEY_MOUSE: {
MEVENT event;
if(getmouse() != OK)
break;
if(show_release)
if( event.bstate & (BUTTON1_RELEASED | BUTTON2_RELEASED | BUTTON3_RELEASED) ){
move(event.y, event.x);
addch('*');
}
int button = 0;
if( event.bstate & BUTTON1_PRESSED )
button = 1;
if( event.bstate & BUTTON2_PRESSED )
button = 2;
if( event.bstate & BUTTON3_PRESSED )
button = 3;
if(button && show_press){
move(event.y, event.x);
addch('0'+button);
}
} break;
}
}
endwin();
return 0;
}
#include
#include
#include
#include
bool mousereporting = true;
bool show_release = true;
bool show_press = true;
unsigned long j = 0;
void altscr(void){
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
Hello Bill On 10/03/2019 16.41, Bill Allombert wrote: > Do you know where in the GPM code this ioctl is used ? I'm not sure how gpm does it, but console application which use ncurses, such as dialog for example, do detect mouse clicks from it. vttest doesn't show them though, so it currently does it in another way. It has a patch for it though: https://sources.debian.org/src/gpm/1.20.4-6.2/patches/todo/xterm-mouse-for-console.patch/ > Do you have an example of program where this feature will be useful? I currently only know about dialog. But I'm working on a console keyboard which will need that functionality. I intend to use it on my librem 5 smartphone. It isn't finished yet though. Here are the sources of the different components of it and a video: https://github.com/Daniel-Abrecht/console-keyboard-multiplexer https://github.com/Daniel-Abrecht/console-keyboard-basic https://github.com/Daniel-Abrecht/libttymultiplex https://dpa.li/console-keyboard-multiplexer-demo.mp4 Regarding the other things you mentioned which could be improved, I'll create a new patch this week. Regards, Daniel Abrecht signature.asc Description: OpenPGP digital signature
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
On 24/02/2019 20.27, Bill Allombert wrote:
>> void
>> +report_pointer(int x, int y, enum current_button button)
>> +{
>> + linux_selection(x, y, x, y, TIOCL_SELMOUSEREPORT + ((button+3) % 4) );
>> +}
>> +
>
> Hello Daniel,
>
> Thanks for your patch, it looks great! Could you explain me how this
> syscall work and where it is documented ?
>
> All I have is console_ioctl(4):
>
>TIOCLINUX, subcode=7
> argp points to a char which is set to the value of the kernel
> variable report_mouse. (Since Linux 1.1.33.)
>
There is no documentation explicitly mentioning TIOCL_SELMOUSEREPORT in
sel_mode for TIOCLINUX, subcode=2 (TIOCL_SETSEL), but console_codes(4)
describes how it works in section "Mouse tracking" to some extent:
> The mouse tracking facility is intended to return xterm(1)-compatible
> mouse status reports. Because the console driver has no way to know
> the device or type of the mouse, these reports are returned in
> the console input stream only when the virtual terminal driver
> receives a mouse update ioctl. These ioctls must be generated by a
> mouse-aware user-mode application such as the gpm(8) daemon.
> ...
I've looked at the kernel code, and this seams to be the only way the
mouse position can be reported by the kernel. Another thing not
mentioned by the docs is, that the kernel only reports the mouse
position if report_mouse was enabled.
console_codes(4) also describes the possible values of report_mouse:
> ESC [ ? 9 h
> X10 Mouse Reporting (default off): Set reporting mode to 1 (or reset
> to 0)—see below.
> ESC [ ? 1000 h
> X11 Mouse Reporting (default off): Set reporting mode to 2 (or reset
> to 0)—see below.
I guess in X10 compatibility mode, sending the mouse releases isn't
completely correct, but it shouldn't really matter, if any application
still uses that, it'll probably just ignore it. I could add a check for
it if you want.
The reason I have set BUTTON_RELEASED=0 in my current_button enum and
not to 3 is mainly just a habit, I like to be able to initialize things
with all 0 and have them in some sort of neutral or default state.
signature.asc
Description: OpenPGP digital signature
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
Package: consolation
Version: 0.0.6-2
Severity: wishlist
Tags: patch
Some programs support mouse tracking to allow users to click on things
inside the terminal. For example, it is possible to click on options in
`dialog`. gpm did support this, but had issues with touch screens. It
would be great if `consolation` could add support for this. I've
attached a patch for adding that functionality.
A good way to test this is using `vttest`. Just select the following in
`vttest`:
`11. Test non-VT100 (e.g., VT220, XTERM) terminals`
`8. Test XTERM special features`
`5. Mouse features`
`4. Normal Mouse Tracking`
After that, you can click anywhere in the terminal. It should display
the button number at the location in the terminal a click occurred, and
a star where the mouse button has been released.
diff -Nru consolation-0.0.6/debian/changelog consolation-0.0.7/debian/changelog
--- consolation-0.0.6/debian/changelog 2018-01-27 21:26:05.0 +
+++ consolation-0.0.7/debian/changelog 2019-02-24 15:10:24.0 +
@@ -1,3 +1,10 @@
+consolation (0.0.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Report mouse position to console programs
+
+ -- Daniel Patrick Abrecht Sun, 24 Feb 2019 15:10:24
+
+
consolation (0.0.6-2) unstable; urgency=medium
* New upstream release
diff -Nru consolation-0.0.6/src/action.c consolation-0.0.7/src/action.c
--- consolation-0.0.6/src/action.c 2017-06-18 16:54:17.0 +
+++ consolation-0.0.7/src/action.c 2019-02-24 17:44:31.0 +
@@ -19,6 +19,7 @@
static double xx=1, yy=1, x0=-1, y0=-1, x1=-1, y1=-1;
static int mode = 0;
+static enum current_button button = BUTTON_RELEASED;
void
set_pointer(double x, double y)
@@ -64,6 +65,8 @@
void
press_left_button(void)
{
+ button = BUTTON_LEFT;
+ report_pointer((int)xx,(int)yy,button);
if ((int)x1==(int)xx && (int)y1==(int)yy)
{
mode = (mode+1)%3;
@@ -80,6 +83,8 @@
void
release_left_button(void)
{
+ button = BUTTON_RELEASED;
+ report_pointer((int)xx,(int)yy,button);
x0=-1; y0=-1;
}
@@ -92,11 +97,20 @@
void
press_right_button(void)
{
+ button = BUTTON_RIGHT;
+ report_pointer((int)xx,(int)yy,button);
if (x1>=0 && y1>=0)
select_region((int)xx,(int)yy,(int)x1,(int)y1);
}
void
+release_right_button(void)
+{
+ button = BUTTON_RELEASED;
+ report_pointer((int)xx,(int)yy,button);
+}
+
+void
vertical_axis(double v)
{
if (v)
diff -Nru consolation-0.0.6/src/consolation.h
consolation-0.0.7/src/consolation.h
--- consolation-0.0.6/src/consolation.h 2018-01-06 21:06:00.0 +
+++ consolation-0.0.7/src/consolation.h 2019-02-24 17:44:33.0 +
@@ -19,6 +19,13 @@
extern int nodaemon;
+enum current_button {
+ BUTTON_RELEASED,
+ BUTTON_LEFT,
+ BUTTON_MIDDLE,
+ BUTTON_RIGHT
+};
+
/* global state */
extern unsigned int screen_width;
@@ -27,6 +34,7 @@
/* selection.c */
void set_screen_size(void);
+void report_pointer(int x, int y, enum current_button button);
void draw_pointer(int x, int y);
void select_region(int x, int y, int x2, int y2);
void select_words(int x, int y, int x2, int y2);
@@ -43,6 +51,7 @@
void release_left_button(void);
void press_middle_button(void);
void press_right_button(void);
+void release_right_button(void);
void vertical_axis(double v);
/* input.c */
diff -Nru consolation-0.0.6/src/input.c consolation-0.0.7/src/input.c
--- consolation-0.0.6/src/input.c 2018-01-26 17:50:05.0 +
+++ consolation-0.0.7/src/input.c 2019-02-24 17:44:31.0 +
@@ -96,6 +96,8 @@
case BTN_RIGHT:
if (state==LIBINPUT_BUTTON_STATE_PRESSED)
press_right_button();
+else
+ release_right_button();
break;
}
}
diff -Nru consolation-0.0.6/src/selection.c consolation-0.0.7/src/selection.c
--- consolation-0.0.6/src/selection.c 2017-06-18 16:54:17.0 +
+++ consolation-0.0.7/src/selection.c 2019-02-24 17:44:31.0 +
@@ -67,6 +67,12 @@
}
void
+report_pointer(int x, int y, enum current_button button)
+{
+ linux_selection(x, y, x, y, TIOCL_SELMOUSEREPORT + ((button+3) % 4) );
+}
+
+void
draw_pointer(int x, int y)
{
linux_selection(x, y, x, y, TIOCL_SELPOINTER);
signature.asc
Description: OpenPGP digital signature
Bug#769494: Please mount cgroup automatically
Hello, I don't think mounting cgroup is sysvinits job. Mounting cgroups can be done using /etc/fstab and/or using the cgroupfs-mount package. I don't mind it being always added though. Also, I think this issue has already been solved. liblxc1, which is a dependency of lxc, has a dependency for "cgroupfs-mount or systemd", which means on non-systemd systems, when installing lxc or anything else which uses liblxc1, cgroupfs-mount will get installed, which will automatically mount the cgroups. I don't use lxc anymore, but I used to have it working in jessie without systemd back when I was still using it. I am using libvirt-lxc (which has been merged into libvirt-daemon) without systemd or lxc, though. I haven't seen a similar dependency on libvirt-daemon yet. libvirt-daemon can be used for other things than lxc containers, in which case cgroups don't seam to be required. I recommend adding a recommends to the libvirt-daemon package for "cgroupfs-mount or systemd" to account for all use cases. To summarize, I'm for closing this bug and just adding a "cgroupfs-mount or systemd" dependency or recommends to packages which need or benefit from it respectively, similar to how it is done with liblxc1. For this, a new bug could be opened for each affected packet. This is my first mail to the debian bug tracker, I hope I was able to help and to give some new helpful perspectives on this matter. Regards, Daniel Abrecht
