Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 3:34 AM, Greg KH wrote: > Can this mean I can drop the usb.ids file from the usbutils package? I > can't remember where hwdb is generated from, does it rely on the usb.ids > file for the initial creation? hwdb does not use the usb.ids from the usbutils package. However, hwdb only contains vendor, product, class, subclass and protocol. So if you drop usb.ids the rest of the information will be lost. Maybe split the rest out into a separate file and ship only that? Or is there a way to get this info into hwdb? Kay? Also, I just realise there is also lsusb,py, which I did not port. What is the usecase for this? Is it also worth porting over? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 12:01 PM, Tom Gundersen wrote: > On Sun, Jul 21, 2013 at 3:34 AM, Greg KH wrote: >> Can this mean I can drop the usb.ids file from the usbutils package? I >> can't remember where hwdb is generated from, does it rely on the usb.ids >> file for the initial creation? > > hwdb does not use the usb.ids from the usbutils package. We download the usb.ids file from: http://www.linux-usb.org/usb.ids and convert them into *.hwdb files, which end up in the binary hwdb udev is using. Shipping a copy of it in the usbutils package makes probably no sense even today before using the hwdb data from udev. Almost all distros ship the downloaded file, which is regularly updated and ignore the one from usbutils. > However, hwdb only contains vendor, product, class, subclass and > protocol. So if you drop usb.ids the rest of the information will be > lost. > > Maybe split the rest out into a separate file and ship only that? > > Or is there a way to get this info into hwdb? Kay? It should work to add some of that data to the existing modalias, right? For some things we probably need to "invent" new synthetic modaliases to query these strings. We should give it a try, I think. Having lsusb shipping a private file only for that seems ugly. > Also, I just realise there is also lsusb,py, which I did not port. > What is the usecase for this? Is it also worth porting over? I think this redundancy is just confusing and should be sorted out. If the output mode is more useful than the one from lsusb, it probably should be added to the C program. The .py version has no man page, and new system commands ending in language suffixes just don't look right. I think that should be sorted out and only one of them should exist in the end. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sat, Jul 20, 2013 at 7:03 PM, Ramkumar Ramachandra wrote: > Kay Sievers wrote: >>> If you're so particular about keeping primary unit files "clean", may >>> I suggest moving the exception code to vconsole-setup.c? >> >> That's what I meant, yeah, sorry for the confusion. > > Cool, I understand that your desire to keep primary units clean: I'll > write a patch for this. > > In the meantime, could you merge [1/2] assuming it's fine? No, sorry, the same rule applies to C code as it does to unit files: We do not collect specific exceptions for broken hacks in exotic tools. Means: there will be _zero_ matches on UML strings in systemd to work around the fact that UML "declares" the broken tty0 hack as ok. Such quirk lists of exceptions are not sustainable and will not propagate from UML or any other subsystem to systemd. It sounds fine so far to work around these issues, make things work better in a *generic* way, like gracefully giving up in the running vconsole when it finds out there is no real tty0 to work with. That we can declare as being "robust" or "forgiving", but there will be no specific matches/workarounds in code or unit files for deliberately broken behavior which should just be fixed where it is caused. We just do not support any specific hacks like that, they are wrong at many levels and should be contained or fixed in the subsystem people have decided to do them. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
Kay Sievers wrote: > No, sorry, the same rule applies to C code as it does to unit files: > We do not collect specific exceptions for broken hacks in exotic > tools. Means: there will be _zero_ matches on UML strings in systemd Um, then why do we have a detect-virt at all? A quick grep tells me that we do have specific workaround for specific containers and vms. *scratches head* ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sun, Jul 21, 2013 at 2:44 PM, Ramkumar Ramachandra wrote: > Kay Sievers wrote: >> No, sorry, the same rule applies to C code as it does to unit files: >> We do not collect specific exceptions for broken hacks in exotic >> tools. Means: there will be _zero_ matches on UML strings in systemd > > Um, then why do we have a detect-virt at all? A quick grep tells me > that we do have specific workaround for specific containers and vms. > > *scratches head* Where do you see any "specific exceptions for broken hacks"? We surely support different forms of virtualizations, and support reasonable custom behavior. But we do not support providing a tty0 and have no working VT. It's just madness we don't want to see anywhere, and we which we don't want to collect quirks for. UML can declare that as fine, but it does not mean for systemd to accept that as fine. It is not. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
Kay Sievers wrote:
> Where do you see any "specific exceptions for broken hacks"?
>
> We surely support different forms of virtualizations, and support
> reasonable custom behavior. But we do not support providing a tty0 and
> have no working VT. It's just madness we don't want to see anywhere,
> and we which we don't want to collect quirks for.
So it has to do with classifying uml's behavior as "broken";
therefore, you want systemd to support only the general case of
"broken-ness", and not the specific case of uml.
Fine. Enough talk. Are you happy with these? (rough, untested)
diff --git a/src/getty-generator/getty-generator.c
b/src/getty-generator/getty-generator.c
index 9c7ed1a..d9881d5 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -97,6 +97,7 @@ int main(int argc, char *argv[]) {
char *active;
const char *j;
const char *id = NULL;
+int fd = -1;
if (argc > 1 && argc != 4) {
log_error("This program takes three or no arguments.");
@@ -112,7 +113,8 @@ int main(int argc, char *argv[]) {
umask(0022);
-if (detect_container(NULL) > 0 || (detect_vm(&id) > 0 &&
!strcmp(id, "uml"))) {
+fd = open_terminal("/dev/tty0", O_RDWR|O_CLOEXEC);
+if (detect_container(NULL) > 0 || !is_vconsole(fd)) {
log_debug("Automatically adding console shell.");
if (add_symlink("console-getty.service",
"console-getty.service") < 0)
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bffc632..77d73fb 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -246,9 +246,8 @@ int main(int argc, char **argv) {
}
if (!is_vconsole(fd)) {
-/* uml does not do VT102 emulation */
-if (detect_vm(&id) > 0 && !strcmp(id, "uml"))
-r = EXIT_SUCCESS;
+/* don't fail the service on broken ttys */
+r = EXIT_SUCCESS;
log_error("Device %s is not a virtual console.", vc);
goto finish;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sun, Jul 21, 2013 at 3:13 PM, Ramkumar Ramachandra wrote: > Kay Sievers wrote: >> Where do you see any "specific exceptions for broken hacks"? >> >> We surely support different forms of virtualizations, and support >> reasonable custom behavior. But we do not support providing a tty0 and >> have no working VT. It's just madness we don't want to see anywhere, >> and we which we don't want to collect quirks for. > > So it has to do with classifying uml's behavior as "broken"; > therefore, Not specifically UML, it's just that we first: don't want to maintain and accumulate specific matches for broken behavior, and second: do not want to explicitly support unreasonably broken things. That rule applies to all other hacks of that class too, it's nothing specific to UML. Hacks like the UML tty0 hack is just a too broken idea, to get any support or an exception in a generic tool like systemd. > you want systemd to support only the general case of > "broken-ness", and not the specific case of uml. Right, as long as we can argue it's more "robust" it might be acceptable, but "approving" of the way of pushing deliberately broken low-level things into higher-level tools is another story. We need to avoid that road as much as possible, it will end up in a mess after a while. > Fine. Enough talk. Are you happy with these? (rough, untested) You meant to provide a patch against git, not your earlier patches? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
Kay Sievers wrote: > You meant to provide a patch against git, not your earlier patches? Ofcourse; I was just asking if this is what you meant before submitting another iteration for inclusion. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 12:01:11PM +0200, Tom Gundersen wrote: > On Sun, Jul 21, 2013 at 3:34 AM, Greg KH wrote: > > Can this mean I can drop the usb.ids file from the usbutils package? I > > can't remember where hwdb is generated from, does it rely on the usb.ids > > file for the initial creation? > > hwdb does not use the usb.ids from the usbutils package. > > However, hwdb only contains vendor, product, class, subclass and > protocol. So if you drop usb.ids the rest of the information will be > lost. > > Maybe split the rest out into a separate file and ship only that? Or > is there a way to get this info into hwdb? Kay? The "rest" of the info in there should be split out of usb.ids and probably just imported into the .c code directly, as it's not anything that changes very often, if at all. I can move that directly into usbutils without an issue. > Also, I just realise there is also lsusb,py, which I did not port. > What is the usecase for this? Is it also worth porting over? I agree with Kay, the options it provides should just be moved into the .c code itself. I added it years ago when someone sent it to me as it provided some options that the existing .c code didn't handle. Other than color support, I don't think that is true anymore, but I'll look closer at it to make sure. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 01:05:31PM +0200, Kay Sievers wrote: > > However, hwdb only contains vendor, product, class, subclass and > > protocol. So if you drop usb.ids the rest of the information will be > > lost. > > > > Maybe split the rest out into a separate file and ship only that? > > > > Or is there a way to get this info into hwdb? Kay? > > It should work to add some of that data to the existing modalias, > right? For some things we probably need to "invent" new synthetic > modaliases to query these strings. We should give it a try, I think. > Having lsusb shipping a private file only for that seems ugly. These are things that are just described in the USB-IF specifications, (HID table commands, class codes, etc.) and really should not be part of any "hardware database" as they don't change, and come directly from the spec. I can just move those into the usbutils package, and get them removed from the usb.ids file, sound good? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: wording and grammar updates
On Sun, Jul 21, 2013 at 06:53:14AM +0200, Jan Engelhardt wrote: > This includes regularly-submitted corrections to comma setting and > orthographical mishaps that appeared in man/ in recent commits. > --- > man/crypttab.xml | 4 ++-- > man/journalctl.xml | 2 +- > man/machinectl.xml | 2 +- > man/pam_systemd.xml | 12 ++-- > man/systemctl.xml| 10 +- > man/systemd-bootchart.xml| 2 +- > man/systemd-machined.service.xml | 2 +- > man/systemd-run.xml | 2 +- > man/systemd.cgroup.xml | 4 ++-- > man/systemd.scope.xml| 2 +- > man/systemd.slice.xml| 6 +++--- > man/systemd.special.xml | 6 +++--- > man/systemd.unit.xml | 2 +- > man/systemd.xml | 14 +++--- > man/udev.xml | 2 +- > 15 files changed, 36 insertions(+), 36 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 5:36 PM, Greg KH wrote: > On Sun, Jul 21, 2013 at 01:05:31PM +0200, Kay Sievers wrote: >> > However, hwdb only contains vendor, product, class, subclass and >> > protocol. So if you drop usb.ids the rest of the information will be >> > lost. >> > >> > Maybe split the rest out into a separate file and ship only that? >> > >> > Or is there a way to get this info into hwdb? Kay? >> >> It should work to add some of that data to the existing modalias, >> right? For some things we probably need to "invent" new synthetic >> modaliases to query these strings. We should give it a try, I think. >> Having lsusb shipping a private file only for that seems ugly. > > These are things that are just described in the USB-IF specifications, > (HID table commands, class codes, etc.) and really should not be part of > any "hardware database" as they don't change, and come directly from the > spec. > > I can just move those into the usbutils package, and get them removed > from the usb.ids file, sound good? Sounds great to me, yeah. You are right, I think, the reason we *can* stuff it into the hwdb, is probably not a good enough reason to do it. lsusb would very likely be the only user ever. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: wording and grammar updates
On Sun, Jul 21, 2013 at 6:53 AM, Jan Engelhardt wrote: > - disables the rules file entirely. Hwdb files must have the extension > + disables the rules file entirely. hwdb files must have the extension Hmm, you mean to start a sentence with a lowercase word? Looks a bit unusual ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb
On Sun, Jul 21, 2013 at 05:49:05PM +0200, Kay Sievers wrote: > On Sun, Jul 21, 2013 at 5:36 PM, Greg KH wrote: > > On Sun, Jul 21, 2013 at 01:05:31PM +0200, Kay Sievers wrote: > >> > However, hwdb only contains vendor, product, class, subclass and > >> > protocol. So if you drop usb.ids the rest of the information will be > >> > lost. > >> > > >> > Maybe split the rest out into a separate file and ship only that? > >> > > >> > Or is there a way to get this info into hwdb? Kay? > >> > >> It should work to add some of that data to the existing modalias, > >> right? For some things we probably need to "invent" new synthetic > >> modaliases to query these strings. We should give it a try, I think. > >> Having lsusb shipping a private file only for that seems ugly. > > > > These are things that are just described in the USB-IF specifications, > > (HID table commands, class codes, etc.) and really should not be part of > > any "hardware database" as they don't change, and come directly from the > > spec. > > > > I can just move those into the usbutils package, and get them removed > > from the usb.ids file, sound good? > > Sounds great to me, yeah. > > You are right, I think, the reason we *can* stuff it into the hwdb, is > probably not a good enough reason to do it. lsusb would very likely be > the only user ever. Ok, I'll do that this week, and work with the owner of usb.ids to see if we can just remove them entirely from the file. Thanks again Tom for this patch, much appreciated. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
Kay Sievers wrote: > [...] Fwiw, I more-or-less agree with the principle "don't accumulate specific workarounds when it's not scalable or maintainable". > Hacks like the UML tty0 hack is just a too broken idea, to > get any support or an exception in a generic tool like systemd. I think of it as less of a hack, and more of a deficiency. Nobody stayed up all night drinking coffee to write that VT emulation: that's why it's not there :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sun, Jul 21, 2013 at 6:02 PM, Ramkumar Ramachandra wrote: >> Hacks like the UML tty0 hack is just a too broken idea, to >> get any support or an exception in a generic tool like systemd. > > I think of it as less of a hack, and more of a deficiency. Nobody > stayed up all night drinking coffee to write that VT emulation: that's > why it's not there :) Yeah, sure, we all know how these things work, and no problem with that. There are many systems out there which don't support VTs but also don't pretend to have them, and have only serial lines or special interfaces. That is all well supported already. A tty0 device has special semantics, providing it means supporting it, and that comes with ioctl()s, corresponding files in /sys, /dev/vcs(a), TERM=linux and so on. It's just not right to fake a tiny part of something and hope all will work out. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: wording and grammar updates
On Sunday 2013-07-21 17:53, Kay Sievers wrote: >On Sun, Jul 21, 2013 at 6:53 AM, Jan Engelhardt wrote: > >> - disables the rules file entirely. Hwdb files must have the extension >> + disables the rules file entirely. hwdb files must have the extension > >Hmm, you mean to start a sentence with a lowercase word? Looks a bit unusual >... "hwdb" is in the class of calling names, which enjoy the spelling they have grown up with. Just like "udev" (or "ls" for more prominent example) which, I think, nobody^1 would write as "Udev" at the start of a sentence. ^1 Except LWN.net, maybe. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [QUERY] getty and terminfo
On Sun, 21.07.13 00:17, Ramkumar Ramachandra (artag...@gmail.com) wrote: Heya, > I noticed that my TERM is set to "linux", even when I boot the > console-getty.service. Isn't it supposed to be "console" instead, > since VT emulation is not guaranteed? Should we explicitly pass the > term argument to agetty? We have some code in place that follows where the console is pointing and then determines the right default TERM from that. It uses /sys/class/tty/console/active for this. See default_term_for_tty(), tty_is_vc_resolve(), tty_is_vc() and resolve_dev_console() in src/shared/util.c for details. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sat, 20.07.13 15:55, Ramkumar Ramachandra (artag...@gmail.com) wrote: > > Kay Sievers wrote: > > I would rather see vconsole to detect the mess and silently give up, > > instead of adding exotic options for really weird faked and wrong tty0 > > setups. > > um Linux lacks VT102 emulation, and this is a documented fact. > Therefore, your code: > > unsigned char data[1]; > > data[0] = TIOCL_GETFGCONSOLE; > return ioctl(fd, TIOCLINUX, data) >= 0; > > is guaranteed to fail. Not because something went "wrong", or due to > some "mess" or "fakeness", but because it was perfectly expected. I > discussed this on LKML, and posted an explanation about this already > [1]. > > That said, I don't know what to do about > systemd-vconsole-setup.service: I just followed Zbyszek's suggestion. > Penalizing um Linux for not doing VT102 emulation, and always failing > a service seems user-unfriendly to me. So, we should not add hacks to work around UML brokeness to systemd. I am all happy with supporting kernels with and without VC subsystem, but the thing UML is doing is just wrong. The VT subsystem makes a few guarantees. You get /dev/tty[1..64], you get /dev/tty0 as special multiplexer, and you get /dev/vcs[1..64] and /dev/vcsa[1..64] to access the terminal buffer. On the /dev/tty[1..64] devices you can speak TERM=linux and issue the ioctls listed in console_ioctl(4) all work. You get some files in /sys like /sys/class/tty/tty0/active and they will generate the right events via POLLIN in poll(). That all together is the VT API. The VT API like this is used by numerous applications. systemd itself, logind, X11, gpm, mc, openvt, ... UML provides /dev/tty1, but it implements the wrong TERM on it, supports none of the ioctls, doesn't provide the other matching devices, or the sysfs interface. That is just wrong. It's totally fine if it provided its TTY under some other name, but doing so under the name of /dev/tty1 is just wrong, because that is the interface to the VT, and UML doesn't have anything resembling that. It just has some normal tty of some kind, but certainly *not* a VT! I am happy with rearranging things here and there for projects like UML. However, I am not happy with doing that for an interface that is simply broken and incorrectly implemented by UML: they should not claim the VT devices if they don't implement it. That's just broken. Our approach is that software needs to be fixed where it is broken, not worked around in other software, So please, ask the UML guys to somehow cleanup their VT mess. It's their broken code, and their job to fix it. We had the same discussion regarding how LXC and suchlike set up VTs in containers. It's the same story there: people assumed that mounting some ptys to /dev/tty[1-64] was a good idea, but it really isn't. We were pretty clear in that case, and we are going to be clear in the UML case: you are doing it wrong. Either support VTs or don't, but don't claim you do, but actually support something very wrong and different. And as you long as your VT support is so broken we will not support it in systemd. I can understand if you are disappointed by this, but please try to see it from out side: we want clean, supportable code, and we want code that works correctly. Because, even if we added a work-around to systemd: the next thing would break soon if you try to run it on UML. Better fix UML than add work-around to all those projects individually. Sorry, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sat, 20.07.13 15:55, Ramkumar Ramachandra (artag...@gmail.com) wrote: > > Kay Sievers wrote: > > I would rather see vconsole to detect the mess and silently give up, > > instead of adding exotic options for really weird faked and wrong tty0 > > setups. > > um Linux lacks VT102 emulation, and this is a documented fact. > Therefore, your code: > > unsigned char data[1]; > > data[0] = TIOCL_GETFGCONSOLE; > return ioctl(fd, TIOCLINUX, data) >= 0; > > is guaranteed to fail. Not because something went "wrong", or due to > some "mess" or "fakeness", but because it was perfectly expected. I > discussed this on LKML, and posted an explanation about this already > [1]. > > That said, I don't know what to do about > systemd-vconsole-setup.service: I just followed Zbyszek's suggestion. > Penalizing um Linux for not doing VT102 emulation, and always failing > a service seems user-unfriendly to me. > > [1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012150.html UML shouldn't be penalized for not implementing some terminal emulation, but it should be penalized for doing so under the label of "VT support", which it simply is not providing. They can call their ttys any way they want. If the call them /dev/tty[1..64] however, then they need to implement the VC interfaces. All of them. Also note that some hypervisors implement /dev/hvc0, /dev/xvc0, /dev/hvsi0 and suchlike. Theser are also ttys, which are used for interfacing in a VT-like way the virtual machines. But they do not claim to ve the real VT, they hence picked different tty names. UML should follow the same route: pick some name you like, or even better, pick one of the existing hypervisor tty names if the interface and usecase is the same, but do not use /dev/tty[1..64], because that is the VT subsystem. systemd handles the hvc0, xvc0, hvsi0 automatically already. We'd be happy if UML could make use of the same logic. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
On Sun, 21.07.13 18:14, Ramkumar Ramachandra (artag...@gmail.com) wrote: > > Kay Sievers wrote: > > No, sorry, the same rule applies to C code as it does to unit files: > > We do not collect specific exceptions for broken hacks in exotic > > tools. Means: there will be _zero_ matches on UML strings in systemd > > Um, then why do we have a detect-virt at all? A quick grep tells me > that we do have specific workaround for specific containers and vms. > > *scratches head* We have a couple of branches in there that generically handle all types of containers differently from VMs, but we have only one check for a specific implementation in place (which is KVM which has one specific feature we'd like to make use of and which in fact I'd like to make generic too, so that we can drop the specific check). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] unused translations in git
Hi, so it seems to me, we use gettext to translate the PolicyKit policy files, but we do not actually enable/ship them, as the po files are not added to po/LINGUAS. Admittedly, it's currently only a single translation (Polish), so I was wondering what the intention here is. Do we want systemd to be translated? If so, should we reach out to translator get a broader coverage of languages? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build: do not link everything with -lrt (and therefore -pthread)
--- Makefile.am | 1 + configure.ac | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3ece887..f96866c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1832,6 +1832,7 @@ libsystemd_daemon_internal_la_SOURCES = \ $(libsystemd_daemon_la_SOURCES) libsystemd_daemon_la_CFLAGS = \ + $(RT_LIBS) \ $(AM_CFLAGS) \ -fvisibility=hidden \ -DSD_EXPORT_SYMBOLS diff --git a/configure.ac b/configure.ac index a14b609..5735bd5 100644 --- a/configure.ac +++ b/configure.ac @@ -194,7 +194,6 @@ AM_CONDITIONAL([HAVE_PYTHON_DEVEL], [test "$have_python_devel" = "yes"]) # -- -AC_SEARCH_LIBS([mq_open], [rt], [], [AC_MSG_ERROR([*** POSIX RT library not found])]) AC_SEARCH_LIBS([dlsym], [dl], [], [AC_MSG_ERROR([*** Dynamic linking loader library not found])]) save_LIBS="$LIBS" @@ -202,6 +201,9 @@ LIBS= AC_SEARCH_LIBS([cap_init], [cap], [], [AC_MSG_ERROR([*** POSIX caps library not found])]) AC_CHECK_HEADERS([sys/capability.h], [], [AC_MSG_ERROR([*** POSIX caps headers not found])]) CAP_LIBS="$LIBS" +AC_SEARCH_LIBS([mq_open], [rt], [], [AC_MSG_ERROR([*** POSIX RT library not found])]) +RT_LIBS="$LIBS" +AC_SUBST(RT_LIBS) LIBS="$save_LIBS" AC_SUBST(CAP_LIBS) -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
