[systemd-devel] Why do we use gold again as default linker?

2015-11-09 Thread Michael Biebl 
I wonder why we use gold as linker in systemd by default.
bfd is not noticeably slower here and the actual generated binaries
seem to be a bit smaller.

-- 
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] [HEADS-UP] Photos, Videos, Slides, Summary from systemd.conf 2015

2015-11-09 Thread Lennart Poettering 
Heya!

For those who missed systemd.conf 2015: I just posted my summary and
thank you note for the conference:

http://0pointer.net/blog/systemdconf-2015-summary.html

You find links to photos, recorded talks, and slides on it, and
more. Enjoy!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Property 'MemoryLimit' is RO when using the D-Bus API

2015-11-09 Thread Francis Moreau 
On Sun, Nov 8, 2015 at 9:38 PM, Lennart Poettering
 wrote:
> On Fri, 06.11.15 18:38, Francis Moreau (francis.m...@gmail.com) wrote:
>
>> Hi,
>>
>> I'm trying to change the MemoryLimit property of one the service unit
>> running on my system by using 'busctl set-property ...' but getting
>> the following error :
>>
>>Property 'MemoryLimit' is not writable.
>>
>> However using 'systemctl set-property' works as expected.
>>
>> I thought that 'systemctl set-property' was basically doing the same
>> D-Bus thing like my former test did but apparently not.
>>
>> Could anybody enlight me why I can't use busctl to set the MemoryLimit
>> property  and why 'systemctl set-property' gives a different result ?
>
> We never hooked that up, that's all..
>
> So, in systemd we have an explicit call SetUnitProperties() that is
> independent of the dbus-mandated Set() calls for the Properties
> interface. We do this mostly to allow atomic changes to multiple
> properties but also to be a step closer to unit file behaviour
> regarding assigning lists of settings to a property, so that it's easy
> to extend ratehr than reset properties that take lists.
>
> In all our tools we use SetUnitProperties() exclusively, since it has
> nicer behaviour. We never thought of hooking up Set() too... but if
> figure it might make sense to do that too, so i'd be happy to take a patch...
>

I see.

It's just from the point of view of a (dumb) user, this behaviour
looked inconsistent. But I can use SetUnitProperties().

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

2015-11-09 Thread Andrei Borzenkov 

10.11.2015 04:41, Jordan Hargrave пишет:



The patch will also decode SMBIOS slot number for NIC, and store in
the variable ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method
for naming ports on a multi-port card plugged into a slot.


Hmm, isn't this stuff the same as exported by the kernel as the
"index" field, i.e. SMBIOS Type 41? Can you elaborate on the relation
of that field and the stuff this patch adds?



  The index is exported for embedded devices, but not add-in cards.
acpi_index may be exported for add-in cards, but generally not very
useful as it has a number like 17 or 24... no relation to the actual
physical slot where a NIC is located.



Quoting SMBIOS spec for Type 9 "Slot ID":

--><--
On a system that supports ACPI, identifies the value returned in the 
_SUN object for this slot.


On a system that supports the PCI IRQ Routing Table Specification, 
identifies the value present
in the Slot Number field of the PCI Interrupt Routing table entry that 
is associated with this slot

--><--

Kernel already exports _SUN when system supports it; and other one does 
not sound very meaningful.


What do you have in /sys/bus/pci/slots?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

2015-11-09 Thread Jordan Hargrave 
On Mon, Nov 9, 2015 at 4:43 PM, Lennart Poettering
 wrote:
> On Mon, 09.11.15 12:42, Jordan Hargrave (jhar...@gmail.com) wrote:
>
>> From: Jordan Hargrave 
>>
>> This patch will integrate some of the features of biosdevname into systemd.
>> The code detects the port and index for detecting NIC partitions. This 
>> creates
>> a new environment variable, ID_NET_NAME_PARTITION of the format
>> _
>
> "partitions"? What's that supposed to be? SR-IOV?
>

Similar to SR-IOV but on Dell servers partitions actually show up as
PCI devices in the initial enumeration.  The PCI device vital product
data area has a map of which Bus:Dev:Func is which port and which port
instance.

So say we have a PCI device tree for a quad-port NIC, 4 physical ports
but 8 NICs.

04:00.0 port 1, instance 1
04:00.1 port 2, instance 1
04:00.2 port 3, instance 1
04:00.3 port 4, instance 1
04:00.4 port 1, instance 2
04:00.5 port 2, instance 2
04:00.6 port 3, instance 2
04:00.7 port 4, instance 2

We use this partition info to display if a bond is created that
contains the same physical nic port.

>> The patch will also decode SMBIOS slot number for NIC, and store in
>> the variable ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method
>> for naming ports on a multi-port card plugged into a slot.
>
> Hmm, isn't this stuff the same as exported by the kernel as the
> "index" field, i.e. SMBIOS Type 41? Can you elaborate on the relation
> of that field and the stuff this patch adds?
>

 The index is exported for embedded devices, but not add-in cards.
acpi_index may be exported for add-in cards, but generally not very
useful as it has a number like 17 or 24... no relation to the actual
physical slot where a NIC is located.

>> Signed-off-by: Jordan Hargrave 
>
> I didn't look too closely in the actual sources, but I did notice that
> it is line-broken, and doesn't follow CODING_STYLE in quite a few
> cases, regarding placement of brackets, or error handling for
> example.
>
> In order to avoid any confusion with line-broken patches, and to make
> review easier, please submit the patch as github PR, which is the way
> we generally prefer receiving patches these days!

Where do I submit this?

>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

2015-11-09 Thread Jordan Hargrave 
Cleaned up linux coding style

This patch will integrate some of the features of biosdevname into systemd.
The code detects the port and index for detecting NIC partitions. This creates
a new environment variable, ID_NET_NAME_PARTITION of the format
_

The patch will also decode SMBIOS slot number for NIC, and store in the variable
ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method for naming
ports on a multi-port card plugged into a slot.

Signed-off-by: Jordan Hargrave 
---
 src/udev/udev-builtin-net_id.c | 206 +
 1 file changed, 206 insertions(+)

diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index bf5c9c6..04b08dd 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -119,16 +119,130 @@ struct netnames {
 bool mac_valid;

 struct udev_device *pcidev;
+struct udev_device *physdev;
 char pci_slot[IFNAMSIZ];
 char pci_path[IFNAMSIZ];
 char pci_onboard[IFNAMSIZ];
 const char *pci_onboard_label;
+int  npar_port;
+int  npar_pfi;
+int  smbios_slot;

 char usb_ports[IFNAMSIZ];
 char bcma_core[IFNAMSIZ];
 char ccw_group[IFNAMSIZ];
 };

+#define FLAG_IOV 0x80
+#define FLAG_NPAR 0x1000
+
+#define VPDI_TAG 0x82
+#define VPDR_TAG 0x90
+
+struct vpd_tag {
+char  cc[2];
+unsigned char len;
+char  data[1];
+};
+
+/* Read VPD tag ID */
+static int vpd_readtag(int fd, int *len)
+{
+unsigned char tag, tlen[2];
+
+if (read(fd, , 1) != 1)
+return -1;
+if (tag == 0x00 || tag == 0xFF || tag == 0x7F)
+return -1;
+if (tag & 0x80) {
+if (read(fd, tlen, 2) != 2)
+return -1;
+*len = tlen[0] + (tlen[1] << 8);
+return tag;
+}
+*len = (tag & 0x7);
+return (tag & ~0x7);
+}
+
+static void *vpd_findtag(void *buf, int len, const char *sig)
+{
+int off, siglen;
+struct vpd_tag *t;
+
+off = 0;
+siglen = strlen(sig);
+while (off < len) {
+t = (struct vpd_tag *)((unsigned char *)buf + off);
+if (!memcmp(t->data, sig, siglen))
+return t;
+off += (t->len + 3);
+}
+return NULL;
+}
+
+static void dev_pci_npar_dcm(struct udev_device *dev, struct netnames *names,
+ int len, const char *dcm,
+ const char *fmt, int step)
+{
+int domain, bus, slot, func, off, mydf;
+int port, df, pfi, flag;
+
+if (sscanf(udev_device_get_sysname(names->physdev), "%x:%x:%x.%u",
+   , , , ) != 4)
+return;
+mydf = (slot << 3) + func;
+for (off = 3; off < len; off += step) {
+if (sscanf(dcm+off, fmt, , , , ) != 4)
+continue;
+if ((flag & FLAG_NPAR) && mydf == df) {
+names->npar_port = port;
+names->npar_pfi = pfi;
+}
+}
+}
+
+static void dev_pci_npar(struct udev_device *dev, struct netnames *names)
+{
+const char *filename;
+int len, fd;
+struct vpd_tag *dcm;
+void *buf;
+
+/* Search for VPD or IOV VPD */
+filename = strjoina(udev_device_get_syspath(names->physdev), "/vpd");
+fd = open(filename, O_RDONLY);
+if (fd < 0)
+return;
+if (vpd_readtag(fd, ) != VPDI_TAG)
+goto done;
+lseek(fd, len, SEEK_CUR);
+
+/* Check VPD-R */
+if (vpd_readtag(fd, ) != VPDR_TAG)
+goto done;
+buf = alloca(len);
+if (read(fd, buf, len) != len)
+goto done;
+
+/* Check for DELL VPD tag */
+if (!vpd_findtag(buf, len, "DSV1028VPDR.VER"))
+goto done;
+
+/* Find DCM/DC2 tag */
+dcm = vpd_findtag(buf, len, "DCM");
+if (dcm != NULL)
+dev_pci_npar_dcm(dev, names, dcm->len, dcm->data,
+ "%1x%1x%2x%6x", 10);
+else {
+dcm = vpd_findtag(buf, len, "DC2");
+if (dcm != NULL)
+dev_pci_npar_dcm(dev, names, dcm->len, dcm->data,
+ "%1x%2x%2x%6x", 11);
+}
+done:
+close(fd);
+}
+
 /* retrieve on-board index number and label from firmware */
 static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
 unsigned dev_port = 0;
@@ -187,6 +301,78 @@ static bool is_pci_multifunction(struct udev_device *dev) {
 return false;
 }

+enum {
+SLOT_USAGE_OTHER = 1,
+SLOT_USAGE_UNKNOWN,
+SLOT_USAGE_AVAILABLE,
+SLOT_USAGE_INUSE,
+};
+
+struct smbios_type9 {
+

Re: [systemd-devel] [PATCH 1/2] detect-virt: detect in best-heuristic order

2015-11-09 Thread Christian Hesse 
Mantas Mikulėnas  on Wed, 2015/11/04 15:55:
> On Wed, Nov 4, 2015 at 3:52 PM, Lennart Poettering 
> wrote:
> 
> > On Wed, 04.11.15 15:54, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> >  
> > > 04.11.2015 00:04, Andrew Jones пишет:  
> > > >afaict, this will fix a regression caused by commit 75f86906c5.
> > > >Where we used to report "kvm" before that patch, without this patch,
> > > >we would only report "qemu".  
> > >
> > > Are you sure it is regression? QEMU is a program (platform) while KVM is
> > > technology. Modern VirtualBox can use KVM as PV interface but it still
> > > remains VirtualBox. QEMU may use KVM as PV interface but it still
> > > remains QEMU.
> > >
> > > Where does it matter? Is anything broken because of this change?  
> >
> > I am pretty sure that vbox should be reported as vbox even if it uses
> > kvm as backend. qemu-kvm should be reported as kvm, and any other qemu
> > as qemu.
> >  
> 
> As I understand it, VirtualBox doesn't use KVM as *backend*; it only
> exposes a KVM-like paravirt interface to *guests*.

It does use kvm since version 5.0.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


pgpHcb6_mOMPF.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kdbus refactoring?

2015-11-09 Thread Andy Lutomirski 
On Mon, Nov 9, 2015 at 9:07 AM, Greg KH  wrote:
> On Mon, Nov 09, 2015 at 05:02:45PM +, Måns Rullgård wrote:
>> Andy Lutomirski  writes:
>>
>> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH  wrote:
>> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH  
>> >>> wrote:
>> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >>> >> the mailinglist archives for more details but didn't find anything.
>> >>> >> So, what are your plans?
>> >>> >>
>> >>> >> [1] 
>> >>> >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >>> >
>> >>> > As that link said, based on the result of the code being in Rawhide, it
>> >>> > is now being reworked / redesigned.  The result will be posted for
>> >>> > review "when it's ready".
>> >>>
>> >>> If you rework/redesign something you have to know what you want to 
>> >>> change.
>> >>> That's why I was asking for the plan...
>> >>
>> >> Since when do people post "plans" or "design documents" on lkml without
>> >> real code?  Again, code will be posted when it's ready, like any other
>> >> kernel submission.
>> >
>> > I ask for feedback on ideas and designs on a fairly regular basis.  I
>> > even frequently get valuable feedback :)
>> >
>> > I would like to think that the kernel community would have something
>> > of value to add to the process of designing and implementing a major
>> > new IPC mechanism.
>>
>> The "trust us, we'll show it when it's ready" attitude reminds me of the
>> controversial TPP and TTIP negotiations.
>
> Ok, that's just trolling, cut it out.
>
> When something is even in the "hey look, it works, here's the big
> changes from last time", we will of course post it, but right now,
> things are being totally revisited based on the feedback we have
> received so far.  Give people a chance to recover from conferences and
> then get back to work...
>

I hate to say this, but this approach to receiving feedback makes me
really dislike the process.

I read a fairly large fraction of the kdbus code.  I found what I
perceived to be issues, and I spoke up.  I was told for quite a while
that the authors disagreed that the issues I found were issues and
that my assessment of the security aspects of the code was correct.

Now the submission has been withdrawn (because of feedback received so
far?  from me?) and there will apparently be a new submission out of
the blue, allegedly based on feedback.

As a developer, I'm willing to ask for feedback on ideas and to ask
for feedback on code.  In many cases, I've gotten (correct!) feedback
telling me that my design is wrong or needs major changes.  I *always*
try to answer such feedback respectfully and, if the reviewers are
right (which they usually are), I won't keep shoving code they don't
like in their face.  In fact, IIRC I got my start as a serious x86
developer when I wrote some code and tglx told me that the way I
designed it was unacceptable for upstream.  In response, I thought
about what the issues were, asked some questions, and rewrite the
majority of the code.  I think I learned a lot from the process, and
the code was vastly improved as a result.  If I'd sent substantially
the same patch series three or four more times and then declared that
I was withdrawing it without commenting directly on what I'd changed,
I really doubt that anyone would have taken my next submission
seriously.

Please understand that kdbus' approach to receiving feedback is very
off-putting.  Fortunately the vast majority of kernel developers
receive feedback for graciously and transparently, because otherwise
I'd probably just never review anything.  Frankly, if I were in the
chain of people through whom the kdbus code would flow to an eventual
home in Linus' tree, I would just say that the developers have used up
my patience as a reviewer and the onus would be on the developers to
demonstrate that it's worth my time to continue thinking about the
code.

--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add support for detecting NIC partitions on Dell Servers

2015-11-09 Thread systemd github import bot 
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kdbus refactoring?

2015-11-09 Thread Greg KH 
On Mon, Nov 09, 2015 at 05:02:45PM +, Måns Rullgård wrote:
> Andy Lutomirski  writes:
> 
> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH  wrote:
> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH  
> >>> wrote:
> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
> >>> >> Hi all,
> >>> >>
> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
> >>> >> the mailinglist archives for more details but didn't find anything.
> >>> >> So, what are your plans?
> >>> >>
> >>> >> [1] 
> >>> >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
> >>> >
> >>> > As that link said, based on the result of the code being in Rawhide, it
> >>> > is now being reworked / redesigned.  The result will be posted for
> >>> > review "when it's ready".
> >>>
> >>> If you rework/redesign something you have to know what you want to change.
> >>> That's why I was asking for the plan...
> >>
> >> Since when do people post "plans" or "design documents" on lkml without
> >> real code?  Again, code will be posted when it's ready, like any other
> >> kernel submission.
> >
> > I ask for feedback on ideas and designs on a fairly regular basis.  I
> > even frequently get valuable feedback :)
> >
> > I would like to think that the kernel community would have something
> > of value to add to the process of designing and implementing a major
> > new IPC mechanism.
> 
> The "trust us, we'll show it when it's ready" attitude reminds me of the
> controversial TPP and TTIP negotiations.

Ok, that's just trolling, cut it out.

When something is even in the "hey look, it works, here's the big
changes from last time", we will of course post it, but right now,
things are being totally revisited based on the feedback we have
received so far.  Give people a chance to recover from conferences and
then get back to work...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kdbus refactoring?

2015-11-09 Thread Andy Lutomirski 
On Sun, Nov 8, 2015 at 3:30 PM, Greg KH  wrote:
> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH  wrote:
>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >> Hi all,
>> >>
>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >> the mailinglist archives for more details but didn't find anything.
>> >> So, what are your plans?
>> >>
>> >> [1] 
>> >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >
>> > As that link said, based on the result of the code being in Rawhide, it
>> > is now being reworked / redesigned.  The result will be posted for
>> > review "when it's ready".
>>
>> If you rework/redesign something you have to know what you want to change.
>> That's why I was asking for the plan...
>
> Since when do people post "plans" or "design documents" on lkml without
> real code?  Again, code will be posted when it's ready, like any other
> kernel submission.

I ask for feedback on ideas and designs on a fairly regular basis.  I
even frequently get valuable feedback :)

I would like to think that the kernel community would have something
of value to add to the process of designing and implementing a major
new IPC mechanism.

--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pulseaudio & systemd-nspawn

2015-11-09 Thread Poncho 
On 09.11.2015 11:29, Kai Hendry wrote:
> On Mon, 2 Nov 2015, at 09:46 PM, Felipe Sateler wrote:
>> Maybe the better option is to load the tcp pulseaudio module, allow 
>> connections from the container ip, and inject PULSE_SERVER envvar into 
>> the container.
> 
> Using tcp will not work since I'm using OpenVPN which seems to usurp all
> network traffic.
> 
> Any other ideas?
> 
> Many thanks,
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

This works for me:

--bind=/run/user/1000/pulse:/run/user/host/pulse

/run/user/1000 gets mounted as tmpfs in the container as soon as you
login with the id 1000 user, therefore bind mount it to /run/user/host

then, use systemd-run with
--setenv=PULSE_SERVER=unix:/run/user/host/pulse/native
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

2015-11-09 Thread Lennart Poettering 
On Mon, 09.11.15 12:42, Jordan Hargrave (jhar...@gmail.com) wrote:

> From: Jordan Hargrave 
> 
> This patch will integrate some of the features of biosdevname into systemd.
> The code detects the port and index for detecting NIC partitions. This creates
> a new environment variable, ID_NET_NAME_PARTITION of the format
> _

"partitions"? What's that supposed to be? SR-IOV?

> The patch will also decode SMBIOS slot number for NIC, and store in
> the variable ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method
> for naming ports on a multi-port card plugged into a slot.

Hmm, isn't this stuff the same as exported by the kernel as the
"index" field, i.e. SMBIOS Type 41? Can you elaborate on the relation
of that field and the stuff this patch adds?

> Signed-off-by: Jordan Hargrave 

I didn't look too closely in the actual sources, but I did notice that
it is line-broken, and doesn't follow CODING_STYLE in quite a few
cases, regarding placement of brackets, or error handling for
example. 

In order to avoid any confusion with line-broken patches, and to make
review easier, please submit the patch as github PR, which is the way
we generally prefer receiving patches these days!

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pulseaudio & systemd-nspawn

2015-11-09 Thread Kai Hendry 
On Mon, 2 Nov 2015, at 09:46 PM, Felipe Sateler wrote:
> Maybe the better option is to load the tcp pulseaudio module, allow 
> connections from the container ip, and inject PULSE_SERVER envvar into 
> the container.

Using tcp will not work since I'm using OpenVPN which seems to usurp all
network traffic.

Any other ideas?

Many thanks,
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kdbus refactoring?

2015-11-09 Thread Richard Weinberger 
On Mon, Nov 9, 2015 at 12:30 AM, Greg KH  wrote:
> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH  wrote:
>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >> Hi all,
>> >>
>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >> the mailinglist archives for more details but didn't find anything.
>> >> So, what are your plans?
>> >>
>> >> [1] 
>> >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >
>> > As that link said, based on the result of the code being in Rawhide, it
>> > is now being reworked / redesigned.  The result will be posted for
>> > review "when it's ready".
>>
>> If you rework/redesign something you have to know what you want to change.
>> That's why I was asking for the plan...
>
> Since when do people post "plans" or "design documents" on lkml without
> real code?  Again, code will be posted when it's ready, like any other
> kernel submission.

Nobody asked for a design document.
And yes, people often say what they do or want to do.
Anyway, heise.de has details from the systemd.conf:
http://www.heise.de/open/meldung/Linux-Kdbus-soll-universeller-werden-Videos-von-Systemd-Konferenz-2910910.html

According to them the plan is making kdbus more universal and less
dbus specific.
Which sounds great.

-- 
Thanks,
//richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel