Hi Zbigniew, thanks for reviewing.
> Even without this patch, the unit would be started, and *then* stopped
> immediately, so it's not true that the user doesn not know if will be
> started.
Ok, I try to use this analogy. You want to install okular with package
manager. Package manager install
Hello,
I have systemd in both Arch and Debian sid, on my netbook.
I have noticed that when I power on netbook with USB flash disk installed,
this USB drive sometimes becomes /dev/sda.
Is this correct? How can I ensure that hard disk is first, at every boot?
Regards.
_
Am 05.02.2013 09:30, schrieb Baurzhan Muftakhidinov:
> Hello,
>
> I have systemd in both Arch and Debian sid, on my netbook.
> I have noticed that when I power on netbook with USB flash disk installed,
> this USB drive sometimes becomes /dev/sda.
>
> Is this correct? How can I ensure that hard
On Tue, Feb 5, 2013 at 9:30 AM, Baurzhan Muftakhidinov
wrote:
> I have systemd in both Arch and Debian sid, on my netbook.
> I have noticed that when I power on netbook with USB flash disk installed,
> this USB drive sometimes becomes /dev/sda.
>
> Is this correct? How can I ensure that hard disk
On Tue, 2013-02-05 at 06:40 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 31, 2013 at 07:21:27PM -0500, Colin Walters wrote:
> > Using -Wl,--gc-sections helps a lot, but still. We could just put it in
> > a private path like /usr/lib/systemd/libsystemd-shared.so.
> I have been wanting
On Tue, Feb 5, 2013 at 1:01 PM, Colin Walters wrote:
> On Tue, 2013-02-05 at 06:40 +0100, Zbigniew Jędrzejewski-Szmek wrote:
>> On Thu, Jan 31, 2013 at 07:21:27PM -0500, Colin Walters wrote:
>> > Using -Wl,--gc-sections helps a lot, but still. We could just put it in
>> > a private path like /usr
On Tue, 2013-02-05 at 13:10 +0100, Kay Sievers wrote:
> We do not want to place shared libraries with private APIs in the
> system. Other people might rely on stuff which we can never track.
Note that it installs into a private subdirectory, so people writing
apps can't just use -lsystemd-shared
Alright,
I've tried on netbook and on relatively powerful laptop to boot 10 times
latest ArchLinux's archboot image from the USB drive.
On laptop, hard disk was /dev/sda 10 times out of 10 tries,
On netbook, only 3 times hard disk was /dev/sda and 7 times USB drive
became /dev/sda.
What concerns
Am 05.02.2013 14:30, schrieb Baurzhan Muftakhidinov:
> I've tried on netbook and on relatively powerful laptop to boot 10 times
> latest ArchLinux's archboot image from the USB drive.
>
> On laptop, hard disk was /dev/sda 10 times out of 10 tries,
> On netbook, only 3 times hard disk was /dev/sd
2013/2/5 Colin Walters :
> On Tue, 2013-02-05 at 13:10 +0100, Kay Sievers wrote:
>
>> We do not want to place shared libraries with private APIs in the
>> system. Other people might rely on stuff which we can never track.
>
> Note that it installs into a private subdirectory, so people writing
> ap
'Twas brillig, and Baurzhan Muftakhidinov at 05/02/13 13:30 did gyre and
gimble:
> Alright,
> I've tried on netbook and on relatively powerful laptop to boot 10 times
> latest ArchLinux's archboot image from the USB drive.
>
> On laptop, hard disk was /dev/sda 10 times out of 10 tries,
>
> On net
Am 05.02.2013 14:30, schrieb Baurzhan Muftakhidinov:
> What concerns me here is that there is no consistency on less powerful
> machine.
There is no consistency. Period. Not on more powerful and not on less
powerful machines. There never was, there never will be.
In some form, this "problem" has
Hello,
I was wondering how (calendar) timer events triggering occurs on systems that
aren't running 24/7 (e.g. a typical desktop system). To do that I used these
two simple units:
[Unit]
Description=Calendar Test Service
[Service]
Type=oneshot
ExecStart=/
On Tue, Feb 5, 2013 at 8:54 AM, Jan Janssen wrote:
> It would be nice if timers got scheduled based on their last time they got
> triggered.
They have always supported this, even before we added calendar-based
support. Check out the systemd.timer man page.
--
David Strauss
| da...@davidstraus
On Mon, Feb 4, 2013 at 6:49 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> What about renaming Journalctl to Journal? It doesn't really control anything
> :)
Neither does the actual journalctl. :-)
But, systemd's naming convention is to call first-tier shell utilities
ctl and second-tier shell utilit
Howdy Lennart and the systemd gang,
Trying to play with systemd-nspawn on a Fedora 18 system using a
3.8-rc5 kernel (if it matters) with audit turned off (why is that
needed? -- i couldn't set the root password without doing so, but am not
sure what the incompatibility is) ...
more or less follow
On Tue, Feb 05, 2013 at 12:34:19PM -0700, Jake Edge wrote:
> Howdy Lennart and the systemd gang,
>
> Trying to play with systemd-nspawn on a Fedora 18 system using a
> 3.8-rc5 kernel (if it matters) with audit turned off (why is that
> needed? -- i couldn't set the root password without doing so,
On Tue, Feb 5, 2013 at 8:34 PM, Jake Edge wrote:
> Howdy Lennart and the systemd gang,
>
> Trying to play with systemd-nspawn on a Fedora 18 system using a
> 3.8-rc5 kernel (if it matters) with audit turned off
You should be able to use audit=0 on the kernel command line.
> (why is that needed?
Repeating myself, but I'll say it again: I strongly prefer a feature
set that is a subset of iCal/xCal [1]. I'd like it to be possible in
the future to expose existing and future runs via CalDAV over
something like the gateway.
iCal already supports "last day of month schedules":
FREQ=MONTHLY;INT
On Tue, Feb 5, 2013 at 11:54 AM, David Strauss wrote:
> Repeating myself, but I'll say it again: I strongly prefer a feature
> set that is a subset of iCal/xCal [1].
Here's a better exposition of the richness of RRULE:
http://www.rahulsingla.com/blog/2010/12/parsing-ical-rrule
It's also a great
On Tue, 5 Feb 2013 20:43:58 +0100 Kay Sievers wrote:
> On Tue, Feb 5, 2013 at 8:34 PM, Jake Edge wrote:
> > Howdy Lennart and the systemd gang,
> >
> > Trying to play with systemd-nspawn on a Fedora 18 system using a
> > 3.8-rc5 kernel (if it matters) with audit turned off
>
> You should be able
On Mon, Feb 04, 2013 at 01:53:24PM +0100, Michal Vyskocil wrote:
> > Hi,
> > can you check if it works with the following test case?
> > For me it doesn't, and I think there must be a bug.
> >
> > Zbyszek
>
> Hi Zbigniew,
>
> sorry for a responding on my initial email, but for some reason your
>
Is there interest in a patch? It looks like adding Recurrence= to
timer units to support iCal RECUR format would be trivial.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
On Mon, Feb 04, 2013 at 10:42:02PM +, Steven Hiscocks wrote:
I've made the suggested changes and pushed it to github. Feedback
welcomed :)
Thanks!
Some more thoughts on the API below. Some of those are probably
stupid, but I want t
On Mon, Feb 4, 2013 at 1:09 PM, Lennart Poettering
wrote:
> If we choose the latter, would "verbosity" really be the best choice? I
> am not a native english speaker, but to me this sounds much broader than
> "priority" or "level" do?
I suggested it for two reasons:
* There's a long history of
In the spirit of "proudly invented elsewhere," Python uses log message
"levels" and filters by minimum severity as the "effective level." The
reason I prefer "verbosity" to "level" is that level discards any
suggestion of the values having an ordering useful for
inequality-based comparison.
On Tue
On Tue, Feb 05, 2013 at 01:42:57PM -0800, David Strauss wrote:
> In the spirit of "proudly invented elsewhere," Python uses log message
> "levels" and filters by minimum severity as the "effective level." The
> reason I prefer "verbosity" to "level" is that level discards any
> suggestion of the va
Adds test coverage and generates html reports. Configure with
--enable-coverage and run make lcov.
make lcov-upload exists but it currently just rsyncs the report to
~/coverage. Perhaps we can set up a host for it and automate it later?
I have temporarily uploaded an example to look at here:
http:
On Tue, Feb 05, 2013 at 09:22:46PM +, Steven Hiscocks wrote:
> On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
> >Hi,
> >
> >On Mon, Feb 04, 2013 at 10:42:02PM +, Steven Hiscocks wrote:
> >>I've made the suggested changes and pushed it to github. Feedback
> >>welcomed :)
> >Thanks!
>
On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 09:22:46PM +, Steven Hiscocks wrote:
On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
On Mon, Feb 04, 2013 at 10:42:02PM +, Steven Hiscocks wrote:
I've made the suggested changes and pushed it to gi
Hi Lennart,
> It should suffice to invoke your set_modifiers() function in some
> wrapper function set_modifiers_on_all_vcs() which internally just runs
> VT_GETSTATE and iterates over all allocated VCs. See
> font_copy_to_all_vcs() for inspiration.
Done. I've factored out the common code as an it
On Tuesday 2013-02-05 01:36, Kay Sievers wrote:
>On Sat, Feb 2, 2013 at 11:17 PM, Arthur Taylor wrote:
>
>> KDSKBMODE is a virtual console ioctl which changes the current "mode"
>> of the virtual console keyboard for that particular virtual terminal.
>> That is, the virtual console keyboard mode,
On Tue, Feb 05, 2013 at 11:45:10PM +, Steven Hiscocks wrote:
> On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Feb 05, 2013 at 09:22:46PM +, Steven Hiscocks wrote:
> >>On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
> >>>Hi,
> >>>
> >>>On Mon, Feb 04, 2013 at 10:42:02
On Tue, Feb 5, 2013 at 2:13 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Why? Higher level, lower level, the term "level" is _very_ strongly tied
> to (vertical) ordering. Also, height-related methaphors are one of the
> most common in all languages, so using "level" makes the metaphor easy.
I guess
Hi Lennart,
I've modified the patch again so that it also sets the default state of the
LED flags to the configued values. Otherwise it'd switch NumLock off again
when you type reset into the console.
Cheers
Matthias
diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml
index 45156b7..4335
On Mon, Feb 4, 2013 at 11:47 PM, Lennart Poettering
wrote:
> This definitely sounds useful. We should certainly extend our syntax to
> support this, and the code for it wouldn't even be that difficult.
>
> However: we'd first have to come up with a nice syntax for it. I'd
> assume we probably want
On Tue, Feb 5, 2013 at 10:15 PM, David Strauss wrote:
> Is there interest in a patch? It looks like adding Recurrence= to
> timer units to support iCal RECUR format would be trivial.
I'm personally not too excited about supporting a full embedded
"language for timers". :)
Many of the things in i
On Tue, Feb 5, 2013 at 6:17 PM, Kay Sievers wrote:
> Many of the things in iCal we *really* don't want or need, like the
> re-occurrence counters we would need to store and we likely don't want
> that kind of state, the time zones which I think we should entirely
> ignore for a system service, wei
On Tue, Feb 05, 2013 at 06:48:23PM -0800, David Strauss wrote:
> On Tue, Feb 5, 2013 at 6:17 PM, Kay Sievers wrote:
> > Many of the things in iCal we *really* don't want or need, like the
> > re-occurrence counters we would need to store and we likely don't want
> > that kind of state, the time zo
I haven't tested this other than ensuring that it compiles with iCal
support (default) and with --disable-ical.
I opted for putting the modularity into which sources get compiled,
like the gateway, which necessarily requires some #ifdefs in the timer
code. I could also put the modularity into the
40 matches
Mail list logo
