.gnome.org/browse/libxml2/tree/parser.c#n14002
I also asked that libxml2 warns directly about this misuse:
https://bugzilla.redhat.com/show_bug.cgi?id=554903
Thanks to Michal Schmidt for tracking this down.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at]
On Tue, 12.01.10 20:07, Tom Lane (t...@redhat.com) wrote:
>
> Lennart Poettering writes:
> > if you have code that links against libxml2 and calls
> > xmlCleanupParser() please verify that your project does that at the
> > appropriate place (i.e. immediately befor
On Wed, 13.01.10 00:21, Lennart Poettering (mzerq...@0pointer.de) wrote:
> Heya!
>
> if you have code that links against libxml2 and calls
> xmlCleanupParser() please verify that your project does that at the
> appropriate place (i.e. immediately before exiting, and only o
revious")
#else
#define WARN_REFERENCE(sym, msg)
#endif
And then simply use something like this:
WARN_REFERENCE(xmlCleanupParser, "You are probably misusing
xmlCleanupParser().");
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 13.01.10 16:07, Tom Lane (t...@redhat.com) wrote:
>
> Lennart Poettering writes:
> > There's something else that came to my mind: if libxml2 is loaded into
> > memory indirectly because some dlopen'ed module wanted it, and then
> > used, and then unl
t;
> The dilemma is in broken libraries that use global variables instead of
> explicitly initialized memory contexts so that you can have multiple
> completely independent instances and also happen to help make them
> thread safe.
If things really were that simple. Unfortu
hose cases.
You can fix this issue by disabling flat-volumes by setting
flat-volumes=no in daemon.conf. Ideally however those drivers should
get fixed.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/
I feel like something has changed, but no idea where the
> issue is.
PA saves per-role/per-app volumes relative to the device volume. So
maybe something changed there. Event sounds are controlled via the
system sounds slider in g-v-c.
Lennart
--
Lennart Poettering
gt; if I turn on audio notification, tab completion and songs going from one
> to the next all sound horrible... Stuff to install/ switches to add etc..
Does the problem go away if you move the system sounds slider in g-v-c
to the very right?
Lennart
--
Lennart Poettering
ld be created:
# systemctl enable ge...@.service prefdm.service getty.target
rc-local.service remote-fs.target
And that should make things work again.
Sorry for the late heads-up.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, 04.08.10 00:10, Lennart Poettering (mzerq...@0pointer.de) wrote:
Small addition. When I was referring to rawhide I meant both F-14 and
the new rawhide. i.e. both F-14 and F-15.
> Heya,
>
> just a little heads up for when you upgrade a rawhide system that is a
> few weeks ol
On Wed, 04.08.10 02:40, Lennart Poettering (mzerq...@0pointer.de) wrote:
>
> On Wed, 04.08.10 00:10, Lennart Poettering (mzerq...@0pointer.de) wrote:
>
> Small addition. When I was referring to rawhide I meant both F-14 and
> the new rawhide. i.e. both F-14 and F-15.
And
On Wed, 04.08.10 10:51, Bill Nottingham (nott...@redhat.com) wrote:
>
> Lennart Poettering (mzerq...@0pointer.de) said:
> > And here's another addition: you might also want to run this command
> > when upgrading from older rwahide to current F-14/rawhide:
> &
On Wed, 04.08.10 16:27, Frank Murphy (frankl...@gmail.com) wrote:
>
> On 04/08/10 16:08, Lennart Poettering wrote:
> >>># systemctl enable graphical.target
> >>>
> >>> This makes sure the default.target link is created properly
> >>
>
. However
I took up nominal maintainership of the package, simply because some
closed source stuff still speaks the esd proto and I need something to
test the PA proto implementation against. So I basically consider esd
package a test case for myself, and that's the sole reason I main
On Thu, 05.08.10 20:35, John Poelstra (poels...@redhat.com) wrote:
> 621200 :: ASSIGNED :: systemd :: Lennart Poettering :: [abrt]
> systemd-units-5-2.fc15: selabel_lookup_common: Process /bin/systemctl
> was killed by signal 11 (SIGSEGV) ::
> https://bugzilla.redhat.com/show_bug.c
pment is supposed to happen in Rawhide FIRST.
Whats the point again of having to development distributions in
parallel? Double the amount of work? Test how wonderful "git merge"
works?
Wasn't there some kind of automatic migration between the to-be-released
distro and rawhide? What happe
already happened when I built systemd the first time after the
branching.
I'd prefer having to maintain a single package only, not two.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nd is a tiny C binary, hence I
see little value in optimizing this dependency away.
Quite frankly I'd like to see stuff like "lsb_release" and similar
programs be replaced by little .pc files across the board.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
de
On Thu, 12.08.10 12:06, Bill Nottingham (nott...@redhat.com) wrote:
>
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > Yes, that is correct. An already built version on f15 will always be
> > > "newer" than anything coming up from f14.
> >
&
uple of weeks more. Maybe that's
something to adopt for Fedora as well?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
as a module, or the RTC module. It just
slows down the boot and will be loaded into the kernel anyway. And
that's why we complain.
(note that systemd will still boot if autofs and ipv6 aren't available
at all, it's not essential and we actually do honour the modprobe
blacklist)
On Wed, 18.08.10 18:45, Dave Jones (da...@redhat.com) wrote:
>
> On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
> > On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote:
> >
> > > > # systemctl enable ge...@.service pre
vice. dcbw has already
fixed this now, but it isn't in f14 yet.
You should be able to work around this by invoking "systemctl enable
NetworkManager.service" and "systemctl start NetworkManager.service".
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 18.08.10 19:35, Dave Jones (da...@redhat.com) wrote:
>
> On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
> > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
> >
> > > > > > It tells me to see the logs for details,
14 bugs page please?
>
> https://fedoraproject.org/wiki/Common_F14_bugs
To my understanding these bugs are visible only if you upgrade from
odler to newer rawhide/f14, resp. when installing an NM version that
entered f14 post alpha.
People installing a fresh f14 image should not see these is
would be nice behaviour
and we basically get it for free, and actually I still think it is.
So, to turn this around. Do you think this behaviour is problematic? Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
Lennart
--
Lennart Poettering - Red Hat, Inc.
On Mon, 23.08.10 10:28, Chris Adams (cmad...@hiwaay.net) wrote:
>
> Once upon a time, Lennart Poettering said:
> > So, to turn this around. Do you think this behaviour is problematic? Can
> > you make a good case for dropping this automatism? If so I'd be willing
>
On Mon, 23.08.10 10:52, Garrett Holmstrom (gho...@fedoraproject.org) wrote:
>
> Lennart Poettering wrote:
> > So, to turn this around. Do you think this behaviour is problematic? Can
> > you make a good case for dropping this automatism? If so I'd be willing
> >
On Mon, 23.08.10 12:23, David Michael (fedora@gmail.com) wrote:
> On Mon, Aug 23, 2010 at 11:51 AM, Lennart Poettering
> wrote:
> > i.e. "auto" → wait for this on boot; "noauto" → don't delay boot for this.
>
> I may be wrong, but wasn't there
s alpha/beta process for Fedora in
place, so that we can find them early.
That all said if you have a look on the number and quality of open bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base syst
at the right time.
Please, end this discussion for now, and restart it if we find a real
issue? That's not too much to ask for now, is it?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ion here: test the alpha. File bugs. You
already have been very successful with that, so please go on.
Anyway, I won't reply to this discussion anymore. I am happy to
reinvestigate this whole issue again if we run into real trouble, but so
far you are "seeing patterns" where no p
ee what even remotely went wrong. So far, I am
myself surprised how smooth this all went. I was prepared for much
worse, I have expected much worse.
I know I am repeating myself: everything's wonderful.
I am quite frankly amazed about the magic powers of fedora-devel to
discuss to death iss
things in F14 are jolly?
Either stop this discussion or tell me exactly which bug you think is
the one that makes you think that "systemd for f14" doesn't work out?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
that this problem is not particularly crucial
and as I understood you you even agreed on trying sssd instead, I'd be
willing to sit down and unfuck pam_ldap to the level that makes this
work, should FESCO come to the conclusion that it matters. The problem
is probably easy to fix actually as pam_ldap should just cleanly refuse
service if the network isn't around.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ds please?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
re, whereas mclasen and adamw were talking about
> systemd, I believe.
David, thanks for the clarifications! Much appreciated!
Matthew, I think you need to choose your examples more
carefully. This is funny. ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 23.08.10 16:39, Mike McGrath (mmcgr...@redhat.com) wrote:
>
> On Mon, 23 Aug 2010, Lennart Poettering wrote:
>
> > On Mon, 23.08.10 16:22, Mike McGrath (mmcgr...@redhat.com) wrote:
> >
> > > (yet another thing we ignored in this process). My experience
24h, and in the other cases it wasn't much different.
I figured the problem people had with systemd was that it was too much
change, not too little. But you seem to believe otherwise, yay?
Let me clarify that the "funny" comment just referred to the quotes
Matthew use
lked with Adam about this, and he suggested 16th
september, but I haven't responded to his suggestion so far.
/me does that now.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ot sure if you actually read this
> > before or participated directly in the discussion, but [...]
>
> "mezcalero" is Lennart himself. Or more precisely, one of his user
> names.
I only ever use this one. No split personality here, sorry ;-)
Lennart
--
Lennart Poettering
of it is not -- things like "noauto now
> means auto" should have been in there. And a FAQ format is not exactly
> what's needed.
Note that the telinit command is supported, too, by systemd. (as is
"init" as an alias for this).
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
tively, if the expert eyes which knew what
> they were doing did migrate, why didn't they catch the bugs that others
> encountered when it became default?
Note that PA is an audio stack for consumers. It's not for audio
technicians. Hence they won't try it. It's as simple
't be Fedora anymore
then.
And I think so far things went really well with systemd, even though
this discussion might create the impression it didn't.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
f new features, e.g. a much nice
> syntax for the unit files compared to the ugly and non race condition
> free sysv init scripts and the bootup should be faster.
Well, for different people different things appear more important. From
that you should not imply that one thing is useless and th
On Mon, 23.08.10 20:04, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> On Mon, Aug 23, 2010 at 11:08:24PM +0200, Lennart Poettering wrote:
> > On Mon, 23.08.10 13:59, Jesse Keating (jkeat...@j2solutions.net) wrote:
> >
> > > On 8/23/10 1:17 PM, Matthew Miller wrote:
&
obably is for 99.9% of all
people). We want prefdm to start as early as possible.
> -- iSCSI /
> -- LDAP user information
> -- IPA/AD user information
> -- NIS user information
Can't test any of this really. Wouldn't even know how to test this. I also
don't want to
On Tue, 24.08.10 03:33, Jeff Garzik (jgar...@pobox.com) wrote:
> File /etc/inittab should keep working at the same level it is now.
Yes, let's have this discussion again. It was so much fun!
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedorapro
as mysqld_t.
With the latest patches we merged this should in theory all be fixed,
right? Or is there anything still left to do in this area?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> how services are started. See the current (now fixed?) NetworkManager
> problems.
Grmbl, let's also note one thing: if LSB headers of init scripts are
incorrect of arbitrary packages I don't want to be held responsible for
that either. The LSB data must be "more correct" than it used to be. But
that's not a bug in systemd...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
instead.
Interesting definition of "important".
BTW, there's a systemd-devel mailing list. Must of the stuff discussed
here should probably discussed there instead.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
AIUI. We're only
> > keeping it around during pre-release, so that if we decide we need to
> > fall back to upstart for final release, it's easy to do. As far as I
> > know, the plan is to decide later (presumably after beta) which one
> > we&
ke systemd do a similar
> > action, if valid.
>
> Since it already is documented as doing the similar actions, let's remove
> "optionally" from this statement.
Well, Upstart doesn't support reexec. We support it just fine, but
if we wouldn't this should
On Tue, 24.08.10 15:55, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Tue, Aug 24, 2010 at 09:33:50PM +0200, Lennart Poettering wrote:
> > What would make sense to add to chkconfig is something that checks
> > whether a systemd unit is installed and then prints "Hey,
at "maintenance" means referred to the
> status of a service) ...
That means something isn't right with the service. For more details see:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
The term was stolen from Solaris SMF btw.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
lect
> > different things. How would you arbitrate?
>
> Well, also as stated in the bug :), always follow the /etc/inittab first. If
> if it makes sense, perhaps systemd should change the default.target to
> match.
Maybe we should check AUTOEXEC.BAT first, too?
Lennart
-
"halt" being called in the end so
that you'd have a system with PID1 but nothing else, not even a
sheel). If set, then running "systemctl start" (and systemctl isolate,
too) will fail with an error, and in systemadm the button to start it
will be greyed out.
Using &quo
On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote:
>
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > - init shall support a mechanism to re-exec itself to not cause dirty
> > > inodes on shutdown; initscripts will use this method on shutdo
ements that indicate where we need
> to be in order to ship systemd as the default in Fedora 14. It doesn't
> matter whose "fault" it is -- if it doesn't work, we can't ship it
> broken.
Great, I geuss I'll become an X hacker then. Apparently if KMS is borke
On Tue, 24.08.10 17:13, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Tue, Aug 24, 2010 at 10:57:38PM +0200, Lennart Poettering wrote:
> > Actually it only shows you the active targets, those which a pending
> > job, and those which have failed before (i.e. the "interes
On Tue, 24.08.10 17:35, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Tue, Aug 24, 2010 at 10:13:26PM +0200, Lennart Poettering wrote:
> > > That said, on the VM I tried F14 upgrading straight from F12 all seem
> > > fine so far, although the output of systemctl i
On Tue, 24.08.10 18:07, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Tue, Aug 24, 2010 at 11:49:56PM +0200, Lennart Poettering wrote:
> > > Wait, so "--all" doesn't actually show me all targets, it shows me an
> > > apparently-arbitrary list of some of
f
multiple different answers would make sense. This should avoid most
problems with scripts doing "if [ `runlevel` = 3 ] ; then", even if
that's a kinda broken thing to do. Since runlevels 3 and 5 are the ones
anaconda writes this should be the safest bet.
Lennart
--
Lennart Poette
On Tue, 24.08.10 20:14, Matt McCutchen (m...@mattmccutchen.net) wrote:
>
> On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote:
> > On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote:
> > > Lennart Poettering (mzerq...@0pointer.de) said:
> > &
works. I tried systemd and couldn't get it to work, so
> I switched the machine back to upstart. You may need a rescue disk to make
> the switch if your computer doesn't boot with systemd. I might try systemd
> again when more of the bugs have been ironed out.
Bugzilla ids?
early); this can still
> race with shutdown in theory, but is probably good enough in practice.
Well, while reexecing on package upgrades might kinda help fix the issue
I think it doesn't really scale, because you'd have to reexec systemd
when any of the libs it uses is upgraded, i.e
e that clear it is called... well... "systemd"...
https://bugzilla.redhat.com/show_bug.cgi?id=627378
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
"3" on the kernel cmdline.
Sorry for breaking this (again), but with this in place things should be
at the appropriate places now for F14.
The bug against anaconda is already filed.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fed
://lists.fedoraproject.org/pipermail/devel/2010-August/140294.html
plus the two followup mails.
Oh, and when you copy the command lines from that mail, make sure to
replace " at " by "@" as the archiver mangled this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
m/default.target
>
> isn't it? :-)
Yupp. Sorry for the confusion. I guess one shouldn't write mails like
that at 2am in the morning...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 26.08.10 12:32, Michal Schmidt (mschm...@redhat.com) wrote:
>
> On Thu, 26 Aug 2010 01:58:41 +0200 Lennart Poettering wrote:
> > We shifted a few files around and most likely your
> > /etc/systemd/system/default.target link will now point into the void,
> > i
group always leaves the systemd tree unmodified.
I hope this clears things up a little. The summary:
There's not systemd vs. libcgroup; more a systemd + libcgroup = ♥
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
md uses cgroups only to
the level that there is a 1:1 relationship between services and cgroups,
and does not get beyond that. That makes it not particularly useful for
Dan's usecase I believe.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.
On Thu, 26.08.10 17:03, Matthew Miller (mat...@mattdm.org) wrote:
> On Thu, Aug 26, 2010 at 10:19:44PM +0200, Lennart Poettering wrote:
> > 2) systemd mounts all hierarchies exposed by the kernel by default. The
> >scheme how it does that follows the default configur
On Thu, 26.08.10 23:30, Lennart Poettering (mzerq...@0pointer.de) wrote:
>
> On Thu, 26.08.10 17:03, Matthew Miller (mat...@mattdm.org) wrote:
>
> > On Thu, Aug 26, 2010 at 10:19:44PM +0200, Lennart Poettering wrote:
> > > 2) systemd mounts all hierarchies exposed by th
file a bug about those! (unless you already did so?)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 14.09.10 16:01, Kevin Fenzi (ke...@scrye.com) wrote:
> * #461 F14 blessing for systemd (nirik, 20:12:29)
> * LINK: http://fedoraproject.org/wiki/QA:Testcase_initialization_basic
> and http://fedoraproject.org/wiki/QA:Testcase_initialization_tools
> (nirik, 20:38:06)
> * ACTION
ests to bugzilla. Coincidentally I
fixed this bug yesterday.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
package for one the most trivial
programs we have in our distribution I'd just go for using the coreutils
hostname implementation.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dy works mostly when you link it to /proc/mounts. For the
securetty hacks I sent a patch last week to PAM.)
Debian in fact has been making great progress to make their OS work with
read-only root by default: http://wiki.debian.org/ReadonlyRoot
Also note that a number of commercial unixes sy
On Tue, 19.10.10 16:51, Stanislav Ochotnicky (sochotni...@redhat.com) wrote:
> On 10/19/2010 04:37 PM, Lennart Poettering wrote:
> > Note that many other distributions gave up on seperate /usr already (for
> > example, Gentoo do this, and even refers to Fedora that it wasn'
actualy be started, however, it is still useful for all
synchronization purposes, and hence not disrupt startup in any way.
You can even specify more than one file in which case the unit will be
run when at least one of those files exists.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
mple, necessitating workarounds in
> libguestfs/qemu. Just speculating, but maybe it doesn't support
> extended attributes, or has only partial support for them?
tmpfs as of now does not support user xattrs. Only SELinux labels are
supported.
Lennart
--
Lennart Poettering -
p_scan_ready_list+0x32/0x154
> [ 37.654015] [] ? ep_remove+0x9b/0x9b
> [ 37.654015] [] ep_poll_readyevents_proc+0x14/0x16
> [ 37.654015] [] ep_call_nested.constprop.2+0x6d/0x9a
> [ 37.654015] [] ? ep_scan_ready_list+0x154/0x154
> [ 37.654015] [] ep_eventpoll_poll+0x45/0x55
&
ut should have one, then
fix the daemon, don't fake a configuration file.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote:
> On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote:
> > On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote:
> >
> > >
> > > Hi,
> > >
> > > 2011/7/18 N
On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote:
>
> Simo Sorce writes:
> > On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote:
> >>>>> http://0pointer.de/blog/projects/on-etc-sysinit.html
>
> >> No. There is no need for a di
tc/machine-id, and
> /etc/os-release and others should come by fiat, although (again) I'm
> very sympathetic to why these things are being done.
These interfaces introduced by systemd are actually discussed in quite
some detail on the systemd irc channel and mailing list. It's a ve
a config file.
Command line options are not wrong, they are completely fine.
What I am saying that faking configuration files, by having wrapper
scripts which build command lines from env var config files is not
ideal. But this was already discussed on this very ML, so I see no
reason to warm this up again.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is the right place to discuss removal of its existing
> configuration, but not the design of the new configuration?
If this "new configuration" is something that shall be shared with other
distributions, then yes, fedora-devel is probably not the right place to
discuss its initial desi
these files.
Nah, not true. The packaging guidelines say explicitly what you should
place in that directory. When we discuss getting rid of the dir we are
also talking about updating the guidelines.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 19.07.11 03:43, Miloslav Trmač (m...@volny.cz) wrote:
> On Mon, Jul 18, 2011 at 11:34 PM, Lennart Poettering
> wrote:
> > On Mon, 18.07.11 23:26, Miloslav Trmač (m...@volny.cz) wrote:
> >> I can't see a reason to discuss /etc/sysconfig as a single unit, nor
&g
al to
recode in other languages. All you need to do is parse $LISTEN_FDS and
$LISTEN_PID and make use of it.)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
this to the systemd mailing list or IRC
channel.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ed 6
times for getty@tty1.service, getty@tty2.service and so on, from a
single service definition file. As are the fsck service or cryptsetup.
Note that writing around in /usr outside of package installation is not
acceptable, since we want to encourage usage of read-only /usr (and even /).
intuitive which ones
those are (i.e. all those where it makes sense to appear multiple times).
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the admin should just copy
/lib/systemd/vncserver@.service to
/etc/systemd/vncserver@1:lennart.service and edit it there. You can do
this for individual users.
Hope this clears some things up.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t specific Apache modules on
fedora-devel, we try to avoid too specific discussions on systemd too,
especially if there's no direct relation to Fedora here.
> Please, I would like to read any answers here in fedoraproject mailing
> list, because I talk about Fedora.
systemd-logind is a systemd
On Wed, 20.07.11 12:17, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> On Wed, Jul 20, 2011 at 11:54, Lennart Poettering
> wrote:
>
> >
> >> Please, I would like to read any answers here in fedoraproject mailing
> >> list, because I talk about Fedora.
1 - 100 of 1852 matches
Mail list logo
