On Thu, Jun 8, 2017 at 8:16 AM, NeilBrown wrote:
> it appears that the fg mount attempt failed quickly (ECONNREFUSED), so it
> background the process immediately. Systemd sees that as success
> (despite the fact that the filesystem isn't actually mounted) and
> doesn't clean up the background pr
On Wed, Jun 07 2017, Steve Dickson wrote:
> On 06/07/2017 08:02 AM, Lennart Poettering wrote:
>> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>>
>>>
>>>
>>> On 06/06/2017 05:49 PM, NeilBrown wrote:
On Tue, Jun 06 2017, Steve Dickson wrote:
> Hello,
>
> On
On 06/07/2017 08:02 AM, Lennart Poettering wrote:
> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>
>>
>>
>> On 06/06/2017 05:49 PM, NeilBrown wrote:
>>> On Tue, Jun 06 2017, Steve Dickson wrote:
>>>
Hello,
On 05/29/2017 06:19 PM, NeilBrown wrote:
>
> Sy
On Fri, May 19, 2017 at 1:46 PM, Chris Murphy wrote:
> FYI the file system folks are discussing this. It is not just a
> problem with XFS it can affect ext4 too. And it's far from clear the
> fs folks have a solution that won't cause worse problems.
OK so this is what I got out of those conversa
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote:
> Thanks, for explanation.
>
> > - a collection of rpms, like a linux distro, including systemd.rpm,
> > libcryptsetup.rpm, and thousands of other loosely coupled rpms
> > → that's a mere aggregation, each of the thousands
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote:
> Thanks, for explanation.
>
> > - a collection of rpms, like a linux distro, including systemd.rpm,
> > libcryptsetup.rpm, and thousands of other loosely coupled rpms
> > → that's a mere aggregation, each of the thousands
Thanks, for explanation.
> - a collection of rpms, like a linux distro, including systemd.rpm,
> libcryptsetup.rpm, and thousands of other loosely coupled rpms
> → that's a mere aggregation, each of the thousands of components carries
> it's own license, each has to be satisfied separately
On Wed, Jun 07, 2017 at 11:47:58AM +0200, Krzysztof Jackiewicz wrote:
> > Not sure what "release product under GPL" is supposed to mean.
>
> The combined work would have to be licensed under GPL according to:
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
> https://www.gnu.org/licens
Hello,
So I am using vncserver on a CentOS system from base repo. I have the
systemd service enabled to start vncserver automatically on each boot.
I found out that vncserver is complaining about /tmp/.X11-unix/X1 socket
file present almost each time shutdown is unclean due to freeze or power
los
On Wed, 07.06.17 14:01, Pawel Szewczyk (p.szewc...@samsung.com) wrote:
> Hello,
>
> What is the purpose of sd_bus_add_filter() function? There is no
> documentation for it and all I can tell from looking over the code is that
> the callback registered by it is called on every dbus message. What e
Hello,
What is the purpose of sd_bus_add_filter() function? There is no
documentation for it and all I can tell from looking over the code is
that the callback registered by it is called on every dbus message. What
else does it do?
Regards,
Paweł Szewczyk
On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>
>
> On 06/06/2017 05:49 PM, NeilBrown wrote:
> > On Tue, Jun 06 2017, Steve Dickson wrote:
> >
> >> Hello,
> >>
> >> On 05/29/2017 06:19 PM, NeilBrown wrote:
> >>>
> >>> Systemd does not, and will not, support "bg" correctly.
>
On 06/06/2017 05:49 PM, NeilBrown wrote:
> On Tue, Jun 06 2017, Steve Dickson wrote:
>
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, better, ways to handle "background" mounting.
>> The only problem with
On 06/07/2017 04:12 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 14:07, Steve Dickson (ste...@redhat.com) wrote:
>
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, better, ways to handle "background" mo
Hi, Benjamin
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the
> state is unknown
>
> Hi Lv,
>
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> Not sure what "release product under GPL" is supposed to mean.
The combined work would have to be licensed under GPL according to:
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
I think that it means that the code has to be rel
The following approach fixes button.lid_init_state=method mode for
systemd 233:
https://patchwork.kernel.org/patch/9756457/
https://patchwork.kernel.org/patch/9756467/
But it is not working well with old systemd 229. This solution tries to
make a more comfortable approach for systemd 229.
There
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
>
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > Subjec
On 06/07/2017 04:13 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 21:57, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2017-06-06 20:07 GMT+02:00 Steve Dickson :
>>> Finally, the whole idea of systemd randomly/silently
>>> strip off mount options is crazy... IMHO...
>>
>> Personally, I would p
There are platform variations implementing ACPI lid device in different
ways:
1. Some platforms send "open" events to OS and the events arrive before
button driver is resumed;
2. Some platforms send "open" events to OS, but the events arrive after
button driver is resumed, ex., Samsung N210+;
Some platforms never send "open" events, _LID returns value sticks to
"close", ex., Surface Pro 1.
Such platforms cannot work well with systemd 229 in
button.lid_init_state=method mode, but button.lid_init_state=open
workaround is available for them to work with systemd 229 and they can work
perfe
On Wed, 07.06.17 09:49, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote:
> I guess the "conflict" was not the best word to describe it.
>
> If I want to release a product with systemd the libryptsetup option will
> force me to release it under GPL. Is that correct?
Not sure what "release
On Tue, 06.06.17 21:57, Michael Biebl (mbi...@gmail.com) wrote:
> 2017-06-06 20:07 GMT+02:00 Steve Dickson :
> > Finally, the whole idea of systemd randomly/silently
> > strip off mount options is crazy... IMHO...
>
> Personally, I would prefer if systemd simply logged a warning/error
> message b
On Tue, 06.06.17 14:07, Steve Dickson (ste...@redhat.com) wrote:
> Hello,
>
> On 05/29/2017 06:19 PM, NeilBrown wrote:
> >
> > Systemd does not, and will not, support "bg" correctly.
> > It has other, better, ways to handle "background" mounting.
> The only problem with this is bg mounts still w
I guess the "conflict" was not the best word to describe it.
If I want to release a product with systemd the libryptsetup option will
force me to release it under GPL. Is that correct?
Thanks,
Krzy
-Original Message-
From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
Sent: T
On Wed, 31.05.17 20:40, Luke Shumaker (luke...@lukeshu.com) wrote:
>
> So my question becomes: what has to be done *after* unsharing the
> mount namespace, but *before* unsharing the PID namespace?
The various types of namespaces are not orthogonal even if they are
exposed in supposedly independ
On Tue, 06.06.17 16:33, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote:
> Hi,
>
> I noticed that when systemd is configured with libcryptsetup option enabled
> it will link to libcryptsetup which is distributed under GPL 2.0. It seems
> like a license conflict to me. Can anyone explain it?
On Thu, 01.06.17 20:46, Benjamin Tissoires (benjamin.tissoi...@redhat.com)
wrote:
> Hi,
>
> Sending this as a WIP as it still need a few changes, but it mostly works as
> expected (still not fully compliant yet).
>
> So this is based on Lennart's comment in [1]: if the LID state is not
> relia
28 matches
Mail list logo