Logging is quite broken

This bug was fixed in the package xsplash - 0.8.3-0ubuntu1

---------------
xsplash (0.8.3-0ubuntu1) karmic; urgency=low

  * New upstream version (LP: #446658)
    - watch for monitors-changed signal (LP: #413348)
    - set a blank cursor on the cow foreign window (LP: #432179)
    - setgid fixes (LP: #439268)
    - 16bpp depth fixes (LP: #423632)
  * debian/patches/90_correctly-setuid.patch
    - Removed, merged upstream

 -- Ken VanDine <email address hidden> Fri, 09 Oct 2009 08:16:49 +0200

This bug is about logging being broken, not setgid:

    - setgid fixes (LP: #439268)

It seems to be fixed though. Are you sure it's not?

I didn't checked whether fixed or not; I only reopened based on the erroneous closing in the changelog entry

Fair enough. I'm going to close this since it appears to be fixed. Thanks.

I only see a single "Started" log in gdm/xsplash.log but I understand two xsplash are started during boot; where's the other log?

On Sat, 2009-10-10 at 13:39 +0000, Loïc Minier wrote:
> I only see a single "Started" log in gdm/xsplash.log but I understand
> two xsplash are started during boot; where's the other log?

We changed the upstream code to log to xsplash-PID.log, IIRC. This makes
it easy to cross reference bootchart data.

Previously every xsplash nuked the prior log.

-Rob

How are the logs cleaned up?

I only see a xsplash.log right now; my original suggestion was to have the second xsplash append to the log and both xsplash log lines with their pid in them.

On Sun, 2009-10-11 at 20:42 +0000, Loïc Minier wrote:
> How are the logs cleaned up?
>
> I only see a xsplash.log right now; my original suggestion was to have
> the second xsplash append to the log and both xsplash log lines with
> their pid in them.

They aren't cleaned up at the moment; we probably want to do that :).
Note that even using a PID prefix in the lines would still require some
cleanup as the log would otherwise get very long.

-Rob

I haven't actually merged that into master yet. I was thinking to instead write xsplash-gdm.log or xsplash-session.log, but doing it that way would require parsing command-line parameters before determining what the log filename is.

I think I overlooked Loïc's original suggestion to append the log. That would be easy enough to do as well. I don't have a preference, I'll implement whichever solution you guys think is best.

@Rob: I was suggesting keeping the truncation for the first xsplash and using append for the second, the log wouldn't grow very long since it would clear at each boot.

@Cody: I like xsplash-gdm.log + xsplash-session.log and don't think it's a big deal if we don't have logging until parsing cmdline args.

On Sun, 2009-10-11 at 21:33 +0000, Cody Russell wrote:
> I think I overlooked Loïc's original suggestion to append the log. That
> would be easy enough to do as well. I don't have a preference, I'll
> implement whichever solution you guys think is best.

I've got no preference; as long as we can gather useful timing/debugging
data reliably, I'm happy.

-Rob

Actually, I could do it even before parsing command line parameters if I name it "xsplash-%s.log" with pwd->pw_name.

I realized that wouldn't actually work since it always runs as user 'gdm'. :)

Anyway, just pushed revno 85 to bzr. It will now create xsplash-user.log or xsplash-gdm.log

Packaging is pushed to lp:~ubuntu-desktop/xsplash/ubuntu

This bug was fixed in the package xsplash - 0.8.4-0ubuntu1

---------------
xsplash (0.8.4-0ubuntu1) karmic; urgency=low

  * New upstream version
    - Fix resolution setting to match desktop session after gdm (LP: #413348)
    - Fix top panel appearing above over xsplash (LP: #447084)
    - Fix broken logging (LP: #439268)

 -- Ken VanDine <email address hidden> Thu, 15 Oct 2009 13:36:24 -0400